Le réseautage

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

   Copy to Clipboard Toggle word wrap

2. Actualisez l’IngressController CR pour faire référence au nouveau secret de certificat:

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

   Copy to Clipboard Toggle word wrap

3. La mise à jour a été efficace:

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

   Copy to Clipboard Toggle word wrap

   là où:

   <domaine>

   Indique le nom de domaine de base de 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

   Copy to Clipboard Toggle word wrap

   Astuce

   Alternativement, vous pouvez appliquer le 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

   Copy to Clipboard Toggle word wrap

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

Procédure

1. Créez un compte de service à authentifier avec Thanos en exécutant la commande suivante:

   $ oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos

   Copy to Clipboard Toggle word wrap

   Exemple de sortie

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

   Copy to Clipboard Toggle word wrap

2. Créez manuellement le jeton secret de compte de service avec la commande suivante:

   $ oc apply -f - <<EOF
   apiVersion: v1
   kind: Secret
   metadata:
     name: thanos-token
     namespace: openshift-ingress-operator
     annotations:
       kubernetes.io/service-account.name: thanos
   type: kubernetes.io/service-account-token
   EOF

   Copy to Clipboard Toggle word wrap

3. Définissez un objet TriggerAuthentication dans l’espace de noms openshift-ingress-operator en utilisant le jeton du compte de service.

   1. Créez l’objet TriggerAuthentication et passez la valeur de la variable secrète au paramètre TOKEN:

      $ oc apply -f - <<EOF
      apiVersion: keda.sh/v1alpha1
      kind: TriggerAuthentication
      metadata:
        name: keda-trigger-auth-prometheus
        namespace: openshift-ingress-operator
      spec:
        secretTargetRef:
        - parameter: bearerToken
          name: thanos-token
          key: token
        - parameter: ca
          name: thanos-token
          key: ca.crt
      EOF

      Copy to Clipboard Toggle word wrap

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

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

      à propos de Thanos-metrics-reader.yaml

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

      Copy to Clipboard Toggle word wrap

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

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

      Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap
   Note

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

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

   Exemple ScaledObject Définition

   apiVersion: keda.sh/v1alpha1
   kind: ScaledObject
   metadata:
     name: ingress-scaler
     namespace: openshift-ingress-operator
   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://thanos-querier.openshift-monitoring.svc.cluster.local: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

   Copy to Clipboard Toggle word wrap

   1

   La ressource personnalisée que vous ciblez. Dans ce cas, le contrôleur Ingress.

   2

   Facultatif: Le nombre maximum de répliques. En cas d’omission de ce champ, le maximum par défaut est défini à 100 répliques.

   3

   Le point d’extrémité du service Thanos dans l’espace de noms de surveillance openshift.

   4

   L’espace de noms Ingress Operator.

   5

   Cette expression évalue cependant de nombreux nœuds de travail sont présents dans le cluster déployé.

   Important

   Lorsque vous utilisez des requêtes cross-namespace, vous devez cibler le port 9091 et non le port 9092 dans le champ serverAddress. Il faut aussi avoir des privilèges élevés pour lire les métriques à partir de ce port.

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

   $ oc apply -f ingress-autoscaler.yaml

   Copy to Clipboard Toggle word wrap

Procédure

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

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

   Copy to Clipboard Toggle word wrap

   Exemple de sortie

   2

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   Exemple de sortie

   ingresscontroller.operator.openshift.io/default patched

   Copy to Clipboard Toggle word wrap

3. Assurez-vous que l’IngreressController par défaut a mis à l’échelle le nombre de répliques que vous avez spécifiées:

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

   Copy to Clipboard Toggle word wrap

   Exemple de sortie

   3

   Copy to Clipboard Toggle word wrap

   Astuce

   Alternativement, vous pouvez appliquer le YAML suivant pour mettre à l’échelle un contrôleur Ingress en trois répliques:

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

   1

   Copy to Clipboard Toggle word wrap

   1

   Lorsque vous avez besoin d’une quantité différente de répliques, modifiez la valeur des répliques.

Procédure

1. Créez une ressource personnalisée IngressController (CR) 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

   Copy to Clipboard Toggle word wrap

   1

   <name> par un nom pour l’objet IngressController.

   2

   Indiquez le domaine de l’application publié par le responsable du traitement.

   3

   Indiquez une valeur d’Interne pour utiliser un équilibreur de charge interne.

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

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

   1

   Copy to Clipboard Toggle word wrap

   1

   <name> par le nom de l’objet IngressController.

3. Facultatif: Confirmer que le contrôleur Ingress a été créé en exécutant la commande suivante:

   $ oc --all-namespaces=true get ingresscontrollers

   Copy to Clipboard Toggle word wrap

Procédure

1. Configurez le contrôleur Ingress par défaut pour que votre cluster 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

   Copy to Clipboard Toggle word wrap

Procédure

1. Configurez la stratégie de wildcard.

   1. À l’aide de la commande suivante pour modifier la ressource IngressController:

      $ oc edit IngressController

      Copy to Clipboard Toggle word wrap

   2. Dans la section Spécification, définissez le champ wildcardPolicy sur WildcardsDisallowed ou WildcardsAllowed:

      spec:
        routeAdmission:
          wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed

      Copy to Clipboard Toggle word wrap

Procédure

1. Éditer la ressource Ingress Controller:

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

   Copy to Clipboard Toggle word wrap

2. De remplacer l’en-tête de requête HTTP X-SSL-Client-Der par l’en-tête de requête HTTP X-Forwarded-Client-Cert:

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

   1

   
         request: 

   2

   
         - name: X-Forwarded-Client-Cert 

   3

   
           action:
             type: Set 

   4

   
             set:
              value: "%{+Q}[ssl_c_der,base64]" 

   5

   
         - name: X-SSL-Client-Der
           action:
             type: Delete

   Copy to Clipboard Toggle word wrap

   1

   La liste des actions que vous souhaitez effectuer sur les en-têtes HTTP.

   2

   Le type d’en-tête que vous voulez changer. Dans ce cas, un en-tête de demande.

   3

   Le nom de l’en-tête que vous voulez changer. Dans le cas d’une liste d’en-têtes disponibles que vous pouvez définir ou supprimer, voir la configuration d’en-tête HTTP.

   4

   Le type d’action en cours sur l’en-tête. Ce champ peut avoir la valeur Set ou Supprimer.

   5

   Lorsque vous définissez des en-têtes HTTP, vous devez fournir une valeur. La valeur peut être une chaîne à partir d’une liste de directives disponibles pour cet en-tête, par exemple DENY, ou il peut s’agir d’une valeur dynamique qui sera interprétée à l’aide de la syntaxe de valeur dynamique de HAProxy. Dans ce cas, une valeur dynamique est ajoutée.

   Note

   Les valeurs d’en-tête dynamiques pour les réponses HTTP sont ré.hdr et ssl_c_der. Les valeurs d’en-tête dynamiques pour les requêtes HTTP sont req.hdr et ssl_c_der. Les valeurs dynamiques de requête et de réponse peuvent utiliser les convertisseurs inférieur et base64.

3. Enregistrez le fichier pour appliquer les modifications.

Procédure

1. Configurez le champ HTTPHeaders pour le contrôleur Ingress.

   1. À l’aide de la commande suivante pour modifier la ressource IngressController:

      $ oc edit IngressController

      Copy to Clipboard Toggle word wrap

   2. Dans la section Spécification, définissez le champ de stratégie HTTPHeaders pour ajouter, remplacer, IfNone ou jamais:

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

      Copy to Clipboard Toggle word wrap

Procédure

1. Modifiez la ressource Ingress Controller en entrant la commande suivante dans votre CLI:

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

   Copy to Clipboard Toggle word wrap

2. Définir la configuration PROXY:

   • Lorsque votre contrôleur Ingress utilise le type de stratégie de publication du point de terminaison HostNetwork, définissez le sous-champ spec.endpointPublishingStrategy.hostNetwork.protocol sur PROXY:

     Exemple de configuration hostNetwork à PROXY

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

     Copy to Clipboard Toggle word wrap

   • Lorsque votre contrôleur Ingress utilise le type de stratégie de publication NodePortService, définissez le sous-champ spec.endpointPublishingStrategy.nodePort.protocol sur PROXY:

     Exemple de configuration nodePort à PROXY

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

     Copy to Clipboard Toggle word wrap

   • Dans le cas où votre contrôleur Ingress utilise le type de stratégie de publication de points de terminaison privés, définissez le sous-champ spec.endpointPublishingStrategy.priv.protocol sur PROXY:

     Exemple de configuration privée à PROXY

     # ...
       spec:
         endpointPublishingStrategy:
           private:
             protocol: PROXY
         type: Private
     # ...

     Copy to Clipboard Toggle word wrap

Procédure

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

   1. Éditer la ressource du cluster d’entrée:

      $ oc edit ingresses.config/cluster -o yaml

      Copy to Clipboard Toggle word wrap

   2. Éditer le fichier YAML:

      Exemple d’applicationsConfiguration de la main pour tester.example.com

      apiVersion: config.openshift.io/v1
      kind: Ingress
      metadata:
        name: cluster
      spec:
        domain: apps.example.com            

      1

      
        appsDomain: <test.example.com>      

      2

      Copy to Clipboard Toggle word wrap

      1

      Indique le domaine par défaut. Après l’installation, vous ne pouvez pas modifier le domaine par défaut.

      2

      En option: Domaine pour Red Hat OpenShift Service sur l’infrastructure AWS à utiliser pour les routes d’application. Au lieu du préfixe par défaut, les applications, vous pouvez utiliser un préfixe alternatif comme le test.

2. Assurez-vous qu’une route existante contient le nom de domaine spécifié dans le champ appsDomain en exposant l’itinéraire et en vérifiant le changement de domaine d’itinéraire:

   Note

   Attendez que l’apiserver ouvert termine les mises à jour de roulement avant d’exposer l’itinéraire.

   1. Exposer l’itinéraire:

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

      Copy to Clipboard Toggle word wrap

      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

      Copy to Clipboard Toggle word wrap

Procédure

1. Configurez le champ httpCompression pour le contrôleur Ingress.

   1. À l’aide de la commande suivante pour modifier la ressource IngressController:

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

      Copy to Clipboard Toggle word wrap

   2. Dans spec, définissez le champ de stratégie httpCompression sur mimeTypes et spécifiez une liste de types MIME qui devraient avoir une compression 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"
         ...

      Copy to Clipboard Toggle word wrap

Procédure

1. Obtenez le nom de la pod de routeur en exécutant la commande suivante:

   $ oc get pods -n openshift-ingress

   Copy to Clipboard Toggle word wrap

   Exemple de sortie

   NAME                              READY   STATUS    RESTARTS   AGE
   router-default-76bfffb66c-46qwp   1/1     Running   0          11h

   Copy to Clipboard Toggle word wrap

2. Accédez au nom d’utilisateur et au mot de passe du routeur, que le routeur stocke dans les fichiers /var/lib/haproxy/conf/metrics-auth/statsUsername et /var/lib/haproxy/conf/metrics-auth/statsword:

   1. Obtenez le nom d’utilisateur en exécutant la commande suivante:

      $ oc rsh <router_pod_name> cat metrics-auth/statsUsername

      Copy to Clipboard Toggle word wrap

   2. Accédez au mot de passe en exécutant la commande suivante:

      $ oc rsh <router_pod_name> cat metrics-auth/statsPassword

      Copy to Clipboard Toggle word wrap

3. Obtenez les certificats IP et métriques du routeur en exécutant la commande suivante:

   $ oc describe pod <router_pod>

   Copy to Clipboard Toggle word wrap

4. Bénéficiez des statistiques brutes au format Prometheus en exécutant la commande suivante:

   $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics

   Copy to Clipboard Toggle word wrap

5. Accédez aux métriques en toute sécurité en exécutant la commande suivante:

   $ curl -u user:password https://<router_IP>:<stats_port>/metrics -k

   Copy to Clipboard Toggle word wrap

6. Accédez au port de statistiques par défaut, 1936, en exécutant la commande suivante:

   $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics

   Copy to Clipboard Toggle word wrap

   Exemple 2.1. Exemple de sortie

   ...
   # HELP haproxy_backend_connections_total Total number of connections.
   # TYPE haproxy_backend_connections_total gauge
   haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0
   haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0
   haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0
   ...
   # HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value.
   # TYPE haproxy_exporter_server_threshold gauge
   haproxy_exporter_server_threshold{type="current"} 11
   haproxy_exporter_server_threshold{type="limit"} 500
   ...
   # HELP haproxy_frontend_bytes_in_total Current total of incoming bytes.
   # TYPE haproxy_frontend_bytes_in_total gauge
   haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0
   haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0
   haproxy_frontend_bytes_in_total{frontend="public"} 119070
   ...
   # HELP haproxy_server_bytes_in_total Current total of incoming bytes.
   # TYPE haproxy_server_bytes_in_total gauge
   haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0
   haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0
   haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0
   haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0
   ...

   Copy to Clipboard Toggle word wrap

7. Lancez la fenêtre de statistiques en entrant l’URL suivante dans un navigateur:

   http://<user>:<password>@<router_IP>:<stats_port>

   Copy to Clipboard Toggle word wrap

8. Facultatif: Obtenez les statistiques au format CSV en entrant l’URL suivante dans un navigateur:

   http://<user>:<password>@<router_ip>:1936/metrics;csv

   Copy to Clipboard Toggle word wrap

Procédure

1. Créer 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

   Copy to Clipboard Toggle word wrap
   Important

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

2. Corrigez le contrôleur Ingress pour référencer les pages de code my-custom-error-config map par nom:

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

   Copy to Clipboard Toggle word wrap

   L’opérateur Ingress copie la carte my-custom-error-code-pages de configuration de l’espace de noms openshift-config vers l’espace de noms openshift-ingress. L’opérateur nomme la carte de configuration en fonction du 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

   Copy to Clipboard Toggle word wrap

   Exemple de sortie

   NAME                       DATA   AGE
   default-errorpages         2      25s  

   1

   Copy to Clipboard Toggle word wrap

   1

   L’exemple de nom de la carte de configuration est des pages d’erreur par défaut parce que la ressource personnalisée (CR) par défaut du contrôleur Ingress a été corrigée.

4. Confirmez que la carte de configuration contenant la page de réponse d’erreur personnalisée monte sur le volume du routeur où la clé map de configuration est le nom de fichier qui a la réponse de code d’erreur HTTP personnalisée:

   • 503 réponse de code d’erreur personnalisée HTTP personnalisée:

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

     Copy to Clipboard Toggle word wrap

   • 404 réponse de code d’erreur personnalisée HTTP personnalisée:

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

     Copy to Clipboard Toggle word wrap