Procédure

1. Créez un groupe de sécurité qui autorise l'accès SSH au nuage privé virtuel (VPC) créé par la commande openshift-install.
2. Créez une instance Amazon EC2 sur l'un des sous-réseaux publics créés par le programme d'installation.

3. Associez une adresse IP publique à l'instance Amazon EC2 que vous avez créée.

   Contrairement à l'installation d'OpenShift Container Platform, vous devez associer l'instance Amazon EC2 que vous avez créée à une paire de clés SSH. Le système d'exploitation que vous choisissez pour cette instance n'a pas d'importance, car elle servira simplement de bastion SSH pour relier l'internet au VPC de votre cluster OpenShift Container Platform. L'Amazon Machine Image (AMI) que vous utilisez a son importance. Avec Red Hat Enterprise Linux CoreOS (RHCOS), par exemple, vous pouvez fournir des clés via Ignition, comme le fait le programme d'installation.

4. Une fois que vous avez provisionné votre instance Amazon EC2 et que vous pouvez y accéder par SSH, vous devez ajouter la clé SSH que vous avez associée à votre installation d'OpenShift Container Platform. Cette clé peut être différente de la clé de l'instance bastion, mais ce n'est pas obligatoire.

   Note

   L'accès SSH direct n'est recommandé que pour la reprise après sinistre. Lorsque l'API Kubernetes est réactive, exécutez plutôt des pods privilégiés.

5. Exécutez oc get nodes, inspectez la sortie et choisissez l'un des nœuds qui est un maître. Le nom d'hôte ressemble à ip-10-0-1-163.ec2.internal.

6. À partir de l'hôte SSH Bastion que vous avez déployé manuellement dans Amazon EC2, connectez-vous en SSH à l'hôte du plan de contrôle. Veillez à utiliser la même clé SSH que celle spécifiée lors de l'installation :

   $ ssh -i <ssh-key-path> core@<master-hostname>

1. Exécutez la commande suivante pour afficher l'état du déploiement :

   $ oc get -n openshift-network-operator deployment/network-operator

   Exemple de sortie

   NAME               READY   UP-TO-DATE   AVAILABLE   AGE
   network-operator   1/1     1            1           56m

2. Exécutez la commande suivante pour afficher l'état de l'opérateur de réseau de cluster :

   $ oc get clusteroperator/network

   Exemple de sortie

   NAME      VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
   network   4.5.4     True        False         False      50m

   Les champs suivants fournissent des informations sur l'état de l'opérateur : AVAILABLE, PROGRESSING, et DEGRADED. Le champ AVAILABLE est True lorsque l'opérateur de réseau de groupe signale un état de disponibilité.

1. Utilisez la commande oc get pour afficher l'état du déploiement :

   $ oc get -n openshift-dns-operator deployment/dns-operator

   Exemple de sortie

   NAME           READY     UP-TO-DATE   AVAILABLE   AGE
   dns-operator   1/1       1            1           23h

2. Utilisez la commande oc get pour afficher l'état de l'opérateur DNS :

   $ oc get clusteroperator/dns

   Exemple de sortie

   NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
   dns       4.1.0-0.11  True        False         False      92m

   AVAILABLE PROGRESSING et fournissent des informations sur l'état de l'opérateur. est lorsqu'au moins un pod de l'ensemble de démons CoreDNS signale une condition d'état . DEGRADED AVAILABLE True Available

Procédure

1. Utilisez la commande oc describe pour afficher les paramètres par défaut dns:

   $ oc describe dns.operator/default

   Exemple de sortie

   Name:         default
   Namespace:
   Labels:       <none>
   Annotations:  <none>
   API Version:  operator.openshift.io/v1
   Kind:         DNS
   ...
   Status:
     Cluster Domain:  cluster.local 1
     Cluster IP:      172.30.0.10 2
   ...

   1

   Le champ Domaine de cluster est le domaine DNS de base utilisé pour construire des noms de pods et de domaines de service entièrement qualifiés.

   2

   L'IP du cluster est l'adresse que les pods interrogent pour la résolution des noms. L'IP est définie comme la 10e adresse de la plage CIDR du service.

2. Pour connaître le CIDR de service de votre cluster, utilisez la commande oc get:

   $ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'

Procédure

1. Modifier l'objet Opérateur DNS nommé default:

   $ oc edit dns.operator/default

   Cela permet à l'opérateur de créer et de mettre à jour la carte de configuration nommée dns-default avec des blocs de configuration de serveur supplémentaires basés sur Server. Si aucun des serveurs ne dispose d'une zone correspondant à la requête, la résolution de noms revient aux serveurs DNS en amont.

   Configuration de la redirection DNS

   apiVersion: operator.openshift.io/v1
   kind: DNS
   metadata:
     name: default
   spec:
     servers:
     - name: example-server 1
       zones: 2
       - example.com
       forwardPlugin:
         policy: Random 3
         upstreams: 4
         - 1.1.1.1
         - 2.2.2.2:5353
     upstreamResolvers: 5
       policy: Random 6
       upstreams: 7
       - type: SystemResolvConf 8
       - type: Network
         address: 1.2.3.4 9
         port: 53 10

   1

   Doit être conforme à la syntaxe du nom de service rfc6335.

   2

   Doit être conforme à la définition d'un sous-domaine dans la syntaxe du nom de service rfc1123. Le domaine de cluster, cluster.local, n'est pas un sous-domaine valide pour le champ zones.

   3

   Définit la politique de sélection des résolveurs en amont. La valeur par défaut est Random. Vous pouvez également utiliser les valeurs RoundRobin, et Sequential.

   4

   Un maximum de 15 upstreams est autorisé par forwardPlugin.

   5

   Facultatif. Vous pouvez l'utiliser pour remplacer la stratégie par défaut et transmettre la résolution DNS aux résolveurs DNS spécifiés (résolveurs en amont) pour le domaine par défaut. Si vous ne fournissez pas de résolveurs en amont, les requêtes de nom DNS sont envoyées aux serveurs situés à l'adresse /etc/resolv.conf.

   6

   Détermine l'ordre dans lequel les serveurs en amont sont sélectionnés pour l'interrogation. Vous pouvez spécifier l'une de ces valeurs : Random RoundRobin , ou Sequential. La valeur par défaut est Sequential.

   7

   Facultatif. Vous pouvez l'utiliser pour fournir des résolveurs en amont.

   8

   Vous pouvez spécifier deux types de upstreams - SystemResolvConf et Network. SystemResolvConf configure l'amont pour utiliser /etc/resolv.conf et Network définit un Networkresolver. Vous pouvez spécifier l'un ou l'autre ou les deux.

   9

   Si le type spécifié est Network, vous devez fournir une adresse IP. Le champ address doit être une adresse IPv4 ou IPv6 valide.

   10

   Si le type spécifié est Network, vous pouvez éventuellement indiquer un port. Le champ port doit avoir une valeur comprise entre 1 et 65535. Si vous ne spécifiez pas de port pour l'amont, le port 853 est utilisé par défaut.

   Lorsque vous travaillez dans un environnement très réglementé, vous pouvez avoir besoin de sécuriser le trafic DNS lorsque vous transmettez des requêtes à des résolveurs en amont, afin de garantir un trafic DNS supplémentaire et la confidentialité des données. Les administrateurs de clusters peuvent configurer la sécurité de la couche transport (TLS) pour les requêtes DNS transmises.

   Configuration du transfert DNS avec TLS

   apiVersion: operator.openshift.io/v1
   kind: DNS
   metadata:
     name: default
   spec:
     servers:
     - name: example-server 1
       zones: 2
       - example.com
       forwardPlugin:
         transportConfig:
           transport: TLS 3
           tls:
             caBundle:
               name: mycacert
             serverName: dnstls.example.com  4
         policy: Random 5
         upstreams: 6
         - 1.1.1.1
         - 2.2.2.2:5353
     upstreamResolvers: 7
       transportConfig:
         transport: TLS
         tls:
           caBundle:
             name: mycacert
           serverName: dnstls.example.com
       upstreams:
       - type: Network 8
         address: 1.2.3.4 9
         port: 53 10

   1

   Doit être conforme à la syntaxe du nom de service rfc6335.

   2

   Doit être conforme à la définition d'un sous-domaine dans la syntaxe du nom de service rfc1123. Le domaine de cluster, cluster.local, n'est pas un sous-domaine valide pour le champ zones. Le domaine de cluster, cluster.local, est un subdomain non valide pour zones.

   3

   Lors de la configuration de TLS pour les requêtes DNS transférées, le champ transport doit avoir la valeur TLS. Par défaut, CoreDNS met en cache les connexions transférées pendant 10 secondes. CoreDNS maintiendra une connexion TCP ouverte pendant ces 10 secondes si aucune requête n'est émise. Dans le cas de clusters importants, assurez-vous que votre serveur DNS est conscient du fait qu'il pourrait recevoir de nombreuses nouvelles connexions à maintenir ouvertes, car vous pouvez initier une connexion par nœud. Configurez votre hiérarchie DNS en conséquence pour éviter les problèmes de performance.

   4

   Lors de la configuration de TLS pour les requêtes DNS transmises, il s'agit d'un nom de serveur obligatoire utilisé dans le cadre de l'indication du nom du serveur (SNI) pour valider le certificat du serveur TLS en amont.

   5

   Définit la politique de sélection des résolveurs en amont. La valeur par défaut est Random. Vous pouvez également utiliser les valeurs RoundRobin, et Sequential.

   6

   Il est obligatoire. Vous pouvez l'utiliser pour fournir des résolveurs en amont. Un maximum de 15 entrées upstreams est autorisé par entrée forwardPlugin.

   7

   Facultatif. Vous pouvez l'utiliser pour remplacer la stratégie par défaut et transmettre la résolution DNS aux résolveurs DNS spécifiés (résolveurs en amont) pour le domaine par défaut. Si vous ne fournissez pas de résolveurs en amont, les requêtes de nom DNS sont envoyées aux serveurs situés à l'adresse /etc/resolv.conf.

   8

   Network indique que ce résolveur en amont doit traiter les demandes transférées séparément des résolveurs en amont répertoriés dans /etc/resolv.conf. Seul le type Network est autorisé en cas d'utilisation de TLS et vous devez fournir une adresse IP.

   9

   Le champ address doit être une adresse IPv4 ou IPv6 valide.

   10

   Vous pouvez optionnellement fournir un port. La valeur de port doit être comprise entre 1 et 65535. Si vous ne spécifiez pas de port pour l'amont, le port 853 est utilisé par défaut.

   Note

   Si servers est indéfini ou invalide, la carte de configuration ne contient que le serveur par défaut.

2. Afficher la carte de configuration :

   $ oc get configmap/dns-default -n openshift-dns -o yaml

   Exemple de ConfigMap DNS basé sur l'exemple précédent de DNS

   apiVersion: v1
   data:
     Corefile: |
       example.com:5353 {
           forward . 1.1.1.1 2.2.2.2:5353
       }
       bar.com:5353 example.com:5353 {
           forward . 3.3.3.3 4.4.4.4:5454 1
       }
       .:5353 {
           errors
           health
           kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods insecure
               upstream
               fallthrough in-addr.arpa ip6.arpa
           }
           prometheus :9153
           forward . /etc/resolv.conf 1.2.3.4:53 {
               policy Random
           }
           cache 30
           reload
       }
   kind: ConfigMap
   metadata:
     labels:
       dns.operator.openshift.io/owning-dns: default
     name: dns-default
     namespace: openshift-dns

   1

   Les modifications apportées au site forwardPlugin déclenchent une mise à jour continue de l'ensemble des démons CoreDNS.

Procédure

1. Modifiez l'objet Opérateur DNS nommé default en exécutant la commande suivante :

   $ oc edit dns.operator.openshift.io/default

2. Modifier les valeurs de mise en cache de la durée de vie (TTL) :

   Configuration de la mise en cache DNS

   apiVersion: operator.openshift.io/v1
   kind: DNS
   metadata:
     name: default
   spec:
     cache:
       positiveTTL: 1h 1
       negativeTTL: 0.5h10m 2

   1

   La valeur de la chaîne 1h est convertie en nombre de secondes par CoreDNS. Si ce champ est omis, la valeur est supposée être 0s et le cluster utilise la valeur interne par défaut de 900s comme solution de repli.

   2

   La valeur de la chaîne peut être une combinaison d'unités telles que 0.5h10m et est convertie en nombre de secondes par CoreDNS. Si ce champ est omis, la valeur est supposée être 0s et le cluster utilise la valeur interne par défaut de 30s comme solution de repli.

   Avertissement

   La définition de champs TTL de faible valeur peut entraîner une augmentation de la charge sur le cluster, sur les résolveurs en amont, ou sur les deux.

Procédure

1. Créez un projet appelé hello-openshift en exécutant la commande suivante :

   $ oc new-project hello-openshift

2. Créez un pod dans le projet en exécutant la commande suivante :

   $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json

3. Créez un service appelé hello-openshift en exécutant la commande suivante :

   $ oc expose pod/hello-openshift

4. Créez une définition de route appelée hello-openshift-route.yaml:

   Définition YAML de la route créée pour le sharding :

   apiVersion: route.openshift.io/v1
   kind: Route
   metadata:
     labels:
       type: sharded 1
     name: hello-openshift-edge
     namespace: hello-openshift
   spec:
     subdomain: hello-openshift 2
     tls:
       termination: edge
     to:
       kind: Service
       name: hello-openshift

   1

   La clé d'étiquette et la valeur d'étiquette correspondante doivent toutes deux correspondre à celles spécifiées dans le contrôleur d'entrée. Dans cet exemple, le contrôleur d'entrée a la clé et la valeur d'étiquette type: sharded.

   2

   La route sera exposée en utilisant la valeur du champ subdomain. Lorsque vous spécifiez le champ subdomain, vous devez laisser le nom d'hôte non défini. Si vous spécifiez à la fois les champs host et subdomain, l'itinéraire utilisera la valeur du champ host et ignorera le champ subdomain.

5. Utilisez hello-openshift-route.yaml pour créer une route vers l'application hello-openshift en exécutant la commande suivante :

   $ oc -n hello-openshift create -f hello-openshift-route.yaml

1. Créez le site IngressNodeFirewallConfig à l'intérieur de l'espace de noms openshift-ingress-node-firewall nommé ingressnodefirewallconfig.

2. Exécutez la commande suivante pour déployer les règles de l'opérateur de pare-feu du nœud d'entrée :

   $ oc apply -f rule.yaml

Procédure

1. Exécutez la commande suivante pour afficher toutes les règles en vigueur :

   $ oc get ingressnodefirewall

2. Choisissez l'un des noms de <resource> et exécutez la commande suivante pour afficher les règles ou les configurations :

   $ oc get <resource> <name> -o yaml

Procédure

1. Créez un fichier de ressources personnalisées (CR) nommé sample-ingress.yaml contenant les éléments suivants :

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

   1

   Spécifiez l'objet <name> avec un nom pour l'objet IngressController.

   2

   Spécifiez l'adresse domain en fonction de l'enregistrement DNS qui a été créé en tant que condition préalable.

   3

   Spécifiez l'adresse scope comme External pour exposer l'équilibreur de charge à l'extérieur.

   4

   dnsManagementPolicy indique si le contrôleur d'entrée gère le cycle de vie de l'enregistrement DNS générique associé à l'équilibreur de charge. Les valeurs valides sont Managed et Unmanaged. La valeur par défaut est Managed.

2. Enregistrez le fichier pour appliquer les modifications.

   oc apply -f <name>.yaml 1

Procédure

1. Modifiez le choix de IngressController pour définir dnsManagementPolicy:

   SCOPE=$(oc -n openshift-ingress-operator get ingresscontroller <name> -o=jsonpath="{.status.endpointPublishingStrategy.loadBalancer.scope}")
   
   oc -n openshift-ingress-operator patch ingresscontrollers/<name> --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"dnsManagementPolicy":"Unmanaged", "scope":"${SCOPE}"}}}}'

2. Facultatif : vous pouvez supprimer l'enregistrement DNS associé dans le fournisseur de cloud.

Procédure

1. Pour dresser la liste des objets PodNetworkConnectivityCheck en cours, entrez la commande suivante :

   $ oc get podnetworkconnectivitycheck -n openshift-network-diagnostics

   Exemple de sortie

   NAME                                                                                                                                AGE
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0   75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1   73m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2   75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-service-cluster                               75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-default-service-cluster                                 75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-external                                         75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-internal                                         75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-0            75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-1            75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-2            75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh      74m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-c-n8mbf      74m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-d-4hnrz      74m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-service-cluster                               75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0    75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1    75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2    74m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-service-cluster                                75m

2. Consulter les journaux des tests de connexion :

   1. À partir de la sortie de la commande précédente, identifiez le point d'extrémité pour lequel vous souhaitez consulter les journaux de connectivité.

   2. Pour visualiser l'objet, entrez la commande suivante :

      $ oc get podnetworkconnectivitycheck <name> \
        -n openshift-network-diagnostics -o yaml

      où <name> indique le nom de l'objet PodNetworkConnectivityCheck.

      Exemple de sortie

      apiVersion: controlplane.operator.openshift.io/v1alpha1
      kind: PodNetworkConnectivityCheck
      metadata:
        name: network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0
        namespace: openshift-network-diagnostics
        ...
      spec:
        sourcePod: network-check-source-7c88f6d9f-hmg2f
        targetEndpoint: 10.0.0.4:6443
        tlsClientCert:
          name: ""
      status:
        conditions:
        - lastTransitionTime: "2021-01-13T20:11:34Z"
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnectSuccess
          status: "True"
          type: Reachable
        failures:
        - latency: 2.241775ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
            to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
            connection refused'
          reason: TCPConnectError
          success: false
          time: "2021-01-13T20:10:34Z"
        - latency: 2.582129ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
            to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
            connection refused'
          reason: TCPConnectError
          success: false
          time: "2021-01-13T20:09:34Z"
        - latency: 3.483578ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
            to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
            connection refused'
          reason: TCPConnectError
          success: false
          time: "2021-01-13T20:08:34Z"
        outages:
        - end: "2021-01-13T20:11:34Z"
          endLogs:
          - latency: 2.032018ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              tcp connection to 10.0.0.4:6443 succeeded'
            reason: TCPConnect
            success: true
            time: "2021-01-13T20:11:34Z"
          - latency: 2.241775ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
              connect: connection refused'
            reason: TCPConnectError
            success: false
            time: "2021-01-13T20:10:34Z"
          - latency: 2.582129ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
              connect: connection refused'
            reason: TCPConnectError
            success: false
            time: "2021-01-13T20:09:34Z"
          - latency: 3.483578ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
              connect: connection refused'
            reason: TCPConnectError
            success: false
            time: "2021-01-13T20:08:34Z"
          message: Connectivity restored after 2m59.999789186s
          start: "2021-01-13T20:08:34Z"
          startLogs:
          - latency: 3.483578ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
              connect: connection refused'
            reason: TCPConnectError
            success: false
            time: "2021-01-13T20:08:34Z"
        successes:
        - latency: 2.845865ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:14:34Z"
        - latency: 2.926345ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:13:34Z"
        - latency: 2.895796ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:12:34Z"
        - latency: 2.696844ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:11:34Z"
        - latency: 1.502064ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:10:34Z"
        - latency: 1.388857ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:09:34Z"
        - latency: 1.906383ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:08:34Z"
        - latency: 2.089073ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:07:34Z"
        - latency: 2.156994ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:06:34Z"
        - latency: 1.777043ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:05:34Z"

1. Pour obtenir le MTU actuel du réseau de la grappe, entrez la commande suivante :

   $ oc describe network.config cluster

   Exemple de sortie

   ...
   Status:
     Cluster Network:
       Cidr:               10.217.0.0/22
       Host Prefix:        23
     Cluster Network MTU:  1400
     Network Type:         OpenShiftSDN
     Service Network:
       10.217.4.0/23
   ...

2. Préparez votre configuration pour le MTU matériel :

   • Si votre MTU matériel est spécifié avec DHCP, mettez à jour votre configuration DHCP, par exemple avec la configuration dnsmasq suivante :

     dhcp-option-force=26,<mtu>

     où :

     <mtu>

     Spécifie le MTU matériel que le serveur DHCP doit annoncer.

   • Si le MTU de votre matériel est spécifié par une ligne de commande du noyau avec PXE, mettez à jour cette configuration en conséquence.

   • Si votre MTU matériel est spécifié dans une configuration de connexion NetworkManager, effectuez les étapes suivantes. Cette approche est la valeur par défaut d'OpenShift Container Platform si vous ne spécifiez pas explicitement votre configuration réseau avec DHCP, une ligne de commande du noyau ou une autre méthode. Vos nœuds de cluster doivent tous utiliser la même configuration réseau sous-jacente pour que la procédure suivante fonctionne sans modification.

     1. Recherchez l'interface réseau principale :

        • Si vous utilisez le plugin réseau OpenShift SDN, entrez la commande suivante :

          $ oc debug node/<node_name> -- chroot /host ip route list match 0.0.0.0/0 | awk '{print $5 }'

          où :

          <node_name>

          Spécifie le nom d'un nœud dans votre cluster.

        • Si vous utilisez le plugin réseau OVN-Kubernetes, entrez la commande suivante :

          oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0

          où :

          <node_name>

          Spécifie le nom d'un nœud dans votre cluster.

     2. Créez la configuration NetworkManager suivante dans le fichier <interface>-mtu.conf:

        Exemple de configuration de la connexion NetworkManager

        [connection-<interface>-mtu]
        match-device=interface-name:<interface>
        ethernet.mtu=<mtu>

        où :

        <mtu>

        Spécifie la nouvelle valeur du MTU matériel.

        <interface>

        Spécifie le nom de l'interface réseau primaire.

     3. Créez deux objets MachineConfig, l'un pour les nœuds du plan de contrôle et l'autre pour les nœuds de travail de votre cluster :

        1. Créez la configuration Butane suivante dans le fichier control-plane-interface.bu:

           variant: openshift
           version: 4.12.0
           metadata:
             name: 01-control-plane-interface
             labels:
               machineconfiguration.openshift.io/role: master
           storage:
             files:
               - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf 1
                 contents:
                   local: <interface>-mtu.conf 2
                 mode: 0600

           1 1

           Spécifiez le nom de la connexion NetworkManager pour l'interface réseau primaire.

           2

           Spécifiez le nom de fichier local pour le fichier de configuration NetworkManager mis à jour à l'étape précédente.

        2. Créez la configuration Butane suivante dans le fichier worker-interface.bu:

           variant: openshift
           version: 4.12.0
           metadata:
             name: 01-worker-interface
             labels:
               machineconfiguration.openshift.io/role: worker
           storage:
             files:
               - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf 1
                 contents:
                   local: <interface>-mtu.conf 2
                 mode: 0600

           1

           Spécifiez le nom de la connexion NetworkManager pour l'interface réseau primaire.

           2

           Spécifiez le nom de fichier local pour le fichier de configuration NetworkManager mis à jour à l'étape précédente.

        3. Créez des objets MachineConfig à partir des configurations Butane en exécutant la commande suivante :

           $ for manifest in control-plane-interface worker-interface; do
               butane --files-dir . $manifest.bu > $manifest.yaml
             done

3. Pour commencer la migration du MTU, spécifiez la configuration de la migration en entrant la commande suivante. L'opérateur Machine Config effectue un redémarrage progressif des nœuds de la grappe pour préparer le changement de MTU.

   $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
     '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'

   où :

   <overlay_from>

   Spécifie la valeur actuelle du MTU du réseau cluster.

   <overlay_to>

   Spécifie le MTU cible pour le réseau du cluster. Cette valeur est définie par rapport à la valeur de <machine_to> et pour OVN-Kubernetes doit être 100 moins et pour OpenShift SDN doit être 50 moins.

   <machine_to>

   Spécifie le MTU pour l'interface réseau primaire sur le réseau hôte sous-jacent.

   Exemple d'augmentation du MTU du cluster

   $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
     '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'

4. Lorsque le MCO met à jour les machines de chaque pool de configuration, il redémarre chaque nœud un par un. Vous devez attendre que tous les nœuds soient mis à jour. Vérifiez l'état du pool de configuration des machines en entrant la commande suivante :

   $ oc get mcp

   Un nœud mis à jour avec succès a le statut suivant : UPDATED=true, UPDATING=false, DEGRADED=false.

   Note

   Par défaut, le MCO met à jour une machine par pool à la fois, ce qui fait que la durée totale de la migration augmente avec la taille du cluster.

5. Confirmer l'état de la configuration de la nouvelle machine sur les hôtes :

   1. Pour répertorier l'état de la configuration de la machine et le nom de la configuration de la machine appliquée, entrez la commande suivante :

      $ oc describe node | egrep "hostname|machineconfig"

      Exemple de sortie

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done

      Vérifiez que les affirmations suivantes sont vraies :

      • La valeur du champ machineconfiguration.openshift.io/state est Done.
      • La valeur du champ machineconfiguration.openshift.io/currentConfig est égale à la valeur du champ machineconfiguration.openshift.io/desiredConfig.

   2. Pour confirmer que la configuration de la machine est correcte, entrez la commande suivante :

      oc get machineconfig <config_name> -o yaml | grep ExecStart

      où <config_name> est le nom de la machine configurée dans le champ machineconfiguration.openshift.io/currentConfig.

      La configuration de la machine doit inclure la mise à jour suivante de la configuration de systemd :

      ExecStart=/usr/local/bin/mtu-migration.sh

6. Mettre à jour la valeur MTU de l'interface réseau sous-jacente :

   • Si vous spécifiez le nouveau MTU avec une configuration de connexion NetworkManager, entrez la commande suivante. L'opérateur MachineConfig effectue automatiquement un redémarrage des nœuds de votre cluster.

     $ for manifest in control-plane-interface worker-interface; do
         oc create -f $manifest.yaml
       done

   • Si vous spécifiez le nouveau MTU avec une option de serveur DHCP ou une ligne de commande du noyau et PXE, apportez les modifications nécessaires à votre infrastructure.

7. Lorsque le MCO met à jour les machines de chaque pool de configuration, il redémarre chaque nœud un par un. Vous devez attendre que tous les nœuds soient mis à jour. Vérifiez l'état du pool de configuration des machines en entrant la commande suivante :

   $ oc get mcp

   Un nœud mis à jour avec succès a le statut suivant : UPDATED=true, UPDATING=false, DEGRADED=false.

   Note

   Par défaut, le MCO met à jour une machine par pool à la fois, ce qui fait que la durée totale de la migration augmente avec la taille du cluster.

8. Confirmer l'état de la configuration de la nouvelle machine sur les hôtes :

   1. Pour répertorier l'état de la configuration de la machine et le nom de la configuration de la machine appliquée, entrez la commande suivante :

      $ oc describe node | egrep "hostname|machineconfig"

      Exemple de sortie

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done

      Vérifiez que les affirmations suivantes sont vraies :

      • La valeur du champ machineconfiguration.openshift.io/state est Done.
      • La valeur du champ machineconfiguration.openshift.io/currentConfig est égale à la valeur du champ machineconfiguration.openshift.io/desiredConfig.

   2. Pour confirmer que la configuration de la machine est correcte, entrez la commande suivante :

      oc get machineconfig <config_name> -o yaml | grep path :

      où <config_name> est le nom de la machine configurée dans le champ machineconfiguration.openshift.io/currentConfig.

      Si la configuration de la machine est déployée avec succès, la sortie précédente contient le chemin d'accès au fichier /etc/NetworkManager/system-connections/<connection_name>.

      La configuration de la machine ne doit pas contenir la ligne ExecStart=/usr/local/bin/mtu-migration.sh.

9. Pour finaliser la migration du MTU, entrez l'une des commandes suivantes :

   • Si vous utilisez le plugin réseau OVN-Kubernetes :

     $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
       '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'

     où :

     <mtu>

     Spécifie le nouveau MTU du réseau cluster que vous avez spécifié avec <overlay_to>.

   • Si vous utilisez le plugin réseau OpenShift SDN :

     $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
       '{"spec": { "migration": null, "defaultNetwork":{ "openshiftSDNConfig": { "mtu": <mtu> }}}}'

     où :

     <mtu>

     Spécifie le nouveau MTU du réseau cluster que vous avez spécifié avec <overlay_to>.

1. Pour obtenir le MTU actuel du réseau de la grappe, entrez la commande suivante :

   $ oc describe network.config cluster

2. Obtenir le MTU actuel de l'interface réseau principale d'un nœud.

   1. Pour dresser la liste des nœuds de votre cluster, entrez la commande suivante :

      $ oc get nodes

   2. Pour obtenir le paramètre MTU actuel de l'interface réseau principale d'un nœud, entrez la commande suivante :

      $ oc debug node/<node> -- chroot /host ip address show <interface>

      où :

      <node>

      Spécifie un nœud à partir de la sortie de l'étape précédente.

      <interface>

      Spécifie le nom de l'interface réseau primaire pour le nœud.

      Exemple de sortie

      ens3 : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051

Procédure

1. Pour étendre la plage de ports du nœud, entrez la commande suivante. Remplacez <port> par le plus grand numéro de port de la nouvelle plage.

   $ oc patch network.config.openshift.io cluster --type=merge -p \
     '{
       "spec":
         { "serviceNodePortRange": "30000-<port>" }
     }'

   Astuce

   Vous pouvez également appliquer le fichier YAML suivant pour mettre à jour la plage de ports du nœud :

   apiVersion: config.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     serviceNodePortRange: "30000-<port>"

   Exemple de sortie

   network.config.openshift.io/cluster patched

2. Pour confirmer que la configuration est active, entrez la commande suivante. L'application de la mise à jour peut prendre plusieurs minutes.

   $ oc get configmaps -n openshift-kube-apiserver config \
     -o jsonpath="{.data['config\.yaml']}" | \
     grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'

   Exemple de sortie

   "service-node-port-range":["30000-33000"]

Procédure

1. Créez un compte de service de basculement IP :

   $ oc create sa ipfailover

2. Mise à jour des contraintes de contexte de sécurité (SCC) pour hostNetwork:

   $ oc adm policy add-scc-to-user privileged -z ipfailover
   $ oc adm policy add-scc-to-user hostnetwork -z ipfailover

3. Créer un fichier YAML de déploiement pour configurer le basculement IP :

   Exemple de déploiement YAML pour la configuration du basculement IP

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: ipfailover-keepalived 1
     labels:
       ipfailover: hello-openshift
   spec:
     strategy:
       type: Recreate
     replicas: 2
     selector:
       matchLabels:
         ipfailover: hello-openshift
     template:
       metadata:
         labels:
           ipfailover: hello-openshift
       spec:
         serviceAccountName: ipfailover
         privileged: true
         hostNetwork: true
         nodeSelector:
           node-role.kubernetes.io/worker: ""
         containers:
         - name: openshift-ipfailover
           image: quay.io/openshift/origin-keepalived-ipfailover
           ports:
           - containerPort: 63000
             hostPort: 63000
           imagePullPolicy: IfNotPresent
           securityContext:
             privileged: true
           volumeMounts:
           - name: lib-modules
             mountPath: /lib/modules
             readOnly: true
           - name: host-slash
             mountPath: /host
             readOnly: true
             mountPropagation: HostToContainer
           - name: etc-sysconfig
             mountPath: /etc/sysconfig
             readOnly: true
           - name: config-volume
             mountPath: /etc/keepalive
           env:
           - name: OPENSHIFT_HA_CONFIG_NAME
             value: "ipfailover"
           - name: OPENSHIFT_HA_VIRTUAL_IPS 2
             value: "1.1.1.1-2"
           - name: OPENSHIFT_HA_VIP_GROUPS 3
             value: "10"
           - name: OPENSHIFT_HA_NETWORK_INTERFACE 4
             value: "ens3" #The host interface to assign the VIPs
           - name: OPENSHIFT_HA_MONITOR_PORT 5
             value: "30060"
           - name: OPENSHIFT_HA_VRRP_ID_OFFSET 6
             value: "0"
           - name: OPENSHIFT_HA_REPLICA_COUNT 7
             value: "2" #Must match the number of replicas in the deployment
           - name: OPENSHIFT_HA_USE_UNICAST
             value: "false"
           #- name: OPENSHIFT_HA_UNICAST_PEERS
             #value: "10.0.148.40,10.0.160.234,10.0.199.110"
           - name: OPENSHIFT_HA_IPTABLES_CHAIN 8
             value: "INPUT"
           #- name: OPENSHIFT_HA_NOTIFY_SCRIPT 9
           #  value: /etc/keepalive/mynotifyscript.sh
           - name: OPENSHIFT_HA_CHECK_SCRIPT 10
             value: "/etc/keepalive/mycheckscript.sh"
           - name: OPENSHIFT_HA_PREEMPTION 11
             value: "preempt_delay 300"
           - name: OPENSHIFT_HA_CHECK_INTERVAL 12
             value: "2"
           livenessProbe:
             initialDelaySeconds: 10
             exec:
               command:
               - pgrep
               - keepalived
         volumes:
         - name: lib-modules
           hostPath:
             path: /lib/modules
         - name: host-slash
           hostPath:
             path: /
         - name: etc-sysconfig
           hostPath:
             path: /etc/sysconfig
         # config-volume contains the check script
         # created with `oc create configmap keepalived-checkscript --from-file=mycheckscript.sh`
         - configMap:
             defaultMode: 0755
             name: keepalived-checkscript
           name: config-volume
         imagePullSecrets:
           - name: openshift-pull-secret 13

   1

   Le nom du déploiement du basculement IP.

   2

   La liste des plages d'adresses IP à répliquer. Elle doit être fournie. Par exemple, 1.2.3.4-6,1.2.3.9.

   3

   Le nombre de groupes à créer pour VRRP. S'il n'est pas défini, un groupe est créé pour chaque plage IP virtuelle spécifiée avec la variable OPENSHIFT_HA_VIP_GROUPS.

   4

   Nom de l'interface que le basculement IP utilise pour envoyer le trafic VRRP. Par défaut, eth0 est utilisé.

   5

   Le module de basculement IP tente d'ouvrir une connexion TCP à ce port sur chaque VIP. Si la connexion est établie, le service est considéré comme étant en cours d'exécution. Si ce port est défini sur 0, le test est toujours réussi. La valeur par défaut est 80.

   6

   La valeur de décalage utilisée pour définir les ID des routeurs virtuels. L'utilisation de différentes valeurs de décalage permet à plusieurs configurations de basculement IP d'exister au sein d'un même cluster. Le décalage par défaut est 0, et la plage autorisée va de 0 à 255.

   7

   Le nombre de répliques à créer. Il doit correspondre à la valeur spec.replicas dans la configuration du déploiement du basculement IP. La valeur par défaut est 2.

   8

   Le nom de la chaîne iptables pour ajouter automatiquement une règle iptables afin d'autoriser le trafic VRRP. Si la valeur n'est pas définie, une règle iptables n'est pas ajoutée. Si la chaîne n'existe pas, elle n'est pas créée et Keepalived fonctionne en mode unicast. La valeur par défaut est INPUT.

   9

   Le nom du chemin complet dans le système de fichiers pod d'un script qui est exécuté chaque fois que l'état change.

   10

   Le nom du chemin complet dans le système de fichiers pod d'un script qui est périodiquement exécuté pour vérifier que l'application fonctionne.

   11

   La stratégie de gestion d'un nouvel hôte de priorité supérieure. La valeur par défaut est preempt_delay 300, ce qui fait qu'une instance Keepalived prend en charge un VIP après 5 minutes si un maître de priorité inférieure détient le VIP.

   12

   Période, en secondes, pendant laquelle le script de vérification est exécuté. La valeur par défaut est 2.

   13

   Créez le secret d'extraction avant de créer le déploiement, sinon vous obtiendrez une erreur lors de la création du déploiement.

Procédure

1. Créez le script souhaité et créez une carte de configuration pour le contenir. Le script n'a pas d'arguments d'entrée et doit renvoyer 0 pour OK et 1 pour fail.

   Le script de vérification, mycheckscript.sh:

   #!/bin/bash
       # Whatever tests are needed
       # E.g., send request and verify response
   exit 0

2. Créer la carte de configuration :

   $ oc create configmap mycustomcheck --from-file=mycheckscript.sh

3. Ajouter le script au pod. L'adresse defaultMode pour les fichiers de configuration montés doit pouvoir être exécutée à l'aide des commandes oc ou en modifiant la configuration du déploiement. Une valeur de 0755, 493 décimal, est typique :

   $ oc set env deploy/ipfailover-keepalived \
       OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh

   $ oc set volume deploy/ipfailover-keepalived --add --overwrite \
       --name=config-volume \
       --mount-path=/etc/keepalive \
       --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'

   Note

   La commande oc set env est sensible aux espaces blancs. Il ne doit pas y avoir d'espace de part et d'autre du signe =.

   Astuce

   Vous pouvez également modifier la configuration du déploiement de ipfailover-keepalived:

   $ oc edit deploy ipfailover-keepalived

       spec:
         containers:
         - env:
           - name: OPENSHIFT_HA_CHECK_SCRIPT  1
             value: /etc/keepalive/mycheckscript.sh
   ...
           volumeMounts: 2
           - mountPath: /etc/keepalive
             name: config-volume
         dnsPolicy: ClusterFirst
   ...
         volumes: 3
         - configMap:
             defaultMode: 0755 4
             name: customrouter
           name: config-volume
   ...

   1

   Dans le champ spec.container.env, ajoutez la variable d'environnement OPENSHIFT_HA_CHECK_SCRIPT pour qu'elle pointe vers le fichier de script monté.

   2

   Ajoutez le champ spec.container.volumeMounts pour créer le point de montage.

   3

   Ajouter un nouveau champ spec.volumes pour mentionner la carte de configuration.

   4

   Cela permet de définir l'autorisation d'exécution des fichiers. Lors de la relecture, elle est affichée en décimal, 493.

   Enregistrez les modifications et quittez l'éditeur. Cette opération redémarre ipfailover-keepalived.

Procédure

1. Facultatif : identifiez et supprimez tous les scripts de contrôle et de notification qui sont stockés sous forme de cartes de configuration :

   1. Identifier si des pods pour le basculement IP utilisent une carte de configuration comme volume :

      $ oc get pod -l ipfailover \
        -o jsonpath="\
      {range .items[?(@.spec.volumes[*].configMap)]}
      {'Namespace: '}{.metadata.namespace}
      {'Pod:       '}{.metadata.name}
      {'Volumes that use config maps:'}
      {range .spec.volumes[?(@.configMap)]}  {'volume:    '}{.name}
        {'configMap: '}{.configMap.name}{'\n'}{end}
      {end}"

      Exemple de sortie

      Namespace: default
      Pod:       keepalived-worker-59df45db9c-2x9mn
      Volumes that use config maps:
        volume:    config-volume
        configMap: mycustomcheck

   2. Si l'étape précédente a fourni les noms des cartes de configuration utilisées comme volumes, supprimez les cartes de configuration :

      oc delete configmap <configmap_name> $ oc delete configmap <configmap_name>

2. Identifier un déploiement existant pour le basculement IP :

   $ oc get deployment -l ipfailover

   Exemple de sortie

   NAMESPACE   NAME         READY   UP-TO-DATE   AVAILABLE   AGE
   default     ipfailover   2/2     2            2           105d

3. Supprimer le déploiement :

   oc delete deployment <ipfailover_deployment_name>

4. Supprimez le compte de service ipfailover:

   $ oc delete sa ipfailover

5. Exécutez un travail qui supprime la règle des tables IP ajoutée lors de la configuration initiale du basculement IP :

   1. Créez un fichier tel que remove-ipfailover-job.yaml dont le contenu est similaire à l'exemple suivant :

      apiVersion: batch/v1
      kind: Job
      metadata:
        generateName: remove-ipfailover-
        labels:
          app: remove-ipfailover
      spec:
        template:
          metadata:
            name: remove-ipfailover
          spec:
            containers:
            - name: remove-ipfailover
              image: quay.io/openshift/origin-keepalived-ipfailover:4.12
              command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"]
            nodeSelector:
              kubernetes.io/hostname: <host_name>  <.>
            restartPolicy: Never

      <.> Exécutez la tâche pour chaque nœud de votre cluster qui a été configuré pour le basculement IP et remplacez le nom d'hôte à chaque fois.

   2. Exécuter le travail :

      $ oc create -f remove-ipfailover-job.yaml

      Exemple de sortie

      job.batch/remove-ipfailover-2h8dm created

Procédure

1. Créez une définition de pièce jointe au réseau, telle que tuning-example.yaml, avec le contenu suivant :

   apiVersion: "k8s.cni.cncf.io/v1"
   kind: NetworkAttachmentDefinition
   metadata:
     name: <name> 1
     namespace: default 2
   spec:
     config: '{
       "cniVersion": "0.4.0", 3
       "name": "<name>", 4
       "plugins": [{
          "type": "<main_CNI_plugin>" 5
         },
         {
          "type": "tuning", 6
          "sysctl": {
               "net.ipv4.conf.IFNAME.accept_redirects": "1" 7
           }
         }
        ]
   }

   1

   Spécifie le nom de la pièce jointe réseau supplémentaire à créer. Le nom doit être unique dans l'espace de noms spécifié.

   2

   Spécifie l'espace de noms auquel l'objet est associé.

   3

   Spécifie la version de la spécification CNI.

   4

   Spécifie le nom de la configuration. Il est recommandé de faire correspondre le nom de la configuration à la valeur du nom de la définition de l'attachement au réseau.

   5

   Spécifie le nom du plugin CNI principal à configurer.

   6

   Spécifie le nom du méta plugin CNI.

   7

   Spécifie le sysctl à définir.

   Un exemple de fichier yaml est présenté ici :

   apiVersion: "k8s.cni.cncf.io/v1"
   kind: NetworkAttachmentDefinition
   metadata:
     name: tuningnad
     namespace: default
   spec:
     config: '{
       "cniVersion": "0.4.0",
       "name": "tuningnad",
       "plugins": [{
         "type": "bridge"
         },
         {
         "type": "tuning",
         "sysctl": {
            "net.ipv4.conf.IFNAME.accept_redirects": "1"
           }
       }
     ]
   }'

2. Appliquez le fichier yaml en exécutant la commande suivante :

   $ oc apply -f tuning-example.yaml

   Exemple de sortie

   networkattachmentdefinition.k8.cni.cncf.io/tuningnad created

3. Créez un pod tel que examplepod.yaml avec la définition de l'attachement réseau similaire à ce qui suit :

   apiVersion: v1
   kind: Pod
   metadata:
     name: tunepod
     namespace: default
     annotations:
       k8s.v1.cni.cncf.io/networks: tuningnad 1
   spec:
     containers:
     - name: podexample
       image: centos
       command: ["/bin/bash", "-c", "sleep INF"]
       securityContext:
         runAsUser: 2000 2
         runAsGroup: 3000 3
         allowPrivilegeEscalation: false 4
         capabilities: 5
           drop: ["ALL"]
     securityContext:
       runAsNonRoot: true 6
       seccompProfile: 7
         type: RuntimeDefault

   1

   Spécifiez le nom du site configuré NetworkAttachmentDefinition.

   2

   runAsUser contrôle l'identifiant de l'utilisateur avec lequel le conteneur est exécuté.

   3

   runAsGroup contrôle l'identifiant du groupe primaire avec lequel les conteneurs sont exécutés.

   4

   allowPrivilegeEscalation détermine si un pod peut demander à autoriser l'escalade des privilèges. S'il n'est pas spécifié, la valeur par défaut est true. Ce booléen contrôle directement si le drapeau no_new_privs est activé sur le processus du conteneur.

   5

   capabilities permettent des actions privilégiées sans donner un accès complet à la racine. Cette politique permet de s'assurer que toutes les capacités sont supprimées du pod.

   6

   runAsNonRoot: true exige que le conteneur fonctionne avec un utilisateur dont l'UID est différent de 0.

   7

   RuntimeDefault active le profil seccomp par défaut pour un pod ou une charge de travail de conteneur.

4. Appliquez le fichier yaml en exécutant la commande suivante :

   $ oc apply -f examplepod.yaml

5. Vérifiez que le module est créé en exécutant la commande suivante :

   $ oc get pod

   Exemple de sortie

   NAME      READY   STATUS    RESTARTS   AGE
   tunepod   1/1     Running   0          47s

6. Connectez-vous au module en exécutant la commande suivante :

   $ oc rsh tunepod

7. Vérifiez les valeurs des drapeaux sysctl configurés. Par exemple, trouvez la valeur net.ipv4.conf.net1.accept_redirects en exécutant la commande suivante :

   sh-4.4# sysctl net.ipv4.conf.net1.accept_redirects

   Résultats attendus

   net.ipv4.conf.net1.accept_redirects = 1

Procédure

1. Créez un fichier nommé load-sctp-module.yaml qui contient la définition YAML suivante :

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     name: load-sctp-module
     labels:
       machineconfiguration.openshift.io/role: worker
   spec:
     config:
       ignition:
         version: 3.2.0
       storage:
         files:
           - path: /etc/modprobe.d/sctp-blacklist.conf
             mode: 0644
             overwrite: true
             contents:
               source: data:,
           - path: /etc/modules-load.d/sctp-load.conf
             mode: 0644
             overwrite: true
             contents:
               source: data:,sctp

2. Pour créer l'objet MachineConfig, entrez la commande suivante :

   $ oc create -f load-sctp-module.yaml

3. En option : Pour observer l'état des nœuds pendant que l'opérateur MachineConfig applique le changement de configuration, entrez la commande suivante. Lorsque l'état d'un nœud passe à Ready, la mise à jour de la configuration est appliquée.

   $ oc get nodes

Procédure

1. La création d'un pod démarre un listener SCTP :

   1. Créer un fichier nommé sctp-server.yaml qui définit un pod avec le YAML suivant :

      apiVersion: v1
      kind: Pod
      metadata:
        name: sctpserver
        labels:
          app: sctpserver
      spec:
        containers:
          - name: sctpserver
            image: registry.access.redhat.com/ubi8/ubi
            command: ["/bin/sh", "-c"]
            args:
              ["dnf install -y nc && sleep inf"]
            ports:
              - containerPort: 30102
                name: sctpserver
                protocol: SCTP

   2. Créez le pod en entrant la commande suivante :

      $ oc create -f sctp-server.yaml

2. Créer un service pour le pod d'écoute SCTP.

   1. Créez un fichier nommé sctp-service.yaml qui définit un service avec le YAML suivant :

      apiVersion: v1
      kind: Service
      metadata:
        name: sctpservice
        labels:
          app: sctpserver
      spec:
        type: NodePort
        selector:
          app: sctpserver
        ports:
          - name: sctpserver
            protocol: SCTP
            port: 30102
            targetPort: 30102

   2. Pour créer le service, entrez la commande suivante :

      $ oc create -f sctp-service.yaml

3. Créer un pod pour le client SCTP.

   1. Créez un fichier nommé sctp-client.yaml avec le langage YAML suivant :

      apiVersion: v1
      kind: Pod
      metadata:
        name: sctpclient
        labels:
          app: sctpclient
      spec:
        containers:
          - name: sctpclient
            image: registry.access.redhat.com/ubi8/ubi
            command: ["/bin/sh", "-c"]
            args:
              ["dnf install -y nc && sleep inf"]

   2. Pour créer l'objet Pod, entrez la commande suivante :

      $ oc apply -f sctp-client.yaml

4. Exécutez une liste d'écoute SCTP sur le serveur.

   1. Pour vous connecter au module serveur, entrez la commande suivante :

      $ oc rsh sctpserver

   2. Pour démarrer l'auditeur SCTP, entrez la commande suivante :

      $ nc -l 30102 --sctp

5. Se connecter à l'auditeur SCTP sur le serveur.

   1. Ouvrez une nouvelle fenêtre ou un nouvel onglet dans votre programme de terminal.

   2. Obtenez l'adresse IP du service sctpservice. Entrez la commande suivante :

      $ oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'

   3. Pour se connecter au pod client, entrez la commande suivante :

      $ oc rsh sctpclient

   4. Pour démarrer le client SCTP, entrez la commande suivante. Remplacez <cluster_IP> par l'adresse IP du cluster du service sctpservice.

      # nc <cluster_IP> 30102 --sctp

Procédure

1. Créer un espace de noms pour l'opérateur PTP.

   1. Enregistrez le YAML suivant dans le fichier ptp-namespace.yaml:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-ptp
        annotations:
          workload.openshift.io/allowed: management
        labels:
          name: openshift-ptp
          openshift.io/cluster-monitoring: "true"

   2. Créer le CR Namespace:

      $ oc create -f ptp-namespace.yaml

2. Créez un groupe d'opérateurs pour l'opérateur PTP.

   1. Enregistrez le YAML suivant dans le fichier ptp-operatorgroup.yaml:

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: ptp-operators
        namespace: openshift-ptp
      spec:
        targetNamespaces:
        - openshift-ptp

   2. Créer le CR OperatorGroup:

      $ oc create -f ptp-operatorgroup.yaml

3. S'abonner à l'opérateur PTP.

   1. Enregistrez le YAML suivant dans le fichier ptp-sub.yaml:

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: ptp-operator-subscription
        namespace: openshift-ptp
      spec:
        channel: "stable"
        name: ptp-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   2. Créer le CR Subscription:

      $ oc create -f ptp-sub.yaml

4. Pour vérifier que l'opérateur est installé, entrez la commande suivante :

   $ oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phase

   Exemple de sortie

   Name                         Phase
   4.12.0-202301261535          Succeeded

Procédure

1. Installez l'opérateur PTP à l'aide de la console web d'OpenShift Container Platform :

   1. Dans la console Web OpenShift Container Platform, cliquez sur Operators → OperatorHub.
   2. Choisissez PTP Operator dans la liste des opérateurs disponibles, puis cliquez sur Install.
   3. Sur la page Install Operator, sous A specific namespace on the cluster, sélectionnez openshift-ptp. Cliquez ensuite sur Install.

2. En option, vérifier que l'installation de l'opérateur PTP a réussi : Vérifiez que l'opérateur PTP a été installé avec succès :

   1. Passez à la page Operators → Installed Operators.

   2. Assurez-vous que PTP Operator est listé dans le projet openshift-ptp avec un Status de InstallSucceeded.

      Note

      Pendant l'installation, un opérateur peut afficher un état Failed. Si l'installation réussit par la suite avec un message InstallSucceeded, vous pouvez ignorer le message Failed.

      Si l'opérateur n'apparaît pas tel qu'il a été installé, il convient de poursuivre le dépannage :

      • Allez à la page Operators → Installed Operators et inspectez les onglets Operator Subscriptions et Install Plans pour voir s'il y a des défaillances ou des erreurs sous Status.
      • Allez sur la page Workloads → Pods et vérifiez les journaux pour les pods dans le projet openshift-ptp.