7.8. Configuration du contrôleur d'entrée

1. Créez une ressource Secret contenant le certificat personnalisé dans l'espace de noms openshift-ingress à l'aide des fichiers tls.crt et tls.key.

   $ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key

2. Mettre à jour la CR du contrôleur d'ingestion pour qu'elle fasse référence au nouveau secret du certificat :

   $ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
     --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'

3. Vérifier que la mise à jour a été effective :

   $ echo Q |\
     openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
     openssl x509 -noout -subject -issuer -enddate

   où :

   <domain>

   Spécifie le nom de domaine de base pour votre cluster.

   Exemple de sortie

   subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
   issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
   notAfter=May 10 08:32:45 2022 GM

   Astuce

   Vous pouvez également appliquer le code YAML suivant pour définir un certificat par défaut personnalisé :

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     defaultCertificate:
       name: custom-certs-default

   Le nom du secret du certificat doit correspondre à la valeur utilisée pour mettre à jour le CR.

Conditions préalables

1. Vous avez installé l'OpenShift CLI (oc).
2. Vous avez accès à un cluster OpenShift Container Platform en tant qu'utilisateur ayant le rôle cluster-admin.
3. L'opérateur Custom Metrics Autoscaler est installé.

Procédure

1. Créez un projet dans l'espace de noms openshift-ingress-operator en exécutant la commande suivante :

   $ oc project openshift-ingress-operator

2. Activer la surveillance d'OpenShift pour des projets définis par l'utilisateur en créant et en appliquant une carte de configuration :

   1. Créez un nouvel objet ConfigMap, cluster-monitoring-config.yaml:

      cluster-monitoring-config.yaml

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
          enableUserWorkload: true 1

      1

      Lorsqu'il est défini sur true, le paramètre enableUserWorkload permet la surveillance de projets définis par l'utilisateur dans un cluster.

   2. Appliquez la carte de configuration en exécutant la commande suivante :

      $ oc apply -f cluster-monitoring-config.yaml

3. Créez un compte de service pour vous authentifier auprès de Thanos en exécutant la commande suivante :

   $ oc create serviceaccount thanos && oc describe serviceaccount thanos

   Exemple de sortie

   Name:                thanos
   Namespace:           openshift-ingress-operator
   Labels:              <none>
   Annotations:         <none>
   Image pull secrets:  thanos-dockercfg-b4l9s
   Mountable secrets:   thanos-dockercfg-b4l9s
   Tokens:              thanos-token-c422q
   Events:              <none>

4. Définir un objet TriggerAuthentication dans l'espace de noms openshift-ingress-operator en utilisant le jeton du compte de service.

   1. Définissez la variable secret qui contient le secret en exécutant la commande suivante :

      $ secret=$(oc get secret | grep thanos-token | head -n 1 | awk '{ print $1 }')

   2. Créez l'objet TriggerAuthentication et transmettez la valeur de la variable secret au paramètre TOKEN:

      $ oc process TOKEN="$secret" -f - <<EOF | oc apply -f -
      apiVersion: template.openshift.io/v1
      kind: Template
      parameters:
      - name: TOKEN
      objects:
      - apiVersion: keda.sh/v1alpha1
        kind: TriggerAuthentication
        metadata:
          name: keda-trigger-auth-prometheus
        spec:
          secretTargetRef:
          - parameter: bearerToken
            name: \${TOKEN}
            key: token
          - parameter: ca
            name: \${TOKEN}
            key: ca.crt
      EOF

5. Créer et appliquer un rôle pour la lecture des métriques de Thanos :

   1. Créez un nouveau rôle, thanos-metrics-reader.yaml, qui lit les métriques des pods et des nœuds :

      thanos-metrics-reader.yaml

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: thanos-metrics-reader
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        - nodes
        verbs:
        - get
      - apiGroups:
        - metrics.k8s.io
        resources:
        - pods
        - nodes
        verbs:
        - get
        - list
        - watch
      - apiGroups:
        - ""
        resources:
        - namespaces
        verbs:
        - get

   2. Appliquez le nouveau rôle en exécutant la commande suivante :

      $ oc apply -f thanos-metrics-reader.yaml

6. Ajoutez le nouveau rôle au compte de service en entrant les commandes suivantes :

   $ oc adm policy add-role-to-user thanos-metrics-reader -z thanos --role=namespace=openshift-ingress-operator

   $ oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos

   Note

   L'argument add-cluster-role-to-user n'est requis que si vous utilisez des requêtes inter-espaces de noms. L'étape suivante utilise une requête de l'espace de noms kube-metrics qui nécessite cet argument.

7. Créez un nouveau fichier YAML ScaledObject, ingress-autoscaler.yaml, qui cible le déploiement du contrôleur d'ingestion par défaut :

   Exemple ScaledObject définition

   apiVersion: keda.sh/v1alpha1
   kind: ScaledObject
   metadata:
     name: ingress-scaler
   spec:
     scaleTargetRef: 1
       apiVersion: operator.openshift.io/v1
       kind: IngressController
       name: default
       envSourceContainerName: ingress-operator
     minReplicaCount: 1
     maxReplicaCount: 20 2
     cooldownPeriod: 1
     pollingInterval: 1
     triggers:
     - type: prometheus
       metricType: AverageValue
       metadata:
         serverAddress: https://<example-cluster>:9091 3
         namespace: openshift-ingress-operator 4
         metricName: 'kube-node-role'
         threshold: '1'
         query: 'sum(kube_node_role{role="worker",service="kube-state-metrics"})' 5
         authModes: "bearer"
       authenticationRef:
         name: keda-trigger-auth-prometheus

   1

   La ressource personnalisée que vous ciblez. Dans ce cas, il s'agit du contrôleur Ingress.

   2

   Facultatif : Le nombre maximal de répliques. Si vous omettez ce champ, le maximum par défaut est fixé à 100 répliques.

   3

   L'adresse et le port du cluster.

   4

   L'espace de noms de l'opérateur d'entrée.

   5

   Cette expression correspond au nombre de nœuds de travail présents dans la grappe déployée.

   Important

   Si vous utilisez des requêtes inter-espace, vous devez cibler le port 9091 et non le port 9092 dans le champ serverAddress. Vous devez également disposer de privilèges élevés pour lire les métriques à partir de ce port.

8. Appliquez la définition de ressource personnalisée en exécutant la commande suivante :

   $ oc apply -f ingress-autoscaler.yaml

Procédure

1. Affichez le nombre actuel de répliques disponibles pour le site par défaut IngressController:

   $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

   Exemple de sortie

   2

2. Adaptez la version par défaut IngressController au nombre de répliques souhaité à l'aide de la commande oc patch. L'exemple suivant met à l'échelle le serveur par défaut IngressController avec 3 réplicas :

   $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge

   Exemple de sortie

   ingresscontroller.operator.openshift.io/default patched

3. Vérifiez que la valeur par défaut de IngressController est adaptée au nombre de répliques que vous avez spécifié :

   $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

   Exemple de sortie

   3

   Astuce

   Vous pouvez également appliquer le fichier YAML suivant pour adapter un contrôleur d'ingestion à trois répliques :

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     replicas: 3               1

   1

   Si vous avez besoin d'un nombre différent de répliques, modifiez la valeur de replicas.

Procédure

1. Créez une ressource personnalisée (CR) IngressController dans un fichier nommé <name>-ingress-controller.yaml, comme dans l'exemple suivant :

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     namespace: openshift-ingress-operator
     name: <name> 1
   spec:
     domain: <domain> 2
     endpointPublishingStrategy:
       type: LoadBalancerService
       loadBalancer:
         scope: Internal 3

   1

   Remplacer <name> par un nom pour l'objet IngressController.

   2

   Spécifiez le site domain pour l'application publiée par le contrôleur.

   3

   Spécifiez une valeur de Internal pour utiliser un équilibreur de charge interne.

2. Créez le contrôleur d'entrée défini à l'étape précédente en exécutant la commande suivante :

   oc create -f <name>-ingress-controller.yaml 1

   1

   Remplacez <name> par le nom de l'objet IngressController.

3. Facultatif : Confirmez que le contrôleur d'entrée a été créé en exécutant la commande suivante :

   $ oc --all-namespaces=true get ingresscontrollers

Procédure

1. Configurez la ressource Ingress Controller pour autoriser l'accès global.

   Note

   Vous pouvez également créer un contrôleur d'entrée et spécifier l'option d'accès global.

   1. Configurer la ressource Ingress Controller :

      $ oc -n openshift-ingress-operator edit ingresscontroller/default

   2. Modifiez le fichier YAML :

      Sample clientAccess configuration to Global

        spec:
          endpointPublishingStrategy:
            loadBalancer:
              providerParameters:
                gcp:
                  clientAccess: Global 1
                type: GCP
              scope: Internal
            type: LoadBalancerService

      1

      Set gcp.clientAccess to Global.

   3. Enregistrez le fichier pour appliquer les modifications.

2. Exécutez la commande suivante pour vérifier que le service autorise l'accès global :

   $ oc -n openshift-ingress edit svc/router-default -o yaml

   La sortie montre que l'accès global est activé pour GCP avec l'annotation networking.gke.io/internal-load-balancer-allow-global-access.

Procédure

1. Configurez le contrôleur d'entrée default de votre cluster pour qu'il soit interne en le supprimant et en le recréant.

   $ oc replace --force --wait --filename - <<EOF
   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     namespace: openshift-ingress-operator
     name: default
   spec:
     endpointPublishingStrategy:
       type: LoadBalancerService
       loadBalancer:
         scope: Internal
   EOF

Procédure

1. Configurer la politique des caractères génériques.

   1. Utilisez la commande suivante pour modifier la ressource IngressController:

      $ oc edit IngressController

   2. Sous spec, définissez le champ wildcardPolicy comme WildcardsDisallowed ou WildcardsAllowed:

      spec:
        routeAdmission:
          wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed

Procédure

1. Configurez le champ HTTPHeaders pour le contrôleur d'entrée.

   1. Utilisez la commande suivante pour modifier la ressource IngressController:

      $ oc edit IngressController

   2. Sous spec, définissez le champ de politique HTTPHeaders sur Append, Replace, IfNone ou Never:

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          forwardedHeaderPolicy: Append

Procédure

1. Modifiez la ressource Ingress Controller :

   $ oc -n openshift-ingress-operator edit ingresscontroller/default

2. Définir la configuration PROXY :

   • Si votre contrôleur d'entrée utilise le type de stratégie de publication des points d'extrémité hostNetwork, définissez le sous-champ spec.endpointPublishingStrategy.hostNetwork.protocol sur PROXY:

     Exemple de configuration de hostNetwork pour PROXY

       spec:
         endpointPublishingStrategy:
           hostNetwork:
             protocol: PROXY
           type: HostNetwork

   • Si votre contrôleur d'entrée utilise le type de stratégie de publication des points d'extrémité NodePortService, attribuez la valeur PROXY au sous-champ spec.endpointPublishingStrategy.nodePort.protocol:

     Exemple de configuration de nodePort pour PROXY

       spec:
         endpointPublishingStrategy:
           nodePort:
             protocol: PROXY
           type: NodePortService

Procédure

1. Configurez le champ appsDomain en spécifiant un autre domaine par défaut pour les itinéraires créés par l'utilisateur.

   1. Modifiez la ressource ingress cluster:

      $ oc edit ingresses.config/cluster -o yaml

   2. Modifiez le fichier YAML :

      Exemple de configuration de appsDomain pour test.example.com

      apiVersion: config.openshift.io/v1
      kind: Ingress
      metadata:
        name: cluster
      spec:
        domain: apps.example.com            1
        appsDomain: <test.example.com>      2

      1

      Spécifie le domaine par défaut. Vous ne pouvez pas modifier le domaine par défaut après l'installation.

      2

      Facultatif : Domaine de l'infrastructure OpenShift Container Platform à utiliser pour les routes d'application. Au lieu du préfixe par défaut, apps, vous pouvez utiliser un autre préfixe comme test.

2. Vérifiez qu'un itinéraire existant contient le nom de domaine spécifié dans le champ appsDomain en exposant l'itinéraire et en vérifiant le changement de domaine de l'itinéraire :

   Note

   Attendez que le site openshift-apiserver finisse de diffuser les mises à jour avant d'exposer l'itinéraire.

   1. Exposer l'itinéraire :

      $ oc expose service hello-openshift
      route.route.openshift.io/hello-openshift exposed

      Exemple de sortie :

      $ oc get routes
      NAME              HOST/PORT                                   PATH   SERVICES          PORT       TERMINATION   WILDCARD
      hello-openshift   hello_openshift-<my_project>.test.example.com
      hello-openshift   8080-tcp                 None

Procédure

1. Configurez le champ httpCompression pour le contrôleur d'entrée.

   1. Utilisez la commande suivante pour modifier la ressource IngressController:

      $ oc edit -n openshift-ingress-operator ingresscontrollers/default

   2. Sous spec, définissez le champ de politique httpCompression sur mimeTypes et indiquez une liste de types MIME pour lesquels la compression doit être appliquée :

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpCompression:
          mimeTypes:
          - "text/html"
          - "text/css; charset=utf-8"
          - "application/json"
         ...

Procédure

1. Créez une carte de configuration nommée my-custom-error-code-pages dans l'espace de noms openshift-config:

   $ oc -n openshift-config create configmap my-custom-error-code-pages \
   --from-file=error-page-503.http \
   --from-file=error-page-404.http

   Important

   Si vous ne spécifiez pas le format correct pour la page de réponse du code d'erreur personnalisé, une panne du module de routeur se produit. Pour résoudre cette panne, vous devez supprimer ou corriger la carte de configuration et supprimer les router pods concernés afin qu'ils puissent être recréés avec les informations correctes.

2. Patch du contrôleur d'entrée pour référencer la carte de configuration my-custom-error-code-pages par son nom :

   $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge

   L'opérateur d'entrée copie la carte de configuration my-custom-error-code-pages de l'espace de noms openshift-config vers l'espace de noms openshift-ingress. L'opérateur nomme la carte de configuration selon le modèle <your_ingresscontroller_name>-errorpages, dans l'espace de noms openshift-ingress.

3. Afficher la copie :

   $ oc get cm default-errorpages -n openshift-ingress

   Exemple de sortie

   NAME                       DATA   AGE
   default-errorpages         2      25s  1

   1

   L'exemple de nom de carte de configuration est default-errorpages car la ressource personnalisée (CR) du contrôleur d'entrée default a été corrigée.

4. Confirmez que la carte de configuration contenant la page de réponse d'erreur personnalisée est montée sur le volume du routeur, la clé de la carte de configuration étant le nom du fichier contenant la réponse du code d'erreur HTTP personnalisé :

   • Pour la réponse au code d'erreur personnalisé HTTP 503 :

     oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http

   • Pour la réponse au code d'erreur HTTP personnalisé 404 :

     oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http

1. Créez un projet et une application de test :

    $ oc new-project test-ingress

   $ oc new-app django-psql-example

2. Pour la réponse au code d'erreur http personnalisé 503 :

   1. Arrêter tous les pods pour l'application.

   2. Exécutez la commande curl suivante ou visitez le nom d'hôte de la route dans le navigateur :

      $ curl -vk <route_hostname>

3. Pour la réponse au code d'erreur http personnalisé 404 :

   1. Visiter un itinéraire inexistant ou un itinéraire incorrect.

   2. Exécutez la commande curl suivante ou visitez le nom d'hôte de la route dans le navigateur :

      $ curl -vk <route_hostname>

4. Vérifier que l'attribut errorfile figure bien dans le fichier haproxy.config:

   oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile