Ejemplos de configuración del operador

Secuencias de imágenes de referencia (.spec.applicationImage)

Para desplegar una imagen desde una secuencia de imágenes, debe especificar un campo .spec.applicationImage en el CR.

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

El ejemplo anterior busca el código 1.0 de la secuencia de imágenes de my-image-stream en el proyecto my-namespace y llena el campo .status.imageReference del CR con una imagen referenciada como image-registry.openshift-image-registry.svc:5000/my-namespace/my-image-stream@sha256:*****. El operador observa la secuencia de imágenes especificada y despliega nuevas imágenes ya que hay nuevas disponibles para la etiqueta especificada.

Para hacer referencia a una secuencia de imágenes, el campo .spec.applicationImage debe seguir el formato project_name/image_stream_name[:tag]. Si no se especifica nombre_proyecto o etiqueta, el operador utiliza los valores predeterminados del espacio de nombres de CR y de latest. Por ejemplo, la configuración de applicationImage: my-image-stream es la misma que la configuración de applicationImage: my-namespace/my-image-stream:latest.

El operador intenta buscar primero un nombre de secuencia de imagen con el formato project_name/image_stream_name y vuelve a la búsqueda de registro si no puede encontrar ninguna secuencia de imagen que coincida con el valor.

Esta característica sólo está disponible si se está ejecutando en Red Hat® OpenShift®. El operador requiere permisos de ClusterRole si el recurso de secuencia de imágenes está en otro espacio de nombres.

Configurar cuenta de servicio (.spec.serviceAccount )

El operador puede crear un recurso ServiceAccount al desplegar un recurso personalizado (CR) WebSphereLibertyApplication . Si no se especifica .spec.serviceAccount.name no se especifica en una CR, el operador crea una cuenta de servicio con el mismo nombre que la CR (como my-app). Además, esta cuenta de servicio se actualiza dinámicamente cuando se detectan cambios de pull secret en el campo CR .spec.pullSecret.

Alternativamente, el operador puede utilizar un ServiceAccount personalizado que usted le proporcione. Si .spec.serviceAccount.name se especifica en una CR, el operador utiliza la cuenta de servicio tal cual, con los permisos de read only cuando aprovisiona nuevos Pods. Es su responsabilidad añadir los secretos de extracción de imágenes necesarios a la cuenta de servicio cuando acceda a imágenes detrás de un registro privado.

Por defecto, el operador verifica que la cuenta de servicio que se utiliza tiene una referencia a un pull secret válido. Si se utiliza una cuenta de servicio personalizada, esta comprobación puede desactivarse configurando .spec.serviceAccount.skipPullSecretValidation en true en el CR.

Puede establecer .spec.serviceAccount.mountToken para inhabilitar el montaje de la señal de cuenta de servicio en los pods de aplicación. De forma predeterminada, se monta la señal de cuenta de servicio. Esta configuración se aplica a la cuenta de servicio predeterminada que crea el operador o a la cuenta de servicio personalizada que proporcione.

Si las aplicaciones requieren permisos específicos pero siguen deseando que el operador cree un ServiceAccount, puede crear manualmente un enlace de rol para enlazar un rol con la cuenta de servicio que ha creado el operador. Para obtener más información sobre el control de acceso basado en roles (RBAC), consulte la documentación de Kubernetes.

Añadir o cambiar etiquetas (.metadata.etiquetas)

De forma predeterminada, el operador añade las etiquetas siguientes a todos los recursos que se crean para un CR WebSphereLibertyApplication .

Puede añadir etiquetas nuevas o sobrescribir etiquetas existentes, excluyendo la etiqueta app.kubernetes.io/instance. Para establecer etiquetas, especifíquelas en el CR como pares de clave-valor en el 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

Después del despliegue inicial del CR, los cambios en las etiquetas sólo se aplican si se actualiza un campo spec.

Cuando se ejecuta en Red Hat OpenShift, hay etiquetas y anotaciones adicionales que son estándar en la plataforma. Sobrescriba los valores predeterminados donde sea aplicable y añada las etiquetas de la Lista de Red Hat OpenShift que no estén establecidas de forma predeterminada utilizando las instrucciones anteriores.

Añadir anotaciones (.metadata.annotations)

Para añadir nuevas anotaciones a todos los recursos creados para un operador WebSphere Liberty, especifíquelas en el CR como pares de clave-valor en el campo .metadata.annotations. Las anotaciones en un CR sustituyen las anotaciones especificadas en un recurso, excepto las anotaciones establecidas en 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

Después del despliegue inicial del CR, los cambios en sus anotaciones sólo se aplican si se actualiza un campo spec.

Cuando se ejecuta en Red Hat OpenShift, hay anotaciones adicionales que son estándar en la plataforma. Sobrescriba los valores predeterminados donde sea aplicable y añada las etiquetas de la Lista de Red Hat OpenShift que no estén establecidas de forma predeterminada utilizando las instrucciones anteriores.

Establecer variables de entorno para un contenedor de aplicaciones (.spec.env o .spec.envFrom)

Para establecer variables de entorno para el contenedor de aplicaciones, especifique los campos .spec.env o .spec.envFrom en un CR. Las variables de entorno pueden proceder directamente de pares de clave-valor, ConfigMap o Secret. Las variables de entorno establecidas por los campos .spec.env o .spec.envFrom sustituyen las variables de entorno especificadas en la imagen de contenedor.

Utilice .spec.envFrom para definir todos los datos en un ConfigMap o un Secret como variables de entorno en un contenedor. Las claves de los recursos ConfigMap o Secret se convierten en nombres de variables de entorno en el contenedor. El CR siguiente establece pares de clave-valor en los campos .spec.env y .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

Para ver otro ejemplo que utilice .spec.envFrom.secretRef, consulte Utilización de variables de entorno para credenciales de autenticación básica. Para ver un ejemplo que altera temporalmente los valores predeterminados de la variable de entorno de registro de la consola, consulte Alterar temporalmente los valores predeterminados de la variable de entorno de registro de la consola (.spec.env).

Sustituir los valores predeterminados de variable de entorno de registro de consola (.spec.env)

El operador WebSphere Liberty establece variables de entorno relacionadas con el registro de consola de forma predeterminada. Puede sustituir los valores predeterminados de registro de la consola con sus propios valores en la lista de CR .spec.env.

La tabla siguiente lista las variables de entorno del registro de la consola y sus valores predeterminados.

Para sustituir los valores predeterminados para las variables de entorno de registro de la consola, establezca manualmente los valores preferidos en la lista de CR .spec.env. Para obtener información sobre los valores que puede establecer, consulte la Open Liberty documentación sobre registro.

El ejemplo siguiente muestra una lista CR .spec.env que establece valores no predeterminados para las variables de entorno de registro de la consola.

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"

Para obtener más información sobre cómo anular los valores predeterminados de las variables, consulte Establezca variables de entorno para un contenedor de aplicación (. spec.env o .spec.envFrom). Para obtener información sobre la supervisión de aplicaciones y el análisis de registros de aplicaciones, consulte Observación con el operador WebSphere Liberty

Configurar réplicas estáticas para alta disponibilidad (. spec.replicas )

Para ejecutar varias instancias de su aplicación en alta disponibilidad con un número fijo de réplicas, utilice el campo .spec.replicas campo El campo .spec.replicas mantiene un número constante de instancias de aplicación independientemente del consumo de recursos. Esta configuración se ignora cuando el autoescalado se configura utilizando el campo .spec.autoscaling .

Configurar Autoescalado Horizontal de Pods para alta disponibilidad (. spec.autoscaling )

Establecer privilegios y permisos para un pod o contenedor (.spec.securityContext)

Un contexto de seguridad controla los valores de privilegios y permisos para un contenedor de aplicaciones o de pod. De forma predeterminada, el operador establece varios parámetros de .spec.securityContext para un contenedor de aplicaciones tal como se muestra en el ejemplo siguiente.

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

Para alterar temporalmente los valores predeterminados o establecer más parámetros, cambie los parámetros .spec.securityContext , por ejemplo:

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

El operador WebSphere Liberty establece el campo securityContext en el perfil RuntimeDefault seccomp. Si su clúster Kubernetes utiliza restricciones de contexto de seguridad personalizadas, seccompProfiles debe establecerse en runtime/default.

Para utilizar restricciones de contexto de seguridad personalizadas con su clúster Kubernetes, añada la siguiente sección.

seccompProfiles:
  - runtime/default

Si la aplicación requiere que seccomp esté desactivado, el seccompProfile debe establecerse en unconfined tanto en las restricciones de contexto de seguridad como en el WebSphereLibertyApplication CR

seccompProfiles:
  - unconfined

spec:
  securityContext:
    seccompProfile:
      type: Unconfined

Para obtener más información, consulte Establecer el contexto de seguridad para un contenedor.

Persistir recursos (.spec.statefuset y .spec.volumeMounts)

Si se especifica almacenamiento en el CR WebSphereLibertyApplication , el operador puede crear un StatefulSet y un PersistentVolumeClaim para cada pod. Si no se especifica el almacenamiento, se crea el recurso StatefulSet sin almacenamiento persistente.

La siguiente definición de CR utiliza .spec.statefulSet.storage para proporcionar almacenamiento básico. El operador crea un StatefulSet con el tamaño de 1Gi que se monta en la carpeta /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 definición de CR WebSphereLibertyApplication puede proporcionar un almacenamiento más avanzado. Con la siguiente definición de CR, el operador crea un PersistentVolumeClaim llamado pvc con el tamaño de 1Gi y la modalidad de acceso ReadWriteOnce. El operador permite a los usuarios proporcionar todo un .spec.statefulSet.storage.volumeClaimTemplate para un control total del PersistentVolumeClaim creado automáticamente. Para persistir en más de una carpeta, la definición de CR utiliza el campo .spec.volumeMounts en lugar de .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 siguiente definición de CR no especifica almacenamiento y crea recursos de StatefulSet sin almacenamiento persistente. Puede crear recursos de StatefulSet sin almacenamiento si sólo necesita el orden y la exclusividad de un conjunto de pods.

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

Supervisar recursos (.spec.monitoring)

Un operador WebSphere Liberty puede crear un recurso ServiceMonitor para integrarse con el operador Prometheus.

Como mínimo, proporcione una etiqueta para Prometheus establecida en objetos ServiceMonitor. En el ejemplo siguiente, la etiqueta .spec.monitoring es 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

Para una supervisión más avanzada, establezca muchos parámetros de ServicerMonitor como, por ejemplo, el secreto de autenticación con Punto final 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

Especifique varios puertos de servicio (.spec.service.port * y .spec.monitoring.endpoints)

Para proporcionar varios puertos de servicio además del puerto de servicio primario, configure el puerto de servicio primario con los campos .spec.service.port, .spec.service.targetPort, .spec.service.portName y .spec.service.nodePort. El puerto primario se expone desde el contenedor que ejecuta la aplicación y los valores de puerto se utilizan para configurar la ruta (o ingreso), el enlace de servicio y el servicio Knative.

Para especificar un puerto alternativo para el Supervisor de servicio, utilice el campo .spec.monitoring.endpoints y especifique el campo port o targetPort; de lo contrario, el valor predeterminado es el puerto primario.

Especifique el puerto primario con el campo .spec.service.port y los puertos adicionales con el campo .spec.service.ports tal como se muestra en el ejemplo siguiente.

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'

Configurar análisis (.spec.probes)

Los análisis son comprobaciones de estado en un contenedor de aplicaciones para determinar si está activo o preparado para recibir tráfico. El operador WebSphere Liberty tiene los análisis startup, liveness y readiness.

De forma predeterminada, los análisis no están habilitados en las aplicaciones. Para habilitar un analizador con los valores predeterminados, establezca los parámetros del analizador en {}. El ejemplo siguiente permite que los 3 análisis utilicen valores predeterminados.

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

Para sustituir un valor predeterminado, especifique un valor distinto. El ejemplo siguiente sustituye un valor predeterminado de retardo inicial de análisis de actividad de 60 segundos y establece el retardo inicial en 90 segundos.

spec:
  probes:
    liveness:
      initialDelaySeconds: 90

Cuando un parámetro initialDelaySeconds de análisis se establece en 0, se utiliza el valor predeterminado. Para establecer un retardo inicial de sondeo en 0, defina el análisis en lugar de utilizar el análisis predeterminado. El ejemplo siguiente sustituye el valor predeterminado y establece el retardo inicial en 0.

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

Configurar sondas basadas en archivos con mpHealth-4.0 (.spec.probes.enableFileBased )

A partir de la versión Liberty del operador 1.5.2, un nuevo campo booleano, .spec.probes.enableFileBased, permite configurar comprobaciones de estado basadas en archivos mediante la MicroProfile función 4.0 Health.

Las sondas basadas en archivos no están habilitadas de forma predeterminada en las aplicaciones. El Liberty operador utiliza por HTTP defecto sondas GET.

• La Liberty imagen especificada en .spec.applicationImage requiere que mpHealth-4.0 la función esté instalada y habilitada en un servidor Liberty que ejecute la versión 25.0.0.6 o superior.
• Para habilitar una sonda basada en archivos con los valores predeterminados, establezca enableFileBased en true y los parámetros de la sonda en {}. El siguiente ejemplo permite que las tres sondas utilicen valores predeterminados basados en archivos.

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

Las comprobaciones de inicio, actividad y disponibilidad basadas en archivos heredan los mismos valores predeterminados (sin configuración httpGet) que se describen en la sección Configurar comprobaciones (. spec.probes ).

Una vez habilitadas las sondas basadas en archivos, el Liberty operador configura la aplicación para supervisar los archivos dentro del /output/health directorio del contenedor.

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

Cada pocos segundos, un Liberty servidor que utilice la mpHealth-4.0 función puede crear/actualizar los archivos live, ready started y/o con una marca de tiempo recién ajustada para indicar un estado UP. El intervalo en el que Liberty se comprueban estos archivos se puede modificar utilizando los campos .spec.probes.checkInterval .spec.probes.startupCheckInterval y. De forma predeterminada, estos intervalos de comprobación están configurados en 5s y 100ms, respectivamente.

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

Para alinearse con el comportamiento de las sondas no basadas en archivos, configure el Liberty servidor para que compruebe los archivos live, readystarted , o más rápido que el tiempo que tarda en Kubernetes realizar una sola sonda. Por ejemplo, configure un búfer para que los intervalos de comprobación mantengan la propiedad de interval * 1.5 ⇐ periodSeconds. En este caso, las WebSphereLibertyApplication sondas tienen un valor predeterminado periodSeconds de 10, que satisface la restricción con intervalos de comprobación de 5s y 100ms. Si modifica los valores de las periodSecondspropiedades startupCheckInterval , checkInterval, o, mantenga esta restricción para evitar tiempos de inactividad inesperados de los pods.

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

Desplegar aplicaciones sin servidor con Knative (.spec.createKnativeService)

Si Knative está instalado en un clúster de Kubernetes, para desplegar aplicaciones sin servidor con Knative en el clúster, el operador crea un recurso Knative Service que gestiona todo el ciclo de vida de una carga de trabajo. Para crear un servicio Knative, establezca .spec.createKnativeService en true.

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

El operador crea un servicio Knative en el clúster y llena el recurso con los campos WebSphereLibertyApplication aplicables. Además, garantiza que los recursos no Knative como Kubernetes Service, Route y Deployment se suprimen.

Los campos de CRD que pueden llenar el recurso de servicio Knative incluyen .spec.applicationImage, .spec.serviceAccount.name, .spec.probes.liveness, .spec.probes.readiness, .spec.service.Port, .spec.volumes, .spec.volumeMounts, .spec.env, .spec.envFrom, .spec.pullSecret y .spec.pullPolicy. El análisis de inicio no está totalmente soportado por Knative, por lo que .spec.probes.startup no se aplica cuando el servicio Knative está habilitado.

Para obtener detalles sobre cómo configurar Knative para tareas como habilitar conexiones HTTPS y configurar un dominio personalizado, consulte la documentación de Knative.

Los campos de escalado automático en WebSphereLibertyApplication no se utilizan para configurar el escalado automático de pods de Knative (KPA). Para obtener información sobre cómo configurar KPA, consulte Configuración del escalado automático.

Exponer aplicaciones externamente (.spec.expose, .spec.createKnativeService, .spec.route)

Exponer una aplicación externamente con un recurso Route, Knative Route o Ingress.

Para exponer una aplicación externamente con una ruta en un despliegue no Knative, establezca .spec.expose en true.

Cuando .spec.manageTLS está habilitado, el operador crea una ruta segura basada en el servicio de aplicaciones. Para utilizar certificados personalizados, consulte la información sobre .spec.service.certificateSecretRef y .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

Para exponer una aplicación externamente con ingreso en un despliegue no Knative, realice los pasos siguientes.

1. Para utilizar el recurso de entrada para exponer el clúster, instale un controlador de entrada como Nginx o Traefik.
2. Asegúrese de que no haya un recurso Route en el clúster. El recurso de entrada sólo se crea si el recurso Route no está disponible en el clúster.
3. Para utilizar el recurso Ingress, establezca la defaultHostName variable en el objeto ConfigMap Operator en un nombre de host como mycompany.com
4. Habilite TLS. Genere un certificado y especifique el secreto que contiene el certificado con el 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. Especifique .spec.route.annotations para configurar el recurso de entrada. Las anotaciones como Nginx, HAProxy, Traefik y otras son específicas de la implementación del controlador de entrada.

   El ejemplo siguiente especifica anotaciones, un secreto TLS existente y un nombre de host personalizado.

   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

Para exponer una aplicación como un servicio Knative, establezca .spec.createKnativeService y .spec.expose en true. El operador crea una ruta Knative no segura. Para configurar conexiones HTTPS seguras para el despliegue de Knative, consulte Configuración de HTTPS con certificados 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

Permitir o limitar el tráfico entrante (.spec.networkPolicy)

De forma predeterminada, las políticas de red para una aplicación aíslan el tráfico entrante.

• La política de red predeterminada creada para las aplicaciones que no están expuestas limita el tráfico entrante a los pods del mismo espacio de nombres que forman parte de la misma aplicación. El tráfico está limitado a sólo los puertos configurados por el servicio. Por defecto, el tráfico se expondrá a .spec.service.targetPort cuando se especifique y, en caso contrario, se volverá a utilizar .spec.service.port. Utilizando la misma lógica, se expondrá tráfico por cada targetPort o port adicional proporcionado en la matriz .spec.service.ports[].
• Red Hat OpenShift da soporte a políticas de red de forma predeterminada. Para aplicaciones expuestas en Red Hat OpenShift, la política de red permite el tráfico entrante desde el controlador de entrada de Red Hat OpenShift en los puertos de la configuración de servicio. La política de red también permite el tráfico entrante desde la pila de supervisión de Red Hat OpenShift.
• Para aplicaciones expuestas en otras plataformas de Kubernetes, la política de red permite el tráfico entrante de cualquier pod en cualquier espacio de nombres en los puertos de la configuración de servicio. Para implementaciones en otras Kubernetes plataformas, asegúrese de que su complemento de red sea compatible con las políticas Kubernetes de red.

Para inhabilitar la creación de políticas de red para una aplicación, establezca .spec.networkPolicy.disable en true.

spec:
  networkPolicy:
    disable: true

Puede cambiar la política de red para permitir el tráfico entrante desde espacios de nombres o pods específicos. De forma predeterminada, .spec.networkPolicy.namespaceLabels se establece en el mismo espacio de nombres al que se despliega la aplicación y .spec.networkPolicy.fromLabels se establece en los pods que pertenecen a la misma aplicación especificada por .spec.applicationName. El ejemplo siguiente permite el tráfico de entrada procedente de pods etiquetados con el rol frontend y que están en el mismo espacio de nombres.

spec:
  networkPolicy:
    fromLabels:
      role: frontend

El ejemplo siguiente permite el tráfico entrante de los pods que pertenecen a la misma aplicación en el espacio de nombres de example.

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

El ejemplo siguiente permite el tráfico de entrada de los pods etiquetados con el rol frontend en el espacio de nombres example .

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

Enlazar aplicaciones con servicios de respaldo gestionados por el operador (.status.binding.name y .spec.service.bindable)

El Operador de enlace de servicio permite a los desarrolladores de aplicaciones enlazar aplicaciones junto con los servicios de respaldo gestionados por el operador. Si el Operador de enlace de servicio está instalado en el clúster, se pueden enlazar aplicaciones creando un recurso personalizado de ServiceBindingRequest.

Puede configurar una aplicación WebSphere Liberty para que se comporte como un Servicio suministrado definido por la Especificación de enlace de servicio. De acuerdo con la especificación, un recurso de servicio suministrado debe definir un .status.binding.name que haga referencia a un secreto. Para exponer la aplicación como un servicio suministrado, establezca el campo .spec.service.bindable en un valor de true. El operador crea un secreto de enlace que se denomina CR_NAME-expose-binding y añade las entradas host, port, protocol, basePathy uri al secreto.

Para alterar temporalmente los valores predeterminados para las entradas en el secreto de enlace o para añadir nuevas entradas al secreto, cree un secreto de alteración temporal denominado CR_NAME-expose-binding-override y añada las entradas al secreto. El operador lee el contenido del secreto de sustitución y sustituye los valores predeterminados en el secreto de enlace.

Después de que una aplicación WebSphere Liberty se exponga como un servicio suministrado, una solicitud de enlace de servicio puede hacer referencia a la aplicación como un servicio de respaldo.

Las instrucciones siguientes muestran cómo enlazar aplicaciones WebSphere Liberty como servicios o productores a otras cargas de trabajo (por ejemplo, pods o despliegues). Dos aplicaciones WebSphere Liberty que se despliegan a través del operador WebSphere Liberty no se pueden enlazar. Para obtener más información, consulte Problemas y limitaciones conocidos.

• Configure el operador de enlace de servicio para acceder a las aplicaciones de WebSphere Liberty.
  De forma predeterminada, el operador de enlace de servicio no tiene permiso para interactuar con las aplicaciones WebSphere Liberty desplegadas a través del operador WebSphere Liberty . Debe crear dos RoleBindings para proporcionar la vista de operador de enlace de servicio y editar el acceso para las aplicaciones de WebSphere Liberty.

  1. En el Red Hat OpenShift panel de control, vaya a Gestión de usuarios > RoleBindings.
  2. Seleccione Crear enlace.
  3. Establezca Tipo de enlace en Cluster-wide role binding (ClusterRoleBinding).
  4. Especifique un nombre para el enlace. Elija un nombre relacionado con los enlaces de servicio y el acceso de vista para las aplicaciones WebSphere .
  5. Para el nombre de rol, escriba webspherelibertyapplications.liberty.websphere.ibm.com-v1-view.
  6. Establezca Asunto en ServiceAccount.
  7. Aparece un menú Espacio de nombres de asunto. Seleccione openshift-operators.
  8. En el campo Nombre de asunto, escriba service-binding-operator.
  9. Pulse Crear.
  Ahora que ha configurado el primer enlace de rol, vaya a la lista RoleBindings y vuelva a pulsar Crear enlace. Configure el acceso de edición utilizando las instrucciones siguientes.

  1. Establezca Tipo de enlace en Cluster-wide role binding (ClusterRoleBinding).
  2. Especifique un nombre para el enlace. Elija un nombre relacionado con los enlaces de servicio y el acceso de edición para las aplicaciones WebSphere .
  3. En el campo Nombre de rol, escriba webspherelibertyapplications.liberty.websphere.ibm.com-v1-edit.
  4. Establezca Asunto en ServiceAccount.
  5. En la lista Espacio de nombres del asunto, seleccione openshift-operators.
  6. En el campo Nombre del asunto, escriba service-binding-operator.
  7. Pulse Crear.

  Los enlaces de servicio de las aplicaciones WebSphere Liberty (o "servicios") a los pods o despliegues (o "cargas de trabajo") ahora se realizan con éxito. Después de realizar un enlace, la carga de trabajo enlazada se reinicia o escala para montar el secreto de enlace a /bindings en todos los contenedores.

• Configure un enlace de servicio utilizando el método Red Hat.
  Para obtener más información, consulte la documentación de Red Hat o la guía de aprendizaje de Red Hat.

  1. En el panel de control web de Red Hat OpenShift , pulse Administrador en la barra lateral y seleccione Desarrollador.
  2. En la vista Topología para el espacio de nombres actual, pase el puntero del ratón sobre el borde de la aplicación de WebSphere para que se enlace como servicio y arrastre una flecha a la carga de trabajo de pod o de despliegue. Aparece una ayuda contextual titulada Crear enlace de servicio.
  3. Se abre la ventana Crear enlace de servicio. Cambie el nombre por un valor que tenga menos de 63 caracteres. Es posible que el operador de enlace de servicio no pueda montar el secreto como un volumen si el nombre tiene más de 63 caracteres.
  4. Pulse Crear.
  5. Se abre una barra lateral. Para ver el estado del enlace, pulse el nombre del secreto y, a continuación, desplácese hasta que aparezca el estado.
  6. Compruebe la carga de trabajo de pod/despliegue y verifique que se ha montado un volumen. También puede abrir una sesión de terminal en un contenedor y ejecutar ls /bindings.
• Configure un enlace de servicio utilizando el método de comunidad / vista previa técnica de la API de especificación.
  Este método es más reciente que el método Red Hat pero obtiene los mismos resultados. Debe añadir una etiqueta a la aplicación WebSphere Liberty como, por ejemplo, app=frontend, si no tiene ninguna etiqueta exclusiva. Establezca el enlace para utilizar un selector de etiquetas para que el operador de enlace de servicios busque una aplicación WebSphere Liberty con una etiqueta específica.

  1. Instale el operador de enlace de servicio utilizando el catálogo de operadores de Red Hat OpenShift.
  2. Seleccione Operadores > Operadores instalados y establezca el espacio de nombres en el mismo que utilizan tanto su WebSphere aplicación como la carga de trabajo del pod/implementación.
  3. Abra la página Enlace de servicio (Vista previa técnica de API de especificación).
  4. Pulse Crear ServiceBinding.
  5. Elija un nombre abreviado para el enlace. Los nombres que tengan más de 63 caracteres pueden causar que el montaje de volumen secreto de enlace falle.
  6. Expanda la sección Servicio.
  7. En el campo Versión de API, escriba liberty.websphere.ibm.com/v1.
  8. En el campo Tipo, escriba WebSphereLibertyApplication.
  9. En el campo Nombre, especifique el nombre de la aplicación. Puede obtener este nombre de la lista de aplicaciones en la página del operador WebSphere Liberty.
  10. Expanda la sección Carga de trabajo.
  11. Establezca el campo Versión de API en el valor de apiVersion en el YAML de carga de trabajo de destino. Por ejemplo, si la carga de trabajo es un despliegue, el valor es apps/v1.
  12. Establezca el campo Tipo en el valor de kind en el YAML de carga de trabajo de destino. Por ejemplo, si la carga de trabajo es un despliegue, el valor es Deployment.
  13. Expanda la subsección Selector y, a continuación, expanda la subsección Expresiones de coincidencia.
  14. Pulse Añadir expresión de coincidencia.
  15. En el campo Clave, especifique la clave de etiqueta que ha establecido anteriormente. Por ejemplo, para la etiqueta app=frontend, la clave es app).
  16. En el campo Operador, escriba Exists.
  17. Expanda la subsección Valores y pulse Añadir valor.
  18. En el campo Valor, especifique el valor de etiqueta que ha establecido anteriormente. Por ejemplo, si utiliza la etiqueta app=frontend, el valor es frontend.
  19. Pulse Crear.
  20. Compruebe la carga de trabajo de Pod/Deployment y verifique que se ha montado un volumen, desplazándose hacia abajo o abriendo una sesión de terminal en un contenedor y ejecutando ls /bindings.

Limitar un pod para que se ejecute en nodos especificados (.spec.affinity)

Utilice .spec.affinity para restringir un pod para que se ejecute sólo en los nodos especificados.

Para establecer las etiquetas necesarias para la planificación de pods en nodos específicos, utilice el 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

El ejemplo siguiente requiere un tipo de nodo large y preferencias para dos zonas, que se denominan zoneA y 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

Utilice la afinidad y la antiafinidad de pod para restringir los nodos que el pod puede seleccionar para planificar según las etiquetas de los pods que ya se están ejecutando en el nodo en lugar de basarse en etiquetas en el nodo.

El ejemplo siguiente muestra que la afinidad de pod es necesaria y que los pods para Service-A y Service-B deben estar en la misma zona. Mediante la antiafinidad de pod, es preferible no planificar Service_B y Service_C en el mismo 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

Restringir cómo se distribuyen los pods entre nodos y zonas (.spec.topologySpreadConstraints )

Utilice el objeto YAML .spec.topologySpreadConstraints para especificar las restricciones sobre cómo se distribuyen los pods de la instancia de aplicación (y si está habilitada, la instancia de Semeru Cloud Compiler) entre los nodos y zonas del clúster.

En el .spec.topologySpreadConstraints.constraints campo puede especificar una lista de Pod TopologySpreadConstraints que se añadirán, como en el siguiente ejemplo:

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

Por defecto, el operador añadirá las siguientes restricciones de propagación de topología de pods a los pods de la instancia de aplicación (y, si procede, a los pods de la instancia de Semeru Cloud Compiler). El comportamiento por defecto es restringir la propagación de pods que son propiedad de la misma instancia de aplicación (o instancia de generación de Semeru Cloud Compiler), denotada por <instance name> con un maxSkew de 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>

Para eliminar las restricciones de dispersión topológica por defecto del operador, establezca el indicador .spec.topologySpreadConstraints.disableOperatorDefaults en true.

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

Alternativamente, anule cada restricción manualmente creando una nueva TopologySpreadConstraint bajo.spec.topologySpreadConstraints.constraints para cadatopologyKey deseas modificar.

Configurar DNS (.spec.dns.policy y .spec.dns.config)

DNS se puede configurar en WebSphereLibertyApplication CR utilizando el campo .spec.dns.policy o el campo .spec.dns.config. El campo .spec.dns.policy es la política DNS para el pod de aplicación y por defecto es la política ClusterFirst. El campo .spec.dns.config es la configuración DNS para el pod de aplicación.

DNS Config permite a los usuarios un mayor control sobre la configuración DNS de una aplicación Pod.

El campo .spec.dns.config es opcional y puede funcionar con cualquier configuración .spec.dns.policy. Sin embargo, cuando un .spec.dns.policy se establece en None, debe especificarse el campo .spec.dns.config.

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

Para obtener más información sobre DNS, consulte la Kubernetes documentación de DNS.

Configurar tolerancias (.spec.tolerations)

La afinidad de nodos es una propiedad que atrae a los pods hacia un conjunto de nodos, ya sea como preferencia o como requisito estricto. Sin embargo, las manchas permiten a un nodo repeler un conjunto de vainas.

Las tolerancias se aplican a los pods y permiten a un programador programar pods con manchas coincidentes. El programador también evalúa otros parámetros como parte de su función.

Los taints y las tolerancias trabajan conjuntamente para ayudar a garantizar que los pods de aplicaciones no se programen en nodos inadecuados. Si se aplican una o varias contaminaciones a un nodo, éste no podrá aceptar ningún pod que no tolere las contaminaciones.

Las tolerancias pueden configurarse en WebSphereLibertyApplication CR utilizando el campo .spec.tolerations.

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

Para obtener más información sobre contaminaciones y tolerancia, consulte la documentación Kubernetes sobre contaminaciones y tolerancia.