Esempi di configurazione dell'operatore

Flussi di immagini di riferimento (.spec.applicationImage )

Per eseguire il deployment di un'immagine da uno stream di immagini, è necessario specificare un campo .spec.applicationImage nella propria CR.

spec:
  applicationImage: my-namespace/my-image-stream:1.0

L'esempio precedente ricerca la tag 1.0 dal flusso di immagine my-image-stream nel progetto my-namespace e popola il campo CR .status.imageReference con un'immagine di riferimento come image-registry.openshift-image-registry.svc:5000/my-namespace/my-image-stream@sha256:*****. L'operatore controlla il flusso di immagini specificato e distribuisce nuove immagini come nuove sono disponibili per il tag specificato.

Per fare riferimento ad un flusso di immagine, il campo .spec.applicationImage deve seguire il formato project_name/image_stream_name[:tag] . Se project_name o tag non viene specificata, l'operatore utilizza i valori predefiniti dello spazio dei nomi CR e di latest. Ad esempio, la configurazione di applicationImage: my-image-stream è la stessa di applicationImage: my-namespace/my-image-stream:latest .

L'operatore tenta di trovare prima un nome del flusso di immagini con il formato project_name/image_stream_name e ritorna alla ricerca del registro se non riesce a trovare alcun flusso di immagini che corrisponda al valore.

Questa funzione è disponibile solo se si è in esecuzione su Red Hat® OpenShift®. L'operatore richiede le autorizzazioni ClusterRole se la risorsa del flusso di immagine si trova in un altro spazio dei nomi.

Configura l'account di servizio (.spec.serviceAccount )

L'operatore può creare una risorsa ServiceAccount quando distribuisce una risorsa personalizzata (CR) WebSphereLibertyApplication . Se .spec.serviceAccount.name non è specificato in un CR, l'operatore crea un account di servizio con lo stesso nome del CR (ad esempio my-app). Inoltre, questo account di servizio viene aggiornato dinamicamente quando vengono rilevate modifiche del pull secret nel campo CR .spec.pullSecret.

In alternativa, l'operatore può utilizzare un sito ServiceAccount personalizzato fornito dall'utente. Se .spec.serviceAccount.name è specificato in una CR, l'operatore utilizza l'account del servizio così com'è, con i permessi di read only durante il provisioning di nuovi Pod. È responsabilità dell'utente aggiungere all'account del servizio tutti i segreti di estrazione dell'immagine richiesti quando si accede alle immagini dietro un registro privato.

Per impostazione predefinita, l'operatore verifica che l'account di servizio utilizzato abbia un riferimento a un pull secret valido. Se si utilizza un account di servizio personalizzato, questo controllo può essere disattivato impostando .spec.serviceAccount.skipPullSecretValidation su true nel CR.

Puoi impostare .spec.serviceAccount.mountToken per disabilitare il montaggio del token dell'account del servizio nei pod dell'applicazione. Per impostazione predefinita, il token di account di servizio è montato. Questa configurazione si applica all'account di servizio predefinito creato dall'operatore o all'account di servizio personalizzato fornito dall'utente.

Se le applicazioni richiedono autorizzazioni specifiche ma si desidera comunque che l'operatore crei un ServiceAccount, è possibile creare manualmente un bind del ruolo per eseguire il bind di un ruolo all'account di servizio creato dall'operatore. Per ulteriori informazioni sul controllo degli accessi basato sui ruoli (RBAC), consultare la Kubernetes documentazione.

Aggiungere o modificare le etichette (.metadata.labels)

Per default, l'operatore aggiunge le seguenti etichette a tutte le risorse create per una CR WebSphereLibertyApplication .

È possibile aggiungere nuove etichette o sovrascrivere quelle esistenti, escludendo l'etichetta app.kubernetes.io/instance . Per impostare le etichette, specificarle nella CR come coppie chiave - valore nel campo .metadata.labels .

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
  labels:
    my-label-key: my-label-value
spec:
  applicationImage: quay.io/my-repo/my-app:1.0

Dopo la distribuzione iniziale della CR, tutte le modifiche alle relative etichette vengono applicate solo se viene aggiornato un campo spec .

Durante l'esecuzione in Red Hat OpenShift, ci sono ulteriori etichette e annotazioni standard sulla piattaforma. Sovrascrivi le impostazioni predefinite dove applicabile Red Hat OpenShift elenco e aggiungi eventuali etichette dal che non sono impostate di default utilizzando le istruzioni precedenti.

Aggiungere annotazioni (.metadata.annotations)

Per aggiungere nuove annotazioni in tutte le risorse create per un operatore WebSphere Liberty , specificale nella tua CR come coppie chiave - valore nel campo .metadata.annotations . Le annotazioni in una CR sovrascrivono le annotazioni specificate in una risorsa, ad eccezione delle annotazioni impostate in Service con .spec.service.annotations.

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
  annotations:
    my-annotation-key: my-annotation-value
spec:
  applicationImage: quay.io/my-repo/my-app:1.0

Dopo la distribuzione iniziale della CR, qualsiasi modifica alle sue annotazioni viene applicata solo se viene aggiornato un campo spec .

Quando si esegue in Red Hat OpenShift, ci sono ulteriori annotazioni standard sulla piattaforma. Sovrascrivi le impostazioni predefinite dove applicabile Red Hat OpenShift elenco e aggiungi eventuali etichette dal che non sono impostate di default utilizzando le istruzioni precedenti.

Imposta le variabili di ambiente per un contenitore di applicazioni (. spec.env O .spec.envFrom)

Per impostare le variabili di ambiente per il contenitore della tua applicazione, specifica i campi .spec.env o .spec.envFrom in una CR. Le variabili di ambiente possono provenire direttamente da coppie chiave - valore, ConfigMapo Secret. Le variabili di ambiente impostate dai campi .spec.env o .spec.envFrom sovrascrivono le variabili di ambiente specificate nell'immagine del contenitore.

Utilizzare .spec.envFrom per definire tutti i dati in un ConfigMap o in un Secret come variabili di ambiente in un contenitore. Le chiavi dalle risorse ConfigMap o Secret diventano nomi di variabili di ambiente nel contenitore. La seguente CR imposta le coppie chiave - valore nei campi .spec.env e .spec.envFrom .

spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  env:
    - name: DB_NAME
      value: "database"
    - name: DB_PORT
      valueFrom:
        configMapKeyRef:
          name: db-config
          key: db-port
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          name: db-credential
          key: adminUsername
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-credential
          key: adminPassword
  envFrom:
    - configMapRef:
        name: env-configmap
    - secretRef:
        name: env-secrets

Per un altro esempio che utilizza .spec.envFrom.secretRef, vedi Utilizzo delle variabili di ambiente per le credenziali di autenticazione di base. Per un esempio che sovrascrive i valori predefiniti della variabile di ambiente di log della console, vedi Override console logging environment variable default values (.spec.env).

Sovrascrivere i valori predefiniti della variabile di ambiente di registrazione della console (.spec.env)

L'operatore WebSphere Liberty imposta le variabili di ambiente correlate alla registrazione della console per impostazione predefinita. È possibile sovrascrivere i valori predefiniti di registrazione della console con i propri valori nell'elenco CR .spec.env .

La seguente tabella elenca le variabili di ambiente di registrazione della console e i relativi valori predefiniti.

Per sovrascrivere i valori predefiniti per le variabili di ambiente di log della console, impostare i valori preferiti manualmente nel proprio elenco CR .spec.env . Per informazioni sui valori che è possibile impostare, consultare la Open Liberty documentazione relativa alla registrazione.

Il seguente esempio mostra un elenco CR .spec.env che imposta i valori non predefiniti per le variabili di ambiente di registrazione della console.

spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  env:
    - name: WLP_LOGGING_CONSOLE_FORMAT
      value: "DEV"
    - name: WLP_LOGGING_CONSOLE_SOURCE
      value: "messages,trace,accessLog"
    - name: WLP_LOGGING_CONSOLE_LOGLEVEL
      value: "error"

Per ulteriori informazioni sulla sostituzione dei valori predefiniti delle variabili, vedere Imposta le variabili di ambiente per un contenitore di applicazioni (. spec.env O .spec.envFrom). Per informazioni sul controllo delle applicazioni e sull'analisi dei log dell'applicazione, vedi Osservazione con l'operatore WebSphere Liberty

Configurare le repliche statiche per l'alta disponibilità (. spec.replicas )

Per eseguire più istanze dell'applicazione per l'alta disponibilità con un numero fisso di repliche, utilizzare il campo .spec.replicas campo. Il campo .spec.replicas mantiene un numero costante di istanze dell'applicazione indipendentemente dal consumo di risorse. Questa configurazione viene ignorata quando l'autoscaling è configurato utilizzando il campo .spec.autoscaling .

Configurare l'autoscaling orizzontale dei pod per l'alta disponibilità (. spec.autoscaling )

Imposta privilegi e autorizzazioni per un pod o un contenitore (.spec.securityContext )

Un contesto di sicurezza controlla le impostazioni dei privilegi e delle autorizzazioni per un pod o un contenitore dell'applicazione. Per impostazione predefinita, l'operatore imposta diversi parametri .spec.securityContext per un contenitore dell'applicazione come mostrato nel seguente esempio.

spec:
  containers:
    - name: app
      securityContext:
        capabilities:
          drop:
            - ALL
        privileged: false
        runAsNonRoot: true
        readOnlyRootFilesystem: false
        allowPrivilegeEscalation: false
        seccompProfile:
          type: RuntimeDefault

Per sovrascrivere i valori predefiniti o impostare più parametri, modificare i parametri .spec.securityContext , ad esempio:

spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  securityContext:
    readOnlyRootFilesystem: true
    runAsUser: 1001
    seLinuxOptions:
      level: "s0:c123,c456"

L'operatore WebSphere Liberty imposta il campo securityContext sul profilo seccomp RuntimeDefault . Se il cluster Kubernetes utilizza vincoli di sicurezza personalizzati, seccompProfiles deve essere impostato su runtime/default.

Per utilizzare i vincoli personalizzati del contesto di sicurezza con il cluster Kubernetes, aggiungere la seguente sezione.

seccompProfiles:
  - runtime/default

Se l'applicazione richiede che seccomp sia disabilitato, seccompProfile deve essere impostato su unconfined sia nei vincoli del contesto di sicurezza che nel CR WebSphereLibertyApplication

seccompProfiles:
  - unconfined

spec:
  securityContext:
    seccompProfile:
      type: Unconfined

Per ulteriori informazioni, vedere Impostare il contesto di sicurezza per un contenitore.

Perseverare risorse ( .spec.statefulSet E .spec.volumeMounts)

Se l'archiviazione è specificata in WebSphereLibertyApplication CR, l'operatore può creare un StatefulSet e PersistentVolumeClaim per ogni pod. Se l'archiviazione non è specificata, la risorsa StatefulSet viene creata senza l'archiviazione persistente.

La seguente definizione CR utilizza .spec.statefulSet.storage per fornire l'archiviazione di base. L'operatore crea un StatefulSet con la dimensione di 1Gi che viene montato nella cartella /data .

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  statefulSet:
    storage:
      size: 1Gi
      mountPath: "/data"

Una definizione di CR WebSphereLibertyApplication può fornire una memoria più avanzata. Con la seguente definizione di CR, l'operatore crea un PersistentVolumeClaim denominato pvc con la dimensione della modalità di accesso 1Gi e ReadWriteOnce . L'operatore consente agli utenti di fornire un intero .spec.statefulSet.storage.volumeClaimTemplate per il controllo completo sul PersistentVolumeClaimcreato automaticamente. Per conservare più di una cartella, la definizione CR utilizza il campo .spec.volumeMounts invece di .spec.statefulSet.storage.mountPath.

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  volumeMounts:
  - name: pvc
    mountPath: /data_1
    subPath: data_1
  - name: pvc
    mountPath: /data_2
    subPath: data_2
  statefulSet:
    storage:
      volumeClaimTemplate:
        metadata:
          name: pvc
        spec:
          accessModes:
          - "ReadWriteMany"
          storageClassName: 'glusterfs'
          resources:
            requests:
              storage: 1Gi

La seguente definizione di CR non specifica l'archiviazione e crea risorse StatefulSet senza l'archiviazione persistente. Puoi creare risorse StatefulSet senza archiviazione se hai bisogno solo dell'ordine e dell'univocità di una serie di pod.

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  statefulSet: {}

Monitora le risorse (.spec.monitoring)

Un operatore WebSphere Liberty può creare una risorsa ServiceMonitor da integrare con l'operatore Prometheus .

Fornire almeno un'etichetta per la serie Prometheus sugli oggetti ServiceMonitor . Nel seguente esempio, l'etichetta .spec.monitoring è apps-prometheus.

spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  monitoring:
    labels:
       app-prometheus: ''
    endpoints:
    - interval: '30s'
      basicAuth:
        username:
          key: username
          name: metrics-secret
        password:
          key: password
          name: metrics-secret
      tlsConfig:
        insecureSkipVerify: true

Per un monitoraggio più avanzato, impostare molti ServicerMonitor parametri come il segreto di autenticazione con Prometheus Endpoint.

spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  monitoring:
    labels:
       app-prometheus: ''
    endpoints:
    - interval: '30s'
      basicAuth:
        username:
          key: username
          name: metrics-secret
        password:
          key: password
          name: metrics-secret
      tlsConfig:
        insecureSkipVerify: true

Specificare più porte servizio (.spec.service.port* e.spec.monitoring.endpoints)

Per fornire più porte servizio oltre alla porta servizio primaria, configurare la porta servizio primaria con i campi .spec.service.port, .spec.service.targetPort .spec.service.portNamee .spec.service.nodePort . La porta primaria viene esposta dal contenitore che esegue l'applicazione e i valori della porta vengono utilizzati per configurare l'instradamento (o Ingress), il bind del servizio e il servizio Knative.

Per specificare una porta alternativa per il monitor di servizio, utilizzare il campo .spec.monitoring.endpoints e specificare il campo port o targetPort , altrimenti il valore predefinito è la porta primaria.

Specificare la porta primaria con il campo .spec.service.port e ulteriori porte con il campo .spec.service.ports come mostrato nel seguente esempio.

spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  service:
    type: NodePort
    port: 9080
    portName: http
    targetPort: 9080
    nodePort: 30008
    ports:
      - port: 9443
        name: https
  monitoring:
    endpoints:
      - basicAuth:
          password:
            key: password
            name: metrics-secret
          username:
            key: username
            name: metrics-secret
        interval: 5s
        port: https
        scheme: HTTPS
        tlsConfig:
          insecureSkipVerify: true
    labels:
      app-monitoring: 'true'

Configura probe (.spec.probes)

I probe sono controlli di integrità su un contenitore dell'applicazione per determinare se è attivo o pronto a ricevere il traffico. L'operatore WebSphere Liberty dispone di probe startup, livenesse readiness .

I probe non vengono abilitati nelle applicazioni per impostazione predefinita. Per abilitare un probe con i valori predefiniti, impostare i parametri probe su {}. Il seguente esempio consente a tutti e 3 i probe di utilizzare i valori predefiniti.

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
spec:
  probes:
    startup: {}
    liveness: {}
    readiness: {}

  httpGet:
    path: /health/started
    port: 9443
    scheme: HTTPS
  timeoutSeconds: 2
  periodSeconds: 10
  failureThreshold: 20

  httpGet:
    path: /health/live
    port: 9443
    scheme: HTTPS
  initialDelaySeconds: 60
  timeoutSeconds: 2
  periodSeconds: 10
  failureThreshold: 3

  httpGet:
    path: /health/ready
    port: 9443
    scheme: HTTPS
  initialDelaySeconds: 10
  timeoutSeconds: 2
  periodSeconds: 10
  failureThreshold: 10

Per sovrascrivere un valore predefinito, specificare un altro valore. Il seguente esempio sovrascrive un valore predefinito di ritardo iniziale dell'analisi di attività di 60 secondi e imposta il ritardo iniziale su 90 secondi.

spec:
  probes:
    liveness:
      initialDelaySeconds: 90

Quando un parametro probe initialDelaySeconds è impostato su 0, viene utilizzato il valore predefinito. Per impostare un ritardo iniziale dell'analisi su 0, definire l'analisi invece di utilizzare l'analisi predefinita. Il seguente esempio sovrascrive il valore predefinito e imposta il ritardo iniziale su 0.

spec:
  probes:
    liveness:
      httpGet:
        path: "/health/live"
        port: 9443
      initialDelaySeconds: 0

Configurare le sonde basate su file con mpHealth-4.0 (.spec.probes.enableFileBased )

A partire dalla Liberty versione operatore 1.5.2, un nuovo campo booleano, .spec.probes.enableFileBased, consente di impostare controlli di integrità basati su file utilizzando la funzione MicroProfile 4.0 Integrità.

Le sonde basate su file non sono abilitate di default nelle applicazioni. L'operatore Liberty utilizza per impostazione HTTP predefinita le sonde GET.

• L'immagine Liberty specificata in .spec.applicationImage richiede che mpHealth-4.0 la funzionalità sia installata e abilitata su un server Liberty con versione 25.0.0.6 o superiore.
• Per abilitare una sonda basata su file con i valori predefiniti, impostare enableFileBased su true e i parametri della sonda su {}. L'esempio seguente consente a tutte e tre le sonde di utilizzare valori predefiniti basati su file.

  spec:
    probes:
      enableFileBased: true
      startup: {}
      liveness: {}
      readiness: {}

Le prove di avvio, funzionalità e disponibilità basate su file ereditano gli stessi valori predefiniti (senza impostazione httpGet) descritti nella sezione Configurazione delle prove (. spec.probes ).

Una volta abilitate le sonde basate su file, Liberty l'operatore configura l'applicazione per monitorare i file all'interno della /output/health directory del contenitore.

sh-4.4$ ls -la /output/health
total 0
drwxr-x---. 2 1000730000 root 46 Nov 21 16:07 .
drwxrwx---. 1 default    root 65 Nov 21 16:07 ..
-rw-r-----. 1 1000730000 root  0 Nov 21 16:07 live
-rw-r-----. 1 1000730000 root  0 Nov 21 16:07 ready
-rw-r-----. 1 1000730000 root  0 Nov 21 16:07 started

Ogni pochi secondi, un Liberty server che utilizza la mpHealth-4.0 funzionalità potrebbe creare/aggiornare i file live, ready e/o started con un timestamp appena modificato per indicare uno stato UP. L'intervallo con cui Liberty controlla questi file può essere modificato utilizzando i .spec.probes.checkInterval campi .spec.probes.startupCheckInterval e. Per impostazione predefinita, questi intervalli di controllo sono impostati rispettivamente su 5s e 100ms.

spec:
  probes:
    enableFileBased: true
    startup: {}
    liveness: {}
    readiness: {}
    checkInterval: 5s
    startupCheckInterval: 100ms

Per allinearsi al comportamento delle sonde non basate su file, impostare il Liberty server in modo che controlli i file live, readystarted , o più velocemente del tempo impiegato da Kubernetes per eseguire una singola sonda. Ad esempio, impostare un buffer in modo che gli intervalli di controllo mantengano la proprietà di interval * 1.5 ⇐ periodSeconds. In questo caso, le WebSphereLibertyApplication sonde hanno un valore predefinito periodSeconds di 10, che soddisfa il vincolo con intervalli di controllo di 5s e 100ms. Se modifichi i valori periodSecondsdelle startupCheckInterval proprietà, checkInterval, o, mantieni questo vincolo per evitare tempi di inattività imprevisti dei pod.

spec:
  probes:
    enableFileBased: true
    startup:
      # periodSeconds: 10
    liveness:
      # periodSeconds: 10
    readiness:
      # periodSeconds: 10
    checkInterval: 5s
    startupCheckInterval: 100ms

Distribuisci applicazioni serverless con Knative (.spec.createKnativeService )

Se Knative è installato su un Kubernetes cluster, per distribuire applicazioni serverless con Knative sul cluster, l'operatore crea una risorsa Service Knative che gestisce l'intero ciclo di vita di un carico di lavoro. Per creare un servizio Knative, impostare .spec.createKnativeService su true.

spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  createKnativeService: true

L'operatore crea un servizio Knative nel cluster e popola la risorsa con i campi WebSphereLibertyApplication applicabili. Inoltre, garantisce che le risorse non Knative come Kubernetes Service, Routee Deployment vengano eliminate.

I campi CRD che possono popolare la risorsa del servizio Knative includono .spec.applicationImage, .spec.serviceAccount.name, .spec.probes.liveness, .spec.probes.readiness, .spec.service.Port, .spec.volumes, .spec.volumeMounts, .spec.env, .spec.envFrom, .spec.pullSecret e .spec.pullPolicy. Il probe di avvio non è completamente supportato da Knative, quindi .spec.probes.startup non si applica quando il servizio Knative è abilitato.

Per i dettagli su come configurare Knative per attività quali l'abilitazione HTTPS delle connessioni e l'impostazione di un dominio personalizzato, consultare la documentazione Knative.

I campi di ridimensionamento automatico in WebSphereLibertyApplication non vengono utilizzati per configurare KPA (Knative Pod Autoscaler). Per informazioni su come configurare KPA, consulta Configurazione dell'autoscaler.

Esporre le applicazioni esternamente (. spec.expose , .spec.createKnativeService, . spec.route )

Esponi un'applicazione esternamente con una risorsa Route, Knative Route o Ingress.

Per esporre un'applicazione esternamente con una rotta in una distribuzione non Knative, impostare .spec.expose su true.

L'operatore crea un instradamento protetto in base al servizio dell'applicazione quando .spec.manageTLS è abilitato. Per utilizzare i certificati personalizzati, consultare le informazioni su .spec.service.certificateSecretRef e .spec.route.certificateSecretRef.

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  expose: true

Per esporre un'applicazione esternamente con Ingress in una distribuzione non - Knative, completa la seguente procedura.

1. Per utilizzare la risorsa Ingress per esporre il cluster, installare un controller Ingress come Nginx o Traefik.
2. Assicurarsi che una risorsa di Route non si trova sul cluster. La risorsa Ingress viene creata solo se la risorsa Route non è disponibile nel cluster.
3. Per utilizzare la risorsa Ingress, impostare la defaultHostName variabile nell'oggetto ConfigMap Operator su un nome host come mycompany.com
4. Abilita TLS. Generare il certificato e specificare il segreto che contiene il certificato con il campo .spec.route.certificateSecretRef .

   apiVersion: liberty.websphere.ibm.com/v1
   Kind: WebSphereLibertyApplication
   metadata:
     name: my-app
     namespace: backend
   spec:
     applicationImage: quay.io/my-repo/my-app:1.0
     expose: true
     route:
       certificateSecretRef: mycompany-tls

5. Specificare .spec.route.annotations per configurare la risorsa Ingress. Le annotazioni come Nginx, HAProxy, Traefik e altre sono specifiche dell'implementazione del controller Ingress.

   Il seguente esempio specifica le annotazioni, un segreto TLS esistente e un nome host personalizzato.

   apiVersion: liberty.websphere.ibm.com/v1
   Kind: WebSphereLibertyApplication
   metadata:
     name: my-app
     namespace: backend
   spec:
     applicationImage: quay.io/my-repo/my-app:1.0
     expose: true
     route:
       annotations:
         # You can use this annotation to specify the name of the ingress controller to use.
         # You can install multiple ingress controllers to address different types of incoming traffic such as an external or internal DNS.
         kubernetes.io/ingress.class: "nginx"
   
         # The following nginx annotation enables a secure pod connection:
         nginx.ingress.kubernetes.io/ssl-redirect: true
         nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
   
         # The following traefik annotation enables a secure pod connection:
         traefik.ingress.kubernetes.io/service.serversscheme: https
   
       # Use a custom hostname for the Ingress
       host: app-v1.mycompany.com
       # Reference a pre-existing TLS secret:
       certificateSecretRef: mycompany-tls

Per esporre un'applicazione come servizio Knative, impostare .spec.createKnativeService e .spec.expose su true. L'operatore crea un instradamento Knative non protetto. Per configurare connessioni HTTPS sicure per la distribuzione Knative, consultare Configurazione HTTPS con certificati TLS.

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  createKnativeService: true
  expose: true

Consentire o limitare il traffico in entrata (.spec.networkPolicy )

Per impostazione predefinita, le politiche di rete per un'applicazione isolano il traffico in entrata.

• La politica di rete predefinita creata per le applicazioni che non sono esposte limita il traffico in entrata ai pod nello stesso spazio dei nomi che fanno parte della stessa applicazione. Il traffico è limitato solo alle porte configurate dal servizio. Per impostazione predefinita, il traffico sarà esposto a .spec.service.targetPort quando specificato e altrimenti si ripiegherà sull'uso di .spec.service.port. Utilizzando la stessa logica, il traffico sarà esposto per ogni ulteriore targetPort o port fornito nell'array .spec.service.ports[].
• Red Hat OpenShift supporta le politiche di rete per impostazione predefinita. Per le applicazioni esposte su Red Hat OpenShift, la normativa di rete consente il traffico in entrata dal controller di ingresso Red Hat OpenShift sulle porte nella configurazione del servizio. La politica di rete consente anche il traffico in entrata dallo stack di monitoraggio Red Hat OpenShift .
• Per le applicazioni esposte su altre piattaforme Kubernetes , la politica di rete consente il traffico in entrata da qualsiasi pod in qualsiasi spazio dei nomi sulle porte nella configurazione del servizio. Per le distribuzioni su altre Kubernetes piattaforme, assicurarsi che il plug-in di rete supporti le Kubernetes politiche di rete.

Per disabilitare la creazione delle politiche di rete per una applicazione, impostare .spec.networkPolicy.disable su true.

spec:
  networkPolicy:
    disable: true

Puoi cambiare la politica di rete per consentire il traffico in entrata da specifici spazi dei nomi o pod. Per impostazione predefinita, .spec.networkPolicy.namespaceLabels è impostata sullo stesso spazio dei nomi in cui è distribuita l'applicazione e .spec.networkPolicy.fromLabels è impostata sui pod che appartengono alla stessa applicazione specificata da .spec.applicationName. Il seguente esempio consente il traffico in entrata dai pod etichettati con il ruolo frontend e che si trovano nello stesso spazio dei nomi.

spec:
  networkPolicy:
    fromLabels:
      role: frontend

Il seguente esempio consente il traffico in entrata dai pod che appartengono alla stessa applicazione nel namespace example .

spec:
  networkPolicy:
    namespaceLabels:
      kubernetes.io/metadata.name: example

Il seguente esempio consente il traffico in entrata dai pod etichettati con il ruolo frontend nello spazio dei nomi example .

spec:
  networkPolicy:
    namespaceLabels:
      kubernetes.io/metadata.name: example
    fromLabels:
      role: frontend

Eseguire il bind delle applicazioni con i servizi di backup gestiti dall'operatore (.status.binding.name e.spec.service.bindable)

L'operatore di associazione dei servizi consente agli sviluppatori di applicazioni di associare le applicazioni ai servizi di supporto gestiti dall'operatore. Se Service Binding Operator è installato sul cluster, puoi eseguire il bind delle applicazioni creando una risorsa personalizzata ServiceBindingRequest .

È possibile configurare WebSphere Liberty un'applicazione affinché si comporti come un servizio fornito definito dalla specifica di associazione dei servizi. Secondo la specifica, una risorsa del servizio di provisioning deve definire un .status.binding.name che fa riferimento a un segreto. Per esporre la tua applicazione come un servizio di provisioning, imposta il campo .spec.service.bindable su un valore true. L'operatore crea un segreto di bind denominato CR_NAME-expose-binding e aggiunge le voci host, port, protocol, basePathe uri al segreto.

Per sovrascrivere i valori predefiniti per le voci nel segreto di bind o per aggiungere nuove voci al segreto, creare un segreto di sovrascrittura denominato CR_NAME-expose-binding-override e aggiungere eventuali voci al segreto. L'operatore legge il contenuto del segreto di sovrascrittura e sovrascrive i valori predefiniti nel segreto di bind.

Dopo che un'applicazione WebSphere Liberty è stata esposta come un servizio di provisioning, una richiesta di bind del servizio può fare riferimento all'applicazione come un servizio di backup.

Le istruzioni che seguono mostrano come associare le applicazioni WebSphere Liberty come servizi o produttori ad altri carichi di lavoro (come pod o distribuzioni). Due applicazioni WebSphere Liberty distribuite tramite l'operatore WebSphere Liberty non possono essere associate. Per ulteriori informazioni, vedi Problemi e limitazioni noti.

• Impostare l'operatore Bind servizio per accedere alle applicazioni WebSphere Liberty .
  Per impostazione predefinita, l'operatore Binding di servizi non ha le autorizzazioni per interagire con applicazioni WebSphere Liberty distribuite tramite l'operatore WebSphere Liberty . È necessario creare due RoleBindings per fornire la vista operatore Bind del servizio e modificare l'accesso per applicazioni WebSphere Liberty .

  1. Nella Red Hat OpenShift dashboard, vai su Gestione utenti > RoleBindings.
  2. Selezionare Crea collegamento.
  3. Impostare il Tipo di associazione su Cluster-wide role binding (ClusterRoleBinding).
  4. Immettere un nome per il collegamento. Scegliere un nome correlato ai bind del servizio e visualizzare l'accesso per le applicazioni WebSphere .
  5. Per il nome ruolo, immettere webspherelibertyapplications.liberty.websphere.ibm.com-v1-view.
  6. Impostare l' Oggetto su ServiceAccount.
  7. Viene visualizzato un menu Spazio dei nomi oggetto . Selezionare openshift-operators.
  8. Nel campo Nome oggetto , immettere service-binding-operator.
  9. Fare clic su Crea.
  Ora che è stato impostato il primo bind del ruolo, passare all'elenco RoleBindings e fare nuovamente clic su Crea bind . Impostare l'accesso di modifica utilizzando le seguenti istruzioni.

  1. Impostare Tipo di bind su Cluster-wide role binding (ClusterRoleBinding).
  2. Immettere un nome per il collegamento. Scegliere un nome correlato ai bind del servizio e modificare l'accesso per le applicazioni WebSphere .
  3. Nel campo Nome ruolo, immettere webspherelibertyapplications.liberty.websphere.ibm.com-v1-edit.
  4. Impostare Oggetto su ServiceAccount.
  5. Nell'elenco Spazio dei nomi oggetto , selezionare openshift-operators.
  6. Nel campo Nome oggetto , immettere service-binding-operator.
  7. Fare clic su Crea.

  I bind del servizio dalle applicazioni WebSphere Liberty (o "servizi") ai pod o alle distribuzione (o "carichi di lavoro") ora hanno esito positivo. Dopo che è stato eseguito un bind, il carico di lavoro associato viene riavviato o ridimensionato per montare il segreto di bind in /bindings in tutti i contenitori.

• Imposta un bind del servizio utilizzando il metodo Red Hat .
  Per ulteriori informazioni, consultare la Red Hat documentazione o il Red Hat tutorial.

  1. Sul dashboard Web Red Hat OpenShift , fai clic su Amministratore sulla barra laterale e seleziona Sviluppatore.
  2. Nella vista Topologia per lo spazio dei nomi corrente, passare con il mouse sul bordo dell'applicazione WebSphere da collegare come servizio e trascinare una freccia sul carico di lavoro Pod o Distribuzione. Viene visualizzato un suggerimento denominato Crea bind del servizio.
  3. Viene visualizzata la finestra Crea bind del servizio . Modificare il nome in un valore inferiore a 63 caratteri. L'operatore di bind del servizio potrebbe non riuscire a montare il segreto come volume se il nome supera i 63 caratteri.
  4. Fare clic su Crea.
  5. Si apre una barra laterale. Per visualizzare lo stato del bind, fare clic sul nome del segreto e scorrere fino a visualizzare lo stato.
  6. Controlla il carico di lavoro di pod / distribuzione e verifica che un volume sia montato. È inoltre possibile aprire una sessione terminale in un contenitore ed eseguire ls /bindings.
• Impostare un bind del servizio utilizzando il metodo Spec API Tech Preview / Community.
  Questo metodo è più recente del metodo Red Hat ma ottiene gli stessi risultati. È necessario aggiungere un'etichetta all'applicazione WebSphere Liberty , ad esempio app=frontend, se non dispone di etichette univoche. Impostare il bind per utilizzare un selettore di etichetta in modo che l'operatore Binding di servizio ricerca un'applicazione WebSphere Liberty con un'etichetta specifica.

  1. Installa l'operatore di bind del servizio utilizzando Red Hat OpenShift Operator Catalog.
  2. Seleziona Operatori > Operatori installati e imposta lo spazio dei nomi in modo che sia lo stesso utilizzato sia WebSphere dall'applicazione che dal carico di lavoro pod/distribuzione.
  3. Apri la pagina Service Binding (Spec API Tech Preview) .
  4. Fare clic su Crea ServiceBinding.
  5. Scegliere un nome breve per il bind. I nomi che superano i 63 caratteri potrebbero causare l'esito negativo del montaggio del volume segreto di bind.
  6. Espandere la sezione Servizio .
  7. Nel campo Versione API , immettere liberty.websphere.ibm.com/v1.
  8. Nel campo Tipo , immettere WebSphereLibertyApplication.
  9. Nel campo Nome , immettere il nome dell'applicazione. È possibile ottenere questo nome dall'elenco di applicazioni nella pagina operatore WebSphere Liberty .
  10. Espandere la sezione Workload .
  11. Impostare il campo Versione API sul valore di apiVersion nel carico di lavoro di destinazione YAML. Ad esempio, se il carico di lavoro è una distribuzione, il valore è apps/v1.
  12. Imposta il campo Kind sul valore kind nel tuo YAML del carico di lavoro di destinazione. Ad esempio, se il carico di lavoro è una distribuzione, il valore è Deployment.
  13. Espandere la sottosezione Selettore ed espandere la sottosezione Espressioni di corrispondenza .
  14. Fare clic su Aggiungi espressione di corrispondenza.
  15. Nel campo Chiave , immettere la chiave di etichetta impostata in precedenza. Ad esempio, per l'etichetta app=frontend, la chiave è app).
  16. Nel campo Operatore , immettere Exists.
  17. Espandere la sottosezione Valori e fare clic su Aggiungi valore.
  18. Nel campo Valore , immettere il valore dell'etichetta impostato precedentemente. Ad esempio, se si utilizza l'etichetta app=frontend, il valore è frontend.
  19. Fare clic su Crea.
  20. Controllare il carico di lavoro Pod / Deployment e verificare che un volume sia montato, scorrendo verso il basso o aprendo una sessione terminale in un contenitore ed eseguendo ls /bindings.

Limita un pod da eseguire sui nodi specificati (spec.affinity)

Utilizzare .spec.affinity per vincolare un pod all'esecuzione solo su nodi specificati.

Per impostare le etichette richieste per la pianificazione pod su nodi specifici, utilizzare il campo .spec.affinity.nodeAffinityLabels .

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
  namespace: test
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  affinity:
    nodeAffinityLabels:
      customNodeLabel: label1, label2
      customNodeLabel2: label3

Il seguente esempio richiede un tipo di nodo large e le preferenze per due zone, denominate zoneA e zoneB.

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
  namespace: test
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key:  node.kubernetes.io/instance-type
            operator: In
            values:
            - large
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 60
        preference:
          matchExpressions:
          - key: failure-domain.beta.kubernetes.io/zone
            operator: In
            values:
            - zoneA
      - weight: 20
        preference:
          matchExpressions:
          - key: failure-domain.beta.kubernetes.io/zone
            operator: In
            values:
            - zoneB

Utilizza l'affinità pod e l'anti - affinità per vincolare quali nodi il tuo pod è idoneo per essere pianificato in base alle etichette sui pod che sono già in esecuzione sul nodo piuttosto che in base alle etichette sul nodo.

Il seguente esempio mostra che l'affinità del pod è obbligatoria e che i pod per Service-A e Service-B devono trovarsi nella stessa zona. Tramite l'anti - affinità del pod, è preferibile non pianificare Service_B e Service_C sullo stesso host.

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: Service-B
  namespace: test
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: service
            operator: In
            values:
            - Service-A
        topologyKey: failure-domain.beta.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: service
              operator: In
              values:
              - Service-C
          topologyKey: kubernetes.io/hostname

Limita il modo in cui i pod vengono distribuiti tra nodi e zone (.spec.topologySpreadConstraints )

Usare l'oggetto .spec.topologySpreadConstraints YAML per specificare i vincoli su come i pod dell'istanza dell'applicazione (e, se abilitata, l'istanza di Semeru Cloud Compiler) sono distribuiti tra i nodi e le zone del cluster.

Utilizzando il .spec.topologySpreadConstraints.constraints campo, è possibile specificare un elenco di Pod TopologySpreadConstraints da aggiungere, come nell'esempio seguente:

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
  namespace: test
spec:
  topologySpreadConstraints:
    constraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app.kubernetes.io/instance: my-app

Per impostazione predefinita, l'operatore aggiunge i seguenti vincoli di diffusione della topologia Pod ai pod dell'istanza dell'applicazione (e, se applicabile, ai pod dell'istanza di Semeru Cloud Compiler). Il comportamento predefinito è quello di limitare la diffusione dei pod che sono di proprietà della stessa istanza applicativa (o istanza di generazione di Semeru Cloud Compiler), denotata da <nome istanza> con un maxSkew di 1.

- maxSkew: 1
  topologyKey: kubernetes.io/hostname
  whenUnsatisfiable: ScheduleAnyway
  labelSelector:
    matchLabels:
      app.kubernetes.io/instance: <instance name>
- maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: ScheduleAnyway
  labelSelector:
    matchLabels:
      app.kubernetes.io/instance: <instance name>

Per rimuovere i vincoli di diffusione della topologia predefiniti dall'operatore, impostare il flag .spec.topologySpreadConstraints.disableOperatorDefaults su true.

apiVersion: liberty.websphere.ibm.com/v1
Kind: WebSphereLibertyApplication
metadata:
  name: my-app
  namespace: test
spec:
  topologySpreadConstraints:
    disableOperatorDefaults: true

In alternativa, sovrascrivere manualmente ciascun vincolo creandone uno nuovo TopologySpreadConstraint Sotto.spec.topologySpreadConstraints.constraints per ciascunotopologyKey vuoi modificare.

Configurare il DNS (.spec.dns.policy e .spec.dns.config)

Il DNS può essere configurato in WebSphereLibertyApplication CR utilizzando il campo .spec.dns.policy o il campo .spec.dns.config. Il campo .spec.dns.policy è il criterio DNS per l'application pod e ha come impostazione predefinita il criterio ClusterFirst. Il campo .spec.dns.config è la configurazione DNS del pod dell'applicazione.

DNS Config consente agli utenti di controllare maggiormente le impostazioni DNS di un'applicazione Pod.

Il campo .spec.dns.config è opzionale e può funzionare con qualsiasi impostazione .spec.dns.policy. Tuttavia, quando un .spec.dns.policy è impostato su None, il campo .spec.dns.config deve essere specificato.

spec:
  dns:
    policy: "None"
    config:
      nameservers:
        - 192.0.2.1 # this is an example
      searches:
        - ns1.svc.cluster-domain.example
        - my.dns.search.suffix
      options:
        - name: ndots
          value: "2"
        - name: edns0

Per ulteriori informazioni sul DNS, consultare la Kubernetes documentazione sul DNS.

Configurare le tolleranze (.spec.tolerations)

L'affinità dei nodi è una proprietà che attira i pod verso un insieme di nodi, sia come preferenza che come requisito fondamentale. Tuttavia, le contaminazioni consentono a un nodo di respingere un insieme di baccelli.

Le tolleranze sono applicate ai pod e consentono a uno scheduler di pianificare pod con taint corrispondenti. Lo scheduler valuta anche altri parametri come parte della sua funzione.

I taints e le tolleranze lavorano insieme per garantire che i pod delle applicazioni non vengano pianificati su nodi inadeguati. Se a un nodo sono stati applicati uno o più taint, il nodo non può accettare alcun pod che non tolleri i taint.

Le tolleranze possono essere configurate in WebSphereLibertyApplication CR utilizzando il campo .spec.tolerations.

spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"

Per ulteriori informazioni sui difetti e sulla tolleranza, consultare la Kubernetes documentazione relativa ai difetti e alla tolleranza.