OpenShift Container Platform

Spécifiez le type de profil de sécurité TLS (Old, Intermediate, ou Custom). La valeur par défaut est Intermediate.

Spécifiez le champ approprié pour le type sélectionné :

old: {}
intermediate: {}
custom:

Pour le type custom, spécifiez une liste de chiffrements TLS et la version TLS minimale acceptée.

Enregistrez le fichier pour appliquer les modifications.

Vérification

Vérifiez que le profil est défini dans le CR IngressController:

oc describe IngressController default -n openshift-ingress-operator

$ oc describe IngressController default -n openshift-ingress-operator

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name:         default
Namespace:    openshift-ingress-operator
Labels:       <none>
Annotations:  <none>
API Version:  operator.openshift.io/v1
Kind:         IngressController
 ...
Spec:
 ...
  Tls Security Profile:
    Custom:
      Ciphers:
        ECDHE-ECDSA-CHACHA20-POLY1305
        ECDHE-RSA-CHACHA20-POLY1305
        ECDHE-RSA-AES128-GCM-SHA256
        ECDHE-ECDSA-AES128-GCM-SHA256
      Min TLS Version:  VersionTLS11
    Type:               Custom
 ...

Name:         default
Namespace:    openshift-ingress-operator
Labels:       <none>
Annotations:  <none>
API Version:  operator.openshift.io/v1
Kind:         IngressController
 ...
Spec:
 ...
  Tls Security Profile:
    Custom:
      Ciphers:
        ECDHE-ECDSA-CHACHA20-POLY1305
        ECDHE-RSA-CHACHA20-POLY1305
        ECDHE-RSA-AES128-GCM-SHA256
        ECDHE-ECDSA-AES128-GCM-SHA256
      Min TLS Version:  VersionTLS11
    Type:               Custom
 ...

Copy to Clipboard

Toggle word wrap

7.3.1.3. Configuration de l'authentification mutuelle TLS
Copier lien

Vous pouvez configurer le contrôleur d'entrée pour activer l'authentification mutuelle TLS (mTLS) en définissant une valeur spec.clientTLS. La valeur clientTLS configure le contrôleur d'entrée pour qu'il vérifie les certificats des clients. Cette configuration comprend la définition d'une valeur clientCA, qui est une référence à une carte de configuration. La carte de configuration contient le paquet de certificats CA codé PEM utilisé pour vérifier le certificat d'un client. En option, vous pouvez configurer une liste de filtres de sujet de certificat.

Si la valeur clientCA indique un point de distribution de liste de révocation de certificats (CRL) X509v3, l'opérateur d'entrée télécharge la CRL et configure le contrôleur d'entrée pour qu'il en prenne acte. Les demandes qui ne fournissent pas de certificats valides sont rejetées.

Conditions préalables

Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

Créer une carte de configuration dans l'espace de noms openshift-config:
```
oc create configmap router-ca-certs-default --from-file=ca-bundle.pem=client-ca.crt -n openshift-config
```
```
$ oc create configmap router-ca-certs-default --from-file=ca-bundle.pem=client-ca.crt -n openshift-config
```
Copy to Clipboard Toggle word wrap
Note
La clé de données de la carte de configuration doit être ca-bundle.pem, et la valeur des données doit être un certificat d'autorité de certification au format PEM.
Modifiez la ressource IngressController dans le projet openshift-ingress-operator:
```
oc edit IngressController default -n openshift-ingress-operator
```
```
$ oc edit IngressController default -n openshift-ingress-operator
```
Copy to Clipboard Toggle word wrap

Ajoutez le champ spec.clientTLS et ses sous-champs pour configurer le TLS mutuel :

Exemple de CR IngressController pour un profil clientTLS qui spécifie des modèles de filtrage

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    clientTLS:
      clientCertificatePolicy: Required
      clientCA:
        name: router-ca-certs-default
      allowedSubjectPatterns:
      - "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    clientTLS:
      clientCertificatePolicy: Required
      clientCA:
        name: router-ca-certs-default
      allowedSubjectPatterns:
      - "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"

Copy to Clipboard

Toggle word wrap

7.4. Afficher le contrôleur d'entrée par défaut
Copier lien

L'opérateur d'ingestion est une fonctionnalité essentielle d'OpenShift Container Platform et est activé d'emblée.

Chaque nouvelle installation d'OpenShift Container Platform a un ingresscontroller nommé default. Il peut être complété par des contrôleurs d'ingestion supplémentaires. Si l'adresse ingresscontroller par défaut est supprimée, l'opérateur d'ingestion la recréera automatiquement dans la minute qui suit.

Procédure

Affichez le contrôleur d'entrée par défaut :

oc describe --namespace=openshift-ingress-operator ingresscontroller/default

$ oc describe --namespace=openshift-ingress-operator ingresscontroller/default

Copy to Clipboard

Toggle word wrap

7.5. Visualiser l'état de l'opérateur d'entrée
Copier lien

Vous pouvez visualiser et contrôler l'état de votre opérateur d'entrée.

Procédure

Consultez votre statut d'opérateur d'entrée :
```
oc describe clusteroperators/ingress
```
```
$ oc describe clusteroperators/ingress
```
Copy to Clipboard Toggle word wrap

7.6. Consulter les journaux du contrôleur d'entrée
Copier lien

Vous pouvez consulter les journaux du contrôleur d'ingérence.

Procédure

Consultez les journaux du contrôleur d'ingérence :

oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>

oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>

Copy to Clipboard

Toggle word wrap

7.7. Afficher l'état du contrôleur d'entrée
Copier lien

Vous pouvez consulter l'état d'un contrôleur d'entrée particulier.

Procédure

Consulter l'état d'un contrôleur d'entrée :

oc describe --namespace=openshift-ingress-operator ingresscontroller/<name> $ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>

oc describe --namespace=openshift-ingress-operator ingresscontroller/<name> $ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>

Copy to Clipboard

Toggle word wrap

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

7.8.1. Définition d'un certificat personnalisé par défaut
Copier lien

En tant qu'administrateur, vous pouvez configurer un contrôleur d'entrée pour qu'il utilise un certificat personnalisé en créant une ressource Secret et en modifiant la ressource personnalisée (CR) IngressController.

Conditions préalables

Vous devez disposer d'une paire certificat/clé dans des fichiers codés PEM, où le certificat est signé par une autorité de certification de confiance ou par une autorité de certification de confiance privée que vous avez configurée dans une infrastructure de clés publiques (PKI) personnalisée.
Votre certificat répond aux exigences suivantes :
- Le certificat est valable pour le domaine d'entrée.
- Le certificat utilise l'extension subjectAltName pour spécifier un domaine de remplacement, tel que *.apps.ocp4.example.com.
Vous devez avoir un CR IngressController. Vous pouvez utiliser le CR par défaut :
```
oc --namespace openshift-ingress-operator get ingresscontrollers
```
```
$ oc --namespace openshift-ingress-operator get ingresscontrollers
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
NAME      AGE
default   10m
```
```
NAME      AGE
default   10m
```
Copy to Clipboard Toggle word wrap

Note

Si vous avez des certificats intermédiaires, ils doivent être inclus dans le fichier tls.crt du secret contenant un certificat par défaut personnalisé. L'ordre est important lors de la spécification d'un certificat ; indiquez votre (vos) certificat(s) intermédiaire(s) après le(s) certificat(s) de serveur.

Procédure

Ce qui suit suppose que le certificat personnalisé et la paire de clés se trouvent dans les fichiers tls.crt et tls.key dans le répertoire de travail actuel. Remplacez les noms de chemin réels par tls.crt et tls.key. Vous pouvez également remplacer custom-certs-default par un autre nom lorsque vous créez la ressource Secret et que vous y faites référence dans le CR IngressController.

Note

Cette action entraînera le redéploiement du contrôleur d'entrée, à l'aide d'une stratégie de déploiement continu.

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

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

Copy to Clipboard

Toggle word wrap

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"}}}'

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

Copy to Clipboard

Toggle word wrap

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

$ 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

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

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

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

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 du secret du certificat doit correspondre à la valeur utilisée pour mettre à jour le CR.

Une fois que le CR du contrôleur d'ingestion a été modifié, l'opérateur d'ingestion met à jour le déploiement du contrôleur d'ingestion afin d'utiliser le certificat personnalisé.

7.8.2. Suppression d'un certificat personnalisé par défaut
Copier lien

En tant qu'administrateur, vous pouvez supprimer un certificat personnalisé pour lequel vous avez configuré un contrôleur d'entrée.

Conditions préalables

Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
Vous avez installé l'OpenShift CLI (oc).
Vous avez précédemment configuré un certificat par défaut personnalisé pour le contrôleur d'entrée.

Procédure

Pour supprimer le certificat personnalisé et restaurer le certificat fourni avec OpenShift Container Platform, entrez la commande suivante :
```
oc patch -n openshift-ingress-operator ingresscontrollers/default \
  --type json -p $'- op: remove\n  path: /spec/defaultCertificate'
```
```
$ oc patch -n openshift-ingress-operator ingresscontrollers/default \
  --type json -p $'- op: remove\n  path: /spec/defaultCertificate'
```
Copy to Clipboard Toggle word wrap
Il peut y avoir un délai pendant que le cluster réconcilie la nouvelle configuration du certificat.

Vérification

Pour confirmer que le certificat original du cluster est restauré, entrez la commande suivante :

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

$ 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

où :

<domain>: Spécifie le nom de domaine de base pour votre cluster.

Exemple de sortie

subject=CN = *.apps.<domain>
issuer=CN = ingress-operator@1620633373
notAfter=May 10 10:44:36 2023 GMT

subject=CN = *.apps.<domain>
issuer=CN = ingress-operator@1620633373
notAfter=May 10 10:44:36 2023 GMT

Copy to Clipboard

Toggle word wrap

7.8.3. Mise à l'échelle automatique d'un contrôleur d'entrée
Copier lien

Mettre automatiquement à l'échelle un contrôleur d'entrée pour répondre dynamiquement aux exigences de performance ou de disponibilité du routage, telles que l'exigence d'augmenter le débit. La procédure suivante fournit un exemple de mise à l'échelle du contrôleur par défaut IngressController.

Important

Le Custom Metrics Autoscaler est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Conditions préalables

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

Procédure

Créez un projet dans l'espace de noms openshift-ingress-operator en exécutant la commande suivante :
```
oc project openshift-ingress-operator
```
```
$ oc project openshift-ingress-operator
```
Copy to Clipboard Toggle word wrap
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
  
  Copy to Clipboard Toggle word wrap
  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
  Copy to Clipboard Toggle word wrap

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

$ oc create serviceaccount thanos && oc describe 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-b4l9s
Mountable secrets:   thanos-dockercfg-b4l9s
Tokens:              thanos-token-c422q
Events:              <none>

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>

Copy to Clipboard

Toggle word wrap

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

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 }')

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

Copy to Clipboard

Toggle word wrap

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

$ 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

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

Appliquez le nouveau rôle en exécutant la commande suivante :
```
oc apply -f thanos-metrics-reader.yaml
```
```
$ oc apply -f thanos-metrics-reader.yaml
```
Copy to Clipboard Toggle word wrap

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 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

$ 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 inter-espaces de noms. L'étape suivante utilise une requête de l'espace de noms kube-metrics qui nécessite cet argument.

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

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

Copy to Clipboard

Toggle word wrap

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.

Appliquez la définition de ressource personnalisée en exécutant la commande suivante :
```
oc apply -f ingress-autoscaler.yaml
```
```
$ oc apply -f ingress-autoscaler.yaml
```
Copy to Clipboard Toggle word wrap

Vérification

Vérifiez que le contrôleur d'entrée par défaut est mis à l'échelle pour correspondre à la valeur renvoyée par la requête kube-state-metrics en exécutant les commandes suivantes :

Utilisez la commande grep pour rechercher des répliques dans le fichier YAML du contrôleur d'entrée :
```
oc get ingresscontroller/default -o yaml | grep replicas:
```
```
$ oc get ingresscontroller/default -o yaml | grep replicas:
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
replicas: 3
```
```
replicas: 3
```
Copy to Clipboard Toggle word wrap

Obtenir les pods dans le projet openshift-ingress:

oc get pods -n openshift-ingress

$ oc get pods -n openshift-ingress

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                             READY   STATUS    RESTARTS   AGE
router-default-7b5df44ff-l9pmm   2/2     Running   0          17h
router-default-7b5df44ff-s5sl5   2/2     Running   0          3d22h
router-default-7b5df44ff-wwsth   2/2     Running   0          66s

NAME                             READY   STATUS    RESTARTS   AGE
router-default-7b5df44ff-l9pmm   2/2     Running   0          17h
router-default-7b5df44ff-s5sl5   2/2     Running   0          3d22h
router-default-7b5df44ff-wwsth   2/2     Running   0          66s

Copy to Clipboard

Toggle word wrap

7.8.4. Mise à l'échelle d'un contrôleur d'entrée
Copier lien

Mettre à l'échelle manuellement un contrôleur d'entrée pour répondre aux exigences de performance de routage ou de disponibilité telles que l'exigence d'augmenter le débit. Les commandes oc sont utilisées pour mettre à l'échelle la ressource IngressController. La procédure suivante fournit un exemple de mise à l'échelle de la ressource par défaut IngressController.

Note

La mise à l'échelle n'est pas une action immédiate, car il faut du temps pour créer le nombre souhaité de répliques.

Procédure

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}'

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

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Copy to Clipboard

Toggle word wrap

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

$ 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

ingresscontroller.operator.openshift.io/default patched

Copy to Clipboard

Toggle word wrap

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}'

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

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Copy to Clipboard

Toggle word wrap

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

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: Si vous avez besoin d'un nombre différent de répliques, modifiez la valeur de replicas.

7.8.5. Configuration de la journalisation des accès d'entrée
Copier lien

Vous pouvez configurer le contrôleur d'entrée pour activer les journaux d'accès. Si vous avez des clusters qui ne reçoivent pas beaucoup de trafic, vous pouvez enregistrer les logs dans un sidecar. Si vous avez des clusters à fort trafic, pour éviter de dépasser la capacité de la pile de journalisation ou pour intégrer une infrastructure de journalisation en dehors d'OpenShift Container Platform, vous pouvez transmettre les journaux à un point d'extrémité syslog personnalisé. Vous pouvez également spécifier le format des journaux d'accès.

La journalisation des conteneurs est utile pour activer les journaux d'accès sur les clusters à faible trafic lorsqu'il n'y a pas d'infrastructure de journalisation Syslog existante, ou pour une utilisation à court terme lors du diagnostic de problèmes avec le contrôleur d'entrée.

Syslog est nécessaire pour les clusters à fort trafic où les logs d'accès pourraient dépasser la capacité de la pile OpenShift Logging, ou pour les environnements où toute solution de logging doit s'intégrer à une infrastructure de logging Syslog existante. Les cas d'utilisation de Syslog peuvent se chevaucher.

Conditions préalables

Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Configurer l'enregistrement des accès entrants à un sidecar.

Pour configurer la journalisation des accès entrants, vous devez spécifier une destination à l'aide de spec.logging.access.destination. Pour spécifier la journalisation vers un conteneur sidecar, vous devez spécifier Container spec.logging.access.destination.type . L'exemple suivant est une définition de contrôleur d'entrée qui enregistre vers une destination Container:

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Container

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Container

Copy to Clipboard

Toggle word wrap

Lorsque vous configurez le contrôleur d'entrée pour qu'il se connecte à un sidecar, l'opérateur crée un conteneur nommé logs dans le pod du contrôleur d'entrée :

oc -n openshift-ingress logs deployment.apps/router-default -c logs

$ oc -n openshift-ingress logs deployment.apps/router-default -c logs

Copy to Clipboard

Toggle word wrap

Exemple de sortie

2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"

2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"

Copy to Clipboard

Toggle word wrap

Configurer la journalisation de l'accès à l'entrée vers un point de terminaison Syslog.

Pour configurer la journalisation des accès d'entrée, vous devez spécifier une destination à l'aide de spec.logging.access.destination. Pour spécifier la journalisation vers un point de terminaison Syslog, vous devez spécifier Syslog pour spec.logging.access.destination.type. Si le type de destination est Syslog, vous devez également spécifier un point d'extrémité de destination à l'aide de spec.logging.access.destination.syslog.endpoint et vous pouvez spécifier une installation à l'aide de spec.logging.access.destination.syslog.facility. L'exemple suivant est une définition de contrôleur d'entrée qui enregistre vers une destination Syslog:
```
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
```
```
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
```
Copy to Clipboard Toggle word wrap
Note
Le port de destination de syslog doit être UDP.

Configurer l'enregistrement des accès d'entrée avec un format d'enregistrement spécifique.

Vous pouvez spécifier spec.logging.access.httpLogFormat pour personnaliser le format du journal. L'exemple suivant est une définition de contrôleur d'entrée qui enregistre sur un point d'extrémité syslog avec l'adresse IP 1.2.3.4 et le port 10514 :

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
      httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
      httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'

Copy to Clipboard

Toggle word wrap

Désactiver la journalisation des accès entrants.

Pour désactiver la journalisation des accès entrants, laissez spec.logging ou spec.logging.access vide :

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access: null

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access: null

Copy to Clipboard

Toggle word wrap

7.8.6. Réglage du nombre de fils du contrôleur d'ingérence
Copier lien

Un administrateur de cluster peut définir le nombre de threads afin d'augmenter le nombre de connexions entrantes qu'un cluster peut gérer. Vous pouvez corriger un contrôleur d'entrée existant pour augmenter le nombre de threads.

Conditions préalables

La procédure suivante suppose que vous avez déjà créé un contrôleur d'entrée.

Procédure

Mettre à jour le contrôleur d'entrée pour augmenter le nombre de threads :
```
oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
```
```
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
```
Copy to Clipboard Toggle word wrap
Note
Si vous disposez d'un nœud capable d'exécuter de grandes quantités de ressources, vous pouvez configurer spec.nodePlacement.nodeSelector avec des étiquettes correspondant à la capacité du nœud prévu et configurer spec.tuningOptions.threadCount avec une valeur élevée appropriée.

7.8.7. Configuration d'un contrôleur d'entrée pour utiliser un équilibreur de charge interne
Copier lien

Lors de la création d'un contrôleur d'ingestion sur des plateformes en nuage, le contrôleur d'ingestion est publié par un équilibreur de charge en nuage public par défaut. En tant qu'administrateur, vous pouvez créer un contrôleur d'entrée qui utilise un équilibreur de charge interne au nuage.

Avertissement

Si votre fournisseur de cloud est Microsoft Azure, vous devez avoir au moins un équilibreur de charge public qui pointe vers vos nœuds. Si ce n'est pas le cas, tous vos nœuds perdront la connectivité de sortie vers l'internet.

Important

Si vous souhaitez modifier le paramètre scope pour une ressource IngressController, vous pouvez modifier le paramètre .spec.endpointPublishingStrategy.loadBalancer.scope après la création de la ressource personnalisée (CR).

Figure 7.1. Diagramme de LoadBalancer

OpenShift Container Platform Ingress LoadBalancerService endpoint publishing strategy

Le graphique précédent illustre les concepts suivants relatifs à la stratégie de publication des points d'extrémité de OpenShift Container Platform Ingress LoadBalancerService :

Vous pouvez équilibrer la charge en externe, en utilisant l'équilibreur de charge du fournisseur de cloud, ou en interne, en utilisant l'équilibreur de charge du contrôleur d'ingestion OpenShift.
Vous pouvez utiliser l'adresse IP unique de l'équilibreur de charge et des ports plus familiers, tels que 8080 et 4200, comme le montre le cluster illustré dans le graphique.
Le trafic provenant de l'équilibreur de charge externe est dirigé vers les pods et géré par l'équilibreur de charge, comme le montre l'instance d'un nœud en panne. Voir la documentation de Kubernetes Services pour plus de détails sur la mise en œuvre.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

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> 
spec:
  domain: <domain> 
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal

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: 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.

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 
```
```
oc create -f <name>-ingress-controller.yaml 
```
1
Copy to Clipboard Toggle word wrap
1
Remplacez <name> par le nom de l'objet IngressController.
Facultatif : Confirmez que le contrôleur d'entrée a été créé en exécutant la commande suivante :
```
oc --all-namespaces=true get ingresscontrollers
```
```
$ oc --all-namespaces=true get ingresscontrollers
```
Copy to Clipboard Toggle word wrap

7.8.8. Configuration de l'accès global pour un contrôleur d'entrée sur GCP
Copier lien

Un contrôleur d'entrée créé sur GCP avec un équilibreur de charge interne génère une adresse IP interne pour le service. Un administrateur de cluster peut spécifier l'option d'accès global, qui permet aux clients de n'importe quelle région du même réseau VPC et de la même région de calcul que l'équilibreur de charge, d'atteindre les charges de travail exécutées sur votre cluster.

Pour plus d'informations, voir la documentation GCP pour l'accès global.

Conditions préalables

Vous avez déployé un cluster OpenShift Container Platform sur une infrastructure GCP.
Vous avez configuré un contrôleur d'entrée pour utiliser un équilibreur de charge interne.
You installed the OpenShift CLI (oc).

Procédure

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.

Configurer la ressource Ingress Controller :

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

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

Copy to Clipboard

Toggle word wrap

Modifiez le fichier YAML :

Sample clientAccess configuration to Global

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

  spec:
    endpointPublishingStrategy:
      loadBalancer:
        providerParameters:
          gcp:
            clientAccess: Global

1


          type: GCP
        scope: Internal
      type: LoadBalancerService

Copy to Clipboard

Toggle word wrap

1: Set gcp.clientAccess to Global.

Enregistrez le fichier pour appliquer les modifications.

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
```
```
$ oc -n openshift-ingress edit svc/router-default -o yaml
```
Copy to Clipboard Toggle word wrap
La sortie montre que l'accès global est activé pour GCP avec l'annotation networking.gke.io/internal-load-balancer-allow-global-access.

7.8.9. Définition de l'intervalle de contrôle de santé du contrôleur d'entrée
Copier lien

L'administrateur d'un cluster peut définir l'intervalle de contrôle de santé afin de déterminer la durée d'attente du routeur entre deux contrôles de santé consécutifs. Cette valeur est appliquée globalement par défaut à toutes les routes. La valeur par défaut est de 5 secondes.

Conditions préalables

La procédure suivante suppose que vous avez déjà créé un contrôleur d'entrée.

Procédure

Mettre à jour le contrôleur d'entrée afin de modifier l'intervalle entre les contrôles de santé du back-end :
```
oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
```
```
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
```
Copy to Clipboard Toggle word wrap
Note
Pour remplacer le site healthCheckInterval pour un seul itinéraire, utilisez l'annotation d'itinéraire router.openshift.io/haproxy.health.check.interval

7.8.10. Configurer le contrôleur d'entrée par défaut de votre cluster pour qu'il soit interne
Copier lien

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

Avertissement

Si votre fournisseur de cloud est Microsoft Azure, vous devez avoir au moins un équilibreur de charge public qui pointe vers vos nœuds. Si ce n'est pas le cas, tous vos nœuds perdront la connectivité de sortie vers l'internet.

Important

Si vous souhaitez modifier le paramètre scope pour une ressource IngressController, vous pouvez modifier le paramètre .spec.endpointPublishingStrategy.loadBalancer.scope après la création de la ressource personnalisée (CR).

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

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

$ 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

7.8.11. Configuration de la politique d'admission des routes
Copier lien

Les administrateurs et les développeurs d'applications peuvent exécuter des applications dans plusieurs espaces de noms avec le même nom de domaine. Cela s'adresse aux organisations où plusieurs équipes développent des microservices qui sont exposés sur le même nom d'hôte.

Avertissement

L'autorisation des revendications à travers les espaces de noms ne devrait être activée que pour les clusters avec confiance entre les espaces de noms, sinon un utilisateur malveillant pourrait prendre le contrôle d'un nom d'hôte. Pour cette raison, la politique d'admission par défaut interdit les demandes de noms d'hôtes entre espaces de noms.

Conditions préalables

Privilèges d'administrateur de cluster.

Procédure

Modifiez le champ .spec.routeAdmission de la variable de ressource ingresscontroller à l'aide de la commande suivante :

oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge

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

Copy to Clipboard

Toggle word wrap

Exemple de configuration du contrôleur d'entrée

spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed
...

spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed
...

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le langage YAML suivant pour configurer la politique d'admission des routes :

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed

Copy to Clipboard

Toggle word wrap

7.8.12. Utilisation d'itinéraires génériques
Copier lien

Le contrôleur d'entrée HAProxy prend en charge les itinéraires génériques. L'opérateur d'entrée utilise wildcardPolicy pour configurer la variable d'environnement ROUTER_ALLOW_WILDCARD_ROUTES du contrôleur d'entrée.

Le comportement par défaut du contrôleur d'entrée est d'admettre les itinéraires avec une politique de caractères génériques de None, ce qui est rétrocompatible avec les ressources IngressController existantes.

Procédure

Configurer la politique des caractères génériques.
1. Utilisez la commande suivante pour modifier la ressource IngressController:
  $ oc edit IngressController
  Copy to Clipboard Toggle word wrap
2. Sous spec, définissez le champ wildcardPolicy comme WildcardsDisallowed ou WildcardsAllowed:
  spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
  Copy to Clipboard Toggle word wrap

7.8.13. Utilisation des en-têtes X-Forwarded
Copier lien

Vous configurez le contrôleur d'entrée HAProxy pour qu'il spécifie une stratégie de traitement des en-têtes HTTP, y compris Forwarded et X-Forwarded-For. L'opérateur d'entrée utilise le champ HTTPHeaders pour configurer la variable d'environnement ROUTER_SET_FORWARDED_HEADERS du contrôleur d'entrée.

Procédure

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

Utilisez la commande suivante pour modifier la ressource IngressController:
```
oc edit IngressController
```
```
$ oc edit IngressController
```
Copy to Clipboard Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

Exemples de cas d'utilisation

As a cluster administrator, you can:

Configurez un proxy externe qui injecte l'en-tête X-Forwarded-For dans chaque requête avant de la transmettre à un contrôleur d'entrée.
Pour configurer le contrôleur d'entrée afin qu'il transmette l'en-tête sans modification, vous devez spécifier la politique never. Le contrôleur d'entrée ne définit alors jamais les en-têtes et les applications ne reçoivent que les en-têtes fournis par le proxy externe.
Configurez le contrôleur d'entrée pour qu'il transmette sans modification l'en-tête X-Forwarded-For que votre proxy externe définit sur les requêtes de clusters externes.
Pour configurer le contrôleur d'entrée afin qu'il définisse l'en-tête X-Forwarded-For sur les requêtes internes du cluster, qui ne passent pas par le proxy externe, spécifiez la stratégie if-none. Si l'en-tête d'une requête HTTP est déjà défini via le proxy externe, le contrôleur d'entrée le conserve. Si l'en-tête est absent parce que la requête n'est pas passée par le proxy, le contrôleur d'entrée ajoute l'en-tête.

As an application developer, you can:

Configurer un proxy externe spécifique à l'application qui injecte l'en-tête X-Forwarded-For.
Pour configurer un contrôleur d'entrée afin qu'il transmette l'en-tête sans modification pour la route d'une application, sans affecter la politique pour les autres routes, ajoutez une annotation haproxy.router.openshift.io/set-forwarded-headers: if-none ou haproxy.router.openshift.io/set-forwarded-headers: never sur la route de l'application.
Note
Vous pouvez définir l'annotation haproxy.router.openshift.io/set-forwarded-headers pour chaque itinéraire, indépendamment de la valeur définie globalement pour le contrôleur d'entrée.

7.8.14. Activation de la connectivité HTTP/2 Ingress
Copier lien

Vous pouvez activer la connectivité HTTP/2 transparente de bout en bout dans HAProxy. Cela permet aux propriétaires d'applications d'utiliser les fonctionnalités du protocole HTTP/2, notamment la connexion unique, la compression des en-têtes, les flux binaires, etc.

Vous pouvez activer la connectivité HTTP/2 pour un contrôleur d'entrée individuel ou pour l'ensemble du cluster.

Pour permettre l'utilisation de HTTP/2 pour la connexion du client à HAProxy, un itinéraire doit spécifier un certificat personnalisé. Une route qui utilise le certificat par défaut ne peut pas utiliser HTTP/2. Cette restriction est nécessaire pour éviter les problèmes liés à la coalescence des connexions, lorsque le client réutilise une connexion pour différents itinéraires qui utilisent le même certificat.

La connexion entre HAProxy et le module d'application ne peut utiliser HTTP/2 que pour le recryptage des itinéraires et non pour les itinéraires terminés ou non sécurisés. Cette restriction est due au fait que HAProxy utilise la négociation de protocole au niveau de l'application (ALPN), qui est une extension TLS, pour négocier l'utilisation de HTTP/2 avec le back-end. Il en résulte que le protocole HTTP/2 de bout en bout est possible avec passthrough et re-encrypt, mais pas avec des itinéraires non sécurisés ou terminés par un bord.

Avertissement

L'utilisation de WebSockets avec une route de recryptage et avec HTTP/2 activé sur un contrôleur d'entrée nécessite la prise en charge de WebSocket sur HTTP/2. WebSockets sur HTTP/2 est une fonctionnalité de HAProxy 2.4, qui n'est pas supportée par OpenShift Container Platform pour le moment.

Important

Pour les routes non passantes, le contrôleur d'entrée négocie sa connexion à l'application indépendamment de la connexion du client. Cela signifie qu'un client peut se connecter au contrôleur d'entrée et négocier HTTP/1.1, et que le contrôleur d'entrée peut ensuite se connecter à l'application, négocier HTTP/2, et transmettre la demande de la connexion HTTP/1.1 du client en utilisant la connexion HTTP/2 à l'application. Cela pose un problème si le client tente par la suite de faire passer sa connexion de HTTP/1.1 au protocole WebSocket, car le contrôleur d'entrée ne peut pas transmettre WebSocket à HTTP/2 et ne peut pas faire passer sa connexion HTTP/2 à WebSocket. Par conséquent, si vous avez une application destinée à accepter des connexions WebSocket, elle ne doit pas autoriser la négociation du protocole HTTP/2, sinon les clients ne parviendront pas à passer au protocole WebSocket.

Procédure

Activer HTTP/2 sur un seul contrôleur d'entrée.

Pour activer HTTP/2 sur un contrôleur d'entrée, entrez la commande oc annotate:

oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true

oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true

Copy to Clipboard

Toggle word wrap

Remplacer <ingresscontroller_name> par le nom du contrôleur d'entrée à annoter.

Activer HTTP/2 sur l'ensemble du cluster.

Pour activer HTTP/2 pour l'ensemble du cluster, entrez la commande oc annotate:

oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true

$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le YAML suivant pour ajouter l'annotation :

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
  annotations:
    ingress.operator.openshift.io/default-enable-http2: "true"

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
  annotations:
    ingress.operator.openshift.io/default-enable-http2: "true"

Copy to Clipboard

Toggle word wrap

7.8.15. Configuration du protocole PROXY pour un contrôleur d'entrée
Copier lien

Un administrateur de cluster peut configurer le protocole PROXY lorsqu'un contrôleur d'entrée utilise les types de stratégie de publication des points d'extrémité HostNetwork ou NodePortService. Le protocole PROXY permet à l'équilibreur de charge de conserver les adresses client d'origine pour les connexions que le contrôleur d'entrée reçoit. Les adresses client d'origine sont utiles pour la journalisation, le filtrage et l'injection d'en-têtes HTTP. Dans la configuration par défaut, les connexions que le contrôleur d'entrée reçoit ne contiennent que l'adresse source associée à l'équilibreur de charge.

Cette fonctionnalité n'est pas prise en charge dans les déploiements en nuage. Cette restriction s'explique par le fait que lorsque OpenShift Container Platform fonctionne sur une plateforme cloud et qu'un IngressController spécifie qu'un service d'équilibrage de charge doit être utilisé, l'opérateur d'ingestion configure le service d'équilibrage de charge et active le protocole PROXY en fonction de l'exigence de la plateforme en matière de préservation des adresses source.

Important

Vous devez configurer OpenShift Container Platform et l'équilibreur de charge externe pour qu'ils utilisent le protocole PROXY ou TCP.

Avertissement

Le protocole PROXY n'est pas pris en charge par le contrôleur d'entrée par défaut avec les clusters fournis par l'installateur sur des plates-formes non cloud qui utilisent un VIP d'entrée Keepalived.

Conditions préalables

Vous avez créé un contrôleur d'entrée.

Procédure

Modifiez la ressource Ingress Controller :

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

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

Copy to Clipboard

Toggle word wrap

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
  
  Copy to Clipboard Toggle word wrap
- 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
  
  Copy to Clipboard Toggle word wrap

7.8.16. Spécification d'un domaine de cluster alternatif à l'aide de l'option appsDomain
Copier lien

En tant qu'administrateur de cluster, vous pouvez spécifier une alternative au domaine de cluster par défaut pour les routes créées par l'utilisateur en configurant le champ appsDomain. Le champ appsDomain est un domaine optionnel pour OpenShift Container Platform à utiliser à la place du domaine par défaut, qui est spécifié dans le champ domain. Si vous spécifiez un domaine alternatif, il remplace le domaine de cluster par défaut afin de déterminer l'hôte par défaut pour une nouvelle route.

Par exemple, vous pouvez utiliser le domaine DNS de votre entreprise comme domaine par défaut pour les routes et les entrées des applications fonctionnant sur votre cluster.

Conditions préalables

You deployed an OpenShift Container Platform cluster.
Vous avez installé l'interface de ligne de commande oc.

Procédure

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
  Copy to Clipboard Toggle word wrap
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
  
  Copy to Clipboard Toggle word wrap
  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.

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.

Exposer l'itinéraire :

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

$ 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

$ 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

7.8.17. Conversion des en-têtes HTTP
Copier lien

HAProxy 2.2 met par défaut les noms d'en-tête HTTP en minuscules, par exemple en remplaçant Host: xyz.com par host: xyz.com. Si les applications existantes sont sensibles à la mise en majuscules des noms d'en-tête HTTP, utilisez le champ API spec.httpHeaders.headerNameCaseAdjustments du contrôleur d'entrée pour trouver une solution permettant d'accommoder les applications existantes jusqu'à ce qu'elles soient corrigées.

Important

Comme OpenShift Container Platform inclut HAProxy 2.2, assurez-vous d'ajouter la configuration nécessaire à l'aide de spec.httpHeaders.headerNameCaseAdjustments avant de procéder à la mise à niveau.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

En tant qu'administrateur de cluster, vous pouvez convertir le cas de l'en-tête HTTP en entrant la commande oc patch ou en définissant le champ HeaderNameCaseAdjustments dans le fichier YAML du contrôleur d'entrée.

Spécifiez un en-tête HTTP à mettre en majuscules en entrant la commande oc patch.

Entrez la commande oc patch pour remplacer l'en-tête HTTP host par Host:

oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'

$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'

Copy to Clipboard

Toggle word wrap

Annoter l'itinéraire de la demande :
```
oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true
```
```
$ oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true
```
Copy to Clipboard Toggle word wrap
Le contrôleur d'entrée ajuste ensuite l'en-tête de demande host comme spécifié.

Spécifiez les ajustements à l'aide du champ HeaderNameCaseAdjustments en configurant le fichier YAML du contrôleur d'entrée.

L'exemple suivant de contrôleur d'entrée YAML ajuste l'en-tête host à Host pour les requêtes HTTP/1 vers des itinéraires correctement annotés :

Exemple de contrôleur d'entrée YAML

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

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

Copy to Clipboard

Toggle word wrap

L'exemple de route suivant permet d'ajuster les cas de figure des en-têtes de réponse HTTP à l'aide de l'annotation haproxy.router.openshift.io/h1-adjust-case:

Exemple de route YAML

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/h1-adjust-case: true 
  name: my-application
  namespace: my-application
spec:
  to:
    kind: Service
    name: my-application

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/h1-adjust-case: true

1


  name: my-application
  namespace: my-application
spec:
  to:
    kind: Service
    name: my-application

Copy to Clipboard

Toggle word wrap

1: Fixer haproxy.router.openshift.io/h1-adjust-case à true (vrai).

7.8.18. Utilisation de la compression du routeur
Copier lien

Vous configurez le contrôleur d'entrée HAProxy pour spécifier globalement la compression du routeur pour des types MIME spécifiques. Vous pouvez utiliser la variable mimeTypes pour définir les formats des types MIME auxquels la compression est appliquée. Les types sont les suivants : application, image, message, multipart, texte, vidéo ou un type personnalisé précédé de "X-". Pour voir la notation complète des types et sous-types MIME, voir RFC1341.

Note

La mémoire allouée à la compression peut affecter le nombre maximal de connexions. En outre, la compression de tampons volumineux peut entraîner une certaine latence, comme c'est le cas pour les expressions rationnelles lourdes ou les longues listes d'expressions rationnelles.

Tous les types MIME ne bénéficient pas de la compression, mais HAProxy utilise tout de même des ressources pour essayer de les compresser si on le lui demande. En général, les formats de texte, tels que html, css et js, bénéficient de la compression, mais les formats déjà compressés, tels que les images, l'audio et la vidéo, bénéficient peu en échange du temps et des ressources consacrés à la compression.

Procédure

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

Utilisez la commande suivante pour modifier la ressource IngressController:

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

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

Copy to Clipboard

Toggle word wrap

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"
   ...

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

7.8.19. Personnalisation des pages de réponse au code d'erreur de HAProxy
Copier lien

En tant qu'administrateur de cluster, vous pouvez spécifier un code d'erreur personnalisé pour la page de réponse 503, 404 ou les deux pages d'erreur. Le routeur HAProxy sert une page d'erreur 503 lorsque le module d'application ne fonctionne pas ou une page d'erreur 404 lorsque l'URL demandée n'existe pas. Par exemple, si vous personnalisez la page de réponse au code d'erreur 503, la page est servie lorsque le module d'application n'est pas en cours d'exécution et la page de réponse HTTP au code d'erreur 404 par défaut est servie par le routeur HAProxy en cas d'itinéraire incorrect ou inexistant.

Les pages de réponse aux codes d'erreur personnalisés sont spécifiées dans une carte de configuration, puis patchées sur le contrôleur d'entrée. Les clés de la carte de configuration ont deux noms de fichier disponibles : error-page-503.http et error-page-404.http.

Les pages de réponse de code d'erreur HTTP personnalisées doivent respecter les directives de configuration de la page d'erreur HTTP de HAProxy. Voici un exemple de la page de réponse par défaut du code d'erreur http 503 du routeur HAProxy de OpenShift Container Platform. Vous pouvez utiliser le contenu par défaut comme modèle pour créer votre propre page personnalisée.

Par défaut, le routeur HAProxy ne sert qu'une page d'erreur 503 lorsque l'application n'est pas en cours d'exécution ou lorsque la route est incorrecte ou inexistante. Ce comportement par défaut est le même que le comportement sur OpenShift Container Platform 4.8 et antérieur. Si une carte de configuration pour la personnalisation d'une réponse de code d'erreur HTTP n'est pas fournie et que vous utilisez une page de réponse de code d'erreur HTTP personnalisée, le routeur sert une page de réponse de code d'erreur 404 ou 503 par défaut.

Note

Si vous utilisez la page de code d'erreur 503 par défaut d'OpenShift Container Platform comme modèle pour vos personnalisations, les en-têtes du fichier nécessitent un éditeur qui peut utiliser les fins de ligne CRLF.

Procédure

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
```
```
$ 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
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.
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
```
```
$ 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 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.
Afficher la copie :
```
oc get cm default-errorpages -n openshift-ingress
```
```
$ oc get cm default-errorpages -n openshift-ingress
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
NAME                       DATA   AGE
default-errorpages         2      25s  
```
```
NAME                       DATA   AGE
default-errorpages         2      25s  
```
1
Copy to Clipboard Toggle word wrap
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.
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
  Copy to Clipboard Toggle word wrap
- 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
  Copy to Clipboard Toggle word wrap

Vérification

Vérifiez votre code d'erreur personnalisé dans la réponse HTTP :

Créez un projet et une application de test :
```
oc new-project test-ingress
```
```
 $ oc new-project test-ingress
```
Copy to Clipboard Toggle word wrap
```
oc new-app django-psql-example
```
```
$ oc new-app django-psql-example
```
Copy to Clipboard Toggle word wrap
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>
  Copy to Clipboard Toggle word wrap
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>
  Copy to Clipboard Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

7.8.20. Définition du nombre maximum de connexions du contrôleur d'entrée
Copier lien

Un administrateur de cluster peut définir le nombre maximum de connexions simultanées pour les déploiements de routeurs OpenShift. Vous pouvez corriger un contrôleur d'entrée existant pour augmenter le nombre maximum de connexions.

Conditions préalables

La procédure suivante suppose que vous avez déjà créé un contrôleur d'entrée

Procédure

Mettez à jour le contrôleur d'entrée afin de modifier le nombre maximal de connexions pour HAProxy :
```
oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
```
```
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
```
Copy to Clipboard Toggle word wrap
Avertissement
Si la valeur de spec.tuningOptions.maxConnections est supérieure à la limite actuelle du système d'exploitation, le processus HAProxy ne démarrera pas. Voir le tableau de la section "Paramètres de configuration du contrôleur d'entrée" pour plus d'informations sur ce paramètre.

Chapitre 8. Ingress sharding dans OpenShift Container Platform
Copier lien

Dans OpenShift Container Platform, un Ingress Controller peut servir toutes les routes ou un sous-ensemble de routes. Par défaut, le contrôleur d'ingestion sert toutes les routes créées dans n'importe quel espace de noms du cluster. Vous pouvez ajouter des contrôleurs d'entrée supplémentaires à votre cluster pour optimiser le routage en créant shards, qui sont des sous-ensembles d'itinéraires basés sur des caractéristiques sélectionnées. Pour marquer un itinéraire comme membre d'une grappe, utilisez des étiquettes dans le champ de l'itinéraire ou de l'espace de noms metadata. Le contrôleur d'entrée utilise selectors, également connu sous le nom de selection expression, pour sélectionner un sous-ensemble d'itinéraires à partir de l'ensemble des itinéraires à desservir.

La répartition des entrées est utile lorsque vous souhaitez équilibrer la charge du trafic entrant entre plusieurs contrôleurs d'entrée, lorsque vous souhaitez isoler le trafic à acheminer vers un contrôleur d'entrée spécifique, ou pour toute une série d'autres raisons décrites dans la section suivante.

Par défaut, chaque route utilise le domaine par défaut du cluster. Toutefois, les itinéraires peuvent être configurés pour utiliser le domaine du routeur à la place. Pour plus d'informations, voir Création d'un itinéraire pour le sharding de contrôleur d'entrée.

8.1. Regroupement des contrôleurs d'entrée
Copier lien

Vous pouvez utiliser le partage d'entrée, également connu sous le nom de partage de routeur, pour distribuer un ensemble d'itinéraires sur plusieurs routeurs en ajoutant des étiquettes aux itinéraires, aux espaces de noms ou aux deux. Le contrôleur d'entrée utilise un ensemble correspondant de sélecteurs pour n'admettre que les itinéraires dotés d'une étiquette spécifique. Chaque groupe d'entrée comprend les itinéraires filtrés à l'aide d'une expression de sélection donnée.

En tant que principal mécanisme d'entrée du trafic dans la grappe, le contrôleur d'entrée peut être fortement sollicité. En tant qu'administrateur de la grappe, vous pouvez répartir les routes pour :

Équilibrer les contrôleurs d'entrée, ou routeurs, avec plusieurs itinéraires pour accélérer les réponses aux changements.
Attribuer à certains itinéraires des garanties de fiabilité différentes de celles des autres itinéraires.
Permettre à certains contrôleurs d'entrée de définir des politiques différentes.
Ne permettre qu'à des itinéraires spécifiques d'utiliser des fonctionnalités supplémentaires.
Exposer des itinéraires différents sur des adresses différentes afin que les utilisateurs internes et externes puissent voir des itinéraires différents, par exemple.
Transférer le trafic d'une version d'une application à une autre lors d'un déploiement bleu-vert.

Lorsque les contrôleurs d'entrée sont groupés, une route donnée est admise par zéro ou plusieurs contrôleurs d'entrée du groupe. L'état d'une route indique si un contrôleur d'entrée l'a admise ou non. Un contrôleur d'entrée n'admettra une route que si elle est unique à son groupe.

Un contrôleur d'entrée peut utiliser trois méthodes de répartition :

Ajout d'un sélecteur d'espace de noms au contrôleur d'ingestion, de sorte que tous les itinéraires d'un espace de noms dont les étiquettes correspondent au sélecteur d'espace de noms se trouvent dans la grappe d'ingestion.
Ajout d'un sélecteur d'itinéraires au contrôleur d'entrée, de sorte que tous les itinéraires dont les étiquettes correspondent au sélecteur d'itinéraires se trouvent dans le groupe d'entrée.
Ajout d'un sélecteur d'espace de noms et d'un sélecteur d'itinéraires au contrôleur d'ingestion, de sorte que les itinéraires dont les étiquettes correspondent au sélecteur d'itinéraires dans un espace de noms dont les étiquettes correspondent au sélecteur d'espace de noms se trouvent dans la grappe d'ingestion.

Avec la répartition, vous pouvez distribuer des sous-ensembles d'itinéraires sur plusieurs contrôleurs d'entrée. Ces sous-ensembles peuvent ne pas se chevaucher ( traditional sharding) ou se chevaucher ( overlapped sharding).

8.1.1. Exemple de partage traditionnel
Copier lien

Un contrôleur d'entrée finops-router est configuré avec le sélecteur d'étiquettes spec.namespaceSelector.matchLabels.name réglé sur finance et ops:

Exemple de définition YAML pour finops-router

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: finops-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name:
          - finance
          - ops

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: finops-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name:
          - finance
          - ops

Copy to Clipboard

Toggle word wrap

Un deuxième contrôleur d'entrée dev-router est configuré avec le sélecteur d'étiquettes spec.namespaceSelector.matchLabels.name réglé sur dev:

Exemple de définition YAML pour dev-router

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: dev-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name: dev

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: dev-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name: dev

Copy to Clipboard

Toggle word wrap

Si toutes les routes d'application sont dans des espaces de noms séparés, chacun étiqueté avec name:finance, name:ops, et name:dev respectivement, cette configuration distribue efficacement vos routes entre les deux contrôleurs d'entrée. Les routes de OpenShift Container Platform pour la console, l'authentification et d'autres objectifs ne doivent pas être gérées.

Dans le scénario ci-dessus, la répartition devient un cas particulier de partitionnement, sans que les sous-ensembles ne se chevauchent. Les routes sont réparties entre les routeurs.

Avertissement

Le contrôleur d'entrée default continue à servir toutes les routes à moins que les champs namespaceSelector ou routeSelector ne contiennent des routes à exclure. Consultez cette solution de la base de connaissances de Red Hat et la section "Sharding the default Ingress Controller" pour plus d'informations sur la manière d'exclure les itinéraires du contrôleur d'entrée par défaut.

8.1.2. Exemple de partage superposé
Copier lien

Outre finops-router et dev-router dans l'exemple ci-dessus, vous avez également devops-router, qui est configuré avec le sélecteur d'étiquettes spec.namespaceSelector.matchLabels.name défini sur dev et ops:

Exemple de définition YAML pour devops-router

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: devops-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name:
          - dev
          - ops

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: devops-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name:
          - dev
          - ops

Copy to Clipboard

Toggle word wrap

Les routes des espaces de noms intitulés name:dev et name:ops sont maintenant gérées par deux contrôleurs d'entrée différents. Avec cette configuration, les sous-ensembles d'itinéraires se chevauchent.

Le chevauchement de sous-ensembles d'itinéraires permet de créer des règles de routage plus complexes. Par exemple, vous pouvez détourner le trafic hautement prioritaire vers le site dédié finops-router tout en envoyant le trafic moins prioritaire vers devops-router.

8.1.3. Partage du contrôleur d'entrée par défaut
Copier lien

Après la création d'un nouveau shard d'ingestion, il se peut que des routes admises dans votre nouveau shard d'ingestion soient également admises par le contrôleur d'ingestion par défaut. En effet, le contrôleur d'entrée par défaut n'a pas de sélecteurs et admet tous les itinéraires par défaut.

Vous pouvez empêcher un contrôleur d'entrée de desservir des itinéraires avec des étiquettes spécifiques à l'aide de sélecteurs d'espace de noms ou de sélecteurs d'itinéraires. La procédure suivante empêche le contrôleur d'entrée par défaut de desservir les itinéraires finance, ops et dev, nouvellement partagés, à l'aide d'un sélecteur d'espace de noms. Cette procédure permet d'isoler davantage les groupes de serveurs d'entrée.

Important

Vous devez conserver toutes les routes d'administration d'OpenShift Container Platform sur le même Ingress Controller. Par conséquent, évitez d'ajouter des sélecteurs supplémentaires au contrôleur d'ingestion par défaut qui excluent ces routes essentielles.

Conditions préalables

You installed the OpenShift CLI (oc).
Vous êtes connecté en tant qu'administrateur de projet.

Procédure

Modifiez le contrôleur d'entrée par défaut en exécutant la commande suivante :
```
oc edit ingresscontroller -n openshift-ingress-operator default
```
```
$ oc edit ingresscontroller -n openshift-ingress-operator default
```
Copy to Clipboard Toggle word wrap

Modifiez le contrôleur d'entrée pour qu'il contienne une adresse namespaceSelector qui exclut les itinéraires portant l'une des étiquettes finance, ops et dev:

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
  namespaceSelector:
    matchExpressions:
    - key: type
      operator: NotIn
      values:
      - finance
      - ops
      - dev

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
  namespaceSelector:
    matchExpressions:
    - key: type
      operator: NotIn
      values:
      - finance
      - ops
      - dev

Copy to Clipboard

Toggle word wrap

Le contrôleur d'entrée par défaut ne desservira plus les espaces de noms intitulés name:finance, name:ops, et name:dev.

8.1.4. Sharding d'entrée et DNS
Copier lien

L'administrateur de la grappe est chargé de créer une entrée DNS distincte pour chaque routeur d'un projet. Un routeur ne transmettra pas de routes inconnues à un autre routeur.

Prenons l'exemple suivant :

Le routeur A se trouve sur l'hôte 192.168.0.5 et a des routes avec *.foo.com.
Le routeur B se trouve sur l'hôte 192.168.1.9 et a des routes avec *.example.com.

Des entrées DNS séparées doivent résoudre *.foo.com en nœud hébergeant le routeur A et *.example.com en nœud hébergeant le routeur B :

*.foo.com A IN 192.168.0.5
*.example.com A IN 192.168.1.9

8.1.5. Configuration de la répartition des contrôleurs d'entrée à l'aide d'étiquettes d'itinéraires
Copier lien

La répartition du contrôleur d'entrée à l'aide d'étiquettes d'itinéraires signifie que le contrôleur d'entrée dessert n'importe quel itinéraire dans n'importe quel espace de noms sélectionné par le sélecteur d'itinéraires.

Figure 8.1. Répartition des entrées à l'aide d'étiquettes d'itinéraires

A diagram showing multiple Ingress Controllers with different route selectors serving any route containing a label that matches a given route selector regardless of the namespace a route belongs to

La répartition des contrôleurs d'entrée est utile pour équilibrer la charge du trafic entrant entre un ensemble de contrôleurs d'entrée et pour isoler le trafic vers un contrôleur d'entrée spécifique. Par exemple, l'entreprise A s'adresse à un contrôleur d'entrée et l'entreprise B à un autre.

Procédure

Modifiez le fichier router-internal.yaml:

cat router-internal.yaml
apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: sharded
    namespace: openshift-ingress-operator
  spec:
    domain: <apps-sharded.basedomain.example.net>
    nodePlacement:
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/worker: ""
    routeSelector:
      matchLabels:
        type: sharded
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

# cat router-internal.yaml
apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: sharded
    namespace: openshift-ingress-operator
  spec:
    domain: <apps-sharded.basedomain.example.net>

1


    nodePlacement:
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/worker: ""
    routeSelector:
      matchLabels:
        type: sharded
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Copy to Clipboard

Toggle word wrap

1: Indiquez un domaine à utiliser par le contrôleur d'entrée. Ce domaine doit être différent du domaine par défaut du contrôleur d'entrée.

Appliquer le fichier du contrôleur d'entrée router-internal.yaml:
```
oc apply -f router-internal.yaml
```
```
# oc apply -f router-internal.yaml
```
Copy to Clipboard Toggle word wrap
Le contrôleur d'entrée sélectionne les routes dans n'importe quel espace de noms qui ont l'étiquette type: sharded.

Créez une nouvelle route en utilisant le domaine configuré dans le site router-internal.yaml:

oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net

oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net

Copy to Clipboard

Toggle word wrap

8.1.6. Configuration de la répartition des contrôleurs d'entrée à l'aide d'étiquettes d'espace de noms
Copier lien

La répartition du contrôleur d'entrée à l'aide d'étiquettes d'espace de noms signifie que le contrôleur d'entrée dessert n'importe quelle route dans n'importe quel espace de noms sélectionné par le sélecteur d'espace de noms.

Figure 8.2. La mise en commun à l'entrée à l'aide d'étiquettes d'espace de noms

A diagram showing multiple Ingress Controllers with different namespace selectors serving routes that belong to the namespace containing a label that matches a given namespace selector

La répartition des contrôleurs d'entrée est utile pour équilibrer la charge du trafic entrant entre un ensemble de contrôleurs d'entrée et pour isoler le trafic vers un contrôleur d'entrée spécifique. Par exemple, l'entreprise A s'adresse à un contrôleur d'entrée et l'entreprise B à un autre.

Procédure

Modifiez le fichier router-internal.yaml:

cat router-internal.yaml

# cat router-internal.yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: sharded
    namespace: openshift-ingress-operator
  spec:
    domain: <apps-sharded.basedomain.example.net> 
    nodePlacement:
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/worker: ""
    namespaceSelector:
      matchLabels:
        type: sharded
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: sharded
    namespace: openshift-ingress-operator
  spec:
    domain: <apps-sharded.basedomain.example.net>

1


    nodePlacement:
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/worker: ""
    namespaceSelector:
      matchLabels:
        type: sharded
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Copy to Clipboard

Toggle word wrap

1: Indiquez un domaine à utiliser par le contrôleur d'entrée. Ce domaine doit être différent du domaine par défaut du contrôleur d'entrée.

Appliquer le fichier du contrôleur d'entrée router-internal.yaml:
```
oc apply -f router-internal.yaml
```
```
# oc apply -f router-internal.yaml
```
Copy to Clipboard Toggle word wrap
Le contrôleur d'entrée sélectionne les itinéraires dans tout espace de noms sélectionné par le sélecteur d'espace de noms et portant l'étiquette type: sharded.

Créez une nouvelle route en utilisant le domaine configuré dans le site router-internal.yaml:

oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net

oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net

Copy to Clipboard

Toggle word wrap

8.2. Création d'une route pour le sharding du contrôleur d'entrée
Copier lien

Une route vous permet d'héberger votre application à une URL. Dans ce cas, le nom d'hôte n'est pas défini et la route utilise un sous-domaine à la place. Lorsque vous spécifiez un sous-domaine, vous utilisez automatiquement le domaine du contrôleur d'entrée qui expose l'itinéraire. Lorsqu'un itinéraire est exposé par plusieurs contrôleurs d'ingestion, l'itinéraire est hébergé sur plusieurs URL.

La procédure suivante décrit comment créer une route pour le sharding du contrôleur d'entrée, en utilisant l'application hello-openshift comme exemple.

La répartition des contrôleurs d'entrée est utile pour équilibrer la charge du trafic entrant entre un ensemble de contrôleurs d'entrée et pour isoler le trafic vers un contrôleur d'entrée spécifique. Par exemple, l'entreprise A s'adresse à un contrôleur d'entrée et l'entreprise B à un autre.

Conditions préalables

You installed the OpenShift CLI (oc).
Vous êtes connecté en tant qu'administrateur de projet.
Vous avez une application web qui expose un port et un point d'extrémité HTTP ou TLS qui écoute le trafic sur le port.
Vous avez configuré le contrôleur d'entrée pour le partage.

Procédure

Créez un projet appelé hello-openshift en exécutant la commande suivante :
```
oc new-project hello-openshift
```
```
$ oc new-project hello-openshift
```
Copy to Clipboard Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

Créez un service appelé hello-openshift en exécutant la commande suivante :
```
oc expose pod/hello-openshift
```
```
$ oc expose pod/hello-openshift
```
Copy to Clipboard Toggle word wrap
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 
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift 
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
```
```
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
```
Copy to Clipboard Toggle word wrap
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.
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
```
```
$ oc -n hello-openshift create -f hello-openshift-route.yaml
```
Copy to Clipboard Toggle word wrap

Vérification

Obtenez l'état de la route à l'aide de la commande suivante :

oc -n hello-openshift get routes/hello-openshift-edge -o yaml

$ oc -n hello-openshift get routes/hello-openshift-edge -o yaml

Copy to Clipboard

Toggle word wrap

La ressource Route qui en résulte devrait ressembler à ce qui suit :

Exemple de sortie

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
status:
  ingress:
  - host: hello-openshift.<apps-sharded.basedomain.example.net> 
    routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net> 
    routerName: sharded

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
status:
  ingress:
  - host: hello-openshift.<apps-sharded.basedomain.example.net>

1


    routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net>

2


    routerName: sharded

3

Copy to Clipboard

Toggle word wrap

1: Le nom d'hôte que le contrôleur d'entrée, ou le routeur, utilise pour exposer l'itinéraire. La valeur du champ host est automatiquement déterminée par le contrôleur d'entrée et utilise son domaine. Dans cet exemple, le domaine du contrôleur d'entrée est <apps-sharded.basedomain.example.net>.
2: Le nom d'hôte du contrôleur d'entrée.
3: Le nom du contrôleur d'entrée. Dans cet exemple, le contrôleur d'entrée porte le nom sharded.

Ressources complémentaires

Performances de base du contrôleur d'entrée (routeur)

Chapitre 9. Opérateur de pare-feu Ingress Node dans OpenShift Container Platform
Copier lien

L'opérateur de pare-feu du nœud d'entrée permet aux administrateurs de gérer les configurations de pare-feu au niveau du nœud.

9.1. Installation de l'opérateur de pare-feu du nœud d'entrée
Copier lien

En tant qu'administrateur de cluster, vous pouvez installer l'opérateur de pare-feu du nœud d'entrée à l'aide de la CLI d'OpenShift Container Platform ou de la console Web.

9.1.1. Installation de l'opérateur de pare-feu du nœud d'entrée à l'aide de la CLI
Copier lien

En tant qu'administrateur de cluster, vous pouvez installer l'Opérateur à l'aide de la CLI.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous disposez d'un compte avec des privilèges d'administrateur.

Procédure

Pour créer l'espace de noms openshift-ingress-node-firewall, entrez la commande suivante :

cat << EOF| oc create -f -
apiVersion: v1
kind: Namespace
metadata:
  labels:
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/enforce-version: v1.24
  name: openshift-ingress-node-firewall
EOF

$ cat << EOF| oc create -f -
apiVersion: v1
kind: Namespace
metadata:
  labels:
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/enforce-version: v1.24
  name: openshift-ingress-node-firewall
EOF

Copy to Clipboard

Toggle word wrap

Pour créer un CR OperatorGroup, entrez la commande suivante :

cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: ingress-node-firewall-operators
  namespace: openshift-ingress-node-firewall
EOF

$ cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: ingress-node-firewall-operators
  namespace: openshift-ingress-node-firewall
EOF

Copy to Clipboard

Toggle word wrap

S'abonner à l'opérateur de pare-feu du nœud d'entrée.

Pour créer un CR Subscription pour l'opérateur de pare-feu du nœud d'entrée, entrez la commande suivante :

cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: ingress-node-firewall-sub
  namespace: openshift-ingress-node-firewall
spec:
  name: ingress-node-firewall
  channel: stable
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

$ cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: ingress-node-firewall-sub
  namespace: openshift-ingress-node-firewall
spec:
  name: ingress-node-firewall
  channel: stable
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

Copy to Clipboard

Toggle word wrap

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

oc get ip -n openshift-ingress-node-firewall

$ oc get ip -n openshift-ingress-node-firewall

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME            CSV                                         APPROVAL    APPROVED
install-5cvnz   ingress-node-firewall.4.12.0-202211122336   Automatic   true

NAME            CSV                                         APPROVAL    APPROVED
install-5cvnz   ingress-node-firewall.4.12.0-202211122336   Automatic   true

Copy to Clipboard

Toggle word wrap

Pour vérifier la version de l'opérateur, entrez la commande suivante :

oc get csv -n openshift-ingress-node-firewall

$ oc get csv -n openshift-ingress-node-firewall

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                        DISPLAY                          VERSION               REPLACES                                    PHASE
ingress-node-firewall.4.12.0-202211122336   Ingress Node Firewall Operator   4.12.0-202211122336   ingress-node-firewall.4.12.0-202211102047   Succeeded

NAME                                        DISPLAY                          VERSION               REPLACES                                    PHASE
ingress-node-firewall.4.12.0-202211122336   Ingress Node Firewall Operator   4.12.0-202211122336   ingress-node-firewall.4.12.0-202211102047   Succeeded

Copy to Clipboard

Toggle word wrap

9.1.2. Installation de l'opérateur de pare-feu du nœud d'entrée à l'aide de la console web
Copier lien

En tant qu'administrateur de cluster, vous pouvez installer l'Opérateur à l'aide de la console web.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous disposez d'un compte avec des privilèges d'administrateur.

Procédure

Installer l'opérateur de pare-feu du nœud d'entrée :
1. Dans la console Web OpenShift Container Platform, cliquez sur Operators → OperatorHub.
2. Sélectionnez Ingress Node Firewall Operator dans la liste des opérateurs disponibles, puis cliquez sur Install.
3. Sur la page Install Operator, sous Installed Namespace, sélectionnez Operator recommended Namespace.
4. Cliquez sur Install.
Vérifiez que l'opérateur de pare-feu du nœud d'entrée a été installé avec succès :
1. Naviguez jusqu'à la page Operators → Installed Operators.
2. Assurez-vous que Ingress Node Firewall Operator est listé dans le projet openshift-ingress-node-firewall 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'a pas de Status de InstallSucceeded, dépanner en suivant les étapes suivantes :
  - Inspectez les onglets Operator Subscriptions et Install Plans pour vérifier qu'il n'y a pas de défaillances ou d'erreurs sous Status.
  - Naviguez vers la page Workloads → Pods et vérifiez les journaux pour les pods dans le projet openshift-ingress-node-firewall.
  - Vérifiez l'espace de noms du fichier YAML. Si l'annotation est manquante, vous pouvez ajouter l'annotation workload.openshift.io/allowed=management à l'espace de noms de l'opérateur à l'aide de la commande suivante :
    
    $ oc annotate ns/openshift-ingress-node-firewall workload.openshift.io/allowed=management
    
    Copy to Clipboard Toggle word wrap
    
    Note
    Pour les clusters OpenShift à nœud unique, l'espace de noms openshift-ingress-node-firewall nécessite l'annotation workload.openshift.io/allowed=management.

9.2. Opérateur du pare-feu du nœud d'entrée
Copier lien

L'opérateur de pare-feu de nœud d'entrée fournit des règles de pare-feu d'entrée au niveau d'un nœud en déployant l'ensemble de démons sur les nœuds que vous spécifiez et gérez dans les configurations de pare-feu. Pour déployer le jeu de démons, vous créez une ressource personnalisée (CR) IngressNodeFirewallConfig. L'opérateur applique la CR IngressNodeFirewallConfig pour créer l'ensemble de démons de pare-feu de nœuds d'entrée daemon, qui s'exécute sur tous les nœuds correspondant à la CR nodeSelector.

Vous configurez rules de la CR IngressNodeFirewall et les appliquez aux clusters en utilisant nodeSelector et en fixant les valeurs à "true".

Important

L'opérateur de pare-feu du nœud d'entrée ne prend en charge que les règles de pare-feu sans état.

Le paramètre des unités de transmission maximale (MTU) est de 4Kb (kilo-octets) dans OpenShift Container Platform 4.12.

Les contrôleurs d'interface réseau (NIC) qui ne prennent pas en charge les pilotes XDP natifs fonctionneront à des performances moindres.

9.3. Déploiement de l'opérateur de pare-feu du nœud d'entrée
Copier lien

Prérequis

L'opérateur de pare-feu du nœud d'entrée est installé.

Procédure

Pour déployer l'opérateur de pare-feu du nœud d'entrée, créez une ressource personnalisée IngressNodeFirewallConfig qui déploiera l'ensemble de démons de l'opérateur. Vous pouvez déployer un ou plusieurs CRD IngressNodeFirewall sur des nœuds en appliquant des règles de pare-feu.

Créez le site IngressNodeFirewallConfig à l'intérieur de l'espace de noms openshift-ingress-node-firewall nommé ingressnodefirewallconfig.
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
```
```
$ oc apply -f rule.yaml
```
Copy to Clipboard Toggle word wrap

9.3.1. Objet de configuration du pare-feu du nœud d'entrée
Copier lien

Les champs de l'objet de configuration Ingress Node Firewall sont décrits dans le tableau suivant :

Expand

Tableau 9.1. Objet de configuration du pare-feu du nœud d'entrée
Field	Type	Description
`metadata.name`	`string`	Le nom de l'objet CR. Le nom de l'objet règles de pare-feu doit être `ingressnodefirewallconfig`.
`metadata.namespace`	`string`	Espace de noms pour l'objet CR de l'opérateur du pare-feu d'entrée. Le CR `IngressNodeFirewallConfig` doit être créé dans l'espace de noms `openshift-ingress-node-firewall`.
`spec.nodeSelector`	`string`	Une contrainte de sélection de nœuds utilisée pour cibler les nœuds par le biais d'étiquettes de nœuds spécifiées. Par exemple : `spec: nodeSelector: node-role.kubernetes.io/worker: ""` Copy to Clipboard Toggle word wrap Note L'une des étiquettes utilisées dans `nodeSelector` doit correspondre à une étiquette sur les nœuds pour que l'ensemble de démons démarre. Par exemple, si les étiquettes de nœuds `node-role.kubernetes.io/worker` et `node-type.kubernetes.io/vm` sont appliquées à un nœud, au moins une étiquette doit être définie à l'aide de `nodeSelector` pour que le jeu de démons démarre.

Note

L'opérateur consomme le CR et crée un ensemble de démons de pare-feu de nœuds d'entrée sur tous les nœuds qui correspondent à nodeSelector.

Exemple de configuration de l'opérateur de pare-feu du nœud d'entrée

L'exemple suivant présente une configuration complète du pare-feu du nœud d'entrée :

Exemple d'objet de configuration du pare-feu du nœud d'entrée

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewallConfig
metadata:
  name: ingressnodefirewallconfig
  namespace: openshift-ingress-node-firewall
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewallConfig
metadata:
  name: ingressnodefirewallconfig
  namespace: openshift-ingress-node-firewall
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""

Copy to Clipboard

Toggle word wrap

Note

L'opérateur consomme le CR et crée un ensemble de démons de pare-feu de nœuds d'entrée sur tous les nœuds qui correspondent à nodeSelector.

9.3.2. Objet "règles de pare-feu" du nœud d'entrée
Copier lien

Les champs de l'objet Règles de pare-feu du nœud d'entrée sont décrits dans le tableau suivant :

Expand

Tableau 9.2. Objet "règles de pare-feu" du nœud d'entrée
Field	Type	Description
`metadata.name`	`string`	Le nom de l'objet CR.
`interfaces`	`array`	Les champs de cet objet spécifient les interfaces auxquelles appliquer les règles de pare-feu. Par exemple, `- en0` et `- en1`.
`nodeSelector`	`array`	Vous pouvez utiliser `nodeSelector` pour sélectionner les nœuds auxquels appliquer les règles de pare-feu. Définissez la valeur de vos étiquettes `nodeselector` à `true` pour appliquer la règle.
`ingress`	`object`	`ingress` vous permet de configurer les règles qui autorisent l'accès extérieur aux services de votre cluster.

Configuration de l'objet d'entrée

Les valeurs de l'objet ingress sont définies dans le tableau suivant :

Expand

Tableau 9.3. ingress objet
Field	Type	Description
`sourceCIDRs`	`array`	Permet de définir le bloc CIDR. Vous pouvez configurer plusieurs CIDR de différentes familles d'adresses. Note Des CIDR différents vous permettent d'utiliser la même règle d'ordre. S'il existe plusieurs objets `IngressNodeFirewall` pour les mêmes nœuds et interfaces avec des CIDR qui se chevauchent, le champ `order` indiquera la règle à appliquer en premier. Les règles sont appliquées par ordre croissant.
`rules`	`array`	Les objets du pare-feu d'entrée `rules.order` sont classés en commençant par `1` pour chaque `source.CIDR`, avec un maximum de 100 règles par CIDR. Les règles d'ordre inférieur sont exécutées en premier. `rules.protocolConfig.protocol` prend en charge les protocoles suivants : TCP, UDP, SCTP, ICMP et ICMPv6. Les règles ICMP et ICMPv6 peuvent correspondre à des types ou des codes ICMP et ICMPv6. Les règles TCP, UDP et SCTP peuvent correspondre à un seul port de destination ou à une série de ports au format `<start : end-1>`. Définissez `rules.action` sur `allow` pour appliquer la règle ou `deny` pour l'interdire. Note Les règles de pare-feu en entrée sont vérifiées à l'aide d'un webhook de vérification qui bloque toute configuration invalide. Le webhook de vérification vous empêche de bloquer les services critiques du cluster tels que le serveur API ou SSH.

Exemple d'objet de règles de pare-feu pour le nœud d'entrée

L'exemple suivant présente une configuration complète du pare-feu du nœud d'entrée :

Exemple de configuration du pare-feu du nœud d'entrée

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
  name: ingressnodefirewall
spec:
  interfaces:
  - eth0
  nodeSelector:
    matchLabels:
      <do_node_ingress_firewall>: 'true'
  ingress:
  - sourceCIDRs:
       - 172.16.0.0/12
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMP
        icmp:
          icmpType: 8 #ICMP Echo request
      action: Deny
    - order: 20
      protocolConfig:
        protocol: TCP
        tcp:
          ports: "8000-9000"
      action: Deny
  - sourceCIDRs:
       - fc00:f853:ccd:e793::0/64
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMPv6
        icmpv6:
          icmpType: 128 #ICMPV6 Echo request
      action: Deny

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
  name: ingressnodefirewall
spec:
  interfaces:
  - eth0
  nodeSelector:
    matchLabels:
      <do_node_ingress_firewall>: 'true'
  ingress:
  - sourceCIDRs:
       - 172.16.0.0/12
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMP
        icmp:
          icmpType: 8 #ICMP Echo request
      action: Deny
    - order: 20
      protocolConfig:
        protocol: TCP
        tcp:
          ports: "8000-9000"
      action: Deny
  - sourceCIDRs:
       - fc00:f853:ccd:e793::0/64
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMPv6
        icmpv6:
          icmpType: 128 #ICMPV6 Echo request
      action: Deny

Copy to Clipboard

Toggle word wrap

Exemple d'objet de règles de pare-feu de nœud d'entrée à confiance zéro

Les règles de pare-feu de nœud d'entrée à confiance zéro peuvent fournir une sécurité supplémentaire aux clusters à interfaces multiples. Par exemple, vous pouvez utiliser des règles de pare-feu de nœud d'entrée à confiance zéro pour supprimer tout le trafic sur une interface spécifique, à l'exception de SSH.

L'exemple suivant présente une configuration complète d'un ensemble de règles de pare-feu de nœud d'entrée à confiance zéro :

Important

Les utilisateurs doivent ajouter tous les ports que leur application utilisera à leur liste d'autorisations dans le cas suivant afin de garantir un fonctionnement correct.

Exemple de règles de pare-feu de nœud d'entrée à confiance zéro

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
 name: ingressnodefirewall-zero-trust
spec:
 interfaces:
 - eth1 
 nodeSelector:
   matchLabels:
     <do_node_ingress_firewall>: 'true'
 ingress:
 - sourceCIDRs:
      - 0.0.0.0/0 
   rules:
   - order: 10
     protocolConfig:
       protocol: TCP
       tcp:
         ports: 22
     action: Allow
   - order: 20
     action: Deny

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
 name: ingressnodefirewall-zero-trust
spec:
 interfaces:
 - eth1

1


 nodeSelector:
   matchLabels:
     <do_node_ingress_firewall>: 'true'
 ingress:
 - sourceCIDRs:
      - 0.0.0.0/0

2


   rules:
   - order: 10
     protocolConfig:
       protocol: TCP
       tcp:
         ports: 22
     action: Allow
   - order: 20
     action: Deny

3

Copy to Clipboard

Toggle word wrap

1: Cluster multi-interface
2: 0.0.0.0/0 défini pour correspondre à n'importe quel CIDR
3: action fixé à deny

9.4. Affichage des règles de l'opérateur de pare-feu du nœud d'entrée
Copier lien

Procédure

Exécutez la commande suivante pour afficher toutes les règles en vigueur :
```
oc get ingressnodefirewall
```
```
$ oc get ingressnodefirewall
```
Copy to Clipboard Toggle word wrap
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
```
```
$ oc get <resource> <name> -o yaml
```
Copy to Clipboard Toggle word wrap

9.5. Dépannage de l'opérateur de pare-feu du nœud d'entrée
Copier lien

Exécutez la commande suivante pour répertorier les définitions de ressources personnalisées (CRD) installées sur le pare-feu du nœud d'entrée :

oc get crds | grep ingressnodefirewall

$ oc get crds | grep ingressnodefirewall

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
ingressnodefirewallconfigs.ingressnodefirewall.openshift.io       2022-08-25T10:03:01Z
ingressnodefirewallnodestates.ingressnodefirewall.openshift.io    2022-08-25T10:03:00Z
ingressnodefirewalls.ingressnodefirewall.openshift.io             2022-08-25T10:03:00Z

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
ingressnodefirewallconfigs.ingressnodefirewall.openshift.io       2022-08-25T10:03:01Z
ingressnodefirewallnodestates.ingressnodefirewall.openshift.io    2022-08-25T10:03:00Z
ingressnodefirewalls.ingressnodefirewall.openshift.io             2022-08-25T10:03:00Z

Copy to Clipboard

Toggle word wrap

Exécutez la commande suivante pour afficher l'état de l'opérateur de pare-feu du nœud d'entrée :

oc get pods -n openshift-ingress-node-firewall

$ oc get pods -n openshift-ingress-node-firewall

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                       READY  STATUS         RESTARTS  AGE
ingress-node-firewall-controller-manager   2/2    Running        0         5d21h
ingress-node-firewall-daemon-pqx56         3/3    Running        0         5d21h

NAME                                       READY  STATUS         RESTARTS  AGE
ingress-node-firewall-controller-manager   2/2    Running        0         5d21h
ingress-node-firewall-daemon-pqx56         3/3    Running        0         5d21h

Copy to Clipboard

Toggle word wrap

Les champs suivants fournissent des informations sur l'état de l'opérateur : READY, STATUS, AGE, et RESTARTS. Le champ STATUS est Running lorsque l'opérateur de pare-feu du nœud d'entrée déploie un ensemble de démons sur les nœuds attribués.

Exécutez la commande suivante pour collecter tous les journaux des nœuds de pare-feu entrants :
```
oc adm must-gather – gather_ingress_node_firewall
```
```
$ oc adm must-gather – gather_ingress_node_firewall
```
Copy to Clipboard Toggle word wrap
Les journaux sont disponibles dans le rapport du nœud sos contenant les sorties eBPF bpftool à l'adresse /sos_commands/ebpf. Ces rapports comprennent les tables de consultation utilisées ou mises à jour lorsque le pare-feu d'entrée XDP traite les paquets, met à jour les statistiques et émet des événements.

Chapitre 10. Configuration d'un contrôleur d'entrée pour la gestion manuelle du DNS
Copier lien

En tant qu'administrateur de cluster, lorsque vous créez un contrôleur d'entrée, l'opérateur gère automatiquement les enregistrements DNS. Cela présente certaines limites lorsque la zone DNS requise est différente de la zone DNS du cluster ou lorsque la zone DNS est hébergée en dehors du fournisseur de cloud.

En tant qu'administrateur de cluster, vous pouvez configurer un contrôleur d'entrée pour qu'il arrête la gestion automatique du DNS et démarre la gestion manuelle du DNS. Définissez dnsManagementPolicy pour spécifier quand il doit être géré automatiquement ou manuellement.

Lorsque vous modifiez un contrôleur d'entrée de Managed à Unmanaged, l'opérateur ne nettoie pas l'ancien enregistrement DNS wildcard provisionné sur le nuage. Lorsque vous modifiez un contrôleur d'entrée de Unmanaged à Managed, l'opérateur tente de créer l'enregistrement DNS sur le fournisseur de cloud s'il n'existe pas ou met à jour l'enregistrement DNS s'il existe déjà.

Important

Lorsque vous remplacez dnsManagementPolicy par unmanaged, vous devez gérer manuellement le cycle de vie de l'enregistrement DNS générique sur le fournisseur de services en nuage.

10.1. Managed Politique de gestion du DNS
Copier lien

La politique de gestion DNS de Managed pour les contrôleurs d'entrée garantit que le cycle de vie de l'enregistrement DNS sauvage sur le fournisseur d'informatique en nuage est automatiquement géré par l'opérateur.

10.2. Unmanaged Politique de gestion du DNS
Copier lien

La politique de gestion DNS de Unmanaged pour les contrôleurs d'entrée garantit que le cycle de vie de l'enregistrement DNS wildcard sur le fournisseur de cloud n'est pas géré automatiquement, mais qu'il relève de la responsabilité de l'administrateur du cluster.

Note

Sur la plateforme cloud AWS, si le domaine du contrôleur d'entrée ne correspond pas à dnsConfig.Spec.BaseDomain, la politique de gestion DNS est automatiquement définie sur Unmanaged.

10.3. Création d'un contrôleur d'entrée personnalisé avec la politique de gestion DNS Unmanaged
Copier lien

En tant qu'administrateur de cluster, vous pouvez créer un nouveau contrôleur d'entrée personnalisé avec la politique de gestion DNS Unmanaged.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

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> 
spec:
  domain: <domain> 
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External 
      dnsManagementPolicy: Unmanaged 
```
```
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
Copy to Clipboard Toggle word wrap
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.
Enregistrez le fichier pour appliquer les modifications.
```
oc apply -f <name>.yaml 
```
```
oc apply -f <name>.yaml 
```
1
Copy to Clipboard Toggle word wrap

10.4. Modification d'un contrôleur d'entrée existant
Copier lien

En tant qu'administrateur de cluster, vous pouvez modifier un contrôleur d'entrée existant pour gérer manuellement le cycle de vie des enregistrements DNS.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

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}"}}}}'

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}"}}}}'

Copy to Clipboard

Toggle word wrap

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

Chapitre 11. Configuration de la stratégie de publication des points d'extrémité du contrôleur d'entrée
Copier lien

11.1. Stratégie de publication des points d'extrémité du contrôleur d'entrée
Copier lien

NodePortService endpoint publishing strategy

La stratégie de publication des points d'extrémité NodePortService publie le contrôleur d'ingestion à l'aide d'un service NodePort de Kubernetes.

Dans cette configuration, le déploiement du contrôleur d'entrée utilise un réseau de conteneurs. Un site NodePortService est créé pour publier le déploiement. Les ports de nœuds spécifiques sont alloués dynamiquement par OpenShift Container Platform ; toutefois, pour prendre en charge les allocations de ports statiques, les modifications apportées au champ node port du site NodePortService géré sont conservées.

Figure 11.1. Diagramme de NodePortService

OpenShift Container Platform Ingress NodePort endpoint publishing strategy

Le graphique précédent illustre les concepts suivants relatifs à la stratégie de publication des points d'extrémité Ingress NodePort d'OpenShift Container Platform :

Tous les nœuds disponibles dans la grappe ont leur propre adresse IP, accessible de l'extérieur. Le service fonctionnant dans la grappe est lié à l'unique NodePort de tous les nœuds.
Lorsque le client se connecte à un nœud en panne, par exemple en connectant l'adresse IP 10.0.128.4 dans le graphique, le port du nœud connecte directement le client à un nœud disponible qui exécute le service. Dans ce scénario, aucun équilibrage de charge n'est nécessaire. Comme le montre l'image, l'adresse 10.0.128.4 est hors service et une autre adresse IP doit être utilisée à la place.

Note

L'opérateur d'entrée ignore toute mise à jour des champs .spec.ports[].nodePort du service.

Par défaut, les ports sont attribués automatiquement et vous pouvez accéder aux attributions de ports pour les intégrations. Cependant, il est parfois nécessaire d'allouer des ports statiques pour s'intégrer à l'infrastructure existante, qui peut ne pas être facilement reconfigurée en réponse aux ports dynamiques. Pour réaliser des intégrations avec des ports de nœuds statiques, vous pouvez mettre à jour la ressource de service géré directement.

Pour plus d'informations, consultez la documentation sur les services Kubernetes à l'adresse NodePort.

HostNetwork endpoint publishing strategy

La stratégie de publication des points d'extrémité HostNetwork publie le contrôleur d'entrée sur les ports des nœuds où le contrôleur d'entrée est déployé.

Un contrôleur d'entrée doté de la stratégie de publication de points finaux HostNetwork ne peut avoir qu'une seule réplique de pod par nœud. Si vous voulez des répliques n, vous devez utiliser au moins des nœuds n où ces répliques peuvent être planifiées. Étant donné que chaque réplique de pod demande les ports 80 et 443 sur l'hôte du nœud où elle est planifiée, une réplique ne peut pas être planifiée sur un nœud si un autre pod sur le même nœud utilise ces ports.

11.1.1. Configuration de l'étendue de la publication du contrôleur d'entrée sur Interne
Copier lien

Lorsqu'un administrateur de cluster installe un nouveau cluster sans spécifier qu'il s'agit d'un cluster privé, le contrôleur d'entrée par défaut est créé avec un scope défini sur External. Les administrateurs de clusters peuvent modifier un contrôleur d'entrée à portée External en Internal.

Conditions préalables

Vous avez installé le CLI oc.

Procédure

Pour modifier un contrôleur d'entrée à portée de External en Internal, entrez la commande suivante :

oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'

$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'

Copy to Clipboard

Toggle word wrap

Pour vérifier l'état du contrôleur d'entrée, entrez la commande suivante :
```
oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
```
```
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
```
Copy to Clipboard Toggle word wrap
- La condition d'état Progressing indique si vous devez prendre d'autres mesures. Par exemple, la condition d'état peut indiquer que vous devez supprimer le service en entrant la commande suivante :
  $ oc -n openshift-ingress delete services/router-default
  Copy to Clipboard Toggle word wrap
  Si vous supprimez le service, l'opérateur d'entrée le recrée en tant que Internal.

11.1.2. Configuration de l'étendue de la publication du point d'extrémité du contrôleur d'entrée sur Externe
Copier lien

Lorsqu'un administrateur de cluster installe un nouveau cluster sans spécifier qu'il s'agit d'un cluster privé, le contrôleur d'entrée par défaut est créé avec une adresse scope définie sur External.

La portée du contrôleur d'entrée peut être configurée pour être Internal pendant l'installation ou après, et les administrateurs de clusters peuvent changer un contrôleur d'entrée Internal en External.

Important

Sur certaines plateformes, il est nécessaire de supprimer et de recréer le service.

La modification de l'étendue peut perturber le trafic Ingress, potentiellement pendant plusieurs minutes. Cela s'applique aux plateformes où il est nécessaire de supprimer et de recréer le service, car la procédure peut amener OpenShift Container Platform à déprovisionner l'équilibreur de charge du service existant, à en provisionner un nouveau et à mettre à jour le DNS.

Conditions préalables

Vous avez installé le CLI oc.

Procédure

Pour modifier un contrôleur d'entrée à portée de Internal en External, entrez la commande suivante :

oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'

$ oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'

Copy to Clipboard

Toggle word wrap

Pour vérifier l'état du contrôleur d'entrée, entrez la commande suivante :
```
oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
```
```
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
```
Copy to Clipboard Toggle word wrap
- La condition d'état Progressing indique si vous devez prendre d'autres mesures. Par exemple, la condition d'état peut indiquer que vous devez supprimer le service en entrant la commande suivante :
  $ oc -n openshift-ingress delete services/router-default
  Copy to Clipboard Toggle word wrap
  Si vous supprimez le service, l'opérateur d'entrée le recrée en tant que External.

Chapitre 12. Vérification de la connectivité à un point d'extrémité
Copier lien

L'opérateur de réseau de cluster (CNO) exécute un contrôleur, le contrôleur de contrôle de connectivité, qui effectue un contrôle de l'état des connexions entre les ressources de votre cluster. En examinant les résultats des contrôles de santé, vous pouvez diagnostiquer les problèmes de connexion ou éliminer la connectivité réseau comme cause d'un problème que vous étudiez.

12.1. Vérification de l'état des connexions
Copier lien

Pour vérifier que les ressources de la grappe sont accessibles, une connexion TCP est établie avec chacun des services API de grappe suivants :

Service de serveur API Kubernetes
Points d'extrémité du serveur API Kubernetes
Service de serveur API OpenShift
Points d'extrémité du serveur API OpenShift
Équilibreurs de charge

Pour vérifier que les services et les points de terminaison des services sont accessibles sur chaque nœud de la grappe, une connexion TCP est établie avec chacune des cibles suivantes :

Service cible de bilan de santé
Points finaux cibles du bilan de santé

12.2. Mise en œuvre des bilans de santé des connexions
Copier lien

Le contrôleur de vérification de la connectivité orchestre les vérifications de connexion dans votre cluster. Les résultats des tests de connexion sont stockés dans les objets PodNetworkConnectivity de l'espace de noms openshift-network-diagnostics. Les tests de connexion sont effectués en parallèle toutes les minutes.

L'opérateur de réseau de grappe (CNO) déploie plusieurs ressources dans la grappe pour envoyer et recevoir des contrôles de santé de la connectivité :

Bilan de santé source: Ce programme se déploie dans un seul ensemble de répliques de pods géré par un objet Deployment. Le programme consomme des objets PodNetworkConnectivity et se connecte au site spec.targetEndpoint spécifié dans chaque objet.
Objectif du bilan de santé: Un module déployé dans le cadre d'un ensemble de démons sur chaque nœud du cluster. Ce module est à l'écoute des contrôles de santé entrants. La présence de ce module sur chaque nœud permet de tester la connectivité de chaque nœud.

12.3. Champs de l'objet PodNetworkConnectivityCheck
Copier lien

Les champs de l'objet PodNetworkConnectivityCheck sont décrits dans les tableaux suivants.

Expand

Tableau 12.1. Champs de l'objet PodNetworkConnectivityCheck
Field	Type	Description
`metadata.name`	`string`	Le nom de l'objet au format suivant : `<source>-to-<target>`. La destination décrite par `<target>` comprend l'une des chaînes suivantes : `load-balancer-api-external` `load-balancer-api-internal` `kubernetes-apiserver-endpoint` `kubernetes-apiserver-service-cluster` `network-check-target` `openshift-apiserver-endpoint` `openshift-apiserver-service-cluster`
`metadata.namespace`	`string`	L'espace de noms auquel l'objet est associé. Cette valeur est toujours `openshift-network-diagnostics`.
`spec.sourcePod`	`string`	Le nom du pod d'où provient le contrôle de connexion, par exemple `network-check-source-596b4c6566-rgh92`.
`spec.targetEndpoint`	`string`	La cible de la vérification de la connexion, telle que `api.devcluster.example.com:6443`.
`spec.tlsClientCert`	`object`	Configuration du certificat TLS à utiliser.
`spec.tlsClientCert.name`	`string`	Le nom du certificat TLS utilisé, le cas échéant. La valeur par défaut est une chaîne vide.
`status`	`object`	Un objet représentant l'état du test de connexion et les journaux des succès et échecs récents de la connexion.
`status.conditions`	`array`	Le dernier état de la vérification de la connexion et tous les états précédents.
`status.failures`	`array`	Journaux des tests de connexion pour les tentatives infructueuses.
`status.outages`	`array`	Connecter les journaux de tests couvrant les périodes de pannes éventuelles.
`status.successes`	`array`	Journaux de tests de connexion pour les tentatives réussies.

Le tableau suivant décrit les champs des objets du tableau status.conditions:

Expand

Tableau 12.2. statut.conditions
Field	Type	Description
`lastTransitionTime`	`string`	Moment où l'état de la connexion est passé d'un état à un autre.
`message`	`string`	Les détails de la dernière transition dans un format lisible par l'homme.
`reason`	`string`	Le dernier état de la transition dans un format lisible par machine.
`status`	`string`	L'état de la condition.
`type`	`string`	Le type d'affection.

Le tableau suivant décrit les champs des objets du tableau status.conditions:

Expand

Tableau 12.3. statut.pannes
Field	Type	Description
`end`	`string`	Date à laquelle l'échec de la connexion a été résolu.
`endLogs`	`array`	Entrées du journal de connexion, y compris l'entrée du journal relative à la fin réussie de la panne.
`message`	`string`	Un résumé des détails de la panne dans un format lisible par l'homme.
`start`	`string`	Date à laquelle l'échec de la connexion a été détecté pour la première fois.
`startLogs`	`array`	Entrées du journal de connexion, y compris l'échec initial.

Champs du journal des connexions

Les champs d'une entrée du journal des connexions sont décrits dans le tableau suivant. L'objet est utilisé dans les champs suivants :

status.failures[]
status.successes[]
status.outages[].startLogs[]
status.outages[].endLogs[]

Expand

Tableau 12.4. Objet du journal des connexions
Field	Type	Description
`latency`	`string`	Enregistre la durée de l'action.
`message`	`string`	Fournit l'état dans un format lisible par l'homme.
`reason`	`string`	Fournit la raison de l'état dans un format lisible par la machine. La valeur est l'une des suivantes : `TCPConnect`, `TCPConnectError`, `DNSResolve`, `DNSError`.
`success`	`boolean`	Indique si l'entrée du journal est un succès ou un échec.
`time`	`string`	Heure de début de la vérification de la connexion.

12.4. Vérification de la connectivité réseau d'un terminal
Copier lien

En tant qu'administrateur de cluster, vous pouvez vérifier la connectivité d'un point d'extrémité, tel qu'un serveur API, un équilibreur de charge, un service ou un pod.

Conditions préalables

Installez le CLI OpenShift (oc).
Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

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

oc get podnetworkconnectivitycheck -n openshift-network-diagnostics

$ oc get podnetworkconnectivitycheck -n openshift-network-diagnostics

Copy to Clipboard

Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

Consulter les journaux des tests de connexion :

À 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é.

Pour visualiser l'objet, entrez la commande suivante :

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

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

Copy to Clipboard

Toggle word wrap

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"

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"

Copy to Clipboard

Toggle word wrap

Chapitre 13. Modification du MTU pour le réseau de la grappe
Copier lien

En tant qu'administrateur de grappe, vous pouvez modifier le MTU du réseau de la grappe après l'installation de la grappe. Ce changement est perturbant car les nœuds du cluster doivent être redémarrés pour finaliser le changement de MTU. Vous ne pouvez modifier le MTU que pour les clusters utilisant les plugins réseau OVN-Kubernetes ou OpenShift SDN.

13.1. À propos du MTU du cluster
Copier lien

Lors de l'installation, l'unité de transmission maximale (MTU) du réseau de la grappe est détectée automatiquement sur la base du MTU de l'interface réseau primaire des nœuds de la grappe. Normalement, il n'est pas nécessaire de remplacer le MTU détecté.

Il est possible que vous souhaitiez modifier le MTU du réseau de la grappe pour plusieurs raisons :

Le MTU détecté lors de l'installation du cluster n'est pas correct pour votre infrastructure
L'infrastructure de votre cluster nécessite désormais un MTU différent, par exemple suite à l'ajout de nœuds nécessitant un MTU différent pour des performances optimales

Vous pouvez modifier le MTU du cluster uniquement pour les plugins de réseau de cluster OVN-Kubernetes et OpenShift SDN.

13.1.1. Considérations relatives à l'interruption de service
Copier lien

Lorsque vous initiez un changement de MTU sur votre cluster, les effets suivants peuvent avoir un impact sur la disponibilité du service :

Au moins deux redémarrages en continu sont nécessaires pour achever la migration vers un nouveau MTU. Pendant cette période, certains nœuds ne sont pas disponibles car ils redémarrent.
Les applications spécifiques déployées sur le cluster avec des intervalles de temporisation plus courts que l'intervalle de temporisation TCP absolu peuvent subir des perturbations pendant le changement de MTU.

13.1.2. Sélection de la valeur MTU
Copier lien

Lorsque vous planifiez votre migration MTU, il y a deux valeurs MTU liées mais distinctes à prendre en compte.

Hardware MTU: Cette valeur MTU est définie en fonction des spécificités de votre infrastructure réseau.
Cluster network MTU: Cette valeur MTU est toujours inférieure à la valeur MTU de votre matériel pour tenir compte de l'overlay du réseau cluster. L'overhead spécifique est déterminé par votre plugin réseau :
- OVN-Kubernetes: 100 octets
- OpenShift SDN: 50 octets

Si votre cluster requiert des valeurs MTU différentes pour les différents nœuds, vous devez soustraire la valeur overhead de votre plugin réseau de la valeur MTU la plus basse utilisée par n'importe quel nœud de votre cluster. Par exemple, si certains nœuds de votre grappe ont un MTU de 9001, et d'autres de 1500, vous devez fixer cette valeur à 1400.

13.1.3. Comment fonctionne le processus de migration
Copier lien

Le tableau suivant résume le processus de migration en distinguant les étapes du processus initiées par l'utilisateur et les actions que la migration exécute en réponse.

Expand

Tableau 13.1. Migration en direct du MTU du cluster
Étapes initiées par l'utilisateur	Activité OpenShift Container Platform
Définissez les valeurs suivantes dans la configuration de l'opérateur de réseau de cluster : `spec.migration.mtu.machine.to` `spec.migration.mtu.network.from` `spec.migration.mtu.network.to`	Cluster Network Operator (CNO): Confirme que chaque champ a une valeur valide. Le site `mtu.machine.to` doit être défini sur le nouveau MTU du matériel ou sur le MTU actuel du matériel si le MTU du matériel ne change pas. Cette valeur est transitoire et est utilisée dans le cadre du processus de migration. Par ailleurs, si vous spécifiez un MTU matériel différent de votre MTU matériel actuel, vous devez configurer manuellement le MTU pour qu'il persiste par d'autres moyens, tels qu'une configuration de machine, un paramètre DHCP ou une ligne de commande du noyau Linux. Le champ `mtu.network.from` doit être égal au champ `network.status.clusterNetworkMTU`, qui est le MTU actuel du réseau cluster. Le champ `mtu.network.to` doit être défini sur le MTU du réseau du cluster cible et doit être inférieur au MTU matériel pour permettre l'overlay du plugin réseau. Pour OVN-Kubernetes, l'overhead est de `100` bytes et pour OpenShift SDN, l'overhead est de `50` bytes. Si les valeurs fournies sont valides, le CNO écrit une nouvelle configuration temporaire avec le MTU pour le réseau cluster fixé à la valeur du champ `mtu.network.to`. Machine Config Operator (MCO): Effectue un redémarrage progressif de chaque nœud de la grappe.
Reconfigurez le MTU de l'interface réseau principale pour les nœuds de la grappe. Pour ce faire, vous pouvez utiliser différentes méthodes, notamment Déploiement d'un nouveau profil de connexion NetworkManager avec changement de MTU Modification du MTU par le biais d'un serveur DHCP Modification du MTU par les paramètres de démarrage	N/A
Définissez la valeur `mtu` dans la configuration CNO pour le plugin réseau et définissez `spec.migration` à `null`.	Machine Config Operator (MCO): Effectue un redémarrage progressif de chaque nœud du cluster avec la nouvelle configuration MTU.

13.2. Modifier le MTU du cluster
Copier lien

En tant qu'administrateur de cluster, vous pouvez modifier l'unité de transmission maximale (MTU) de votre cluster. La migration est perturbatrice et les nœuds de votre cluster peuvent être temporairement indisponibles pendant la mise à jour du MTU.

La procédure suivante décrit comment modifier le MTU de la grappe en utilisant les configurations de machine, le DHCP ou une ISO. Si vous utilisez l'approche DHCP ou ISO, vous devez vous référer aux artefacts de configuration que vous avez conservés après l'installation de votre cluster pour compléter la procédure.

Conditions préalables

You installed the OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
Vous avez identifié le MTU cible pour votre cluster. Le MTU correct varie en fonction du plugin réseau utilisé par votre cluster :
- OVN-Kubernetes: Le MTU du cluster doit être défini à 100 de moins que la valeur MTU matérielle la plus basse de votre cluster.
- OpenShift SDN: Le MTU du cluster doit être défini à 50 de moins que la valeur MTU matérielle la plus basse de votre cluster.

Procédure

Pour augmenter ou diminuer le MTU pour le réseau cluster, suivez la procédure suivante.

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

oc describe network.config cluster

$ oc describe network.config cluster

Copy to Clipboard

Toggle word wrap

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
...

...
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
...

Copy to Clipboard

Toggle word wrap

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>
  Copy to Clipboard Toggle word wrap
  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 }'
    
    Copy to Clipboard Toggle word wrap
    
    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
    
    Copy to Clipboard Toggle word wrap
    
    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>
    
    Copy to Clipboard Toggle word wrap
    
    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 :
    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
    
    Copy to Clipboard Toggle word wrap
    
    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.
    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
    
    Copy to Clipboard Toggle word wrap
    
    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.
    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
    
    Copy to Clipboard Toggle word wrap

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> } } } } }'

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

Copy to Clipboard

Toggle word wrap

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} } } } }'

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

Copy to Clipboard

Toggle word wrap

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
```
```
$ oc get mcp
```
Copy to Clipboard Toggle word wrap
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.
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"
  Copy to Clipboard Toggle word wrap
  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
  
  Copy to Clipboard Toggle word wrap
  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
  Copy to Clipboard Toggle word wrap
  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
  Copy to Clipboard Toggle word wrap
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
  Copy to Clipboard Toggle word wrap
- 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.
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
```
```
$ oc get mcp
```
Copy to Clipboard Toggle word wrap
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.
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"
  Copy to Clipboard Toggle word wrap
  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
  
  Copy to Clipboard Toggle word wrap
  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 :
  Copy to Clipboard Toggle word wrap
  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.

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> }}}}'

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

Copy to Clipboard

Toggle word wrap

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> }}}}'

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

Copy to Clipboard

Toggle word wrap

où :

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

Vérification

Vous pouvez vérifier qu'un nœud de votre cluster utilise un MTU que vous avez spécifié dans la procédure précédente.

Pour obtenir le MTU actuel du réseau de la grappe, entrez la commande suivante :
```
oc describe network.config cluster
```
```
$ oc describe network.config cluster
```
Copy to Clipboard Toggle word wrap
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
  Copy to Clipboard Toggle word wrap
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>
  Copy to Clipboard Toggle word wrap
  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
  
  Copy to Clipboard Toggle word wrap

Chapitre 14. Configuration de la plage de service du port de nœud
Copier lien

En tant qu'administrateur de grappe, vous pouvez étendre la plage de ports de nœuds disponibles. Si votre grappe utilise un grand nombre de ports de nœuds, vous devrez peut-être augmenter le nombre de ports disponibles.

La plage de ports par défaut est 30000-32767. Vous ne pouvez jamais réduire la plage de ports, même si vous l'étendez d'abord au-delà de la plage par défaut.

14.1. Conditions préalables
Copier lien

Votre infrastructure de cluster doit autoriser l'accès aux ports que vous spécifiez dans la plage étendue. Par exemple, si vous étendez la plage de ports du nœud à 30000-32900, la plage de ports inclusive de 32768-32900 doit être autorisée par votre pare-feu ou votre configuration de filtrage de paquets.

14.2. Extension de la plage de ports du nœud
Copier lien

Vous pouvez étendre la plage de ports du nœud pour le cluster.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous au cluster avec un utilisateur disposant des privilèges cluster-admin.

Procédure

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>" }
  }'

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

Copy to Clipboard

Toggle word wrap

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>"

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

Copy to Clipboard

Toggle word wrap

Exemple de sortie

network.config.openshift.io/cluster patched

network.config.openshift.io/cluster patched

Copy to Clipboard

Toggle word wrap

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:]]+"]'

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

Copy to Clipboard

Toggle word wrap

Exemple de sortie

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

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

Copy to Clipboard

Toggle word wrap

Chapitre 15. Configuration du basculement IP
Copier lien

Cette rubrique décrit la configuration du basculement IP pour les pods et les services sur votre cluster OpenShift Container Platform.

Le basculement IP gère un pool d'adresses IP virtuelles (VIP) sur un ensemble de nœuds. Chaque adresse VIP de l'ensemble est desservie par un nœud sélectionné dans l'ensemble. Tant qu'un seul nœud est disponible, les VIP sont desservis. Il n'existe aucun moyen de répartir explicitement les adresses VIP entre les nœuds, de sorte qu'il peut y avoir des nœuds sans adresses VIP et d'autres nœuds avec de nombreuses adresses VIP. S'il n'y a qu'un seul nœud, tous les VIP s'y trouvent.

Note

Les VIP doivent être routables depuis l'extérieur du cluster.

Le basculement IP surveille un port sur chaque VIP afin de déterminer si le port est accessible sur le nœud. Si le port n'est pas accessible, le VIP n'est pas affecté au nœud. Si le port est défini sur 0, cette vérification est supprimée. Le script de contrôle effectue les tests nécessaires.

Le basculement IP utilise Keepalived pour héberger un ensemble d'adresses VIP accessibles de l'extérieur sur un ensemble d'hôtes. Chaque VIP n'est desservi que par un seul hôte à la fois. Keepalived utilise le protocole VRRP (Virtual Router Redundancy Protocol) pour déterminer quel hôte, parmi l'ensemble des hôtes, dessert quel VIP. Si un hôte devient indisponible, ou si le service que Keepalived surveille ne répond pas, le VIP est basculé sur un autre hôte de l'ensemble. Cela signifie qu'un VIP est toujours servi tant qu'un hôte est disponible.

Lorsqu'un nœud exécutant Keepalived passe le script de contrôle, le VIP sur ce nœud peut entrer dans l'état master en fonction de sa priorité et de la priorité du maître actuel et selon la stratégie de préemption.

Un administrateur de cluster peut fournir un script via la variable OPENSHIFT_HA_NOTIFY_SCRIPT, et ce script est appelé chaque fois que l'état du VIP sur le nœud change. Keepalived utilise l'état master lorsqu'il gère le VIP, l'état backup lorsqu'un autre noeud gère le VIP, ou l'état fault lorsque le script de vérification échoue. Le script de notification est appelé avec le nouvel état à chaque fois que l'état change.

Vous pouvez créer une configuration de déploiement de basculement IP sur OpenShift Container Platform. La configuration de déploiement de basculement IP spécifie l'ensemble des adresses VIP et l'ensemble des nœuds sur lesquels ils sont gérés. Un cluster peut avoir plusieurs configurations de déploiement de basculement IP, chacune gérant son propre ensemble d'adresses VIP uniques. Chaque nœud de la configuration de basculement IP exécute un pod de basculement IP, et ce pod exécute Keepalived.

Lorsque l'on utilise des VIP pour accéder à un pod avec un réseau hôte, le pod d'application s'exécute sur tous les nœuds qui exécutent les pods de basculement IP. Cela permet à n'importe quel nœud de basculement IP de devenir le maître et de desservir les VIP en cas de besoin. Si les modules d'application ne sont pas exécutés sur tous les nœuds avec basculement IP, certains nœuds de basculement IP ne desservent jamais les VIP ou certains modules d'application ne reçoivent jamais de trafic. Utilisez le même sélecteur et le même nombre de réplications, à la fois pour le basculement IP et pour les modules d'application, afin d'éviter cette incohérence.

Lorsque l'on utilise des VIP pour accéder à un service, n'importe quel nœud peut faire partie de l'ensemble de nœuds de basculement IP, puisque le service est accessible sur tous les nœuds, quel que soit l'endroit où s'exécute le module d'application. N'importe lequel des nœuds de basculement IP peut devenir maître à tout moment. Le service peut soit utiliser des IP externes et un port de service, soit utiliser une adresse NodePort.

Lors de l'utilisation d'IP externes dans la définition du service, les VIP sont définis sur les IP externes et le port de surveillance du basculement d'IP est défini sur le port du service. Lors de l'utilisation d'un port de nœud, le port est ouvert sur chaque nœud du cluster et le service équilibre le trafic à partir du nœud qui dessert actuellement le VIP. Dans ce cas, le port de surveillance du basculement IP est défini sur NodePort dans la définition du service.

Important

La mise en place d'un site NodePort est une opération privilégiée.

Important

Même si un service VIP est hautement disponible, les performances peuvent encore être affectées. Keepalived s'assure que chaque VIP est desservi par un nœud de la configuration, et plusieurs VIP peuvent se retrouver sur le même nœud même si d'autres nœuds n'en ont pas. Les stratégies qui équilibrent la charge de manière externe sur un ensemble de VIP peuvent être contrecarrées lorsque le basculement IP place plusieurs VIP sur le même nœud.

Lorsque vous utilisez ingressIP, vous pouvez configurer le basculement IP pour avoir la même plage VIP que la plage ingressIP. Vous pouvez également désactiver le port de surveillance. Dans ce cas, tous les VIP apparaissent sur le même nœud du cluster. Tout utilisateur peut configurer un service avec ingressIP et le rendre hautement disponible.

Important

Il y a un maximum de 254 VIP dans le cluster.

15.1. Variables d'environnement pour le basculement IP
Copier lien

Le tableau suivant contient les variables utilisées pour configurer le basculement IP.

Expand

Tableau 15.1. Variables d'environnement pour le basculement IP
Nom de la variable	Défaut	Description
`OPENSHIFT_HA_MONITOR_PORT`	`80`	Le module de basculement IP tente d'ouvrir une connexion TCP à ce port sur chaque IP virtuelle (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.
`OPENSHIFT_HA_NETWORK_INTERFACE`		Nom de l'interface que le basculement IP utilise pour envoyer le trafic VRRP (Virtual Router Redundancy Protocol). La valeur par défaut est `eth0`.
`OPENSHIFT_HA_REPLICA_COUNT`	`2`	Le nombre de répliques à créer. Il doit correspondre à la valeur `spec.replicas` dans la configuration du déploiement du basculement IP.
`OPENSHIFT_HA_VIRTUAL_IPS`		La liste des plages d'adresses IP à répliquer. Elle doit être fournie. Par exemple, `1.2.3.4-6,1.2.3.9`.
`OPENSHIFT_HA_VRRP_ID_OFFSET`	`0`	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`.
`OPENSHIFT_HA_VIP_GROUPS`		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`.
`OPENSHIFT_HA_IPTABLES_CHAIN`	ENTRÉE	Le nom de la chaîne iptables, pour ajouter automatiquement une règle `iptables` pour 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.
`OPENSHIFT_HA_CHECK_SCRIPT`		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.
`OPENSHIFT_HA_CHECK_INTERVAL`	`2`	Période, en secondes, pendant laquelle le script de contrôle est exécuté.
`OPENSHIFT_HA_NOTIFY_SCRIPT`		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.
`OPENSHIFT_HA_PREEMPTION`	`preempt_nodelay 300`	La stratégie de gestion d'un nouvel hôte de priorité supérieure. La stratégie `nopreempt` ne déplace pas le maître de l'hôte de priorité inférieure vers l'hôte de priorité supérieure.

15.2. Configuration du basculement IP
Copier lien

En tant qu'administrateur de grappe, vous pouvez configurer le basculement IP sur une grappe entière ou sur un sous-ensemble de nœuds, comme défini par le sélecteur d'étiquettes. Vous pouvez également configurer plusieurs configurations de déploiement du basculement IP dans votre grappe, chacune étant indépendante des autres.

La configuration du déploiement du basculement IP garantit qu'un pod de basculement s'exécute sur chacun des nœuds correspondant aux contraintes ou à l'étiquette utilisée.

Ce pod exécute Keepalived, qui peut surveiller un point d'extrémité et utiliser le protocole VRRP (Virtual Router Redundancy Protocol) pour basculer l'IP virtuelle (VIP) d'un nœud à l'autre si le premier nœud ne peut pas atteindre le service ou le point d'extrémité.

Pour une utilisation en production, définissez un selector qui sélectionne au moins deux nœuds, et définissez replicas égal au nombre de nœuds sélectionnés.

Conditions préalables

Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
Vous avez créé un secret de fabrication.

Procédure

Créez un compte de service de basculement IP :
```
oc create sa ipfailover
```
```
$ oc create sa ipfailover
```
Copy to Clipboard Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

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 
  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 
          value: "1.1.1.1-2"
        - name: OPENSHIFT_HA_VIP_GROUPS 
          value: "10"
        - name: OPENSHIFT_HA_NETWORK_INTERFACE 
          value: "ens3" #The host interface to assign the VIPs
        - name: OPENSHIFT_HA_MONITOR_PORT 
          value: "30060"
        - name: OPENSHIFT_HA_VRRP_ID_OFFSET 
          value: "0"
        - name: OPENSHIFT_HA_REPLICA_COUNT 
          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 
          value: "INPUT"
        #- name: OPENSHIFT_HA_NOTIFY_SCRIPT 
        #  value: /etc/keepalive/mynotifyscript.sh
        - name: OPENSHIFT_HA_CHECK_SCRIPT 
          value: "/etc/keepalive/mycheckscript.sh"
        - name: OPENSHIFT_HA_PREEMPTION 
          value: "preempt_delay 300"
        - name: OPENSHIFT_HA_CHECK_INTERVAL 
          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

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

Copy to Clipboard

Toggle word wrap

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.

15.3. À propos des adresses IP virtuelles
Copier lien

Keepalived gère un ensemble d'adresses IP virtuelles (VIP). L'administrateur doit s'assurer que toutes ces adresses :

Sont accessibles sur les hôtes configurés depuis l'extérieur du cluster.
Ne sont pas utilisés à d'autres fins au sein du groupe.

Keepalived sur chaque nœud détermine si le service nécessaire est en cours d'exécution. Si c'est le cas, les VIP sont pris en charge et Keepalived participe à la négociation pour déterminer quel nœud dessert le VIP. Pour qu'un nœud puisse participer, le service doit être à l'écoute sur le port de surveillance d'un VIP ou le contrôle doit être désactivé.

Note

Chaque VIP de l'ensemble peut être desservi par un nœud différent.

15.4. Configuration des scripts de contrôle et de notification
Copier lien

Keepalived surveille la santé de l'application en exécutant périodiquement un script de vérification optionnel fourni par l'utilisateur. Par exemple, le script peut tester un serveur web en émettant une requête et en vérifiant la réponse.

Lorsqu'un script de contrôle n'est pas fourni, un simple script par défaut est exécuté pour tester la connexion TCP. Ce test par défaut est supprimé lorsque le port du moniteur est 0.

Chaque module de basculement IP gère un démon Keepalived qui gère une ou plusieurs IP virtuelles (VIP) sur le nœud où le module est exécuté. Le démon Keepalived conserve l'état de chaque VIP pour ce nœud. Un VIP particulier sur un nœud particulier peut être dans l'état master, backup ou fault.

Lorsque le script de vérification de ce VIP sur le nœud qui est dans l'état master échoue, le VIP sur ce nœud entre dans l'état fault, ce qui déclenche une renégociation. Au cours de la renégociation, tous les VIP d'un nœud qui ne sont pas dans l'état fault participent au choix du nœud qui prendra en charge le VIP. En fin de compte, le VIP entre dans l'état master sur un nœud, et le VIP reste dans l'état backup sur les autres nœuds.

Lorsqu'un nœud avec un VIP dans l'état backup échoue, le VIP sur ce nœud entre dans l'état fault. Lorsque le script de contrôle réussit à nouveau pour un VIP sur un nœud dans l'état fault, le VIP sur ce nœud quitte l'état fault et négocie pour entrer dans l'état master. Le VIP sur ce nœud peut alors entrer dans l'état master ou backup.

En tant qu'administrateur du cluster, vous pouvez fournir un script de notification optionnel, qui est appelé chaque fois que l'état change. Keepalived transmet les trois paramètres suivants au script :

$1 - group ou instance
$2 - Nom du site group ou instance
$3 - Le nouvel État : master, backup, ou fault

Les scripts de vérification et de notification s'exécutent dans le module de basculement IP et utilisent le système de fichiers du module, et non le système de fichiers de l'hôte. Toutefois, le module de basculement IP rend le système de fichiers hôte disponible sous le chemin de montage /hosts. Lors de la configuration d'un script de contrôle ou de notification, vous devez fournir le chemin d'accès complet au script. L'approche recommandée pour fournir les scripts est d'utiliser une carte de configuration.

Les noms des chemins complets des scripts de vérification et de notification sont ajoutés au fichier de configuration de Keepalived, _/etc/keepalived/keepalived.conf, qui est chargé à chaque démarrage de Keepalived. Les scripts peuvent être ajoutés au pod avec une carte de configuration comme suit.

Conditions préalables

You installed the OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.

Procédure

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
```
```
#!/bin/bash
    # Whatever tests are needed
    # E.g., send request and verify response
exit 0
```
Copy to Clipboard Toggle word wrap

Créer la carte de configuration :

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

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

Copy to Clipboard

Toggle word wrap

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 env deploy/ipfailover-keepalived \
    OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh

Copy to Clipboard

Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

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

$ oc edit deploy ipfailover-keepalived

Copy to Clipboard

Toggle word wrap

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

    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
...

Copy to Clipboard

Toggle word wrap

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.

15.5. Configuration de la préemption VRRP
Copier lien

Lorsqu'une IP virtuelle (VIP) sur un nœud quitte l'état fault en passant le script de contrôle, la VIP sur le nœud entre dans l'état backup si elle a une priorité inférieure à celle de la VIP sur le nœud qui est actuellement dans l'état master. Toutefois, si le VIP du nœud qui quitte l'état fault a une priorité plus élevée, la stratégie de préemption détermine son rôle dans le cluster.

La stratégie nopreempt ne déplace pas master du VIP de priorité inférieure sur l'hôte vers le VIP de priorité supérieure sur l'hôte. Avec preempt_delay 300, la valeur par défaut, Keepalived attend les 300 secondes spécifiées et déplace master vers le VIP de plus haute priorité sur l'hôte.

Conditions préalables

You installed the OpenShift CLI (oc).

Procédure

Pour spécifier la préemption, entrez dans oc edit deploy ipfailover-keepalived pour modifier la configuration du déploiement du routeur :
```
oc edit deploy ipfailover-keepalived
```
```
$ oc edit deploy ipfailover-keepalived
```
Copy to Clipboard Toggle word wrap
```
...
    spec:
      containers:
      - env:
        - name: OPENSHIFT_HA_PREEMPTION  
          value: preempt_delay 300
...
```
```
...
    spec:
      containers:
      - env:
        - name: OPENSHIFT_HA_PREEMPTION  
```
1
```
          value: preempt_delay 300
...
```
Copy to Clipboard Toggle word wrap
1
Définir la valeur de OPENSHIFT_HA_PREEMPTION:
preempt_delay 300: Keepalived attend les 300 secondes spécifiées et déplace master vers le VIP de priorité supérieure sur l'hôte. Il s'agit de la valeur par défaut.
nopreempt: ne déplace pas master du VIP de priorité inférieure sur l'hôte vers le VIP de priorité supérieure sur l'hôte.

15.6. À propos du décalage de l'ID VRRP
Copier lien

Chaque module de basculement IP géré par la configuration de déploiement de basculement IP, 1 module par nœud ou réplique, exécute un démon Keepalived. Au fur et à mesure que des configurations de déploiement de basculement IP sont configurées, d'autres modules sont créés et d'autres démons participent à la négociation commune du protocole VRRP (Virtual Router Redundancy Protocol). Cette négociation est effectuée par tous les démons Keepalived et détermine quels nœuds gèrent quelles IP virtuelles (VIP).

En interne, Keepalived attribue un vrrp-id unique à chaque VIP. La négociation utilise cet ensemble de vrrp-ids, lorsqu'une décision est prise, le VIP correspondant au vrrp-id gagnant est pris en charge sur le nœud gagnant.

Par conséquent, pour chaque VIP défini dans la configuration du déploiement du basculement IP, le pod de basculement IP doit attribuer un vrrp-id correspondant. Pour ce faire, il commence par OPENSHIFT_HA_VRRP_ID_OFFSET et attribue séquentiellement vrrp-ids à la liste des VIP. Les valeurs de vrrp-ids peuvent être comprises dans l'intervalle 1..255.

Lorsqu'il existe plusieurs configurations de déploiement de basculement IP, vous devez spécifier OPENSHIFT_HA_VRRP_ID_OFFSET pour qu'il soit possible d'augmenter le nombre de VIP dans la configuration de déploiement et qu'aucune des plages vrrp-id ne se chevauche.

15.7. Configuration du basculement IP pour plus de 254 adresses
Copier lien

La gestion du basculement IP est limitée à 254 groupes d'adresses IP virtuelles (VIP). Par défaut, OpenShift Container Platform attribue une adresse IP à chaque groupe. Vous pouvez utiliser la variable OPENSHIFT_HA_VIP_GROUPS pour changer cela afin que plusieurs adresses IP soient dans chaque groupe et définir le nombre de groupes VIP disponibles pour chaque instance VRRP (Virtual Router Redundancy Protocol) lors de la configuration du basculement IP.

Le regroupement des VIP permet d'élargir la gamme d'attribution des VIP par VRRP dans le cas d'événements de basculement VRRP, et est utile lorsque tous les hôtes du cluster ont accès à un service localement. Par exemple, lorsqu'un service est exposé avec un ExternalIP.

Note

En règle générale, pour le basculement, ne limitez pas les services, tels que le routeur, à un hôte spécifique. Au contraire, les services doivent être répliqués sur chaque hôte de sorte qu'en cas de basculement IP, les services ne doivent pas être recréés sur le nouvel hôte.

Note

Si vous utilisez les contrôles de santé d'OpenShift Container Platform, la nature du basculement IP et des groupes signifie que toutes les instances du groupe ne sont pas contrôlées. Pour cette raison, les contrôles de santé de Kubernetes doivent être utilisés pour s'assurer que les services sont actifs.

Conditions préalables

Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.

Procédure

Pour modifier le nombre d'adresses IP attribuées à chaque groupe, modifiez la valeur de la variable OPENSHIFT_HA_VIP_GROUPS, par exemple :
Exemple Deployment YAML pour la configuration du basculement IP
```
...
    spec:
        env:
        - name: OPENSHIFT_HA_VIP_GROUPS 
          value: "3"
...
```
```
...
    spec:
        env:
        - name: OPENSHIFT_HA_VIP_GROUPS 
```
1
```
          value: "3"
...
```
Copy to Clipboard Toggle word wrap
1
Si OPENSHIFT_HA_VIP_GROUPS est défini sur 3 dans un environnement comportant sept VIP, il crée trois groupes, assignant trois VIP au premier groupe et deux VIP aux deux groupes restants.

Note

Si le nombre de groupes défini par OPENSHIFT_HA_VIP_GROUPS est inférieur au nombre d'adresses IP définies pour le basculement, le groupe contient plus d'une adresse IP et toutes les adresses sont déplacées en tant qu'unité unique.

15.8. Haute disponibilité Pour ingressIP
Copier lien

Dans les clusters non-cloud, il est possible de combiner le basculement IP et ingressIP vers un service. Il en résulte des services à haute disponibilité pour les utilisateurs qui créent des services à l'aide de ingressIP.

L'approche consiste à spécifier une plage ingressIPNetworkCIDR et à utiliser la même plage lors de la création de la configuration ipfailover.

Étant donné que le basculement IP peut prendre en charge un maximum de 255 VIP pour l'ensemble du cluster, le site ingressIPNetworkCIDR doit être /24 ou plus petit.

15.9. Suppression du basculement IP
Copier lien

Lors de la configuration initiale du basculement IP, les nœuds de travail du cluster sont modifiés avec une règle iptables qui autorise explicitement les paquets multicast sur 224.0.0.18 pour Keepalived. En raison de la modification des nœuds, la suppression du basculement IP nécessite l'exécution d'un travail pour supprimer la règle iptables et supprimer les adresses IP virtuelles utilisées par Keepalived.

Procédure

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

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}"

$ 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}"

Copy to Clipboard

Toggle word wrap

Exemple de sortie

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

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

Copy to Clipboard

Toggle word wrap

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>
```
```
oc delete configmap <configmap_name> $ oc delete configmap <configmap_name>
```
Copy to Clipboard Toggle word wrap

Identifier un déploiement existant pour le basculement IP :

oc get deployment -l ipfailover

$ oc get deployment -l ipfailover

Copy to Clipboard

Toggle word wrap

Exemple de sortie

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

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

Copy to Clipboard

Toggle word wrap

Supprimer le déploiement :

oc delete deployment <ipfailover_deployment_name>

oc delete deployment <ipfailover_deployment_name>

Copy to Clipboard

Toggle word wrap

Supprimez le compte de service ipfailover:
```
oc delete sa ipfailover
```
```
$ oc delete sa ipfailover
```
Copy to Clipboard Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

<.> 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.

Exécuter le travail :

oc create -f remove-ipfailover-job.yaml

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

Copy to Clipboard

Toggle word wrap

Exemple de sortie

job.batch/remove-ipfailover-2h8dm created

job.batch/remove-ipfailover-2h8dm created

Copy to Clipboard

Toggle word wrap

Vérification

Confirmez que le travail a supprimé la configuration initiale du basculement IP.

oc logs job/remove-ipfailover-2h8dm

$ oc logs job/remove-ipfailover-2h8dm

Copy to Clipboard

Toggle word wrap

Exemple de sortie

remove-failover.sh: OpenShift IP Failover service terminating.
  - Removing ip_vs module ...
  - Cleaning up ...
  - Releasing VIPs  (interface eth0) ...

remove-failover.sh: OpenShift IP Failover service terminating.
  - Removing ip_vs module ...
  - Cleaning up ...
  - Releasing VIPs  (interface eth0) ...

Copy to Clipboard

Toggle word wrap

Chapitre 16. Configuration des sysctl de réseau au niveau de l'interface
Copier lien

Sous Linux, sysctl permet à un administrateur de modifier les paramètres du noyau au moment de l'exécution. Vous pouvez modifier les sysctls réseau au niveau de l'interface en utilisant le méta plugin tuning Container Network Interface (CNI). Le méta plugin CNI de réglage fonctionne en chaîne avec un plugin CNI principal, comme illustré.

Le plugin CNI principal attribue l'interface et la transmet au méta plugin CNI de réglage au moment de l'exécution. Vous pouvez modifier certains sysctls et plusieurs attributs d'interface (mode promiscuous, mode all-multicast, MTU et adresse MAC) dans l'espace de noms du réseau en utilisant le méta plugin CNI tuning. Dans la configuration du méta plugin CNI tuning, le nom de l'interface est représenté par le jeton IFNAME, et est remplacé par le nom réel de l'interface au moment de l'exécution.

Note

Dans OpenShift Container Platform, le méta plugin CNI tuning ne prend en charge que la modification des sysctls réseau au niveau de l'interface.

16.1. Configuration du CNI d'accord
Copier lien

La procédure suivante configure le CNI de réglage pour modifier le réseau au niveau de l'interface net.ipv4.conf.IFNAME.accept_redirects sysctl. Cet exemple permet d'accepter et d'envoyer des paquets ICMP redirigés.

Procédure

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> 
  namespace: default 
spec:
  config: '{
    "cniVersion": "0.4.0", 
    "name": "<name>", 
    "plugins": [{
       "type": "<main_CNI_plugin>" 
      },
      {
       "type": "tuning", 
       "sysctl": {
            "net.ipv4.conf.IFNAME.accept_redirects": "1" 
        }
      }
     ]
}

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

Copy to Clipboard

Toggle word wrap

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"
        }
    }
  ]
}'

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"
        }
    }
  ]
}'

Copy to Clipboard

Toggle word wrap

Appliquez le fichier yaml en exécutant la commande suivante :
```
oc apply -f tuning-example.yaml
```
```
$ oc apply -f tuning-example.yaml
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
networkattachmentdefinition.k8.cni.cncf.io/tuningnad created
```
```
networkattachmentdefinition.k8.cni.cncf.io/tuningnad created
```
Copy to Clipboard Toggle word wrap

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 
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000 
      runAsGroup: 3000 
      allowPrivilegeEscalation: false 
      capabilities: 
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true 
    seccompProfile: 
      type: RuntimeDefault

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

Copy to Clipboard

Toggle word wrap

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.

Appliquez le fichier yaml en exécutant la commande suivante :
```
oc apply -f examplepod.yaml
```
```
$ oc apply -f examplepod.yaml
```
Copy to Clipboard Toggle word wrap
Vérifiez que le module est créé en exécutant la commande suivante :
```
oc get pod
```
```
$ oc get pod
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
NAME      READY   STATUS    RESTARTS   AGE
tunepod   1/1     Running   0          47s
```
```
NAME      READY   STATUS    RESTARTS   AGE
tunepod   1/1     Running   0          47s
```
Copy to Clipboard Toggle word wrap
Connectez-vous au module en exécutant la commande suivante :
```
oc rsh tunepod
```
```
$ oc rsh tunepod
```
Copy to Clipboard Toggle word wrap
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 :
```
sysctl net.ipv4.conf.net1.accept_redirects
```
```
sh-4.4# sysctl net.ipv4.conf.net1.accept_redirects
```
Copy to Clipboard Toggle word wrap
Résultats attendus
```
net.ipv4.conf.net1.accept_redirects = 1
```
```
net.ipv4.conf.net1.accept_redirects = 1
```
Copy to Clipboard Toggle word wrap

Chapitre 17. Utilisation du protocole SCTP (Stream Control Transmission Protocol) sur un cluster bare metal
Copier lien

En tant qu'administrateur de cluster, vous pouvez utiliser le protocole SCTP (Stream Control Transmission Protocol) sur un cluster.

17.1. Prise en charge du protocole de transmission de contrôle de flux (SCTP) sur OpenShift Container Platform
Copier lien

En tant qu'administrateur de cluster, vous pouvez activer SCTP sur les hôtes du cluster. Sur Red Hat Enterprise Linux CoreOS (RHCOS), le module SCTP est désactivé par défaut.

SCTP est un protocole fiable basé sur des messages qui fonctionne sur un réseau IP.

Lorsque cette option est activée, vous pouvez utiliser SCTP comme protocole avec les pods, les services et la stratégie réseau. Un objet Service doit être défini avec le paramètre type réglé sur la valeur ClusterIP ou NodePort.

17.1.1. Exemple de configurations utilisant le protocole SCTP
Copier lien

Vous pouvez configurer un pod ou un service pour qu'il utilise le protocole SCTP en attribuant au paramètre protocol la valeur SCTP dans l'objet pod ou service.

Dans l'exemple suivant, un pod est configuré pour utiliser SCTP :

apiVersion: v1
kind: Pod
metadata:
  namespace: project1
  name: example-pod
spec:
  containers:
    - name: example-pod
...
      ports:
        - containerPort: 30100
          name: sctpserver
          protocol: SCTP

apiVersion: v1
kind: Pod
metadata:
  namespace: project1
  name: example-pod
spec:
  containers:
    - name: example-pod
...
      ports:
        - containerPort: 30100
          name: sctpserver
          protocol: SCTP

Copy to Clipboard

Toggle word wrap

Dans l'exemple suivant, un service est configuré pour utiliser SCTP :

apiVersion: v1
kind: Service
metadata:
  namespace: project1
  name: sctpserver
spec:
...
  ports:
    - name: sctpserver
      protocol: SCTP
      port: 30100
      targetPort: 30100
  type: ClusterIP

apiVersion: v1
kind: Service
metadata:
  namespace: project1
  name: sctpserver
spec:
...
  ports:
    - name: sctpserver
      protocol: SCTP
      port: 30100
      targetPort: 30100
  type: ClusterIP

Copy to Clipboard

Toggle word wrap

Dans l'exemple suivant, un objet NetworkPolicy est configuré pour s'appliquer au trafic réseau SCTP sur le port 80 à partir de n'importe quel pod doté d'une étiquette spécifique :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-sctp-on-http
spec:
  podSelector:
    matchLabels:
      role: web
  ingress:
  - ports:
    - protocol: SCTP
      port: 80

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-sctp-on-http
spec:
  podSelector:
    matchLabels:
      role: web
  ingress:
  - ports:
    - protocol: SCTP
      port: 80

Copy to Clipboard

Toggle word wrap

17.2. Activation du protocole de transmission par contrôle de flux (SCTP)
Copier lien

En tant qu'administrateur de cluster, vous pouvez charger et activer le module noyau SCTP figurant sur la liste noire sur les nœuds de travail de votre cluster.

Conditions préalables

Installez le CLI OpenShift (oc).
Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

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

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

Copy to Clipboard

Toggle word wrap

Pour créer l'objet MachineConfig, entrez la commande suivante :
```
oc create -f load-sctp-module.yaml
```
```
$ oc create -f load-sctp-module.yaml
```
Copy to Clipboard Toggle word wrap
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
```
```
$ oc get nodes
```
Copy to Clipboard Toggle word wrap

17.3. Vérification de l'activation du protocole de transmission par contrôle de flux (SCTP)
Copier lien

Vous pouvez vérifier que le SCTP fonctionne sur un cluster en créant un pod avec une application qui écoute le trafic SCTP, en l'associant à un service, puis en vous connectant au service exposé.

Conditions préalables

Accès à l'internet depuis le cluster pour installer le paquet nc.
Installez le CLI OpenShift (oc).
Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

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

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

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

Copy to Clipboard

Toggle word wrap

Créez le pod en entrant la commande suivante :
```
oc create -f sctp-server.yaml
```
```
$ oc create -f sctp-server.yaml
```
Copy to Clipboard Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

Pour créer le service, entrez la commande suivante :
```
oc create -f sctp-service.yaml
```
```
$ oc create -f sctp-service.yaml
```
Copy to Clipboard Toggle word wrap

Créer un pod pour le client SCTP.

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"]

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"]

Copy to Clipboard

Toggle word wrap

Pour créer l'objet Pod, entrez la commande suivante :
```
oc apply -f sctp-client.yaml
```
```
$ oc apply -f sctp-client.yaml
```
Copy to Clipboard Toggle word wrap

Exécutez une liste d'écoute SCTP sur le serveur.
1. Pour vous connecter au module serveur, entrez la commande suivante :
  $ oc rsh sctpserver
  Copy to Clipboard Toggle word wrap
2. Pour démarrer l'auditeur SCTP, entrez la commande suivante :
  $ nc -l 30102 --sctp
  Copy to Clipboard Toggle word wrap
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"}}'
  Copy to Clipboard Toggle word wrap
3. Pour se connecter au pod client, entrez la commande suivante :
  $ oc rsh sctpclient
  Copy to Clipboard Toggle word wrap
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
  Copy to Clipboard Toggle word wrap

Chapitre 18. Utilisation du matériel PTP
Copier lien

Vous pouvez configurer les services linuxptp et utiliser du matériel compatible PTP dans les nœuds de cluster d'OpenShift Container Platform.

18.1. À propos du matériel PTP
Copier lien

Vous pouvez utiliser la console OpenShift Container Platform ou OpenShift CLI (oc) pour installer PTP en déployant le PTP Operator. L'opérateur PTP crée et gère les services linuxptp et fournit les fonctionnalités suivantes :

Découverte des appareils compatibles PTP dans le cluster.
Gestion de la configuration des services linuxptp.
Notification des événements d'horloge PTP qui affectent négativement les performances et la fiabilité de votre application avec le sidecar PTP Operator cloud-event-proxy.

Note

L'opérateur PTP travaille avec des appareils compatibles PTP sur des clusters approvisionnés uniquement sur une infrastructure bare-metal.

18.2. À propos de PTP
Copier lien

Le Precision Time Protocol (PTP) est utilisé pour synchroniser les horloges d'un réseau. Lorsqu'il est utilisé en conjonction avec un support matériel, le PTP est capable d'une précision inférieure à la microseconde et est plus précis que le Network Time Protocol (NTP).

Le paquet linuxptp comprend les programmes ptp4l et phc2sys pour la synchronisation des horloges. ptp4l implémente l'horloge frontière PTP et l'horloge ordinaire. ptp4l synchronise l'horloge matérielle PTP avec l'horloge source avec un horodatage matériel et synchronise l'horloge système avec l'horloge source avec un horodatage logiciel. phc2sys est utilisé pour l'horodatage matériel afin de synchroniser l'horloge système avec l'horloge matérielle PTP sur le contrôleur d'interface de réseau (NIC).

18.2.1. Éléments d'un domaine PTP
Copier lien

Le protocole PTP est utilisé pour synchroniser plusieurs nœuds connectés dans un réseau, avec des horloges pour chaque nœud. Les horloges synchronisées par PTP sont organisées dans une hiérarchie source-destination. La hiérarchie est créée et mise à jour automatiquement par l'algorithme de la meilleure horloge maîtresse (BMC), qui s'exécute sur chaque horloge. Les horloges de destination sont synchronisées avec les horloges sources, et les horloges de destination peuvent elles-mêmes être la source d'autres horloges en aval. Les types d'horloges suivants peuvent être inclus dans les configurations :

Horloge du grand maître: L'horloge grand maître fournit des informations horaires standard aux autres horloges du réseau et assure une synchronisation précise et stable. Elle écrit des horodatages et répond aux demandes de temps des autres horloges. Les horloges grand maître peuvent être synchronisées avec une source de temps GPS (Global Positioning System).
Horloge ordinaire: L'horloge ordinaire dispose d'une connexion à port unique qui peut jouer le rôle d'horloge source ou de destination, en fonction de sa position dans le réseau. L'horloge ordinaire peut lire et écrire des horodatages.
Horloge frontière: L'horloge périphérique possède des ports dans deux ou plusieurs voies de communication et peut être à la fois une source et une destination pour d'autres horloges de destination. L'horloge périphérique fonctionne comme une horloge de destination en amont. L'horloge de destination reçoit le message de synchronisation, corrige le retard, puis crée un nouveau signal temporel source à transmettre sur le réseau. L'horloge périphérique produit un nouveau paquet de données temporelles qui reste correctement synchronisé avec l'horloge source et peut réduire le nombre de dispositifs connectés qui se rapportent directement à l'horloge source.

18.2.2. Avantages du PTP par rapport au NTP
Copier lien

L'un des principaux avantages du PTP par rapport au NTP est le support matériel présent dans divers contrôleurs d'interface réseau (NIC) et commutateurs de réseau. Le matériel spécialisé permet au PTP de tenir compte des retards dans le transfert des messages et d'améliorer la précision de la synchronisation du temps. Pour obtenir la meilleure précision possible, il est recommandé que tous les composants de réseau entre les horloges PTP soient compatibles avec le matériel PTP.

Le PTP matériel offre une précision optimale, car la carte d'interface réseau peut horodater les paquets PTP au moment exact où ils sont envoyés et reçus. Comparé au PTP logiciel, qui nécessite un traitement supplémentaire des paquets PTP par le système d'exploitation, le PTP matériel offre une précision optimale.

Important

Avant d'activer le PTP, assurez-vous que NTP est désactivé pour les nœuds requis. Vous pouvez désactiver le service chronologique (chronyd) à l'aide d'une ressource personnalisée MachineConfig. Pour plus d'informations, voir Désactivation du service chronologique.

18.2.3. Utilisation de PTP avec un matériel à double NIC
Copier lien

OpenShift Container Platform prend en charge le matériel NIC simple et double pour une synchronisation PTP précise dans le cluster.

Pour les réseaux télécoms 5G qui offrent une couverture du spectre à bande moyenne, chaque unité virtuelle distribuée (vDU) nécessite des connexions à 6 unités radio (RU). Pour établir ces connexions, chaque hôte vDU a besoin de deux cartes d'interface réseau configurées en tant qu'horloges limites.

Le matériel Dual NIC vous permet de connecter chaque NIC à la même horloge leader en amont, avec des instances ptp4l distinctes pour chaque NIC alimentant les horloges en aval.

18.3. Installation de l'opérateur PTP à l'aide du CLI
Copier lien

En tant qu'administrateur de cluster, vous pouvez installer l'Opérateur à l'aide de la CLI.

Conditions préalables

Un cluster installé sur du matériel bare-metal avec des nœuds dont le matériel prend en charge le protocole PTP.
Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

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

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"

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

Copy to Clipboard

Toggle word wrap

Créer le CR Namespace:
```
oc create -f ptp-namespace.yaml
```
```
$ oc create -f ptp-namespace.yaml
```
Copy to Clipboard Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

Créer le CR OperatorGroup:
```
oc create -f ptp-operatorgroup.yaml
```
```
$ oc create -f ptp-operatorgroup.yaml
```
Copy to Clipboard Toggle word wrap

S'abonner à l'opérateur PTP.

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

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

Copy to Clipboard

Toggle word wrap

Créer le CR Subscription:
```
oc create -f ptp-sub.yaml
```
```
$ oc create -f ptp-sub.yaml
```
Copy to Clipboard Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name                         Phase
4.12.0-202301261535          Succeeded

Name                         Phase
4.12.0-202301261535          Succeeded

Copy to Clipboard

Toggle word wrap

18.4. Installation de l'opérateur PTP à l'aide de la console web
Copier lien

En tant qu'administrateur de cluster, vous pouvez installer l'opérateur PTP à l'aide de la console web.

Note

Vous devez créer l'espace de noms et le groupe d'opérateurs comme indiqué dans la section précédente.

Procédure

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.
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.

18.5. Configuration des dispositifs PTP
Copier lien

L'opérateur PTP ajoute la définition de ressource personnalisée (CRD) NodePtpDevice.ptp.openshift.io à OpenShift Container Platform.

Une fois installé, l'opérateur PTP recherche dans votre grappe des périphériques réseau compatibles PTP sur chaque nœud. Il crée et met à jour un objet de ressource personnalisée (CR) NodePtpDevice pour chaque nœud qui fournit un périphérique réseau compatible PTP.

18.5.1. Découverte des périphériques réseau compatibles avec le protocole PTP dans votre cluster
Copier lien

Pour obtenir une liste complète des périphériques réseau compatibles avec le protocole PTP dans votre cluster, exécutez la commande suivante :

oc get NodePtpDevice -n openshift-ptp -o yaml

$ oc get NodePtpDevice -n openshift-ptp -o yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: v1
items:
- apiVersion: ptp.openshift.io/v1
  kind: NodePtpDevice
  metadata:
    creationTimestamp: "2022-01-27T15:16:28Z"
    generation: 1
    name: dev-worker-0 
    namespace: openshift-ptp
    resourceVersion: "6538103"
    uid: d42fc9ad-bcbf-4590-b6d8-b676c642781a
  spec: {}
  status:
    devices: 
    - name: eno1
    - name: eno2
    - name: eno3
    - name: eno4
    - name: enp5s0f0
    - name: enp5s0f1
...

apiVersion: v1
items:
- apiVersion: ptp.openshift.io/v1
  kind: NodePtpDevice
  metadata:
    creationTimestamp: "2022-01-27T15:16:28Z"
    generation: 1
    name: dev-worker-0

1


    namespace: openshift-ptp
    resourceVersion: "6538103"
    uid: d42fc9ad-bcbf-4590-b6d8-b676c642781a
  spec: {}
  status:
    devices:

2


    - name: eno1
    - name: eno2
    - name: eno3
    - name: eno4
    - name: enp5s0f0
    - name: enp5s0f1
...

Copy to Clipboard

Toggle word wrap

1: La valeur du paramètre name est identique au nom du nœud parent.
2: La collection devices comprend une liste des dispositifs compatibles PTP que l'opérateur PTP découvre pour le nœud.

18.5.2. Configuration des services linuxptp en tant qu'horloge ordinaire
Copier lien

Vous pouvez configurer les services linuxptp (ptp4l, phc2sys) comme des horloges ordinaires en créant un objet PtpConfig custom resource (CR).

Note

Utilisez l'exemple suivant PtpConfig CR comme base pour configurer les services linuxptp en tant qu'horloge ordinaire pour votre matériel et votre environnement particuliers. Cet exemple CR ne configure pas les événements rapides PTP. Pour configurer les événements rapides PTP, définissez les valeurs appropriées pour ptp4lOpts, ptp4lConf, et ptpClockThreshold. ptpClockThreshold n'est nécessaire que lorsque les événements sont activés. Voir "Configuring the PTP fast event notifications publisher" (Configuration de l'éditeur de notifications d'événements rapides PTP) pour plus d'informations.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
Installer l'opérateur PTP.

Procédure

Créez le CR PtpConfig suivant, puis enregistrez le YAML dans le fichier ordinary-clock-ptp-config.yaml.

Configuration recommandée de l'horloge ordinaire PTP

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: ordinary-clock-ptp-config
  namespace: openshift-ptp
  spec:
    profile:
      - name: ordinary-clock
        interface: "<interface_name>"
        phc2sysOpts: "-a -r -n 24"
        ptp4lOpts: "-2 -s"
        ptpSchedulingPolicy: SCHED_FIFO
        ptpSchedulingPriority: 10
        ptp4lConf: |
          [global]
          #
          # Default Data Set
          #
          twoStepFlag 1
          slaveOnly 1
          priority1 128
          priority2 128
          domainNumber 24
          clockClass 255
          clockAccuracy 0xFE
          offsetScaledLogVariance 0xFFFF
          free_running 0
          freq_est_interval 1
          dscp_event 0
          dscp_general 0
          dataset_comparison G.8275.x
          G.8275.defaultDS.localPriority 128
          #
          # Port Data Set
          #
          logAnnounceInterval -3
          logSyncInterval -4
          logMinDelayReqInterval -4
          logMinPdelayReqInterval -4
          announceReceiptTimeout 3
          syncReceiptTimeout 0
          delayAsymmetry 0
          fault_reset_interval 4
          neighborPropDelayThresh 20000000
          masterOnly 0
          G.8275.portDS.localPriority 128
          #
          # Run time options
          #
          assume_two_step 0
          logging_level 6
          path_trace_enabled 0
          follow_up_info 0
          hybrid_e2e 0
          inhibit_multicast_service 0
          net_sync_monitor 0
          tc_spanning_tree 0
          tx_timestamp_timeout 50
          unicast_listen 0
          unicast_master_table 0
          unicast_req_duration 3600
          use_syslog 1
          verbose 0
          summary_interval 0
          kernel_leap 1
          check_fup_sync 0
          #
          # Servo Options
          #
          pi_proportional_const 0.0
          pi_integral_const 0.0
          pi_proportional_scale 0.0
          pi_proportional_exponent -0.3
          pi_proportional_norm_max 0.7
          pi_integral_scale 0.0
          pi_integral_exponent 0.4
          pi_integral_norm_max 0.3
          step_threshold 2.0
          first_step_threshold 0.00002
          max_frequency 900000000
          clock_servo pi
          sanity_freq_limit 200000000
          ntpshm_segment 0
          #
          # Transport options
          #
          transportSpecific 0x0
          ptp_dst_mac 01:1B:19:00:00:00
          p2p_dst_mac 01:80:C2:00:00:0E
          udp_ttl 1
          udp6_scope 0x0E
          uds_address /var/run/ptp4l
          #
          # Default interface options
          #
          clock_type OC
          network_transport L2
          delay_mechanism E2E
          time_stamping hardware
          tsproc_mode filter
          delay_filter moving_median
          delay_filter_length 10
          egressLatency 0
          ingressLatency 0
          boundary_clock_jbod 0
          #
          # Clock description
          #
          productDescription ;;
          revisionData ;;
          manufacturerIdentity 00:00:00
          userDescription ;
          timeSource 0xA0
      recommend:
      - profile: ordinary-clock
        priority: 4
        match:
        - nodeLabel: "node-role.kubernetes.io/worker"
          nodeName: "<node_name>"

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: ordinary-clock-ptp-config
  namespace: openshift-ptp
  spec:
    profile:
      - name: ordinary-clock
        interface: "<interface_name>"
        phc2sysOpts: "-a -r -n 24"
        ptp4lOpts: "-2 -s"
        ptpSchedulingPolicy: SCHED_FIFO
        ptpSchedulingPriority: 10
        ptp4lConf: |
          [global]
          #
          # Default Data Set
          #
          twoStepFlag 1
          slaveOnly 1
          priority1 128
          priority2 128
          domainNumber 24
          clockClass 255
          clockAccuracy 0xFE
          offsetScaledLogVariance 0xFFFF
          free_running 0
          freq_est_interval 1
          dscp_event 0
          dscp_general 0
          dataset_comparison G.8275.x
          G.8275.defaultDS.localPriority 128
          #
          # Port Data Set
          #
          logAnnounceInterval -3
          logSyncInterval -4
          logMinDelayReqInterval -4
          logMinPdelayReqInterval -4
          announceReceiptTimeout 3
          syncReceiptTimeout 0
          delayAsymmetry 0
          fault_reset_interval 4
          neighborPropDelayThresh 20000000
          masterOnly 0
          G.8275.portDS.localPriority 128
          #
          # Run time options
          #
          assume_two_step 0
          logging_level 6
          path_trace_enabled 0
          follow_up_info 0
          hybrid_e2e 0
          inhibit_multicast_service 0
          net_sync_monitor 0
          tc_spanning_tree 0
          tx_timestamp_timeout 50
          unicast_listen 0
          unicast_master_table 0
          unicast_req_duration 3600
          use_syslog 1
          verbose 0
          summary_interval 0
          kernel_leap 1
          check_fup_sync 0
          #
          # Servo Options
          #
          pi_proportional_const 0.0
          pi_integral_const 0.0
          pi_proportional_scale 0.0
          pi_proportional_exponent -0.3
          pi_proportional_norm_max 0.7
          pi_integral_scale 0.0
          pi_integral_exponent 0.4
          pi_integral_norm_max 0.3
          step_threshold 2.0
          first_step_threshold 0.00002
          max_frequency 900000000
          clock_servo pi
          sanity_freq_limit 200000000
          ntpshm_segment 0
          #
          # Transport options
          #
          transportSpecific 0x0
          ptp_dst_mac 01:1B:19:00:00:00
          p2p_dst_mac 01:80:C2:00:00:0E
          udp_ttl 1
          udp6_scope 0x0E
          uds_address /var/run/ptp4l
          #
          # Default interface options
          #
          clock_type OC
          network_transport L2
          delay_mechanism E2E
          time_stamping hardware
          tsproc_mode filter
          delay_filter moving_median
          delay_filter_length 10
          egressLatency 0
          ingressLatency 0
          boundary_clock_jbod 0
          #
          # Clock description
          #
          productDescription ;;
          revisionData ;;
          manufacturerIdentity 00:00:00
          userDescription ;
          timeSource 0xA0
      recommend:
      - profile: ordinary-clock
        priority: 4
        match:
        - nodeLabel: "node-role.kubernetes.io/worker"
          nodeName: "<node_name>"

Copy to Clipboard

Toggle word wrap

Expand

Tableau 18.1. Options de configuration de l'horloge ordinaire PTP CR
Champ de ressource personnalisé	Description
`name`	Le nom du CR `PtpConfig`.
`profile`	Spécifier un tableau d'un ou plusieurs objets `profile`. Chaque profil doit être nommé de manière unique.
`interface`	Indiquez l'interface réseau à utiliser par le service `ptp4l`, par exemple `ens787f1`.
`ptp4lOpts`	Spécifiez les options de configuration du système pour le service `ptp4l`, par exemple `-2` pour sélectionner le transport réseau IEEE 802.3. Les options ne doivent pas inclure le nom de l'interface réseau `-i <interface>` et le fichier de configuration du service `-f /etc/ptp4l.conf`, car le nom de l'interface réseau et le fichier de configuration du service sont automatiquement ajoutés. Ajoutez `--summary_interval -4` pour utiliser les événements rapides PTP avec cette interface.
`phc2sysOpts`	Spécifier les options de configuration du système pour le service `phc2sys`. Si ce champ est vide, l'opérateur PTP ne démarre pas le service `phc2sys`. Pour les cartes réseau Intel Columbiaville 800 Series, définissez les options de `phc2sysOpts` sur `-a -r -m -n 24 -N 8 -R 16`. `-m` imprime les messages sur `stdout`. `linuxptp-daemon` `DaemonSet` analyse les journaux et génère des métriques Prometheus.
`ptp4lConf`	Indiquez une chaîne contenant la configuration qui remplacera le fichier par défaut `/etc/ptp4l.conf`. Pour utiliser la configuration par défaut, laissez le champ vide.
`tx_timestamp_timeout`	Pour les cartes réseau de la série 800 d'Intel Columbiaville, définissez `tx_timestamp_timeout` sur `50`.
`boundary_clock_jbod`	Pour les cartes réseau de la série 800 d'Intel Columbiaville, définissez `boundary_clock_jbod` sur `0`.
`ptpSchedulingPolicy`	Politique d'ordonnancement des processus `ptp4l` et `phc2sys`. La valeur par défaut est `SCHED_OTHER`. Utilisez `SCHED_FIFO` sur les systèmes qui prennent en charge l'ordonnancement FIFO.
`ptpSchedulingPriority`	Valeur entière de 1 à 65 utilisée pour définir la priorité FIFO pour les processus `ptp4l` et `phc2sys` lorsque `ptpSchedulingPolicy` est défini sur `SCHED_FIFO`. Le champ `ptpSchedulingPriority` n'est pas utilisé lorsque `ptpSchedulingPolicy` est défini sur `SCHED_OTHER`.
`ptpClockThreshold`	Facultatif. Si `ptpClockThreshold` n'est pas présent, les valeurs par défaut sont utilisées pour les champs `ptpClockThreshold`. `ptpClockThreshold` configure le délai de déconnexion de l'horloge maître PTP avant le déclenchement des événements PTP. `holdOverTimeout` est la valeur temporelle en secondes avant que l'état de l'événement de l'horloge PTP ne passe à `FREERUN` lorsque l'horloge maître PTP est déconnectée. Les paramètres `maxOffsetThreshold` et `minOffsetThreshold` configurent les valeurs de décalage en nanosecondes qui se comparent aux valeurs de `CLOCK_REALTIME` (`phc2sys`) ou au décalage du maître (`ptp4l`). Lorsque la valeur de décalage `ptp4l` ou `phc2sys` est en dehors de cette plage, l'état de l'horloge PTP est réglé sur `FREERUN`. Lorsque la valeur de décalage est comprise dans cette plage, l'état de l'horloge PTP est réglé sur `LOCKED`.
`recommend`	Spécifier un tableau d'un ou plusieurs objets `recommend` qui définissent les règles d'application de `profile` aux nœuds.
`.recommend.profile`	Indiquez le nom de l'objet `.recommend.profile` défini dans la section `profile`.
`.recommend.priority`	Réglez `.recommend.priority` sur `0` pour une horloge ordinaire.
`.recommend.match`	Spécifiez les règles `.recommend.match` avec `nodeLabel` ou `nodeName`.
`.recommend.match.nodeLabel`	Mettez à jour `nodeLabel` avec le `key` de `node.Labels` à partir de l'objet nœud en utilisant la commande `oc get nodes --show-labels`. Par exemple : `node-role.kubernetes.io/worker`.
`.recommend.match.nodeLabel`	Mettez à jour `nodeName` avec la valeur de `node.Name` de l'objet nœud en utilisant la commande `oc get nodes`. Par exemple : `compute-0.example.com`.

Créez le CR PtpConfig en exécutant la commande suivante :
```
oc create -f ordinary-clock-ptp-config.yaml
```
```
$ oc create -f ordinary-clock-ptp-config.yaml
```
Copy to Clipboard Toggle word wrap

Vérification

Vérifiez que le profil PtpConfig est appliqué au nœud.

Obtenez la liste des pods dans l'espace de noms openshift-ptp en exécutant la commande suivante :

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

Vérifiez que le profil est correct. Examinez les journaux du démon linuxptp qui correspond au nœud spécifié dans le profil PtpConfig. Exécutez la commande suivante :

oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container

$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container

Copy to Clipboard

Toggle word wrap

Exemple de sortie

I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 -s
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 -s
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

Copy to Clipboard

Toggle word wrap

18.5.3. Configuration des services linuxptp en tant qu'horloge frontière
Copier lien

Vous pouvez configurer les services linuxptp (ptp4l, phc2sys) en tant qu'horloge frontière en créant un objet PtpConfig custom resource (CR).

Note

Utilisez l'exemple suivant PtpConfig CR comme base pour configurer les services linuxptp en tant qu'horloge frontière pour votre matériel et votre environnement particuliers. Cet exemple CR ne configure pas les événements rapides PTP. Pour configurer les événements rapides PTP, définissez les valeurs appropriées pour ptp4lOpts, ptp4lConf et ptpClockThreshold. ptpClockThreshold n'est utilisé que lorsque les événements sont activés. Voir "Configuring the PTP fast event notifications publisher" (Configuration de l'éditeur de notifications d'événements rapides PTP) pour plus d'informations.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
Installer l'opérateur PTP.

Procédure

Créez le CR PtpConfig suivant, puis enregistrez le YAML dans le fichier boundary-clock-ptp-config.yaml.

Configuration recommandée de l'horloge limite PTP

---
apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config
  namespace: openshift-ptp
spec:
  profile:
  - name: boundary-clock
    phc2sysOpts: "-a -r -n 24"
    ptp4lOpts: "-2"
    ptpSchedulingPolicy: SCHED_FIFO
    ptpSchedulingPriority: 10
    ptp4lConf: |
      [<interface_1>]
      masterOnly 0
      [<interface_2>]
      masterOnly 1
      [<interface_3>]
      masterOnly 1
      [<interface_4>]
      masterOnly 1
      [global]
      #
      # Default Data Set
      #
      twoStepFlag 1
      slaveOnly 0
      priority1 128
      priority2 128
      domainNumber 24
      clockClass 248
      clockAccuracy 0xFE
      offsetScaledLogVariance 0xFFFF
      free_running 0
      freq_est_interval 1
      dscp_event 0
      dscp_general 0
      dataset_comparison G.8275.x
      G.8275.defaultDS.localPriority 128
      #
      # Port Data Set
      #
      logAnnounceInterval -3
      logSyncInterval -4
      logMinDelayReqInterval -4
      logMinPdelayReqInterval -4
      announceReceiptTimeout 3
      syncReceiptTimeout 0
      delayAsymmetry 0
      fault_reset_interval 4
      neighborPropDelayThresh 20000000
      masterOnly 0
      G.8275.portDS.localPriority 128
      #
      # Run time options
      #
      assume_two_step 0
      logging_level 6
      path_trace_enabled 0
      follow_up_info 0
      hybrid_e2e 0
      inhibit_multicast_service 0
      net_sync_monitor 0
      tc_spanning_tree 0
      tx_timestamp_timeout 50
      unicast_listen 0
      unicast_master_table 0
      unicast_req_duration 3600
      use_syslog 1
      verbose 0
      summary_interval 0
      kernel_leap 1
      check_fup_sync 0
      #
      # Servo Options
      #
      pi_proportional_const 0.0
      pi_integral_const 0.0
      pi_proportional_scale 0.0
      pi_proportional_exponent -0.3
      pi_proportional_norm_max 0.7
      pi_integral_scale 0.0
      pi_integral_exponent 0.4
      pi_integral_norm_max 0.3
      step_threshold 2.0
      first_step_threshold 0.00002
      max_frequency 900000000
      clock_servo pi
      sanity_freq_limit 200000000
      ntpshm_segment 0
      #
      # Transport options
      #
      transportSpecific 0x0
      ptp_dst_mac 01:1B:19:00:00:00
      p2p_dst_mac 01:80:C2:00:00:0E
      udp_ttl 1
      udp6_scope 0x0E
      uds_address /var/run/ptp4l
      #
      # Default interface options
      #
      clock_type BC
      network_transport L2
      delay_mechanism E2E
      time_stamping hardware
      tsproc_mode filter
      delay_filter moving_median
      delay_filter_length 10
      egressLatency 0
      ingressLatency 0
      boundary_clock_jbod 0
      #
      # Clock description
      #
      productDescription ;;
      revisionData ;;
      manufacturerIdentity 00:00:00
      userDescription ;
      timeSource 0xA0
  recommend:
  - profile: boundary-clock
    priority: 4
    match:
    - nodeLabel: node-role.kubernetes.io/master
      nodeName: <nodename>

---
apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config
  namespace: openshift-ptp
spec:
  profile:
  - name: boundary-clock
    phc2sysOpts: "-a -r -n 24"
    ptp4lOpts: "-2"
    ptpSchedulingPolicy: SCHED_FIFO
    ptpSchedulingPriority: 10
    ptp4lConf: |
      [<interface_1>]
      masterOnly 0
      [<interface_2>]
      masterOnly 1
      [<interface_3>]
      masterOnly 1
      [<interface_4>]
      masterOnly 1
      [global]
      #
      # Default Data Set
      #
      twoStepFlag 1
      slaveOnly 0
      priority1 128
      priority2 128
      domainNumber 24
      clockClass 248
      clockAccuracy 0xFE
      offsetScaledLogVariance 0xFFFF
      free_running 0
      freq_est_interval 1
      dscp_event 0
      dscp_general 0
      dataset_comparison G.8275.x
      G.8275.defaultDS.localPriority 128
      #
      # Port Data Set
      #
      logAnnounceInterval -3
      logSyncInterval -4
      logMinDelayReqInterval -4
      logMinPdelayReqInterval -4
      announceReceiptTimeout 3
      syncReceiptTimeout 0
      delayAsymmetry 0
      fault_reset_interval 4
      neighborPropDelayThresh 20000000
      masterOnly 0
      G.8275.portDS.localPriority 128
      #
      # Run time options
      #
      assume_two_step 0
      logging_level 6
      path_trace_enabled 0
      follow_up_info 0
      hybrid_e2e 0
      inhibit_multicast_service 0
      net_sync_monitor 0
      tc_spanning_tree 0
      tx_timestamp_timeout 50
      unicast_listen 0
      unicast_master_table 0
      unicast_req_duration 3600
      use_syslog 1
      verbose 0
      summary_interval 0
      kernel_leap 1
      check_fup_sync 0
      #
      # Servo Options
      #
      pi_proportional_const 0.0
      pi_integral_const 0.0
      pi_proportional_scale 0.0
      pi_proportional_exponent -0.3
      pi_proportional_norm_max 0.7
      pi_integral_scale 0.0
      pi_integral_exponent 0.4
      pi_integral_norm_max 0.3
      step_threshold 2.0
      first_step_threshold 0.00002
      max_frequency 900000000
      clock_servo pi
      sanity_freq_limit 200000000
      ntpshm_segment 0
      #
      # Transport options
      #
      transportSpecific 0x0
      ptp_dst_mac 01:1B:19:00:00:00
      p2p_dst_mac 01:80:C2:00:00:0E
      udp_ttl 1
      udp6_scope 0x0E
      uds_address /var/run/ptp4l
      #
      # Default interface options
      #
      clock_type BC
      network_transport L2
      delay_mechanism E2E
      time_stamping hardware
      tsproc_mode filter
      delay_filter moving_median
      delay_filter_length 10
      egressLatency 0
      ingressLatency 0
      boundary_clock_jbod 0
      #
      # Clock description
      #
      productDescription ;;
      revisionData ;;
      manufacturerIdentity 00:00:00
      userDescription ;
      timeSource 0xA0
  recommend:
  - profile: boundary-clock
    priority: 4
    match:
    - nodeLabel: node-role.kubernetes.io/master
      nodeName: <nodename>

Copy to Clipboard

Toggle word wrap

Expand

Tableau 18.2. Options de configuration de l'horloge boundary CR du PTP
Champ de ressource personnalisé	Description
`name`	Le nom du CR `PtpConfig`.
`profile`	Spécifier un tableau d'un ou plusieurs objets `profile`.
`name`	Spécifiez le nom d'un objet de profil qui identifie de manière unique un objet de profil.
`ptp4lOpts`	Spécifiez les options de configuration du système pour le service `ptp4l`. Les options ne doivent pas inclure le nom de l'interface réseau `-i <interface>` et le fichier de configuration du service `-f /etc/ptp4l.conf` car le nom de l'interface réseau et le fichier de configuration du service sont automatiquement ajoutés.
`ptp4lConf`	Spécifiez la configuration requise pour démarrer `ptp4l` en tant qu'horloge périphérique. Par exemple, `ens1f0` se synchronise à partir d'une horloge grand maître et `ens1f3` synchronise les périphériques connectés.
`<interface_1>`	L'interface qui reçoit l'horloge de synchronisation.
`<interface_2>`	L'interface qui envoie l'horloge de synchronisation.
`tx_timestamp_timeout`	Pour les cartes réseau de la série 800 d'Intel Columbiaville, définissez `tx_timestamp_timeout` sur `50`.
`boundary_clock_jbod`	Pour les cartes d'interface réseau de la série Intel Columbiaville 800, assurez-vous que `boundary_clock_jbod` est défini sur `0`. Pour les cartes d'interface réseau de la série Intel Fortville X710, assurez-vous que `boundary_clock_jbod` est défini sur `1`.
`phc2sysOpts`	Spécifier les options de configuration du système pour le service `phc2sys`. Si ce champ est vide, l'opérateur PTP ne démarre pas le service `phc2sys`.
`ptpSchedulingPolicy`	Politique d'ordonnancement pour les processus ptp4l et phc2sys. La valeur par défaut est `SCHED_OTHER`. Utilisez `SCHED_FIFO` sur les systèmes qui prennent en charge l'ordonnancement FIFO.
`ptpSchedulingPriority`	Valeur entière de 1 à 65 utilisée pour définir la priorité FIFO pour les processus `ptp4l` et `phc2sys` lorsque `ptpSchedulingPolicy` est défini sur `SCHED_FIFO`. Le champ `ptpSchedulingPriority` n'est pas utilisé lorsque `ptpSchedulingPolicy` est défini sur `SCHED_OTHER`.
`ptpClockThreshold`	Facultatif. Si `ptpClockThreshold` n'est pas présent, les valeurs par défaut sont utilisées pour les champs `ptpClockThreshold`. `ptpClockThreshold` configure le délai de déconnexion de l'horloge maître PTP avant le déclenchement des événements PTP. `holdOverTimeout` est la valeur temporelle en secondes avant que l'état de l'événement de l'horloge PTP ne passe à `FREERUN` lorsque l'horloge maître PTP est déconnectée. Les paramètres `maxOffsetThreshold` et `minOffsetThreshold` configurent les valeurs de décalage en nanosecondes qui se comparent aux valeurs de `CLOCK_REALTIME` (`phc2sys`) ou au décalage du maître (`ptp4l`). Lorsque la valeur de décalage `ptp4l` ou `phc2sys` est en dehors de cette plage, l'état de l'horloge PTP est réglé sur `FREERUN`. Lorsque la valeur de décalage est comprise dans cette plage, l'état de l'horloge PTP est réglé sur `LOCKED`.
`recommend`	Spécifier un tableau d'un ou plusieurs objets `recommend` qui définissent les règles d'application de `profile` aux nœuds.
`.recommend.profile`	Indiquez le nom de l'objet `.recommend.profile` défini dans la section `profile`.
`.recommend.priority`	Spécifiez le champ `priority` avec une valeur entière comprise entre `0` et `99`. Un nombre plus élevé est moins prioritaire, de sorte qu'une priorité de `99` est inférieure à une priorité de `10`. Si un nœud peut être associé à plusieurs profils conformément aux règles définies dans le champ `match`, le profil ayant la priorité la plus élevée est appliqué à ce nœud.
`.recommend.match`	Spécifiez les règles `.recommend.match` avec `nodeLabel` ou `nodeName`.
`.recommend.match.nodeLabel`	Mettez à jour `nodeLabel` avec le `key` de `node.Labels` à partir de l'objet nœud en utilisant la commande `oc get nodes --show-labels`. Par exemple : `node-role.kubernetes.io/worker`.
`.recommend.match.nodeLabel`	Mettez à jour `nodeName` avec la valeur de `node.Name` de l'objet nœud en utilisant la commande `oc get nodes`. Par exemple : `compute-0.example.com`.

Créez le CR en exécutant la commande suivante :
```
oc create -f boundary-clock-ptp-config.yaml
```
```
$ oc create -f boundary-clock-ptp-config.yaml
```
Copy to Clipboard Toggle word wrap

Vérification

Vérifiez que le profil PtpConfig est appliqué au nœud.

Obtenez la liste des pods dans l'espace de noms openshift-ptp en exécutant la commande suivante :

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

Vérifiez que le profil est correct. Examinez les journaux du démon linuxptp qui correspond au nœud spécifié dans le profil PtpConfig. Exécutez la commande suivante :

oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container

$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container

Copy to Clipboard

Toggle word wrap

Exemple de sortie

I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
I1115 09:41:17.117616 4143292 daemon.go:102] Interface:
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
I1115 09:41:17.117616 4143292 daemon.go:102] Interface:
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

Copy to Clipboard

Toggle word wrap

18.5.4. Configuration des services linuxptp en tant qu'horloges limites pour le matériel à double carte réseau
Copier lien

Important

Le matériel Precision Time Protocol (PTP) avec deux NIC configurés en tant qu'horloges limites est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes d'un point de vue fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Vous pouvez configurer les services linuxptp (ptp4l, phc2sys) en tant qu'horloges limites pour le matériel à deux NIC en créant un objet de ressource personnalisée (CR) PtpConfig pour chaque NIC.

Le matériel Dual NIC vous permet de connecter chaque NIC à la même horloge leader en amont, avec des instances ptp4l distinctes pour chaque NIC alimentant les horloges en aval.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
Installer l'opérateur PTP.

Procédure

Créez deux CR PtpConfig distincts, un pour chaque NIC, en utilisant le CR de référence dans "Configuring linuxptp services as a boundary clock" comme base pour chaque CR. Par exemple :

Créez boundary-clock-ptp-config-nic1.yaml, en spécifiant des valeurs pour phc2sysOpts:

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config-nic1
  namespace: openshift-ptp
spec:
  profile:
  - name: "profile1"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: | 
      [ens5f1]
      masterOnly 1
      [ens5f0]
      masterOnly 0
    ...
    phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config-nic1
  namespace: openshift-ptp
spec:
  profile:
  - name: "profile1"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: |

1


      [ens5f1]
      masterOnly 1
      [ens5f0]
      masterOnly 0
    ...
    phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"

2

Copy to Clipboard

Toggle word wrap

1: Spécifiez les interfaces requises pour démarrer ptp4l en tant qu'horloge périphérique. Par exemple, ens5f0 se synchronise à partir d'une horloge grand maître et ens5f1 synchronise les périphériques connectés.
2: Valeurs requises phc2sysOpts. -m imprime des messages à stdout. linuxptp-daemon DaemonSet analyse les journaux et génère des métriques Prometheus.

Créez boundary-clock-ptp-config-nic2.yaml, en supprimant complètement le champ phc2sysOpts pour désactiver le service phc2sys pour le deuxième NIC :

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config-nic2
  namespace: openshift-ptp
spec:
  profile:
  - name: "profile2"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: | 
      [ens7f1]
      masterOnly 1
      [ens7f0]
      masterOnly 0
...

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config-nic2
  namespace: openshift-ptp
spec:
  profile:
  - name: "profile2"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: |

1


      [ens7f1]
      masterOnly 1
      [ens7f0]
      masterOnly 0
...

Copy to Clipboard

Toggle word wrap

1: Spécifiez les interfaces requises pour démarrer ptp4l en tant qu'horloge périphérique sur le second NIC.

Note

Vous devez supprimer complètement le champ phc2sysOpts du deuxième CR PtpConfig pour désactiver le service phc2sys sur le deuxième NIC.

Créez les CR double NIC PtpConfig en exécutant les commandes suivantes :
1. Créez le CR qui configure le PTP pour le premier NIC :
  $ oc create -f boundary-clock-ptp-config-nic1.yaml
  Copy to Clipboard Toggle word wrap
2. Créez le CR qui configure le PTP pour le second NIC :
  $ oc create -f boundary-clock-ptp-config-nic2.yaml
  Copy to Clipboard Toggle word wrap

Vérification

Vérifiez que l'opérateur PTP a appliqué les CR PtpConfig pour les deux NIC. Examinez les journaux du démon linuxptp correspondant au nœud sur lequel est installé le matériel à double carte d'interface réseau. Par exemple, exécutez la commande suivante :

oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-container

$ oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-container

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ptp4l[80828.335]: [ptp4l.1.config] master offset          5 s2 freq   -5727 path delay       519
ptp4l[80828.343]: [ptp4l.0.config] master offset         -5 s2 freq  -10607 path delay       533
phc2sys[80828.390]: [ptp4l.0.config] CLOCK_REALTIME phc offset         1 s2 freq  -87239 delay    539

ptp4l[80828.335]: [ptp4l.1.config] master offset          5 s2 freq   -5727 path delay       519
ptp4l[80828.343]: [ptp4l.0.config] master offset         -5 s2 freq  -10607 path delay       533
phc2sys[80828.390]: [ptp4l.0.config] CLOCK_REALTIME phc offset         1 s2 freq  -87239 delay    539

Copy to Clipboard

Toggle word wrap

18.5.5. Intel Columbiaville E800 series NIC comme référence d'horloge ordinaire PTP
Copier lien

Le tableau suivant décrit les modifications que vous devez apporter à la configuration PTP de référence afin d'utiliser les cartes d'interface réseau de la série Intel Columbiaville E800 comme horloges ordinaires. Apportez les modifications dans une ressource personnalisée (CR) PtpConfig que vous appliquez au cluster.

Expand

Tableau 18.3. Paramètres PTP recommandés pour Intel Columbiaville NIC
Configuration PTP	Réglage recommandé
`phc2sysOpts`	`-a -r -m -n 24 -N 8 -R 16`
`tx_timestamp_timeout`	`50`
`boundary_clock_jbod`	`0`

Note

Pour phc2sysOpts, -m imprime des messages à stdout. linuxptp-daemon DaemonSet analyse les journaux et génère des métriques Prometheus.

18.5.6. Configuration de l'ordonnancement des priorités FIFO pour le matériel PTP
Copier lien

Dans les télécoms ou autres configurations de déploiement nécessitant une faible latence, les threads du démon PTP s'exécutent dans un espace CPU restreint, aux côtés du reste des composants de l'infrastructure. Par défaut, les threads PTP s'exécutent avec la stratégie SCHED_OTHER. En cas de forte charge, ces threads risquent de ne pas bénéficier de la latence de planification dont ils ont besoin pour fonctionner sans erreur.

Pour atténuer les erreurs potentielles de latence d'ordonnancement, vous pouvez configurer les services linuxptp de l'opérateur PTP pour permettre aux threads de s'exécuter avec une politique SCHED_FIFO. Si SCHED_FIFO est défini pour un CR PtpConfig, alors ptp4l et phc2sys s'exécuteront dans le conteneur parent sous chrt avec une priorité définie par le champ ptpSchedulingPriority du CR PtpConfig.

Note

Le réglage de ptpSchedulingPolicy est facultatif et n'est nécessaire que si vous rencontrez des erreurs de latence.

Procédure

Modifier le profil PtpConfig CR :
```
oc edit PtpConfig -n openshift-ptp
```
```
$ oc edit PtpConfig -n openshift-ptp
```
Copy to Clipboard Toggle word wrap

Modifiez les champs ptpSchedulingPolicy et ptpSchedulingPriority:

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: <ptp_config_name>
  namespace: openshift-ptp
...
spec:
  profile:
  - name: "profile1"
...
    ptpSchedulingPolicy: SCHED_FIFO 
    ptpSchedulingPriority: 10

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: <ptp_config_name>
  namespace: openshift-ptp
...
spec:
  profile:
  - name: "profile1"
...
    ptpSchedulingPolicy: SCHED_FIFO

1


    ptpSchedulingPriority: 10

2

Copy to Clipboard

Toggle word wrap

1: Politique d'ordonnancement pour les processus ptp4l et phc2sys. Utilisez SCHED_FIFO sur les systèmes qui prennent en charge l'ordonnancement FIFO.
2: Requis. Définit la valeur entière 1-65 utilisée pour configurer la priorité FIFO pour les processus ptp4l et phc2sys.

Sauvegardez et quittez pour appliquer les changements à PtpConfig CR.

Vérification

Obtenir le nom du pod linuxptp-daemon et du nœud correspondant où la CR PtpConfig a été appliquée :

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-gmv2n           3/3     Running   0          1d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-lgm55           3/3     Running   0          1d17h   10.1.196.25   compute-1.example.com
ptp-operator-3r4dcvf7f4-zndk7   1/1     Running   0          1d7h    10.129.0.61   control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-gmv2n           3/3     Running   0          1d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-lgm55           3/3     Running   0          1d17h   10.1.196.25   compute-1.example.com
ptp-operator-3r4dcvf7f4-zndk7   1/1     Running   0          1d7h    10.129.0.61   control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

Vérifier que le processus ptp4l s'exécute avec la priorité FIFO mise à jour de chrt:

oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrt

$ oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrt

Copy to Clipboard

Toggle word wrap

Exemple de sortie

I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2  --summary_interval -4 -m

I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2  --summary_interval -4 -m

Copy to Clipboard

Toggle word wrap

18.5.7. Configuration du filtrage des journaux pour les services linuxptp
Copier lien

Le démon linuxptp génère des journaux que vous pouvez utiliser à des fins de débogage. Dans les télécoms ou d'autres configurations de déploiement qui disposent d'une capacité de stockage limitée, ces journaux peuvent augmenter la demande de stockage.

Pour réduire le nombre de messages de journalisation, vous pouvez configurer la ressource personnalisée (CR) PtpConfig afin d'exclure les messages de journalisation qui indiquent la valeur master offset. Le message master offset indique la différence entre l'horloge du nœud actuel et l'horloge principale en nanosecondes.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
Installer l'opérateur PTP.

Procédure

Modifier le CR PtpConfig:
```
oc edit PtpConfig -n openshift-ptp
```
```
$ oc edit PtpConfig -n openshift-ptp
```
Copy to Clipboard Toggle word wrap

Dans spec.profile, ajoutez la spécification ptpSettings.logReduce et fixez la valeur à true:

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: <ptp_config_name>
  namespace: openshift-ptp
...
spec:
  profile:
  - name: "profile1"
...
    ptpSettings:
      logReduce: "true"

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: <ptp_config_name>
  namespace: openshift-ptp
...
spec:
  profile:
  - name: "profile1"
...
    ptpSettings:
      logReduce: "true"

Copy to Clipboard

Toggle word wrap

Note

À des fins de débogage, vous pouvez renvoyer cette spécification à False pour inclure les messages de décalage du maître.

Sauvegardez et quittez pour appliquer les changements à PtpConfig CR.

Vérification

Obtenir le nom du pod linuxptp-daemon et du nœud correspondant où la CR PtpConfig a été appliquée :

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-gmv2n           3/3     Running   0          1d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-lgm55           3/3     Running   0          1d17h   10.1.196.25   compute-1.example.com
ptp-operator-3r4dcvf7f4-zndk7   1/1     Running   0          1d7h    10.129.0.61   control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-gmv2n           3/3     Running   0          1d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-lgm55           3/3     Running   0          1d17h   10.1.196.25   compute-1.example.com
ptp-operator-3r4dcvf7f4-zndk7   1/1     Running   0          1d7h    10.129.0.61   control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

Vérifiez que les messages de décalage du maître sont exclus des journaux en exécutant la commande suivante :
```
oc -n openshift-ptp logs <linux_daemon_container> -c linuxptp-daemon-container | grep "master offset"
```
```
$ oc -n openshift-ptp logs <linux_daemon_container> -c linuxptp-daemon-container | grep "master offset" 
```
1
Copy to Clipboard Toggle word wrap
1
<linux_daemon_container> est le nom du pod linuxptp-daemon, par exemple linuxptp-daemon-gmv2n.
Lorsque vous configurez la spécification logReduce, cette commande ne signale aucune instance de master offset dans les journaux du démon linuxptp.

18.6. Dépannage des problèmes courants de l'opérateur PTP
Copier lien

Dépannez les problèmes courants de l'opérateur PTP en procédant comme suit.

Conditions préalables

Installez le CLI OpenShift Container Platform (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
Installez l'opérateur PTP sur un cluster bare-metal avec des hôtes qui prennent en charge PTP.

Procédure

Vérifiez que l'opérateur et les opérandes ont bien été déployés dans le cluster pour les nœuds configurés.

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

Note

Lorsque le bus d'événements rapides PTP est activé, le nombre de pods linuxptp-daemon prêts est 3/3. Si le bus d'événements rapides PTP n'est pas activé, 2/2 est affiché.

Vérifiez que le matériel pris en charge est présent dans le cluster.

oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io

$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                  AGE
control-plane-0.example.com           10d
control-plane-1.example.com           10d
compute-0.example.com                 10d
compute-1.example.com                 10d
compute-2.example.com                 10d

NAME                                  AGE
control-plane-0.example.com           10d
control-plane-1.example.com           10d
compute-0.example.com                 10d
compute-1.example.com                 10d
compute-2.example.com                 10d

Copy to Clipboard

Toggle word wrap

Vérifiez les interfaces réseau PTP disponibles pour un nœud :

oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yaml

oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yaml

Copy to Clipboard

Toggle word wrap

où :

<node_name>

Spécifie le nœud que vous souhaitez interroger, par exemple, compute-0.example.com.

Exemple de sortie

apiVersion: ptp.openshift.io/v1
kind: NodePtpDevice
metadata:
  creationTimestamp: "2021-09-14T16:52:33Z"
  generation: 1
  name: compute-0.example.com
  namespace: openshift-ptp
  resourceVersion: "177400"
  uid: 30413db0-4d8d-46da-9bef-737bacd548fd
spec: {}
status:
  devices:
  - name: eno1
  - name: eno2
  - name: eno3
  - name: eno4
  - name: enp5s0f0
  - name: enp5s0f1

apiVersion: ptp.openshift.io/v1
kind: NodePtpDevice
metadata:
  creationTimestamp: "2021-09-14T16:52:33Z"
  generation: 1
  name: compute-0.example.com
  namespace: openshift-ptp
  resourceVersion: "177400"
  uid: 30413db0-4d8d-46da-9bef-737bacd548fd
spec: {}
status:
  devices:
  - name: eno1
  - name: eno2
  - name: eno3
  - name: eno4
  - name: enp5s0f0
  - name: enp5s0f1

Copy to Clipboard

Toggle word wrap

Vérifiez que l'interface PTP est bien synchronisée avec l'horloge primaire en accédant au pod linuxptp-daemon pour le nœud correspondant.

Obtenez le nom du pod linuxptp-daemon et du nœud correspondant que vous souhaitez dépanner en exécutant la commande suivante :

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

Remote shell dans le conteneur linuxptp-daemon requis :
```
oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>
```
```
oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>
```
Copy to Clipboard Toggle word wrap
où :
<linux_daemon_container>
est le conteneur que vous voulez diagnostiquer, par exemple linuxptp-daemon-lmvgn.

Dans la connexion shell à distance au conteneur linuxptp-daemon, utilisez l'outil PTP Management Client (pmc) pour diagnostiquer l'interface réseau. Exécutez la commande suivante pmc pour vérifier l'état de synchronisation du dispositif PTP, par exemple ptp4l.

pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'

# pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'

Copy to Clipboard

Toggle word wrap

Exemple de sortie lorsque le nœud est synchronisé avec succès sur l'horloge primaire

sending: GET PORT_DATA_SET
    40a6b7.fffe.166ef0-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
        portIdentity            40a6b7.fffe.166ef0-1
        portState               SLAVE
        logMinDelayReqInterval  -4
        peerMeanPathDelay       0
        logAnnounceInterval     -3
        announceReceiptTimeout  3
        logSyncInterval         -4
        delayMechanism          1
        logMinPdelayReqInterval -4
        versionNumber           2

sending: GET PORT_DATA_SET
    40a6b7.fffe.166ef0-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
        portIdentity            40a6b7.fffe.166ef0-1
        portState               SLAVE
        logMinDelayReqInterval  -4
        peerMeanPathDelay       0
        logAnnounceInterval     -3
        announceReceiptTimeout  3
        logSyncInterval         -4
        delayMechanism          1
        logMinPdelayReqInterval -4
        versionNumber           2

Copy to Clipboard

Toggle word wrap

18.7. Cadre de notification des événements rapides du matériel PTP
Copier lien

18.7.1. A propos du PTP et des erreurs de synchronisation d'horloge
Copier lien

Les applications natives de l'informatique en nuage, telles que le RAN virtuel, nécessitent l'accès à des notifications sur les événements de synchronisation du matériel qui sont essentiels au fonctionnement de l'ensemble du réseau. Les notifications d'événements rapides sont des signaux d'alerte précoce concernant des événements de synchronisation d'horloge PTP (Precision Time Protocol) imminents et en temps réel. Les erreurs de synchronisation d'horloge PTP peuvent affecter négativement la performance et la fiabilité de votre application à faible latence, par exemple, une application vRAN fonctionnant dans une unité distribuée (DU).

La perte de synchronisation PTP est une erreur critique pour un réseau RAN. Si la synchronisation est perdue sur un nœud, la radio peut être arrêtée et le trafic OTA (Over the Air) du réseau peut être déplacé vers un autre nœud du réseau sans fil. Les notifications d'événements rapides atténuent les erreurs de charge de travail en permettant aux nœuds de cluster de communiquer l'état de la synchronisation de l'horloge PTP à l'application vRAN exécutée dans l'unité centrale.

Les notifications d'événements sont disponibles pour les applications RAN fonctionnant sur le même nœud DU. Une API REST de type "publish/subscribe" transmet les notifications d'événements au bus de messagerie. La messagerie par publication/abonnement, ou messagerie pub/sub, est une architecture de communication asynchrone de service à service dans laquelle tout message publié sur un sujet est immédiatement reçu par tous les abonnés au sujet.

Des notifications d'événements rapides sont générées par l'opérateur PTP dans OpenShift Container Platform pour chaque interface réseau compatible PTP. Les événements sont mis à disposition à l'aide d'un conteneur sidecar cloud-event-proxy sur un bus de messages AMQP (Advanced Message Queuing Protocol). Le bus de messages AMQP est fourni par l'opérateur d'interconnexion AMQ.

Note

Les notifications d'événements rapides PTP sont disponibles pour les interfaces réseau configurées pour utiliser des horloges ordinaires PTP ou des horloges limites PTP.

18.7.2. À propos du cadre de notifications d'événements rapides PTP
Copier lien

Vous pouvez abonner des applications d'unités distribuées (DU) aux notifications d'événements rapides du protocole Precision Time Protocol (PTP) générées par OpenShift Container Platform avec le conteneur PTP Operator et cloud-event-proxy sidecar. Vous activez le conteneur sidecar cloud-event-proxy en définissant le champ enableEventPublisher sur true dans la ressource personnalisée (CR) ptpOperatorConfig et en spécifiant une adresse AMQP (Advanced Message Queuing Protocol) transportHost. Les événements rapides PTP utilisent un bus de notification d'événements AMQP fourni par l'opérateur AMQ Interconnect. AMQ Interconnect est un composant de Red Hat AMQ, un routeur de messagerie qui fournit un routage flexible des messages entre tous les points d'extrémité compatibles avec AMQP. Une vue d'ensemble du cadre des événements rapides PTP est présentée ci-dessous :

Figure 18.1. Vue d'ensemble des événements rapides PTP

Le conteneur sidecar cloud-event-proxy peut accéder aux mêmes ressources que l'application vRAN principale sans utiliser aucune des ressources de l'application principale et sans latence significative.

Le cadre de notifications d'événements rapides utilise une API REST pour la communication et est basé sur la spécification de l'API REST O-RAN. Le cadre se compose d'un éditeur, d'un abonné et d'un bus de messagerie AMQ pour gérer les communications entre les applications de l'éditeur et de l'abonné. Le sidecar cloud-event-proxy est un conteneur utilitaire qui s'exécute dans un pod faiblement couplé au conteneur d'application DU principal sur le nœud DU. Il fournit un cadre de publication d'événements qui vous permet d'abonner les applications DU aux événements PTP publiés.

Les applications DU exécutent le conteneur cloud-event-proxy dans un modèle de sidecar pour s'abonner aux événements PTP. Le flux de travail suivant décrit comment une application DU utilise les événements rapides PTP :

DU application requests a subscription: Le DU envoie une requête API au sidecar cloud-event-proxy pour créer un abonnement aux événements PTP. Le sidecar cloud-event-proxy crée une ressource d'abonnement.
cloud-event-proxy sidecar creates the subscription: La ressource d'événement est conservée par le sidecar cloud-event-proxy. Le conteneur sidecar cloud-event-proxy envoie un accusé de réception avec un ID et une URL permettant d'accéder à la ressource d'abonnement stockée. Le sidecar crée un protocole d'écoute de messagerie AMQ pour la ressource spécifiée dans l'abonnement.
DU application receives the PTP event notification: Le conteneur sidecar cloud-event-proxy écoute l'adresse spécifiée dans le qualificateur de ressource. Le consommateur d'événements DU traite le message et le transmet à l'URL de retour spécifiée dans l'abonnement.
cloud-event-proxy sidecar validates the PTP event and posts it to the DU application: Le sidecar cloud-event-proxy reçoit l'événement, déballe l'objet "cloud events" pour récupérer les données et récupère l'URL de retour pour renvoyer l'événement à l'application consommateur de l'UA.
DU application uses the PTP event: Le consommateur d'événements de l'application DU reçoit et traite l'événement PTP.

18.7.3. Installation du bus de messagerie AMQ
Copier lien

Pour transmettre des notifications d'événements rapides PTP entre l'éditeur et l'abonné sur un nœud, vous devez installer et configurer un bus de messagerie AMQ pour qu'il fonctionne localement sur le nœud. Pour ce faire, vous devez installer l'opérateur d'interconnexion AMQ à utiliser dans le cluster.

Conditions préalables

Installez le CLI OpenShift Container Platform (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Installez l'opérateur d'interconnexion AMQ dans son propre espace de noms amq-interconnect. Voir Ajouter l'intégration Red Hat - Opérateur d'interconnexion AMQ.

Vérification

Vérifiez que l'opérateur d'interconnexion AMQ est disponible et que les pods requis sont en cours d'exécution :

oc get pods -n amq-interconnect

$ oc get pods -n amq-interconnect

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                    READY   STATUS    RESTARTS   AGE
amq-interconnect-645db76c76-k8ghs       1/1     Running   0          23h
interconnect-operator-5cb5fc7cc-4v7qm   1/1     Running   0          23h

NAME                                    READY   STATUS    RESTARTS   AGE
amq-interconnect-645db76c76-k8ghs       1/1     Running   0          23h
interconnect-operator-5cb5fc7cc-4v7qm   1/1     Running   0          23h

Copy to Clipboard

Toggle word wrap

Vérifiez que les pods producteurs d'événements linuxptp-daemon PTP requis sont exécutés dans l'espace de noms openshift-ptp.

oc get pods -n openshift-ptp

$ oc get pods -n openshift-ptp

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                     READY   STATUS    RESTARTS       AGE
linuxptp-daemon-2t78p    3/3     Running   0              12h
linuxptp-daemon-k8n88    3/3     Running   0              12h

NAME                     READY   STATUS    RESTARTS       AGE
linuxptp-daemon-2t78p    3/3     Running   0              12h
linuxptp-daemon-k8n88    3/3     Running   0              12h

Copy to Clipboard

Toggle word wrap

18.7.4. Configuration de l'éditeur de notifications d'événements rapides PTP
Copier lien

Pour commencer à utiliser les notifications d'événements rapides PTP pour une interface réseau dans votre cluster, vous devez activer l'éditeur d'événements rapides dans la ressource personnalisée (CR) PTP Operator PtpOperatorConfig et configurer les valeurs ptpClockThreshold dans une CR PtpConfig que vous créez.

Conditions préalables

Installez le CLI OpenShift Container Platform (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
Installer l'opérateur PTP et l'opérateur d'interconnexion AMQ.

Procédure

Modifier la configuration par défaut de l'opérateur PTP pour activer les événements rapides PTP.

Enregistrez le YAML suivant dans le fichier ptp-operatorconfig.yaml:

apiVersion: ptp.openshift.io/v1
kind: PtpOperatorConfig
metadata:
  name: default
  namespace: openshift-ptp
spec:
  daemonNodeSelector:
    node-role.kubernetes.io/worker: ""
  ptpEventConfig:
    enableEventPublisher: true 
    transportHost: amqp://<instance_name>.<namespace>.svc.cluster.local

apiVersion: ptp.openshift.io/v1
kind: PtpOperatorConfig
metadata:
  name: default
  namespace: openshift-ptp
spec:
  daemonNodeSelector:
    node-role.kubernetes.io/worker: ""
  ptpEventConfig:
    enableEventPublisher: true

1


    transportHost: amqp://<instance_name>.<namespace>.svc.cluster.local

2

Copy to Clipboard

Toggle word wrap

1: Réglez enableEventPublisher sur true pour activer les notifications d'événements rapides PTP.
2: Définissez transportHost comme étant le routeur AMQ que vous avez configuré, où <instance_name> et <namespace> correspondent au nom de l'instance du routeur AMQ Interconnect et à l'espace de noms, par exemple, amqp://amq-interconnect.amq-interconnect.svc.cluster.local

Mettre à jour le CR PtpOperatorConfig:
```
oc apply -f ptp-operatorconfig.yaml
```
```
$ oc apply -f ptp-operatorconfig.yaml
```
Copy to Clipboard Toggle word wrap

Créez une ressource personnalisée (CR) PtpConfig pour l'interface activée par PTP et définissez les valeurs requises pour ptpClockThreshold et ptp4lOpts. Le fichier YAML suivant illustre les valeurs requises que vous devez définir dans la CR PtpConfig:
```
spec:
  profile:
  - name: "profile1"
    interface: "enp5s0f0"
    ptp4lOpts: "-2 -s --summary_interval -4" 
    phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 
    ptp4lConf: "" 
  ptpClockThreshold: 
    holdOverTimeout: 5
    maxOffsetThreshold: 100
    minOffsetThreshold: -100
```
```
spec:
  profile:
  - name: "profile1"
    interface: "enp5s0f0"
    ptp4lOpts: "-2 -s --summary_interval -4" 
```
1
```
    phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 
```
2
```
    ptp4lConf: "" 
```
3
```
  ptpClockThreshold: 
```
4
```
    holdOverTimeout: 5
    maxOffsetThreshold: 100
    minOffsetThreshold: -100
```
Copy to Clipboard Toggle word wrap
1
Ajouter --summary_interval -4 pour utiliser les événements rapides PTP.
2
Valeurs requises phc2sysOpts. -m imprime des messages à stdout. linuxptp-daemon DaemonSet analyse les journaux et génère des métriques Prometheus.
3
Spécifiez une chaîne contenant la configuration qui remplacera le fichier /etc/ptp4l.conf par défaut. Pour utiliser la configuration par défaut, laissez le champ vide.
4
Facultatif. Si la strophe ptpClockThreshold n'est pas présente, des valeurs par défaut sont utilisées pour les champs ptpClockThreshold. La strophe indique les valeurs par défaut de ptpClockThreshold. Les valeurs de ptpClockThreshold configurent le délai de déclenchement des événements PTP après la déconnexion de l'horloge maître PTP. holdOverTimeout est la valeur de temps en secondes avant que l'état de l'événement de l'horloge PTP ne passe à FREERUN lorsque l'horloge maître PTP est déconnectée. Les paramètres maxOffsetThreshold et minOffsetThreshold configurent des valeurs de décalage en nanosecondes qui se comparent aux valeurs de CLOCK_REALTIME (phc2sys) ou au décalage du maître (ptp4l). Lorsque la valeur de décalage ptp4l ou phc2sys est en dehors de cette plage, l'état de l'horloge PTP est réglé sur FREERUN. Lorsque la valeur de décalage est comprise dans cette plage, l'état de l'horloge PTP est réglé sur LOCKED.

18.7.5. Abonnement des applications DU aux événements PTP Référence de l'API REST
Copier lien

Utilisez l'API REST de notifications d'événements PTP pour abonner une application d'unité distribuée (UD) aux événements PTP générés sur le nœud parent.

Abonner les applications aux événements PTP en utilisant l'adresse de ressource /cluster/node/<node_name>/ptp, où <node_name> est le nœud de cluster qui exécute l'application DU.

Déployez votre conteneur d'application DU cloud-event-consumer et votre conteneur sidecar cloud-event-proxy dans un pod d'application DU séparé. L'application DU cloud-event-consumer s'abonne au conteneur cloud-event-proxy dans le module d'application.

Utilisez les points d'extrémité API suivants pour abonner l'application DU cloud-event-consumer aux événements PTP publiés par le conteneur cloud-event-proxy à http://localhost:8089/api/ocloudNotifications/v1/ dans le pod d'application DU :

/api/ocloudNotifications/v1/subscriptions
- POST: Crée un nouvel abonnement
- GET: Récupère une liste d'abonnements
/api/ocloudNotifications/v1/subscriptions/<subscription_id>
- GET: Renvoie les détails de l'identifiant d'abonnement spécifié
api/ocloudNotifications/v1/subscriptions/status/<subscription_id>
- PUT: Crée une nouvelle demande de ping d'état pour l'identifiant d'abonnement spécifié
/api/ocloudNotifications/v1/health
- GET: Renvoie l'état de santé de ocloudNotifications API
api/ocloudNotifications/v1/publishers
- GET: Renvoie un tableau de messages os-clock-sync-state, ptp-clock-class-change, et lock-state pour le nœud de la grappe
/api/ocloudnotifications/v1/<resource_address>/CurrentState
- GET: Renvoie l'état actuel de l'un des types d'événements suivants : os-clock-sync-state ptp-clock-class-change , ou lock-state

Note

9089 est le port par défaut du conteneur cloud-event-consumer déployé dans le pod d'application. Vous pouvez configurer un port différent pour votre application DU si nécessaire.

18.7.5.1. api/ocloudNotifications/v1/subscriptions
Copier lien

Méthode HTTP

GET api/ocloudNotifications/v1/subscriptions

Description

Renvoie une liste d'abonnements. Si des abonnements existent, un code d'état 200 OK est renvoyé avec la liste des abonnements.

Exemple de réponse API

[
 {
  "id": "75b1ad8f-c807-4c23-acf5-56f4b7ee3826",
  "endpointUri": "http://localhost:9089/event",
  "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/75b1ad8f-c807-4c23-acf5-56f4b7ee3826",
  "resource": "/cluster/node/compute-1.example.com/ptp"
 }
]

[
 {
  "id": "75b1ad8f-c807-4c23-acf5-56f4b7ee3826",
  "endpointUri": "http://localhost:9089/event",
  "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/75b1ad8f-c807-4c23-acf5-56f4b7ee3826",
  "resource": "/cluster/node/compute-1.example.com/ptp"
 }
]

Copy to Clipboard

Toggle word wrap

Méthode HTTP

POST api/ocloudNotifications/v1/subscriptions

Description

Crée un nouvel abonnement. Si un abonnement est créé avec succès, ou s'il existe déjà, un code d'état 201 Created est renvoyé.

Expand

Tableau 18.4. Paramètres d'interrogation
Paramètres	Type
abonnement	données

Exemple de charge utile

{
  "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions",
  "resource": "/cluster/node/compute-1.example.com/ptp"
}

{
  "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions",
  "resource": "/cluster/node/compute-1.example.com/ptp"
}

Copy to Clipboard

Toggle word wrap

18.7.5.2. api/ocloudNotifications/v1/abonnements/
Copier lien

Méthode HTTP

GET api/ocloudNotifications/v1/subscriptions/<subscription_id>

Description

Renvoie les détails de l'abonnement avec l'ID <subscription_id>

Expand

Tableau 18.5. Paramètres d'interrogation
Paramètres	Type
`<subscription_id>`	chaîne de caractères

Exemple de réponse API

{
  "id":"48210fb3-45be-4ce0-aa9b-41a0e58730ab",
  "endpointUri": "http://localhost:9089/event",
  "uriLocation":"http://localhost:8089/api/ocloudNotifications/v1/subscriptions/48210fb3-45be-4ce0-aa9b-41a0e58730ab",
  "resource":"/cluster/node/compute-1.example.com/ptp"
}

{
  "id":"48210fb3-45be-4ce0-aa9b-41a0e58730ab",
  "endpointUri": "http://localhost:9089/event",
  "uriLocation":"http://localhost:8089/api/ocloudNotifications/v1/subscriptions/48210fb3-45be-4ce0-aa9b-41a0e58730ab",
  "resource":"/cluster/node/compute-1.example.com/ptp"
}

Copy to Clipboard

Toggle word wrap

18.7.5.3. api/ocloudNotifications/v1/abonnements/status/
Copier lien

Méthode HTTP

PUT api/ocloudNotifications/v1/subscriptions/status/<subscription_id>

Description

Crée une nouvelle demande de ping d'état pour l'abonnement avec l'ID <subscription_id>. Si un abonnement est présent, la demande d'état est réussie et le code d'état 202 Accepted est renvoyé.

Expand

Tableau 18.6. Paramètres d'interrogation
Paramètres	Type
`<subscription_id>`	chaîne de caractères

Exemple de réponse API

{"status":"ping sent"}

{"status":"ping sent"}

Copy to Clipboard

Toggle word wrap

18.7.5.4. api/ocloudNotifications/v1/santé/
Copier lien

Méthode HTTP

GET api/ocloudNotifications/v1/health/

Description

Renvoie l'état de santé de l'API REST ocloudNotifications.

Exemple de réponse API

OK

OK

Copy to Clipboard

Toggle word wrap

18.7.5.5. api/ocloudNotifications/v1/publishers
Copier lien

Méthode HTTP

GET api/ocloudNotifications/v1/publishers

Description

Renvoie un tableau de détails os-clock-sync-state, ptp-clock-class-change, et lock-state pour le nœud de cluster. Le système génère des notifications lorsque l'état de l'équipement concerné change.

os-clock-sync-state les notifications décrivent l'état de synchronisation de l'horloge du système d'exploitation hôte. Peut être dans l'état LOCKED ou FREERUN.
ptp-clock-class-change décrivent l'état actuel de la classe d'horloge PTP.
lock-state les notifications décrivent l'état actuel du verrouillage de l'équipement PTP. Il peut s'agir de l'état LOCKED, HOLDOVER ou FREERUN.

Exemple de réponse API

[
  {
    "id": "0fa415ae-a3cf-4299-876a-589438bacf75",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/0fa415ae-a3cf-4299-876a-589438bacf75",
    "resource": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state"
  },
  {
    "id": "28cd82df-8436-4f50-bbd9-7a9742828a71",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/28cd82df-8436-4f50-bbd9-7a9742828a71",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change"
  },
  {
    "id": "44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state"
  }
]

[
  {
    "id": "0fa415ae-a3cf-4299-876a-589438bacf75",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/0fa415ae-a3cf-4299-876a-589438bacf75",
    "resource": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state"
  },
  {
    "id": "28cd82df-8436-4f50-bbd9-7a9742828a71",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/28cd82df-8436-4f50-bbd9-7a9742828a71",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change"
  },
  {
    "id": "44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state"
  }
]

Copy to Clipboard

Toggle word wrap

Vous pouvez trouver les événements os-clock-sync-state, ptp-clock-class-change et lock-state dans les journaux du conteneur cloud-event-proxy. Par exemple :

oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy

$ oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy

Copy to Clipboard

Toggle word wrap

Exemple d'événement os-clock-sync-state

{
   "id":"c8a784d1-5f4a-4c16-9a81-a3b4313affe5",
   "type":"event.sync.sync-status.os-clock-sync-state-change",
   "source":"/cluster/compute-1.example.com/ptp/CLOCK_REALTIME",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.906277159Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/sync-status/os-clock-sync-state",
            "dataType":"notification",
            "valueType":"enumeration",
            "value":"LOCKED"
         },
         {
            "resource":"/sync/sync-status/os-clock-sync-state",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"-53"
         }
      ]
   }
}

{
   "id":"c8a784d1-5f4a-4c16-9a81-a3b4313affe5",
   "type":"event.sync.sync-status.os-clock-sync-state-change",
   "source":"/cluster/compute-1.example.com/ptp/CLOCK_REALTIME",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.906277159Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/sync-status/os-clock-sync-state",
            "dataType":"notification",
            "valueType":"enumeration",
            "value":"LOCKED"
         },
         {
            "resource":"/sync/sync-status/os-clock-sync-state",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"-53"
         }
      ]
   }
}

Copy to Clipboard

Toggle word wrap

Exemple d'événement ptp-clock-class-change

{
   "id":"69eddb52-1650-4e56-b325-86d44688d02b",
   "type":"event.sync.ptp-status.ptp-clock-class-change",
   "source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.147100033Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/ptp-status/ptp-clock-class-change",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"135"
         }
      ]
   }
}

{
   "id":"69eddb52-1650-4e56-b325-86d44688d02b",
   "type":"event.sync.ptp-status.ptp-clock-class-change",
   "source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.147100033Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/ptp-status/ptp-clock-class-change",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"135"
         }
      ]
   }
}

Copy to Clipboard

Toggle word wrap

Exemple d'événement d'état de blocage

{
   "id":"305ec18b-1472-47b3-aadd-8f37933249a9",
   "type":"event.sync.ptp-status.ptp-state-change",
   "source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.467684081Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/ptp-status/lock-state",
            "dataType":"notification",
            "valueType":"enumeration",
            "value":"LOCKED"
         },
         {
            "resource":"/sync/ptp-status/lock-state",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"62"
         }
      ]
   }
}

{
   "id":"305ec18b-1472-47b3-aadd-8f37933249a9",
   "type":"event.sync.ptp-status.ptp-state-change",
   "source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.467684081Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/ptp-status/lock-state",
            "dataType":"notification",
            "valueType":"enumeration",
            "value":"LOCKED"
         },
         {
            "resource":"/sync/ptp-status/lock-state",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"62"
         }
      ]
   }
}

Copy to Clipboard

Toggle word wrap

18.7.5.6. /api/ocloudnotifications/v1//CurrentState
Copier lien

Méthode HTTP

GET api/ocloudNotifications/v1/cluster/node/<node_name>/sync/ptp-status/lock-state/CurrentState

GET api/ocloudNotifications/v1/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state/CurrentState

GET api/ocloudNotifications/v1/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change/CurrentState

Description

Configurez le point de terminaison de l'API CurrentState pour qu'il renvoie l'état actuel des événements os-clock-sync-state, ptp-clock-class-change ou lock-state pour le nœud de cluster.

os-clock-sync-state les notifications décrivent l'état de synchronisation de l'horloge du système d'exploitation hôte. Peut être dans l'état LOCKED ou FREERUN.
ptp-clock-class-change décrivent l'état actuel de la classe d'horloge PTP.
lock-state les notifications décrivent l'état actuel du verrouillage de l'équipement PTP. Il peut s'agir de l'état LOCKED, HOLDOVER ou FREERUN.

Expand

Tableau 18.7. Paramètres d'interrogation
Paramètres	Type
`<resource_address>`	chaîne de caractères

Exemple de réponse de l'API sur l'état de verrouillage

{
  "id": "c1ac3aa5-1195-4786-84f8-da0ea4462921",
  "type": "event.sync.ptp-status.ptp-state-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:57.094981478Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "29"
      }
    ]
  }
}

{
  "id": "c1ac3aa5-1195-4786-84f8-da0ea4462921",
  "type": "event.sync.ptp-status.ptp-state-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:57.094981478Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "29"
      }
    ]
  }
}

Copy to Clipboard

Toggle word wrap

Exemple de réponse de l'API os-clock-sync-state

{
  "specversion": "0.3",
  "id": "4f51fe99-feaa-4e66-9112-66c5c9b9afcb",
  "source": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "type": "event.sync.sync-status.os-clock-sync-state-change",
  "subject": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "datacontenttype": "application/json",
  "time": "2022-11-29T17:44:22.202Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "27"
      }
    ]
  }
}

{
  "specversion": "0.3",
  "id": "4f51fe99-feaa-4e66-9112-66c5c9b9afcb",
  "source": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "type": "event.sync.sync-status.os-clock-sync-state-change",
  "subject": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "datacontenttype": "application/json",
  "time": "2022-11-29T17:44:22.202Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "27"
      }
    ]
  }
}

Copy to Clipboard

Toggle word wrap

Exemple de réponse API ptp-clock-class-change

{
  "id": "064c9e67-5ad4-4afb-98ff-189c6aa9c205",
  "type": "event.sync.ptp-status.ptp-clock-class-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:56.785673989Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "165"
      }
    ]
  }
}

{
  "id": "064c9e67-5ad4-4afb-98ff-189c6aa9c205",
  "type": "event.sync.ptp-status.ptp-clock-class-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:56.785673989Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "165"
      }
    ]
  }
}

Copy to Clipboard

Toggle word wrap

18.7.6. Surveillance des mesures d'événements rapides PTP à l'aide du CLI
Copier lien

Vous pouvez surveiller les métriques du bus d'événements rapides directement à partir des conteneurs cloud-event-proxy à l'aide du CLI oc.

Note

Les mesures de notification des événements rapides PTP sont également disponibles dans la console web d'OpenShift Container Platform.

Conditions préalables

Installez le CLI OpenShift Container Platform (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
Installer et configurer l'opérateur PTP.

Procédure

Obtenir la liste des pods linuxptp-daemon actifs.

oc get pods -n openshift-ptp

$ oc get pods -n openshift-ptp

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                    READY   STATUS    RESTARTS   AGE
linuxptp-daemon-2t78p   3/3     Running   0          8h
linuxptp-daemon-k8n88   3/3     Running   0          8h

NAME                    READY   STATUS    RESTARTS   AGE
linuxptp-daemon-2t78p   3/3     Running   0          8h
linuxptp-daemon-k8n88   3/3     Running   0          8h

Copy to Clipboard

Toggle word wrap

Accédez aux métriques du conteneur cloud-event-proxy requis en exécutant la commande suivante :

oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics

oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics

Copy to Clipboard

Toggle word wrap

où :

<linuxptp-daemon>

Spécifie le pod que vous voulez interroger, par exemple, linuxptp-daemon-2t78p.

Exemple de sortie

# HELP cne_amqp_events_published Metric to get number of events published by the transport
# TYPE cne_amqp_events_published gauge
cne_amqp_events_published{address="/cluster/node/compute-1.example.com/ptp/status",status="success"} 1041
# HELP cne_amqp_events_received Metric to get number of events received  by the transport
# TYPE cne_amqp_events_received gauge
cne_amqp_events_received{address="/cluster/node/compute-1.example.com/ptp",status="success"} 1019
# HELP cne_amqp_receiver Metric to get number of receiver created
# TYPE cne_amqp_receiver gauge
cne_amqp_receiver{address="/cluster/node/mock",status="active"} 1
cne_amqp_receiver{address="/cluster/node/compute-1.example.com/ptp",status="active"} 1
cne_amqp_receiver{address="/cluster/node/compute-1.example.com/redfish/event",status="active"}
...

# HELP cne_amqp_events_published Metric to get number of events published by the transport
# TYPE cne_amqp_events_published gauge
cne_amqp_events_published{address="/cluster/node/compute-1.example.com/ptp/status",status="success"} 1041
# HELP cne_amqp_events_received Metric to get number of events received  by the transport
# TYPE cne_amqp_events_received gauge
cne_amqp_events_received{address="/cluster/node/compute-1.example.com/ptp",status="success"} 1019
# HELP cne_amqp_receiver Metric to get number of receiver created
# TYPE cne_amqp_receiver gauge
cne_amqp_receiver{address="/cluster/node/mock",status="active"} 1
cne_amqp_receiver{address="/cluster/node/compute-1.example.com/ptp",status="active"} 1
cne_amqp_receiver{address="/cluster/node/compute-1.example.com/redfish/event",status="active"}
...

Copy to Clipboard

Toggle word wrap

18.7.7. Surveillance des mesures d'événements rapides PTP dans la console web
Copier lien

Vous pouvez surveiller les métriques d'événements rapides PTP dans la console web OpenShift Container Platform en utilisant la pile de surveillance Prometheus préconfigurée et auto-actualisée.

Conditions préalables

Install the OpenShift Container Platform CLI oc.
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Entrez la commande suivante pour renvoyer la liste des mesures PTP disponibles à partir du conteneur sidecar cloud-event-proxy:
```
oc exec -it <linuxptp_daemon_pod> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics
```
```
oc exec -it <linuxptp_daemon_pod> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics
```
Copy to Clipboard Toggle word wrap
où :
<linuxptp_daemon_pod>
Spécifie le pod que vous voulez interroger, par exemple, linuxptp-daemon-2t78p.
Copiez le nom de la métrique PTP que vous souhaitez interroger dans la liste des métriques renvoyées, par exemple, cne_amqp_events_received.
Dans la console Web OpenShift Container Platform, cliquez sur Observe → Metrics.
Collez la métrique PTP dans le champ Expression et cliquez sur Run queries.

Chapitre 19. Opérateur DNS externe
Copier lien

19.1. Opérateur DNS externe dans OpenShift Container Platform
Copier lien

L'opérateur DNS externe déploie et gère ExternalDNS pour fournir la résolution de nom pour les services et les routes du fournisseur DNS externe à OpenShift Container Platform.

19.1.1. Opérateur DNS externe
Copier lien

L'opérateur DNS externe met en œuvre l'API DNS externe du groupe d'API olm.openshift.io. L'opérateur DNS externe déploie le site ExternalDNS à l'aide d'une ressource de déploiement. Le déploiement ExternalDNS surveille les ressources telles que les services et les routes dans le cluster et met à jour les fournisseurs DNS externes.

Procédure

Vous pouvez déployer l'opérateur ExternalDNS à la demande depuis l'OperatorHub, ce qui crée un objet Subscription.

Vérifier le nom d'un plan d'installation :

oc -n external-dns-operator get sub external-dns-operator -o yaml | yq '.status.installplan.name'

$ oc -n external-dns-operator get sub external-dns-operator -o yaml | yq '.status.installplan.name'

Copy to Clipboard

Toggle word wrap

Exemple de sortie

install-zcvlr

install-zcvlr

Copy to Clipboard

Toggle word wrap

Vérifier le statut d'un plan d'installation, le statut d'un plan d'installation doit être Complete:
```
oc -n external-dns-operator get ip <install_plan_name> -o yaml | yq .status.phase'
```
```
$ oc -n external-dns-operator get ip <install_plan_name> -o yaml | yq .status.phase'
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
Complete
```
```
Complete
```
Copy to Clipboard Toggle word wrap

Utilisez la commande oc get pour visualiser l'état de Deployment:

oc get -n external-dns-operator deployment/external-dns-operator

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

Copy to Clipboard

Toggle word wrap

Exemple de sortie

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

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

Copy to Clipboard

Toggle word wrap

19.1.2. Journaux de l'opérateur DNS externe
Copier lien

Vous pouvez consulter les journaux de l'opérateur DNS externe à l'aide de la commande oc logs.

Procédure

Consulter les journaux de l'opérateur DNS externe :

oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operator

$ oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operator

Copy to Clipboard

Toggle word wrap

19.1.2.1. Limitations du nom de domaine de l'opérateur DNS externe
Copier lien

L'opérateur DNS externe utilise le registre TXT, qui suit le nouveau format et ajoute le préfixe pour les enregistrements TXT. Cela réduit la longueur maximale du nom de domaine pour les enregistrements TXT. Un enregistrement DNS ne peut être présent sans un enregistrement TXT correspondant, de sorte que le nom de domaine de l'enregistrement DNS doit respecter la même limite que les enregistrements TXT. Par exemple, l'enregistrement DNS est <domain-name-from-source> et l'enregistrement TXT est external-dns-<record-type>-<domain-name-from-source>.

Le nom de domaine des enregistrements DNS générés par l'Opérateur DNS externe est soumis aux limitations suivantes :

Expand

Type d'enregistrement	Nombre de caractères
CNAME	44
Enregistrements CNAME Wildcard sur AzureDNS	42
A	48
Enregistrements A Wildcard sur AzureDNS	46

Si le nom de domaine généré par le DNS externe dépasse la limite de nom de domaine, l'instance DNS externe affiche l'erreur suivante :

oc -n external-dns-operator logs external-dns-aws-7ddbd9c7f8-2jqjh

oc -n external-dns-operator logs external-dns-aws-7ddbd9c7f8-2jqjh

1

Copy to Clipboard

Toggle word wrap

1: Le paramètre external-dns-aws-7ddbd9c7f8-2jqjh spécifie le nom du module DNS externe.

Exemple de sortie

time="2022-09-02T08:53:57Z" level=info msg="Desired change: CREATE external-dns-cname-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc.test.example.io TXT [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=info msg="Desired change: CREATE external-dns-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc.test.example.io TXT [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=info msg="Desired change: CREATE hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc.test.example.io A [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=error msg="Failure in zone test.example.io. [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=error msg="InvalidChangeBatch: [FATAL problem: DomainLabelTooLong (Domain label is too long) encountered with 'external-dns-a-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc']\n\tstatus code: 400, request id: e54dfd5a-06c6-47b0-bcb9-a4f7c3a4e0c6"

time="2022-09-02T08:53:57Z" level=info msg="Desired change: CREATE external-dns-cname-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc.test.example.io TXT [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=info msg="Desired change: CREATE external-dns-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc.test.example.io TXT [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=info msg="Desired change: CREATE hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc.test.example.io A [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=error msg="Failure in zone test.example.io. [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=error msg="InvalidChangeBatch: [FATAL problem: DomainLabelTooLong (Domain label is too long) encountered with 'external-dns-a-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc']\n\tstatus code: 400, request id: e54dfd5a-06c6-47b0-bcb9-a4f7c3a4e0c6"

Copy to Clipboard

Toggle word wrap

19.2. Installation d'un opérateur DNS externe sur les fournisseurs de services en nuage
Copier lien

Vous pouvez installer External DNS Operator sur des fournisseurs de cloud tels que AWS, Azure et GCP.

19.2.1. Installation de l'opérateur DNS externe
Copier lien

Vous pouvez installer l'Opérateur DNS Externe en utilisant le OperatorHub de OpenShift Container Platform.

Procédure

Cliquez sur Operators → OperatorHub dans la console Web d'OpenShift Container Platform.
Cliquez sur External DNS Operator. Vous pouvez utiliser la zone de texte Filter by keyword ou la liste de filtres pour rechercher un opérateur DNS externe dans la liste des opérateurs.
Sélectionnez l'espace de noms external-dns-operator.
Sur la page Opérateur DNS externe, cliquez sur Install.
Sur la page Install Operator, assurez-vous que vous avez sélectionné les options suivantes :
1. Mettre à jour le canal à l'adresse stable-v1.
2. Mode d'installation comme A specific name on the cluster.
3. L'espace de noms installé est external-dns-operator. Si l'espace de noms external-dns-operator n'existe pas, il est créé lors de l'installation de l'opérateur.
4. Sélectionnez Approval Strategy comme Automatic ou Manual. La stratégie d'approbation est définie par défaut sur Automatic.
5. Cliquez sur Install.

Si vous sélectionnez Automatic updates, Operator Lifecycle Manager (OLM) met automatiquement à jour l'instance en cours d'exécution de votre opérateur sans aucune intervention.

Si vous sélectionnez Manual updates, l'OLM crée une demande de mise à jour. En tant qu'administrateur de cluster, vous devez ensuite approuver manuellement cette demande de mise à jour pour que l'opérateur soit mis à jour avec la nouvelle version.

Vérification

Vérifiez que l'opérateur DNS externe affiche le site Status comme Succeeded sur le tableau de bord des opérateurs installés.

19.3. Paramètres de configuration de l'opérateur DNS externe
Copier lien

Les opérateurs DNS externes comprennent les paramètres de configuration suivants :

19.3.1. Paramètres de configuration de l'opérateur DNS externe
Copier lien

L'opérateur DNS externe comprend les paramètres de configuration suivants :

Expand

Paramètres	Description
`spec`	Permet d'activer le type de fournisseur de nuages. `spec: provider: type: AWS` 1 `aws: credentials: name: aws-access-key` 2 Copy to Clipboard Toggle word wrap 1 Définit les options disponibles telles que AWS, GCP et Azure. 2 Définit le nom du site `secret` qui contient les informations d'identification de votre fournisseur de cloud.
`zones`	Permet de spécifier les zones DNS par leurs domaines. Si vous ne spécifiez pas de zones, `ExternalDNS` découvre toutes les zones présentes dans votre compte de fournisseur de cloud. `zones: - "myzoneid"` 1 Copy to Clipboard Toggle word wrap 1 Spécifie les ID des zones DNS.
`domains`	Permet de spécifier les zones AWS en fonction de leur domaine. Si vous ne spécifiez pas de domaines, `ExternalDNS` découvre toutes les zones présentes dans votre compte de fournisseur de cloud. `domains: - filterType: Include` 1 `matchType: Exact` 2 `name: "myzonedomain1.com"` 3 `- filterType: Include matchType: Pattern` 4 `pattern: ".*\\.otherzonedomain\\.com"` 5 Copy to Clipboard Toggle word wrap 1 Demande à `ExternalDNS` d'inclure le domaine spécifié. 2 Indique à `ExtrnalDNS` que la correspondance entre les domaines doit être exacte, contrairement à la correspondance par expression régulière. 3 Définit le nom de domaine exact par lequel `ExternalDNS` filtre. 4 Définit l'indicateur `regex-domain-filter` dans `ExternalDNS`. Vous pouvez limiter les domaines possibles en utilisant un filtre Regex. 5 Définit le modèle de regex à utiliser par `ExternalDNS` pour filtrer les domaines des zones cibles.
`source`	Permet de spécifier la source des enregistrements DNS, `Service` ou `Route`. `source:` 1 `type: Service` 2 `service: serviceType:` 3 `- LoadBalancer - ClusterIP labelFilter:` 4 `matchLabels: external-dns.mydomain.org/publish: "yes" hostnameAnnotation: "Allow"` 5 `fqdnTemplate: - "{{.Name}}.myzonedomain.com"` 6 Copy to Clipboard Toggle word wrap 1 Définit les paramètres de la source des enregistrements DNS. 2 Le site `ExternalDNS` utilise le type `Service` comme source pour créer des enregistrements DNS. 3 Définit l'indicateur `service-type-filter` dans `ExternalDNS`. Le site `serviceType` contient les champs suivants : `default`: `LoadBalancer` `expected`: `ClusterIP` `NodePort` `LoadBalancer` `ExternalName` 4 Veille à ce que le contrôleur ne prenne en compte que les ressources qui correspondent au filtre d'étiquettes. 5 La valeur par défaut de `hostnameAnnotation` est `Ignore`, ce qui indique à `ExternalDNS` de générer des enregistrements DNS à l'aide des modèles spécifiés dans le champ `fqdnTemplates`. Lorsque la valeur est `Allow`, les enregistrements DNS sont générés sur la base de la valeur spécifiée dans l'annotation `external-dns.alpha.kubernetes.io/hostname`. 6 L'opérateur DNS externe utilise une chaîne pour générer des noms DNS à partir de sources qui ne définissent pas de nom d'hôte, ou pour ajouter un suffixe de nom d'hôte lorsqu'il est associé à la fausse source. `source: type: OpenShiftRoute` 1 `openshiftRouteOptions: routerName: default` 2 `labelFilter: matchLabels: external-dns.mydomain.org/publish: "yes"` Copy to Clipboard Toggle word wrap 1 ExternalDNS` utilise le type `route` comme source pour créer des enregistrements dns. 2 Si la source est `OpenShiftRoute`, vous pouvez transmettre le nom du contrôleur d'entrée. Le site `ExternalDNS` utilise le nom canonique du contrôleur d'entrée comme cible de l'enregistrement CNAME.

19.4. Création d'enregistrements DNS sur AWS
Copier lien

Vous pouvez créer des enregistrements DNS sur AWS et AWS GovCloud en utilisant l'opérateur DNS externe.

19.4.1. Création d'enregistrements DNS sur une zone publique hébergée pour AWS à l'aide de l'Opérateur DNS Externe de Red Hat
Copier lien

Vous pouvez créer des enregistrements DNS sur une zone hébergée publique pour AWS en utilisant l'Opérateur DNS externe de Red Hat. Vous pouvez utiliser les mêmes instructions pour créer des enregistrements DNS sur une zone hébergée pour AWS GovCloud.

Procédure

Vérifiez l'utilisateur. L'utilisateur doit avoir accès à l'espace de noms kube-system. Si vous n'avez pas les informations d'identification, vous pouvez les récupérer dans l'espace de noms kube-system pour utiliser le client du fournisseur de cloud :
```
oc whoami
```
```
$ oc whoami
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
system:admin
```
```
system:admin
```
Copy to Clipboard Toggle word wrap

Récupérer les valeurs du secret aws-creds présent dans l'espace de noms kube-system.

export AWS_ACCESS_KEY_ID=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_access_key_id}} | base64 -d)
export AWS_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_secret_access_key}} | base64 -d)

$ export AWS_ACCESS_KEY_ID=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_access_key_id}} | base64 -d)
$ export AWS_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_secret_access_key}} | base64 -d)

Copy to Clipboard

Toggle word wrap

Obtenir les itinéraires pour vérifier le domaine :

oc get routes --all-namespaces | grep console

$ oc get routes --all-namespaces | grep console

Copy to Clipboard

Toggle word wrap

Exemple de sortie

openshift-console          console             console-openshift-console.apps.testextdnsoperator.apacshift.support                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.testextdnsoperator.apacshift.support                     downloads           http    edge/Redirect          None

openshift-console          console             console-openshift-console.apps.testextdnsoperator.apacshift.support                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.testextdnsoperator.apacshift.support                     downloads           http    edge/Redirect          None

Copy to Clipboard

Toggle word wrap

Obtenir la liste des zones DNS pour trouver celle qui correspond au domaine de la route trouvée précédemment :

aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support

$ aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support

Copy to Clipboard

Toggle word wrap

Exemple de sortie

HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support.	5

HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support.	5

Copy to Clipboard

Toggle word wrap

Créer une ressource ExternalDNS pour une source route:
```
$ cat <<EOF | oc create -f -
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-aws 
spec:
  domains:
  - filterType: Include   
    matchType: Exact   
    name: testextdnsoperator.apacshift.support 
  provider:
    type: AWS 
  source:  
    type: OpenShiftRoute 
    openshiftRouteOptions:
      routerName: default 
EOF
```
```
$ cat <<EOF | oc create -f -
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-aws 
```
1
```
spec:
  domains:
  - filterType: Include   
```
2
```
    matchType: Exact   
```
3
```
    name: testextdnsoperator.apacshift.support 
```
4
```
  provider:
    type: AWS 
```
5
```
  source:  
```
6
```
    type: OpenShiftRoute 
```
7
```
    openshiftRouteOptions:
      routerName: default 
```
8
```
EOF
```
Copy to Clipboard Toggle word wrap
1
Définit le nom de la ressource DNS externe.
2
Par défaut, toutes les zones hébergées sont sélectionnées comme cibles potentielles. Vous pouvez inclure une zone hébergée dont vous avez besoin.
3
La correspondance du domaine de la zone cible doit être exacte (par opposition à une correspondance par expression régulière).
4
Indiquez le domaine exact de la zone que vous souhaitez mettre à jour. Les noms d'hôte des routes doivent être des sous-domaines du domaine spécifié.
5
Définit le fournisseur DNS AWS Route53.
6
Définit les options pour la source des enregistrements DNS.
7
Définit la ressource OpenShift route comme source pour les enregistrements DNS qui sont créés dans le fournisseur DNS spécifié précédemment.
8
Si la source est OpenShiftRoute, alors vous pouvez passer le nom du contrôleur d'entrée d'OpenShift. L'opérateur DNS externe sélectionne le nom d'hôte canonique de ce routeur comme cible lors de la création de l'enregistrement CNAME.

Vérifiez les enregistrements créés pour les routes OCP à l'aide de la commande suivante :

aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console

$ aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console

Copy to Clipboard

Toggle word wrap

19.5. Création d'enregistrements DNS sur Azure
Copier lien

Vous pouvez créer des enregistrements DNS sur Azure à l'aide de l'opérateur DNS externe.

19.5.1. Création d'enregistrements DNS sur une zone DNS publique pour Azure à l'aide de Red Hat External DNS Operator
Copier lien

Vous pouvez créer des enregistrements DNS sur une zone DNS publique pour Azure en utilisant Red Hat External DNS Operator.

Procédure

Vérifiez l'utilisateur. L'utilisateur doit avoir accès à l'espace de noms kube-system. Si vous n'avez pas les informations d'identification, vous pouvez les récupérer dans l'espace de noms kube-system pour utiliser le client du fournisseur de cloud :
```
oc whoami
```
```
$ oc whoami
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
system:admin
```
```
system:admin
```
Copy to Clipboard Toggle word wrap

Récupère les valeurs du secret azure-credentials présent dans l'espace de noms kube-system.

CLIENT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_id}} | base64 -d)
CLIENT_SECRET=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_secret}} | base64 -d)
RESOURCE_GROUP=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_resourcegroup}} | base64 -d)
SUBSCRIPTION_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_subscription_id}} | base64 -d)
TENANT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_tenant_id}} | base64 -d)

$ CLIENT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_id}} | base64 -d)
$ CLIENT_SECRET=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_secret}} | base64 -d)
$ RESOURCE_GROUP=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_resourcegroup}} | base64 -d)
$ SUBSCRIPTION_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_subscription_id}} | base64 -d)
$ TENANT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_tenant_id}} | base64 -d)

Copy to Clipboard

Toggle word wrap

Se connecter à azure avec des valeurs décodées en base64 :

az login --service-principal -u "${CLIENT_ID}" -p "${CLIENT_SECRET}" --tenant "${TENANT_ID}"

$ az login --service-principal -u "${CLIENT_ID}" -p "${CLIENT_SECRET}" --tenant "${TENANT_ID}"

Copy to Clipboard

Toggle word wrap

Obtenir les itinéraires pour vérifier le domaine :

oc get routes --all-namespaces | grep console

$ oc get routes --all-namespaces | grep console

Copy to Clipboard

Toggle word wrap

Exemple de sortie

openshift-console          console             console-openshift-console.apps.test.azure.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.azure.example.com                     downloads           http    edge/Redirect          None

openshift-console          console             console-openshift-console.apps.test.azure.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.azure.example.com                     downloads           http    edge/Redirect          None

Copy to Clipboard

Toggle word wrap

Obtenir la liste des zones DNS pour trouver celle qui correspond au domaine de la route trouvée précédemment :
```
az network dns zone list --resource-group "${RESOURCE_GROUP}"
```
```
$ az network dns zone list --resource-group "${RESOURCE_GROUP}"
```
Copy to Clipboard Toggle word wrap

Créer une ressource ExternalDNS pour une source route:

apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-azure 
spec:
  zones:
  - "/subscriptions/1234567890/resourceGroups/test-azure-xxxxx-rg/providers/Microsoft.Network/dnszones/test.azure.example.com" 
  provider:
    type: Azure 
  source:
    openshiftRouteOptions: 
      routerName: default 
    type: OpenShiftRoute 
EOF

apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-azure

1


spec:
  zones:
  - "/subscriptions/1234567890/resourceGroups/test-azure-xxxxx-rg/providers/Microsoft.Network/dnszones/test.azure.example.com"

2


  provider:
    type: Azure

3


  source:
    openshiftRouteOptions:

4


      routerName: default

5


    type: OpenShiftRoute

6

EOF

Copy to Clipboard

Toggle word wrap

1: Spécifie le nom du DNS CR externe.
2: Définir l'ID de la zone.
3: Définit le fournisseur Azure DNS.
4: Vous pouvez définir des options pour la source des enregistrements DNS.
5: Si la source est OpenShiftRoute, vous pouvez passer le nom du contrôleur d'entrée d'OpenShift. Le DNS externe sélectionne le nom d'hôte canonique de ce routeur comme cible lors de la création de l'enregistrement CNAME.
6: Définit la ressource OpenShift route comme source pour les enregistrements DNS qui sont créés dans le fournisseur DNS spécifié précédemment.

Vérifiez les enregistrements créés pour les routes OCP à l'aide de la commande suivante :
```
az network dns record-set list -g "${RESOURCE_GROUP}"  -z test.azure.example.com | grep console
```
```
$ az network dns record-set list -g "${RESOURCE_GROUP}"  -z test.azure.example.com | grep console
```
Copy to Clipboard Toggle word wrap
Note
Pour créer des enregistrements sur des zones hébergées privées sur des dns Azure privés, vous devez spécifier la zone privée sous zones qui remplit le type de fournisseur à azure-private-dns dans les args du conteneur ExternalDNS.

19.6. Création d'enregistrements DNS sur GCP
Copier lien

Vous pouvez créer des enregistrements DNS sur GCP à l'aide de l'opérateur DNS externe.

19.6.1. Création d'enregistrements DNS sur une zone publique gérée pour GCP à l'aide de Red Hat External DNS Operator
Copier lien

Vous pouvez créer des enregistrements DNS sur une zone publique gérée pour GCP en utilisant Red Hat External DNS Operator.

Procédure

Vérifiez l'utilisateur. L'utilisateur doit avoir accès à l'espace de noms kube-system. Si vous n'avez pas les informations d'identification, vous pouvez les récupérer dans l'espace de noms kube-system pour utiliser le client du fournisseur de cloud :
```
oc whoami
```
```
$ oc whoami
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
system:admin
```
```
system:admin
```
Copy to Clipboard Toggle word wrap

Copiez la valeur de service_account.json dans gcp-credentials secret dans un fichier encoded-gcloud.json en exécutant la commande suivante :

oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.json

$ oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.json

Copy to Clipboard

Toggle word wrap

Exporter les informations d'identification Google :
```
export GOOGLE_CREDENTIALS=decoded-gcloud.json
```
```
$ export GOOGLE_CREDENTIALS=decoded-gcloud.json
```
Copy to Clipboard Toggle word wrap

Activez votre compte en utilisant la commande suivante :

gcloud auth activate-service-account  <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json

$ gcloud auth activate-service-account  <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json

Copy to Clipboard

Toggle word wrap

Définissez votre projet :

gcloud config set project <project_id as per decoded-gcloud.json>

$ gcloud config set project <project_id as per decoded-gcloud.json>

Copy to Clipboard

Toggle word wrap

Obtenir les itinéraires pour vérifier le domaine :

oc get routes --all-namespaces | grep console

$ oc get routes --all-namespaces | grep console

Copy to Clipboard

Toggle word wrap

Exemple de sortie

openshift-console          console             console-openshift-console.apps.test.gcp.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.gcp.example.com                     downloads           http    edge/Redirect          None

openshift-console          console             console-openshift-console.apps.test.gcp.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.gcp.example.com                     downloads           http    edge/Redirect          None

Copy to Clipboard

Toggle word wrap

Obtenir la liste des zones gérées pour trouver la zone qui correspond au domaine de la route trouvée précédemment :

gcloud dns managed-zones list | grep test.gcp.example.com
qe-cvs4g-private-zone test.gcp.example.com

$ gcloud dns managed-zones list | grep test.gcp.example.com
qe-cvs4g-private-zone test.gcp.example.com

Copy to Clipboard

Toggle word wrap

Créer une ressource ExternalDNS pour une source route:
```
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-gcp 
spec:
  domains:
    - filterType: Include 
      matchType: Exact 
      name: test.gcp.example.com 
  provider:
    type: GCP 
  source:
    openshiftRouteOptions: 
      routerName: default 
    type: OpenShiftRoute 
EOF
```
```
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-gcp 
```
1
```
spec:
  domains:
    - filterType: Include 
```
2
```
      matchType: Exact 
```
3
```
      name: test.gcp.example.com 
```
4
```
  provider:
    type: GCP 
```
5
```
  source:
    openshiftRouteOptions: 
```
6
```
      routerName: default 
```
7
```
    type: OpenShiftRoute 
```
8
```
EOF
```
Copy to Clipboard Toggle word wrap
1
Spécifie le nom du DNS CR externe.
2
Par défaut, toutes les zones hébergées sont sélectionnées comme cibles potentielles. Vous pouvez inclure une zone hébergée dont vous avez besoin.
3
La correspondance du domaine de la zone cible doit être exacte (par opposition à une correspondance par expression régulière).
4
Indiquez le domaine exact de la zone que vous souhaitez mettre à jour. Les noms d'hôte des routes doivent être des sous-domaines du domaine spécifié.
5
Définit le fournisseur de Google Cloud DNS.
6
Vous pouvez définir des options pour la source des enregistrements DNS.
7
Si la source est OpenShiftRoute, vous pouvez passer le nom du contrôleur d'entrée d'OpenShift. Le DNS externe sélectionne le nom d'hôte canonique de ce routeur comme cible lors de la création de l'enregistrement CNAME.
8
Définit la ressource OpenShift route comme source pour les enregistrements DNS qui sont créés dans le fournisseur DNS spécifié précédemment.

Vérifiez les enregistrements créés pour les routes OCP à l'aide de la commande suivante :

gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console

$ gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console

Copy to Clipboard

Toggle word wrap

19.7. Création d'enregistrements DNS sur Infoblox
Copier lien

Vous pouvez créer des enregistrements DNS sur Infoblox à l'aide de l'opérateur DNS externe de Red Hat.

19.7.1. Création d'enregistrements DNS sur une zone DNS publique sur Infoblox
Copier lien

Vous pouvez créer des enregistrements DNS sur une zone DNS publique sur Infoblox en utilisant l'opérateur DNS externe de Red Hat.

Conditions préalables

Vous avez accès au CLI OpenShift (oc).
Vous avez accès à l'interface utilisateur d'Infoblox.

Procédure

Créez un objet secret avec les informations d'identification Infoblox en exécutant la commande suivante :

oc -n external-dns-operator create secret generic infoblox-credentials --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_USERNAME=<infoblox_username> --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_PASSWORD=<infoblox_password>

$ oc -n external-dns-operator create secret generic infoblox-credentials --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_USERNAME=<infoblox_username> --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_PASSWORD=<infoblox_password>

Copy to Clipboard

Toggle word wrap

Obtenez les objets routes pour vérifier votre domaine de cluster en exécutant la commande suivante :

oc get routes --all-namespaces | grep console

$ oc get routes --all-namespaces | grep console

Copy to Clipboard

Toggle word wrap

Example Output

openshift-console          console             console-openshift-console.apps.test.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.example.com                     downloads           http    edge/Redirect          None

openshift-console          console             console-openshift-console.apps.test.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.example.com                     downloads           http    edge/Redirect          None

Copy to Clipboard

Toggle word wrap

Créez un fichier YAML de ressource ExternalDNS, par exemple, sample-infoblox.yaml, comme suit :

apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-infoblox
spec:
  provider:
    type: Infoblox
    infoblox:
      credentials:
        name: infoblox-credentials
      gridHost: ${INFOBLOX_GRID_PUBLIC_IP}
      wapiPort: 443
      wapiVersion: "2.3.1"
  domains:
  - filterType: Include
    matchType: Exact
    name: test.example.com
  source:
    type: OpenShiftRoute
    openshiftRouteOptions:
      routerName: default

apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-infoblox
spec:
  provider:
    type: Infoblox
    infoblox:
      credentials:
        name: infoblox-credentials
      gridHost: ${INFOBLOX_GRID_PUBLIC_IP}
      wapiPort: 443
      wapiVersion: "2.3.1"
  domains:
  - filterType: Include
    matchType: Exact
    name: test.example.com
  source:
    type: OpenShiftRoute
    openshiftRouteOptions:
      routerName: default

Copy to Clipboard

Toggle word wrap

Créez une ressource ExternalDNS sur Infoblox en exécutant la commande suivante :
```
oc create -f sample-infoblox.yaml
```
```
$ oc create -f sample-infoblox.yaml
```
Copy to Clipboard Toggle word wrap
Depuis l'interface Infoblox, vérifiez les enregistrements DNS créés pour les itinéraires console:
1. Cliquez sur Data Management → DNS → Zones.
2. Sélectionnez le nom de la zone.

19.8. Configuration du proxy à l'échelle du cluster sur l'opérateur DNS externe
Copier lien

Vous pouvez configurer le proxy à l'échelle du cluster dans l'Opérateur DNS externe. Après avoir configuré le proxy en grappe dans l'opérateur DNS externe, Operator Lifecycle Manager (OLM) met automatiquement à jour tous les déploiements des opérateurs avec les variables d'environnement telles que HTTP_PROXY, HTTPS_PROXY, et NO_PROXY.

19.8.1. Configuration de l'opérateur DNS externe pour qu'il fasse confiance à l'autorité de certification du proxy à l'échelle du cluster
Copier lien

Vous pouvez configurer l'opérateur DNS externe pour qu'il fasse confiance à l'autorité de certification du proxy à l'échelle du cluster.

Procédure

Créez la carte de configuration pour contenir le bundle CA dans l'espace de noms external-dns-operator en exécutant la commande suivante :
```
oc -n external-dns-operator create configmap trusted-ca
```
```
$ oc -n external-dns-operator create configmap trusted-ca
```
Copy to Clipboard Toggle word wrap
Pour injecter le paquet d'AC de confiance dans la carte de configuration, ajoutez l'étiquette config.openshift.io/inject-trusted-cabundle=true à la carte de configuration en exécutant la commande suivante :
```
oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
```
```
$ oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
```
Copy to Clipboard Toggle word wrap

Mettez à jour l'abonnement de l'opérateur DNS externe en exécutant la commande suivante :

oc -n external-dns-operator patch subscription external-dns-operator --type='json' -p='[{"op": "add", "path": "/spec/config", "value":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}]}}]'

$ oc -n external-dns-operator patch subscription external-dns-operator --type='json' -p='[{"op": "add", "path": "/spec/config", "value":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}]}}]'

Copy to Clipboard

Toggle word wrap

Vérification

Une fois le déploiement de l'opérateur DNS externe terminé, vérifiez que la variable d'environnement de l'autorité de certification approuvée est ajoutée au déploiement external-dns-operator en exécutant la commande suivante :
```
oc -n external-dns-operator exec deploy/external-dns-operator -c external-dns-operator -- printenv TRUSTED_CA_CONFIGMAP_NAME
```
```
$ oc -n external-dns-operator exec deploy/external-dns-operator -c external-dns-operator -- printenv TRUSTED_CA_CONFIGMAP_NAME
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
trusted-ca
```
```
trusted-ca
```
Copy to Clipboard Toggle word wrap

Chapitre 20. Politique des réseaux
Copier lien

20.1. A propos de la politique de réseau
Copier lien

En tant qu'administrateur de cluster, vous pouvez définir des politiques de réseau qui restreignent le trafic vers les pods de votre cluster.

Note

Les politiques de réseau configurées sont ignorées dans les réseaux IPv6.

20.1.1. A propos de la politique de réseau
Copier lien

Dans un cluster utilisant un plugin réseau qui prend en charge la politique réseau de Kubernetes, l'isolation du réseau est entièrement contrôlée par les objets NetworkPolicy. Dans OpenShift Container Platform 4.12, OpenShift SDN prend en charge l'utilisation de la politique réseau dans son mode d'isolation réseau par défaut.

Avertissement

La politique de réseau ne s'applique pas à l'espace de noms du réseau hôte. Les pods dont le réseau d'hôtes est activé ne sont pas affectés par les règles de la politique de réseau.

Par défaut, tous les modules d'un projet sont accessibles aux autres modules et aux points d'extrémité du réseau. Pour isoler un ou plusieurs pods dans un projet, vous pouvez créer des objets NetworkPolicy dans ce projet pour indiquer les connexions entrantes autorisées. Les administrateurs de projet peuvent créer et supprimer des objets NetworkPolicy dans leur propre projet.

Si un pod est associé à des sélecteurs dans un ou plusieurs objets NetworkPolicy, il n'acceptera que les connexions autorisées par au moins un de ces objets NetworkPolicy. Un module qui n'est sélectionné par aucun objet NetworkPolicy est entièrement accessible.

Les exemples suivants d'objets NetworkPolicy illustrent la prise en charge de différents scénarios :

Refuser tout le trafic :

Pour qu'un projet soit refusé par défaut, ajoutez un objet NetworkPolicy qui correspond à tous les pods mais n'accepte aucun trafic :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector: {}
  ingress: []

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector: {}
  ingress: []

Copy to Clipboard

Toggle word wrap

N'autoriser que les connexions provenant du contrôleur d'entrée de la plate-forme OpenShift Container :

Pour qu'un projet n'autorise que les connexions provenant du contrôleur d'ingestion de la plate-forme OpenShift Container, ajoutez l'objet NetworkPolicy suivant.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: ingress
  podSelector: {}
  policyTypes:
  - Ingress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: ingress
  podSelector: {}
  policyTypes:
  - Ingress

Copy to Clipboard

Toggle word wrap

N'accepte que les connexions provenant de pods au sein d'un projet :

Pour que les pods acceptent les connexions d'autres pods du même projet, mais rejettent toutes les autres connexions de pods d'autres projets, ajoutez l'objet suivant NetworkPolicy:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}

Copy to Clipboard

Toggle word wrap

N'autoriser le trafic HTTP et HTTPS qu'en fonction des étiquettes de pods :

Pour permettre uniquement l'accès HTTP et HTTPS aux pods avec un label spécifique (role=frontend dans l'exemple suivant), ajoutez un objet NetworkPolicy similaire à ce qui suit :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-http-and-https
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-http-and-https
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443

Copy to Clipboard

Toggle word wrap

Accepter les connexions en utilisant des sélecteurs d'espace de noms et de pods :

Pour faire correspondre le trafic réseau en combinant les sélecteurs d'espace de noms et de pods, vous pouvez utiliser un objet NetworkPolicy similaire à ce qui suit :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-pod-and-namespace-both
spec:
  podSelector:
    matchLabels:
      name: test-pods
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            project: project_name
        podSelector:
          matchLabels:
            name: test-pods

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-pod-and-namespace-both
spec:
  podSelector:
    matchLabels:
      name: test-pods
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            project: project_name
        podSelector:
          matchLabels:
            name: test-pods

Copy to Clipboard

Toggle word wrap

NetworkPolicy sont additifs, ce qui signifie que vous pouvez combiner plusieurs objets NetworkPolicy pour répondre à des exigences complexes en matière de réseau.

Par exemple, pour les objets NetworkPolicy définis dans les exemples précédents, vous pouvez définir les politiques allow-same-namespace et allow-http-and-https dans le même projet. Cela permet aux pods portant l'étiquette role=frontend d'accepter toutes les connexions autorisées par chaque politique. C'est-à-dire des connexions sur n'importe quel port à partir de pods dans le même espace de noms, et des connexions sur les ports 80 et 443 à partir de pods dans n'importe quel espace de noms.

20.1.1.1. Utilisation de la stratégie réseau allow-from-router
Copier lien

Utilisez l'adresse NetworkPolicy pour autoriser le trafic externe quelle que soit la configuration du routeur :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-router
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress:""
  podSelector: {}
  policyTypes:
  - Ingress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-router
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress:""

1


  podSelector: {}
  policyTypes:
  - Ingress

Copy to Clipboard

Toggle word wrap

1: policy-group.network.openshift.io/ingress:"" prend en charge à la fois Openshift-SDN et OVN-Kubernetes.

20.1.1.2. Utilisation de la stratégie réseau allow-from-hostnetwork
Copier lien

Ajoutez l'objet suivant allow-from-hostnetwork NetworkPolicy pour diriger le trafic des pods du réseau hôte :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-hostnetwork
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/host-network:""
  podSelector: {}
  policyTypes:
  - Ingress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-hostnetwork
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/host-network:""
  podSelector: {}
  policyTypes:
  - Ingress

Copy to Clipboard

Toggle word wrap

20.1.2. Optimisations de la politique réseau avec OpenShift SDN
Copier lien

Utilisez une stratégie de réseau pour isoler les pods qui sont différenciés les uns des autres par des étiquettes au sein d'un espace de noms.

Il est inefficace d'appliquer les objets NetworkPolicy à un grand nombre de pods individuels dans un seul espace de noms. Les étiquettes de pods n'existent pas au niveau de l'adresse IP, de sorte qu'une stratégie de réseau génère une règle de flux Open vSwitch (OVS) distincte pour chaque lien possible entre chaque pod sélectionné à l'aide d'une adresse podSelector.

Par exemple, si la spécification podSelector et l'entrée podSelector dans un objet NetworkPolicy correspondent chacune à 200 pods, 40 000 (200*200) règles de flux OVS sont générées. Cela peut ralentir un nœud.

Lors de l'élaboration de votre politique de réseau, reportez-vous aux lignes directrices suivantes :

Réduisez le nombre de règles de flux OVS en utilisant des espaces de noms pour contenir des groupes de pods qui doivent être isolés.
NetworkPolicy les objets qui sélectionnent un espace de noms entier, en utilisant le site namespaceSelector ou un site vide podSelector, ne génèrent qu'une seule règle de flux OVS correspondant à l'ID de réseau virtuel VXLAN (VNID) de l'espace de noms.
Conservez les modules qui n'ont pas besoin d'être isolés dans leur espace de noms d'origine et déplacez les modules qui ont besoin d'être isolés dans un ou plusieurs espaces de noms différents.
Créez des stratégies réseau supplémentaires ciblées pour l'espace de nommage afin d'autoriser le trafic spécifique que vous souhaitez autoriser à partir des modules isolés.

20.1.3. Optimisations de la politique réseau avec OpenShift OVN
Copier lien

Lors de l'élaboration de votre politique de réseau, reportez-vous aux lignes directrices suivantes :

Pour les politiques de réseau ayant la même spécification spec.podSelector, il est plus efficace d'utiliser une politique de réseau avec plusieurs règles ingress ou egress que plusieurs politiques de réseau avec des sous-ensembles de règles ingress ou egress.

Chaque règle ingress ou egress basée sur les spécifications podSelector ou namespaceSelector génère un nombre de flux OVS proportionnel à number of pods selected by network policy number of pods selected by ingress or egress rule. Il est donc préférable d'utiliser les spécifications podSelector ou namespaceSelector qui permettent de sélectionner autant de pods que nécessaire dans une règle, plutôt que de créer des règles individuelles pour chaque pod.

Par exemple, la politique suivante contient deux règles :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: test-network-policy
spec:
  podSelector: {}
  ingress:
    - from:
       - podSelector:
           matchLabels:
             role: frontend
    - from:
       - podSelector:
           matchLabels:
             role: backend

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: test-network-policy
spec:
  podSelector: {}
  ingress:
    - from:
       - podSelector:
           matchLabels:
             role: frontend
    - from:
       - podSelector:
           matchLabels:
             role: backend

Copy to Clipboard

Toggle word wrap

La politique suivante exprime ces deux règles en une seule :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: test-network-policy
spec:
  podSelector: {}
  ingress:
    - from:
       - podSelector:
           matchExpressions:
             - {key: role, operator: In, values: [frontend, backend]}

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: test-network-policy
spec:
  podSelector: {}
  ingress:
    - from:
       - podSelector:
           matchExpressions:
             - {key: role, operator: In, values: [frontend, backend]}

Copy to Clipboard

Toggle word wrap

La même règle s'applique à la spécification spec.podSelector. Si vous avez les mêmes règles ingress ou egress pour différentes politiques de réseau, il peut être plus efficace de créer une politique de réseau avec une spécification spec.podSelector commune. Par exemple, les deux politiques suivantes ont des règles différentes :

metadata:
 name: policy1
spec:
 podSelector:
   matchLabels:
     role: db
  ingress:
    - from:
       - podSelector:
           matchLabels:
             role: frontend

metadata:
 name: policy2
spec:
 podSelector:
   matchLabels:
     role: client
  ingress:
    - from:
       - podSelector:
           matchLabels:
             role: frontend

metadata:
 name: policy1
spec:
 podSelector:
   matchLabels:
     role: db
  ingress:
    - from:
       - podSelector:
           matchLabels:
             role: frontend

metadata:
 name: policy2
spec:
 podSelector:
   matchLabels:
     role: client
  ingress:
    - from:
       - podSelector:
           matchLabels:
             role: frontend

Copy to Clipboard

Toggle word wrap

La politique de réseau suivante exprime ces deux règles en une seule :

metadata:
 name: policy3
spec:
 podSelector:
   matchExpressions:
     - {key: role, operator: In, values: [db, client]}
  ingress:
    - from:
       - podSelector:
           matchLabels:
             role: frontend

metadata:
 name: policy3
spec:
 podSelector:
   matchExpressions:
     - {key: role, operator: In, values: [db, client]}
  ingress:
    - from:
       - podSelector:
           matchLabels:
             role: frontend

Copy to Clipboard

Toggle word wrap

Vous pouvez appliquer cette optimisation lorsque seuls plusieurs sélecteurs sont exprimés comme un seul. Dans les cas où les sélecteurs sont basés sur des étiquettes différentes, il peut être impossible d'appliquer cette optimisation. Dans ce cas, envisagez d'appliquer de nouvelles étiquettes pour l'optimisation de la politique de réseau en particulier.

20.1.4. Prochaines étapes
Copier lien

20.2. Création d'une politique de réseau
Copier lien

En tant qu'utilisateur ayant le rôle admin, vous pouvez créer une stratégie de réseau pour un espace de noms.

20.2.1. Exemple d'objet NetworkPolicy
Copier lien

Un exemple d'objet NetworkPolicy est annoté ci-dessous :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 
spec:
  podSelector: 
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 
        matchLabels:
          app: app
    ports: 
    - protocol: TCP
      port: 27017

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107

1


spec:
  podSelector:

2


    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:

3


        matchLabels:
          app: app
    ports:

4


    - protocol: TCP
      port: 27017

Copy to Clipboard

Toggle word wrap

1: Le nom de l'objet NetworkPolicy.
2: Un sélecteur qui décrit les pods auxquels la politique s'applique. L'objet de politique ne peut sélectionner que des pods dans le projet qui définit l'objet NetworkPolicy.
3: Un sélecteur qui correspond aux pods à partir desquels l'objet de politique autorise le trafic entrant. Le sélecteur correspond aux pods situés dans le même espace de noms que la NetworkPolicy.
4: Liste d'un ou plusieurs ports de destination sur lesquels le trafic doit être accepté.

20.2.2. Création d'une politique de réseau à l'aide de l'interface de ligne de commande
Copier lien

Pour définir des règles granulaires décrivant le trafic réseau entrant ou sortant autorisé pour les espaces de noms de votre cluster, vous pouvez créer une stratégie réseau.

Note

Si vous vous connectez avec un utilisateur ayant le rôle cluster-admin, vous pouvez créer une stratégie de réseau dans n'importe quel espace de noms du cluster.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges admin.
Vous travaillez dans l'espace de noms auquel s'applique la politique de réseau.

Procédure

Créer une règle de politique :

Créer un fichier <policy_name>.yaml:
```
touch <policy_name>.yaml
```
```
$ touch <policy_name>.yaml
```
Copy to Clipboard Toggle word wrap
où :
<policy_name>
Spécifie le nom du fichier de stratégie réseau.

Définissez une politique de réseau dans le fichier que vous venez de créer, comme dans les exemples suivants :

Refuser l'entrée de tous les pods dans tous les espaces de noms

Il s'agit d'une politique fondamentale, qui bloque tout réseau inter-pods autre que le trafic inter-pods autorisé par la configuration d'autres politiques de réseau.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector:
  ingress: []

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector:
  ingress: []

Copy to Clipboard

Toggle word wrap

Autoriser l'entrée de tous les pods dans le même espace de noms

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}

Copy to Clipboard

Toggle word wrap

Autoriser le trafic entrant vers un pod à partir d'un espace de noms particulier

Cette politique autorise le trafic vers les pods étiquetés pod-a à partir des pods fonctionnant sur namespace-y.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-traffic-pod
spec:
  podSelector:
   matchLabels:
      pod: pod-a
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
           kubernetes.io/metadata.name: namespace-y

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-traffic-pod
spec:
  podSelector:
   matchLabels:
      pod: pod-a
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
           kubernetes.io/metadata.name: namespace-y

Copy to Clipboard

Toggle word wrap

Pour créer l'objet de stratégie de réseau, entrez la commande suivante :
```
oc apply -f <policy_name>.yaml -n <namespace>
```
```
oc apply -f <policy_name>.yaml -n <namespace>
```
Copy to Clipboard Toggle word wrap
où :
<policy_name>
Spécifie le nom du fichier de stratégie réseau.
<namespace>
Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.
Exemple de sortie
```
networkpolicy.networking.k8s.io/deny-by-default created
```
```
networkpolicy.networking.k8s.io/deny-by-default created
```
Copy to Clipboard Toggle word wrap

Note

Si vous vous connectez à la console web avec les privilèges cluster-admin, vous avez le choix de créer une politique de réseau dans n'importe quel espace de noms du cluster directement dans YAML ou à partir d'un formulaire dans la console web.

20.2.3. Création d'une stratégie réseau de refus de tout par défaut
Copier lien

Il s'agit d'une politique fondamentale, qui bloque tout réseau inter-pods autre que le trafic réseau autorisé par la configuration d'autres politiques de réseau déployées. Cette procédure applique une politique par défaut : deny-by-default.

Note

Si vous vous connectez avec un utilisateur ayant le rôle cluster-admin, vous pouvez créer une stratégie de réseau dans n'importe quel espace de noms du cluster.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges admin.
Vous travaillez dans l'espace de noms auquel s'applique la politique de réseau.

Procédure

Créez le fichier YAML suivant qui définit une politique deny-by-default pour refuser l'entrée de tous les pods dans tous les espaces de noms. Enregistrez le YAML dans le fichier deny-by-default.yaml:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
  namespace: default 
spec:
  podSelector: {} 
  ingress: [] 
```
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
  namespace: default 
```
1
```
spec:
  podSelector: {} 
```
2
```
  ingress: [] 
```
3
Copy to Clipboard Toggle word wrap
1
namespace: default déploie cette politique dans l'espace de noms default.
2
podSelector: est vide, cela signifie qu'elle correspond à tous les pods. Par conséquent, la politique s'applique à tous les modules de l'espace de noms par défaut.
3
Aucune règle ingress n'est spécifiée. Le trafic entrant est donc supprimé pour tous les pods.
Appliquez la politique en entrant la commande suivante :
```
oc apply -f deny-by-default.yaml
```
```
$ oc apply -f deny-by-default.yaml
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
networkpolicy.networking.k8s.io/deny-by-default created
```
```
networkpolicy.networking.k8s.io/deny-by-default created
```
Copy to Clipboard Toggle word wrap

20.2.4. Création d'une politique de réseau pour autoriser le trafic en provenance de clients externes
Copier lien

La politique deny-by-default étant en place, vous pouvez configurer une politique qui autorise le trafic des clients externes vers un pod portant l'étiquette app=web.

Note

Si vous vous connectez avec un utilisateur ayant le rôle cluster-admin, vous pouvez créer une stratégie de réseau dans n'importe quel espace de noms du cluster.

Suivez cette procédure pour configurer une politique qui autorise un service externe à partir de l'Internet public directement ou en utilisant un équilibreur de charge pour accéder au module. Le trafic n'est autorisé que vers un pod portant l'étiquette app=web.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges admin.
Vous travaillez dans l'espace de noms auquel s'applique la politique de réseau.

Procédure

Créez une politique qui autorise le trafic provenant de l'Internet public directement ou en utilisant un équilibreur de charge pour accéder au pod. Enregistrez le YAML dans le fichier web-allow-external.yaml:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-external
  namespace: default
spec:
  policyTypes:
  - Ingress
  podSelector:
    matchLabels:
      app: web
  ingress:
    - {}

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-external
  namespace: default
spec:
  policyTypes:
  - Ingress
  podSelector:
    matchLabels:
      app: web
  ingress:
    - {}

Copy to Clipboard

Toggle word wrap

Appliquez la politique en entrant la commande suivante :

oc apply -f web-allow-external.yaml

$ oc apply -f web-allow-external.yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

networkpolicy.networking.k8s.io/web-allow-external created

networkpolicy.networking.k8s.io/web-allow-external created

Copy to Clipboard

Toggle word wrap

Cette politique autorise le trafic en provenance de toutes les ressources, y compris le trafic externe, comme l'illustre le diagramme suivant :

20.2.5. Création d'une politique de réseau autorisant le trafic vers une application à partir de tous les espaces de noms
Copier lien

Note

Si vous vous connectez avec un utilisateur ayant le rôle cluster-admin, vous pouvez créer une stratégie de réseau dans n'importe quel espace de noms du cluster.

Suivez cette procédure pour configurer une stratégie qui autorise le trafic de tous les pods de tous les espaces de noms vers une application particulière.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges admin.
Vous travaillez dans l'espace de noms auquel s'applique la politique de réseau.

Procédure

Créez une politique qui autorise le trafic de tous les pods dans tous les espaces de noms vers une application particulière. Enregistrez le YAML dans le fichier web-allow-all-namespaces.yaml:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-all-namespaces
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web 
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {} 
```
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-all-namespaces
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web 
```
1
```
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {} 
```
2
Copy to Clipboard Toggle word wrap
1
Applique la politique uniquement aux pods app:web dans l'espace de noms par défaut.
2
Sélectionne tous les pods dans tous les espaces de noms.
Note
Par défaut, si vous ne précisez pas namespaceSelector, aucun espace de noms n'est sélectionné, ce qui signifie que la stratégie n'autorise que le trafic provenant de l'espace de noms dans lequel la stratégie de réseau est déployée.

Appliquez la politique en entrant la commande suivante :

oc apply -f web-allow-all-namespaces.yaml

$ oc apply -f web-allow-all-namespaces.yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

networkpolicy.networking.k8s.io/web-allow-all-namespaces created

networkpolicy.networking.k8s.io/web-allow-all-namespaces created

Copy to Clipboard

Toggle word wrap

Vérification

Démarrez un service web dans l'espace de noms default en entrant la commande suivante :

oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

Copy to Clipboard

Toggle word wrap

Exécutez la commande suivante pour déployer une image alpine dans l'espace de noms secondary et pour démarrer un shell :
```
oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
```
```
$ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
```
Copy to Clipboard Toggle word wrap

Exécutez la commande suivante dans l'interpréteur de commandes et observez que la demande est autorisée :

wget -qO- --timeout=2 http://web.default

# wget -qO- --timeout=2 http://web.default

Copy to Clipboard

Toggle word wrap

Résultats attendus

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Copy to Clipboard

Toggle word wrap

20.2.6. Création d'une politique de réseau autorisant le trafic vers une application à partir d'un espace de noms
Copier lien

Note

Si vous vous connectez avec un utilisateur ayant le rôle cluster-admin, vous pouvez créer une stratégie de réseau dans n'importe quel espace de noms du cluster.

Suivez cette procédure pour configurer une politique qui autorise le trafic vers un pod avec l'étiquette app=web à partir d'un espace de noms particulier. Vous pourriez vouloir faire ceci pour :

Restreindre le trafic vers une base de données de production aux seuls espaces de noms dans lesquels des charges de travail de production sont déployées.
Permet aux outils de surveillance déployés dans un espace de noms particulier de récupérer les mesures de l'espace de noms actuel.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges admin.
Vous travaillez dans l'espace de noms auquel s'applique la politique de réseau.

Procédure

Créez une politique qui autorise le trafic de tous les pods dans un espace de noms particulier avec un label purpose=production. Sauvegardez le YAML dans le fichier web-allow-prod.yaml:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-prod
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web 
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: production

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-prod
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web

1


  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: production

2

Copy to Clipboard

Toggle word wrap

1: Applique la politique uniquement aux pods app:web dans l'espace de noms par défaut.
2: Restreint le trafic aux seuls pods des espaces de noms portant l'étiquette purpose=production.

Appliquez la politique en entrant la commande suivante :
```
oc apply -f web-allow-prod.yaml
```
```
$ oc apply -f web-allow-prod.yaml
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
networkpolicy.networking.k8s.io/web-allow-prod created
```
```
networkpolicy.networking.k8s.io/web-allow-prod created
```
Copy to Clipboard Toggle word wrap

Vérification

Démarrez un service web dans l'espace de noms default en entrant la commande suivante :

oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

Copy to Clipboard

Toggle word wrap

Exécutez la commande suivante pour créer l'espace de noms prod:
```
oc create namespace prod
```
```
$ oc create namespace prod
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour étiqueter l'espace de noms prod:
```
oc label namespace/prod purpose=production
```
```
$ oc label namespace/prod purpose=production
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour créer l'espace de noms dev:
```
oc create namespace dev
```
```
$ oc create namespace dev
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour étiqueter l'espace de noms dev:
```
oc label namespace/dev purpose=testing
```
```
$ oc label namespace/dev purpose=testing
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour déployer une image alpine dans l'espace de noms dev et pour démarrer un shell :
```
oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
```
```
$ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante dans l'interpréteur de commandes et observez que la demande est bloquée :
```
wget -qO- --timeout=2 http://web.default
```
```
# wget -qO- --timeout=2 http://web.default
```
Copy to Clipboard Toggle word wrap
Résultats attendus
```
wget: download timed out
```
```
wget: download timed out
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour déployer une image alpine dans l'espace de noms prod et démarrer un shell :
```
oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
```
```
$ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
```
Copy to Clipboard Toggle word wrap

Exécutez la commande suivante dans l'interpréteur de commandes et observez que la demande est autorisée :

wget -qO- --timeout=2 http://web.default

# wget -qO- --timeout=2 http://web.default

Copy to Clipboard

Toggle word wrap

Résultats attendus

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Copy to Clipboard

Toggle word wrap

20.3. Visualisation d'une politique de réseau
Copier lien

En tant qu'utilisateur ayant le rôle admin, vous pouvez afficher une stratégie de réseau pour un espace de noms.

20.3.1. Exemple d'objet NetworkPolicy
Copier lien

Un exemple d'objet NetworkPolicy est annoté ci-dessous :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 
spec:
  podSelector: 
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 
        matchLabels:
          app: app
    ports: 
    - protocol: TCP
      port: 27017

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107

1


spec:
  podSelector:

2


    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:

3


        matchLabels:
          app: app
    ports:

4


    - protocol: TCP
      port: 27017

Copy to Clipboard

Toggle word wrap

1: Le nom de l'objet NetworkPolicy.
2: Un sélecteur qui décrit les pods auxquels la politique s'applique. L'objet de politique ne peut sélectionner que des pods dans le projet qui définit l'objet NetworkPolicy.
3: Un sélecteur qui correspond aux pods à partir desquels l'objet de politique autorise le trafic entrant. Le sélecteur correspond aux pods situés dans le même espace de noms que la NetworkPolicy.
4: Liste d'un ou plusieurs ports de destination sur lesquels le trafic doit être accepté.

20.3.2. Visualisation des stratégies de réseau à l'aide de l'interface de ligne de commande
Copier lien

Vous pouvez examiner les politiques de réseau dans un espace de noms.

Note

Si vous vous connectez avec un utilisateur ayant le rôle cluster-admin, vous pouvez visualiser n'importe quelle stratégie de réseau dans le cluster.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges admin.
Vous travaillez dans l'espace de noms où la politique de réseau existe.

Procédure

Liste des politiques de réseau dans un espace de noms :

Pour afficher les objets de stratégie de réseau définis dans un espace de noms, entrez la commande suivante :
```
oc get networkpolicy
```
```
$ oc get networkpolicy
```
Copy to Clipboard Toggle word wrap

Facultatif : Pour examiner une politique de réseau spécifique, entrez la commande suivante :

oc describe networkpolicy <nom_de_la_politique> -n <espace_de_noms>

oc describe networkpolicy <nom_de_la_politique> -n <espace_de_noms>

Copy to Clipboard

Toggle word wrap

où :

<policy_name>: Spécifie le nom de la stratégie de réseau à inspecter.
<namespace>: Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.

Par exemple :

oc describe networkpolicy allow-same-namespace

$ oc describe networkpolicy allow-same-namespace

Copy to Clipboard

Toggle word wrap

Sortie de la commande oc describe

Name:         allow-same-namespace
Namespace:    ns1
Created on:   2021-05-24 22:28:56 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      PodSelector: <none>
  Not affecting egress traffic
  Policy Types: Ingress

Name:         allow-same-namespace
Namespace:    ns1
Created on:   2021-05-24 22:28:56 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      PodSelector: <none>
  Not affecting egress traffic
  Policy Types: Ingress

Copy to Clipboard

Toggle word wrap

Note

Si vous vous connectez à la console web avec les privilèges cluster-admin, vous avez le choix d'afficher une politique de réseau dans n'importe quel espace de noms du cluster directement dans YAML ou à partir d'un formulaire dans la console web.

20.4. Modification d'une politique de réseau
Copier lien

En tant qu'utilisateur ayant le rôle admin, vous pouvez modifier une stratégie réseau existante pour un espace de noms.

20.4.1. Modification d'une politique de réseau
Copier lien

Vous pouvez modifier une stratégie de réseau dans un espace de noms.

Note

Si vous vous connectez avec un utilisateur ayant le rôle cluster-admin, vous pouvez modifier une stratégie réseau dans n'importe quel espace de noms du cluster.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges admin.
Vous travaillez dans l'espace de noms où la politique de réseau existe.

Procédure

Facultatif : Pour répertorier les objets de stratégie de réseau dans un espace de noms, entrez la commande suivante :
```
oc get networkpolicy
```
```
$ oc get networkpolicy
```
Copy to Clipboard Toggle word wrap
où :
<namespace>
Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.
Modifiez l'objet de politique de réseau.
- Si vous avez enregistré la définition de la stratégie réseau dans un fichier, éditez le fichier et apportez les modifications nécessaires, puis entrez la commande suivante.
  $ oc apply -n <namespace> -f <policy_file>.yaml
  Copy to Clipboard Toggle word wrap
  où :
  <namespace>
  Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.
  <policy_file>
  Spécifie le nom du fichier contenant la politique de réseau.
- Si vous devez mettre à jour l'objet de stratégie de réseau directement, entrez la commande suivante :
  oc edit networkpolicy <policy_name> -n <namespace> $ oc edit networkpolicy <policy_name> -n <namespace>
  Copy to Clipboard Toggle word wrap
  où :
  <policy_name>
  Spécifie le nom de la politique de réseau.
  <namespace>
  Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.
Confirmez la mise à jour de l'objet de stratégie de réseau.
```
oc describe networkpolicy <nom_de_la_politique> -n <espace_de_noms>
```
```
oc describe networkpolicy <nom_de_la_politique> -n <espace_de_noms>
```
Copy to Clipboard Toggle word wrap
où :
<policy_name>
Spécifie le nom de la politique de réseau.
<namespace>
Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.

Note

Si vous vous connectez à la console web avec les privilèges cluster-admin, vous avez le choix entre éditer une politique de réseau dans n'importe quel espace de noms du cluster directement dans YAML ou à partir de la politique dans la console web via le menu Actions.

20.4.2. Exemple d'objet NetworkPolicy
Copier lien

Un exemple d'objet NetworkPolicy est annoté ci-dessous :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 
spec:
  podSelector: 
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 
        matchLabels:
          app: app
    ports: 
    - protocol: TCP
      port: 27017

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107

1


spec:
  podSelector:

2


    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:

3


        matchLabels:
          app: app
    ports:

4


    - protocol: TCP
      port: 27017

Copy to Clipboard

Toggle word wrap

1: Le nom de l'objet NetworkPolicy.
2: Un sélecteur qui décrit les pods auxquels la politique s'applique. L'objet de politique ne peut sélectionner que des pods dans le projet qui définit l'objet NetworkPolicy.
3: Un sélecteur qui correspond aux pods à partir desquels l'objet de politique autorise le trafic entrant. Le sélecteur correspond aux pods situés dans le même espace de noms que la NetworkPolicy.
4: Liste d'un ou plusieurs ports de destination sur lesquels le trafic doit être accepté.

20.5. Suppression d'une politique de réseau
Copier lien

En tant qu'utilisateur ayant le rôle admin, vous pouvez supprimer une stratégie de réseau d'un espace de noms.

20.5.1. Suppression d'une stratégie de réseau à l'aide de l'interface de ligne de commande
Copier lien

Vous pouvez supprimer une stratégie de réseau dans un espace de noms.

Note

Si vous vous connectez avec un utilisateur ayant le rôle cluster-admin, vous pouvez supprimer n'importe quelle stratégie de réseau dans le cluster.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges admin.
Vous travaillez dans l'espace de noms où la politique de réseau existe.

Procédure

Pour supprimer un objet de stratégie de réseau, entrez la commande suivante :
```
oc delete networkpolicy <policy_name> -n <namespace>
```
```
oc delete networkpolicy <policy_name> -n <namespace>
```
Copy to Clipboard Toggle word wrap
où :
<policy_name>
Spécifie le nom de la politique de réseau.
<namespace>
Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.
Exemple de sortie
```
networkpolicy.networking.k8s.io/default-deny deleted
```
```
networkpolicy.networking.k8s.io/default-deny deleted
```
Copy to Clipboard Toggle word wrap

Note

Si vous vous connectez à la console web avec les privilèges cluster-admin, vous avez le choix entre supprimer une politique de réseau dans n'importe quel espace de noms du cluster directement dans YAML ou à partir de la politique dans la console web via le menu Actions.

20.6. Définir une politique de réseau par défaut pour les projets
Copier lien

En tant qu'administrateur de cluster, vous pouvez modifier le modèle de nouveau projet pour inclure automatiquement les stratégies de réseau lorsque vous créez un nouveau projet. Si vous n'avez pas encore de modèle personnalisé pour les nouveaux projets, vous devez d'abord en créer un.

20.6.1. Modifier le modèle pour les nouveaux projets
Copier lien

En tant qu'administrateur de cluster, vous pouvez modifier le modèle de projet par défaut afin que les nouveaux projets soient créés en fonction de vos besoins.

Pour créer votre propre modèle de projet personnalisé :

Procédure

Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Générer le modèle de projet par défaut :

oc adm create-bootstrap-project-template -o yaml > template.yaml

oc adm create-bootstrap-project-template -o yaml > template.yaml

Copy to Clipboard

Toggle word wrap

Utilisez un éditeur de texte pour modifier le fichier template.yaml généré en ajoutant des objets ou en modifiant des objets existants.
Le modèle de projet doit être créé dans l'espace de noms openshift-config. Chargez votre modèle modifié :
```
oc create -f template.yaml -n openshift-config
```
```
$ oc create -f template.yaml -n openshift-config
```
Copy to Clipboard Toggle word wrap
Modifiez la ressource de configuration du projet à l'aide de la console Web ou de la CLI.
- En utilisant la console web :
  1. Naviguez jusqu'à la page Administration → Cluster Settings.
  2. Cliquez sur Configuration pour afficher toutes les ressources de configuration.
  3. Trouvez l'entrée pour Project et cliquez sur Edit YAML.
- Utilisation de la CLI :
  1. Modifier la ressource project.config.openshift.io/cluster:
    
    $ oc edit project.config.openshift.io/cluster
    
    Copy to Clipboard Toggle word wrap
Mettez à jour la section spec pour inclure les paramètres projectRequestTemplate et name, et définissez le nom de votre modèle de projet téléchargé. Le nom par défaut est project-request.
Ressource de configuration de projet avec modèle de projet personnalisé
```
apiVersion: config.openshift.io/v1
kind: Project
metadata:
  ...
spec:
  projectRequestTemplate:
    name: <template_name>
```
```
apiVersion: config.openshift.io/v1
kind: Project
metadata:
  ...
spec:
  projectRequestTemplate:
    name: <template_name>
```
Copy to Clipboard Toggle word wrap
Après avoir enregistré vos modifications, créez un nouveau projet pour vérifier que vos modifications ont bien été appliquées.

20.6.2. Ajouter des politiques de réseau au nouveau modèle de projet
Copier lien

En tant qu'administrateur de cluster, vous pouvez ajouter des politiques de réseau au modèle par défaut pour les nouveaux projets. OpenShift Container Platform créera automatiquement tous les objets NetworkPolicy spécifiés dans le modèle du projet.

Conditions préalables

Votre cluster utilise un fournisseur de réseau CNI par défaut qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec l'option mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
You installed the OpenShift CLI (oc).
Vous devez vous connecter au cluster avec un utilisateur disposant des privilèges cluster-admin.
Vous devez avoir créé un modèle de projet personnalisé par défaut pour les nouveaux projets.

Procédure

Modifiez le modèle par défaut pour un nouveau projet en exécutant la commande suivante :
```
oc edit template <project_template> -n openshift-config
```
```
$ oc edit template <project_template> -n openshift-config
```
Copy to Clipboard Toggle word wrap
Remplacez <project_template> par le nom du modèle par défaut que vous avez configuré pour votre cluster. Le nom du modèle par défaut est project-request.

Dans le modèle, ajoutez chaque objet NetworkPolicy en tant qu'élément du paramètre objects. Le paramètre objects accepte une collection d'un ou plusieurs objets.

Dans l'exemple suivant, la collection de paramètres objects comprend plusieurs objets NetworkPolicy.

objects:
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-same-namespace
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector: {}
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-openshift-ingress
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            network.openshift.io/policy-group: ingress
    podSelector: {}
    policyTypes:
    - Ingress
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-kube-apiserver-operator
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: openshift-kube-apiserver-operator
        podSelector:
          matchLabels:
            app: kube-apiserver-operator
    policyTypes:
    - Ingress
...

objects:
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-same-namespace
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector: {}
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-openshift-ingress
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            network.openshift.io/policy-group: ingress
    podSelector: {}
    policyTypes:
    - Ingress
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-kube-apiserver-operator
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: openshift-kube-apiserver-operator
        podSelector:
          matchLabels:
            app: kube-apiserver-operator
    policyTypes:
    - Ingress
...

Copy to Clipboard

Toggle word wrap

Facultatif : Créez un nouveau projet pour confirmer que vos objets de stratégie de réseau ont été créés avec succès en exécutant les commandes suivantes :
1. Créer un nouveau projet :
  oc new-project <projet> $ oc new-project <projet>
  1
  Copy to Clipboard Toggle word wrap
  1
  Remplacez <project> par le nom du projet que vous créez.
2. Confirmez que les objets de stratégie de réseau du nouveau modèle de projet existent dans le nouveau projet :
  $ oc get networkpolicy NAME POD-SELECTOR AGE allow-from-openshift-ingress <none> 7s allow-from-same-namespace <none> 7s
  Copy to Clipboard Toggle word wrap

20.7. Configuration de l'isolation des multitenants à l'aide d'une stratégie de réseau
Copier lien

En tant qu'administrateur de cluster, vous pouvez configurer vos stratégies réseau pour assurer l'isolation du réseau multitenant.

Note

Si vous utilisez le plugin réseau OpenShift SDN, la configuration des politiques réseau comme décrit dans cette section fournit une isolation réseau similaire au mode multitenant mais avec un mode de politique réseau défini.

20.7.1. Configuration de l'isolation des multitenants à l'aide d'une stratégie de réseau
Copier lien

Vous pouvez configurer votre projet pour l'isoler des pods et des services dans d'autres espaces de noms de projets.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
You installed the OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges admin.

Procédure

Créez les objets NetworkPolicy suivants :

Une police nommée allow-from-openshift-ingress.

cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  podSelector: {}
  policyTypes:
  - Ingress
EOF

$ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  podSelector: {}
  policyTypes:
  - Ingress
EOF

Copy to Clipboard

Toggle word wrap

Note

policy-group.network.openshift.io/ingress: "" est l'étiquette de sélecteur d'espace de noms préférée pour OpenShift SDN. Vous pouvez utiliser l'étiquette de sélecteur d'espace de noms network.openshift.io/policy-group: ingress, mais il s'agit d'une étiquette héritée.

Une police nommée allow-from-openshift-monitoring:

cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: monitoring
  podSelector: {}
  policyTypes:
  - Ingress
EOF

$ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: monitoring
  podSelector: {}
  policyTypes:
  - Ingress
EOF

Copy to Clipboard

Toggle word wrap

Une police nommée allow-same-namespace:

cat << EOF| oc create -f -
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}
EOF

$ cat << EOF| oc create -f -
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}
EOF

Copy to Clipboard

Toggle word wrap

Une police nommée allow-from-kube-apiserver-operator:

cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-kube-apiserver-operator
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: openshift-kube-apiserver-operator
      podSelector:
        matchLabels:
          app: kube-apiserver-operator
  policyTypes:
  - Ingress
EOF

$ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-kube-apiserver-operator
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: openshift-kube-apiserver-operator
      podSelector:
        matchLabels:
          app: kube-apiserver-operator
  policyTypes:
  - Ingress
EOF

Copy to Clipboard

Toggle word wrap

Pour plus de détails, voir Nouveau contrôleur de webhook kube-apiserver-operator validant l'état de santé du webhook.

Facultatif : Pour confirmer que les politiques de réseau existent dans votre projet actuel, entrez la commande suivante :

oc describe networkpolicy

$ oc describe networkpolicy

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name:         allow-from-openshift-ingress
Namespace:    example1
Created on:   2020-06-09 00:28:17 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: network.openshift.io/policy-group: ingress
  Not affecting egress traffic
  Policy Types: Ingress


Name:         allow-from-openshift-monitoring
Namespace:    example1
Created on:   2020-06-09 00:29:57 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: network.openshift.io/policy-group: monitoring
  Not affecting egress traffic
  Policy Types: Ingress

Name:         allow-from-openshift-ingress
Namespace:    example1
Created on:   2020-06-09 00:28:17 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: network.openshift.io/policy-group: ingress
  Not affecting egress traffic
  Policy Types: Ingress


Name:         allow-from-openshift-monitoring
Namespace:    example1
Created on:   2020-06-09 00:29:57 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: network.openshift.io/policy-group: monitoring
  Not affecting egress traffic
  Policy Types: Ingress

Copy to Clipboard

Toggle word wrap

20.7.2. Prochaines étapes
Copier lien

Définition d'une politique de réseau par défaut

Chapitre 21. Opérateur d'équilibreur de charge AWS
Copier lien

21.1. Notes de mise à jour de AWS Load Balancer Operator
Copier lien

L'opérateur AWS Load Balancer (ALB) déploie et gère une instance de la ressource AWSLoadBalancerController.

Ces notes de version suivent le développement de l'opérateur AWS Load Balancer dans OpenShift Container Platform.

Pour une vue d'ensemble de l'AWS Load Balancer Operator, voir AWS Load Balancer Operator dans OpenShift Container Platform.

21.1.1. AWS Load Balancer Operator 1.0.0
Copier lien

L'avis suivant est disponible pour la version 1.0.0 d'AWS Load Balancer Operator :

RHEA-2023:1954 Release of AWS Load Balancer Operator on OperatorHub Enhancement Advisory Update (Mise à jour de l'avis d'amélioration de AWS Load Balancer sur OperatorHub)

21.1.1.1. Changements notables
Copier lien

Cette version utilise la nouvelle version de l'API v1.

21.1.1.2. Bug fixes
Copier lien

Auparavant, le contrôleur provisionné par AWS Load Balancer Operator n'utilisait pas correctement la configuration du proxy cluster-wide. Ces paramètres sont désormais appliqués de manière appropriée au contrôleur. (OCPBUGS-4052, OCPBUGS-5295)

21.1.2. Versions antérieures
Copier lien

Les deux premières versions de l'AWS Load Balancer Operator sont disponibles en tant qu'aperçu technologique. Ces versions ne doivent pas être utilisées dans un cluster de production. Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

L'avis suivant est disponible pour la version 0.2.0 d'AWS Load Balancer Operator :

RHEA-2022:9084 Mise à jour de l'avis d'amélioration de l'opérateur AWS Load Balancer sur OperatorHub

L'avis suivant est disponible pour la version 0.0.1 d'AWS Load Balancer Operator :

RHEA-2022:5780 Mise à jour de l'avis d'amélioration de l'opérateur AWS Load Balancer sur OperatorHub

21.2. Opérateur AWS Load Balancer dans OpenShift Container Platform
Copier lien

L'opérateur AWS Load Balancer (ALB) déploie et gère une instance de aws-load-balancer-controller. Vous pouvez installer l'opérateur ALB à partir de l'OperatorHub en utilisant la console web ou le CLI d'OpenShift Container Platform.

21.2.1. Opérateur d'équilibreur de charge AWS
Copier lien

L'opérateur de l'équilibreur de charge AWS peut marquer les sous-réseaux publics si la balise kubernetes.io/role/elb est manquante. En outre, l'opérateur de l'équilibreur de charge AWS détecte les éléments suivants dans le nuage AWS sous-jacent :

L'ID du nuage privé virtuel (VPC) sur lequel le cluster hébergeant l'opérateur est déployé.
Sous-réseaux publics et privés du VPC découvert.

L'opérateur AWS Load Balancer prend en charge la ressource de service Kubernetes de type LoadBalancer en utilisant l'équilibreur de charge réseau (NLB) avec le type de cible instance uniquement.

Conditions préalables

Vous devez disposer des informations d'identification AWS secrètes. Les informations d'identification sont utilisées pour le marquage des sous-réseaux et la découverte des VPC.

Procédure

Vous pouvez déployer l'opérateur AWS Load Balancer à la demande depuis OperatorHub, en créant un objet Subscription:

oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'

$ oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'

Copy to Clipboard

Toggle word wrap

Exemple de sortie

install-zlfbt

install-zlfbt

Copy to Clipboard

Toggle word wrap

Vérifier le statut d'un plan d'installation. Le statut d'un plan d'installation doit être Complete:

oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{{\N-"\N\N"}}''

$ oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{{\N-"\N\N"}}''

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Complete

Complete

Copy to Clipboard

Toggle word wrap

Utilisez la commande oc get pour visualiser l'état de Deployment:

oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager

$ oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                           READY     UP-TO-DATE   AVAILABLE   AGE
aws-load-balancer-operator-controller-manager  1/1       1            1           23h

NAME                                           READY     UP-TO-DATE   AVAILABLE   AGE
aws-load-balancer-operator-controller-manager  1/1       1            1           23h

Copy to Clipboard

Toggle word wrap

21.2.2. Journaux de l'opérateur de l'équilibreur de charge AWS
Copier lien

Utilisez la commande oc logs pour afficher les journaux de l'opérateur AWS Load Balancer.

Procédure

Consulter les journaux de l'opérateur AWS Load Balancer :

oc logs -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager -c manager

$ oc logs -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager -c manager

Copy to Clipboard

Toggle word wrap

21.3. Comprendre l'opérateur d'équilibreur de charge AWS
Copier lien

L'opérateur AWS Load Balancer (ALB) déploie et gère une instance de la ressource aws-load-balancer-controller. Vous pouvez installer l'AWS Load Balancer Operator depuis l'OperatorHub en utilisant la console web ou le CLI d'OpenShift Container Platform.

Important

Le déploiement d'AWS Load Balancer Operator est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

21.3.1. Installation de l'opérateur AWS Load Balancer
Copier lien

Vous pouvez installer l'opérateur AWS Load Balancer depuis OperatorHub en utilisant la console web d'OpenShift Container Platform.

Conditions préalables

Vous vous êtes connecté à la console web de OpenShift Container Platform en tant qu'utilisateur avec les permissions cluster-admin.
Votre cluster est configuré avec AWS comme type de plateforme et fournisseur de cloud.

Procédure

Naviguez vers Operators → OperatorHub dans la console web de OpenShift Container Platform.
Sélectionnez le site AWS Load Balancer Operator. Vous pouvez utiliser la zone de texte Filter by keyword ou la liste de filtres pour rechercher l'opérateur AWS Load Balancer dans la liste des opérateurs.
Sélectionnez l'espace de noms aws-load-balancer-operator.
Suivez les instructions pour préparer l'opérateur à l'installation.
Sur la page AWS Load Balancer Operator, cliquez sur Install.
Sur la page Install Operator, sélectionnez les options suivantes :
1. Update the channel comme stable-v1.
2. Installation mode comme A specific namespace on the cluster.
3. Installed Namespace comme aws-load-balancer-operator. Si l'espace de noms aws-load-balancer-operator n'existe pas, il est créé lors de l'installation de l'opérateur.
4. Sélectionnez Update approval comme Automatic ou Manual. Par défaut, Update approval est défini sur Automatic. Si vous sélectionnez les mises à jour automatiques, l'Operator Lifecycle Manager (OLM) met automatiquement à niveau l'instance en cours d'exécution de votre opérateur sans aucune intervention. Si vous sélectionnez les mises à jour manuelles, l'OLM crée une demande de mise à jour. En tant qu'administrateur de cluster, vous devez ensuite approuver manuellement cette demande de mise à jour pour mettre à jour l'opérateur vers la nouvelle version.
5. Cliquez sur Install.

Vérification

Vérifiez que l'opérateur AWS Load Balancer affiche le site Status comme Succeeded sur le tableau de bord des opérateurs installés.

21.4. Installation d'AWS Load Balancer Operator sur un cluster Security Token Service
Copier lien

Vous pouvez installer l'opérateur AWS Load Balancer sur un cluster Security Token Service (STS).

L'opérateur de l'équilibreur de charge AWS s'appuie sur CredentialsRequest pour démarrer l'opérateur et chaque instance AWSLoadBalancerController. L'opérateur d'équilibreur de charge AWS attend que les secrets requis soient créés et disponibles. Le Cloud Credential Operator ne fournit pas les secrets automatiquement dans le cluster STS. Vous devez définir les secrets d'identification manuellement à l'aide du binaire ccoctl.

Si vous ne souhaitez pas fournir de secret d'identification à l'aide de Cloud Credential Operator, vous pouvez configurer l'instance AWSLoadBalancerController sur le cluster STS en spécifiant le secret d'identification dans la ressource personnalisée (CR) du contrôleur d'équilibre de charge AWS.

21.4.1. Bootstrapping AWS Load Balancer Operator on Security Token Service cluster
Copier lien

Conditions préalables

Vous devez extraire et préparer le binaire ccoctl.

Procédure

Créez l'espace de noms aws-load-balancer-operator en exécutant la commande suivante :
```
oc create namespace aws-load-balancer-operator
```
```
$ oc create namespace aws-load-balancer-operator
```
Copy to Clipboard Toggle word wrap

Téléchargez la ressource personnalisée (CR) CredentialsRequest de l'opérateur AWS Load Balancer et créez un répertoire pour la stocker en exécutant la commande suivante :

curl --create-dirs -o <path-to-credrequests-dir>/cr.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-credentials-request.yaml

$ curl --create-dirs -o <path-to-credrequests-dir>/cr.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-credentials-request.yaml

Copy to Clipboard

Toggle word wrap

Utilisez l'outil ccoctl pour traiter les objets CredentialsRequest de l'opérateur AWS Load Balancer, en exécutant la commande suivante :

ccoctl aws create-iam-roles \
    --name <name> --region=<aws_region> \
    --credentials-requests-dir=<path-to-credrequests-dir> \
    --identity-provider-arn <oidc-arn>

$ ccoctl aws create-iam-roles \
    --name <name> --region=<aws_region> \
    --credentials-requests-dir=<path-to-credrequests-dir> \
    --identity-provider-arn <oidc-arn>

Copy to Clipboard

Toggle word wrap

Appliquez les secrets générés dans le répertoire manifests de votre cluster en exécutant la commande suivante :
```
ls manifests/*-credentials.yaml | xargs -I{} oc apply -f {}
```
```
$ ls manifests/*-credentials.yaml | xargs -I{} oc apply -f {}
```
Copy to Clipboard Toggle word wrap

Vérifiez que le secret d'identification de l'opérateur AWS Load Balancer est créé en exécutant la commande suivante :

oc -n aws-load-balancer-operator get secret aws-load-balancer-operator --template='{{index .data "credentials"}}' | base64 -d

$ oc -n aws-load-balancer-operator get secret aws-load-balancer-operator --template='{{index .data "credentials"}}' | base64 -d

Copy to Clipboard

Toggle word wrap

Exemple de sortie

[default]
sts_regional_endpoints = regional
role_arn = arn:aws:iam::999999999999:role/aws-load-balancer-operator-aws-load-balancer-operator
web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token

[default]
sts_regional_endpoints = regional
role_arn = arn:aws:iam::999999999999:role/aws-load-balancer-operator-aws-load-balancer-operator
web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token

Copy to Clipboard

Toggle word wrap

21.4.2. Configuration de l'opérateur AWS Load Balancer sur le cluster Security Token Service à l'aide des objets gérés CredentialsRequest
Copier lien

Conditions préalables

Vous devez extraire et préparer le binaire ccoctl.

Procédure

L'opérateur AWS Load Balancer crée l'objet CredentialsRequest dans l'espace de noms openshift-cloud-credential-operator pour chaque ressource personnalisée (CR) AWSLoadBalancerController. Vous pouvez extraire et enregistrer l'objet CredentialsRequest créé dans un répertoire en exécutant la commande suivante :
```
oc get credentialsrequest -n openshift-cloud-credential-operator  \
    aws-load-balancer-controller-<cr-name> -o yaml > <path-to-credrequests-dir>/cr.yaml
```
```
$ oc get credentialsrequest -n openshift-cloud-credential-operator  \
    aws-load-balancer-controller-<cr-name> -o yaml > <path-to-credrequests-dir>/cr.yaml 
```
1
Copy to Clipboard Toggle word wrap
1
Le paramètre aws-load-balancer-controller-<cr-name> indique le nom de la demande d'informations d'identification créée par l'opérateur de l'équilibreur de charge AWS. Le paramètre cr-name indique le nom de l'instance du contrôleur AWS Load Balancer.

Utilisez l'outil ccoctl pour traiter tous les objets CredentialsRequest dans le répertoire credrequests en exécutant la commande suivante :

ccoctl aws create-iam-roles \
    --name <name> --region=<aws_region> \
    --credentials-requests-dir=<path-to-credrequests-dir> \
    --identity-provider-arn <oidc-arn>

$ ccoctl aws create-iam-roles \
    --name <name> --region=<aws_region> \
    --credentials-requests-dir=<path-to-credrequests-dir> \
    --identity-provider-arn <oidc-arn>

Copy to Clipboard

Toggle word wrap

Appliquez les secrets générés dans le répertoire manifests à votre cluster, en exécutant la commande suivante :
```
ls manifests/*-credentials.yaml | xargs -I{} oc apply -f {}
```
```
$ ls manifests/*-credentials.yaml | xargs -I{} oc apply -f {}
```
Copy to Clipboard Toggle word wrap

Vérifiez que le pod aws-load-balancer-controller est créé :

oc -n aws-load-balancer-operator get pods
NAME                                                            READY   STATUS    RESTARTS   AGE
aws-load-balancer-controller-cluster-9b766d6-gg82c              1/1     Running   0          137m
aws-load-balancer-operator-controller-manager-b55ff68cc-85jzg   2/2     Running   0          3h26m

$ oc -n aws-load-balancer-operator get pods
NAME                                                            READY   STATUS    RESTARTS   AGE
aws-load-balancer-controller-cluster-9b766d6-gg82c              1/1     Running   0          137m
aws-load-balancer-operator-controller-manager-b55ff68cc-85jzg   2/2     Running   0          3h26m

Copy to Clipboard

Toggle word wrap

21.4.3. Configuration de l'opérateur AWS Load Balancer sur le cluster Security Token Service à l'aide d'informations d'identification spécifiques
Copier lien

Vous pouvez spécifier le secret d'authentification en utilisant le champ spec.credentials dans la ressource personnalisée (CR) du contrôleur AWS Load Balancer. Vous pouvez utiliser l'objet prédéfini CredentialsRequest du contrôleur pour savoir quels rôles sont requis.

Conditions préalables

Vous devez extraire et préparer le binaire ccoctl.

Procédure

Téléchargez la ressource personnalisée CredentialsRequest (CR) du contrôleur AWS Load Balancer et créez un répertoire pour la stocker en exécutant la commande suivante :

curl --create-dirs -o <path-to-credrequests-dir>/cr.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/controller/controller-credentials-request.yaml

$ curl --create-dirs -o <path-to-credrequests-dir>/cr.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/controller/controller-credentials-request.yaml

Copy to Clipboard

Toggle word wrap

Utilisez l'outil ccoctl pour traiter l'objet CredentialsRequest du contrôleur :

ccoctl aws create-iam-roles \
        --name <name> --region=<aws_region> \
        --credentials-requests-dir=<path-to-credrequests-dir> \
        --identity-provider-arn <oidc-arn>

$ ccoctl aws create-iam-roles \
        --name <name> --region=<aws_region> \
        --credentials-requests-dir=<path-to-credrequests-dir> \
        --identity-provider-arn <oidc-arn>

Copy to Clipboard

Toggle word wrap

Appliquez les secrets à votre cluster :

ls manifests/*-credentials.yaml | xargs -I{} oc apply -f {}

$ ls manifests/*-credentials.yaml | xargs -I{} oc apply -f {}

Copy to Clipboard

Toggle word wrap

Vérifiez que le secret d'identification a été créé pour être utilisé par le contrôleur :

oc -n aws-load-balancer-operator get secret aws-load-balancer-controller-manual-cluster --template='{{index .data "credentials"}}' | base64 -d

$ oc -n aws-load-balancer-operator get secret aws-load-balancer-controller-manual-cluster --template='{{index .data "credentials"}}' | base64 -d

Copy to Clipboard

Toggle word wrap

Exemple de sortie

[default]
    sts_regional_endpoints = regional
    role_arn = arn:aws:iam::999999999999:role/aws-load-balancer-operator-aws-load-balancer-controller
    web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token

[default]
    sts_regional_endpoints = regional
    role_arn = arn:aws:iam::999999999999:role/aws-load-balancer-operator-aws-load-balancer-controller
    web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token

Copy to Clipboard

Toggle word wrap

Créez le fichier YAML de la ressource AWSLoadBalancerController, par exemple sample-aws-lb-manual-creds.yaml, comme suit :
```
apiVersion: networking.olm.openshift.io/v1
kind: AWSLoadBalancerController 
metadata:
  name: cluster 
spec:
  credentials:
    name: <secret-name> 
```
```
apiVersion: networking.olm.openshift.io/v1
kind: AWSLoadBalancerController 
```
1
```
metadata:
  name: cluster 
```
2
```
spec:
  credentials:
    name: <secret-name> 
```
3
Copy to Clipboard Toggle word wrap
1
Définit la ressource AWSLoadBalancerController.
2
Définit le nom de l'instance du contrôleur AWS Load Balancer. Ce nom d'instance est ajouté comme suffixe à toutes les ressources connexes.
3
Spécifie le nom secret contenant les informations d'identification AWS utilisées par le contrôleur.

21.5. Création d'une instance de AWS Load Balancer Controller
Copier lien

Après avoir installé l'opérateur, vous pouvez créer une instance du contrôleur AWS Load Balancer.

21.5.1. Création d'une instance du contrôleur AWS Load Balancer à l'aide d'AWS Load Balancer Operator
Copier lien

Vous ne pouvez installer qu'une seule instance de aws-load-balancer-controller dans un cluster. Vous pouvez créer le contrôleur AWS Load Balancer en utilisant le CLI. L'opérateur AWS Load Balancer (ALB) ne réconcilie que la ressource portant le nom cluster.

Conditions préalables

Vous avez créé l'espace de noms echoserver.
Vous avez accès au CLI OpenShift (oc).

Procédure

Créez un fichier YAML de la ressource aws-load-balancer-controller, par exemple sample-aws-lb.yaml, comme suit :
```
apiVersion: networking.olm.openshift.io/v1
kind: AWSLoadBalancerController 
metadata:
  name: cluster 
spec:
  subnetTagging: Auto 
  additionalResourceTags: 
  - key: example.org/security-scope
    value: staging
  ingressClass: cloud 
  config:
    replicas: 2 
  enabledAddons: 
    - AWSWAFv2 
```
```
apiVersion: networking.olm.openshift.io/v1
kind: AWSLoadBalancerController 
```
1
```
metadata:
  name: cluster 
```
2
```
spec:
  subnetTagging: Auto 
```
3
```
  additionalResourceTags: 
```
4
```
  - key: example.org/security-scope
    value: staging
  ingressClass: cloud 
```
5
```
  config:
    replicas: 2 
```
6
```
  enabledAddons: 
```
7
```
    - AWSWAFv2 
```
8
Copy to Clipboard Toggle word wrap
1
Définit la ressource aws-load-balancer-controller.
2
Définit le nom de l'instance du contrôleur AWS Load Balancer. Ce nom d'instance est ajouté comme suffixe à toutes les ressources connexes.
3
Les options valides sont Auto et Manual. Lorsque la valeur est définie sur Auto, l'opérateur tente de déterminer les sous-réseaux qui appartiennent à la grappe et les marque de manière appropriée. L'opérateur ne peut pas déterminer le rôle correctement si les balises de sous-réseau interne ne sont pas présentes sur le sous-réseau interne. Si vous avez installé votre cluster sur une infrastructure fournie par l'utilisateur, vous pouvez marquer manuellement les sous-réseaux avec les balises de rôle appropriées et définir la stratégie de marquage des sous-réseaux sur Manual.
4
Définit les balises utilisées par le contrôleur lorsqu'il approvisionne les ressources AWS.
5
La valeur par défaut de ce champ est alb. L'opérateur fournit une ressource IngressClass portant le même nom si elle n'existe pas.
6
Spécifie le nombre de répliques du contrôleur.
7
Spécifie les modules complémentaires pour les équilibreurs de charge AWS, qui sont spécifiés par le biais d'annotations.
8
Active l'annotation alb.ingress.kubernetes.io/wafv2-acl-arn.
Créez une ressource aws-load-balancer-controller en exécutant la commande suivante :
```
oc create -f sample-aws-lb.yaml
```
```
$ oc create -f sample-aws-lb.yaml
```
Copy to Clipboard Toggle word wrap

Une fois le contrôleur AWS Load Balancer lancé, créez une ressource deployment:

apiVersion: apps/v1
kind: Deployment 
metadata:
  name: <echoserver> 
  namespace: echoserver
spec:
  selector:
    matchLabels:
      app: echoserver
  replicas: 3 
  template:
    metadata:
      labels:
        app: echoserver
    spec:
      containers:
        - image: openshift/origin-node
          command:
           - "/bin/socat"
          args:
            - TCP4-LISTEN:8080,reuseaddr,fork
            - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
          imagePullPolicy: Always
          name: echoserver
          ports:
            - containerPort: 8080

apiVersion: apps/v1
kind: Deployment

1


metadata:
  name: <echoserver>

2


  namespace: echoserver
spec:
  selector:
    matchLabels:
      app: echoserver
  replicas: 3

3


  template:
    metadata:
      labels:
        app: echoserver
    spec:
      containers:
        - image: openshift/origin-node
          command:
           - "/bin/socat"
          args:
            - TCP4-LISTEN:8080,reuseaddr,fork
            - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
          imagePullPolicy: Always
          name: echoserver
          ports:
            - containerPort: 8080

Copy to Clipboard

Toggle word wrap

1: Définit la ressource de déploiement.
2: Spécifie le nom du déploiement.
3: Spécifie le nombre de répliques du déploiement.

Créer une ressource service:

apiVersion: v1
kind: Service 
metadata:
  name: <echoserver> 
  namespace: echoserver
spec:
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  type: NodePort
  selector:
    app: echoserver

apiVersion: v1
kind: Service

1


metadata:
  name: <echoserver>

2


  namespace: echoserver
spec:
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  type: NodePort
  selector:
    app: echoserver

Copy to Clipboard

Toggle word wrap

1: Définit la ressource de service.
2: Spécifie le nom du service.

Déployer une ressource Ingress soutenue par l'ALB :

apiVersion: networking.k8s.io/v1
kind: Ingress 
metadata:
  name: <echoserver> 
  namespace: echoserver
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: instance
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: <echoserver> 
                port:
                  number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress

1


metadata:
  name: <echoserver>

2


  namespace: echoserver
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: instance
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: <echoserver>

3


                port:
                  number: 80

Copy to Clipboard

Toggle word wrap

1: Définit la ressource d'entrée.
2: Spécifie le nom de la ressource d'entrée.
3: Spécifie le nom de la ressource de service.

Vérification

Vérifiez l'état de la ressource Ingress pour afficher l'hôte de l'équilibreur de charge AWS (ALB) provisionné en exécutant la commande suivante :

HOST=$(oc get ingress -n echoserver echoserver --template='{{(index .status.loadBalancer.ingress 0).hostname}}')

$ HOST=$(oc get ingress -n echoserver echoserver --template='{{(index .status.loadBalancer.ingress 0).hostname}}')

Copy to Clipboard

Toggle word wrap

Vérifiez l'état de l'hôte AWS Load Balancer (ALB) provisionné en exécutant la commande suivante :
```
curl $HOST
```
```
$ curl $HOST
```
Copy to Clipboard Toggle word wrap

21.6. Création de plusieurs entrées
Copier lien

Vous pouvez acheminer le trafic vers différents services faisant partie d'un même domaine par le biais d'un seul équilibreur de charge AWS (ALB). Chaque ressource d'entrée fournit différents points d'extrémité du domaine.

21.6.1. Création de plusieurs entrées via un seul équilibreur de charge AWS
Copier lien

Vous pouvez acheminer le trafic vers plusieurs entrées via un seul équilibreur de charge AWS (ALB) à l'aide de la CLI.

Conditions préalables

Vous avez un accès au CLI OpenShift (oc).

Procédure

Créez un fichier YAML de la ressource IngressClassParams, par exemple sample-single-lb-params.yaml, comme suit :
```
apiVersion: elbv2.k8s.aws/v1beta1 
kind: IngressClassParams
metadata:
  name: <single-lb-params> 
spec:
  group:
    name: single-lb 
```
```
apiVersion: elbv2.k8s.aws/v1beta1 
```
1
```
kind: IngressClassParams
metadata:
  name: <single-lb-params> 
```
2
```
spec:
  group:
    name: single-lb 
```
3
Copy to Clipboard Toggle word wrap
1
Définit le groupe API et la version de la ressource IngressClassParams.
2
Spécifie le nom de la ressource IngressClassParams.
3
Spécifie le nom de la classe IngressGroup. Toutes les entrées de cette classe appartiennent à cette classe IngressGroup.
Créez une ressource IngressClassParams en exécutant la commande suivante :
```
oc create -f sample-single-lb-params.yaml
```
```
$ oc create -f sample-single-lb-params.yaml
```
Copy to Clipboard Toggle word wrap
Créez un fichier YAML de la ressource IngressClass, par exemple sample-single-lb.yaml, comme suit :
```
apiVersion: networking.k8s.io/v1 
kind: IngressClass
metadata:
  name: <single-lb> 
spec:
  controller: ingress.k8s.aws/alb 
  parameters:
    apiGroup: elbv2.k8s.aws 
    kind: IngressClassParams 
    name: single-lb 
```
```
apiVersion: networking.k8s.io/v1 
```
1
```
kind: IngressClass
metadata:
  name: <single-lb> 
```
2
```
spec:
  controller: ingress.k8s.aws/alb 
```
3
```
  parameters:
    apiGroup: elbv2.k8s.aws 
```
4
```
    kind: IngressClassParams 
```
5
```
    name: single-lb 
```
6
Copy to Clipboard Toggle word wrap
1
Définit le groupe API et la version de la ressource IngressClass.
2
Spécifie le nom du site IngressClass.
3
Définit le nom du contrôleur, commun à tous les IngressClasses. Le site aws-load-balancer-controller réconcilie le contrôleur.
4
Définit le groupe API de la ressource IngressClassParams.
5
Définit le type de ressource de la ressource IngressClassParams.
6
Définit le nom de la ressource IngressClassParams.
Créez une ressource IngressClass en exécutant la commande suivante :
```
oc create -f sample-single-lb.yaml
```
```
$ oc create -f sample-single-lb.yaml
```
Copy to Clipboard Toggle word wrap

Créez un fichier YAML de la ressource Ingress, par exemple sample-multiple-ingress.yaml, comme suit :

apiVersion: networking.k8s.io/v1 
kind: Ingress
metadata:
  name: <example-1> 
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing 
    alb.ingress.kubernetes.io/group.order: "1" 
spec:
  ingressClass: alb 
  rules:
  - host: example.com 
    http:
        paths:
        - path: /blog 
          backend:
            service:
              name: <example-1> 
              port:
                number: 80 
kind: Ingress
metadata:
  name: <example-2>
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/group.order: "2"
spec:
  ingressClass: alb
  rules:
  - host: example.com
    http:
        paths:
        - path: /store
          backend:
            service:
              name: <example-2>
              port:
                number: 80
kind: Ingress
  metadata:
  name: <example-3>
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/group.order: "3"
spec:
  ingressClass: alb
  rules:
  - host: example.com
    http:
        paths:
        - path: /
          backend:
            service:
              name: <example-3>
              port:
                number: 80

apiVersion: networking.k8s.io/v1

1


kind: Ingress
metadata:
  name: <example-1>

2


  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing

3


    alb.ingress.kubernetes.io/group.order: "1"

4


spec:
  ingressClass: alb

5


  rules:
  - host: example.com

6


    http:
        paths:
        - path: /blog

7


          backend:
            service:
              name: <example-1>

8


              port:
                number: 80

9


kind: Ingress
metadata:
  name: <example-2>
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/group.order: "2"
spec:
  ingressClass: alb
  rules:
  - host: example.com
    http:
        paths:
        - path: /store
          backend:
            service:
              name: <example-2>
              port:
                number: 80
kind: Ingress
  metadata:
  name: <example-3>
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/group.order: "3"
spec:
  ingressClass: alb
  rules:
  - host: example.com
    http:
        paths:
        - path: /
          backend:
            service:
              name: <example-3>
              port:
                number: 80

Copy to Clipboard

Toggle word wrap

1 2: Spécifie le nom d'une entrée.
3: Indique que l'équilibreur de charge doit être placé dans le sous-réseau public et le rend accessible sur l'internet.
4: Spécifie l'ordre dans lequel les règles des entrées sont appliquées lorsque la demande est reçue par l'équilibreur de charge.
5: Spécifie la classe d'entrée qui appartient à cette entrée.
6: Définit le nom d'un domaine utilisé pour l'acheminement des demandes.
7: Définit le chemin qui doit mener au service.
8: Définit le nom du service qui dessert le point de terminaison configuré dans l'entrée.
9: Définit le port du service qui dessert le point d'extrémité.

Créez les ressources Ingress en exécutant la commande suivante :
```
oc create -f sample-multiple-ingress.yaml
```
```
$ oc create -f sample-multiple-ingress.yaml
```
Copy to Clipboard Toggle word wrap

21.7. Ajout de la terminaison TLS
Copier lien

Vous pouvez ajouter une terminaison TLS sur l'équilibreur de charge AWS.

21.7.1. Ajout d'une terminaison TLS sur l'équilibreur de charge AWS
Copier lien

Vous pouvez acheminer le trafic du domaine vers les pods d'un service et ajouter une terminaison TLS sur l'équilibreur de charge AWS.

Conditions préalables

Vous avez un accès au CLI OpenShift (oc).

Procédure

Installez l'opérateur et créez une instance de la ressource aws-load-balancer-controller:
```
apiVersion: networking.olm.openshift.io/v1
kind: AWSLoadBalancerController
metadata:
  name: cluster 
spec:
  subnetTagging: auto
  ingressClass: tls-termination 
```
```
apiVersion: networking.olm.openshift.io/v1
kind: AWSLoadBalancerController
metadata:
  name: cluster 
```
1
```
spec:
  subnetTagging: auto
  ingressClass: tls-termination 
```
2
Copy to Clipboard Toggle word wrap
1
Définit l'instance aws-load-balancer-controller.
2
Définit le nom d'une ressource ingressClass réconciliée par le contrôleur AWS Load Balancer. Cette ressource ingressClass est créée si elle n'existe pas. Vous pouvez ajouter des valeurs ingressClass supplémentaires. Le contrôleur réconcilie les valeurs ingressClass si la ressource spec.controller est définie sur ingress.k8s.aws/alb.

Créer une ressource Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <example> 
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing 
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx 
spec:
  ingressClassName: tls-termination 
  rules:
  - host: <example.com> 
    http:
        paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: <example-service> 
                port:
                  number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <example>

1


  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing

2


    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx

3


spec:
  ingressClassName: tls-termination

4


  rules:
  - host: <example.com>

5


    http:
        paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: <example-service>

6


                port:
                  number: 80

Copy to Clipboard

Toggle word wrap

1: Spécifie le nom d'une entrée.
2: Le contrôleur fournit l'équilibreur de charge pour cette ressource Ingress dans un sous-réseau public de sorte que l'équilibreur de charge soit accessible sur l'internet.
3: Le nom de ressource Amazon du certificat que vous attachez à l'équilibreur de charge.
4: Définit le nom de la classe d'entrée.
5: Définit le domaine pour l'acheminement du trafic.
6: Définit le service d'acheminement du trafic.

21.8. Configuration d'un proxy à l'échelle d'un cluster
Copier lien

Vous pouvez configurer le proxy à l'échelle du cluster dans l'opérateur AWS Load Balancer. Après avoir configuré le proxy en grappe dans l'opérateur AWS Load Balancer, Operator Lifecycle Manager (OLM) met automatiquement à jour tous les déploiements des opérateurs avec les variables d'environnement telles que HTTP_PROXY, HTTPS_PROXY, et NO_PROXY. Ces variables sont ajoutées au contrôleur géré par l'opérateur d'équilibreur de charge AWS.

21.8.1. Configurer l'opérateur AWS Load Balancer pour qu'il fasse confiance à l'autorité de certification du proxy à l'échelle du cluster
Copier lien

Créez la carte de configuration pour contenir le bundle de l'autorité de certification (CA) dans l'espace de noms aws-load-balancer-operator et injectez un bundle CA qui est approuvé par OpenShift Container Platform dans une carte de configuration en exécutant la commande suivante :
```
oc -n aws-load-balancer-operator create configmap trusted-ca
```
```
$ oc -n aws-load-balancer-operator create configmap trusted-ca
```
Copy to Clipboard Toggle word wrap
Pour injecter le paquet d'AC de confiance dans la carte de configuration, ajoutez l'étiquette config.openshift.io/inject-trusted-cabundle=true à la carte de configuration en exécutant la commande suivante :
```
oc -n aws-load-balancer-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
```
```
$ oc -n aws-load-balancer-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
```
Copy to Clipboard Toggle word wrap

Mettez à jour l'abonnement de l'AWS Load Balancer Operator pour accéder à la carte de configuration dans le déploiement de l'AWS Load Balancer Operator en exécutant la commande suivante :

oc -n aws-load-balancer-operator patch subscription aws-load-balancer-operator --type='merge' -p '{"spec":{"config":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}],"volumes":[{"name":"trusted-ca","configMap":{"name":"trusted-ca"}}],"volumeMounts":[{"name":"trusted-ca","mountPath":"/etc/pki/tls/certs/albo-tls-ca-bundle.crt","subPath":"ca-bundle.crt"}]}}}'

$ oc -n aws-load-balancer-operator patch subscription aws-load-balancer-operator --type='merge' -p '{"spec":{"config":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}],"volumes":[{"name":"trusted-ca","configMap":{"name":"trusted-ca"}}],"volumeMounts":[{"name":"trusted-ca","mountPath":"/etc/pki/tls/certs/albo-tls-ca-bundle.crt","subPath":"ca-bundle.crt"}]}}}'

Copy to Clipboard

Toggle word wrap

Une fois le déploiement de l'opérateur AWS Load Balancer terminé, vérifiez que le bundle CA est ajouté au déploiement aws-load-balancer-operator-controller-manager en exécutant la commande suivante :

oc -n aws-load-balancer-operator exec deploy/aws-load-balancer-operator-controller-manager -c manager -- bash -c "ls -l /etc/pki/tls/certs/albo-tls-ca-bundle.crt; printenv TRUSTED_CA_CONFIGMAP_NAME"

$ oc -n aws-load-balancer-operator exec deploy/aws-load-balancer-operator-controller-manager -c manager -- bash -c "ls -l /etc/pki/tls/certs/albo-tls-ca-bundle.crt; printenv TRUSTED_CA_CONFIGMAP_NAME"

Copy to Clipboard

Toggle word wrap

Exemple de sortie

-rw-r--r--. 1 root 1000690000 5875 Jan 11 12:25 /etc/pki/tls/certs/albo-tls-ca-bundle.crt
trusted-ca

-rw-r--r--. 1 root 1000690000 5875 Jan 11 12:25 /etc/pki/tls/certs/albo-tls-ca-bundle.crt
trusted-ca

Copy to Clipboard

Toggle word wrap

Facultatif : Redémarrez le déploiement de l'opérateur AWS Load Balancer chaque fois que la carte de configuration est modifiée en exécutant la commande suivante :
```
oc -n aws-load-balancer-operator rollout restart deployment/aws-load-balancer-operator-controller-manager
```
```
$ oc -n aws-load-balancer-operator rollout restart deployment/aws-load-balancer-operator-controller-manager
```
Copy to Clipboard Toggle word wrap

Chapitre 22. Réseaux multiples
Copier lien

22.1. Comprendre les réseaux multiples
Copier lien

Dans Kubernetes, la mise en réseau des conteneurs est déléguée à des plugins de mise en réseau qui mettent en œuvre l'interface de réseau de conteneurs (CNI).

OpenShift Container Platform utilise le plugin CNI Multus pour permettre le chaînage des plugins CNI. Lors de l'installation du cluster, vous configurez votre réseau de pods default. Le réseau par défaut gère tout le trafic réseau ordinaire pour le cluster. Vous pouvez définir un additional network basé sur les plugins CNI disponibles et attacher un ou plusieurs de ces réseaux à vos pods. Vous pouvez définir plusieurs réseaux supplémentaires pour votre cluster, en fonction de vos besoins. Cela vous donne de la flexibilité lorsque vous configurez des pods qui fournissent des fonctionnalités réseau, telles que la commutation ou le routage.

22.1.1. Scénarios d'utilisation d'un réseau supplémentaire
Copier lien

Vous pouvez utiliser un réseau supplémentaire dans les situations où l'isolation du réseau est nécessaire, y compris la séparation du plan de données et du plan de contrôle. L'isolation du trafic réseau est utile pour les raisons de performance et de sécurité suivantes :

Performances: Vous pouvez envoyer du trafic sur deux plans différents afin de gérer la quantité de trafic sur chaque plan.
Sécurité: Vous pouvez envoyer le trafic sensible sur un plan de réseau géré spécifiquement pour des considérations de sécurité, et vous pouvez séparer les données privées qui ne doivent pas être partagées entre les locataires ou les clients.

Tous les pods du cluster utilisent toujours le réseau par défaut du cluster pour maintenir la connectivité à travers le cluster. Chaque module dispose d'une interface eth0 qui est attachée au réseau du module à l'échelle du cluster. Vous pouvez afficher les interfaces d'un module à l'aide de la commande oc exec -it <pod_name> -- ip a. Si vous ajoutez des interfaces réseau supplémentaires qui utilisent Multus CNI, elles sont nommées net1, net2, ..., netN.

Pour attacher des interfaces réseau supplémentaires à un pod, vous devez créer des configurations qui définissent la manière dont les interfaces sont attachées. Vous spécifiez chaque interface en utilisant une ressource personnalisée (CR) NetworkAttachmentDefinition. Une configuration CNI à l'intérieur de chacune de ces CR définit la manière dont cette interface est créée.

22.1.2. Réseaux supplémentaires dans OpenShift Container Platform
Copier lien

OpenShift Container Platform fournit les plugins CNI suivants pour créer des réseaux supplémentaires dans votre cluster :

bridge: Configurez un réseau supplémentaire basé sur un pont pour permettre aux pods sur le même hôte de communiquer entre eux et avec l'hôte.
host-device: Configurer un réseau supplémentaire hôte-dispositif pour permettre aux pods d'accéder à un périphérique de réseau Ethernet physique sur le système hôte.
ipvlan: Configurer un réseau supplémentaire basé sur ipvlan pour permettre aux pods d'un hôte de communiquer avec d'autres hôtes et pods sur ces hôtes, de manière similaire à un réseau supplémentaire basé sur macvlan. Contrairement à un réseau supplémentaire basé sur macvlan, chaque pod partage la même adresse MAC que l'interface réseau physique parent.
macvlan: Configurer un réseau supplémentaire basé sur macvlan pour permettre aux pods sur un hôte de communiquer avec d'autres hôtes et pods sur ces hôtes en utilisant une interface réseau physique. Chaque pod attaché à un réseau supplémentaire basé sur macvlan reçoit une adresse MAC unique.
SR-IOV: Configurer un réseau supplémentaire basé sur SR-IOV pour permettre aux pods de s'attacher à une interface de fonction virtuelle (VF) sur un matériel compatible SR-IOV sur le système hôte.

22.2. Configuration d'un réseau supplémentaire
Copier lien

En tant qu'administrateur de cluster, vous pouvez configurer un réseau supplémentaire pour votre cluster. Les types de réseaux suivants sont pris en charge :

22.2.1. Approches de la gestion d'un réseau supplémentaire
Copier lien

Vous pouvez gérer le cycle de vie d'un réseau supplémentaire selon deux approches. Chaque approche est mutuellement exclusive et vous ne pouvez utiliser qu'une seule approche à la fois pour gérer un réseau supplémentaire. Dans les deux cas, le réseau supplémentaire est géré par un plugin CNI (Container Network Interface) que vous configurez.

Pour un réseau supplémentaire, les adresses IP sont fournies par un plugin CNI de gestion des adresses IP (IPAM) que vous configurez dans le cadre du réseau supplémentaire. Le plugin IPAM prend en charge une variété d'approches d'attribution d'adresses IP, y compris l'attribution DHCP et l'attribution statique.

Modifier la configuration du Cluster Network Operator (CNO) : Le CNO crée et gère automatiquement l'objet NetworkAttachmentDefinition. En plus de gérer le cycle de vie de l'objet, le CNO s'assure qu'un DHCP est disponible pour un réseau supplémentaire qui utilise une adresse IP attribuée par DHCP.
Appliquer un manifeste YAML : Vous pouvez gérer le réseau supplémentaire directement en créant un objet NetworkAttachmentDefinition. Cette approche permet le chaînage des plugins CNI.

Note

Lors du déploiement de nœuds OpenShift Container Platform avec plusieurs interfaces réseau sur Red Hat OpenStack Platform (RHOSP) avec OVN SDN, la configuration DNS de l'interface secondaire peut être prioritaire sur la configuration DNS de l'interface primaire. Dans ce cas, supprimez les serveurs de noms DNS pour l'identifiant de sous-réseau qui est attaché à l'interface secondaire :

openstack subnet set --dns-nameserver 0.0.0.0 <subnet_id>

$ openstack subnet set --dns-nameserver 0.0.0.0 <subnet_id>

Copy to Clipboard

Toggle word wrap

22.2.2. Configuration pour une connexion réseau supplémentaire
Copier lien

Un réseau supplémentaire est configuré en utilisant l'API NetworkAttachmentDefinition dans le groupe d'API k8s.cni.cncf.io.

Important

Ne stockez pas d'informations sensibles ou secrètes dans l'objet NetworkAttachmentDefinition car ces informations sont accessibles à l'utilisateur de l'administration du projet.

La configuration de l'API est décrite dans le tableau suivant :

Expand

Tableau 22.1. NetworkAttachmentDefinition Champs de l'API
Field	Type	Description
`metadata.name`	`string`	Nom du réseau supplémentaire.
`metadata.namespace`	`string`	L'espace de noms auquel l'objet est associé.
`spec.config`	`string`	La configuration du plugin CNI au format JSON.

22.2.2.1. Configuration d'un réseau supplémentaire par l'intermédiaire de l'opérateur de réseau du cluster
Copier lien

La configuration d'une connexion réseau supplémentaire est spécifiée dans le cadre de la configuration de l'opérateur de réseau de cluster (CNO).

Le fichier YAML suivant décrit les paramètres de configuration pour la gestion d'un réseau supplémentaire avec le CNO :

Cluster Network Operator configuration

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
  additionalNetworks: 
  - name: <name> 
    namespace: <namespace> 
    rawCNIConfig: |- 
      {
        ...
      }
    type: Raw

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
  additionalNetworks:

1


  - name: <name>

2


    namespace: <namespace>

3


    rawCNIConfig: |-

4


      {
        ...
      }
    type: Raw

Copy to Clipboard

Toggle word wrap

1: Un tableau d'une ou plusieurs configurations de réseau supplémentaires.
2: Le nom de la pièce jointe réseau supplémentaire que vous créez. Le nom doit être unique au sein de l'adresse namespace.
3: L'espace de noms dans lequel l'attachement au réseau doit être créé. Si vous ne spécifiez pas de valeur, l'espace de noms default est utilisé.
4: Une configuration du plugin CNI au format JSON.

22.2.2.2. Configuration d'un réseau supplémentaire à partir d'un manifeste YAML
Copier lien

La configuration d'un réseau supplémentaire est spécifiée dans un fichier de configuration YAML, comme dans l'exemple suivant :

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: <name> 
spec:
  config: |- 
    {
      ...
    }

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: <name>

1


spec:
  config: |-

2


    {
      ...
    }

Copy to Clipboard

Toggle word wrap

1: Nom de la pièce jointe réseau supplémentaire que vous créez.
2: Une configuration du plugin CNI au format JSON.

22.2.3. Configurations pour des types de réseaux supplémentaires
Copier lien

Les champs de configuration spécifiques aux réseaux supplémentaires sont décrits dans les sections suivantes.

22.2.3.1. Configuration d'un réseau supplémentaire de ponts
Copier lien

L'objet suivant décrit les paramètres de configuration du plugin CNI bridge :

Expand

Tableau 22.2. Objet de configuration JSON du plugin CNI Bridge
Field	Type	Description
`cniVersion`	`string`	La version de la spécification CNI. La valeur `0.3.1` est obligatoire.
`name`	`string`	La valeur du paramètre `name` que vous avez fourni précédemment pour la configuration CNO.
`type`	`string`
`bridge`	`string`	Indiquez le nom du pont virtuel à utiliser. Si l'interface du pont n'existe pas sur l'hôte, elle est créée. La valeur par défaut est `cni0`.
`ipam`	`object`	L'objet de configuration pour le plugin IPAM CNI. Le plugin gère l'attribution des adresses IP pour la définition des pièces jointes.
`ipMasq`	`boolean`	La valeur `true` permet d'activer le masquage IP pour le trafic qui quitte le réseau virtuel. L'adresse IP source de tout le trafic est remplacée par l'adresse IP du pont. Si le pont n'a pas d'adresse IP, ce paramètre n'a aucun effet. La valeur par défaut est `false`.
`isGateway`	`boolean`	La valeur `true` permet d'attribuer une adresse IP à la passerelle. La valeur par défaut est `false`.
`isDefaultGateway`	`boolean`	La valeur `true` permet de configurer le pont comme passerelle par défaut pour le réseau virtuel. La valeur par défaut est `false`. Si `isDefaultGateway` est défini sur `true`, `isGateway` est également défini sur `true` automatiquement.
`forceAddress`	`boolean`	Défini sur `true` pour permettre l'attribution d'une adresse IP précédemment attribuée au pont virtuel. Lorsque la valeur est `false`, une erreur se produit si une adresse IPv4 ou une adresse IPv6 provenant de sous-ensembles qui se chevauchent est attribuée au pont virtuel. La valeur par défaut est `false`.
`hairpinMode`	`boolean`	La valeur `true` permet au pont virtuel de renvoyer une trame Ethernet par le port virtuel sur lequel elle a été reçue. Ce mode est également connu sous le nom de reflective relay. La valeur par défaut est `false`.
`promiscMode`	`boolean`	La valeur `true` permet d'activer le mode promiscuous sur le pont. La valeur par défaut est `false`.
`vlan`	`string`	Spécifiez une balise de réseau local virtuel (VLAN) sous la forme d'une valeur entière. Par défaut, aucune balise VLAN n'est attribuée.
`mtu`	`string`	Fixe l'unité de transmission maximale (MTU) à la valeur spécifiée. La valeur par défaut est définie automatiquement par le noyau.

22.2.3.1.1. exemple de configuration de pont
Copier lien

L'exemple suivant configure un réseau supplémentaire nommé bridge-net:

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "bridge",
  "isGateway": true,
  "vlan": 2,
  "ipam": {
    "type": "dhcp"
    }
}

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "bridge",
  "isGateway": true,
  "vlan": 2,
  "ipam": {
    "type": "dhcp"
    }
}

Copy to Clipboard

Toggle word wrap

22.2.3.2. Configuration d'un périphérique hôte réseau supplémentaire
Copier lien

Note

Spécifiez votre périphérique réseau en définissant un seul des paramètres suivants : device, hwaddr, kernelpath, ou pciBusID.

L'objet suivant décrit les paramètres de configuration du plugin CNI hôte-dispositif :

Expand

Tableau 22.3. Objet de configuration JSON du plugin CNI de l'appareil hôte
Field	Type	Description
`cniVersion`	`string`	La version de la spécification CNI. La valeur `0.3.1` est obligatoire.
`name`	`string`	La valeur du paramètre `name` que vous avez fourni précédemment pour la configuration CNO.
`type`	`string`	Le nom du plugin CNI à configurer : `host-device`.
`device`	`string`	Facultatif : Le nom de l'appareil, par exemple `eth0`.
`hwaddr`	`string`	Facultatif : L'adresse MAC du matériel de l'appareil.
`kernelpath`	`string`	Facultatif : Le chemin d'accès au périphérique du noyau Linux, tel que `/sys/devices/pci0000:00/0000:00:1f.6`.
`pciBusID`	`string`	Facultatif : L'adresse PCI du périphérique réseau, par exemple `0000:00:1f.6`.

22.2.3.2.1. exemple de configuration d'un dispositif hôte
Copier lien

L'exemple suivant configure un réseau supplémentaire nommé hostdev-net:

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "host-device",
  "device": "eth1"
}

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "host-device",
  "device": "eth1"
}

Copy to Clipboard

Toggle word wrap

22.2.3.3. Configuration d'un réseau supplémentaire IPVLAN
Copier lien

L'objet suivant décrit les paramètres de configuration du plugin IPVLAN CNI :

Expand

Tableau 22.4. Objet de configuration JSON du plugin CNI IPVLAN
Field	Type	Description
`cniVersion`	`string`	La version de la spécification CNI. La valeur `0.3.1` est obligatoire.
`name`	`string`	La valeur du paramètre `name` que vous avez fourni précédemment pour la configuration CNO.
`type`	`string`	Le nom du plugin CNI à configurer : `ipvlan`.
`mode`	`string`	Le mode de fonctionnement du réseau virtuel. La valeur doit être `l2`, `l3` ou `l3s`. La valeur par défaut est `l2`.
`master`	`string`	L'interface Ethernet à associer à l'attachement réseau. Si l'adresse `master` n'est pas spécifiée, c'est l'interface de la route réseau par défaut qui est utilisée.
`mtu`	`integer`	Fixe l'unité de transmission maximale (MTU) à la valeur spécifiée. La valeur par défaut est définie automatiquement par le noyau.
`ipam`	`object`	L'objet de configuration pour le plugin IPAM CNI. Le plugin gère l'attribution des adresses IP pour la définition des pièces jointes. Ne pas spécifier `dhcp`. La configuration d'IPVLAN avec DHCP n'est pas supportée car les interfaces IPVLAN partagent l'adresse MAC avec l'interface hôte.

22.2.3.3.1. exemple de configuration ipvlan
Copier lien

L'exemple suivant configure un réseau supplémentaire nommé ipvlan-net:

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "ipvlan",
  "master": "eth1",
  "mode": "l3",
  "ipam": {
    "type": "static",
    "addresses": [
       {
         "address": "192.168.10.10/24"
       }
    ]
  }
}

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "ipvlan",
  "master": "eth1",
  "mode": "l3",
  "ipam": {
    "type": "static",
    "addresses": [
       {
         "address": "192.168.10.10/24"
       }
    ]
  }
}

Copy to Clipboard

Toggle word wrap

22.2.3.4. Configuration d'un réseau supplémentaire MACVLAN
Copier lien

L'objet suivant décrit les paramètres de configuration du plugin CNI macvlan :

Expand

Tableau 22.5. Objet de configuration JSON du plugin CNI MACVLAN
Field	Type	Description
`cniVersion`	`string`	La version de la spécification CNI. La valeur `0.3.1` est obligatoire.
`name`	`string`	La valeur du paramètre `name` que vous avez fourni précédemment pour la configuration CNO.
`type`	`string`	Le nom du plugin CNI à configurer : `macvlan`.
`mode`	`string`	Configure la visibilité du trafic sur le réseau virtuel. Doit être soit `bridge`, `passthru`, `private`, ou `vepa`. Si aucune valeur n'est fournie, la valeur par défaut est `bridge`.
`master`	`string`	L'interface réseau de l'hôte à associer à l'interface macvlan nouvellement créée. Si aucune valeur n'est spécifiée, l'interface de la route par défaut est utilisée.
`mtu`	`string`	L'unité de transmission maximale (MTU) à la valeur spécifiée. La valeur par défaut est définie automatiquement par le noyau.
`ipam`	`object`	L'objet de configuration pour le plugin IPAM CNI. Le plugin gère l'attribution des adresses IP pour la définition des pièces jointes.

Note

Si vous spécifiez la clé master pour la configuration du plugin, utilisez une interface réseau physique différente de celle qui est associée à votre plugin réseau principal afin d'éviter tout conflit éventuel.

22.2.3.4.1. exemple de configuration macvlan
Copier lien

L'exemple suivant configure un réseau supplémentaire nommé macvlan-net:

{
  "cniVersion": "0.3.1",
  "name": "macvlan-net",
  "type": "macvlan",
  "master": "eth1",
  "mode": "bridge",
  "ipam": {
    "type": "dhcp"
    }
}

{
  "cniVersion": "0.3.1",
  "name": "macvlan-net",
  "type": "macvlan",
  "master": "eth1",
  "mode": "bridge",
  "ipam": {
    "type": "dhcp"
    }
}

Copy to Clipboard

Toggle word wrap

22.2.4. Configuration de l'attribution d'adresses IP pour un réseau supplémentaire
Copier lien

Le module de gestion des adresses IP (IPAM) Container Network Interface (CNI) fournit des adresses IP aux autres modules CNI.

Vous pouvez utiliser les types d'attribution d'adresses IP suivants :

Affectation statique.
Attribution dynamique par le biais d'un serveur DHCP. Le serveur DHCP que vous spécifiez doit être accessible depuis le réseau supplémentaire.
Affectation dynamique via le plugin CNI de Whereabouts IPAM.

22.2.4.1. Configuration de l'attribution d'une adresse IP statique
Copier lien

Le tableau suivant décrit la configuration pour l'attribution d'une adresse IP statique :

Expand

Tableau 22.6. ipam objet de configuration statique
Field	Type	Description
`type`	`string`	Le type d'adresse IPAM. La valeur `static` est obligatoire.
`addresses`	`array`	Un tableau d'objets spécifiant les adresses IP à attribuer à l'interface virtuelle. Les adresses IPv4 et IPv6 sont prises en charge.
`routes`	`array`	Un tableau d'objets spécifiant les routes à configurer dans le pod.
`dns`	`array`	Facultatif : Un tableau d'objets spécifiant la configuration DNS.

Le tableau addresses nécessite des objets avec les champs suivants :

Expand

Tableau 22.7. ipam.addresses[] réseau
Field	Type	Description
`address`	`string`	Une adresse IP et un préfixe de réseau que vous spécifiez. Par exemple, si vous spécifiez `10.10.21.10/24`, le réseau supplémentaire se voit attribuer une adresse IP de `10.10.21.10` et le masque de réseau est `255.255.255.0`.
`gateway`	`string`	Passerelle par défaut vers laquelle acheminer le trafic réseau sortant.

Expand

Tableau 22.8. ipam.routes[] réseau
Field	Type	Description
`dst`	`string`	La plage d'adresses IP au format CIDR, par exemple `192.168.17.0/24` ou `0.0.0.0/0` pour la route par défaut.
`gw`	`string`	La passerelle où le trafic réseau est acheminé.

Expand

Tableau 22.9. ipam.dns objet
Field	Type	Description
`nameservers`	`array`	Un tableau d'une ou plusieurs adresses IP auxquelles envoyer les requêtes DNS.
`domain`	`array`	Le domaine par défaut à ajouter à un nom d'hôte. Par exemple, si le domaine est défini sur `example.com`, une requête DNS pour `example-host` est réécrite en `example-host.example.com`.
`search`	`array`	Un tableau de noms de domaine à ajouter à un nom d'hôte non qualifié, tel que `example-host`, lors d'une requête de recherche DNS.

Exemple de configuration de l'attribution d'une adresse IP statique

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

Copy to Clipboard

Toggle word wrap

22.2.4.2. Configuration de l'attribution dynamique d'adresses IP (DHCP)
Copier lien

Le JSON suivant décrit la configuration pour l'attribution dynamique d'adresses IP avec DHCP.

Renouvellement des baux DHCP

Un pod obtient son bail DHCP d'origine lors de sa création. Le bail doit être renouvelé périodiquement par un serveur DHCP minimal déployé sur le cluster.

Pour déclencher le déploiement du serveur DHCP, vous devez créer un attachement réseau shim en modifiant la configuration de l'opérateur réseau du cluster, comme dans l'exemple suivant :

Exemple de définition de l'attachement au réseau de cales

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

Copy to Clipboard

Toggle word wrap

Expand

Tableau 22.10. ipam Objet de configuration DHCP
Field	Type	Description
`type`	`string`	Le type d'adresse IPAM. La valeur `dhcp` est obligatoire.

Exemple de configuration de l'attribution dynamique d'une adresse IP (DHCP)

{
  "ipam": {
    "type": "dhcp"
  }
}

{
  "ipam": {
    "type": "dhcp"
  }
}

Copy to Clipboard

Toggle word wrap

22.2.4.3. Configuration de l'attribution dynamique d'adresses IP avec Whereabouts
Copier lien

Le plugin Whereabouts CNI permet l'attribution dynamique d'une adresse IP à un réseau supplémentaire sans utiliser de serveur DHCP.

Le tableau suivant décrit la configuration pour l'attribution dynamique d'adresses IP avec Whereabouts :

Expand

Tableau 22.11. ipam objet de configuration de la localisation
Field	Type	Description
`type`	`string`	Le type d'adresse IPAM. La valeur `whereabouts` est obligatoire.
`range`	`string`	Une adresse IP et une plage d'adresses en notation CIDR. Les adresses IP sont attribuées à partir de cette plage d'adresses.
`exclude`	`array`	Facultatif : Une liste de zéro ou plusieurs adresses IP et plages d'adresses en notation CIDR. Les adresses IP situées dans une plage d'adresses exclue ne sont pas attribuées.

Exemple de configuration de l'attribution dynamique d'adresses IP à l'aide de Whereabouts

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

Copy to Clipboard

Toggle word wrap

22.2.5. Création d'un rattachement réseau supplémentaire avec l'opérateur de réseau de cluster
Copier lien

Le Cluster Network Operator (CNO) gère les définitions de réseaux supplémentaires. Lorsque vous spécifiez un réseau supplémentaire à créer, le CNO crée automatiquement l'objet NetworkAttachmentDefinition.

Important

Ne modifiez pas les objets NetworkAttachmentDefinition gérés par le Cluster Network Operator. Cela risquerait de perturber le trafic sur votre réseau supplémentaire.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Facultatif : Créez l'espace de noms pour les réseaux supplémentaires :

oc create namespace <namespace_name> $ oc create namespace <namespace_name>

oc create namespace <namespace_name> $ oc create namespace <namespace_name>

Copy to Clipboard

Toggle word wrap

Pour modifier la configuration du CNO, entrez la commande suivante :
```
oc edit networks.operator.openshift.io cluster
```
```
$ oc edit networks.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap

Modifiez le CR que vous êtes en train de créer en ajoutant la configuration pour le réseau supplémentaire que vous êtes en train de créer, comme dans l'exemple de CR suivant.

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
  additionalNetworks:
  - name: tertiary-net
    namespace: namespace2
    type: Raw
    rawCNIConfig: |-
      {
        "cniVersion": "0.3.1",
        "name": "tertiary-net",
        "type": "ipvlan",
        "master": "eth1",
        "mode": "l2",
        "ipam": {
          "type": "static",
          "addresses": [
            {
              "address": "192.168.1.23/24"
            }
          ]
        }
      }

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
  additionalNetworks:
  - name: tertiary-net
    namespace: namespace2
    type: Raw
    rawCNIConfig: |-
      {
        "cniVersion": "0.3.1",
        "name": "tertiary-net",
        "type": "ipvlan",
        "master": "eth1",
        "mode": "l2",
        "ipam": {
          "type": "static",
          "addresses": [
            {
              "address": "192.168.1.23/24"
            }
          ]
        }
      }

Copy to Clipboard

Toggle word wrap

Enregistrez vos modifications et quittez l'éditeur de texte pour valider vos modifications.

Vérification

Confirmez que le CNO a créé l'objet NetworkAttachmentDefinition en exécutant la commande suivante. Il peut y avoir un délai avant que le CNO ne crée l'objet.
```
oc get network-attachment-definitions -n <namespace>
```
```
oc get network-attachment-definitions -n <namespace>
```
Copy to Clipboard Toggle word wrap
où :
<namespace>
Spécifie l'espace de noms pour l'attachement réseau que vous avez ajouté à la configuration CNO.
Exemple de sortie
```
NAME                 AGE
test-network-1       14m
```
```
NAME                 AGE
test-network-1       14m
```
Copy to Clipboard Toggle word wrap

22.2.6. Création d'une pièce jointe réseau supplémentaire par l'application d'un manifeste YAML
Copier lien

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créez un fichier YAML avec votre configuration réseau supplémentaire, comme dans l'exemple suivant :

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: next-net
spec:
  config: |-
    {
      "cniVersion": "0.3.1",
      "name": "work-network",
      "type": "host-device",
      "device": "eth1",
      "ipam": {
        "type": "dhcp"
      }
    }

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: next-net
spec:
  config: |-
    {
      "cniVersion": "0.3.1",
      "name": "work-network",
      "type": "host-device",
      "device": "eth1",
      "ipam": {
        "type": "dhcp"
      }
    }

Copy to Clipboard

Toggle word wrap

Pour créer le réseau supplémentaire, entrez la commande suivante :
```
oc apply -f <file>.yaml
```
```
oc apply -f <file>.yaml
```
Copy to Clipboard Toggle word wrap
où :
<file>
Spécifie le nom du fichier contenant le manifeste YAML.

22.3. À propos du routage et du transfert virtuels
Copier lien

22.3.1. À propos du routage et du transfert virtuels
Copier lien

Les dispositifs de routage et de transfert virtuels (VRF) combinés aux règles IP permettent de créer des domaines de routage et de transfert virtuels. La VRF réduit le nombre d'autorisations nécessaires à la CNF et offre une meilleure visibilité de la topologie des réseaux secondaires. La VRF est utilisée pour fournir une fonctionnalité multi-locataires, par exemple, lorsque chaque locataire a ses propres tables de routage et nécessite des passerelles par défaut différentes.

Les processus peuvent lier une socket au périphérique VRF. Les paquets passant par la socket liée utilisent la table de routage associée au périphérique VRF. Une caractéristique importante de la VRF est qu'elle n'affecte que le trafic de la couche 3 du modèle OSI et des couches supérieures, de sorte que les outils L2, tels que LLDP, ne sont pas concernés. Cela permet à des règles IP plus prioritaires, telles que le routage basé sur une politique, d'avoir la priorité sur les règles du dispositif VRF qui dirigent un trafic spécifique.

22.3.1.1. Avantages des réseaux secondaires pour les opérateurs de télécommunications
Copier lien

Dans les cas d'utilisation des télécommunications, chaque CNF peut potentiellement être connecté à plusieurs réseaux différents partageant le même espace d'adressage. Ces réseaux secondaires peuvent potentiellement entrer en conflit avec le CIDR du réseau principal du cluster. Grâce au plugin VRF de CNI, les fonctions réseau peuvent être connectées à l'infrastructure de différents clients en utilisant la même adresse IP, ce qui permet d'isoler les différents clients. Les adresses IP sont superposées à l'espace IP d'OpenShift Container Platform. Le plugin CNI VRF réduit également le nombre de permissions nécessaires à CNF et augmente la visibilité des topologies des réseaux secondaires.

22.4. Configuration de la politique multi-réseaux
Copier lien

En tant qu'administrateur de cluster, vous pouvez configurer le multi-réseau pour les réseaux supplémentaires. Vous pouvez spécifier une politique multi-réseaux pour les réseaux supplémentaires SR-IOV et macvlan. Les réseaux supplémentaires macvlan sont entièrement pris en charge. Les autres types de réseaux supplémentaires, tels que ipvlan, ne sont pas pris en charge.

Important

La prise en charge de la configuration de politiques multi-réseaux pour les réseaux supplémentaires SR-IOV est une fonctionnalité de l'aperçu technologique et n'est prise en charge qu'avec les cartes d'interface réseau (NIC) du noyau. SR-IOV n'est pas pris en charge pour les applications du kit de développement du plan de données (DPDK).

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Note

Les politiques de réseau configurées sont ignorées dans les réseaux IPv6.

22.4.1. Différences entre la politique multi-réseaux et la politique des réseaux
Copier lien

Bien que l'API MultiNetworkPolicy mette en œuvre l'API NetworkPolicy, il existe plusieurs différences importantes :

Vous devez utiliser l'API MultiNetworkPolicy:

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy

Copy to Clipboard

Toggle word wrap

Vous devez utiliser le nom de la ressource multi-networkpolicy lorsque vous utilisez le CLI pour interagir avec les politiques multi-réseaux. Par exemple, vous pouvez afficher un objet de politique multi-réseaux avec la commande oc get multi-networkpolicy <name> où <name> est le nom d'une politique multi-réseaux.
Vous devez spécifier une annotation avec le nom de la définition de l'attachement au réseau qui définit le réseau supplémentaire macvlan ou SR-IOV :
```
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
```
```
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
```
Copy to Clipboard Toggle word wrap
où :
<network_name>
Spécifie le nom d'une définition de pièce jointe au réseau.

22.4.2. Activation de la politique multi-réseaux pour le cluster
Copier lien

En tant qu'administrateur de cluster, vous pouvez activer la prise en charge des politiques multi-réseaux sur votre cluster.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous au cluster avec un utilisateur disposant des privilèges cluster-admin.

Procédure

Créez le fichier multinetwork-enable-patch.yaml avec le YAML suivant :

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  useMultiNetworkPolicy: true

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  useMultiNetworkPolicy: true

Copy to Clipboard

Toggle word wrap

Configurer le cluster pour activer la politique multi-réseaux :

oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml

$ oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

network.operator.openshift.io/cluster patched

network.operator.openshift.io/cluster patched

Copy to Clipboard

Toggle word wrap

22.4.3. Travailler avec une politique multi-réseaux
Copier lien

En tant qu'administrateur de cluster, vous pouvez créer, modifier, afficher et supprimer des politiques multi-réseaux.

22.4.3.1. Conditions préalables
Copier lien

Vous avez activé la prise en charge des stratégies multi-réseaux pour votre cluster.

22.4.3.2. Création d'une politique multi-réseaux à l'aide de l'interface CLI
Copier lien

Pour définir des règles granulaires décrivant le trafic réseau entrant ou sortant autorisé pour les espaces de noms de votre cluster, vous pouvez créer une stratégie multi-réseaux.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
Vous travaillez dans l'espace de noms auquel s'applique la politique multi-réseaux.

Procédure

Créer une règle de politique :

Créer un fichier <policy_name>.yaml:
```
touch <policy_name>.yaml
```
```
$ touch <policy_name>.yaml
```
Copy to Clipboard Toggle word wrap
où :
<policy_name>
Spécifie le nom du fichier de stratégie multi-réseaux.

Définissez une politique multi-réseaux dans le fichier que vous venez de créer, comme dans les exemples suivants :

Refuser l'entrée de tous les pods dans tous les espaces de noms

Il s'agit d'une politique fondamentale, qui bloque tout réseau inter-pods autre que le trafic inter-pods autorisé par la configuration d'autres politiques de réseau.

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: deny-by-default
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
  ingress: []

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: deny-by-default
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
  ingress: []

Copy to Clipboard

Toggle word wrap

où :

<network_name>: Spécifie le nom d'une définition de pièce jointe au réseau.

Autoriser l'entrée de tous les pods dans le même espace de noms

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: allow-same-namespace
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: allow-same-namespace
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}

Copy to Clipboard

Toggle word wrap

où :

<network_name>: Spécifie le nom d'une définition de pièce jointe au réseau.

Autoriser le trafic entrant vers un pod à partir d'un espace de noms particulier

Cette politique autorise le trafic vers les pods étiquetés pod-a à partir des pods fonctionnant sur namespace-y.

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: allow-traffic-pod
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
   matchLabels:
      pod: pod-a
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
           kubernetes.io/metadata.name: namespace-y

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: allow-traffic-pod
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
   matchLabels:
      pod: pod-a
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
           kubernetes.io/metadata.name: namespace-y

Copy to Clipboard

Toggle word wrap

où :

<network_name>: Spécifie le nom d'une définition de pièce jointe au réseau.

Restreindre le trafic vers un service

Cette politique, lorsqu'elle est appliquée, garantit que tous les pods portant les étiquettes app=bookstore et role=api ne sont accessibles qu'aux pods portant l'étiquette app=bookstore. Dans cet exemple, l'application pourrait être un serveur d'API REST, marqué par les étiquettes app=bookstore et role=api.

Cet exemple traite des cas d'utilisation suivants :

Restreindre le trafic d'un service aux seuls autres microservices qui doivent l'utiliser.

Restreindre les connexions à une base de données pour n'autoriser que l'application qui l'utilise.

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: api-allow
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
    matchLabels:
      app: bookstore
      role: api
  ingress:
  - from:
      - podSelector:
          matchLabels:
            app: bookstore

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: api-allow
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
    matchLabels:
      app: bookstore
      role: api
  ingress:
  - from:
      - podSelector:
          matchLabels:
            app: bookstore

Copy to Clipboard

Toggle word wrap

où :

<network_name>: Spécifie le nom d'une définition de pièce jointe au réseau.

Pour créer l'objet de politique multiréseau, entrez la commande suivante :
```
oc apply -f <policy_name>.yaml -n <namespace>
```
```
oc apply -f <policy_name>.yaml -n <namespace>
```
Copy to Clipboard Toggle word wrap
où :
<policy_name>
Spécifie le nom du fichier de stratégie multi-réseaux.
<namespace>
Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.
Exemple de sortie
```
multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created
```
```
multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created
```
Copy to Clipboard Toggle word wrap

Note

Si vous vous connectez à la console web avec les privilèges cluster-admin, vous avez le choix de créer une politique de réseau dans n'importe quel espace de noms du cluster directement dans YAML ou à partir d'un formulaire dans la console web.

22.4.3.3. Modification d'une politique multi-réseaux
Copier lien

Vous pouvez modifier une politique multi-réseaux dans un espace de noms.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
Vous travaillez dans l'espace de noms où la politique multi-réseaux existe.

Procédure

Facultatif : Pour répertorier les objets de stratégie multi-réseaux d'un espace de noms, entrez la commande suivante :
```
oc get multi-networkpolicy
```
```
$ oc get multi-networkpolicy
```
Copy to Clipboard Toggle word wrap
où :
<namespace>
Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.
Modifier l'objet de politique multi-réseaux.
- Si vous avez enregistré la définition de la stratégie multi-réseaux dans un fichier, éditez le fichier et apportez les modifications nécessaires, puis entrez la commande suivante.
  $ oc apply -n <namespace> -f <policy_file>.yaml
  Copy to Clipboard Toggle word wrap
  où :
  <namespace>
  Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.
  <policy_file>
  Spécifie le nom du fichier contenant la politique de réseau.
- Si vous devez mettre à jour l'objet de stratégie multi-réseau directement, entrez la commande suivante :
  oc edit multi-networkpolicy <nom_de_la_politique> -n <espace_de_noms>
  Copy to Clipboard Toggle word wrap
  où :
  <policy_name>
  Spécifie le nom de la politique de réseau.
  <namespace>
  Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.
Confirmez la mise à jour de l'objet de stratégie multi-réseaux.
```
oc describe multi-networkpolicy <nom_de_la_politique> -n <espace_de_noms>
```
```
oc describe multi-networkpolicy <nom_de_la_politique> -n <espace_de_noms>
```
Copy to Clipboard Toggle word wrap
où :
<policy_name>
Spécifie le nom de la politique multi-réseaux.
<namespace>
Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.

Note

Si vous vous connectez à la console web avec les privilèges cluster-admin, vous avez le choix entre éditer une politique de réseau dans n'importe quel espace de noms du cluster directement dans YAML ou à partir de la politique dans la console web via le menu Actions.

22.4.3.4. Visualisation des politiques multi-réseaux à l'aide de la CLI
Copier lien

Vous pouvez examiner les politiques multi-réseaux dans un espace de noms.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
Vous travaillez dans l'espace de noms où la politique multi-réseaux existe.

Procédure

Liste des politiques multi-réseaux dans un espace de noms :
- Pour afficher les objets de stratégie multi-réseaux définis dans un espace de noms, entrez la commande suivante :
  $ oc get multi-networkpolicy
  Copy to Clipboard Toggle word wrap
- En outre, il est possible d'examiner une politique multi-réseaux spécifique : Pour examiner une politique multi-réseaux spécifique, entrez la commande suivante :
  oc describe multi-networkpolicy <nom_de_la_politique> -n <espace_de_noms>
  Copy to Clipboard Toggle word wrap
  où :
  <policy_name>
  Spécifie le nom de la politique multi-réseaux à inspecter.
  <namespace>
  Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.

Note

Si vous vous connectez à la console web avec les privilèges cluster-admin, vous avez le choix d'afficher une politique de réseau dans n'importe quel espace de noms du cluster directement dans YAML ou à partir d'un formulaire dans la console web.

22.4.3.5. Suppression d'une politique multi-réseaux à l'aide de la CLI
Copier lien

Vous pouvez supprimer une politique multi-réseaux dans un espace de noms.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
Vous travaillez dans l'espace de noms où la politique multi-réseaux existe.

Procédure

Pour supprimer un objet de stratégie multi-réseaux, entrez la commande suivante :
```
oc delete multi-networkpolicy <nom_de_la_politique> -n <espace_de_noms>
```
```
oc delete multi-networkpolicy <nom_de_la_politique> -n <espace_de_noms>
```
Copy to Clipboard Toggle word wrap
où :
<policy_name>
Spécifie le nom de la politique multi-réseaux.
<namespace>
Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.
Exemple de sortie
```
multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted
```
```
multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted
```
Copy to Clipboard Toggle word wrap

Note

Si vous vous connectez à la console web avec les privilèges cluster-admin, vous avez le choix entre supprimer une politique de réseau dans n'importe quel espace de noms du cluster directement dans YAML ou à partir de la politique dans la console web via le menu Actions.

22.4.3.6. Création d'une politique de refus de tout par défaut pour les réseaux multiples
Copier lien

Il s'agit d'une politique fondamentale, qui bloque tout réseau inter-pods autre que le trafic réseau autorisé par la configuration d'autres politiques de réseau déployées. Cette procédure applique une politique par défaut : deny-by-default.

Note

Si vous vous connectez avec un utilisateur ayant le rôle cluster-admin, vous pouvez créer une stratégie de réseau dans n'importe quel espace de noms du cluster.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
Vous travaillez dans l'espace de noms auquel s'applique la politique multi-réseaux.

Procédure

Créez le fichier YAML suivant qui définit une politique deny-by-default pour refuser l'entrée de tous les pods dans tous les espaces de noms. Enregistrez le YAML dans le fichier deny-by-default.yaml:
```
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: deny-by-default
  namespace: default 
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name> 
spec:
  podSelector: {} 
  ingress: [] 
```
```
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: deny-by-default
  namespace: default 
```
1
```
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name> 
```
2
```
spec:
  podSelector: {} 
```
3
```
  ingress: [] 
```
4
Copy to Clipboard Toggle word wrap
1
namespace: default déploie cette politique dans l'espace de noms default.
2
podSelector: est vide, cela signifie qu'elle correspond à tous les pods. Par conséquent, la politique s'applique à tous les modules de l'espace de noms par défaut.
3
network_name: spécifie le nom d'une définition de pièce jointe au réseau.
4
Aucune règle ingress n'est spécifiée. Le trafic entrant est donc supprimé pour tous les pods.

Appliquez la politique en entrant la commande suivante :

oc apply -f deny-by-default.yaml

$ oc apply -f deny-by-default.yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created

multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created

Copy to Clipboard

Toggle word wrap

22.4.3.7. Création d'une stratégie multi-réseaux pour autoriser le trafic provenant de clients externes
Copier lien

La politique deny-by-default étant en place, vous pouvez configurer une politique qui autorise le trafic des clients externes vers un pod portant l'étiquette app=web.

Note

Si vous vous connectez avec un utilisateur ayant le rôle cluster-admin, vous pouvez créer une stratégie de réseau dans n'importe quel espace de noms du cluster.

Suivez cette procédure pour configurer une politique qui autorise un service externe à partir de l'Internet public directement ou en utilisant un équilibreur de charge pour accéder au module. Le trafic n'est autorisé que vers un pod portant l'étiquette app=web.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
Vous travaillez dans l'espace de noms auquel s'applique la politique multi-réseaux.

Procédure

Créez une politique qui autorise le trafic provenant de l'Internet public directement ou en utilisant un équilibreur de charge pour accéder au pod. Enregistrez le YAML dans le fichier web-allow-external.yaml:

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: web-allow-external
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  policyTypes:
  - Ingress
  podSelector:
    matchLabels:
      app: web
  ingress:
    - {}

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: web-allow-external
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  policyTypes:
  - Ingress
  podSelector:
    matchLabels:
      app: web
  ingress:
    - {}

Copy to Clipboard

Toggle word wrap

Appliquez la politique en entrant la commande suivante :

oc apply -f web-allow-external.yaml

$ oc apply -f web-allow-external.yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

multinetworkpolicy.k8s.cni.cncf.io/web-allow-external created

multinetworkpolicy.k8s.cni.cncf.io/web-allow-external created

Copy to Clipboard

Toggle word wrap

Cette politique autorise le trafic en provenance de toutes les ressources, y compris le trafic externe, comme l'illustre le diagramme suivant :

22.4.3.8. Création d'une politique multi-réseaux autorisant le trafic vers une application à partir de tous les espaces de noms
Copier lien

Note

Si vous vous connectez avec un utilisateur ayant le rôle cluster-admin, vous pouvez créer une stratégie de réseau dans n'importe quel espace de noms du cluster.

Suivez cette procédure pour configurer une stratégie qui autorise le trafic de tous les pods de tous les espaces de noms vers une application particulière.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
Vous travaillez dans l'espace de noms auquel s'applique la politique multi-réseaux.

Procédure

Créez une politique qui autorise le trafic de tous les pods dans tous les espaces de noms vers une application particulière. Enregistrez le YAML dans le fichier web-allow-all-namespaces.yaml:

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: web-allow-all-namespaces
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
    matchLabels:
      app: web 
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {}

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: web-allow-all-namespaces
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
    matchLabels:
      app: web

1


  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {}

2

Copy to Clipboard

Toggle word wrap

1: Applique la politique uniquement aux pods app:web dans l'espace de noms par défaut.
2: Sélectionne tous les pods dans tous les espaces de noms.

Note

Par défaut, si vous ne précisez pas namespaceSelector, aucun espace de noms n'est sélectionné, ce qui signifie que la stratégie n'autorise que le trafic provenant de l'espace de noms dans lequel la stratégie de réseau est déployée.

Appliquez la politique en entrant la commande suivante :

oc apply -f web-allow-all-namespaces.yaml

$ oc apply -f web-allow-all-namespaces.yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

multinetworkpolicy.k8s.cni.cncf.io/web-allow-all-namespaces created

multinetworkpolicy.k8s.cni.cncf.io/web-allow-all-namespaces created

Copy to Clipboard

Toggle word wrap

Vérification

Démarrez un service web dans l'espace de noms default en entrant la commande suivante :

oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

Copy to Clipboard

Toggle word wrap

Exécutez la commande suivante pour déployer une image alpine dans l'espace de noms secondary et pour démarrer un shell :
```
oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
```
```
$ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
```
Copy to Clipboard Toggle word wrap

Exécutez la commande suivante dans l'interpréteur de commandes et observez que la demande est autorisée :

wget -qO- --timeout=2 http://web.default

# wget -qO- --timeout=2 http://web.default

Copy to Clipboard

Toggle word wrap

Résultats attendus

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Copy to Clipboard

Toggle word wrap

22.4.3.9. Création d'une politique multi-réseaux autorisant le trafic vers une application à partir d'un espace de noms
Copier lien

Note

Si vous vous connectez avec un utilisateur ayant le rôle cluster-admin, vous pouvez créer une stratégie de réseau dans n'importe quel espace de noms du cluster.

Suivez cette procédure pour configurer une politique qui autorise le trafic vers un pod avec l'étiquette app=web à partir d'un espace de noms particulier. Vous pourriez vouloir faire ceci pour :

Restreindre le trafic vers une base de données de production aux seuls espaces de noms dans lesquels des charges de travail de production sont déployées.
Permet aux outils de surveillance déployés dans un espace de noms particulier de récupérer les mesures de l'espace de noms actuel.

Conditions préalables

Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
Vous travaillez dans l'espace de noms auquel s'applique la politique multi-réseaux.

Procédure

Créez une politique qui autorise le trafic de tous les pods dans un espace de noms particulier avec un label purpose=production. Sauvegardez le YAML dans le fichier web-allow-prod.yaml:

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: web-allow-prod
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
    matchLabels:
      app: web 
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: production

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: web-allow-prod
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
    matchLabels:
      app: web

1


  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: production

2

Copy to Clipboard

Toggle word wrap

1: Applique la politique uniquement aux pods app:web dans l'espace de noms par défaut.
2: Restreint le trafic aux seuls pods des espaces de noms portant l'étiquette purpose=production.

Appliquez la politique en entrant la commande suivante :
```
oc apply -f web-allow-prod.yaml
```
```
$ oc apply -f web-allow-prod.yaml
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
multinetworkpolicy.k8s.cni.cncf.io/web-allow-prod created
```
```
multinetworkpolicy.k8s.cni.cncf.io/web-allow-prod created
```
Copy to Clipboard Toggle word wrap

Vérification

Démarrez un service web dans l'espace de noms default en entrant la commande suivante :

oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

Copy to Clipboard

Toggle word wrap

Exécutez la commande suivante pour créer l'espace de noms prod:
```
oc create namespace prod
```
```
$ oc create namespace prod
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour étiqueter l'espace de noms prod:
```
oc label namespace/prod purpose=production
```
```
$ oc label namespace/prod purpose=production
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour créer l'espace de noms dev:
```
oc create namespace dev
```
```
$ oc create namespace dev
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour étiqueter l'espace de noms dev:
```
oc label namespace/dev purpose=testing
```
```
$ oc label namespace/dev purpose=testing
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour déployer une image alpine dans l'espace de noms dev et pour démarrer un shell :
```
oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
```
```
$ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante dans l'interpréteur de commandes et observez que la demande est bloquée :
```
wget -qO- --timeout=2 http://web.default
```
```
# wget -qO- --timeout=2 http://web.default
```
Copy to Clipboard Toggle word wrap
Résultats attendus
```
wget: download timed out
```
```
wget: download timed out
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour déployer une image alpine dans l'espace de noms prod et démarrer un shell :
```
oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
```
```
$ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
```
Copy to Clipboard Toggle word wrap

Exécutez la commande suivante dans l'interpréteur de commandes et observez que la demande est autorisée :

wget -qO- --timeout=2 http://web.default

# wget -qO- --timeout=2 http://web.default

Copy to Clipboard

Toggle word wrap

Résultats attendus

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Copy to Clipboard

Toggle word wrap

22.5. Attacher un pod à un réseau supplémentaire
Copier lien

En tant qu'utilisateur du cluster, vous pouvez attacher un pod à un réseau supplémentaire.

22.5.1. Ajouter un pod à un réseau supplémentaire
Copier lien

Vous pouvez ajouter un module à un réseau supplémentaire. Le pod continue à envoyer le trafic réseau normal lié au cluster sur le réseau par défaut.

Lorsqu'un module est créé, des réseaux supplémentaires lui sont rattachés. Toutefois, si un module existe déjà, il n'est pas possible d'y attacher des réseaux supplémentaires.

Le pod doit se trouver dans le même espace de noms que le réseau supplémentaire.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous au cluster.

Procédure

Ajouter une annotation à l'objet Pod. Un seul des formats d'annotation suivants peut être utilisé :
1. Pour attacher un réseau supplémentaire sans aucune personnalisation, ajoutez une annotation avec le format suivant. Remplacez <network> par le nom du réseau supplémentaire à associer au pod :
  metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]
  1
  Copy to Clipboard Toggle word wrap
  1
  Pour spécifier plus d'un réseau supplémentaire, séparez chaque réseau par une virgule. N'incluez pas d'espace entre les virgules. Si vous spécifiez plusieurs fois le même réseau supplémentaire, plusieurs interfaces réseau seront attachées à ce pod.
2. Pour joindre un réseau supplémentaire avec des personnalisations, ajoutez une annotation avec le format suivant :
  metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>",
  1
  "namespace": "<namespace>",
  2
  "default-route": ["<default-route>"]
  3
  } ]
  Copy to Clipboard Toggle word wrap
  1
  Indiquer le nom du réseau supplémentaire défini par un objet NetworkAttachmentDefinition.
  2
  Spécifier l'espace de noms dans lequel l'objet NetworkAttachmentDefinition est défini.
  3
  Facultatif : Spécifiez un remplacement de l'itinéraire par défaut, tel que 192.168.17.1.
Pour créer le module, entrez la commande suivante. Remplacez <name> par le nom du module.
```
oc create -f <name>.yaml
```
```
$ oc create -f <name>.yaml
```
Copy to Clipboard Toggle word wrap

Facultatif : Pour confirmer que l'annotation existe dans le CR Pod, entrez la commande suivante, en remplaçant <name> par le nom du module.

oc get pod <name> -o yaml

$ oc get pod <name> -o yaml

Copy to Clipboard

Toggle word wrap

Dans l'exemple suivant, le pod example-pod est rattaché au réseau supplémentaire net1:

oc get pod example-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-bridge
    k8s.v1.cni.cncf.io/networks-status: |-
      [{
          "name": "openshift-sdn",
          "interface": "eth0",
          "ips": [
              "10.128.2.14"
          ],
          "default": true,
          "dns": {}
      },{
          "name": "macvlan-bridge",
          "interface": "net1",
          "ips": [
              "20.2.2.100"
          ],
          "mac": "22:2f:60:a5:f8:00",
          "dns": {}
      }]
  name: example-pod
  namespace: default
spec:
  ...
status:
  ...

$ oc get pod example-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-bridge
    k8s.v1.cni.cncf.io/networks-status: |-

1


      [{
          "name": "openshift-sdn",
          "interface": "eth0",
          "ips": [
              "10.128.2.14"
          ],
          "default": true,
          "dns": {}
      },{
          "name": "macvlan-bridge",
          "interface": "net1",
          "ips": [
              "20.2.2.100"
          ],
          "mac": "22:2f:60:a5:f8:00",
          "dns": {}
      }]
  name: example-pod
  namespace: default
spec:
  ...
status:
  ...

Copy to Clipboard

Toggle word wrap

1: Le paramètre k8s.v1.cni.cncf.io/networks-status est un tableau JSON d'objets. Chaque objet décrit l'état d'un réseau supplémentaire attaché au pod. La valeur de l'annotation est stockée sous forme de texte brut.

22.5.1.1. Spécification des options d'adressage et de routage spécifiques au pod
Copier lien

Lorsque vous attachez un module à un réseau supplémentaire, vous pouvez vouloir spécifier d'autres propriétés de ce réseau dans un module particulier. Cela vous permet de modifier certains aspects du routage, ainsi que de spécifier des adresses IP et des adresses MAC statiques. Pour ce faire, vous pouvez utiliser les annotations au format JSON.

Conditions préalables

Le pod doit se trouver dans le même espace de noms que le réseau supplémentaire.
Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster.

Procédure

Pour ajouter un pod à un réseau supplémentaire tout en spécifiant des options d'adressage et/ou de routage, procédez comme suit :

Modifiez la définition de la ressource Pod. Si vous modifiez une ressource Pod existante, exécutez la commande suivante pour modifier sa définition dans l'éditeur par défaut. Remplacez <name> par le nom de la ressource Pod à modifier.
```
oc edit pod <name> $ oc edit pod <name>
```
```
oc edit pod <name> $ oc edit pod <name>
```
Copy to Clipboard Toggle word wrap
Dans la définition de la ressource Pod, ajoutez le paramètre k8s.v1.cni.cncf.io/networks au mappage du pod metadata. Le paramètre k8s.v1.cni.cncf.io/networks accepte une chaîne JSON d'une liste d'objets référençant le nom des ressources personnalisées (CR) NetworkAttachmentDefinition en plus de spécifier des propriétés supplémentaires.
```
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]' 
```
```
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]' 
```
1
Copy to Clipboard Toggle word wrap
1
Remplacez <network> par un objet JSON comme indiqué dans les exemples suivants. Les guillemets simples sont obligatoires.

Dans l'exemple suivant, l'annotation spécifie l'attachement réseau qui aura la route par défaut, en utilisant le paramètre default-route.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: '
    {
      "name": "net1"
    },
    {
      "name": "net2", 
      "default-route": ["192.0.2.1"] 
    }'
spec:
  containers:
  - name: example-pod
    command: ["/bin/bash", "-c", "sleep 2000000000000"]
    image: centos/tools

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: '
    {
      "name": "net1"
    },
    {
      "name": "net2",

1


      "default-route": ["192.0.2.1"]

2


    }'
spec:
  containers:
  - name: example-pod
    command: ["/bin/bash", "-c", "sleep 2000000000000"]
    image: centos/tools

Copy to Clipboard

Toggle word wrap

1: La clé name est le nom du réseau supplémentaire à associer au pod.
2: La clé default-route spécifie la valeur d'une passerelle sur laquelle le trafic doit être acheminé si aucune autre entrée de routage n'est présente dans la table de routage. Si plus d'une clé default-route est spécifiée, le pod ne sera pas activé.

La route par défaut permet d'acheminer vers la passerelle tout le trafic qui n'est pas spécifié dans d'autres routes.

Important

La définition de la route par défaut sur une interface autre que l'interface réseau par défaut pour OpenShift Container Platform peut faire en sorte que le trafic prévu pour le trafic pod-to-pod soit acheminé sur une autre interface.

Pour vérifier les propriétés de routage d'un pod, la commande oc peut être utilisée pour exécuter la commande ip à l'intérieur d'un pod.

oc exec -it <nom_du_pod> -- ip route

oc exec -it <nom_du_pod> -- ip route

Copy to Clipboard

Toggle word wrap

Note

Vous pouvez également consulter le site k8s.v1.cni.cncf.io/networks-status du pod pour savoir quel réseau supplémentaire s'est vu attribuer la route par défaut, grâce à la présence de la clé default-route dans la liste d'objets au format JSON.

Pour définir une adresse IP statique ou une adresse MAC pour un pod, vous pouvez utiliser les annotations au format JSON. Pour ce faire, vous devez créer des réseaux qui autorisent spécifiquement cette fonctionnalité. Ceci peut être spécifié dans un rawCNIConfig pour le CNO.

Modifiez le CR CNO en exécutant la commande suivante :
```
oc edit networks.operator.openshift.io cluster
```
```
$ oc edit networks.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap

Le fichier YAML suivant décrit les paramètres de configuration du CNO :

Configuration YAML de l'opérateur de réseau de cluster

name: <name> 
namespace: <namespace> 
rawCNIConfig: '{ 
  ...
}'
type: Raw

name: <name>

1


namespace: <namespace>

2


rawCNIConfig: '{

3


  ...
}'
type: Raw

Copy to Clipboard

Toggle word wrap

1: Indiquez un nom pour la pièce jointe réseau supplémentaire que vous créez. Le nom doit être unique au sein de l'adresse namespace.
2: Indiquez l'espace de noms dans lequel créer la pièce jointe au réseau. Si vous ne spécifiez pas de valeur, l'espace de noms default est utilisé.
3: Spécifiez la configuration du plugin CNI au format JSON, qui est basé sur le modèle suivant.

L'objet suivant décrit les paramètres de configuration pour l'utilisation d'une adresse MAC statique et d'une adresse IP à l'aide du plugin CNI macvlan :

macvlan Objet de configuration JSON du plugin CNI utilisant une adresse IP et MAC statique

{
  "cniVersion": "0.3.1",
  "name": "<name>", 
  "plugins": [{ 
      "type": "macvlan",
      "capabilities": { "ips": true }, 
      "master": "eth0", 
      "mode": "bridge",
      "ipam": {
        "type": "static"
      }
    }, {
      "capabilities": { "mac": true }, 
      "type": "tuning"
    }]
}

{
  "cniVersion": "0.3.1",
  "name": "<name>",

1


  "plugins": [{

2


      "type": "macvlan",
      "capabilities": { "ips": true },

3


      "master": "eth0",

4


      "mode": "bridge",
      "ipam": {
        "type": "static"
      }
    }, {
      "capabilities": { "mac": true },

5


      "type": "tuning"
    }]
}

Copy to Clipboard

Toggle word wrap

1: Spécifie le nom de la pièce jointe réseau supplémentaire à créer. Le nom doit être unique au sein de l'adresse namespace.
2: Spécifie un tableau de configurations de plugins CNI. Le premier objet spécifie une configuration de plugin macvlan et le second objet spécifie une configuration de plugin tuning.
3: Spécifie qu'une demande est faite pour activer la fonctionnalité d'adresse IP statique des capacités de configuration d'exécution du plugin CNI.
4: Spécifie l'interface utilisée par le plugin macvlan.
5: Spécifie qu'une demande est faite pour activer la fonctionnalité d'adresse MAC statique d'un plugin CNI.

L'attachement réseau ci-dessus peut être référencé dans une annotation au format JSON, avec des clés permettant de spécifier l'adresse IP statique et l'adresse MAC qui seront attribuées à un pod donné.

Modifier le pod avec :

oc edit pod <name> $ oc edit pod <name>

oc edit pod <name> $ oc edit pod <name>

Copy to Clipboard

Toggle word wrap

macvlan Objet de configuration JSON du plugin CNI utilisant une adresse IP et MAC statique

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
      {
        "name": "<name>", 
        "ips": [ "192.0.2.205/24" ], 
        "mac": "CA:FE:C0:FF:EE:00" 
      }
    ]'

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
      {
        "name": "<name>",

1


        "ips": [ "192.0.2.205/24" ],

2


        "mac": "CA:FE:C0:FF:EE:00"

3


      }
    ]'

Copy to Clipboard

Toggle word wrap

1: Utilisez le site <name> comme indiqué lors de la création du site rawCNIConfig ci-dessus.
2: Fournir une adresse IP, y compris le masque de sous-réseau.
3: Indiquer l'adresse MAC.

Note

Les adresses IP statiques et les adresses MAC ne doivent pas nécessairement être utilisées en même temps ; vous pouvez les utiliser séparément ou ensemble.

Pour vérifier l'adresse IP et les propriétés MAC d'un module avec des réseaux supplémentaires, utilisez la commande oc pour exécuter la commande ip dans un module.

oc exec -it <nom_du_pod> -- ip a

oc exec -it <nom_du_pod> -- ip a

Copy to Clipboard

Toggle word wrap

22.6. Retrait d'un pod d'un réseau supplémentaire
Copier lien

En tant qu'utilisateur du cluster, vous pouvez retirer un pod d'un réseau supplémentaire.

22.6.1. Retrait d'un pod d'un réseau supplémentaire
Copier lien

Vous ne pouvez retirer un pod d'un réseau supplémentaire qu'en supprimant le pod.

Conditions préalables

Un réseau supplémentaire est rattaché au pod.
Installez le CLI OpenShift (oc).
Connectez-vous au cluster.

Procédure

Pour supprimer le module, entrez la commande suivante :
```
oc delete pod <name> -n <namespace> $ oc delete pod <name> -n <namespace>
```
```
oc delete pod <name> -n <namespace> $ oc delete pod <name> -n <namespace>
```
Copy to Clipboard Toggle word wrap
- <name> est le nom du module.
- <namespace> est l'espace de noms qui contient le pod.

22.7. Modification d'un réseau supplémentaire
Copier lien

En tant qu'administrateur de cluster, vous pouvez modifier la configuration d'un réseau supplémentaire existant.

22.7.1. Modification d'une définition supplémentaire de pièce jointe au réseau
Copier lien

En tant qu'administrateur de cluster, vous pouvez apporter des modifications à un réseau supplémentaire existant. Les pods existants attachés au réseau supplémentaire ne seront pas mis à jour.

Conditions préalables

Vous avez configuré un réseau supplémentaire pour votre cluster.
Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Pour modifier un réseau supplémentaire pour votre cluster, suivez les étapes suivantes :

Exécutez la commande suivante pour modifier le CR de l'opérateur de réseau de cluster (CNO) dans votre éditeur de texte par défaut :
```
oc edit networks.operator.openshift.io cluster
```
```
$ oc edit networks.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap
Dans la collection additionalNetworks, mettez à jour le réseau supplémentaire avec vos modifications.
Enregistrez vos modifications et quittez l'éditeur de texte pour valider vos modifications.

Optionnel : Confirmez que le CNO a mis à jour l'objet NetworkAttachmentDefinition en exécutant la commande suivante. Remplacez <network-name> par le nom du réseau supplémentaire à afficher. Il peut y avoir un délai avant que le CNO ne mette à jour l'objet NetworkAttachmentDefinition pour refléter vos changements.

oc get network-attachment-definitions <networkame> -o yaml

oc get network-attachment-definitions <networkame> -o yaml

Copy to Clipboard

Toggle word wrap

Par exemple, la sortie de console suivante affiche un objet NetworkAttachmentDefinition nommé net1:

oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'
{ "cniVersion": "0.3.1", "type": "macvlan",
"master": "ens5",
"mode": "bridge",
"ipam":       {"type":"static","routes":[{"dst":"0.0.0.0/0","gw":"10.128.2.1"}],"addresses":[{"address":"10.128.2.100/23","gateway":"10.128.2.1"}],"dns":{"nameservers":["172.30.0.10"],"domain":"us-west-2.compute.internal","search":["us-west-2.compute.internal"]}} }

$ oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'
{ "cniVersion": "0.3.1", "type": "macvlan",
"master": "ens5",
"mode": "bridge",
"ipam":       {"type":"static","routes":[{"dst":"0.0.0.0/0","gw":"10.128.2.1"}],"addresses":[{"address":"10.128.2.100/23","gateway":"10.128.2.1"}],"dns":{"nameservers":["172.30.0.10"],"domain":"us-west-2.compute.internal","search":["us-west-2.compute.internal"]}} }

Copy to Clipboard

Toggle word wrap

22.8. Suppression d'un réseau supplémentaire
Copier lien

En tant qu'administrateur de cluster, vous pouvez supprimer une pièce jointe réseau supplémentaire.

22.8.1. Suppression d'une définition supplémentaire de pièce jointe au réseau
Copier lien

En tant qu'administrateur de cluster, vous pouvez supprimer un réseau supplémentaire de votre cluster OpenShift Container Platform. Le réseau supplémentaire n'est pas supprimé des pods auxquels il est attaché.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Pour supprimer un réseau supplémentaire de votre cluster, procédez comme suit :

Modifiez le Cluster Network Operator (CNO) dans votre éditeur de texte par défaut en exécutant la commande suivante :
```
oc edit networks.operator.openshift.io cluster
```
```
$ oc edit networks.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap
Modifiez la CR en supprimant la configuration de la collection additionalNetworks pour la définition de l'attachement réseau que vous supprimez.
```
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks: [] 
```
```
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks: [] 
```
1
Copy to Clipboard Toggle word wrap
1
Si vous supprimez le mappage de configuration pour la seule définition de pièce jointe réseau supplémentaire dans la collection additionalNetworks, vous devez spécifier une collection vide.
Enregistrez vos modifications et quittez l'éditeur de texte pour valider vos modifications.
Facultatif : Confirmez que le réseau supplémentaire CR a été supprimé en exécutant la commande suivante :
```
oc get network-attachment-definition --all-namespaces
```
```
$ oc get network-attachment-definition --all-namespaces
```
Copy to Clipboard Toggle word wrap

22.9. Affectation d'un réseau secondaire à un VRF
Copier lien

22.9.1. Affectation d'un réseau secondaire à un VRF
Copier lien

En tant qu'administrateur de cluster, vous pouvez configurer un réseau supplémentaire pour votre domaine VRF en utilisant le plugin CNI VRF. Le réseau virtuel créé par ce plugin est associé à une interface physique que vous spécifiez.

Note

Les applications qui utilisent les VRF doivent se lier à un périphérique spécifique. L'usage courant est d'utiliser l'option SO_BINDTODEVICE pour une socket. SO_BINDTODEVICE lie la socket à un périphérique spécifié dans le nom de l'interface passée, par exemple, eth1. Pour utiliser SO_BINDTODEVICE, l'application doit avoir les capacités de CAP_NET_RAW.

L'utilisation d'une VRF via la commande ip vrf exec n'est pas prise en charge dans les pods OpenShift Container Platform. Pour utiliser la VRF, liez les applications directement à l'interface VRF.

22.9.1.1. Création d'un attachement réseau supplémentaire avec le plugin CNI VRF
Copier lien

L'opérateur de réseau de cluster (CNO) gère les définitions de réseaux supplémentaires. Lorsque vous spécifiez un réseau supplémentaire à créer, le CNO crée automatiquement la ressource personnalisée (CR) NetworkAttachmentDefinition.

Note

Ne modifiez pas les CR NetworkAttachmentDefinition gérés par l'opérateur du réseau en grappe. Cela risquerait de perturber le trafic sur votre réseau supplémentaire.

Pour créer un attachement réseau supplémentaire avec le plugin CNI VRF, suivez la procédure suivante.

Conditions préalables

Installez le CLI (oc) de OpenShift Container Platform.
Connectez-vous au cluster OpenShift en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créez la ressource personnalisée (CR) Network pour l'attachement au réseau supplémentaire et insérez la configuration rawCNIConfig pour le réseau supplémentaire, comme dans l'exemple de CR suivant. Enregistrez le YAML dans le fichier additional-network-attachment.yaml.

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
  spec:
  additionalNetworks:
  - name: test-network-1
    namespace: additional-network-1
    type: Raw
    rawCNIConfig: '{
      "cniVersion": "0.3.1",
      "name": "macvlan-vrf",
      "plugins": [  
      {
        "type": "macvlan",  
        "master": "eth1",
        "ipam": {
            "type": "static",
            "addresses": [
            {
                "address": "191.168.1.23/24"
            }
            ]
        }
      },
      {
        "type": "vrf",
        "vrfname": "example-vrf-name",  
        "table": 1001   
      }]
    }'

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
  spec:
  additionalNetworks:
  - name: test-network-1
    namespace: additional-network-1
    type: Raw
    rawCNIConfig: '{
      "cniVersion": "0.3.1",
      "name": "macvlan-vrf",
      "plugins": [

1


      {
        "type": "macvlan",

2


        "master": "eth1",
        "ipam": {
            "type": "static",
            "addresses": [
            {
                "address": "191.168.1.23/24"
            }
            ]
        }
      },
      {
        "type": "vrf",
        "vrfname": "example-vrf-name",

3


        "table": 1001

4


      }]
    }'

Copy to Clipboard

Toggle word wrap

1: plugins doit être une liste. Le premier élément de la liste doit être le réseau secondaire qui sous-tend le réseau VRF. Le deuxième élément de la liste est la configuration du plugin VRF.
2: type doit être réglé sur vrf.
3: vrfname est le nom du VRF auquel l'interface est assignée. S'il n'existe pas dans le pod, il est créé.
4: Facultatif. table est l'ID de la table de routage. Par défaut, le paramètre tableid est utilisé. S'il n'est pas spécifié, le CNI attribue un ID de table de routage libre au VRF.

Note

VRF ne fonctionne correctement que si la ressource est de type netdevice.

Créer la ressource Network:

oc create -f additional-network-attachment.yaml

$ oc create -f additional-network-attachment.yaml

Copy to Clipboard

Toggle word wrap

Confirmez que le CNO a créé le CR NetworkAttachmentDefinition en exécutant la commande suivante. Remplacez <namespace> par l'espace de noms que vous avez spécifié lors de la configuration de l'attachement au réseau, par exemple additional-network-1.
```
oc get network-attachment-definitions -n <namespace>
```
```
oc get network-attachment-definitions -n <namespace>
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
NAME                       AGE
additional-network-1       14m
```
```
NAME                       AGE
additional-network-1       14m
```
Copy to Clipboard Toggle word wrap
Note
Il peut y avoir un délai avant que le CNO ne crée le CR.

Vérification de la réussite de l'attachement au réseau VRF supplémentaire

Pour vérifier que le VRF CNI est correctement configuré et que l'attachement réseau supplémentaire est attaché, procédez comme suit :

Créez un réseau qui utilise le VRF CNI.
Attribuer le réseau à un pod.
Vérifiez que l'attachement réseau du pod est connecté au réseau supplémentaire VRF. Connectez-vous à distance au pod et exécutez la commande suivante :
```
ip vrf show
```
```
$ ip vrf show
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
Name              Table
-----------------------
red                 10
```
```
Name              Table
-----------------------
red                 10
```
Copy to Clipboard Toggle word wrap

Confirmez que l'interface VRF est maître de l'interface secondaire :

ip link

$ ip link

Copy to Clipboard

Toggle word wrap

Exemple de sortie

5 : net1 : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode

5 : net1 : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode

Copy to Clipboard

Toggle word wrap

Chapitre 23. Réseaux matériels
Copier lien

23.1. À propos des réseaux matériels de virtualisation des E/S à racine unique (SR-IOV)
Copier lien

La spécification SR-IOV (Single Root I/O Virtualization) est une norme pour un type d'affectation de périphérique PCI qui peut partager un périphérique unique avec plusieurs pods.

SR-IOV peut segmenter un dispositif de réseau conforme, reconnu sur le nœud hôte comme une fonction physique (PF), en plusieurs fonctions virtuelles (VF). La VF est utilisée comme n'importe quel autre périphérique réseau. Le pilote de périphérique réseau SR-IOV pour le périphérique détermine comment la VF est exposée dans le conteneur :

netdevice pilote : Un périphérique réseau normal du noyau dans le site netns du conteneur
vfio-pci conducteur : Un dispositif de caractère monté dans le conteneur

Vous pouvez utiliser les périphériques réseau SR-IOV avec des réseaux supplémentaires sur votre cluster OpenShift Container Platform installé sur une infrastructure bare metal ou Red Hat OpenStack Platform (RHOSP) pour les applications qui nécessitent une bande passante élevée ou une faible latence.

Vous pouvez configurer des politiques multi-réseaux pour les réseaux SR-IOV. Il s'agit d'un aperçu technologique et les réseaux supplémentaires SR-IOV ne sont pris en charge qu'avec les cartes réseau du noyau. Ils ne sont pas pris en charge pour les applications du kit de développement du plan de données (DPDK).

Note

La création de politiques multi-réseaux sur les réseaux SR-IOV risque de ne pas offrir les mêmes performances aux applications que les réseaux SR-IOV sur lesquels aucune politique multi-réseaux n'est configurée.

Important

Les politiques multi-réseaux pour le réseau SR-IOV sont une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas leur utilisation en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Vous pouvez activer le SR-IOV sur un nœud à l'aide de la commande suivante :

oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"

$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"

Copy to Clipboard

Toggle word wrap

23.1.1. Composants qui gèrent les périphériques de réseau SR-IOV
Copier lien

L'opérateur de réseau SR-IOV crée et gère les composants de la pile SR-IOV. Il remplit les fonctions suivantes :

Orchestrer la découverte et la gestion des périphériques de réseau SR-IOV
Génère NetworkAttachmentDefinition des ressources personnalisées pour l'interface de réseau de conteneurs SR-IOV (CNI)
Crée et met à jour la configuration du plugin de l'appareil réseau SR-IOV
Crée des ressources personnalisées spécifiques au nœud SriovNetworkNodeState
Met à jour le champ spec.interfaces dans chaque ressource personnalisée SriovNetworkNodeState

L'opérateur fournit les éléments suivants :

Démon de configuration du réseau SR-IOV: Ensemble de démons déployés sur les nœuds de travail lors du démarrage de l'opérateur de réseau SR-IOV. Le démon est responsable de la découverte et de l'initialisation des périphériques réseau SR-IOV dans le cluster.
Webhook de l'opérateur de réseau SR-IOV: Un webhook de contrôleur d'admission dynamique qui valide la ressource personnalisée de l'opérateur et définit les valeurs par défaut appropriées pour les champs non définis.
SR-IOV Injecteur de ressources réseau: Un webhook de contrôleur d'admission dynamique qui fournit une fonctionnalité pour patcher les spécifications des pods Kubernetes avec des demandes et des limites pour les ressources réseau personnalisées telles que les VF SR-IOV. L'injecteur de ressources réseau SR-IOV ajoute automatiquement le champ resource au premier conteneur d'un pod.
Plugin de périphérique de réseau SR-IOV: Un plugin de périphérique qui découvre, annonce et alloue des ressources de fonction virtuelle (VF) de réseau SR-IOV. Les plugins de périphérique sont utilisés dans Kubernetes pour permettre l'utilisation de ressources limitées, généralement dans des dispositifs physiques. Les plugins de périphérique permettent au planificateur de Kubernetes de connaître la disponibilité des ressources, de sorte que le planificateur peut programmer des pods sur des nœuds disposant de ressources suffisantes.
SR-IOV Plugin CNI: Un plugin CNI qui attache les interfaces VF allouées par le plugin de périphérique réseau SR-IOV directement à un pod.
SR-IOV InfiniBand CNI plugin: Un plugin CNI qui attache les interfaces InfiniBand (IB) VF allouées par le plugin de périphérique réseau SR-IOV directement dans un pod.

Note

L'injecteur de ressources du réseau SR-IOV et le webhook de l'opérateur du réseau SR-IOV sont activés par défaut et peuvent être désactivés en modifiant le site default SriovOperatorConfig CR. Soyez prudent lorsque vous désactivez le webhook du contrôleur d'admission de l'opérateur de réseau SR-IOV. Vous pouvez désactiver le webhook dans des circonstances spécifiques, telles que le dépannage, ou si vous souhaitez utiliser des périphériques non pris en charge.

23.1.1.1. Plates-formes prises en charge
Copier lien

L'opérateur de réseau SR-IOV est pris en charge sur les plates-formes suivantes :

Métal nu
Plate-forme Red Hat OpenStack (RHOSP)

23.1.1.2. Dispositifs pris en charge
Copier lien

OpenShift Container Platform prend en charge les contrôleurs d'interface réseau suivants :

Expand

Tableau 23.1. Contrôleurs d'interface réseau pris en charge
Fabricant	Model	ID du vendeur	ID de l'appareil
Broadcom	BCM57414	14e4	16d7
Broadcom	BCM57508	14e4	1750
Intel	X710	8086	1572
Intel	XL710	8086	1583
Intel	XXV710	8086	158b
Intel	E810-CQDA2	8086	1592
Intel	E810-2CQDA2	8086	1592
Intel	E810-XXVDA2	8086	159b
Intel	E810-XXVDA4	8086	1593
Mellanox	Famille MT27700 [ConnectX-4]	15b3	1013
Mellanox	Famille MT27710 [ConnectX-4 Lx]	15b3	1015
Mellanox	Famille MT27800 [ConnectX-5]	15b3	1017
Mellanox	Famille MT28880 [ConnectX-5 Ex]	15b3	1019
Mellanox	Famille MT28908 [ConnectX-6]	15b3	101b
Mellanox	Famille MT2892 [ConnectX-6 Dx]	15b3	101d
Mellanox	Famille MT2894 [ConnectX-6 Lx]	15b3	101f
Mellanox	MT42822 BlueField-2 en mode NIC ConnectX-6	15b3	a2d6
Pensando ^[1]	DSC-25 carte de services distribués 25G à double port pour pilote ionique	0x1dd8	0x1002
Pensando ^[1]	DSC-100 carte de services distribués 100G à double port pour pilote ionique	0x1dd8	0x1003
Silicom	Famille STS	8086	1591

OpenShift SR-IOV est pris en charge, mais vous devez définir une adresse MAC (media access control) statique, Virtual Function (VF), à l'aide du fichier de configuration CNI SR-IOV lorsque vous utilisez SR-IOV.

Note

Pour obtenir la liste la plus récente des cartes prises en charge et des versions compatibles d'OpenShift Container Platform, consultez la matrice de prise en charge des réseaux matériels SR-IOV (Single Root I/O Virtualization) et PTP d'OpenShift.

23.1.1.3. Découverte automatisée des dispositifs de réseau SR-IOV
Copier lien

L'opérateur de réseau SR-IOV recherche dans votre cluster les périphériques réseau compatibles SR-IOV sur les nœuds de travail. L'opérateur crée et met à jour une ressource personnalisée (CR) SriovNetworkNodeState pour chaque nœud de travailleur qui fournit un périphérique réseau SR-IOV compatible.

Le CR porte le même nom que le nœud de travail. La liste status.interfaces fournit des informations sur les périphériques réseau d'un nœud.

Important

Ne pas modifier un objet SriovNetworkNodeState. L'Opérateur crée et gère ces ressources automatiquement.

23.1.1.3.1. Exemple d'objet SriovNetworkNodeState
Copier lien

Le fichier YAML suivant est un exemple d'objet SriovNetworkNodeState créé par l'opérateur de réseau SR-IOV :

Un objet SriovNetworkNodeState

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodeState
metadata:
  name: node-25 
  namespace: openshift-sriov-network-operator
  ownerReferences:
  - apiVersion: sriovnetwork.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: SriovNetworkNodePolicy
    name: default
spec:
  dpConfigVersion: "39824"
status:
  interfaces: 
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f0
    pciAddress: "0000:18:00.0"
    totalvfs: 8
    vendor: 15b3
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f1
    pciAddress: "0000:18:00.1"
    totalvfs: 8
    vendor: 15b3
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f0
    pciAddress: 0000:81:00.0
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f1
    pciAddress: 0000:81:00.1
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens803f0
    pciAddress: 0000:86:00.0
    totalvfs: 64
    vendor: "8086"
  syncStatus: Succeeded

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodeState
metadata:
  name: node-25

1


  namespace: openshift-sriov-network-operator
  ownerReferences:
  - apiVersion: sriovnetwork.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: SriovNetworkNodePolicy
    name: default
spec:
  dpConfigVersion: "39824"
status:
  interfaces:

2


  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f0
    pciAddress: "0000:18:00.0"
    totalvfs: 8
    vendor: 15b3
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f1
    pciAddress: "0000:18:00.1"
    totalvfs: 8
    vendor: 15b3
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f0
    pciAddress: 0000:81:00.0
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f1
    pciAddress: 0000:81:00.1
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens803f0
    pciAddress: 0000:86:00.0
    totalvfs: 64
    vendor: "8086"
  syncStatus: Succeeded

Copy to Clipboard

Toggle word wrap

1: La valeur du champ name est identique au nom du nœud de travail.
2: La strophe interfaces comprend une liste de tous les dispositifs SR-IOV découverts par l'opérateur sur le nœud de travail.

23.1.1.4. Exemple d'utilisation d'une fonction virtuelle dans un pod
Copier lien

Vous pouvez exécuter une application d'accès direct à la mémoire à distance (RDMA) ou un kit de développement du plan de données (DPDK) dans un pod auquel est attaché un SR-IOV VF.

Cet exemple montre un pod utilisant une fonction virtuelle (VF) en mode RDMA :

Pod qui utilise le mode RDMA

apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-rdma-mlnx
spec:
  containers:
  - name: testpmd
    image: <RDMA_image>
    imagePullPolicy: IfNotPresent
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]
    command: ["sleep", "infinity"]

apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-rdma-mlnx
spec:
  containers:
  - name: testpmd
    image: <RDMA_image>
    imagePullPolicy: IfNotPresent
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]
    command: ["sleep", "infinity"]

Copy to Clipboard

Toggle word wrap

L'exemple suivant montre un pod avec un VF en mode DPDK :

Pod spec qui utilise le mode DPDK

apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-dpdk-net
spec:
  containers:
  - name: testpmd
    image: <DPDK_image>
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
      requests:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-dpdk-net
spec:
  containers:
  - name: testpmd
    image: <DPDK_image>
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
      requests:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Copy to Clipboard

Toggle word wrap

23.1.1.5. Bibliothèque DPDK à utiliser avec les applications de conteneurs
Copier lien

Une bibliothèque optionnelle, app-netutil, fournit plusieurs méthodes API pour collecter des informations réseau sur un pod à partir d'un conteneur s'exécutant dans ce pod.

Cette bibliothèque peut aider à intégrer les fonctions virtuelles SR-IOV (VF) en mode DPDK (Data Plane Development Kit) dans le conteneur. La bibliothèque fournit à la fois une API Golang et une API C.

Actuellement, trois méthodes API sont mises en œuvre :

GetCPUInfo(): Cette fonction détermine quels sont les processeurs disponibles pour le conteneur et renvoie la liste.
GetHugepages(): Cette fonction détermine la quantité de mémoire de page énorme demandée dans la spécification Pod pour chaque conteneur et renvoie les valeurs.
GetInterfaces(): Cette fonction détermine l'ensemble des interfaces du conteneur et renvoie la liste. La valeur de retour comprend le type d'interface et les données spécifiques à chaque interface.

Le dépôt de la bibliothèque comprend un exemple de fichier Docker pour construire une image de conteneur, dpdk-app-centos. L'image de conteneur peut exécuter l'un des exemples d'applications DPDK suivants, en fonction d'une variable d'environnement dans la spécification du pod : l2fwd l3wd testpmd l'image de conteneur fournit un exemple d'intégration de la bibliothèque app-netutil dans l'image de conteneur elle-même. La bibliothèque peut également être intégrée dans un conteneur d'initialisation. Ce dernier peut collecter les données requises et les transmettre à une charge de travail DPDK existante.

23.1.1.6. Injection de ressources dans des pages volumineuses pour l'API descendante
Copier lien

Lorsqu'une spécification de pod inclut une demande de ressources ou une limite pour les pages volumineuses, l'injecteur de ressources réseau ajoute automatiquement des champs API descendants à la spécification de pod afin de fournir les informations sur les pages volumineuses au conteneur.

L'injecteur de ressources réseau ajoute un volume nommé podnetinfo et monté sur /etc/podnetinfo pour chaque conteneur du module. Le volume utilise l'API Downward et inclut un fichier pour les demandes de pages énormes et les limites. La convention de dénomination des fichiers est la suivante :

/etc/podnetinfo/hugepages_1G_request_<container-name>
/etc/podnetinfo/hugepages_1G_limit_<container-name>
/etc/podnetinfo/hugepages_2M_request_<container-name>
/etc/podnetinfo/hugepages_2M_limit_<container-name>

Les chemins spécifiés dans la liste précédente sont compatibles avec la bibliothèque app-netutil. Par défaut, la bibliothèque est configurée pour rechercher des informations sur les ressources dans le répertoire /etc/podnetinfo. Si vous choisissez de spécifier manuellement les éléments du chemin d'accès à l'API descendante, la bibliothèque app-netutil recherche les chemins d'accès suivants en plus des chemins d'accès de la liste précédente.

/etc/podnetinfo/hugepages_request
/etc/podnetinfo/hugepages_limit
/etc/podnetinfo/hugepages_1G_request
/etc/podnetinfo/hugepages_1G_limit
/etc/podnetinfo/hugepages_2M_request
/etc/podnetinfo/hugepages_2M_limit

Comme pour les chemins que l'injecteur de ressources réseau peut créer, les chemins de la liste précédente peuvent éventuellement se terminer par un suffixe _<container-name>.

23.1.3. Prochaines étapes
Copier lien

Installation de l'opérateur de réseau SR-IOV
Optionnel : Configuration de l'opérateur de réseau SR-IOV
Configuration d'un périphérique de réseau SR-IOV
Si vous utilisez OpenShift Virtualization : Connexion d'une machine virtuelle à un réseau SR-IOV
Configuration de l'attachement à un réseau SR-IOV
Ajout d'un pod à un réseau supplémentaire SR-IOV

23.2. Installation de l'opérateur de réseau SR-IOV
Copier lien

Vous pouvez installer l'opérateur de réseau SR-IOV (Single Root I/O Virtualization) sur votre cluster pour gérer les périphériques et les pièces jointes du réseau SR-IOV.

23.2.1. Installation de l'opérateur de réseau SR-IOV
Copier lien

En tant qu'administrateur de cluster, vous pouvez installer l'opérateur de réseau SR-IOV en utilisant la CLI d'OpenShift Container Platform ou la console web.

23.2.1.1. CLI : Installation de l'opérateur de réseau SR-IOV
Copier lien

En tant qu'administrateur de cluster, vous pouvez installer l'Opérateur à l'aide de la CLI.

Conditions préalables

Un cluster installé sur du matériel bare-metal avec des nœuds dont le matériel prend en charge le SR-IOV.
Installez le CLI OpenShift (oc).
Un compte avec des privilèges cluster-admin.

Procédure

Pour créer l'espace de noms openshift-sriov-network-operator, entrez la commande suivante :

cat << EOF| oc create -f -
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management
EOF

$ cat << EOF| oc create -f -
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management
EOF

Copy to Clipboard

Toggle word wrap

Pour créer un OperatorGroup CR, entrez la commande suivante :

cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
  - openshift-sriov-network-operator
EOF

$ cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
  - openshift-sriov-network-operator
EOF

Copy to Clipboard

Toggle word wrap

S'abonner à l'opérateur du réseau SR-IOV.

Exécutez la commande suivante pour obtenir la version majeure et mineure d'OpenShift Container Platform. Cette information est nécessaire pour la valeur channel dans l'étape suivante.
```
OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \
    grep -o '[0-9]*[.][0-9]*' | head -1)
```
```
$ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \
    grep -o '[0-9]*[.][0-9]*' | head -1)
```
Copy to Clipboard Toggle word wrap

Pour créer un CR d'abonnement pour l'opérateur de réseau SR-IOV, entrez la commande suivante :

cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subscription
  namespace: openshift-sriov-network-operator
spec:
  channel: "${OC_VERSION}"
  name: sriov-network-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

$ cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subscription
  namespace: openshift-sriov-network-operator
spec:
  channel: "${OC_VERSION}"
  name: sriov-network-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

Copy to Clipboard

Toggle word wrap

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

oc get csv -n openshift-sriov-network-operator \
  -o custom-columns=Name:.metadata.name,Phase:.status.phase

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

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name                                         Phase
sriov-network-operator.4.12.0-202310121402   Succeeded

Name                                         Phase
sriov-network-operator.4.12.0-202310121402   Succeeded

Copy to Clipboard

Toggle word wrap

23.2.1.2. Console Web : Installation de l'opérateur de réseau SR-IOV
Copier lien

En tant qu'administrateur de cluster, vous pouvez installer l'Opérateur à l'aide de la console web.

Conditions préalables

Un cluster installé sur du matériel bare-metal avec des nœuds dont le matériel prend en charge le SR-IOV.
Installez le CLI OpenShift (oc).
Un compte avec des privilèges cluster-admin.

Procédure

Installer l'opérateur de réseau SR-IOV :
1. Dans la console web d'OpenShift Container Platform, cliquez sur Operators → OperatorHub.
2. Sélectionnez SR-IOV Network Operator dans la liste des opérateurs disponibles, puis cliquez sur Install.
3. Sur la page Install Operator page, sous Installed Namespacesélectionnez Operator recommended Namespace.
4. Cliquez Install.
Vérifiez que l'opérateur de réseau SR-IOV a été installé avec succès :
1. Naviguez jusqu'à l'écran Operators → Installed Operators page.
2. Veiller à ce que SR-IOV Network Operator soit listé dans le projet openshift-sriov-network-operator avec un Status de InstallSucceeded.
  Note
  Pendant l'installation, un opérateur peut afficher un Failed un état d'erreur. Si l'installation réussit par la suite avec un InstallSucceeded vous pouvez ignorer le message Failed message.
  Si l'opérateur n'apparaît pas tel qu'il a été installé, il convient de poursuivre le dépannage :
  - Inspecter les Operator Subscriptions et Install Plans et les onglets pour détecter toute défaillance ou erreur dans le cadre de la Status.
  - Naviguez jusqu'à l'écran Workloads → Pods et vérifiez les journaux des pods du projet openshift-sriov-network-operator.
  - Vérifiez l'espace de noms du fichier YAML. Si l'annotation est manquante, vous pouvez ajouter l'annotation workload.openshift.io/allowed=management à l'espace de noms de l'opérateur à l'aide de la commande suivante :
    
    $ oc annotate ns/openshift-sriov-network-operator workload.openshift.io/allowed=management
    
    Copy to Clipboard Toggle word wrap
    
    Note
    Pour les clusters OpenShift à nœud unique, l'annotation workload.openshift.io/allowed=management est requise pour l'espace de noms.

23.2.2. Prochaines étapes
Copier lien

Optionnel : Configuration de l'opérateur de réseau SR-IOV

23.3. Configuration de l'opérateur de réseau SR-IOV
Copier lien

L'opérateur de réseau SR-IOV (Single Root I/O Virtualization) gère les périphériques réseau SR-IOV et les attachements réseau dans votre cluster.

23.3.1. Configuration de l'opérateur de réseau SR-IOV
Copier lien

Important

Il n'est normalement pas nécessaire de modifier la configuration de l'opérateur de réseau SR-IOV. La configuration par défaut est recommandée pour la plupart des cas d'utilisation. Ne procédez à la modification de la configuration que si le comportement par défaut de l'opérateur n'est pas compatible avec votre cas d'utilisation.

L'opérateur du réseau SR-IOV ajoute la ressource SriovOperatorConfig.sriovnetwork.openshift.io CustomResourceDefinition. L'opérateur crée automatiquement une ressource personnalisée SriovOperatorConfig (CR) nommée default dans l'espace de noms openshift-sriov-network-operator.

Note

Le CR default contient la configuration de l'opérateur du réseau SR-IOV pour votre cluster. Pour modifier la configuration de l'opérateur, vous devez modifier ce CR.

23.3.1.1. SR-IOV Network Operator config custom resource (ressource personnalisée de configuration de l'opérateur de réseau)
Copier lien

Les champs de la ressource personnalisée sriovoperatorconfig sont décrits dans le tableau suivant :

Expand

Tableau 23.2. SR-IOV Network Operator config custom resource (ressource personnalisée de configuration de l'opérateur de réseau)
Field	Type	Description
`metadata.name`	`string`	Spécifie le nom de l'instance de l'opérateur de réseau SR-IOV. La valeur par défaut est `default`. Ne pas définir une valeur différente.
`metadata.namespace`	`string`	Spécifie l'espace de noms de l'instance de l'opérateur de réseau SR-IOV. La valeur par défaut est `openshift-sriov-network-operator`. Ne pas définir une valeur différente.
`spec.configDaemonNodeSelector`	`string`	Spécifie la sélection de nœuds pour contrôler la planification du démon de configuration du réseau SR-IOV sur les nœuds sélectionnés. Par défaut, ce champ n'est pas défini et l'opérateur déploie le daemon SR-IOV Network Config sur les nœuds de travail.
`spec.disableDrain`	`boolean`	Indique s'il faut désactiver ou activer le processus de vidange du nœud lorsque vous appliquez une nouvelle stratégie pour configurer la carte d'interface réseau sur un nœud. La définition de ce champ sur `true` facilite le développement de logiciels et l'installation d'OpenShift Container Platform sur un seul nœud. Par défaut, ce champ n'est pas défini. Pour les clusters à un seul nœud, définissez ce champ sur `true` après avoir installé l'opérateur. Ce champ doit rester à `true`.
`spec.enableInjector`	`boolean`	Indique s'il faut activer ou désactiver le jeu de démons Network Resources Injector. Par défaut, ce champ est défini sur `true`.
`spec.enableOperatorWebhook`	`boolean`	Indique s'il faut activer ou désactiver le jeu de démons webhook du contrôleur d'admission de l'opérateur. Par défaut, ce champ est défini sur `true`.
`spec.logLevel`	`integer`	Spécifie le niveau de verbosité des journaux de l'opérateur. La valeur `0` permet d'afficher uniquement les journaux de base. La valeur `2` permet d'afficher tous les journaux disponibles. Par défaut, ce champ est défini sur `2`.

23.3.1.2. À propos de l'injecteur de ressources réseau
Copier lien

L'injecteur de ressources réseau est une application de contrôleur d'admission dynamique Kubernetes. Il fournit les capacités suivantes :

Mutation des demandes et des limites de ressources dans une spécification de pod pour ajouter un nom de ressource SR-IOV conformément à une annotation de définition d'attachement au réseau SR-IOV.
Mutation d'une spécification de pod avec un volume d'API descendant pour exposer les annotations de pod, les étiquettes et les demandes et limites de pages énormes. Les conteneurs qui s'exécutent dans le pod peuvent accéder aux informations exposées en tant que fichiers sous le chemin /etc/podnetinfo.

Par défaut, l'injecteur de ressources réseau est activé par l'opérateur de réseau SR-IOV et s'exécute en tant que démon sur tous les nœuds du plan de contrôle. Voici un exemple de pods d'injecteur de ressources réseau fonctionnant dans un cluster avec trois nœuds de plan de contrôle :

oc get pods -n openshift-sriov-network-operator

$ oc get pods -n openshift-sriov-network-operator

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                      READY   STATUS    RESTARTS   AGE
network-resources-injector-5cz5p          1/1     Running   0          10m
network-resources-injector-dwqpx          1/1     Running   0          10m
network-resources-injector-lktz5          1/1     Running   0          10m

NAME                                      READY   STATUS    RESTARTS   AGE
network-resources-injector-5cz5p          1/1     Running   0          10m
network-resources-injector-dwqpx          1/1     Running   0          10m
network-resources-injector-lktz5          1/1     Running   0          10m

Copy to Clipboard

Toggle word wrap

23.3.1.3. À propos du webhook du contrôleur d'admission de l'opérateur de réseau SR-IOV
Copier lien

Le webhook du contrôleur d'admission de l'opérateur de réseau SR-IOV est une application de contrôleur d'admission dynamique Kubernetes. Il fournit les capacités suivantes :

Validation du CR SriovNetworkNodePolicy lors de sa création ou de sa mise à jour.
Mutation du CR SriovNetworkNodePolicy en fixant la valeur par défaut des champs priority et deviceType lors de la création ou de la mise à jour du CR.

Par défaut, le webhook du contrôleur d'admission de l'opérateur de réseau SR-IOV est activé par l'opérateur et s'exécute en tant que démon sur tous les nœuds du plan de contrôle.

Note

Soyez prudent lorsque vous désactivez le webhook du contrôleur d'admission de l'opérateur de réseau SR-IOV. Vous pouvez désactiver le webhook dans des circonstances spécifiques, telles que le dépannage, ou si vous souhaitez utiliser des périphériques non pris en charge.

Voici un exemple de pods de webhooks du contrôleur d'admission de l'opérateur fonctionnant dans un cluster avec trois nœuds de plan de contrôle :

oc get pods -n openshift-sriov-network-operator

$ oc get pods -n openshift-sriov-network-operator

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                      READY   STATUS    RESTARTS   AGE
operator-webhook-9jkw6                    1/1     Running   0          16m
operator-webhook-kbr5p                    1/1     Running   0          16m
operator-webhook-rpfrl                    1/1     Running   0          16m

NAME                                      READY   STATUS    RESTARTS   AGE
operator-webhook-9jkw6                    1/1     Running   0          16m
operator-webhook-kbr5p                    1/1     Running   0          16m
operator-webhook-rpfrl                    1/1     Running   0          16m

Copy to Clipboard

Toggle word wrap

23.3.1.4. À propos des sélecteurs de nœuds personnalisés
Copier lien

Le démon SR-IOV Network Config découvre et configure les périphériques réseau SR-IOV sur les nœuds de la grappe. Par défaut, il est déployé sur tous les nœuds worker du cluster. Vous pouvez utiliser des étiquettes de nœuds pour spécifier sur quels nœuds le démon SR-IOV Network Config s'exécute.

23.3.1.5. Désactivation ou activation de l'injecteur de ressources réseau
Copier lien

Pour désactiver ou activer l'injecteur de ressources réseau, qui est activé par défaut, suivez la procédure suivante.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
Vous devez avoir installé l'opérateur de réseau SR-IOV.

Procédure

Définissez le champ enableInjector. Remplacez <value> par false pour désactiver la fonctionnalité ou par true pour l'activer.

oc patch sriovoperatorconfig default \
  --type=merge -n openshift-sriov-network-operator \
  --patch '{ "spec": { "enableInjector": <value> } }'

$ oc patch sriovoperatorconfig default \
  --type=merge -n openshift-sriov-network-operator \
  --patch '{ "spec": { "enableInjector": <value> } }'

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le YAML suivant pour mettre à jour l'opérateur :

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableInjector: <value>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableInjector: <value>

Copy to Clipboard

Toggle word wrap

23.3.1.6. Désactivation ou activation du webhook du contrôleur d'admission de l'opérateur de réseau SR-IOV
Copier lien

Pour désactiver ou activer le webhook du contrôleur d'admission, qui est activé par défaut, suivez la procédure suivante.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
Vous devez avoir installé l'opérateur de réseau SR-IOV.

Procédure

Définissez le champ enableOperatorWebhook. Remplacez <value> par false pour désactiver la fonctionnalité ou par true pour l'activer :

oc patch sriovoperatorconfig default --type=merge \
  -n openshift-sriov-network-operator \
  --patch '{ "spec": { "enableOperatorWebhook": <value> } }'

$ oc patch sriovoperatorconfig default --type=merge \
  -n openshift-sriov-network-operator \
  --patch '{ "spec": { "enableOperatorWebhook": <value> } }'

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le YAML suivant pour mettre à jour l'opérateur :

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableOperatorWebhook: <value>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableOperatorWebhook: <value>

Copy to Clipboard

Toggle word wrap

23.3.1.7. Configuration d'un NodeSelector personnalisé pour le démon SR-IOV Network Config
Copier lien

Le démon SR-IOV Network Config découvre et configure les périphériques réseau SR-IOV sur les nœuds de la grappe. Par défaut, il est déployé sur tous les nœuds worker du cluster. Vous pouvez utiliser des étiquettes de nœuds pour spécifier sur quels nœuds le démon SR-IOV Network Config s'exécute.

Pour spécifier les nœuds où le démon SR-IOV Network Config est déployé, suivez la procédure suivante.

Important

Lorsque vous mettez à jour le champ configDaemonNodeSelector, le démon SR-IOV Network Config est recréé sur chaque nœud sélectionné. Pendant que le démon est recréé, les utilisateurs du cluster ne peuvent pas appliquer de nouvelle politique de nœuds SR-IOV Network ni créer de nouveaux pods SR-IOV.

Procédure

Pour mettre à jour le sélecteur de nœuds de l'opérateur, entrez la commande suivante :

oc patch sriovoperatorconfig default --type=json \
  -n openshift-sriov-network-operator \
  --patch '[{
      "op": "replace",
      "path": "/spec/configDaemonNodeSelector",
      "value": {<node_label>}
    }]'

$ oc patch sriovoperatorconfig default --type=json \
  -n openshift-sriov-network-operator \
  --patch '[{
      "op": "replace",
      "path": "/spec/configDaemonNodeSelector",
      "value": {<node_label>}
    }]'

Copy to Clipboard

Toggle word wrap

Remplacez <node_label> par une étiquette à appliquer comme dans l'exemple suivant : "node-role.kubernetes.io/worker": "".

Astuce

Vous pouvez également appliquer le YAML suivant pour mettre à jour l'opérateur :

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  configDaemonNodeSelector:
    <node_label>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  configDaemonNodeSelector:
    <node_label>

Copy to Clipboard

Toggle word wrap

23.3.1.8. Configuration de l'opérateur de réseau SR-IOV pour les installations à nœud unique
Copier lien

Par défaut, l'opérateur de réseau SR-IOV draine les charges de travail d'un nœud avant chaque changement de politique. L'opérateur effectue cette action pour s'assurer qu'aucune charge de travail n'utilise les fonctions virtuelles avant la reconfiguration.

Pour les installations sur un seul nœud, il n'y a pas d'autres nœuds pour recevoir les charges de travail. Par conséquent, l'opérateur doit être configuré pour ne pas drainer les charges de travail du nœud unique.

Important

Après avoir exécuté la procédure suivante pour désactiver les charges de travail drainantes, vous devez supprimer toute charge de travail utilisant une interface réseau SR-IOV avant de modifier toute stratégie de nœud de réseau SR-IOV.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
Vous devez avoir installé l'opérateur de réseau SR-IOV.

Procédure

Pour attribuer la valeur true au champ disableDrain, entrez la commande suivante :

oc patch sriovoperatorconfig default --type=merge \
  -n openshift-sriov-network-operator \
  --patch '{ "spec": { "disableDrain": true } }'

$ oc patch sriovoperatorconfig default --type=merge \
  -n openshift-sriov-network-operator \
  --patch '{ "spec": { "disableDrain": true } }'

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le YAML suivant pour mettre à jour l'opérateur :

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  disableDrain: true

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  disableDrain: true

Copy to Clipboard

Toggle word wrap

23.3.1.9. Déploiement de l'opérateur SR-IOV pour les plans de contrôle hébergés
Copier lien

Important

Les plans de contrôle hébergés sont une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Après avoir configuré et déployé votre cluster de services d'hébergement, vous pouvez créer un abonnement à l'opérateur SR-IOV sur un cluster hébergé. Le pod SR-IOV s'exécute sur les machines de travail plutôt que sur le plan de contrôle.

Conditions préalables

Vous avez configuré et déployé le cluster hébergé.

Procédure

Créer un espace de noms et un groupe d'opérateurs :

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
  - openshift-sriov-network-operator

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
  - openshift-sriov-network-operator

Copy to Clipboard

Toggle word wrap

Créer un abonnement à l'opérateur SR-IOV :

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subsription
  namespace: openshift-sriov-network-operator
spec:
  channel: "4.12"
  name: sriov-network-operator
  config:
    nodeSelector:
      node-role.kubernetes.io/worker: ""
  source: s/qe-app-registry/redhat-operators
  sourceNamespace: openshift-marketplace

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subsription
  namespace: openshift-sriov-network-operator
spec:
  channel: "4.12"
  name: sriov-network-operator
  config:
    nodeSelector:
      node-role.kubernetes.io/worker: ""
  source: s/qe-app-registry/redhat-operators
  sourceNamespace: openshift-marketplace

Copy to Clipboard

Toggle word wrap

Vérification

Pour vérifier que l'opérateur SR-IOV est prêt, exécutez la commande suivante et affichez le résultat :

oc get csv -n openshift-sriov-network-operator

$ oc get csv -n openshift-sriov-network-operator

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                         DISPLAY                   VERSION               REPLACES                                     PHASE
sriov-network-operator.4.12.0-202211021237   SR-IOV Network Operator   4.12.0-202211021237   sriov-network-operator.4.12.0-202210290517   Succeeded

NAME                                         DISPLAY                   VERSION               REPLACES                                     PHASE
sriov-network-operator.4.12.0-202211021237   SR-IOV Network Operator   4.12.0-202211021237   sriov-network-operator.4.12.0-202210290517   Succeeded

Copy to Clipboard

Toggle word wrap

Pour vérifier que les pods SR-IOV sont déployés, exécutez la commande suivante :
```
oc get pods -n openshift-sriov-network-operator
```
```
$ oc get pods -n openshift-sriov-network-operator
```
Copy to Clipboard Toggle word wrap

23.3.2. Prochaines étapes
Copier lien

Configuration d'un périphérique de réseau SR-IOV

23.4. Configuration d'un périphérique de réseau SR-IOV
Copier lien

Vous pouvez configurer un dispositif de virtualisation d'E/S à racine unique (SR-IOV) dans votre cluster.

23.4.1. Objet de configuration du nœud de réseau SR-IOV
Copier lien

Vous spécifiez la configuration du dispositif de réseau SR-IOV pour un nœud en créant une stratégie de nœud de réseau SR-IOV. L'objet API de la stratégie fait partie du groupe API sriovnetwork.openshift.io.

Le fichier YAML suivant décrit une politique de nœuds de réseau SR-IOV :

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name> 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: <sriov_resource_name> 
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true" 
  priority: <priority> 
  mtu: <mtu> 
  needVhostNet: false 
  numVfs: <num> 
  nicSelector: 
    vendor: "<vendor_code>" 
    deviceID: "<device_id>" 
    pfNames: ["<pf_name>", ...] 
    rootDevices: ["<pci_bus_id>", ...] 
    netFilter: "<filter_string>" 
  deviceType: <device_type> 
  isRdma: false 
    linkType: <link_type> 
  eSwitchMode: "switchdev"

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name>

1


  namespace: openshift-sriov-network-operator

2


spec:
  resourceName: <sriov_resource_name>

3


  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"

4


  priority: <priority>

5


  mtu: <mtu>

6


  needVhostNet: false

7


  numVfs: <num>

8


  nicSelector:

9


    vendor: "<vendor_code>"

10


    deviceID: "<device_id>"

11


    pfNames: ["<pf_name>", ...]

12


    rootDevices: ["<pci_bus_id>", ...]

13


    netFilter: "<filter_string>"

14


  deviceType: <device_type>

15


  isRdma: false

16


    linkType: <link_type>

17


  eSwitchMode: "switchdev"

18

Copy to Clipboard

Toggle word wrap

Nom de l'objet ressource personnalisé.

L'espace de noms dans lequel l'opérateur de réseau SR-IOV est installé.

Le nom de la ressource du plugin de périphérique réseau SR-IOV. Vous pouvez créer plusieurs stratégies de nœuds de réseau SR-IOV pour un nom de ressource.

Lorsque vous spécifiez un nom, veillez à utiliser l'expression syntaxique acceptée ^[a-zA-Z0-9_] $ dans le formulaire resourceName.

4

Le sélecteur de nœuds indique les nœuds à configurer. Seuls les périphériques de réseau SR-IOV sur les nœuds sélectionnés sont configurés. Le plugin SR-IOV Container Network Interface (CNI) et le plugin de périphérique sont déployés sur les nœuds sélectionnés uniquement.

5

Facultatif : La priorité est une valeur entière comprise entre 0 et 99. Plus la valeur est petite, plus la priorité est élevée. Par exemple, une priorité de 10 est plus élevée que celle de 99. La valeur par défaut est 99.

6

Facultatif : L'unité de transmission maximale (MTU) de la fonction virtuelle. La valeur maximale du MTU peut varier selon les modèles de contrôleurs d'interface réseau (NIC).

7

Facultatif : Définissez needVhostNet sur true pour monter le périphérique /dev/vhost-net dans le pod. Utilisez le périphérique /dev/vhost-net monté avec le kit de développement du plan de données (DPDK) pour transmettre le trafic à la pile réseau du noyau.

8

Le nombre de fonctions virtuelles (VF) à créer pour le périphérique de réseau physique SR-IOV. Pour un contrôleur d'interface réseau (NIC) Intel, le nombre de VF ne peut pas être supérieur au nombre total de VF pris en charge par le périphérique. Pour un NIC Mellanox, le nombre de VF ne peut pas être supérieur à 128.

9

Le sélecteur NIC identifie le dispositif à configurer par l'opérateur. Il n'est pas nécessaire de spécifier des valeurs pour tous les paramètres. Il est recommandé d'identifier le périphérique réseau avec suffisamment de précision pour éviter de sélectionner un périphérique par inadvertance.

Si vous spécifiez rootDevices, vous devez également spécifier une valeur pour vendor, deviceID ou pfNames. Si vous spécifiez pfNames et rootDevices en même temps, assurez-vous qu'ils se réfèrent au même appareil. Si vous spécifiez une valeur pour netFilter, il n'est pas nécessaire de spécifier d'autres paramètres car un ID de réseau est unique.

10

Facultatif : Le code hexadécimal du fournisseur de l'appareil de réseau SR-IOV. Les seules valeurs autorisées sont 8086 et 15b3.

11

Facultatif : Le code hexadécimal du périphérique du réseau SR-IOV. Par exemple, 101b est l'ID d'un périphérique Mellanox ConnectX-6.

12

Facultatif : Un tableau d'un ou plusieurs noms de fonctions physiques (PF) pour l'appareil.

13

Facultatif : Un tableau d'une ou plusieurs adresses de bus PCI pour le PF de l'appareil. Indiquer l'adresse au format suivant : 0000:02:00.1.

14

Facultatif : Le filtre réseau spécifique à la plateforme. La seule plateforme prise en charge est Red Hat OpenStack Platform (RHOSP). Les valeurs acceptables utilisent le format suivant : openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Remplacez xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx par la valeur du fichier de métadonnées /var/config/openstack/latest/network_data.json.

15

Facultatif : Le type de pilote pour les fonctions virtuelles. Les seules valeurs autorisées sont netdevice et vfio-pci. La valeur par défaut est netdevice.

Pour qu'une carte d'interface réseau Mellanox fonctionne en mode DPDK sur des nœuds métalliques nus, utilisez le type de pilote netdevice et définissez isRdma comme true.

16

Facultatif : Permet d'activer ou non le mode d'accès direct à la mémoire à distance (RDMA). La valeur par défaut est false.

Si le paramètre isRdma est réglé sur true, vous pouvez continuer à utiliser le VF compatible RDMA comme un périphérique réseau normal. Un périphérique peut être utilisé dans l'un ou l'autre mode.

Définissez isRdma sur true et needVhostNet sur true pour configurer une carte d'interface réseau Mellanox à utiliser avec les applications Fast Datapath DPDK.

17

Optionnel : Le type de lien pour les VF. La valeur par défaut est eth pour Ethernet. Remplacez cette valeur par "ib" pour InfiniBand.

Lorsque linkType est défini sur ib, isRdma est automatiquement défini sur true par le webhook de l'opérateur de réseau SR-IOV. Lorsque linkType est défini sur ib, deviceType ne doit pas être défini sur vfio-pci.

Ne pas définir linkType sur 'eth' pour SriovNetworkNodePolicy, car cela peut conduire à un nombre incorrect de périphériques disponibles rapportés par le plugin de périphérique.

18

Facultatif : Pour activer le délestage matériel, le champ "eSwitchMode" doit être défini sur "switchdev".

23.4.1.1. Exemples de configuration de nœuds de réseau SR-IOV
Copier lien

L'exemple suivant décrit la configuration d'un dispositif InfiniBand :

Exemple de configuration d'un dispositif InfiniBand

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-ib-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: ibnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    rootDevices:
      - "0000:19:00.0"
  linkType: ib
  isRdma: true

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-ib-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: ibnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    rootDevices:
      - "0000:19:00.0"
  linkType: ib
  isRdma: true

Copy to Clipboard

Toggle word wrap

L'exemple suivant décrit la configuration d'un périphérique réseau SR-IOV dans une machine virtuelle RHOSP :

Exemple de configuration d'un dispositif SR-IOV dans une machine virtuelle

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-sriov-net-openstack-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: sriovnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 1 
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509"

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-sriov-net-openstack-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: sriovnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 1

1


  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509"

2

Copy to Clipboard

Toggle word wrap

1: Le champ numVfs est toujours défini sur 1 lors de la configuration de la stratégie de réseau de nœuds pour une machine virtuelle.
2: Le champ netFilter doit faire référence à un ID de réseau lorsque la machine virtuelle est déployée sur RHOSP. Les valeurs valides pour netFilter sont disponibles à partir d'un objet SriovNetworkNodeState.

23.4.1.2. Partitionnement des fonctions virtuelles (VF) pour les dispositifs SR-IOV
Copier lien

Dans certains cas, vous pouvez souhaiter répartir les fonctions virtuelles (VF) d'une même fonction physique (PF) dans plusieurs pools de ressources. Par exemple, vous pouvez vouloir que certaines fonctions virtuelles se chargent avec le pilote par défaut et que les autres se chargent avec le pilote vfio-pci. Dans un tel déploiement, le sélecteur pfNames de votre ressource personnalisée (CR) SriovNetworkNodePolicy peut être utilisé pour spécifier une plage de VF pour un pool en utilisant le format suivant : <pfname>#<first_vf>-<last_vf>.

Par exemple, le YAML suivant montre le sélecteur pour une interface nommée netpf0 avec les VF 2 et 7:

pfNames: ["netpf0#2-7"]

pfNames: ["netpf0#2-7"]

Copy to Clipboard

Toggle word wrap

netpf0 est le nom de l'interface PF.
2 est le premier indice VF (basé sur 0) qui est inclus dans la plage.
7 est le dernier indice VF (basé sur 0) qui est inclus dans la plage.

Il est possible de sélectionner des VF dans la même CP en utilisant des CR de polices différentes si les conditions suivantes sont remplies :

La valeur numVfs doit être identique pour les polices qui sélectionnent la même CP.
L'indice VF doit être compris entre 0 et <numVfs>-1. Par exemple, si vous avez une police dont la valeur numVfs est définie sur 8, la valeur <first_vf> ne doit pas être inférieure à 0, et la valeur <last_vf> ne doit pas être supérieure à 7.
Les fourchettes de valeurs des différentes politiques ne doivent pas se chevaucher.
L'adresse <first_vf> ne doit pas être plus grande que l'adresse <last_vf>.

L'exemple suivant illustre le partitionnement des cartes réseau pour un périphérique SR-IOV.

La politique policy-net-1 définit un pool de ressources net-1 qui contient le VF 0 de PF netpf0 avec le pilote VF par défaut. La politique policy-net-1-dpdk définit un pool de ressources net-1-dpdk qui contient les VF 8 à 15 de la PF netpf0 avec le pilote VF vfio.

Politique policy-net-1:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#0-0"]
  deviceType: netdevice

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#0-0"]
  deviceType: netdevice

Copy to Clipboard

Toggle word wrap

Politique policy-net-1-dpdk:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1-dpdk
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1dpdk
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#8-15"]
  deviceType: vfio-pci

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1-dpdk
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1dpdk
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#8-15"]
  deviceType: vfio-pci

Copy to Clipboard

Toggle word wrap

Vérification de la réussite du partitionnement de l'interface

Confirmez que l'interface est partitionnée en fonctions virtuelles (VF) pour le périphérique SR-IOV en exécutant la commande suivante.

ip link show <interface>

ip link show <interface>

1

Copy to Clipboard

Toggle word wrap

1: Remplacez <interface> par l'interface que vous avez spécifiée lors du partitionnement en VF pour le périphérique SR-IOV, par exemple, ens3f1.

Exemple de sortie

5: ens3f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:d1:bc:01 brd ff:ff:ff:ff:ff:ff

vf 0     link/ether 5a:e7:88:25:ea:a0 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 1     link/ether 3e:1d:36:d7:3d:49 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 2     link/ether ce:09:56:97:df:f9 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 3     link/ether 5e:91:cf:88:d1:38 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 4     link/ether e6:06:a1:96:2f:de brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

5: ens3f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:d1:bc:01 brd ff:ff:ff:ff:ff:ff

vf 0     link/ether 5a:e7:88:25:ea:a0 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 1     link/ether 3e:1d:36:d7:3d:49 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 2     link/ether ce:09:56:97:df:f9 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 3     link/ether 5e:91:cf:88:d1:38 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 4     link/ether e6:06:a1:96:2f:de brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

Copy to Clipboard

Toggle word wrap

23.4.2. Configuration des périphériques de réseau SR-IOV
Copier lien

L'opérateur de réseau SR-IOV ajoute la ressource SriovNetworkNodePolicy.sriovnetwork.openshift.io CustomResourceDefinition à OpenShift Container Platform. Vous pouvez configurer un périphérique réseau SR-IOV en créant une ressource personnalisée (CR) SriovNetworkNodePolicy.

Note

Lors de l'application de la configuration spécifiée dans un objet SriovNetworkNodePolicy, l'opérateur SR-IOV peut vidanger les nœuds et, dans certains cas, les redémarrer.

L'application d'une modification de configuration peut prendre plusieurs minutes.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
Vous avez installé l'opérateur de réseau SR-IOV.
Vous avez suffisamment de nœuds disponibles dans votre cluster pour gérer la charge de travail expulsée des nœuds épuisés.
Vous n'avez sélectionné aucun nœud du plan de contrôle pour la configuration des équipements du réseau SR-IOV.

Procédure

Créez un objet SriovNetworkNodePolicy, puis enregistrez le YAML dans le fichier <name>-sriov-node-network.yaml. Remplacez <name> par le nom de cette configuration.
Facultatif : Étiqueter les nœuds de cluster compatibles SR-IOV avec SriovNetworkNodePolicy.Spec.NodeSelector s'ils ne le sont pas déjà. Pour plus d'informations sur l'étiquetage des nœuds, voir "Understanding how to update labels on nodes".
Créer l'objet SriovNetworkNodePolicy:
```
oc create -f <name>-sriov-node-network.yaml
```
```
oc create -f <name>-sriov-node-network.yaml
```
Copy to Clipboard Toggle word wrap
où <name> spécifie le nom de cette configuration.
Après l'application de la mise à jour de la configuration, tous les pods de l'espace de noms sriov-network-operator passent à l'état Running.
Pour vérifier que le dispositif de réseau SR-IOV est configuré, entrez la commande suivante. Remplacez <node_name> par le nom d'un nœud avec le dispositif de réseau SR-IOV que vous venez de configurer.
```
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
```
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
Copy to Clipboard Toggle word wrap

23.4.3. Dépannage de la configuration SR-IOV
Copier lien

Après avoir suivi la procédure de configuration d'un périphérique de réseau SR-IOV, les sections suivantes traitent de certaines conditions d'erreur.

Pour afficher l'état des nœuds, exécutez la commande suivante :

oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>

oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>

Copy to Clipboard

Toggle word wrap

où : <node_name> indique le nom d'un nœud doté d'un dispositif de réseau SR-IOV.

Sortie d'erreur : Impossible d'allouer de la mémoire

"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"

"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"

Copy to Clipboard

Toggle word wrap

Lorsqu'un nœud indique qu'il ne peut pas allouer de mémoire, vérifiez les éléments suivants :

Confirmez que les paramètres SR-IOV globaux sont activés dans le BIOS du nœud.
Confirmez que VT-d est activé dans le BIOS du nœud.

23.4.4. Affectation d'un réseau SR-IOV à un VRF
Copier lien

En tant qu'administrateur de cluster, vous pouvez affecter une interface réseau SR-IOV à votre domaine VRF en utilisant le plugin CNI VRF.

Pour ce faire, ajoutez la configuration VRF au paramètre facultatif metaPlugins de la ressource SriovNetwork.

Note

Les applications qui utilisent les VRF doivent se lier à un périphérique spécifique. L'usage courant est d'utiliser l'option SO_BINDTODEVICE pour une socket. SO_BINDTODEVICE lie la socket à un périphérique spécifié dans le nom de l'interface passée, par exemple, eth1. Pour utiliser SO_BINDTODEVICE, l'application doit avoir les capacités de CAP_NET_RAW.

L'utilisation d'une VRF via la commande ip vrf exec n'est pas prise en charge dans les pods OpenShift Container Platform. Pour utiliser la VRF, liez les applications directement à l'interface VRF.

23.4.4.1. Création d'un attachement réseau SR-IOV supplémentaire avec le plugin CNI VRF
Copier lien

L'opérateur de réseau SR-IOV gère les définitions de réseaux supplémentaires. Lorsque vous indiquez un réseau SR-IOV supplémentaire à créer, l'opérateur de réseau SR-IOV crée automatiquement la ressource personnalisée (CR) NetworkAttachmentDefinition.

Note

Ne modifiez pas les ressources personnalisées NetworkAttachmentDefinition gérées par l'opérateur de réseau SR-IOV. Cela pourrait perturber le trafic sur votre réseau supplémentaire.

Pour créer un attachement réseau SR-IOV supplémentaire avec le plugin CNI VRF, suivez la procédure suivante.

Conditions préalables

Installez le CLI (oc) de OpenShift Container Platform.
Connectez-vous au cluster OpenShift Container Platform en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créez la ressource personnalisée (CR) SriovNetwork pour l'attachement supplémentaire au réseau SR-IOV et insérez la configuration metaPlugins, comme dans l'exemple de CR suivant. Enregistrez le YAML dans le fichier sriov-network-attachment.yaml.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: example-network
  namespace: additional-sriov-network-1
spec:
  ipam: |
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "routes": [{
        "dst": "0.0.0.0/0"
      }],
      "gateway": "10.56.217.1"
    }
  vlan: 0
  resourceName: intelnics
  metaPlugins : |
    {
      "type": "vrf", 
      "vrfname": "example-vrf-name" 
    }

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: example-network
  namespace: additional-sriov-network-1
spec:
  ipam: |
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "routes": [{
        "dst": "0.0.0.0/0"
      }],
      "gateway": "10.56.217.1"
    }
  vlan: 0
  resourceName: intelnics
  metaPlugins : |
    {
      "type": "vrf",

1


      "vrfname": "example-vrf-name"

2

Copy to Clipboard

Toggle word wrap

1: type doit être réglé sur vrf.
2: vrfname est le nom du VRF auquel l'interface est assignée. S'il n'existe pas dans le pod, il est créé.

Créer la ressource SriovNetwork:

oc create -f sriov-network-attachment.yaml

$ oc create -f sriov-network-attachment.yaml

Copy to Clipboard

Toggle word wrap

Vérification de la création de la CR NetworkAttachmentDefinition

Confirmez que l'opérateur du réseau SR-IOV a créé le CR NetworkAttachmentDefinition en exécutant la commande suivante.
```
oc get network-attachment-definitions -n <namespace> 
```
```
oc get network-attachment-definitions -n <namespace> 
```
1
Copy to Clipboard Toggle word wrap
1
Remplacez <namespace> par l'espace de noms que vous avez spécifié lors de la configuration de l'attachement au réseau, par exemple, additional-sriov-network-1.
Exemple de sortie
```
NAME                            AGE
additional-sriov-network-1      14m
```
```
NAME                            AGE
additional-sriov-network-1      14m
```
Copy to Clipboard Toggle word wrap
Note
Il peut y avoir un délai avant que l'opérateur du réseau SR-IOV ne crée le CR.

Vérification de la réussite de l'attachement au réseau SR-IOV supplémentaire

Pour vérifier que le VRF CNI est correctement configuré et que l'attachement réseau SR-IOV supplémentaire est attaché, procédez comme suit :

Créer un réseau SR-IOV qui utilise la VRF CNI.
Attribuer le réseau à un pod.
Vérifiez que l'attachement réseau du pod est connecté au réseau supplémentaire SR-IOV. Connectez-vous à distance au pod et exécutez la commande suivante :
```
ip vrf show
```
```
$ ip vrf show
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
Name              Table
-----------------------
red                 10
```
```
Name              Table
-----------------------
red                 10
```
Copy to Clipboard Toggle word wrap

Confirmez que l'interface VRF est maître de l'interface secondaire :

ip link

$ ip link

Copy to Clipboard

Toggle word wrap

Exemple de sortie

...
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
...

...
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
...

Copy to Clipboard

Toggle word wrap

23.4.5. Prochaines étapes
Copier lien

Configuration de l'attachement à un réseau SR-IOV

23.5. Configuration d'une connexion au réseau Ethernet SR-IOV
Copier lien

Vous pouvez configurer une connexion réseau Ethernet pour un périphérique de virtualisation d'E/S à racine unique (SR-IOV) dans le cluster.

23.5.1. Objet de configuration de l'appareil Ethernet
Copier lien

Vous pouvez configurer un périphérique de réseau Ethernet en définissant un objet SriovNetwork.

Le fichier YAML suivant décrit un objet SriovNetwork:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: <name> 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: <sriov_resource_name> 
  networkNamespace: <target_namespace> 
  vlan: <vlan> 
  spoofChk: "<spoof_check>" 
  ipam: |- 
    {}
  linkState: <link_state> 
  maxTxRate: <max_tx_rate> 
  minTxRate: <min_tx_rate> 
  vlanQoS: <vlan_qos> 
  trust: "<trust_vf>" 
  capabilities: <capabilities>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: <name>

1


  namespace: openshift-sriov-network-operator

2


spec:
  resourceName: <sriov_resource_name>

3


  networkNamespace: <target_namespace>

4


  vlan: <vlan>

5


  spoofChk: "<spoof_check>"

6


  ipam: |-

7


    {}
  linkState: <link_state>

8


  maxTxRate: <max_tx_rate>

9


  minTxRate: <min_tx_rate>

10


  vlanQoS: <vlan_qos>

11


  trust: "<trust_vf>"

12


  capabilities: <capabilities>

13

Copy to Clipboard

Toggle word wrap

1: Un nom pour l'objet. L'opérateur de réseau SR-IOV crée un objet NetworkAttachmentDefinition portant le même nom.
2: L'espace de noms dans lequel l'opérateur de réseau SR-IOV est installé.
3: La valeur du paramètre spec.resourceName de l'objet SriovNetworkNodePolicy qui définit le matériel SR-IOV pour ce réseau supplémentaire.
4: L'espace de noms cible pour l'objet SriovNetwork. Seuls les pods de l'espace de noms cible peuvent s'attacher au réseau supplémentaire.
5: Facultatif : Un ID de réseau local virtuel (VLAN) pour le réseau supplémentaire. La valeur entière doit être comprise entre 0 et 4095. La valeur par défaut est 0.
6: Facultatif : Le mode de vérification de l'usurpation d'identité du VF. Les valeurs autorisées sont les chaînes "on" et "off".
Important
Vous devez mettre la valeur que vous indiquez entre guillemets, sinon l'objet est rejeté par l'opérateur de réseau SR-IOV.
7: Un objet de configuration pour le plugin IPAM CNI sous la forme d'un bloc YAML scalaire. Le plugin gère l'attribution des adresses IP pour la définition de l'attachement.
8: Facultatif : L'état de la liaison de la fonction virtuelle (VF). Les valeurs autorisées sont enable, disable et auto.
9: Facultatif : Vitesse de transmission maximale, en Mbps, pour le VF.
10: Facultatif : Un taux de transmission minimum, en Mbps, pour le VF. Cette valeur doit être inférieure ou égale à la vitesse de transmission maximale.
Note
Les cartes réseau Intel ne prennent pas en charge le paramètre minTxRate. Pour plus d'informations, voir BZ#1772847.
11: Facultatif : Un niveau de priorité IEEE 802.1p pour le VF. La valeur par défaut est 0.
12: Facultatif : Le mode de confiance du VF. Les valeurs autorisées sont les chaînes "on" et "off".
Important
Vous devez mettre la valeur que vous indiquez entre guillemets, sinon l'opérateur de réseau SR-IOV rejette l'objet.
13: Facultatif : Les capacités à configurer pour ce réseau supplémentaire. Vous pouvez spécifier "{ "ips": true }" pour activer la prise en charge des adresses IP ou "{ "mac": true }" pour activer la prise en charge des adresses MAC.

23.5.1.1. Configuration de l'attribution d'adresses IP pour un réseau supplémentaire
Copier lien

Le module de gestion des adresses IP (IPAM) Container Network Interface (CNI) fournit des adresses IP aux autres modules CNI.

Vous pouvez utiliser les types d'attribution d'adresses IP suivants :

Affectation statique.
Attribution dynamique par le biais d'un serveur DHCP. Le serveur DHCP que vous spécifiez doit être accessible depuis le réseau supplémentaire.
Affectation dynamique via le plugin CNI de Whereabouts IPAM.

23.5.1.1.1. Configuration de l'attribution d'une adresse IP statique
Copier lien

Le tableau suivant décrit la configuration pour l'attribution d'une adresse IP statique :

Expand

Tableau 23.3. ipam objet de configuration statique
Field	Type	Description
`type`	`string`	Le type d'adresse IPAM. La valeur `static` est obligatoire.
`addresses`	`array`	Un tableau d'objets spécifiant les adresses IP à attribuer à l'interface virtuelle. Les adresses IPv4 et IPv6 sont prises en charge.
`routes`	`array`	Un tableau d'objets spécifiant les routes à configurer dans le pod.
`dns`	`array`	Facultatif : Un tableau d'objets spécifiant la configuration DNS.

Le tableau addresses nécessite des objets avec les champs suivants :

Expand

Tableau 23.4. ipam.addresses[] réseau
Field	Type	Description
`address`	`string`	Une adresse IP et un préfixe de réseau que vous spécifiez. Par exemple, si vous spécifiez `10.10.21.10/24`, le réseau supplémentaire se voit attribuer une adresse IP de `10.10.21.10` et le masque de réseau est `255.255.255.0`.
`gateway`	`string`	Passerelle par défaut vers laquelle acheminer le trafic réseau sortant.

Expand

Tableau 23.5. ipam.routes[] réseau
Field	Type	Description
`dst`	`string`	La plage d'adresses IP au format CIDR, par exemple `192.168.17.0/24` ou `0.0.0.0/0` pour la route par défaut.
`gw`	`string`	La passerelle où le trafic réseau est acheminé.

Expand

Tableau 23.6. ipam.dns objet
Field	Type	Description
`nameservers`	`array`	Un tableau d'une ou plusieurs adresses IP auxquelles envoyer les requêtes DNS.
`domain`	`array`	Le domaine par défaut à ajouter à un nom d'hôte. Par exemple, si le domaine est défini sur `example.com`, une requête DNS pour `example-host` est réécrite en `example-host.example.com`.
`search`	`array`	Un tableau de noms de domaine à ajouter à un nom d'hôte non qualifié, tel que `example-host`, lors d'une requête de recherche DNS.

Exemple de configuration de l'attribution d'une adresse IP statique

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

Copy to Clipboard

Toggle word wrap

23.5.1.1.2. Configuration de l'attribution dynamique d'adresses IP (DHCP)
Copier lien

Le JSON suivant décrit la configuration pour l'attribution dynamique d'adresses IP avec DHCP.

Renouvellement des baux DHCP

Un pod obtient son bail DHCP d'origine lors de sa création. Le bail doit être renouvelé périodiquement par un serveur DHCP minimal déployé sur le cluster.

L'opérateur réseau SR-IOV ne crée pas de déploiement de serveur DHCP ; l'opérateur réseau du cluster est responsable de la création du déploiement minimal de serveur DHCP.

Pour déclencher le déploiement du serveur DHCP, vous devez créer un attachement réseau shim en modifiant la configuration de l'opérateur réseau du cluster, comme dans l'exemple suivant :

Exemple de définition de l'attachement au réseau de cales

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

Copy to Clipboard

Toggle word wrap

Expand

Tableau 23.7. ipam Objet de configuration DHCP
Field	Type	Description
`type`	`string`	Le type d'adresse IPAM. La valeur `dhcp` est obligatoire.

Exemple de configuration de l'attribution dynamique d'une adresse IP (DHCP)

{
  "ipam": {
    "type": "dhcp"
  }
}

{
  "ipam": {
    "type": "dhcp"
  }
}

Copy to Clipboard

Toggle word wrap

23.5.1.1.3. Configuration de l'attribution dynamique d'adresses IP avec Whereabouts
Copier lien

Le plugin Whereabouts CNI permet l'attribution dynamique d'une adresse IP à un réseau supplémentaire sans utiliser de serveur DHCP.

Le tableau suivant décrit la configuration pour l'attribution dynamique d'adresses IP avec Whereabouts :

Expand

Tableau 23.8. ipam objet de configuration de la localisation
Field	Type	Description
`type`	`string`	Le type d'adresse IPAM. La valeur `whereabouts` est obligatoire.
`range`	`string`	Une adresse IP et une plage d'adresses en notation CIDR. Les adresses IP sont attribuées à partir de cette plage d'adresses.
`exclude`	`array`	Facultatif : Une liste de zéro ou plusieurs adresses IP et plages d'adresses en notation CIDR. Les adresses IP situées dans une plage d'adresses exclue ne sont pas attribuées.

Exemple de configuration de l'attribution dynamique d'adresses IP à l'aide de Whereabouts

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

Copy to Clipboard

Toggle word wrap

23.5.2. Configuration du réseau supplémentaire SR-IOV
Copier lien

Vous pouvez configurer un réseau supplémentaire qui utilise le matériel SR-IOV en créant un objet SriovNetwork. Lorsque vous créez un objet SriovNetwork, l'opérateur de réseau SR-IOV crée automatiquement un objet NetworkAttachmentDefinition.

Note

Ne pas modifier ou supprimer un objet SriovNetwork s'il est rattaché à un pod en état running.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créez un objet SriovNetwork, puis enregistrez le fichier YAML dans le fichier <name>.yaml, où <name> est le nom de ce réseau supplémentaire. La spécification de l'objet peut ressembler à l'exemple suivant :

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: attach1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  networkNamespace: project2
  ipam: |-
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "gateway": "10.56.217.1"
    }

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: attach1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  networkNamespace: project2
  ipam: |-
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "gateway": "10.56.217.1"
    }

Copy to Clipboard

Toggle word wrap

Pour créer l'objet, entrez la commande suivante :
```
oc create -f <name>.yaml
```
```
$ oc create -f <name>.yaml
```
Copy to Clipboard Toggle word wrap
où <name> indique le nom du réseau supplémentaire.
Facultatif : Pour confirmer l'existence de l'objet NetworkAttachmentDefinition associé à l'objet SriovNetwork créé à l'étape précédente, entrez la commande suivante. Remplacez <namespace> par le networkNamespace que vous avez spécifié dans l'objet SriovNetwork.
```
oc get net-attach-def -n <namespace>
```
```
oc get net-attach-def -n <namespace>
```
Copy to Clipboard Toggle word wrap

23.5.3. Prochaines étapes
Copier lien

Ajout d'un pod à un réseau supplémentaire SR-IOV

23.6. Configuration d'une connexion au réseau InfiniBand SR-IOV
Copier lien

Vous pouvez configurer une connexion réseau InfiniBand (IB) pour un périphérique de virtualisation d'E/S à racine unique (SR-IOV) dans le cluster.

23.6.1. Objet de configuration du dispositif InfiniBand
Copier lien

Vous pouvez configurer un périphérique réseau InfiniBand (IB) en définissant un objet SriovIBNetwork.

Le fichier YAML suivant décrit un objet SriovIBNetwork:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork
metadata:
  name: <name> 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: <sriov_resource_name> 
  networkNamespace: <target_namespace> 
  ipam: |- 
    {}
  linkState: <link_state> 
  capabilities: <capabilities>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork
metadata:
  name: <name>

1


  namespace: openshift-sriov-network-operator

2


spec:
  resourceName: <sriov_resource_name>

3


  networkNamespace: <target_namespace>

4


  ipam: |-

5


    {}
  linkState: <link_state>

6


  capabilities: <capabilities>

7

Copy to Clipboard

Toggle word wrap

1: Un nom pour l'objet. L'opérateur de réseau SR-IOV crée un objet NetworkAttachmentDefinition portant le même nom.
2: L'espace de noms dans lequel l'opérateur SR-IOV est installé.
3: La valeur du paramètre spec.resourceName de l'objet SriovNetworkNodePolicy qui définit le matériel SR-IOV pour ce réseau supplémentaire.
4: L'espace de noms cible pour l'objet SriovIBNetwork. Seuls les pods de l'espace de noms cible peuvent s'attacher au périphérique réseau.
5: Facultatif : Un objet de configuration pour le plugin IPAM CNI sous la forme d'un bloc YAML scalaire. Le plugin gère l'attribution des adresses IP pour la définition de l'attachement.
6: Facultatif : L'état de la liaison de la fonction virtuelle (VF). Les valeurs autorisées sont enable, disable et auto.
7: Facultatif : Les capacités à configurer pour ce réseau. Vous pouvez spécifier "{ "ips": true }" pour activer la prise en charge des adresses IP ou "{ "infinibandGUID": true }" pour activer la prise en charge des identificateurs uniques globaux (GUID) de l'IB.

23.6.1.1. Configuration de l'attribution d'adresses IP pour un réseau supplémentaire
Copier lien

Le module de gestion des adresses IP (IPAM) Container Network Interface (CNI) fournit des adresses IP aux autres modules CNI.

Vous pouvez utiliser les types d'attribution d'adresses IP suivants :

Affectation statique.
Attribution dynamique par le biais d'un serveur DHCP. Le serveur DHCP que vous spécifiez doit être accessible depuis le réseau supplémentaire.
Affectation dynamique via le plugin CNI de Whereabouts IPAM.

23.6.1.1.1. Configuration de l'attribution d'une adresse IP statique
Copier lien

Le tableau suivant décrit la configuration pour l'attribution d'une adresse IP statique :

Expand

Tableau 23.9. ipam objet de configuration statique
Field	Type	Description
`type`	`string`	Le type d'adresse IPAM. La valeur `static` est obligatoire.
`addresses`	`array`	Un tableau d'objets spécifiant les adresses IP à attribuer à l'interface virtuelle. Les adresses IPv4 et IPv6 sont prises en charge.
`routes`	`array`	Un tableau d'objets spécifiant les routes à configurer dans le pod.
`dns`	`array`	Facultatif : Un tableau d'objets spécifiant la configuration DNS.

Le tableau addresses nécessite des objets avec les champs suivants :

Expand

Tableau 23.10. ipam.addresses[] réseau
Field	Type	Description
`address`	`string`	Une adresse IP et un préfixe de réseau que vous spécifiez. Par exemple, si vous spécifiez `10.10.21.10/24`, le réseau supplémentaire se voit attribuer une adresse IP de `10.10.21.10` et le masque de réseau est `255.255.255.0`.
`gateway`	`string`	Passerelle par défaut vers laquelle acheminer le trafic réseau sortant.

Expand

Tableau 23.11. ipam.routes[] réseau
Field	Type	Description
`dst`	`string`	La plage d'adresses IP au format CIDR, par exemple `192.168.17.0/24` ou `0.0.0.0/0` pour la route par défaut.
`gw`	`string`	La passerelle où le trafic réseau est acheminé.

Expand

Tableau 23.12. ipam.dns objet
Field	Type	Description
`nameservers`	`array`	Un tableau d'une ou plusieurs adresses IP auxquelles envoyer les requêtes DNS.
`domain`	`array`	Le domaine par défaut à ajouter à un nom d'hôte. Par exemple, si le domaine est défini sur `example.com`, une requête DNS pour `example-host` est réécrite en `example-host.example.com`.
`search`	`array`	Un tableau de noms de domaine à ajouter à un nom d'hôte non qualifié, tel que `example-host`, lors d'une requête de recherche DNS.

Exemple de configuration de l'attribution d'une adresse IP statique

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

Copy to Clipboard

Toggle word wrap

23.6.1.1.2. Configuration de l'attribution dynamique d'adresses IP (DHCP)
Copier lien

Le JSON suivant décrit la configuration pour l'attribution dynamique d'adresses IP avec DHCP.

Renouvellement des baux DHCP

Un pod obtient son bail DHCP d'origine lors de sa création. Le bail doit être renouvelé périodiquement par un serveur DHCP minimal déployé sur le cluster.

Pour déclencher le déploiement du serveur DHCP, vous devez créer un attachement réseau shim en modifiant la configuration de l'opérateur réseau du cluster, comme dans l'exemple suivant :

Exemple de définition de l'attachement au réseau de cales

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

Copy to Clipboard

Toggle word wrap

Expand

Tableau 23.13. ipam Objet de configuration DHCP
Field	Type	Description
`type`	`string`	Le type d'adresse IPAM. La valeur `dhcp` est obligatoire.

Exemple de configuration de l'attribution dynamique d'une adresse IP (DHCP)

{
  "ipam": {
    "type": "dhcp"
  }
}

{
  "ipam": {
    "type": "dhcp"
  }
}

Copy to Clipboard

Toggle word wrap

23.6.1.1.3. Configuration de l'attribution dynamique d'adresses IP avec Whereabouts
Copier lien

Le plugin Whereabouts CNI permet l'attribution dynamique d'une adresse IP à un réseau supplémentaire sans utiliser de serveur DHCP.

Le tableau suivant décrit la configuration pour l'attribution dynamique d'adresses IP avec Whereabouts :

Expand

Tableau 23.14. ipam objet de configuration de la localisation
Field	Type	Description
`type`	`string`	Le type d'adresse IPAM. La valeur `whereabouts` est obligatoire.
`range`	`string`	Une adresse IP et une plage d'adresses en notation CIDR. Les adresses IP sont attribuées à partir de cette plage d'adresses.
`exclude`	`array`	Facultatif : Une liste de zéro ou plusieurs adresses IP et plages d'adresses en notation CIDR. Les adresses IP situées dans une plage d'adresses exclue ne sont pas attribuées.

Exemple de configuration de l'attribution dynamique d'adresses IP à l'aide de Whereabouts

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

Copy to Clipboard

Toggle word wrap

23.6.2. Configuration du réseau supplémentaire SR-IOV
Copier lien

Vous pouvez configurer un réseau supplémentaire qui utilise le matériel SR-IOV en créant un objet SriovIBNetwork. Lorsque vous créez un objet SriovIBNetwork, l'opérateur de réseau SR-IOV crée automatiquement un objet NetworkAttachmentDefinition.

Note

Ne pas modifier ou supprimer un objet SriovIBNetwork s'il est rattaché à un pod en état running.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créez un objet SriovIBNetwork, puis enregistrez le fichier YAML dans le fichier <name>.yaml, où <name> est le nom de ce réseau supplémentaire. La spécification de l'objet peut ressembler à l'exemple suivant :

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork
metadata:
  name: attach1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  networkNamespace: project2
  ipam: |-
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "gateway": "10.56.217.1"
    }

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork
metadata:
  name: attach1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  networkNamespace: project2
  ipam: |-
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "gateway": "10.56.217.1"
    }

Copy to Clipboard

Toggle word wrap

Pour créer l'objet, entrez la commande suivante :
```
oc create -f <name>.yaml
```
```
$ oc create -f <name>.yaml
```
Copy to Clipboard Toggle word wrap
où <name> indique le nom du réseau supplémentaire.
Facultatif : Pour confirmer l'existence de l'objet NetworkAttachmentDefinition associé à l'objet SriovIBNetwork créé à l'étape précédente, entrez la commande suivante. Remplacez <namespace> par le networkNamespace que vous avez spécifié dans l'objet SriovIBNetwork.
```
oc get net-attach-def -n <namespace>
```
```
oc get net-attach-def -n <namespace>
```
Copy to Clipboard Toggle word wrap

23.6.3. Prochaines étapes
Copier lien

Ajout d'un pod à un réseau supplémentaire SR-IOV

23.7. Ajout d'un pod à un réseau supplémentaire SR-IOV
Copier lien

Vous pouvez ajouter un pod à un réseau existant de virtualisation d'E/S à racine unique (SR-IOV).

23.7.1. Configuration de l'exécution pour une pièce jointe au réseau
Copier lien

Lors de l'attachement d'un module à un réseau supplémentaire, vous pouvez spécifier une configuration d'exécution afin d'effectuer des personnalisations spécifiques pour le module. Par exemple, vous pouvez demander une adresse matérielle MAC spécifique.

Vous spécifiez la configuration d'exécution en définissant une annotation dans la spécification du pod. La clé de l'annotation est k8s.v1.cni.cncf.io/networks, et elle accepte un objet JSON qui décrit la configuration d'exécution.

23.7.1.1. Configuration de l'exécution pour un attachement SR-IOV basé sur Ethernet
Copier lien

Le JSON suivant décrit les options de configuration de la durée d'exécution pour un accessoire de réseau SR-IOV basé sur Ethernet.

[
  {
    "name": "<name>", 
    "mac": "<mac_address>", 
    "ips": ["<cidr_range>"] 
  }
]

[
  {
    "name": "<name>",

1


    "mac": "<mac_address>",

2


    "ips": ["<cidr_range>"]

3

}
]

Copy to Clipboard

Toggle word wrap

1: Le nom du CR de définition de l'attachement au réseau SR-IOV.
2: Facultatif : L'adresse MAC de l'appareil SR-IOV qui est allouée à partir du type de ressource défini dans le CR de définition de l'attachement au réseau SR-IOV. Pour utiliser cette fonctionnalité, vous devez également spécifier { "mac": true } dans l'objet SriovNetwork.
3: Facultatif : adresses IP pour le périphérique SR-IOV allouées à partir du type de ressource défini dans la CR de définition de l'attachement au réseau SR-IOV. Les adresses IPv4 et IPv6 sont prises en charge. Pour utiliser cette fonctionnalité, vous devez également spécifier { "ips": true } dans l'objet SriovNetwork.

Exemple de configuration d'exécution

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "net1",
          "mac": "20:04:0f:f1:88:01",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "net1",
          "mac": "20:04:0f:f1:88:01",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

Copy to Clipboard

Toggle word wrap

23.7.1.2. Configuration de l'exécution pour un attachement SR-IOV basé sur InfiniBand
Copier lien

Le JSON suivant décrit les options de configuration de la durée d'exécution pour un attachement réseau SR-IOV basé sur InfiniBand.

[
  {
    "name": "<network_attachment>", 
    "infiniband-guid": "<guid>", 
    "ips": ["<cidr_range>"] 
  }
]

[
  {
    "name": "<network_attachment>",

1


    "infiniband-guid": "<guid>",

2


    "ips": ["<cidr_range>"]

3

}
]

Copy to Clipboard

Toggle word wrap

1: Le nom du CR de définition de l'attachement au réseau SR-IOV.
2: Le GUID InfiniBand pour le périphérique SR-IOV. Pour utiliser cette fonctionnalité, vous devez également spécifier { "infinibandGUID": true } dans l'objet SriovIBNetwork.
3: Les adresses IP pour le dispositif SR-IOV qui est alloué à partir du type de ressource défini dans le CR de définition de l'attachement au réseau SR-IOV. Les adresses IPv4 et IPv6 sont prises en charge. Pour utiliser cette fonctionnalité, vous devez également spécifier { "ips": true } dans l'objet SriovIBNetwork.

Exemple de configuration d'exécution

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "ib1",
          "infiniband-guid": "c2:11:22:33:44:55:66:77",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "ib1",
          "infiniband-guid": "c2:11:22:33:44:55:66:77",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

Copy to Clipboard

Toggle word wrap

23.7.2. Ajouter un pod à un réseau supplémentaire
Copier lien

Vous pouvez ajouter un module à un réseau supplémentaire. Le pod continue à envoyer le trafic réseau normal lié au cluster sur le réseau par défaut.

Lorsqu'un module est créé, des réseaux supplémentaires lui sont rattachés. Toutefois, si un module existe déjà, il n'est pas possible d'y attacher des réseaux supplémentaires.

Le pod doit se trouver dans le même espace de noms que le réseau supplémentaire.

Note

L'injecteur de ressources réseau SR-IOV ajoute automatiquement le champ resource au premier conteneur d'un module.

Si vous utilisez un contrôleur d'interface réseau (NIC) Intel en mode DPDK (Data Plane Development Kit), seul le premier conteneur de votre pod est configuré pour accéder au NIC. Votre réseau supplémentaire SR-IOV est configuré pour le mode DPDK si deviceType est défini sur vfio-pci dans l'objet SriovNetworkNodePolicy.

Vous pouvez contourner ce problème en vous assurant que le conteneur qui a besoin d'accéder au NIC est le premier conteneur défini dans l'objet Pod ou en désactivant l'injecteur de ressources réseau. Pour plus d'informations, voir BZ#1990953.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous au cluster.
Installer l'opérateur SR-IOV.
Créez un objet SriovNetwork ou un objet SriovIBNetwork pour y attacher le pod.

Procédure

Ajouter une annotation à l'objet Pod. Un seul des formats d'annotation suivants peut être utilisé :
1. Pour attacher un réseau supplémentaire sans aucune personnalisation, ajoutez une annotation avec le format suivant. Remplacez <network> par le nom du réseau supplémentaire à associer au pod :
  metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]
  1
  Copy to Clipboard Toggle word wrap
  1
  Pour spécifier plus d'un réseau supplémentaire, séparez chaque réseau par une virgule. N'incluez pas d'espace entre les virgules. Si vous spécifiez plusieurs fois le même réseau supplémentaire, plusieurs interfaces réseau seront attachées à ce pod.
2. Pour joindre un réseau supplémentaire avec des personnalisations, ajoutez une annotation avec le format suivant :
  metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>",
  1
  "namespace": "<namespace>",
  2
  "default-route": ["<default-route>"]
  3
  } ]
  Copy to Clipboard Toggle word wrap
  1
  Indiquer le nom du réseau supplémentaire défini par un objet NetworkAttachmentDefinition.
  2
  Spécifier l'espace de noms dans lequel l'objet NetworkAttachmentDefinition est défini.
  3
  Facultatif : Spécifiez un remplacement de l'itinéraire par défaut, tel que 192.168.17.1.
Pour créer le module, entrez la commande suivante. Remplacez <name> par le nom du module.
```
oc create -f <name>.yaml
```
```
$ oc create -f <name>.yaml
```
Copy to Clipboard Toggle word wrap

Facultatif : Pour confirmer que l'annotation existe dans le CR Pod, entrez la commande suivante, en remplaçant <name> par le nom du module.

oc get pod <name> -o yaml

$ oc get pod <name> -o yaml

Copy to Clipboard

Toggle word wrap

Dans l'exemple suivant, le pod example-pod est rattaché au réseau supplémentaire net1:

oc get pod example-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-bridge
    k8s.v1.cni.cncf.io/networks-status: |-
      [{
          "name": "openshift-sdn",
          "interface": "eth0",
          "ips": [
              "10.128.2.14"
          ],
          "default": true,
          "dns": {}
      },{
          "name": "macvlan-bridge",
          "interface": "net1",
          "ips": [
              "20.2.2.100"
          ],
          "mac": "22:2f:60:a5:f8:00",
          "dns": {}
      }]
  name: example-pod
  namespace: default
spec:
  ...
status:
  ...

$ oc get pod example-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-bridge
    k8s.v1.cni.cncf.io/networks-status: |-

1


      [{
          "name": "openshift-sdn",
          "interface": "eth0",
          "ips": [
              "10.128.2.14"
          ],
          "default": true,
          "dns": {}
      },{
          "name": "macvlan-bridge",
          "interface": "net1",
          "ips": [
              "20.2.2.100"
          ],
          "mac": "22:2f:60:a5:f8:00",
          "dns": {}
      }]
  name: example-pod
  namespace: default
spec:
  ...
status:
  ...

Copy to Clipboard

Toggle word wrap

1: Le paramètre k8s.v1.cni.cncf.io/networks-status est un tableau JSON d'objets. Chaque objet décrit l'état d'un réseau supplémentaire attaché au pod. La valeur de l'annotation est stockée sous forme de texte brut.

23.7.3. Création d'un pod SR-IOV aligné sur un accès mémoire non uniforme (NUMA)
Copier lien

Vous pouvez créer un pod SR-IOV aligné NUMA en limitant le SR-IOV et les ressources CPU allouées à partir du même nœud NUMA avec restricted ou single-numa-node Topology Manager polices.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous avez configuré la politique du Gestionnaire de CPU sur static. Pour plus d'informations sur le gestionnaire de CPU, voir la section "Ressources supplémentaires".
Vous avez configuré la politique de Topology Manager sur single-numa-node.
Note
Lorsque single-numa-node n'est pas en mesure de satisfaire la demande, vous pouvez configurer la politique du gestionnaire de topologie pour restricted.

Procédure

Créez la spécification de pod SR-IOV suivante, puis enregistrez le YAML dans le fichier <name>-sriov-pod.yaml. Remplacez <name> par un nom pour ce pod.

L'exemple suivant montre une spécification de pod SR-IOV :

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: <name> 
spec:
  containers:
  - name: sample-container
    image: <image> 
    command: ["sleep", "infinity"]
    resources:
      limits:
        memory: "1Gi" 
        cpu: "2" 
      requests:
        memory: "1Gi"
        cpu: "2"

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: <name>

1


spec:
  containers:
  - name: sample-container
    image: <image>

2


    command: ["sleep", "infinity"]
    resources:
      limits:
        memory: "1Gi"

3


        cpu: "2"

4


      requests:
        memory: "1Gi"
        cpu: "2"

Copy to Clipboard

Toggle word wrap

1: Remplacer <name> par le nom de la définition de l'attachement au réseau SR-IOV CR.
2: Remplacez <image> par le nom de l'image sample-pod.
3: Pour créer le pod SR-IOV avec une garantie de qualité de service, définissez memory limits égal à memory requests.
4: Pour créer le pod SR-IOV avec une qualité de service garantie, définissez cpu limits égal à cpu requests.

Créez l'exemple de pod SR-IOV en exécutant la commande suivante :
```
oc create -f <filename>
```
```
$ oc create -f <filename> 
```
1
Copy to Clipboard Toggle word wrap
1
Remplacez <filename> par le nom du fichier que vous avez créé à l'étape précédente.
Confirmez que le site sample-pod est configuré avec une qualité de service garantie.
```
oc describe pod sample-pod
```
```
$ oc describe pod sample-pod
```
Copy to Clipboard Toggle word wrap
Confirmez que le site sample-pod est doté d'unités centrales exclusives.
```
oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
```
```
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
```
Copy to Clipboard Toggle word wrap
Confirmez que le dispositif SR-IOV et les CPU alloués à l'adresse sample-pod se trouvent sur le même nœud NUMA.
```
oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
```
```
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
```
Copy to Clipboard Toggle word wrap

23.7.4. Un modèle de pod de test pour les clusters qui utilisent SR-IOV sur OpenStack
Copier lien

Le pod testpmd suivant illustre la création d'un conteneur avec des pages énormes, des unités centrales réservées et le port SR-IOV.

Un exemple de pod testpmd

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/sriov1: 1
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/sriov1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile 
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/sriov1: 1
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/sriov1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile

1


  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Copy to Clipboard

Toggle word wrap

1: Cet exemple suppose que le nom du profil de performance est cnf-performance profile.

23.8. Configuration des paramètres sysctl du réseau au niveau de l'interface pour les réseaux SR-IOV
Copier lien

En tant qu'administrateur de cluster, vous pouvez modifier les sysctls de réseau au niveau de l'interface à l'aide du méta plugin Tuning Container Network Interface (CNI) pour un pod connecté à un périphérique réseau SR-IOV.

23.8.1. Étiquetage des nœuds dotés d'une carte d'interface réseau compatible SR-IOV
Copier lien

Si vous souhaitez activer SR-IOV uniquement sur les nœuds capables de le faire, il existe plusieurs façons de procéder :

Installez l'opérateur NFD (Node Feature Discovery). NFD détecte la présence de cartes d'interface réseau compatibles SR-IOV et étiquette les nœuds avec node.alpha.kubernetes-incubator.io/nfd-network-sriov.capable = true.
Examinez le CR SriovNetworkNodeState pour chaque nœud. La strophe interfaces comprend une liste de tous les dispositifs SR-IOV découverts par l'opérateur de réseau SR-IOV sur le nœud de travail. Étiquetez chaque nœud avec feature.node.kubernetes.io/network-sriov.capable: "true" à l'aide de la commande suivante :
```
$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
```
```
$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
```
Copy to Clipboard Toggle word wrap
Note
Vous pouvez donner aux nœuds le nom que vous souhaitez.

23.8.2. Définition d'un drapeau sysctl
Copier lien

Vous pouvez définir les paramètres du réseau sysctl au niveau de l'interface pour un pod connecté à un périphérique réseau SR-IOV.

Dans cet exemple, net.ipv4.conf.IFNAME.accept_redirects est défini sur 1 sur les interfaces virtuelles créées.

Le site sysctl-tuning-test est un espace de noms utilisé dans cet exemple.

Utilisez la commande suivante pour créer l'espace de noms sysctl-tuning-test:
```
oc create namespace sysctl-tuning-test
```
```
$ oc create namespace sysctl-tuning-test
```
Copy to Clipboard Toggle word wrap

23.8.2.1. Définition d'un drapeau sysctl sur les nœuds dotés de périphériques réseau SR-IOV
Copier lien

L'opérateur de réseau SR-IOV ajoute la définition de ressource personnalisée (CRD) SriovNetworkNodePolicy.sriovnetwork.openshift.io à OpenShift Container Platform. Vous pouvez configurer un périphérique réseau SR-IOV en créant une ressource personnalisée (CR) SriovNetworkNodePolicy.

Note

Lors de l'application de la configuration spécifiée dans un objet SriovNetworkNodePolicy, l'opérateur SR-IOV peut vidanger et redémarrer les nœuds.

L'application d'une modification de configuration peut prendre plusieurs minutes.

Suivez cette procédure pour créer une ressource personnalisée (CR) SriovNetworkNodePolicy.

Procédure

Créez une ressource personnalisée (CR) SriovNetworkNodePolicy. Par exemple, enregistrez le YAML suivant dans le fichier policyoneflag-sriov-node-network.yaml:
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policyoneflag 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: policyoneflag 
  nodeSelector: 
    feature.node.kubernetes.io/network-sriov.capable="true"
  priority: 10 
  numVfs: 5 
  nicSelector: 
    pfNames: ["ens5"] 
  deviceType: "netdevice" 
  isRdma: false 
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policyoneflag 
```
1
```
  namespace: openshift-sriov-network-operator 
```
2
```
spec:
  resourceName: policyoneflag 
```
3
```
  nodeSelector: 
```
4
```
    feature.node.kubernetes.io/network-sriov.capable="true"
  priority: 10 
```
5
```
  numVfs: 5 
```
6
```
  nicSelector: 
```
7
```
    pfNames: ["ens5"] 
```
8
```
  deviceType: "netdevice" 
```
9
```
  isRdma: false 
```
10
Copy to Clipboard Toggle word wrap
1
Nom de l'objet ressource personnalisé.
2
L'espace de noms dans lequel l'opérateur de réseau SR-IOV est installé.
3
Le nom de la ressource du plugin de périphérique réseau SR-IOV. Vous pouvez créer plusieurs stratégies de nœuds de réseau SR-IOV pour un nom de ressource.
4
Le sélecteur de nœuds indique les nœuds à configurer. Seuls les périphériques de réseau SR-IOV sur les nœuds sélectionnés sont configurés. Le plugin SR-IOV Container Network Interface (CNI) et le plugin de périphérique sont déployés sur les nœuds sélectionnés uniquement.
5
Facultatif : La priorité est une valeur entière comprise entre 0 et 99. Plus la valeur est petite, plus la priorité est élevée. Par exemple, une priorité de 10 est plus élevée que celle de 99. La valeur par défaut est 99.
6
Le nombre de fonctions virtuelles (VF) à créer pour le périphérique de réseau physique SR-IOV. Pour un contrôleur d'interface réseau (NIC) Intel, le nombre de VF ne peut pas être supérieur au nombre total de VF pris en charge par le périphérique. Pour un NIC Mellanox, le nombre de VF ne peut pas être supérieur à 128.
7
Le sélecteur NIC identifie le dispositif à configurer par l'opérateur. Il n'est pas nécessaire de spécifier des valeurs pour tous les paramètres. Il est recommandé d'identifier le périphérique réseau avec suffisamment de précision pour éviter de sélectionner un périphérique par inadvertance. Si vous spécifiez rootDevices, vous devez également spécifier une valeur pour vendor, deviceID ou pfNames. Si vous spécifiez pfNames et rootDevices en même temps, assurez-vous qu'ils se réfèrent au même dispositif. Si vous spécifiez une valeur pour netFilter, il n'est pas nécessaire de spécifier d'autres paramètres car un ID de réseau est unique.
8
Facultatif : Un tableau d'un ou plusieurs noms de fonctions physiques (PF) pour l'appareil.
9
Facultatif : Le type de pilote pour les fonctions virtuelles. La seule valeur autorisée est netdevice. Pour qu'une carte d'interface réseau Mellanox fonctionne en mode DPDK sur des nœuds métalliques nus, définissez isRdma sur true.
10
Facultatif : Permet d'activer ou non le mode d'accès direct à la mémoire à distance (RDMA). La valeur par défaut est false. Si le paramètre isRdma est défini sur true, vous pouvez continuer à utiliser le VF compatible RDMA comme un périphérique réseau normal. Un périphérique peut être utilisé dans l'un ou l'autre mode. Définissez isRdma sur true et needVhostNet sur true pour configurer une carte d'interface réseau Mellanox à utiliser avec les applications Fast Datapath DPDK.
Note
Le type de pilote vfio-pci n'est pas pris en charge.
Créer l'objet SriovNetworkNodePolicy:
```
oc create -f policyoneflag-sriov-node-network.yaml
```
```
$ oc create -f policyoneflag-sriov-node-network.yaml
```
Copy to Clipboard Toggle word wrap
Après avoir appliqué la mise à jour de la configuration, tous les pods de l'espace de noms sriov-network-operator passent à l'état Running.
Pour vérifier que le dispositif de réseau SR-IOV est configuré, entrez la commande suivante. Remplacez <node_name> par le nom d'un nœud avec le dispositif de réseau SR-IOV que vous venez de configurer.
```
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
```
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
Succeeded
```
```
Succeeded
```
Copy to Clipboard Toggle word wrap

23.8.2.2. Configuration de sysctl sur un réseau SR-IOV
Copier lien

Vous pouvez définir des paramètres sysctl spécifiques à l'interface sur les interfaces virtuelles créées par SR-IOV en ajoutant la configuration de réglage au paramètre facultatif metaPlugins de la ressource SriovNetwork.

L'opérateur de réseau SR-IOV gère les définitions de réseaux supplémentaires. Lorsque vous indiquez un réseau SR-IOV supplémentaire à créer, l'opérateur de réseau SR-IOV crée automatiquement la ressource personnalisée (CR) NetworkAttachmentDefinition.

Note

Ne modifiez pas les ressources personnalisées NetworkAttachmentDefinition gérées par l'opérateur de réseau SR-IOV. Cela pourrait perturber le trafic sur votre réseau supplémentaire.

Pour modifier les paramètres du réseau au niveau de l'interface net.ipv4.conf.IFNAME.accept_redirects sysctl , créez un réseau SR-IOV supplémentaire avec le plugin de réglage Container Network Interface (CNI).

Conditions préalables

Installez le CLI (oc) de OpenShift Container Platform.
Connectez-vous au cluster OpenShift Container Platform en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créez la ressource personnalisée (CR) SriovNetwork pour l'attachement supplémentaire au réseau SR-IOV et insérez la configuration metaPlugins, comme dans l'exemple de CR suivant. Enregistrez le YAML dans le fichier sriov-network-interface-sysctl.yaml.
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: onevalidflag 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: policyoneflag 
  networkNamespace: sysctl-tuning-test 
  ipam: '{ "type": "static" }' 
  capabilities: '{ "mac": true, "ips": true }' 
  metaPlugins : | 
    {
      "type": "tuning",
      "capabilities":{
        "mac":true
      },
      "sysctl":{
         "net.ipv4.conf.IFNAME.accept_redirects": "1"
      }
    }
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: onevalidflag 
```
1
```
  namespace: openshift-sriov-network-operator 
```
2
```
spec:
  resourceName: policyoneflag 
```
3
```
  networkNamespace: sysctl-tuning-test 
```
4
```
  ipam: '{ "type": "static" }' 
```
5
```
  capabilities: '{ "mac": true, "ips": true }' 
```
6
```
  metaPlugins : | 
```
7
```
    {
      "type": "tuning",
      "capabilities":{
        "mac":true
      },
      "sysctl":{
         "net.ipv4.conf.IFNAME.accept_redirects": "1"
      }
    }
```
Copy to Clipboard Toggle word wrap
1
Un nom pour l'objet. L'opérateur de réseau SR-IOV crée un objet NetworkAttachmentDefinition portant le même nom.
2
L'espace de noms dans lequel l'opérateur de réseau SR-IOV est installé.
3
La valeur du paramètre spec.resourceName de l'objet SriovNetworkNodePolicy qui définit le matériel SR-IOV pour ce réseau supplémentaire.
4
L'espace de noms cible pour l'objet SriovNetwork. Seuls les pods de l'espace de noms cible peuvent s'attacher au réseau supplémentaire.
5
Un objet de configuration pour le plugin IPAM CNI sous la forme d'un bloc YAML scalaire. Le plugin gère l'attribution des adresses IP pour la définition de l'attachement.
6
Optionnel : Définissez les capacités du réseau supplémentaire. Vous pouvez spécifier "{ "ips": true }" pour activer la prise en charge des adresses IP ou "{ "mac": true }" pour activer la prise en charge des adresses MAC.
7
Facultatif : Le paramètre metaPlugins est utilisé pour ajouter des capacités supplémentaires à l'appareil. Dans ce cas d'utilisation, réglez le champ type sur tuning. Spécifiez le réseau au niveau de l'interface sysctl que vous souhaitez définir dans le champ sysctl.

Créer la ressource SriovNetwork:

oc create -f sriov-network-interface-sysctl.yaml

$ oc create -f sriov-network-interface-sysctl.yaml

Copy to Clipboard

Toggle word wrap

Vérification de la création de la CR NetworkAttachmentDefinition

Confirmez que l'opérateur du réseau SR-IOV a créé le CR NetworkAttachmentDefinition en exécutant la commande suivante :
```
oc get network-attachment-definitions -n <namespace> 
```
```
oc get network-attachment-definitions -n <namespace> 
```
1
Copy to Clipboard Toggle word wrap
1
Remplacez <namespace> par la valeur de networkNamespace que vous avez spécifiée dans l'objet SriovNetwork. Par exemple, sysctl-tuning-test.
Exemple de sortie
```
NAME                                  AGE
onevalidflag                          14m
```
```
NAME                                  AGE
onevalidflag                          14m
```
Copy to Clipboard Toggle word wrap
Note
Il peut y avoir un délai avant que l'opérateur du réseau SR-IOV ne crée le CR.

Vérification de la réussite de l'attachement au réseau SR-IOV supplémentaire

Pour vérifier que le CNI d'accord est correctement configuré et que l'attachement réseau SR-IOV supplémentaire est attaché, procédez comme suit :

Créez un CR Pod. Enregistrez le YAML suivant dans le fichier examplepod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: sysctl-tuning-test
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "onevalidflag",  
          "mac": "0a:56:0a:83:04:0c", 
          "ips": ["10.100.100.200/24"] 
       }
      ]
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: sysctl-tuning-test
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "onevalidflag",

1


          "mac": "0a:56:0a:83:04:0c",

2


          "ips": ["10.100.100.200/24"]

3


       }
      ]
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

Copy to Clipboard

Toggle word wrap

1: Le nom du CR de définition de l'attachement au réseau SR-IOV.
2: Facultatif : L'adresse MAC de l'appareil SR-IOV qui est allouée à partir du type de ressource défini dans la définition de l'attachement au réseau SR-IOV CR. Pour utiliser cette fonctionnalité, vous devez également spécifier { "mac": true } dans l'objet SriovNetwork.
3: Facultatif : adresses IP pour le périphérique SR-IOV qui sont allouées à partir du type de ressource défini dans le CR de définition de l'attachement au réseau SR-IOV. Les adresses IPv4 et IPv6 sont prises en charge. Pour utiliser cette fonctionnalité, vous devez également spécifier { "ips": true } dans l'objet SriovNetwork.

Créer le CR Pod:
```
oc apply -f examplepod.yaml
```
```
$ oc apply -f examplepod.yaml
```
Copy to Clipboard Toggle word wrap

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

oc get pod -n sysctl-tuning-test

$ oc get pod -n sysctl-tuning-test

Copy to Clipboard

Toggle word wrap

Exemple de sortie

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

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

Copy to Clipboard

Toggle word wrap

Connectez-vous au module en exécutant la commande suivante :
```
oc rsh -n sysctl-tuning-test tunepod
```
```
$ oc rsh -n sysctl-tuning-test tunepod
```
Copy to Clipboard Toggle word wrap
Vérifiez les valeurs de l'indicateur sysctl configuré. Trouvez la valeur net.ipv4.conf.IFNAME.accept_redirects en exécutant la commande suivante: :
```
sysctl net.ipv4.conf.net1.accept_redirects
```
```
$ sysctl net.ipv4.conf.net1.accept_redirects
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
net.ipv4.conf.net1.accept_redirects = 1
```
```
net.ipv4.conf.net1.accept_redirects = 1
```
Copy to Clipboard Toggle word wrap

23.8.3. Configuration des paramètres sysctl pour les pods associés au drapeau d'interface SR-IOV lié
Copier lien

Vous pouvez définir les paramètres du réseau sysctl au niveau de l'interface pour un pod connecté à un périphérique réseau SR-IOV lié.

Dans cet exemple, les paramètres spécifiques au niveau de l'interface réseau sysctl qui peuvent être configurés sont définis sur l'interface liée.

Le site sysctl-tuning-test est un espace de noms utilisé dans cet exemple.

Utilisez la commande suivante pour créer l'espace de noms sysctl-tuning-test:
```
oc create namespace sysctl-tuning-test
```
```
$ oc create namespace sysctl-tuning-test
```
Copy to Clipboard Toggle word wrap

23.8.3.1. Définition de tous les drapeaux sysctl sur les nœuds avec des périphériques de réseau SR-IOV liés
Copier lien

L'opérateur de réseau SR-IOV ajoute la définition de ressource personnalisée (CRD) SriovNetworkNodePolicy.sriovnetwork.openshift.io à OpenShift Container Platform. Vous pouvez configurer un périphérique réseau SR-IOV en créant une ressource personnalisée (CR) SriovNetworkNodePolicy.

Note

Lors de l'application de la configuration spécifiée dans un objet SriovNetworkNodePolicy, l'opérateur SR-IOV peut vidanger les nœuds et, dans certains cas, les redémarrer.

L'application d'une modification de configuration peut prendre plusieurs minutes.

Suivez cette procédure pour créer une ressource personnalisée (CR) SriovNetworkNodePolicy.

Procédure

Créez une ressource personnalisée (CR) SriovNetworkNodePolicy. Enregistrez le YAML suivant dans le fichier policyallflags-sriov-node-network.yaml. Remplacez policyallflags par le nom de la configuration.
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policyallflags 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: policyallflags 
  nodeSelector: 
    node.alpha.kubernetes-incubator.io/nfd-network-sriov.capable = `true`
  priority: 10 
  numVfs: 5 
  nicSelector: 
    pfNames: ["ens1f0"]  
  deviceType: "netdevice" 
  isRdma: false 
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policyallflags 
```
1
```
  namespace: openshift-sriov-network-operator 
```
2
```
spec:
  resourceName: policyallflags 
```
3
```
  nodeSelector: 
```
4
```
    node.alpha.kubernetes-incubator.io/nfd-network-sriov.capable = `true`
  priority: 10 
```
5
```
  numVfs: 5 
```
6
```
  nicSelector: 
```
7
```
    pfNames: ["ens1f0"]  
```
8
```
  deviceType: "netdevice" 
```
9
```
  isRdma: false 
```
10
Copy to Clipboard Toggle word wrap
1
Nom de l'objet ressource personnalisé.
2
L'espace de noms dans lequel l'opérateur de réseau SR-IOV est installé.
3
Le nom de la ressource du plugin de périphérique réseau SR-IOV. Vous pouvez créer plusieurs stratégies de nœuds de réseau SR-IOV pour un nom de ressource.
4
Le sélecteur de nœuds indique les nœuds à configurer. Seuls les périphériques de réseau SR-IOV sur les nœuds sélectionnés sont configurés. Le plugin SR-IOV Container Network Interface (CNI) et le plugin de périphérique sont déployés sur les nœuds sélectionnés uniquement.
5
Facultatif : La priorité est une valeur entière comprise entre 0 et 99. Plus la valeur est petite, plus la priorité est élevée. Par exemple, une priorité de 10 est plus élevée que celle de 99. La valeur par défaut est 99.
6
Nombre de fonctions virtuelles (VF) à créer pour le périphérique réseau physique SR-IOV. Pour un contrôleur d'interface réseau (NIC) Intel, le nombre de VF ne peut pas être supérieur au nombre total de VF pris en charge par le périphérique. Pour un NIC Mellanox, le nombre de VF ne peut pas être supérieur à 128.
7
Le sélecteur NIC identifie le dispositif à configurer par l'opérateur. Il n'est pas nécessaire de spécifier des valeurs pour tous les paramètres. Il est recommandé d'identifier le périphérique réseau avec suffisamment de précision pour éviter de sélectionner un périphérique par inadvertance. Si vous spécifiez rootDevices, vous devez également spécifier une valeur pour vendor, deviceID ou pfNames. Si vous spécifiez pfNames et rootDevices en même temps, assurez-vous qu'ils se réfèrent au même dispositif. Si vous spécifiez une valeur pour netFilter, il n'est pas nécessaire de spécifier d'autres paramètres car un ID de réseau est unique.
8
Facultatif : Un tableau d'un ou plusieurs noms de fonctions physiques (PF) pour l'appareil.
9
Facultatif : Le type de pilote pour les fonctions virtuelles. La seule valeur autorisée est netdevice. Pour qu'une carte d'interface réseau Mellanox fonctionne en mode DPDK sur des nœuds métalliques nus, définissez isRdma sur true.
10
Facultatif : Permet d'activer ou non le mode d'accès direct à la mémoire à distance (RDMA). La valeur par défaut est false. Si le paramètre isRdma est défini sur true, vous pouvez continuer à utiliser le VF compatible RDMA comme un périphérique réseau normal. Un périphérique peut être utilisé dans l'un ou l'autre mode. Définissez isRdma sur true et needVhostNet sur true pour configurer une carte d'interface réseau Mellanox à utiliser avec les applications Fast Datapath DPDK.
Note
Le type de pilote vfio-pci n'est pas pris en charge.
Créer l'objet SriovNetworkNodePolicy :
```
oc create -f policyallflags-sriov-node-network.yaml
```
```
$ oc create -f policyallflags-sriov-node-network.yaml
```
Copy to Clipboard Toggle word wrap
Après avoir appliqué la mise à jour de la configuration, tous les pods de l'espace de noms sriov-network-operator passent à l'état Running.
Pour vérifier que le dispositif de réseau SR-IOV est configuré, entrez la commande suivante. Remplacez <node_name> par le nom d'un nœud avec le dispositif de réseau SR-IOV que vous venez de configurer.
```
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
```
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
Succeeded
```
```
Succeeded
```
Copy to Clipboard Toggle word wrap

23.8.3.2. Configuration de sysctl sur un réseau SR-IOV lié
Copier lien

Vous pouvez définir des paramètres sysctl spécifiques à l'interface sur une interface liée créée à partir de deux interfaces SR-IOV. Pour ce faire, ajoutez la configuration de réglage au paramètre facultatif Plugins de la définition de l'attachement au réseau de liaison.

Note

Ne modifiez pas les ressources personnalisées NetworkAttachmentDefinition gérées par l'opérateur de réseau SR-IOV. Cela pourrait perturber le trafic sur votre réseau supplémentaire.

Pour modifier des paramètres réseau spécifiques au niveau de l'interface sysctl, créez la ressource personnalisée (CR) SriovNetwork avec le plugin de réglage Container Network Interface (CNI) en suivant la procédure suivante.

Conditions préalables

Installez le CLI (oc) de OpenShift Container Platform.
Connectez-vous au cluster OpenShift Container Platform en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créez la ressource personnalisée (CR) SriovNetwork pour l'interface liée, comme dans l'exemple de CR suivant. Enregistrez le YAML dans le fichier sriov-network-attachment.yaml.
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: allvalidflags 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: policyallflags 
  networkNamespace: sysctl-tuning-test 
  capabilities: '{ "mac": true, "ips": true }' 
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: allvalidflags 
```
1
```
  namespace: openshift-sriov-network-operator 
```
2
```
spec:
  resourceName: policyallflags 
```
3
```
  networkNamespace: sysctl-tuning-test 
```
4
```
  capabilities: '{ "mac": true, "ips": true }' 
```
5
Copy to Clipboard Toggle word wrap
1
Un nom pour l'objet. L'opérateur de réseau SR-IOV crée un objet NetworkAttachmentDefinition portant le même nom.
2
L'espace de noms dans lequel l'opérateur de réseau SR-IOV est installé.
3
La valeur du paramètre spec.resourceName de l'objet SriovNetworkNodePolicy qui définit le matériel SR-IOV pour ce réseau supplémentaire.
4
L'espace de noms cible pour l'objet SriovNetwork. Seuls les pods de l'espace de noms cible peuvent s'attacher au réseau supplémentaire.
5
Facultatif : Les capacités à configurer pour ce réseau supplémentaire. Vous pouvez spécifier "{ "ips": true }" pour activer la prise en charge des adresses IP ou "{ "mac": true }" pour activer la prise en charge des adresses MAC.

Créer la ressource SriovNetwork:

oc create -f sriov-network-attachment.yaml

$ oc create -f sriov-network-attachment.yaml

Copy to Clipboard

Toggle word wrap

Créez une définition d'attachement au réseau de liens comme dans l'exemple suivant CR. Enregistrez le YAML dans le fichier sriov-bond-network-interface.yaml.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: bond-sysctl-network
  namespace: sysctl-tuning-test
spec:
  config: '{
  "cniVersion":"0.4.0",
  "name":"bound-net",
  "plugins":[
    {
      "type":"bond", 
      "mode": "active-backup", 
      "failOverMac": 1, 
      "linksInContainer": true, 
      "miimon": "100",
      "links": [ 
        {"name": "net1"},
        {"name": "net2"}
      ],
      "ipam":{ 
        "type":"static"
      }
    },
    {
      "type":"tuning", 
      "capabilities":{
        "mac":true
      },
      "sysctl":{
        "net.ipv4.conf.IFNAME.accept_redirects": "0",
        "net.ipv4.conf.IFNAME.accept_source_route": "0",
        "net.ipv4.conf.IFNAME.disable_policy": "1",
        "net.ipv4.conf.IFNAME.secure_redirects": "0",
        "net.ipv4.conf.IFNAME.send_redirects": "0",
        "net.ipv6.conf.IFNAME.accept_redirects": "0",
        "net.ipv6.conf.IFNAME.accept_source_route": "1",
        "net.ipv6.neigh.IFNAME.base_reachable_time_ms": "20000",
        "net.ipv6.neigh.IFNAME.retrans_time_ms": "2000"
      }
    }
  ]
}'

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: bond-sysctl-network
  namespace: sysctl-tuning-test
spec:
  config: '{
  "cniVersion":"0.4.0",
  "name":"bound-net",
  "plugins":[
    {
      "type":"bond",

1


      "mode": "active-backup",

2


      "failOverMac": 1,

3


      "linksInContainer": true,

4


      "miimon": "100",
      "links": [

5


        {"name": "net1"},
        {"name": "net2"}
      ],
      "ipam":{

6


        "type":"static"
      }
    },
    {
      "type":"tuning",

7


      "capabilities":{
        "mac":true
      },
      "sysctl":{
        "net.ipv4.conf.IFNAME.accept_redirects": "0",
        "net.ipv4.conf.IFNAME.accept_source_route": "0",
        "net.ipv4.conf.IFNAME.disable_policy": "1",
        "net.ipv4.conf.IFNAME.secure_redirects": "0",
        "net.ipv4.conf.IFNAME.send_redirects": "0",
        "net.ipv6.conf.IFNAME.accept_redirects": "0",
        "net.ipv6.conf.IFNAME.accept_source_route": "1",
        "net.ipv6.neigh.IFNAME.base_reachable_time_ms": "20000",
        "net.ipv6.neigh.IFNAME.retrans_time_ms": "2000"
      }
    }
  ]
}'

Copy to Clipboard

Toggle word wrap

Le type est bond.

L'attribut mode spécifie le mode de liaison. Les modes de liaison pris en charge sont les suivants :

balance-rr - 0
active-backup - 1
balance-xor - 2
Pour les modes balance-rr ou balance-xor, vous devez définir le mode trust sur on pour la fonction virtuelle SR-IOV.

L'attribut failover est obligatoire pour le mode de sauvegarde active.

4

Le drapeau linksInContainer=true informe le Bond CNI que les interfaces requises doivent être trouvées à l'intérieur du conteneur. Par défaut, Bond CNI recherche ces interfaces sur l'hôte, ce qui ne fonctionne pas pour l'intégration avec SRIOV et Multus.

5

La section links définit les interfaces qui seront utilisées pour créer le lien. Par défaut, Multus nomme les interfaces attachées comme suit : \N "net\N", plus un nombre consécutif, en commençant par un.

6

Un objet de configuration pour le plugin IPAM CNI sous la forme d'un bloc YAML scalaire. Le plugin gère l'attribution des adresses IP pour la définition de l'attachement. Dans cet exemple de pod, les adresses IP sont configurées manuellement, donc dans ce cas,ipam est défini comme statique.

7

Ajoutez des capacités supplémentaires à l'appareil. Par exemple, définissez le champ type sur tuning. Spécifiez le réseau au niveau de l'interface sysctl que vous souhaitez définir dans le champ sysctl. Cet exemple définit tous les paramètres de réseau au niveau de l'interface sysctl qui peuvent être définis.

Créer la ressource de rattachement au réseau de liens :
```
oc create -f sriov-bond-network-interface.yaml
```
```
$ oc create -f sriov-bond-network-interface.yaml
```
Copy to Clipboard Toggle word wrap

Vérification de la création de la CR NetworkAttachmentDefinition

Confirmez que l'opérateur du réseau SR-IOV a créé le CR NetworkAttachmentDefinition en exécutant la commande suivante :
```
oc get network-attachment-definitions -n <namespace> 
```
```
oc get network-attachment-definitions -n <namespace> 
```
1
Copy to Clipboard Toggle word wrap
1
Remplacez <namespace> par le networkNamespace que vous avez spécifié lors de la configuration de l'attachement au réseau, par exemple, sysctl-tuning-test.
Exemple de sortie
```
NAME                          AGE
bond-sysctl-network           22m
allvalidflags                 47m
```
```
NAME                          AGE
bond-sysctl-network           22m
allvalidflags                 47m
```
Copy to Clipboard Toggle word wrap
Note
Il peut y avoir un délai avant que l'opérateur du réseau SR-IOV ne crée le CR.

Vérification du succès de la ressource réseau SR-IOV supplémentaire

Pour vérifier que le CNI d'accord est correctement configuré et que l'attachement réseau SR-IOV supplémentaire est attaché, procédez comme suit :

Créez un CR Pod. Par exemple, enregistrez le YAML suivant dans le fichier examplepod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: sysctl-tuning-test
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {"name": "allvalidflags"}, 
        {"name": "allvalidflags"},
        {
          "name": "bond-sysctl-network",
          "interface": "bond0",
          "mac": "0a:56:0a:83:04:0c", 
          "ips": ["10.100.100.200/24"] 
       }
      ]
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: sysctl-tuning-test
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {"name": "allvalidflags"},

1


        {"name": "allvalidflags"},
        {
          "name": "bond-sysctl-network",
          "interface": "bond0",
          "mac": "0a:56:0a:83:04:0c",

2


          "ips": ["10.100.100.200/24"]

3


       }
      ]
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

Copy to Clipboard

Toggle word wrap

1: Le nom du CR de définition de l'attachement au réseau SR-IOV.
2: Facultatif : L'adresse MAC de l'appareil SR-IOV qui est allouée à partir du type de ressource défini dans la définition de l'attachement au réseau SR-IOV CR. Pour utiliser cette fonctionnalité, vous devez également spécifier { "mac": true } dans l'objet SriovNetwork.
3: Facultatif : adresses IP pour le périphérique SR-IOV qui sont allouées à partir du type de ressource défini dans le CR de définition de l'attachement au réseau SR-IOV. Les adresses IPv4 et IPv6 sont prises en charge. Pour utiliser cette fonctionnalité, vous devez également spécifier { "ips": true } dans l'objet SriovNetwork.

Appliquer le YAML :
```
oc apply -f examplepod.yaml
```
```
$ oc apply -f examplepod.yaml
```
Copy to Clipboard Toggle word wrap

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

oc get pod -n sysctl-tuning-test

$ oc get pod -n sysctl-tuning-test

Copy to Clipboard

Toggle word wrap

Exemple de sortie

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

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

Copy to Clipboard

Toggle word wrap

Connectez-vous au module en exécutant la commande suivante :
```
oc rsh -n sysctl-tuning-test tunepod
```
```
$ oc rsh -n sysctl-tuning-test tunepod
```
Copy to Clipboard Toggle word wrap
Vérifiez les valeurs de l'indicateur sysctl configuré. Trouvez la valeur net.ipv6.neigh.IFNAME.base_reachable_time_ms en exécutant la commande suivante: :
```
sysctl net.ipv6.neigh.bond0.base_reachable_time_ms
```
```
$ sysctl net.ipv6.neigh.bond0.base_reachable_time_ms
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
net.ipv6.neigh.bond0.base_reachable_time_ms = 20000
```
```
net.ipv6.neigh.bond0.base_reachable_time_ms = 20000
```
Copy to Clipboard Toggle word wrap

23.9. Utilisation de la multidiffusion haute performance
Copier lien

Vous pouvez utiliser le multicast sur votre réseau matériel de virtualisation d'E/S à racine unique (SR-IOV).

23.9.1. Multidiffusion haute performance
Copier lien

Le plugin réseau OpenShift SDN supporte le multicast entre les pods sur le réseau par défaut. Il est préférable de l'utiliser pour la coordination ou la découverte de services à faible bande passante, et non pour des applications à large bande passante. Pour les applications telles que le streaming média, comme la télévision sur protocole Internet (IPTV) et la vidéoconférence multipoint, vous pouvez utiliser du matériel de virtualisation d'E/S à racine unique (SR-IOV) pour fournir des performances quasi natives.

Lors de l'utilisation d'interfaces SR-IOV supplémentaires pour le multicast :

Les paquets de multidiffusion doivent être envoyés ou reçus par un pod via l'interface SR-IOV supplémentaire.
Le réseau physique qui connecte les interfaces SR-IOV décide du routage et de la topologie multicast, qui n'est pas contrôlée par OpenShift Container Platform.

23.9.2. Configuration d'une interface SR-IOV pour la multidiffusion
Copier lien

La procédure suivante crée un exemple d'interface SR-IOV pour le multicast.

Conditions préalables

Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster avec un utilisateur ayant le rôle cluster-admin.

Procédure

Créer un objet SriovNetworkNodePolicy:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-example
  namespace: openshift-sriov-network-operator
spec:
  resourceName: example
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "8086"
    pfNames: ['ens803f0']
    rootDevices: ['0000:86:00.0']

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-example
  namespace: openshift-sriov-network-operator
spec:
  resourceName: example
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "8086"
    pfNames: ['ens803f0']
    rootDevices: ['0000:86:00.0']

Copy to Clipboard

Toggle word wrap

Créer un objet SriovNetwork:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: net-example
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: default
  ipam: | 
    {
      "type": "host-local", 
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "routes": [
        {"dst": "224.0.0.0/5"},
        {"dst": "232.0.0.0/5"}
      ],
      "gateway": "10.56.217.1"
    }
  resourceName: example

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: net-example
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: default
  ipam: |

1


    {
      "type": "host-local",

2


      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "routes": [
        {"dst": "224.0.0.0/5"},
        {"dst": "232.0.0.0/5"}
      ],
      "gateway": "10.56.217.1"
    }
  resourceName: example

Copy to Clipboard

Toggle word wrap

1 2: Si vous choisissez de configurer DHCP en tant qu'IPAM, assurez-vous de fournir les routes par défaut suivantes via votre serveur DHCP : 224.0.0.0/5 et 232.0.0.0/5. Cela permet de remplacer la route multicast statique définie par le fournisseur de réseau par défaut.

Créer un pod avec une application multicast :

apiVersion: v1
kind: Pod
metadata:
  name: testpmd
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: nic1
spec:
  containers:
  - name: example
    image: rhel7:latest
    securityContext:
      capabilities:
        add: ["NET_ADMIN"] 
    command: [ "sleep", "infinity"]

apiVersion: v1
kind: Pod
metadata:
  name: testpmd
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: nic1
spec:
  containers:
  - name: example
    image: rhel7:latest
    securityContext:
      capabilities:
        add: ["NET_ADMIN"]

1


    command: [ "sleep", "infinity"]

Copy to Clipboard

Toggle word wrap

1: La capacité NET_ADMIN n'est requise que si votre application doit attribuer l'adresse IP multicast à l'interface SR-IOV. Dans le cas contraire, elle peut être omise.

23.10. Utilisation de DPDK et RDMA
Copier lien

L'application conteneurisée Data Plane Development Kit (DPDK) est prise en charge sur OpenShift Container Platform. Vous pouvez utiliser du matériel réseau de virtualisation d'E/S à racine unique (SR-IOV) avec le kit de développement du plan de données (DPDK) et avec l'accès direct à la mémoire à distance (RDMA).

Pour plus d'informations sur les appareils pris en charge, reportez-vous à la section Appareils pris en charge.

23.10.1. Utilisation d'une fonction virtuelle en mode DPDK avec un NIC Intel
Copier lien

Conditions préalables

Installez le CLI OpenShift (oc).
Installer l'opérateur de réseau SR-IOV.
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créez l'objet SriovNetworkNodePolicy suivant, puis enregistrez le YAML dans le fichier intel-dpdk-node-policy.yaml.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: intel-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: intelnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "8086"
    deviceID: "158b"
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: vfio-pci

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: intel-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: intelnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "8086"
    deviceID: "158b"
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: vfio-pci

1

Copy to Clipboard

Toggle word wrap

1: Spécifiez le type de pilote pour les fonctions virtuelles à vfio-pci.

Note

Voir la section Configuring SR-IOV network devices pour une explication détaillée de chaque option de SriovNetworkNodePolicy.

Lors de l'application de la configuration spécifiée dans un objet SriovNetworkNodePolicy, l'opérateur SR-IOV peut vidanger les nœuds et, dans certains cas, les redémarrer. L'application d'une modification de configuration peut prendre plusieurs minutes. Assurez-vous au préalable qu'il y a suffisamment de nœuds disponibles dans votre cluster pour gérer la charge de travail expulsée.

Après l'application de la mise à jour de la configuration, tous les pods de l'espace de noms openshift-sriov-network-operator passeront à l'état Running.

Créez l'objet SriovNetworkNodePolicy en exécutant la commande suivante :
```
oc create -f intel-dpdk-node-policy.yaml
```
```
$ oc create -f intel-dpdk-node-policy.yaml
```
Copy to Clipboard Toggle word wrap
Créez l'objet SriovNetwork suivant, puis enregistrez le YAML dans le fichier intel-dpdk-network.yaml.
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: intel-dpdk-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |-
# ... 
  vlan: <vlan>
  resourceName: intelnics
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: intel-dpdk-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |-
# ... 
```
1
```
  vlan: <vlan>
  resourceName: intelnics
```
Copy to Clipboard Toggle word wrap
1
Spécifier un objet de configuration pour le plugin CNI ipam sous la forme d'un bloc YAML scalaire. Le plugin gère l'attribution des adresses IP pour la définition des pièces jointes.
Note
Voir la section "Configuration du réseau supplémentaire SR-IOV" pour une explication détaillée de chaque option sur SriovNetwork.
Une bibliothèque optionnelle, app-netutil, fournit plusieurs méthodes API pour collecter des informations réseau sur le pod parent d'un conteneur.
Créez l'objet SriovNetwork en exécutant la commande suivante :
```
oc create -f intel-dpdk-network.yaml
```
```
$ oc create -f intel-dpdk-network.yaml
```
Copy to Clipboard Toggle word wrap
Créez la spécification Pod suivante, puis enregistrez le YAML dans le fichier intel-dpdk-pod.yaml.
```
apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  namespace: <target_namespace> 
  annotations:
    k8s.v1.cni.cncf.io/networks: intel-dpdk-network
spec:
  containers:
  - name: testpmd
    image: <DPDK_image> 
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    volumeMounts:
    - mountPath: /dev/hugepages 
      name: hugepage
    resources:
      limits:
        openshift.io/intelnics: "1" 
        memory: "1Gi"
        cpu: "4" 
        hugepages-1Gi: "4Gi" 
      requests:
        openshift.io/intelnics: "1"
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
```
```
apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  namespace: <target_namespace> 
```
1
```
  annotations:
    k8s.v1.cni.cncf.io/networks: intel-dpdk-network
spec:
  containers:
  - name: testpmd
    image: <DPDK_image> 
```
2
```
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
```
3
```
    volumeMounts:
    - mountPath: /dev/hugepages 
```
4
```
      name: hugepage
    resources:
      limits:
        openshift.io/intelnics: "1" 
```
5
```
        memory: "1Gi"
        cpu: "4" 
```
6
```
        hugepages-1Gi: "4Gi" 
```
7
```
      requests:
        openshift.io/intelnics: "1"
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
```
Copy to Clipboard Toggle word wrap
1
Spécifiez le même target_namespace où l'objet SriovNetwork intel-dpdk-network est créé. Si vous souhaitez créer le pod dans un espace de noms différent, modifiez target_namespace à la fois dans la spécification Pod et dans l'objet SriovNetowrk.
2
Spécifiez l'image DPDK qui inclut votre application et la bibliothèque DPDK utilisée par l'application.
3
Spécifier les capacités supplémentaires requises par l'application à l'intérieur du conteneur pour l'allocation de pages énormes, l'allocation de ressources système et l'accès à l'interface réseau.
4
Monter un volume hugepage sur le pod DPDK sous /dev/hugepages. Le volume hugepage est soutenu par le type de volume emptyDir, le support étant Hugepages.
5
Facultatif : Spécifiez le nombre de dispositifs DPDK alloués au pod DPDK. Cette demande de ressource et cette limite, si elles ne sont pas explicitement spécifiées, seront automatiquement ajoutées par l'injecteur de ressources du réseau SR-IOV. L'injecteur de ressources réseau SR-IOV est un composant du contrôleur d'admission géré par l'opérateur SR-IOV. Il est activé par défaut et peut être désactivé en définissant l'option enableInjector sur false dans le CR SriovOperatorConfig par défaut.
6
Spécifiez le nombre d'unités centrales. Le pod DPDK nécessite généralement que des CPU exclusifs soient alloués par le kubelet. Pour ce faire, définissez la politique du gestionnaire de CPU sur static et créez un pod avec Guaranteed QoS.
7
Spécifiez la taille de la page d'accueil hugepages-1Gi ou hugepages-2Mi et la quantité de pages d'accueil qui seront allouées au module DPDK. Configurez 2Mi et 1Gi hugepages séparément. La configuration de la page d'accueil 1Gi nécessite l'ajout d'arguments de noyau aux nœuds. Par exemple, l'ajout des arguments du noyau default_hugepagesz=1GB, hugepagesz=1G et hugepages=16 aura pour effet d'allouer 16*1Gi hugepages lors du démarrage du système.
Créez le module DPDK en exécutant la commande suivante :
```
oc create -f intel-dpdk-pod.yaml
```
```
$ oc create -f intel-dpdk-pod.yaml
```
Copy to Clipboard Toggle word wrap

23.10.2. Utilisation d'une fonction virtuelle en mode DPDK avec un NIC Mellanox
Copier lien

Vous pouvez créer une stratégie de nœud de réseau et créer un pod Data Plane Development Kit (DPDK) à l'aide d'une fonction virtuelle en mode DPDK avec un NIC Mellanox.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous avez installé l'opérateur de réseau SR-IOV (Single Root I/O Virtualization).
Vous vous êtes connecté en tant qu'utilisateur avec les privilèges cluster-admin.

Procédure

SriovNetworkNodePolicy Enregistrez la configuration YAML suivante dans un fichier mlx-dpdk-node-policy.yaml:
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlx-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: mlxnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "15b3"
    deviceID: "1015" 
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: netdevice 
  isRdma: true 
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlx-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: mlxnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "15b3"
    deviceID: "1015" 
```
1
```
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: netdevice 
```
2
```
  isRdma: true 
```
3
Copy to Clipboard Toggle word wrap
1
Indiquez le code hexadécimal du périphérique du réseau SR-IOV.
2
Spécifiez le type de pilote pour les fonctions virtuelles à netdevice. Une fonction virtuelle (VF) Mellanox SR-IOV peut fonctionner en mode DPDK sans utiliser le type de périphérique vfio-pci. Le périphérique VF apparaît comme une interface réseau du noyau à l'intérieur d'un conteneur.
3
Activer le mode RDMA (Remote Direct Memory Access). Ceci est nécessaire pour que les cartes Mellanox fonctionnent en mode DPDK.
Note
Voir Configuring an SR-IOV network device pour une explication détaillée de chaque option de l'objet SriovNetworkNodePolicy.
Lors de l'application de la configuration spécifiée dans un objet SriovNetworkNodePolicy, l'opérateur SR-IOV peut vidanger les nœuds et, dans certains cas, les redémarrer. L'application d'une modification de configuration peut prendre plusieurs minutes. Assurez-vous au préalable qu'il y a suffisamment de nœuds disponibles dans votre cluster pour gérer la charge de travail expulsée.
Après l'application de la mise à jour de la configuration, tous les pods de l'espace de noms openshift-sriov-network-operator passeront à l'état Running.
Créez l'objet SriovNetworkNodePolicy en exécutant la commande suivante :
```
oc create -f mlx-dpdk-node-policy.yaml
```
```
$ oc create -f mlx-dpdk-node-policy.yaml
```
Copy to Clipboard Toggle word wrap
SriovNetwork Enregistrez la configuration YAML suivante dans un fichier mlx-dpdk-network.yaml:
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: mlx-dpdk-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |- 
...
  vlan: <vlan>
  resourceName: mlxnics
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: mlx-dpdk-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |- 
```
1
```
...
  vlan: <vlan>
  resourceName: mlxnics
```
Copy to Clipboard Toggle word wrap
1
Spécifier un objet de configuration pour le plugin IPAM (gestion des adresses IP) Container Network Interface (CNI) sous la forme d'un bloc YAML scalaire. Le plugin gère l'attribution des adresses IP pour la définition de l'attachement.
Note
Voir Configuring an SR-IOV network device pour une explication détaillée de chaque option de l'objet SriovNetwork.
La bibliothèque d'options app-netutil fournit plusieurs méthodes API pour collecter des informations réseau sur le module parent d'un conteneur.
Créez l'objet SriovNetwork en exécutant la commande suivante :
```
oc create -f mlx-dpdk-network.yaml
```
```
$ oc create -f mlx-dpdk-network.yaml
```
Copy to Clipboard Toggle word wrap
Pod Enregistrez la configuration YAML suivante dans un fichier mlx-dpdk-pod.yaml:
```
apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  namespace: <target_namespace> 
  annotations:
    k8s.v1.cni.cncf.io/networks: mlx-dpdk-network
spec:
  containers:
  - name: testpmd
    image: <DPDK_image> 
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    volumeMounts:
    - mountPath: /dev/hugepages 
      name: hugepage
    resources:
      limits:
        openshift.io/mlxnics: "1" 
        memory: "1Gi"
        cpu: "4" 
        hugepages-1Gi: "4Gi" 
      requests:
        openshift.io/mlxnics: "1"
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
```
```
apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  namespace: <target_namespace> 
```
1
```
  annotations:
    k8s.v1.cni.cncf.io/networks: mlx-dpdk-network
spec:
  containers:
  - name: testpmd
    image: <DPDK_image> 
```
2
```
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
```
3
```
    volumeMounts:
    - mountPath: /dev/hugepages 
```
4
```
      name: hugepage
    resources:
      limits:
        openshift.io/mlxnics: "1" 
```
5
```
        memory: "1Gi"
        cpu: "4" 
```
6
```
        hugepages-1Gi: "4Gi" 
```
7
```
      requests:
        openshift.io/mlxnics: "1"
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
```
Copy to Clipboard Toggle word wrap
1
Spécifiez le même target_namespace où l'objet SriovNetwork mlx-dpdk-network est créé. Pour créer le pod dans un espace de noms différent, modifiez target_namespace à la fois dans la spécification Pod et dans l'objet SriovNetwork.
2
Spécifiez l'image DPDK qui inclut votre application et la bibliothèque DPDK utilisée par l'application.
3
Spécifier les capacités supplémentaires requises par l'application à l'intérieur du conteneur pour l'allocation de pages énormes, l'allocation de ressources système et l'accès à l'interface réseau.
4
Montez le volume hugepage sur le pod DPDK sous /dev/hugepages. Le volume hugepage est soutenu par le type de volume emptyDir, le support étant Hugepages.
5
Facultatif : Spécifiez le nombre de périphériques DPDK alloués pour le module DPDK. Si elle n'est pas explicitement spécifiée, cette demande de ressource et cette limite sont automatiquement ajoutées par l'injecteur de ressources du réseau SR-IOV. L'injecteur de ressources réseau SR-IOV est un composant du contrôleur d'admission géré par l'opérateur SR-IOV. Il est activé par défaut et peut être désactivé en définissant l'option enableInjector sur false dans le CR SriovOperatorConfig par défaut.
6
Spécifiez le nombre d'unités centrales. Le pod DPDK nécessite généralement que des CPU exclusifs soient alloués à partir du kubelet. Pour ce faire, définissez la politique du gestionnaire de CPU sur static et créez un pod avec Guaranteed Quality of Service (QoS).
7
Spécifiez la taille de la page d'accueil hugepages-1Gi ou hugepages-2Mi et la quantité de pages d'accueil qui seront allouées au module DPDK. Configurez séparément 2Mi et 1Gi hugepages. La configuration de 1Gi hugepages nécessite l'ajout d'arguments de noyau à Nodes.
Créez le module DPDK en exécutant la commande suivante :
```
oc create -f mlx-dpdk-pod.yaml
```
```
$ oc create -f mlx-dpdk-pod.yaml
```
Copy to Clipboard Toggle word wrap

23.10.3. Vue d'ensemble de l'obtention d'un débit de ligne DPDK spécifique
Copier lien

Pour atteindre un débit de ligne spécifique du kit de développement du plan de données (DPDK), déployez un opérateur de réglage de nœud et configurez la virtualisation d'E/S à racine unique (SR-IOV). Vous devez également régler les paramètres du DPDK pour les ressources suivantes :

CPU isolés
Hugepages
Le planificateur de topologie

Note

Dans les versions précédentes d'OpenShift Container Platform, l'opérateur Performance Addon était utilisé pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence pour les applications OpenShift Container Platform. Dans OpenShift Container Platform 4.11 et les versions ultérieures, cette fonctionnalité fait partie de l'opérateur Node Tuning.

Environnement de test DPDK

Le diagramme suivant montre les composants d'un environnement de test de trafic :

Traffic generator: Une application qui peut générer un trafic de paquets important.
SR-IOV-supporting NIC: Carte d'interface réseau compatible avec SR-IOV. La carte exécute un certain nombre de fonctions virtuelles sur une interface physique.
Physical Function (PF): Fonction PCI Express (PCIe) d'un adaptateur réseau qui prend en charge l'interface SR-IOV.
Virtual Function (VF): Une fonction PCIe légère sur un adaptateur de réseau qui prend en charge le SR-IOV. Le VF est associé à la PF PCIe de l'adaptateur réseau. Le VF représente une instance virtualisée de l'adaptateur réseau.
Switch: Un commutateur de réseau. Les nœuds peuvent également être connectés dos à dos.
testpmd: Une application d'exemple incluse dans le DPDK. L'application testpmd peut être utilisée pour tester le DPDK dans un mode de transmission de paquets. L'application testpmd est également un exemple de construction d'une application complète à l'aide du kit de développement logiciel (SDK) DPDK.
worker 0 et worker 1: Nœuds OpenShift Container Platform.

23.10.4. Utilisation du SR-IOV et du Node Tuning Operator pour atteindre un débit de ligne DPDK
Copier lien

Vous pouvez utiliser le Node Tuning Operator pour configurer des CPU isolés, des hugepages et un planificateur de topologie. Vous pouvez ensuite utiliser l'opérateur de réglage de nœud avec la virtualisation d'E/S à racine unique (SR-IOV) pour atteindre un débit de ligne spécifique du kit de développement du plan de données (DPDK).

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous avez installé l'opérateur de réseau SR-IOV.
Vous vous êtes connecté en tant qu'utilisateur avec les privilèges cluster-admin.
Vous avez déployé un Node Tuning Operator autonome.
Note
Dans les versions précédentes d'OpenShift Container Platform, l'opérateur Performance Addon était utilisé pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence pour les applications OpenShift. Dans OpenShift Container Platform 4.11 et les versions ultérieures, cette fonctionnalité fait partie de l'opérateur Node Tuning.

Procédure

Créez un objet PerformanceProfile en vous inspirant de l'exemple suivant :
```
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: performance
spec:
  globallyDisableIrqLoadBalancing: true
  cpu:
    isolated: 21-51,73-103 
    reserved: 0-20,52-72 
  hugepages:
    defaultHugepagesSize: 1G 
    pages:
      - count: 32
        size: 1G
  net:
    userLevelNetworking: true
  numa:
    topologyPolicy: "single-numa-node"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
```
```
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: performance
spec:
  globallyDisableIrqLoadBalancing: true
  cpu:
    isolated: 21-51,73-103 
```
1
```
    reserved: 0-20,52-72 
```
2
```
  hugepages:
    defaultHugepagesSize: 1G 
```
3
```
    pages:
      - count: 32
        size: 1G
  net:
    userLevelNetworking: true
  numa:
    topologyPolicy: "single-numa-node"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
```
Copy to Clipboard Toggle word wrap
1
Si l'hyperthreading est activé sur le système, allouez les liens symboliques appropriés aux groupes de CPU isolated et reserved. Si le système contient plusieurs nœuds d'accès à la mémoire non uniforme (NUMA), allouez les CPU des deux NUMA aux deux groupes. Vous pouvez également utiliser le Créateur de profil de performance pour cette tâche. Pour plus d'informations, voir Creating a performance profile.
2
Vous pouvez également spécifier une liste de périphériques dont les files d'attente seront définies en fonction du nombre d'unités centrales réservées. Pour plus d'informations, voir Reducing NIC queues using the Node Tuning Operator.
3
Allouer le nombre et la taille des hugepages nécessaires. Vous pouvez spécifier la configuration NUMA pour les hugepages. Par défaut, le système alloue un nombre pair à chaque nœud NUMA du système. Si nécessaire, vous pouvez demander l'utilisation d'un noyau en temps réel pour les nœuds. Pour plus d'informations, voir Provisioning a worker with real-time capabilities pour plus d'informations.
Enregistrez le fichier yaml sous mlx-dpdk-perfprofile-policy.yaml.
Appliquez le profil de performance à l'aide de la commande suivante :
```
oc create -f mlx-dpdk-perfprofile-policy.yaml
```
```
$ oc create -f mlx-dpdk-perfprofile-policy.yaml
```
Copy to Clipboard Toggle word wrap

23.10.4.1. Exemple d'opérateur de réseau SR-IOV pour les fonctions virtuelles
Copier lien

Vous pouvez utiliser l'opérateur de réseau de virtualisation d'E/S à racine unique (SR-IOV) pour allouer et configurer des fonctions virtuelles (VF) à partir de cartes d'interface réseau de fonctions physiques supportant la SR-IOV sur les nœuds.

Pour plus d'informations sur le déploiement de l'opérateur, voir Installing the SR-IOV Network Operator. Pour plus d'informations sur la configuration d'un périphérique réseau SR-IOV, voir Configuring an SR-IOV network device.

Il existe quelques différences entre l'exécution des charges de travail du kit de développement du plan de données (DPDK) sur les VF Intel et les VF Mellanox. Cette section fournit des exemples de configuration d'objets pour les deux types de VF. Voici un exemple d'objet sriovNetworkNodePolicy utilisé pour exécuter des applications DPDK sur des cartes réseau Intel :

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci 
  needVhostNet: true 
  nicSelector:
    pfNames: ["ens3f0"]
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci
  needVhostNet: true
  nicSelector:
    pfNames: ["ens3f1"]
  nodeSelector:
  node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_2

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci

1


  needVhostNet: true

2


  nicSelector:
    pfNames: ["ens3f0"]
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci
  needVhostNet: true
  nicSelector:
    pfNames: ["ens3f1"]
  nodeSelector:
  node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_2

Copy to Clipboard

Toggle word wrap

1: Pour les NIC d'Intel, deviceType doit être vfio-pci.
2: Si la communication du noyau avec les charges de travail DPDK est nécessaire, ajoutez needVhostNet: true. Cela permet de monter les périphériques /dev/net/tun et /dev/vhost-net dans le conteneur afin que l'application puisse créer un périphérique de prise et connecter le périphérique de prise à la charge de travail DPDK.

Voici un exemple d'objet sriovNetworkNodePolicy pour les cartes d'interface réseau Mellanox :

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice 
  isRdma: true 
  nicSelector:
    rootDevices:
      - "0000:5e:00.1"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-2
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  nicSelector:
    rootDevices:
      - "0000:5e:00.0"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_2

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice

1


  isRdma: true

2


  nicSelector:
    rootDevices:
      - "0000:5e:00.1"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-2
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  nicSelector:
    rootDevices:
      - "0000:5e:00.0"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_2

Copy to Clipboard

Toggle word wrap

1: Pour les dispositifs Mellanox, le site deviceType doit être netdevice.
2: Pour les dispositifs Mellanox, isRdma doit être true. Les cartes Mellanox sont connectées aux applications DPDK en utilisant la bifurcation de flux. Ce mécanisme divise le trafic entre l'espace utilisateur Linux et l'espace noyau, et peut améliorer la capacité de traitement du débit de ligne.

23.10.4.2. Exemple d'opérateur de réseau SR-IOV
Copier lien

Voici un exemple de définition d'un objet sriovNetwork. Dans ce cas, les configurations Intel et Mellanox sont identiques :

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-1
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.1.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}' 
  networkNamespace: dpdk-test 
  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_1 
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-2
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.2.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}'
  networkNamespace: dpdk-test
  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_2

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-1
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.1.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}'

1


  networkNamespace: dpdk-test

2


  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_1

3


---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-2
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.2.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}'
  networkNamespace: dpdk-test
  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_2

Copy to Clipboard

Toggle word wrap

1: Vous pouvez utiliser une implémentation différente de la gestion des adresses IP (IPAM), telle que Whereabouts. Pour plus d'informations, voir Dynamic IP address assignment configuration with Whereabouts.
2: Vous devez demander l'adresse networkNamespace où la définition de la pièce jointe au réseau sera créée. Vous devez créer le CR sriovNetwork sous l'espace de noms openshift-sriov-network-operator.
3: La valeur de resourceName doit correspondre à celle de resourceName créée sous sriovNetworkNodePolicy.

23.10.4.3. Exemple de charge de travail de base DPDK
Copier lien

Voici un exemple de conteneur du kit de développement du plan de données (DPDK) :

apiVersion: v1
kind: Namespace
metadata:
  name: dpdk-test
---
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[ 
     {
      "name": "dpdk-network-1",
      "namespace": "dpdk-test"
     },
     {
      "name": "dpdk-network-2",
      "namespace": "dpdk-test"
     }
   ]'
    irq-load-balancing.crio.io: "disable" 
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
  labels:
    app: dpdk
  name: testpmd
  namespace: dpdk-test
spec:
  runtimeClassName: performance-performance 
  containers:
    - command:
        - /bin/bash
        - -c
        - sleep INF
      image: registry.redhat.io/openshift4/dpdk-base-rhel8
      imagePullPolicy: Always
      name: dpdk
      resources: 
        limits:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
        requests:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
      securityContext:
        capabilities:
          add:
            - IPC_LOCK
            - SYS_RESOURCE
            - NET_RAW
            - NET_ADMIN
        runAsUser: 0
      volumeMounts:
        - mountPath: /mnt/huge
          name: hugepages
  terminationGracePeriodSeconds: 5
  volumes:
    - emptyDir:
        medium: HugePages
      name: hugepages

apiVersion: v1
kind: Namespace
metadata:
  name: dpdk-test
---
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[

1


     {
      "name": "dpdk-network-1",
      "namespace": "dpdk-test"
     },
     {
      "name": "dpdk-network-2",
      "namespace": "dpdk-test"
     }
   ]'
    irq-load-balancing.crio.io: "disable"

2


    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
  labels:
    app: dpdk
  name: testpmd
  namespace: dpdk-test
spec:
  runtimeClassName: performance-performance

3


  containers:
    - command:
        - /bin/bash
        - -c
        - sleep INF
      image: registry.redhat.io/openshift4/dpdk-base-rhel8
      imagePullPolicy: Always
      name: dpdk
      resources:

4


        limits:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
        requests:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
      securityContext:
        capabilities:
          add:
            - IPC_LOCK
            - SYS_RESOURCE
            - NET_RAW
            - NET_ADMIN
        runAsUser: 0
      volumeMounts:
        - mountPath: /mnt/huge
          name: hugepages
  terminationGracePeriodSeconds: 5
  volumes:
    - emptyDir:
        medium: HugePages
      name: hugepages

Copy to Clipboard

Toggle word wrap

1: Demandez les réseaux SR-IOV dont vous avez besoin. Les ressources pour les appareils seront injectées automatiquement.
2: Désactiver la base d'équilibrage de charge du CPU et de l'IRQ. Pour plus d'informations, voir Disabling interrupt processing for individual pods pour plus d'informations.
3: Réglez le runtimeClass sur le performance-performance. Ne définissez pas runtimeClass sur HostNetwork ou privileged.
4: Demander un nombre égal de ressources pour les demandes et les limites afin de démarrer le pod avec Guaranteed Qualité de service (QoS).

Note

Ne démarrez pas le pod avec SLEEP puis exécutez dans le pod pour démarrer le testpmd ou la charge de travail DPDK. Cela peut ajouter des interruptions supplémentaires car le processus exec n'est rattaché à aucun processeur.

23.10.4.4. Exemple de script testpmd
Copier lien

Voici un exemple de script pour l'exécution de testpmd:

#!/bin/bash
set -ex
export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus)
echo ${CPU}

dpdk-testpmd -l ${CPU} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_1} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_2} -n 4 -- -i --nb-cores=15 --rxd=4096 --txd=4096 --rxq=7 --txq=7 --forward-mode=mac --eth-peer=0,50:00:00:00:00:01 --eth-peer=1,50:00:00:00:00:02

#!/bin/bash
set -ex
export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus)
echo ${CPU}

dpdk-testpmd -l ${CPU} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_1} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_2} -n 4 -- -i --nb-cores=15 --rxd=4096 --txd=4096 --rxq=7 --txq=7 --forward-mode=mac --eth-peer=0,50:00:00:00:00:01 --eth-peer=1,50:00:00:00:00:02

Copy to Clipboard

Toggle word wrap

Cet exemple utilise deux CR sriovNetwork différents. La variable d'environnement contient l'adresse PCI de la fonction virtuelle (VF) qui a été allouée au module. Si vous utilisez le même réseau dans la définition du pod, vous devez diviser le pciAddress. Il est important de configurer les adresses MAC correctes du générateur de trafic. Cet exemple utilise des adresses MAC personnalisées.

23.10.5. Utilisation d'une fonction virtuelle en mode RDMA avec un NIC Mellanox
Copier lien

Important

RDMA over Converged Ethernet (RoCE) est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes d'un point de vue fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

RDMA over Converged Ethernet (RoCE) est le seul mode pris en charge lors de l'utilisation de RDMA sur OpenShift Container Platform.

Conditions préalables

Installez le CLI OpenShift (oc).
Installer l'opérateur de réseau SR-IOV.
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créez l'objet SriovNetworkNodePolicy suivant, puis enregistrez le YAML dans le fichier mlx-rdma-node-policy.yaml.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlx-rdma-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: mlxnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "15b3"
    deviceID: "1015" 
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: netdevice 
  isRdma: true

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlx-rdma-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: mlxnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "15b3"
    deviceID: "1015"

1


    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: netdevice

2


  isRdma: true

3

Copy to Clipboard

Toggle word wrap

1: Indiquez le code hexadécimal du périphérique du réseau SR-IOV.
2: Spécifiez le type de pilote pour les fonctions virtuelles à netdevice.
3: Activer le mode RDMA.

Note

Voir la section Configuring SR-IOV network devices pour une explication détaillée de chaque option de SriovNetworkNodePolicy.

Lors de l'application de la configuration spécifiée dans un objet SriovNetworkNodePolicy, l'opérateur SR-IOV peut vidanger les nœuds et, dans certains cas, les redémarrer. L'application d'une modification de configuration peut prendre plusieurs minutes. Assurez-vous au préalable qu'il y a suffisamment de nœuds disponibles dans votre cluster pour gérer la charge de travail expulsée.

Après l'application de la mise à jour de la configuration, tous les pods de l'espace de noms openshift-sriov-network-operator passeront à l'état Running.

Créez l'objet SriovNetworkNodePolicy en exécutant la commande suivante :
```
oc create -f mlx-rdma-node-policy.yaml
```
```
$ oc create -f mlx-rdma-node-policy.yaml
```
Copy to Clipboard Toggle word wrap
Créez l'objet SriovNetwork suivant, puis enregistrez le YAML dans le fichier mlx-rdma-network.yaml.
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: mlx-rdma-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |- 
# ...
  vlan: <vlan>
  resourceName: mlxnics
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: mlx-rdma-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |- 
```
1
```
# ...
  vlan: <vlan>
  resourceName: mlxnics
```
Copy to Clipboard Toggle word wrap
1
Spécifier un objet de configuration pour le plugin CNI ipam sous la forme d'un bloc YAML scalaire. Le plugin gère l'attribution des adresses IP pour la définition des pièces jointes.
Note
Voir la section "Configuration du réseau supplémentaire SR-IOV" pour une explication détaillée de chaque option sur SriovNetwork.
Une bibliothèque optionnelle, app-netutil, fournit plusieurs méthodes API pour collecter des informations réseau sur le pod parent d'un conteneur.
Créez l'objet SriovNetworkNodePolicy en exécutant la commande suivante :
```
oc create -f mlx-rdma-network.yaml
```
```
$ oc create -f mlx-rdma-network.yaml
```
Copy to Clipboard Toggle word wrap

Créez la spécification Pod suivante, puis enregistrez le YAML dans le fichier mlx-rdma-pod.yaml.

apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  namespace: <target_namespace> 
  annotations:
    k8s.v1.cni.cncf.io/networks: mlx-rdma-network
spec:
  containers:
  - name: testpmd
    image: <RDMA_image> 
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    volumeMounts:
    - mountPath: /dev/hugepages 
      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "4" 
        hugepages-1Gi: "4Gi" 
      requests:
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  namespace: <target_namespace>

1


  annotations:
    k8s.v1.cni.cncf.io/networks: mlx-rdma-network
spec:
  containers:
  - name: testpmd
    image: <RDMA_image>

2


    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]

3


    volumeMounts:
    - mountPath: /dev/hugepages

4


      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "4"

5


        hugepages-1Gi: "4Gi"

6


      requests:
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Copy to Clipboard

Toggle word wrap

1: Spécifiez le même target_namespace où l'objet SriovNetwork mlx-rdma-network est créé. Si vous souhaitez créer le pod dans un espace de noms différent, modifiez target_namespace dans la spécification Pod et dans l'objet SriovNetowrk.
2: Spécifiez l'image RDMA qui inclut votre application et la bibliothèque RDMA utilisée par l'application.
3: Spécifier les capacités supplémentaires requises par l'application à l'intérieur du conteneur pour l'allocation de pages énormes, l'allocation de ressources système et l'accès à l'interface réseau.
4: Monter le volume hugepage sur le pod RDMA sous /dev/hugepages. Le volume hugepage est sauvegardé par le type de volume emptyDir, le support étant Hugepages.
5: Spécifiez le nombre de CPU. Le pod RDMA nécessite généralement que des CPU exclusifs soient alloués par le kubelet. Pour ce faire, définissez la politique du gestionnaire de CPU sur static et créez un pod avec Guaranteed QoS.
6: Spécifiez la taille de la page d'accueil hugepages-1Gi ou hugepages-2Mi et la quantité de pages d'accueil qui seront allouées au pod RDMA. Configurez 2Mi et 1Gi hugepages séparément. La configuration de 1Gi hugepage nécessite l'ajout d'arguments de noyau à Nodes.

Créez le pod RDMA en exécutant la commande suivante :
```
oc create -f mlx-rdma-pod.yaml
```
```
$ oc create -f mlx-rdma-pod.yaml
```
Copy to Clipboard Toggle word wrap

23.10.6. Un modèle de pod de test pour les clusters qui utilisent OVS-DPDK sur OpenStack
Copier lien

Le pod testpmd suivant illustre la création d'un conteneur avec des pages énormes, des unités centrales réservées et le port SR-IOV.

Un exemple de pod testpmd

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-dpdk
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/dpdk1: 1 
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/dpdk1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile 
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-dpdk
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/dpdk1: 1

1


      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/dpdk1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile

2


  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Copy to Clipboard

Toggle word wrap

1: Le nom dpdk1 dans cet exemple correspond à une ressource SriovNetworkNodePolicy créée par l'utilisateur. Vous pouvez remplacer ce nom par celui d'une ressource que vous créez.
2: Si votre profil de performance ne s'appelle pas cnf-performance profile, remplacez cette chaîne par le nom correct du profil de performance.

23.10.7. Un modèle de pod de test pour les clusters qui utilisent le déchargement matériel OVS sur OpenStack
Copier lien

Le pod testpmd suivant démontre le déchargement matériel d'Open vSwitch (OVS) sur Red Hat OpenStack Platform (RHOSP).

Un exemple de pod testpmd

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    k8s.v1.cni.cncf.io/networks: hwoffload1
spec:
  runtimeClassName: performance-cnf-performanceprofile 
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    k8s.v1.cni.cncf.io/networks: hwoffload1
spec:
  runtimeClassName: performance-cnf-performanceprofile

1


  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Copy to Clipboard

Toggle word wrap

1: Si votre profil de performance ne s'appelle pas cnf-performance profile, remplacez cette chaîne par le nom correct du profil de performance.

23.11. Utiliser la liaison au niveau du pod
Copier lien

Le bonding au niveau du pod est essentiel pour permettre aux charges de travail à l'intérieur des pods de bénéficier d'une haute disponibilité et d'un débit plus élevé. Avec le bonding au niveau du pod, vous pouvez créer une interface de bonding à partir de plusieurs interfaces de fonctions virtuelles de virtualisation d'E/S à racine unique (SR-IOV) dans une interface en mode noyau. Les fonctions virtuelles SR-IOV sont transférées dans le pod et attachées à un pilote de noyau.

Un scénario dans lequel le bonding au niveau du pod est nécessaire est la création d'une interface de bonding à partir de plusieurs fonctions virtuelles SR-IOV sur différentes fonctions physiques. La création d'une interface de liaison à partir de deux fonctions physiques différentes sur l'hôte peut être utilisée pour obtenir une haute disponibilité et un débit élevé au niveau du pod.

Pour obtenir des conseils sur des tâches telles que la création d'un réseau SR-IOV, les politiques de réseau, les définitions d'attachement au réseau et les pods, voir Configuration d'un dispositif de réseau SR-IOV.

23.11.1. Configuration d'une interface de liaison à partir de deux interfaces SR-IOV
Copier lien

Le bonding permet d'agréger plusieurs interfaces réseau en une seule interface logique. L'interface Bond Container Network Interface (Bond-CNI) intègre la capacité de liaison dans les conteneurs.

Bond-CNI peut être créé en utilisant des fonctions virtuelles SR-IOV (Single Root I/O Virtualization) et en les plaçant dans l'espace de noms du réseau de conteneurs.

OpenShift Container Platform ne supporte que Bond-CNI en utilisant les fonctions virtuelles SR-IOV. L'opérateur de réseau SR-IOV fournit le plugin CNI SR-IOV nécessaire pour gérer les fonctions virtuelles. D'autres CNI ou types d'interfaces ne sont pas pris en charge.

Conditions préalables

L'opérateur de réseau SR-IOV doit être installé et configuré pour obtenir des fonctions virtuelles dans un conteneur.
Pour configurer les interfaces SR-IOV, un réseau et une politique SR-IOV doivent être créés pour chaque interface.
L'opérateur de réseau SR-IOV crée une définition de l'attachement au réseau pour chaque interface SR-IOV, sur la base du réseau SR-IOV et de la politique définie.
Le site linkState est réglé sur la valeur par défaut auto pour la fonction virtuelle SR-IOV.

23.11.1.1. Création d'une définition d'attachement à un réseau de liens
Copier lien

Maintenant que les fonctions virtuelles SR-IOV sont disponibles, vous pouvez créer une définition d'attachement au réseau de liaison.

apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: bond-net1
      namespace: demo
    spec:
      config: '{
      "type": "bond", 
      "cniVersion": "0.3.1",
      "name": "bond-net1",
      "mode": "active-backup", 
      "failOverMac": 1, 
      "linksInContainer": true, 
      "miimon": "100",
      "mtu": 1500,
      "links": [ 
            {"name": "net1"},
            {"name": "net2"}
        ],
      "ipam": {
            "type": "host-local",
            "subnet": "10.56.217.0/24",
            "routes": [{
            "dst": "0.0.0.0/0"
            }],
            "gateway": "10.56.217.1"
        }
      }'

apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: bond-net1
      namespace: demo
    spec:
      config: '{
      "type": "bond",

1


      "cniVersion": "0.3.1",
      "name": "bond-net1",
      "mode": "active-backup",

2


      "failOverMac": 1,

3


      "linksInContainer": true,

4


      "miimon": "100",
      "mtu": 1500,
      "links": [

5


            {"name": "net1"},
            {"name": "net2"}
        ],
      "ipam": {
            "type": "host-local",
            "subnet": "10.56.217.0/24",
            "routes": [{
            "dst": "0.0.0.0/0"
            }],
            "gateway": "10.56.217.1"
        }
      }'

Copy to Clipboard

Toggle word wrap

Le type cni- est toujours défini sur bond.

L'attribut mode spécifie le mode de liaison.

Note

Les modes de liaison pris en charge sont les suivants :

balance-rr - 0
active-backup - 1
balance-xor - 2

Pour les modes balance-rr ou balance-xor, vous devez définir le mode trust sur on pour la fonction virtuelle SR-IOV.

L'attribut failover est obligatoire pour le mode de sauvegarde active et doit être défini sur 1.

4

Le drapeau linksInContainer=true informe le Bond CNI que les interfaces requises doivent être trouvées à l'intérieur du conteneur. Par défaut, Bond CNI recherche ces interfaces sur l'hôte, ce qui ne fonctionne pas pour l'intégration avec SRIOV et Multus.

5

La section links définit les interfaces qui seront utilisées pour créer le lien. Par défaut, Multus nomme les interfaces attachées comme suit : \N "net\N", plus un nombre consécutif, en commençant par un.

23.11.1.2. Création d'un pod à l'aide d'une interface de liaison
Copier lien

Testez la configuration en créant un pod avec un fichier YAML nommé par exemple podbonding.yaml avec un contenu similaire à ce qui suit :

apiVersion: v1
    kind: Pod
    metadata:
      name: bondpod1
      namespace: demo
      annotations:
        k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1 
    spec:
      containers:
      - name: podexample
        image: quay.io/openshift/origin-network-interface-bond-cni:4.11.0
        command: ["/bin/bash", "-c", "sleep INF"]

apiVersion: v1
    kind: Pod
    metadata:
      name: bondpod1
      namespace: demo
      annotations:
        k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1

1


    spec:
      containers:
      - name: podexample
        image: quay.io/openshift/origin-network-interface-bond-cni:4.11.0
        command: ["/bin/bash", "-c", "sleep INF"]

Copy to Clipboard

Toggle word wrap

1: Notez l'annotation du réseau : il contient deux attachements de réseau SR-IOV et un attachement de réseau de liaison. L'attachement de liaison utilise les deux interfaces SR-IOV comme interfaces de port liées.

Appliquez le fichier yaml en exécutant la commande suivante :
```
oc apply -f podbonding.yaml
```
```
$ oc apply -f podbonding.yaml
```
Copy to Clipboard Toggle word wrap

Inspectez les interfaces du pod à l'aide de la commande suivante :

$ oc rsh -n demo bondpod1
sh-4.4#
sh-4.4# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
3: eth0@if150: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP
link/ether 62:b1:b5:c8:fb:7a brd ff:ff:ff:ff:ff:ff
inet 10.244.1.122/24 brd 10.244.1.255 scope global eth0
valid_lft forever preferred_lft forever
4: net3: <BROADCAST,MULTICAST,UP,LOWER_UP400> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff 
inet 10.56.217.66/24 scope global bond0
valid_lft forever preferred_lft forever
43: net1: <BROADCAST,MULTICAST,UP,LOWER_UP800> mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff 
44: net2: <BROADCAST,MULTICAST,UP,LOWER_UP800> mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff

$ oc rsh -n demo bondpod1
sh-4.4#
sh-4.4# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
3: eth0@if150: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP
link/ether 62:b1:b5:c8:fb:7a brd ff:ff:ff:ff:ff:ff
inet 10.244.1.122/24 brd 10.244.1.255 scope global eth0
valid_lft forever preferred_lft forever
4: net3: <BROADCAST,MULTICAST,UP,LOWER_UP400> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff

1


inet 10.56.217.66/24 scope global bond0
valid_lft forever preferred_lft forever
43: net1: <BROADCAST,MULTICAST,UP,LOWER_UP800> mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff

2


44: net2: <BROADCAST,MULTICAST,UP,LOWER_UP800> mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff

3

Copy to Clipboard

Toggle word wrap

1: L'interface de liaison est automatiquement nommée net3. Pour définir un nom d'interface spécifique, ajoutez le suffixe @name à l'annotation k8s.v1.cni.cncf.io/networks du pod.
2: L'interface net1 est basée sur une fonction virtuelle SR-IOV.
3: L'interface net2 est basée sur une fonction virtuelle SR-IOV.

Note

Si aucun nom d'interface n'est configuré dans l'annotation du pod, les noms d'interface sont attribués automatiquement sous la forme net<n>, <n> commençant par 1.

Facultatif : si vous souhaitez définir un nom d'interface spécifique, par exemple bond0, modifiez l'annotation k8s.v1.cni.cncf.io/networks et définissez bond0 comme nom d'interface comme suit :
```
annotations:
        k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1@bond0
```
```
annotations:
        k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1@bond0
```
Copy to Clipboard Toggle word wrap

23.12. Configuration du délestage matériel
Copier lien

En tant qu'administrateur de cluster, vous pouvez configurer le délestage matériel sur les nœuds compatibles afin d'augmenter les performances de traitement des données et de réduire la charge sur les processeurs hôtes.

23.12.1. À propos du délestage matériel
Copier lien

Le déchargement matériel Open vSwitch est une méthode de traitement des tâches réseau qui consiste à les détourner de l'unité centrale et à les décharger sur un processeur dédié sur un contrôleur d'interface réseau. Les clusters peuvent ainsi bénéficier de vitesses de transfert de données plus rapides, d'une réduction de la charge de travail de l'unité centrale et d'une baisse des coûts informatiques.

L'élément clé de cette fonctionnalité est une classe moderne de contrôleurs d'interface réseau connus sous le nom de SmartNIC. Un SmartNIC est un contrôleur d'interface réseau capable de gérer des tâches de traitement réseau lourdes en termes de calcul. De la même manière qu'une carte graphique dédiée peut améliorer les performances graphiques, un SmartNIC peut améliorer les performances du réseau. Dans chaque cas, un processeur dédié améliore les performances pour un type spécifique de tâche de traitement.

Dans OpenShift Container Platform, vous pouvez configurer le délestage matériel pour les nœuds bare metal qui ont un SmartNIC compatible. Le délestage matériel est configuré et activé par l'opérateur du réseau SR-IOV.

Le délestage matériel n'est pas compatible avec toutes les charges de travail ou tous les types d'application. Seuls les deux types de communication suivants sont pris en charge :

de pod à pod
pod-to-service, où le service est un service ClusterIP soutenu par un pod régulier

Dans tous les cas, le délestage matériel n'a lieu que lorsque les pods et les services sont affectés à des nœuds dotés d'un SmartNIC compatible. Supposons, par exemple, qu'un module sur un nœud avec délestage matériel essaie de communiquer avec un service sur un nœud normal. Sur le nœud normal, tout le traitement a lieu dans le noyau, de sorte que les performances globales de la communication entre le pod et le service sont limitées aux performances maximales de ce nœud normal. Le déchargement matériel n'est pas compatible avec les applications DPDK.

Le fait d'activer le délestage matériel sur un nœud, mais de ne pas configurer les pods pour qu'ils l'utilisent, peut entraîner une diminution des performances de débit pour le trafic des pods. Vous ne pouvez pas configurer le délestage matériel pour les pods qui sont gérés par OpenShift Container Platform.

23.12.2. Dispositifs pris en charge
Copier lien

Le délestage matériel est pris en charge par les contrôleurs d'interface réseau suivants :

Expand

Tableau 23.15. Contrôleurs d'interface réseau pris en charge
Fabricant	Model	ID du vendeur	ID de l'appareil
Mellanox	Famille MT27800 [ConnectX-5]	15b3	1017
Mellanox	Famille MT28880 [ConnectX-5 Ex]	15b3	1019

Expand

Tableau 23.16. Technologie Aperçu des contrôleurs d'interface réseau
Fabricant	Model	ID du vendeur	ID de l'appareil
Mellanox	Famille MT2892 [ConnectX-6 Dx]	15b3	101d
Mellanox	Famille MT2894 [ConnectX-6 Lx]	15b3	101f
Mellanox	MT42822 BlueField-2 en mode NIC ConnectX-6	15b3	a2d6

Important

L'utilisation d'un périphérique ConnectX-6 Lx ou BlueField-2 en mode ConnectX-6 NIC est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

23.12.3. Conditions préalables
Copier lien

Votre cluster possède au moins une machine bare metal avec un contrôleur d'interface réseau pris en charge pour le délestage matériel.
Vous avez installé l'opérateur de réseau SR-IOV.
Votre cluster utilise le plugin réseau OVN-Kubernetes.
Dans la configuration de votre plugin réseau OVN-Kubernetes, le champ gatewayConfig.routingViaHost est défini sur false.

23.12.4. Configuration d'un pool de configuration de machines pour le délestage matériel
Copier lien

Pour activer le délestage matériel, vous devez d'abord créer un pool de configuration machine dédié et le configurer pour qu'il fonctionne avec l'opérateur de réseau SR-IOV.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

Créez un pool de configuration pour les machines sur lesquelles vous souhaitez utiliser le délestage matériel.

Créez un fichier, tel que mcp-offloading.yaml, dont le contenu ressemble à l'exemple suivant :

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: mcp-offloading 
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,mcp-offloading]} 
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/mcp-offloading: ""

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: mcp-offloading

1


spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,mcp-offloading]}

2


  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/mcp-offloading: ""

3

Copy to Clipboard

Toggle word wrap

1 2: Le nom du pool de configuration de la machine pour le délestage matériel.
3: Cette étiquette de rôle de nœud est utilisée pour ajouter des nœuds au pool de configuration de la machine.

Appliquer la configuration pour le pool de configuration de la machine :
```
oc create -f mcp-offloading.yaml
```
```
$ oc create -f mcp-offloading.yaml
```
Copy to Clipboard Toggle word wrap

Ajoutez des nœuds au pool de configuration de machines. Étiqueter chaque nœud avec l'étiquette de rôle de nœud de votre pool :
```
oc label node worker-2 node-role.kubernetes.io/mcp-offloading=""
```
```
$ oc label node worker-2 node-role.kubernetes.io/mcp-offloading=""
```
Copy to Clipboard Toggle word wrap

Facultatif : Pour vérifier que le nouveau pool est créé, exécutez la commande suivante :

oc get nodes

$ oc get nodes

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME       STATUS   ROLES                   AGE   VERSION
master-0   Ready    master                  2d    v1.25.0
master-1   Ready    master                  2d    v1.25.0
master-2   Ready    master                  2d    v1.25.0
worker-0   Ready    worker                  2d    v1.25.0
worker-1   Ready    worker                  2d    v1.25.0
worker-2   Ready    mcp-offloading,worker   47h   v1.25.0
worker-3   Ready    mcp-offloading,worker   47h   v1.25.0

NAME       STATUS   ROLES                   AGE   VERSION
master-0   Ready    master                  2d    v1.25.0
master-1   Ready    master                  2d    v1.25.0
master-2   Ready    master                  2d    v1.25.0
worker-0   Ready    worker                  2d    v1.25.0
worker-1   Ready    worker                  2d    v1.25.0
worker-2   Ready    mcp-offloading,worker   47h   v1.25.0
worker-3   Ready    mcp-offloading,worker   47h   v1.25.0

Copy to Clipboard

Toggle word wrap

Ajouter ce pool de configuration machine à la ressource personnalisée SriovNetworkPoolConfig:
1. Créez un fichier, tel que sriov-pool-config.yaml, dont le contenu ressemble à l'exemple suivant :
  apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkPoolConfig metadata: name: sriovnetworkpoolconfig-offload namespace: openshift-sriov-network-operator spec: ovsHardwareOffloadConfig: name: mcp-offloading
  1
  Copy to Clipboard Toggle word wrap
  1
  Le nom du pool de configuration de la machine pour le délestage matériel.
2. Appliquer la configuration :
  oc create -f <SriovNetworkPoolConfig_name>.yaml
  Copy to Clipboard Toggle word wrap
  Note
  Lorsque vous appliquez la configuration spécifiée dans un objet SriovNetworkPoolConfig, l'opérateur SR-IOV vide et redémarre les nœuds du pool de configuration de la machine.
  L'application des changements de configuration peut prendre plusieurs minutes.

23.12.5. Configuration de la politique des nœuds de réseau SR-IOV
Copier lien

Vous pouvez créer une configuration de dispositif de réseau SR-IOV pour un nœud en créant une stratégie de nœud de réseau SR-IOV. Pour activer le délestage matériel, vous devez définir le champ .spec.eSwitchMode avec la valeur "switchdev".

La procédure suivante permet de créer une interface SR-IOV pour un contrôleur d'interface réseau avec délestage matériel.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

Créez un fichier, tel que sriov-node-policy.yaml, dont le contenu ressemble à l'exemple suivant :

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: sriov-node-policy <.>
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice <.>
  eSwitchMode: "switchdev" <.>
  nicSelector:
    deviceID: "1019"
    rootDevices:
    - 0000:d8:00.0
    vendor: "15b3"
    pfNames:
    - ens8f0
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 6
  priority: 5
  resourceName: mlxnics

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: sriov-node-policy <.>
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice <.>
  eSwitchMode: "switchdev" <.>
  nicSelector:
    deviceID: "1019"
    rootDevices:
    - 0000:d8:00.0
    vendor: "15b3"
    pfNames:
    - ens8f0
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 6
  priority: 5
  resourceName: mlxnics

Copy to Clipboard

Toggle word wrap

<.> Nom de l'objet ressource personnalisé. <.> Requis. Le délestage matériel n'est pas pris en charge par vfio-pci<.> Requis.

Appliquer la configuration de la politique :
```
oc create -f sriov-node-policy.yaml
```
```
$ oc create -f sriov-node-policy.yaml
```
Copy to Clipboard Toggle word wrap
Note
Lorsque vous appliquez la configuration spécifiée dans un objet SriovNetworkPoolConfig, l'opérateur SR-IOV vide et redémarre les nœuds du pool de configuration de la machine.
L'application d'une modification de configuration peut prendre plusieurs minutes.

23.12.5.1. Exemple de politique de nœuds de réseau SR-IOV pour OpenStack
Copier lien

L'exemple suivant décrit une interface SR-IOV pour un contrôleur d'interface réseau (NIC) avec déchargement matériel sur Red Hat OpenStack Platform (RHOSP).

Une interface SR-IOV pour une carte d'interface réseau avec délestage matériel sur RHOSP

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: ${name}
  namespace: openshift-sriov-network-operator
spec:
  deviceType: switchdev
  isRdma: true
  nicSelector:
    netFilter: openstack/NetworkID:${net_id}
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: 'true'
  numVfs: 1
  priority: 99
  resourceName: ${name}

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: ${name}
  namespace: openshift-sriov-network-operator
spec:
  deviceType: switchdev
  isRdma: true
  nicSelector:
    netFilter: openstack/NetworkID:${net_id}
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: 'true'
  numVfs: 1
  priority: 99
  resourceName: ${name}

Copy to Clipboard

Toggle word wrap

23.12.6. Création d'une définition de pièce jointe au réseau
Copier lien

Après avoir défini le pool de configuration machine et la stratégie de nœuds de réseau SR-IOV, vous pouvez créer une définition d'attachement réseau pour la carte d'interface réseau que vous avez spécifiée.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

Créez un fichier, tel que net-attach-def.yaml, dont le contenu ressemble à l'exemple suivant :

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: net-attach-def <.>
  namespace: net-attach-def <.>
  annotations:
    k8s.v1.cni.cncf.io/resourceName: openshift.io/mlxnics <.>
spec:
  config: '{"cniVersion":"0.3.1","name":"ovn-kubernetes","type":"ovn-k8s-cni-overlay","ipam":{},"dns":{}}'

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: net-attach-def <.>
  namespace: net-attach-def <.>
  annotations:
    k8s.v1.cni.cncf.io/resourceName: openshift.io/mlxnics <.>
spec:
  config: '{"cniVersion":"0.3.1","name":"ovn-kubernetes","type":"ovn-k8s-cni-overlay","ipam":{},"dns":{}}'

Copy to Clipboard

Toggle word wrap

<.> Le nom de la définition de la pièce jointe au réseau. <.> L'espace de noms pour votre définition de pièce jointe au réseau. <.> Il s'agit de la valeur du champ spec.resourceName que vous avez spécifiée dans l'objet SriovNetworkNodePolicy.

Appliquer la configuration pour la définition de l'attachement au réseau :
```
oc create -f net-attach-def.yaml
```
```
$ oc create -f net-attach-def.yaml
```
Copy to Clipboard Toggle word wrap

Vérification

Exécutez la commande suivante pour vérifier si la nouvelle définition est présente :
```
oc get net-attach-def -A
```
```
$ oc get net-attach-def -A
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
NAMESPACE         NAME             AGE
net-attach-def    net-attach-def   43h
```
```
NAMESPACE         NAME             AGE
net-attach-def    net-attach-def   43h
```
Copy to Clipboard Toggle word wrap

23.12.7. Ajouter la définition de l'attachement réseau à vos pods
Copier lien

Après avoir créé le pool de configuration machine, les ressources personnalisées SriovNetworkPoolConfig et SriovNetworkNodePolicy et la définition de l'attachement au réseau, vous pouvez appliquer ces configurations à vos modules en ajoutant la définition de l'attachement au réseau aux spécifications de votre module.

Procédure

Dans la spécification du pod, ajoutez le champ .metadata.annotations.k8s.v1.cni.cncf.io/networks et indiquez la définition de l'attachement réseau que vous avez créée pour le déchargement matériel :
```
....
metadata:
  annotations:
    v1.multus-cni.io/default-network: net-attach-def/net-attach-def <.>
```
```
....
metadata:
  annotations:
    v1.multus-cni.io/default-network: net-attach-def/net-attach-def <.>
```
Copy to Clipboard Toggle word wrap
<.> La valeur doit être le nom et l'espace de noms de la définition de l'attachement réseau que vous avez créée pour le déchargement matériel.

23.13. Passage de Bluefield-2 de DPU à NIC
Copier lien

Vous pouvez faire passer le périphérique réseau Bluefield-2 du mode unité de traitement des données (DPU) au mode contrôleur d'interface réseau (NIC).

Important

Le passage de Bluefield-2 du mode unité de traitement des données (DPU) au mode contrôleur d'interface réseau (NIC) est une fonctionnalité de l'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas leur utilisation en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

23.13.1. Passage de Bluefield-2 du mode DPU au mode NIC
Copier lien

Utilisez la procédure suivante pour faire passer Bluefield-2 du mode unités de traitement des données (DPU) au mode contrôleur d'interface réseau (NIC).

Important

Actuellement, seul le passage de Bluefield-2 du mode DPU au mode NIC est pris en charge. Le passage du mode NIC au mode DPU n'est pas pris en charge.

Conditions préalables

Vous avez installé l'opérateur de réseau SR-IOV. Pour plus d'informations, voir "Installation de l'opérateur de réseau SR-IOV".
Vous avez mis à jour Bluefield-2 avec le dernier firmware. Pour plus d'informations, voir Firmware for NVIDIA BlueField-2.

Procédure

Ajoutez les étiquettes suivantes à chacun de vos nœuds de travail en entrant les commandes suivantes :

oc label node <example_node_name_one> node-role.kubernetes.io/sriov=

$ oc label node <example_node_name_one> node-role.kubernetes.io/sriov=

Copy to Clipboard

Toggle word wrap

oc label node <example_nom_du_node_deux> node-role.kubernetes.io/sriov= $ oc label node <example_nom_du_node_deux> rôle

oc label node <example_nom_du_node_deux> node-role.kubernetes.io/sriov= $ oc label node <example_nom_du_node_deux> rôle

Copy to Clipboard

Toggle word wrap

Créez un pool de configuration de machines pour l'opérateur SR-IOV, par exemple :

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: sriov
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,sriov]}
  nodeSelector:
    matchLabels:
            node-role.kubernetes.io/sriov: ""

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: sriov
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,sriov]}
  nodeSelector:
    matchLabels:
            node-role.kubernetes.io/sriov: ""

Copy to Clipboard

Toggle word wrap

Appliquez le fichier machineconfig.yaml suivant aux nœuds de travail :

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: sriov
  name: 99-bf2-dpu
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,ZmluZF9jb250YWluZXIoKSB7CiAgY3JpY3RsIHBzIC1vIGpzb24gfCBqcSAtciAnLmNvbnRhaW5lcnNbXSB8IHNlbGVjdCgubWV0YWRhdGEubmFtZT09InNyaW92LW5ldHdvcmstY29uZmlnLWRhZW1vbiIpIHwgLmlkJwp9CnVudGlsIG91dHB1dD0kKGZpbmRfY29udGFpbmVyKTsgW1sgLW4gIiRvdXRwdXQiIF1dOyBkbwogIGVjaG8gIndhaXRpbmcgZm9yIGNvbnRhaW5lciB0byBjb21lIHVwIgogIHNsZWVwIDE7CmRvbmUKISBzdWRvIGNyaWN0bCBleGVjICRvdXRwdXQgL2JpbmRhdGEvc2NyaXB0cy9iZjItc3dpdGNoLW1vZGUuc2ggIiRAIgo=
        mode: 0755
        overwrite: true
        path: /etc/default/switch_in_sriov_config_daemon.sh
    systemd:
      units:
        - name: dpu-switch.service
          enabled: true
          contents: |
            [Unit]
            Description=Switch BlueField2 card to NIC/DPU mode
            RequiresMountsFor=%t/containers
            Wants=network.target
            After=network-online.target kubelet.service
            [Service]
            SuccessExitStatus=0 120
            RemainAfterExit=True
            ExecStart=/bin/bash -c '/etc/default/switch_in_sriov_config_daemon.sh nic || shutdown -r now' 
            Type=oneshot
            [Install]
            WantedBy=multi-user.target

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: sriov
  name: 99-bf2-dpu
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,ZmluZF9jb250YWluZXIoKSB7CiAgY3JpY3RsIHBzIC1vIGpzb24gfCBqcSAtciAnLmNvbnRhaW5lcnNbXSB8IHNlbGVjdCgubWV0YWRhdGEubmFtZT09InNyaW92LW5ldHdvcmstY29uZmlnLWRhZW1vbiIpIHwgLmlkJwp9CnVudGlsIG91dHB1dD0kKGZpbmRfY29udGFpbmVyKTsgW1sgLW4gIiRvdXRwdXQiIF1dOyBkbwogIGVjaG8gIndhaXRpbmcgZm9yIGNvbnRhaW5lciB0byBjb21lIHVwIgogIHNsZWVwIDE7CmRvbmUKISBzdWRvIGNyaWN0bCBleGVjICRvdXRwdXQgL2JpbmRhdGEvc2NyaXB0cy9iZjItc3dpdGNoLW1vZGUuc2ggIiRAIgo=
        mode: 0755
        overwrite: true
        path: /etc/default/switch_in_sriov_config_daemon.sh
    systemd:
      units:
        - name: dpu-switch.service
          enabled: true
          contents: |
            [Unit]
            Description=Switch BlueField2 card to NIC/DPU mode
            RequiresMountsFor=%t/containers
            Wants=network.target
            After=network-online.target kubelet.service
            [Service]
            SuccessExitStatus=0 120
            RemainAfterExit=True
            ExecStart=/bin/bash -c '/etc/default/switch_in_sriov_config_daemon.sh nic || shutdown -r now'

1


            Type=oneshot
            [Install]
            WantedBy=multi-user.target

Copy to Clipboard

Toggle word wrap

1: Optionnel : L'adresse PCI d'une carte spécifique peut être spécifiée en option, par exemple ExecStart=/bin/bash -c '/etc/default/switch_in_sriov_config_daemon.sh nic 0000:5e:00.0 || echo done'. Par défaut, le premier appareil est sélectionné. S'il y a plus d'un périphérique, vous devez spécifier l'adresse PCI à utiliser. L'adresse PCI doit être la même sur tous les nœuds qui font passer Bluefield-2 du mode DPU au mode NIC.

Attendez que les nœuds de travail redémarrent. Après le redémarrage, le périphérique réseau Bluefield-2 sur les nœuds de travailleur passe en mode NIC.

23.14. Désinstallation de l'opérateur de réseau SR-IOV
Copier lien

Pour désinstaller l'opérateur de réseau SR-IOV, vous devez supprimer toutes les charges de travail SR-IOV en cours d'exécution, désinstaller l'opérateur et supprimer les webhooks utilisés par l'opérateur.

23.14.1. Désinstallation de l'opérateur de réseau SR-IOV
Copier lien

En tant qu'administrateur de cluster, vous pouvez désinstaller l'opérateur de réseau SR-IOV.

Conditions préalables

Vous avez accès à un cluster OpenShift Container Platform en utilisant un compte avec des permissions cluster-admin.
Vous avez installé l'opérateur de réseau SR-IOV.

Procédure

Supprimer toutes les ressources personnalisées (CR) SR-IOV :

oc delete sriovnetwork -n openshift-sriov-network-operator --all

$ oc delete sriovnetwork -n openshift-sriov-network-operator --all

Copy to Clipboard

Toggle word wrap

oc delete sriovnetworknodepolicy -n openshift-sriov-network-operator --all

$ oc delete sriovnetworknodepolicy -n openshift-sriov-network-operator --all

Copy to Clipboard

Toggle word wrap

oc delete sriovibnetwork -n openshift-sriov-network-operator --all

$ oc delete sriovibnetwork -n openshift-sriov-network-operator --all

Copy to Clipboard

Toggle word wrap

Suivez les instructions de la section "Suppression des opérateurs d'une grappe" pour supprimer l'opérateur de réseau SR-IOV de votre grappe.

Supprimer les définitions de ressources personnalisées SR-IOV qui restent dans le cluster après la désinstallation de l'opérateur de réseau SR-IOV :

oc delete crd sriovibnetworks.sriovnetwork.openshift.io

$ oc delete crd sriovibnetworks.sriovnetwork.openshift.io

Copy to Clipboard

Toggle word wrap

oc delete crd sriovnetworknodepolicies.sriovnetwork.openshift.io

$ oc delete crd sriovnetworknodepolicies.sriovnetwork.openshift.io

Copy to Clipboard

Toggle word wrap

oc delete crd sriovnetworknodestates.sriovnetwork.openshift.io

$ oc delete crd sriovnetworknodestates.sriovnetwork.openshift.io

Copy to Clipboard

Toggle word wrap

oc delete crd sriovnetworkpoolconfigs.sriovnetwork.openshift.io

$ oc delete crd sriovnetworkpoolconfigs.sriovnetwork.openshift.io

Copy to Clipboard

Toggle word wrap

oc delete crd sriovnetworks.sriovnetwork.openshift.io

$ oc delete crd sriovnetworks.sriovnetwork.openshift.io

Copy to Clipboard

Toggle word wrap

oc delete crd sriovoperatorconfigs.sriovnetwork.openshift.io

$ oc delete crd sriovoperatorconfigs.sriovnetwork.openshift.io

Copy to Clipboard

Toggle word wrap

Supprimer les webhooks SR-IOV :

oc delete mutatingwebhookconfigurations network-resources-injector-config

$ oc delete mutatingwebhookconfigurations network-resources-injector-config

Copy to Clipboard

Toggle word wrap

oc delete MutatingWebhookConfiguration sriov-operator-webhook-config

$ oc delete MutatingWebhookConfiguration sriov-operator-webhook-config

Copy to Clipboard

Toggle word wrap

oc delete ValidatingWebhookConfiguration sriov-operator-webhook-config

$ oc delete ValidatingWebhookConfiguration sriov-operator-webhook-config

Copy to Clipboard

Toggle word wrap

Supprimer l'espace de noms de l'opérateur de réseau SR-IOV :
```
oc delete namespace openshift-sriov-network-operator
```
```
$ oc delete namespace openshift-sriov-network-operator
```
Copy to Clipboard Toggle word wrap

Chapitre 24. Plugin réseau OVN-Kubernetes
Copier lien

24.1. À propos du plugin réseau OVN-Kubernetes
Copier lien

Le cluster OpenShift Container Platform utilise un réseau virtualisé pour les réseaux de pods et de services.

Faisant partie de Red Hat OpenShift Networking, le plugin réseau OVN-Kubernetes est le fournisseur de réseau par défaut pour OpenShift Container Platform. OVN-Kubernetes est basé sur Open Virtual Network (OVN) et fournit une implémentation de réseau basée sur la superposition. Un cluster qui utilise le plugin OVN-Kubernetes exécute également Open vSwitch (OVS) sur chaque nœud. OVN configure OVS sur chaque nœud pour mettre en œuvre la configuration réseau déclarée.

Note

OVN-Kubernetes est la solution de mise en réseau par défaut pour OpenShift Container Platform et les déploiements OpenShift à nœud unique.

OVN-Kubernetes, issu du projet OVS, utilise un grand nombre des mêmes constructions, telles que les règles de flux ouvertes, pour déterminer comment les paquets voyagent à travers le réseau. Pour plus d'informations, consultez le site web de l'Open Virtual Network.

OVN-Kubernetes est une série de démons pour OVS qui traduisent les configurations de réseaux virtuels en règles OpenFlow. OpenFlow est un protocole de communication avec les commutateurs et les routeurs de réseau, fournissant un moyen de contrôler à distance le flux du trafic réseau sur un périphérique de réseau, permettant aux administrateurs de réseau de configurer, de gérer et de surveiller le flux du trafic réseau.

OVN-Kubernetes offre davantage de fonctionnalités avancées qui ne sont pas disponibles sur OpenFlow. OVN prend en charge le routage virtuel distribué, les commutateurs logiques distribués, le contrôle d'accès, le DHCP et le DNS. OVN met en œuvre le routage virtuel distribué dans des flux logiques qui équivalent à des flux ouverts. Par exemple, si vous avez un pod qui envoie une requête DHCP sur le réseau, il envoie une diffusion à la recherche d'une adresse DHCP, il y aura une règle de flux logique qui correspondra à ce paquet et qui répondra en lui donnant une passerelle, un serveur DNS, une adresse IP et ainsi de suite.

OVN-Kubernetes exécute un démon sur chaque nœud. Il existe des ensembles de démons pour les bases de données et pour le contrôleur OVN qui s'exécutent sur chaque nœud. Le contrôleur OVN programme le démon Open vSwitch sur les nœuds pour prendre en charge les fonctionnalités du fournisseur de réseau : IP de sortie, pare-feu, routeurs, réseau hybride, cryptage IPSEC, IPv6, politique de réseau, journaux de politique de réseau, délestage matériel et multidiffusion.

24.1.1. Objectif OVN-Kubernetes
Copier lien

Le plugin réseau OVN-Kubnernetes est un plugin CNI Kubernetes open-source et entièrement fonctionnel qui utilise Open Virtual Network (OVN) pour gérer les flux de trafic réseau. OVN est une solution de virtualisation de réseau développée par la communauté et agnostique vis-à-vis des fournisseurs. Le plugin réseau OVN-Kubnernetes :

Utilise OVN (Open Virtual Network) pour gérer les flux de trafic du réseau. OVN est une solution de virtualisation de réseau développée par la communauté et indépendante des fournisseurs.
Met en œuvre la prise en charge de la politique réseau de Kubernetes, y compris les règles d'entrée et de sortie.
Utilise le protocole Geneve (Generic Network Virtualization Encapsulation) plutôt que VXLAN pour créer un réseau superposé entre les nœuds.

Le plugin réseau OVN-Kubernetes présente les avantages suivants par rapport à OpenShift SDN.

Prise en charge complète des réseaux IPv6 à pile unique et IPv4/IPv6 à double pile sur les plates-formes prises en charge
Prise en charge des clusters hybrides avec des charges de travail Linux et Microsoft Windows
Cryptage IPsec facultatif des communications à l'intérieur du cluster
Déchargement du traitement des données réseau de l'unité centrale vers des cartes réseau et des unités de traitement des données (DPU) compatibles

24.1.2. Matrice des caractéristiques des plugins réseau pris en charge
Copier lien

Red Hat OpenShift Networking offre deux options pour le plugin réseau, OpenShift SDN et OVN-Kubernetes, pour le plugin réseau. Le tableau suivant résume la prise en charge actuelle des fonctionnalités pour les deux plugins réseau :

Expand

Tableau 24.1. Comparaison des fonctionnalités du plugin réseau CNI par défaut
Fonctionnalité	OVN-Kubernetes	OpenShift SDN
IP de sortie	Soutenu	Soutenu
Pare-feu de sortie ^[1]	Soutenu	Soutenu
Routeur de sortie	Soutenu ^[2]	Soutenu
Réseau hybride	Soutenu	Non pris en charge
Cryptage IPsec pour les communications à l'intérieur du cluster	Soutenu	Non pris en charge
IPv6	Soutenu ^[3]	Non pris en charge
Politique de réseau Kubernetes	Soutenu	Soutenu
Journaux de la politique réseau de Kubernetes	Soutenu	Non pris en charge
Déchargement du matériel	Soutenu	Non pris en charge
Multidiffusion	Soutenu	Soutenu

Le pare-feu de sortie est également connu sous le nom de politique de réseau de sortie dans OpenShift SDN. Ce n'est pas la même chose que la politique de réseau de sortie.
Le routeur de sortie pour OVN-Kubernetes ne prend en charge que le mode de redirection.
IPv6 n'est pris en charge que sur les clusters bare metal, IBM Power et IBM zSystems.

24.1.3. OVN-Kubernetes IPv6 et limitations de la double pile
Copier lien

Le plugin réseau OVN-Kubernetes a les limitations suivantes :

Pour les clusters configurés pour un réseau à double pile, le trafic IPv4 et IPv6 doit utiliser la même interface réseau comme passerelle par défaut. Si cette condition n'est pas remplie, les modules sur l'hôte dans l'ensemble de démons ovnkube-node entrent dans l'état CrashLoopBackOff. Si vous affichez un pod avec une commande telle que oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml, le champ status contient plus d'un message sur la passerelle par défaut, comme le montre la sortie suivante :
```
I1006 16:09:50.985852   60651 helper_linux.go:73] Found default gateway interface br-ex 192.168.127.1
I1006 16:09:50.985923   60651 helper_linux.go:73] Found default gateway interface ens4 fe80::5054:ff:febe:bcd4
F1006 16:09:50.985939   60651 ovnkube.go:130] multiple gateway interfaces detected: br-ex ens4
```
```
I1006 16:09:50.985852   60651 helper_linux.go:73] Found default gateway interface br-ex 192.168.127.1
I1006 16:09:50.985923   60651 helper_linux.go:73] Found default gateway interface ens4 fe80::5054:ff:febe:bcd4
F1006 16:09:50.985939   60651 ovnkube.go:130] multiple gateway interfaces detected: br-ex ens4
```
Copy to Clipboard Toggle word wrap
La seule solution consiste à reconfigurer le réseau de l'hôte de manière à ce que les deux familles IP utilisent la même interface réseau pour la passerelle par défaut.
Pour les clusters configurés pour un réseau à double pile, les tables de routage IPv4 et IPv6 doivent contenir la passerelle par défaut. Si cette condition n'est pas remplie, les modules sur l'hôte dans l'ensemble de démons ovnkube-node entrent dans l'état CrashLoopBackOff. Si vous affichez un pod avec une commande telle que oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml, le champ status contient plus d'un message sur la passerelle par défaut, comme le montre la sortie suivante :
```
I0512 19:07:17.589083  108432 helper_linux.go:74] Found default gateway interface br-ex 192.168.123.1
F0512 19:07:17.589141  108432 ovnkube.go:133] failed to get default gateway interface
```
```
I0512 19:07:17.589083  108432 helper_linux.go:74] Found default gateway interface br-ex 192.168.123.1
F0512 19:07:17.589141  108432 ovnkube.go:133] failed to get default gateway interface
```
Copy to Clipboard Toggle word wrap
La seule solution consiste à reconfigurer le réseau de l'hôte de manière à ce que les deux familles IP contiennent la passerelle par défaut.

24.1.4. Affinité de session
Copier lien

L'affinité de session est une fonctionnalité qui s'applique aux objets Kubernetes Service. Vous pouvez utiliser session affinity si vous voulez vous assurer qu'à chaque fois que vous vous connectez à un <service_VIP>:<Port>, le trafic est toujours équilibré en charge vers le même back-end. Pour plus d'informations, notamment sur la manière de définir l'affinité de session en fonction de l'adresse IP d'un client, voir Affinité de session.

Délai d'attente pour l'affinité de session

Le plugin réseau OVN-Kubernetes pour OpenShift Container Platform calcule le délai d'attente pour une session à partir d'un client sur la base du dernier paquet. Par exemple, si vous exécutez la commande curl 10 fois, le délai de la session collante commence à partir du dixième paquet et non du premier. Par conséquent, si le client contacte continuellement le service, la session n'est jamais interrompue. Le délai d'attente démarre lorsque le service n'a pas reçu de paquet pendant la durée définie par le paramètre timeoutSeconds paramètre.

24.2. Architecture OVN-Kubernetes
Copier lien

24.2.1. Introduction à l'architecture OVN-Kubernetes
Copier lien

Le schéma suivant présente l'architecture OVN-Kubernetes.

Figure 24.1. Architecture OVK-Kubernetes

Les éléments clés sont les suivants :

Cloud Management System (CMS) - Un client spécifique à la plateforme pour OVN qui fournit un plugin spécifique au CMS pour l'intégration d'OVN. Le plugin traduit le concept de configuration logique du réseau du système de gestion en nuage, stocké dans la base de données de configuration du CMS dans un format spécifique au CMS, en une représentation intermédiaire comprise par OVN.
OVN Northbound database (nbdb) - Stocke la configuration logique du réseau transmise par le plugin CMS.
OVN Southbound database (sbdb) - Stocke l'état de la configuration physique et logique du réseau pour le système OpenVswitch (OVS) sur chaque nœud, y compris les tables qui les lient.
ovn-northd - Il s'agit du client intermédiaire entre nbdb et sbdb. Il traduit la configuration logique du réseau en termes de concepts de réseau conventionnels, tirés de nbdb, en flux de chemins de données logiques dans sbdb en dessous de lui. Le nom du conteneur est northd et il fonctionne dans les pods ovnkube-master.
ovn-controller - Il s'agit de l'agent OVN qui interagit avec OVS et les hyperviseurs pour toute information ou mise à jour nécessaire à sbdb. Le ovn-controller lit les flux logiques depuis le sbdb, les traduit en flux OpenFlow et les envoie au démon OVS du nœud. Le nom du conteneur est ovn-controller et il s'exécute dans les pods ovnkube-node.

La base de données OVN northbound possède la configuration logique du réseau qui lui a été transmise par le système de gestion des nuages (CMS). La base de données OVN northbound contient l'état actuel souhaité du réseau, présenté comme une collection de ports logiques, de commutateurs logiques, de routeurs logiques, etc. Le ovn-northd (conteneurnorthd ) se connecte à la base de données OVN northbound et à la base de données OVN southbound. Il traduit la configuration logique du réseau en termes de concepts de réseau conventionnels, tirés de la base de données OVN northbound, en flux de chemins de données logiques dans la base de données OVN southbound.

La base de données southbound d'OVN contient des représentations physiques et logiques du réseau et des tables de liaison qui les relient. Chaque nœud du cluster est représenté dans la base de données southbound, et vous pouvez voir les ports qui y sont connectés. Elle contient également tous les flux logiques, qui sont partagés avec le processus ovn-controller qui s'exécute sur chaque nœud et que ovn-controller transforme en règles OpenFlow pour programmer Open vSwitch.

Les nœuds du plan de contrôle Kubernetes contiennent chacun un pod ovnkube-master qui héberge des conteneurs pour les bases de données OVN northbound et southbound. Toutes les bases de données OVN en direction du nord forment un cluster Raft et toutes les bases de données en direction du sud forment un cluster Raft distinct. À tout moment, un seul ovnkube-master est le leader et les autres pods ovnkube-master sont des suiveurs.

24.2.2. Liste de toutes les ressources du projet OVN-Kubernetes
Copier lien

Il est important de trouver les ressources et les conteneurs qui fonctionnent dans le projet OVN-Kubernetes pour vous aider à comprendre la mise en œuvre du réseau OVN-Kubernetes.

Conditions préalables

Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
L'OpenShift CLI (oc) est installé.

Procédure

Exécutez la commande suivante pour obtenir toutes les ressources, les points de terminaison et ConfigMaps dans le projet OVN-Kubernetes :

oc get all,ep,cm -n openshift-ovn-kubernetes

$ oc get all,ep,cm -n openshift-ovn-kubernetes

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                       READY   STATUS    RESTARTS      AGE
pod/ovnkube-master-9g7zt   6/6     Running   1 (48m ago)   57m
pod/ovnkube-master-lqs4v   6/6     Running   0             57m
pod/ovnkube-master-vxhtq   6/6     Running   0             57m
pod/ovnkube-node-9k9kc     5/5     Running   0             57m
pod/ovnkube-node-jg52r     5/5     Running   0             51m
pod/ovnkube-node-k8wf7     5/5     Running   0             57m
pod/ovnkube-node-tlwk6     5/5     Running   0             47m
pod/ovnkube-node-xsvnk     5/5     Running   0             57m

NAME                            TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)             AGE
service/ovn-kubernetes-master   ClusterIP   None         <none>        9102/TCP            57m
service/ovn-kubernetes-node     ClusterIP   None         <none>        9103/TCP,9105/TCP   57m
service/ovnkube-db              ClusterIP   None         <none>        9641/TCP,9642/TCP   57m

NAME                            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                                                 AGE
daemonset.apps/ovnkube-master   3         3         3       3            3           beta.kubernetes.io/os=linux,node-role.kubernetes.io/master=   57m
daemonset.apps/ovnkube-node     5         5         5       5            5           beta.kubernetes.io/os=linux                                   57m

NAME                              ENDPOINTS                                                        AGE
endpoints/ovn-kubernetes-master   10.0.132.11:9102,10.0.151.18:9102,10.0.192.45:9102               57m
endpoints/ovn-kubernetes-node     10.0.132.11:9105,10.0.143.72:9105,10.0.151.18:9105 + 7 more...   57m
endpoints/ovnkube-db              10.0.132.11:9642,10.0.151.18:9642,10.0.192.45:9642 + 3 more...   57m

NAME                                 DATA   AGE
configmap/control-plane-status       1      55m
configmap/kube-root-ca.crt           1      57m
configmap/openshift-service-ca.crt   1      57m
configmap/ovn-ca                     1      57m
configmap/ovn-kubernetes-master      0      55m
configmap/ovnkube-config             1      57m
configmap/signer-ca                  1      57m

NAME                       READY   STATUS    RESTARTS      AGE
pod/ovnkube-master-9g7zt   6/6     Running   1 (48m ago)   57m
pod/ovnkube-master-lqs4v   6/6     Running   0             57m
pod/ovnkube-master-vxhtq   6/6     Running   0             57m
pod/ovnkube-node-9k9kc     5/5     Running   0             57m
pod/ovnkube-node-jg52r     5/5     Running   0             51m
pod/ovnkube-node-k8wf7     5/5     Running   0             57m
pod/ovnkube-node-tlwk6     5/5     Running   0             47m
pod/ovnkube-node-xsvnk     5/5     Running   0             57m

NAME                            TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)             AGE
service/ovn-kubernetes-master   ClusterIP   None         <none>        9102/TCP            57m
service/ovn-kubernetes-node     ClusterIP   None         <none>        9103/TCP,9105/TCP   57m
service/ovnkube-db              ClusterIP   None         <none>        9641/TCP,9642/TCP   57m

NAME                            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                                                 AGE
daemonset.apps/ovnkube-master   3         3         3       3            3           beta.kubernetes.io/os=linux,node-role.kubernetes.io/master=   57m
daemonset.apps/ovnkube-node     5         5         5       5            5           beta.kubernetes.io/os=linux                                   57m

NAME                              ENDPOINTS                                                        AGE
endpoints/ovn-kubernetes-master   10.0.132.11:9102,10.0.151.18:9102,10.0.192.45:9102               57m
endpoints/ovn-kubernetes-node     10.0.132.11:9105,10.0.143.72:9105,10.0.151.18:9105 + 7 more...   57m
endpoints/ovnkube-db              10.0.132.11:9642,10.0.151.18:9642,10.0.192.45:9642 + 3 more...   57m

NAME                                 DATA   AGE
configmap/control-plane-status       1      55m
configmap/kube-root-ca.crt           1      57m
configmap/openshift-service-ca.crt   1      57m
configmap/ovn-ca                     1      57m
configmap/ovn-kubernetes-master      0      55m
configmap/ovnkube-config             1      57m
configmap/signer-ca                  1      57m

Copy to Clipboard

Toggle word wrap

Trois sites ovnkube-masters sont exécutés sur les nœuds du plan de contrôle, et deux ensembles de démons sont utilisés pour déployer les modules ovnkube-master et ovnkube-node. Il y a un pod ovnkube-node pour chaque nœud du cluster. Dans cet exemple, il y en a 5, et comme il y a un ovnkube-node par nœud dans le cluster, il y a cinq nœuds dans le cluster. Le pod ovnkube-config ConfigMap contient les configurations OpenShift Container Platform OVN-Kubernetes démarrées par online-master et ovnkube-node. Le site ovn-kubernetes-master ConfigMap contient les informations sur le maître en ligne actuel.

Listez tous les conteneurs dans les pods ovnkube-master en exécutant la commande suivante :
```
oc get pods ovnkube-master-9g7zt \
-o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes
```
```
$ oc get pods ovnkube-master-9g7zt \
-o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes
```
Copy to Clipboard Toggle word wrap
Résultats attendus
```
northd nbdb kube-rbac-proxy sbdb ovnkube-master ovn-dbchecker
```
```
northd nbdb kube-rbac-proxy sbdb ovnkube-master ovn-dbchecker
```
Copy to Clipboard Toggle word wrap
Le pod ovnkube-master est composé de plusieurs conteneurs. Il est responsable de l'hébergement de la base de données nord (conteneurnbdb ), de la base de données sud (conteneursbdb ), de la surveillance des événements du cluster pour les pods, egressIP, namespaces, services, endpoints, egress firewall et network policy et de leur écriture dans la base de données nord (podovnkube-master ), ainsi que de la gestion de l'allocation des sous-réseaux des pods aux nœuds.
Listez tous les conteneurs dans les pods ovnkube-node en exécutant la commande suivante :
```
oc get pods ovnkube-node-jg52r \
-o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes
```
```
$ oc get pods ovnkube-node-jg52r \
-o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes
```
Copy to Clipboard Toggle word wrap
Résultats attendus
```
ovn-controller ovn-acl-logging kube-rbac-proxy kube-rbac-proxy-ovn-metrics ovnkube-node
```
```
ovn-controller ovn-acl-logging kube-rbac-proxy kube-rbac-proxy-ovn-metrics ovnkube-node
```
Copy to Clipboard Toggle word wrap
Le pod ovnkube-node a un conteneur (ovn-controller) qui réside sur chaque nœud d'OpenShift Container Platform. Le site ovn-controller de chaque nœud connecte la base de données OVN northbound à la base de données OVN southbound pour connaître la configuration OVN. Le ovn-controller se connecte au sud au ovs-vswitchd en tant que contrôleur OpenFlow, pour contrôler le trafic réseau, et au ovsdb-server local pour lui permettre de surveiller et de contrôler la configuration de l'Open vSwitch.

24.2.3. Liste du contenu de la base de données OVN-Kubernetes northbound
Copier lien

Pour comprendre les règles de flux logique, il faut examiner la base de données de la connexion nord et comprendre quels objets s'y trouvent pour voir comment ils sont traduits en règles de flux logique. L'information à jour est présente sur l'OVN Raft leader et cette procédure décrit comment trouver le Raft leader et ensuite l'interroger pour lister le contenu de la base de données de la liaison nord de l'OVN.

Conditions préalables

Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
L'OpenShift CLI (oc) est installé.

Procédure

Trouver le chef de file du radeau OVN pour la base de données en direction du nord.

Note

Le chef de file du radeau stocke les informations les plus récentes.

Dressez la liste des pods en exécutant la commande suivante :

oc get po -n openshift-ovn-kubernetes

$ oc get po -n openshift-ovn-kubernetes

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                   READY   STATUS    RESTARTS       AGE
ovnkube-master-7j97q   6/6     Running   2 (148m ago)   149m
ovnkube-master-gt4ms   6/6     Running   1 (140m ago)   147m
ovnkube-master-mk6p6   6/6     Running   0              148m
ovnkube-node-8qvtr     5/5     Running   0              149m
ovnkube-node-fqdc9     5/5     Running   0              149m
ovnkube-node-tlfwv     5/5     Running   0              149m
ovnkube-node-wlwkn     5/5     Running   0              142m

NAME                   READY   STATUS    RESTARTS       AGE
ovnkube-master-7j97q   6/6     Running   2 (148m ago)   149m
ovnkube-master-gt4ms   6/6     Running   1 (140m ago)   147m
ovnkube-master-mk6p6   6/6     Running   0              148m
ovnkube-node-8qvtr     5/5     Running   0              149m
ovnkube-node-fqdc9     5/5     Running   0              149m
ovnkube-node-tlfwv     5/5     Running   0              149m
ovnkube-node-wlwkn     5/5     Running   0              142m

Copy to Clipboard

Toggle word wrap

Choisissez au hasard l'un des pods maîtres et exécutez la commande suivante :

oc exec -n openshift-ovn-kubernetes ovnkube-master-7j97q \
-- /usr/bin/ovn-appctl -t /var/run/ovn/ovnnb_db.ctl \
--timeout=3 cluster/status OVN_Northbound

$ oc exec -n openshift-ovn-kubernetes ovnkube-master-7j97q \
-- /usr/bin/ovn-appctl -t /var/run/ovn/ovnnb_db.ctl \
--timeout=3 cluster/status OVN_Northbound

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Defaulted container "northd" out of: northd, nbdb, kube-rbac-proxy, sbdb, ovnkube-master, ovn-dbchecker
1c57
Name: OVN_Northbound
Cluster ID: c48a (c48aa5c0-a704-4c77-a066-24fe99d9b338)
Server ID: 1c57 (1c57b6fc-2849-49b7-8679-fbf18bafe339)
Address: ssl:10.0.147.219:9643
Status: cluster member
Role: follower 
Term: 5
Leader: 2b4f 
Vote: unknown

Election timer: 10000
Log: [2, 3018]
Entries not yet committed: 0
Entries not yet applied: 0
Connections: ->0000 ->0000 <-8844 <-2b4f
Disconnections: 0
Servers:
    1c57 (1c57 at ssl:10.0.147.219:9643) (self)
    8844 (8844 at ssl:10.0.163.212:9643) last msg 8928047 ms ago
    2b4f (2b4f at ssl:10.0.242.240:9643) last msg 620 ms ago

Defaulted container "northd" out of: northd, nbdb, kube-rbac-proxy, sbdb, ovnkube-master, ovn-dbchecker
1c57
Name: OVN_Northbound
Cluster ID: c48a (c48aa5c0-a704-4c77-a066-24fe99d9b338)
Server ID: 1c57 (1c57b6fc-2849-49b7-8679-fbf18bafe339)
Address: ssl:10.0.147.219:9643
Status: cluster member
Role: follower

1


Term: 5
Leader: 2b4f

2


Vote: unknown

Election timer: 10000
Log: [2, 3018]
Entries not yet committed: 0
Entries not yet applied: 0
Connections: ->0000 ->0000 <-8844 <-2b4f
Disconnections: 0
Servers:
    1c57 (1c57 at ssl:10.0.147.219:9643) (self)
    8844 (8844 at ssl:10.0.163.212:9643) last msg 8928047 ms ago
    2b4f (2b4f at ssl:10.0.242.240:9643) last msg 620 ms ago

3

Copy to Clipboard

Toggle word wrap

1: Ce pod est identifié comme un suiveur
2: Le leader est identifié comme 2b4f
3: Le site 2b4f est sur l'adresse IP 10.0.242.240

Recherchez le pod ovnkube-master fonctionnant sur l'adresse IP 10.0.242.240 à l'aide de la commande suivante :

oc get po -o wide -n openshift-ovn-kubernetes | grep 10.0.242.240 | grep -v ovnkube-node

$ oc get po -o wide -n openshift-ovn-kubernetes | grep 10.0.242.240 | grep -v ovnkube-node

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ovnkube-master-gt4ms   6/6     Running             1 (143m ago)   150m   10.0.242.240   ip-10-0-242-240.ec2.internal   <none>           <none>

ovnkube-master-gt4ms   6/6     Running             1 (143m ago)   150m   10.0.242.240   ip-10-0-242-240.ec2.internal   <none>           <none>

Copy to Clipboard

Toggle word wrap

Le pod ovnkube-master-gt4ms fonctionne sur l'adresse IP 10.0.242.240.

Exécutez la commande suivante pour afficher tous les objets de la base de données northbound :
```
oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \
-c northd -- ovn-nbctl show
```
```
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \
-c northd -- ovn-nbctl show
```
Copy to Clipboard Toggle word wrap
Le résultat est trop long pour être énuméré ici. La liste comprend les règles NAT, les commutateurs logiques, les équilibreurs de charge, etc.
Exécutez la commande suivante pour afficher les options disponibles avec la commande ovn-nbctl:
```
oc exec -n openshift-ovn-kubernetes -it ovnkube-master-mk6p6 \
-c northd ovn-nbctl --help
```
```
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-mk6p6 \
-c northd ovn-nbctl --help
```
Copy to Clipboard Toggle word wrap
Vous pouvez vous concentrer sur des composants spécifiques en utilisant certaines des commandes suivantes :

Exécutez la commande suivante pour afficher la liste des routeurs logiques :

oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \
-c northd -- ovn-nbctl lr-list

$ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \
-c northd -- ovn-nbctl lr-list

Copy to Clipboard

Toggle word wrap

Exemple de sortie

f971f1f3-5112-402f-9d1e-48f1d091ff04 (GR_ip-10-0-145-205.ec2.internal)
69c992d8-a4cf-429e-81a3-5361209ffe44 (GR_ip-10-0-147-219.ec2.internal)
7d164271-af9e-4283-b84a-48f2a44851cd (GR_ip-10-0-163-212.ec2.internal)
111052e3-c395-408b-97b2-8dd0a20a29a5 (GR_ip-10-0-165-9.ec2.internal)
ed50ce33-df5d-48e8-8862-2df6a59169a0 (GR_ip-10-0-209-170.ec2.internal)
f44e2a96-8d1e-4a4d-abae-ed8728ac6851 (GR_ip-10-0-242-240.ec2.internal)
ef3d0057-e557-4b1a-b3c6-fcc3463790b0 (ovn_cluster_router)

f971f1f3-5112-402f-9d1e-48f1d091ff04 (GR_ip-10-0-145-205.ec2.internal)
69c992d8-a4cf-429e-81a3-5361209ffe44 (GR_ip-10-0-147-219.ec2.internal)
7d164271-af9e-4283-b84a-48f2a44851cd (GR_ip-10-0-163-212.ec2.internal)
111052e3-c395-408b-97b2-8dd0a20a29a5 (GR_ip-10-0-165-9.ec2.internal)
ed50ce33-df5d-48e8-8862-2df6a59169a0 (GR_ip-10-0-209-170.ec2.internal)
f44e2a96-8d1e-4a4d-abae-ed8728ac6851 (GR_ip-10-0-242-240.ec2.internal)
ef3d0057-e557-4b1a-b3c6-fcc3463790b0 (ovn_cluster_router)

Copy to Clipboard

Toggle word wrap

Note

Cette sortie montre qu'il y a un routeur sur chaque nœud et un ovn_cluster_router.

Exécutez la commande suivante pour afficher la liste des commutateurs logiques :

oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \
-c northd -- ovn-nbctl ls-list

$ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \
-c northd -- ovn-nbctl ls-list

Copy to Clipboard

Toggle word wrap

Exemple de sortie

82808c5c-b3bc-414a-bb59-8fec4b07eb14 (ext_ip-10-0-145-205.ec2.internal)
3d22444f-0272-4c51-afc6-de9e03db3291 (ext_ip-10-0-147-219.ec2.internal)
bf73b9df-59ab-4c58-a456-ce8205b34ac5 (ext_ip-10-0-163-212.ec2.internal)
bee1e8d0-ec87-45eb-b98b-63f9ec213e5e (ext_ip-10-0-165-9.ec2.internal)
812f08f2-6476-4abf-9a78-635f8516f95e (ext_ip-10-0-209-170.ec2.internal)
f65e710b-32f9-482b-8eab-8d96a44799c1 (ext_ip-10-0-242-240.ec2.internal)
84dad700-afb8-4129-86f9-923a1ddeace9 (ip-10-0-145-205.ec2.internal)
1b7b448b-e36c-4ca3-9f38-4a2cf6814bfd (ip-10-0-147-219.ec2.internal)
d92d1f56-2606-4f23-8b6a-4396a78951de (ip-10-0-163-212.ec2.internal)
6864a6b2-de15-4de3-92d8-f95014b6f28f (ip-10-0-165-9.ec2.internal)
c26bf618-4d7e-4afd-804f-1a2cbc96ec6d (ip-10-0-209-170.ec2.internal)
ab9a4526-44ed-4f82-ae1c-e20da04947d9 (ip-10-0-242-240.ec2.internal)
a8588aba-21da-4276-ba0f-9d68e88911f0 (join)

82808c5c-b3bc-414a-bb59-8fec4b07eb14 (ext_ip-10-0-145-205.ec2.internal)
3d22444f-0272-4c51-afc6-de9e03db3291 (ext_ip-10-0-147-219.ec2.internal)
bf73b9df-59ab-4c58-a456-ce8205b34ac5 (ext_ip-10-0-163-212.ec2.internal)
bee1e8d0-ec87-45eb-b98b-63f9ec213e5e (ext_ip-10-0-165-9.ec2.internal)
812f08f2-6476-4abf-9a78-635f8516f95e (ext_ip-10-0-209-170.ec2.internal)
f65e710b-32f9-482b-8eab-8d96a44799c1 (ext_ip-10-0-242-240.ec2.internal)
84dad700-afb8-4129-86f9-923a1ddeace9 (ip-10-0-145-205.ec2.internal)
1b7b448b-e36c-4ca3-9f38-4a2cf6814bfd (ip-10-0-147-219.ec2.internal)
d92d1f56-2606-4f23-8b6a-4396a78951de (ip-10-0-163-212.ec2.internal)
6864a6b2-de15-4de3-92d8-f95014b6f28f (ip-10-0-165-9.ec2.internal)
c26bf618-4d7e-4afd-804f-1a2cbc96ec6d (ip-10-0-209-170.ec2.internal)
ab9a4526-44ed-4f82-ae1c-e20da04947d9 (ip-10-0-242-240.ec2.internal)
a8588aba-21da-4276-ba0f-9d68e88911f0 (join)

Copy to Clipboard

Toggle word wrap

Note

Cette sortie montre qu'il y a un commutateur ext pour chaque nœud, des commutateurs avec le nom du nœud lui-même et un commutateur join.

Exécutez la commande suivante pour afficher la liste des équilibreurs de charge :

oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \
-c northd -- ovn-nbctl lb-list

$ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \
-c northd -- ovn-nbctl lb-list

Copy to Clipboard

Toggle word wrap

Exemple de sortie

UUID                                    LB                  PROTO      VIP                     IPs
f0fb50f9-4968-4b55-908c-616bae4db0a2    Service_default/    tcp        172.30.0.1:443          10.0.147.219:6443,10.0.163.212:6443,169.254.169.2:6443
0dc42012-4f5b-432e-ae01-2cc4bfe81b00    Service_default/    tcp        172.30.0.1:443          10.0.147.219:6443,169.254.169.2:6443,10.0.242.240:6443
f7fff5d5-5eff-4a40-98b1-3a4ba8f7f69c    Service_default/    tcp        172.30.0.1:443          169.254.169.2:6443,10.0.163.212:6443,10.0.242.240:6443
12fe57a0-50a4-4a1b-ac10-5f288badee07    Service_default/    tcp        172.30.0.1:443          10.0.147.219:6443,10.0.163.212:6443,10.0.242.240:6443
3f137fbf-0b78-4875-ba44-fbf89f254cf7    Service_openshif    tcp        172.30.23.153:443       10.130.0.14:8443
174199fe-0562-4141-b410-12094db922a7    Service_openshif    tcp        172.30.69.51:50051      10.130.0.84:50051
5ee2d4bd-c9e2-4d16-a6df-f54cd17c9ac3    Service_openshif    tcp        172.30.143.87:9001      10.0.145.205:9001,10.0.147.219:9001,10.0.163.212:9001,10.0.165.9:9001,10.0.209.170:9001,10.0.242.240:9001
a056ae3d-83f8-45bc-9c80-ef89bce7b162    Service_openshif    tcp        172.30.164.74:443       10.0.147.219:6443,10.0.163.212:6443,10.0.242.240:6443
bac51f3d-9a6f-4f5e-ac02-28fd343a332a    Service_openshif    tcp        172.30.0.10:53          10.131.0.6:5353
                                                            tcp        172.30.0.10:9154        10.131.0.6:9154
48105bbc-51d7-4178-b975-417433f9c20a    Service_openshif    tcp        172.30.26.159:2379      10.0.147.219:2379,169.254.169.2:2379,10.0.242.240:2379
                                                            tcp        172.30.26.159:9979      10.0.147.219:9979,169.254.169.2:9979,10.0.242.240:9979
7de2b8fc-342a-415f-ac13-1a493f4e39c0    Service_openshif    tcp        172.30.53.219:443       10.128.0.7:8443
                                                            tcp        172.30.53.219:9192      10.128.0.7:9192
2cef36bc-d720-4afb-8d95-9350eff1d27a    Service_openshif    tcp        172.30.81.66:443        10.128.0.23:8443
365cb6fb-e15e-45a4-a55b-21868b3cf513    Service_openshif    tcp        172.30.96.51:50051      10.130.0.19:50051
41691cbb-ec55-4cdb-8431-afce679c5e8d    Service_openshif    tcp        172.30.98.218:9099      169.254.169.2:9099
82df10ba-8143-400b-977a-8f5f416a4541    Service_openshif    tcp        172.30.26.159:2379      10.0.147.219:2379,10.0.163.212:2379,169.254.169.2:2379
                                                            tcp        172.30.26.159:9979      10.0.147.219:9979,10.0.163.212:9979,169.254.169.2:9979
debe7f3a-39a8-490e-bc0a-ebbfafdffb16    Service_openshif    tcp        172.30.23.244:443       10.128.0.48:8443,10.129.0.27:8443,10.130.0.45:8443
8a749239-02d9-4dc2-8737-716528e0da7b    Service_openshif    tcp        172.30.124.255:8443     10.128.0.14:8443
880c7c78-c790-403d-a3cb-9f06592717a3    Service_openshif    tcp        172.30.0.10:53          10.130.0.20:5353
                                                            tcp        172.30.0.10:9154        10.130.0.20:9154
d2f39078-6751-4311-a161-815bbaf7f9c7    Service_openshif    tcp        172.30.26.159:2379      169.254.169.2:2379,10.0.163.212:2379,10.0.242.240:2379
                                                            tcp        172.30.26.159:9979      169.254.169.2:9979,10.0.163.212:9979,10.0.242.240:9979
30948278-602b-455c-934a-28e64c46de12    Service_openshif    tcp        172.30.157.35:9443      10.130.0.43:9443
2cc7e376-7c02-4a82-89e8-dfa1e23fb003    Service_openshif    tcp        172.30.159.212:17698    10.128.0.48:17698,10.129.0.27:17698,10.130.0.45:17698
e7d22d35-61c2-40c2-bc30-265cff8ed18d    Service_openshif    tcp        172.30.143.87:9001      10.0.145.205:9001,10.0.147.219:9001,10.0.163.212:9001,10.0.165.9:9001,10.0.209.170:9001,169.254.169.2:9001
75164e75-e0c5-40fb-9636-bfdbf4223a02    Service_openshif    tcp        172.30.150.68:1936      10.129.4.8:1936,10.131.0.10:1936
                                                            tcp        172.30.150.68:443       10.129.4.8:443,10.131.0.10:443
                                                            tcp        172.30.150.68:80        10.129.4.8:80,10.131.0.10:80
7bc4ee74-dccf-47e9-9149-b011f09aff39    Service_openshif    tcp        172.30.164.74:443       10.0.147.219:6443,10.0.163.212:6443,169.254.169.2:6443
0db59e74-1cc6-470c-bf44-57c520e0aa8f    Service_openshif    tcp        10.0.163.212:31460
                                                            tcp        10.0.163.212:32361
c300e134-018c-49af-9f84-9deb1d0715f8    Service_openshif    tcp        172.30.42.244:50051     10.130.0.47:50051
5e352773-429b-4881-afb3-a13b7ba8b081    Service_openshif    tcp        172.30.244.66:443       10.129.0.8:8443,10.130.0.8:8443
54b82d32-1939-4465-a87d-f26321442a7a    Service_openshif    tcp        172.30.12.9:8443        10.128.0.35:8443

UUID                                    LB                  PROTO      VIP                     IPs
f0fb50f9-4968-4b55-908c-616bae4db0a2    Service_default/    tcp        172.30.0.1:443          10.0.147.219:6443,10.0.163.212:6443,169.254.169.2:6443
0dc42012-4f5b-432e-ae01-2cc4bfe81b00    Service_default/    tcp        172.30.0.1:443          10.0.147.219:6443,169.254.169.2:6443,10.0.242.240:6443
f7fff5d5-5eff-4a40-98b1-3a4ba8f7f69c    Service_default/    tcp        172.30.0.1:443          169.254.169.2:6443,10.0.163.212:6443,10.0.242.240:6443
12fe57a0-50a4-4a1b-ac10-5f288badee07    Service_default/    tcp        172.30.0.1:443          10.0.147.219:6443,10.0.163.212:6443,10.0.242.240:6443
3f137fbf-0b78-4875-ba44-fbf89f254cf7    Service_openshif    tcp        172.30.23.153:443       10.130.0.14:8443
174199fe-0562-4141-b410-12094db922a7    Service_openshif    tcp        172.30.69.51:50051      10.130.0.84:50051
5ee2d4bd-c9e2-4d16-a6df-f54cd17c9ac3    Service_openshif    tcp        172.30.143.87:9001      10.0.145.205:9001,10.0.147.219:9001,10.0.163.212:9001,10.0.165.9:9001,10.0.209.170:9001,10.0.242.240:9001
a056ae3d-83f8-45bc-9c80-ef89bce7b162    Service_openshif    tcp        172.30.164.74:443       10.0.147.219:6443,10.0.163.212:6443,10.0.242.240:6443
bac51f3d-9a6f-4f5e-ac02-28fd343a332a    Service_openshif    tcp        172.30.0.10:53          10.131.0.6:5353
                                                            tcp        172.30.0.10:9154        10.131.0.6:9154
48105bbc-51d7-4178-b975-417433f9c20a    Service_openshif    tcp        172.30.26.159:2379      10.0.147.219:2379,169.254.169.2:2379,10.0.242.240:2379
                                                            tcp        172.30.26.159:9979      10.0.147.219:9979,169.254.169.2:9979,10.0.242.240:9979
7de2b8fc-342a-415f-ac13-1a493f4e39c0    Service_openshif    tcp        172.30.53.219:443       10.128.0.7:8443
                                                            tcp        172.30.53.219:9192      10.128.0.7:9192
2cef36bc-d720-4afb-8d95-9350eff1d27a    Service_openshif    tcp        172.30.81.66:443        10.128.0.23:8443
365cb6fb-e15e-45a4-a55b-21868b3cf513    Service_openshif    tcp        172.30.96.51:50051      10.130.0.19:50051
41691cbb-ec55-4cdb-8431-afce679c5e8d    Service_openshif    tcp        172.30.98.218:9099      169.254.169.2:9099
82df10ba-8143-400b-977a-8f5f416a4541    Service_openshif    tcp        172.30.26.159:2379      10.0.147.219:2379,10.0.163.212:2379,169.254.169.2:2379
                                                            tcp        172.30.26.159:9979      10.0.147.219:9979,10.0.163.212:9979,169.254.169.2:9979
debe7f3a-39a8-490e-bc0a-ebbfafdffb16    Service_openshif    tcp        172.30.23.244:443       10.128.0.48:8443,10.129.0.27:8443,10.130.0.45:8443
8a749239-02d9-4dc2-8737-716528e0da7b    Service_openshif    tcp        172.30.124.255:8443     10.128.0.14:8443
880c7c78-c790-403d-a3cb-9f06592717a3    Service_openshif    tcp        172.30.0.10:53          10.130.0.20:5353
                                                            tcp        172.30.0.10:9154        10.130.0.20:9154
d2f39078-6751-4311-a161-815bbaf7f9c7    Service_openshif    tcp        172.30.26.159:2379      169.254.169.2:2379,10.0.163.212:2379,10.0.242.240:2379
                                                            tcp        172.30.26.159:9979      169.254.169.2:9979,10.0.163.212:9979,10.0.242.240:9979
30948278-602b-455c-934a-28e64c46de12    Service_openshif    tcp        172.30.157.35:9443      10.130.0.43:9443
2cc7e376-7c02-4a82-89e8-dfa1e23fb003    Service_openshif    tcp        172.30.159.212:17698    10.128.0.48:17698,10.129.0.27:17698,10.130.0.45:17698
e7d22d35-61c2-40c2-bc30-265cff8ed18d    Service_openshif    tcp        172.30.143.87:9001      10.0.145.205:9001,10.0.147.219:9001,10.0.163.212:9001,10.0.165.9:9001,10.0.209.170:9001,169.254.169.2:9001
75164e75-e0c5-40fb-9636-bfdbf4223a02    Service_openshif    tcp        172.30.150.68:1936      10.129.4.8:1936,10.131.0.10:1936
                                                            tcp        172.30.150.68:443       10.129.4.8:443,10.131.0.10:443
                                                            tcp        172.30.150.68:80        10.129.4.8:80,10.131.0.10:80
7bc4ee74-dccf-47e9-9149-b011f09aff39    Service_openshif    tcp        172.30.164.74:443       10.0.147.219:6443,10.0.163.212:6443,169.254.169.2:6443
0db59e74-1cc6-470c-bf44-57c520e0aa8f    Service_openshif    tcp        10.0.163.212:31460
                                                            tcp        10.0.163.212:32361
c300e134-018c-49af-9f84-9deb1d0715f8    Service_openshif    tcp        172.30.42.244:50051     10.130.0.47:50051
5e352773-429b-4881-afb3-a13b7ba8b081    Service_openshif    tcp        172.30.244.66:443       10.129.0.8:8443,10.130.0.8:8443
54b82d32-1939-4465-a87d-f26321442a7a    Service_openshif    tcp        172.30.12.9:8443        10.128.0.35:8443

Copy to Clipboard

Toggle word wrap

Note

A partir de cette sortie tronquée, vous pouvez voir qu'il y a beaucoup de répartiteurs de charge OVN-Kubernetes. Les équilibreurs de charge dans OVN-Kubernetes sont des représentations de services.

24.2.4. Arguments de ligne de commande pour ovn-nbctl afin d'examiner le contenu de la base de données de la liaison descendante
Copier lien

Le tableau suivant décrit les arguments de ligne de commande qui peuvent être utilisés avec ovn-nbctl pour examiner le contenu de la base de données northbound.

Expand

Tableau 24.2. Arguments de la ligne de commande pour examiner le contenu de la base de données de la liaison descendante
Argument	Description
`ovn-nbctl show`	Une vue d'ensemble du contenu de la base de données pour le trafic nord.
`ovn-nbctl show <switch_or_router>`	Affiche les détails associés au commutateur ou au routeur spécifié.
`ovn-nbctl lr-list`	Afficher les routeurs logiques.
`ovn-nbctl lrp-list <router>`	Utilisation des informations du routeur à partir de `ovn-nbctl lr-list` pour montrer les ports du routeur.
`ovn-nbctl lr-nat-list <router>`	Affiche les détails de la traduction d'adresses réseau pour le routeur spécifié.
`ovn-nbctl ls-list`	Afficher les commutateurs logiques
`ovn-nbctl lsp-list <switch>`	Utilisation des informations sur le commutateur à partir de `ovn-nbctl ls-list` pour montrer le port du commutateur.
`ovn-nbctl lsp-get-type <port>`	Obtenir le type du port logique.
`ovn-nbctl lb-list`	Montrer les équilibreurs de charge.

24.2.5. Liste du contenu de la base de données OVN-Kubernetes en direction du sud
Copier lien

Les règles de flux logiques sont stockées dans la base de données southbound qui est une représentation de votre infrastructure. L'information à jour est présente sur le Raft leader OVN et cette procédure décrit comment trouver le Raft leader et l'interroger pour lister le contenu de la base de données OVN southbound.

Conditions préalables

Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
L'OpenShift CLI (oc) est installé.

Procédure

Trouver le chef de file du radeau OVN pour la base de données en direction du sud.

Note

Le chef de file du radeau stocke les informations les plus récentes.

Dressez la liste des pods en exécutant la commande suivante :

oc get po -n openshift-ovn-kubernetes

$ oc get po -n openshift-ovn-kubernetes

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                   READY   STATUS    RESTARTS       AGE
ovnkube-master-7j97q   6/6     Running   2 (134m ago)   135m
ovnkube-master-gt4ms   6/6     Running   1 (126m ago)   133m
ovnkube-master-mk6p6   6/6     Running   0              134m
ovnkube-node-8qvtr     5/5     Running   0              135m
ovnkube-node-bqztb     5/5     Running   0              117m
ovnkube-node-fqdc9     5/5     Running   0              135m
ovnkube-node-tlfwv     5/5     Running   0              135m
ovnkube-node-wlwkn     5/5     Running   0              128m

NAME                   READY   STATUS    RESTARTS       AGE
ovnkube-master-7j97q   6/6     Running   2 (134m ago)   135m
ovnkube-master-gt4ms   6/6     Running   1 (126m ago)   133m
ovnkube-master-mk6p6   6/6     Running   0              134m
ovnkube-node-8qvtr     5/5     Running   0              135m
ovnkube-node-bqztb     5/5     Running   0              117m
ovnkube-node-fqdc9     5/5     Running   0              135m
ovnkube-node-tlfwv     5/5     Running   0              135m
ovnkube-node-wlwkn     5/5     Running   0              128m

Copy to Clipboard

Toggle word wrap

Choisissez au hasard l'un des pods principaux et exécutez la commande suivante pour trouver le chef de file du radeau OVN en direction du sud :

oc exec -n openshift-ovn-kubernetes ovnkube-master-7j97q \
-- /usr/bin/ovn-appctl -t /var/run/ovn/ovnsb_db.ctl \
--timeout=3 cluster/status OVN_Southbound

$ oc exec -n openshift-ovn-kubernetes ovnkube-master-7j97q \
-- /usr/bin/ovn-appctl -t /var/run/ovn/ovnsb_db.ctl \
--timeout=3 cluster/status OVN_Southbound

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Defaulted container "northd" out of: northd, nbdb, kube-rbac-proxy, sbdb, ovnkube-master, ovn-dbchecker
1930
Name: OVN_Southbound
Cluster ID: f772 (f77273c0-7986-42dd-bd3c-a9f18e25701f)
Server ID: 1930 (1930f4b7-314b-406f-9dcb-b81fe2729ae1)
Address: ssl:10.0.147.219:9644
Status: cluster member
Role: follower 
Term: 3
Leader: 7081 
Vote: unknown

Election timer: 16000
Log: [2, 2423]
Entries not yet committed: 0
Entries not yet applied: 0
Connections: ->0000 ->7145 <-7081 <-7145
Disconnections: 0
Servers:
    7081 (7081 at ssl:10.0.163.212:9644) last msg 59 ms ago 
    1930 (1930 at ssl:10.0.147.219:9644) (self)
    7145 (7145 at ssl:10.0.242.240:9644) last msg 7871735 ms ago

Defaulted container "northd" out of: northd, nbdb, kube-rbac-proxy, sbdb, ovnkube-master, ovn-dbchecker
1930
Name: OVN_Southbound
Cluster ID: f772 (f77273c0-7986-42dd-bd3c-a9f18e25701f)
Server ID: 1930 (1930f4b7-314b-406f-9dcb-b81fe2729ae1)
Address: ssl:10.0.147.219:9644
Status: cluster member
Role: follower

1


Term: 3
Leader: 7081

2


Vote: unknown

Election timer: 16000
Log: [2, 2423]
Entries not yet committed: 0
Entries not yet applied: 0
Connections: ->0000 ->7145 <-7081 <-7145
Disconnections: 0
Servers:
    7081 (7081 at ssl:10.0.163.212:9644) last msg 59 ms ago

3


    1930 (1930 at ssl:10.0.147.219:9644) (self)
    7145 (7145 at ssl:10.0.242.240:9644) last msg 7871735 ms ago

Copy to Clipboard

Toggle word wrap

1: Ce pod est identifié comme un suiveur
2: Le leader est identifié comme 7081
3: Le site 7081 est sur l'adresse IP 10.0.163.212

Recherchez le pod ovnkube-master fonctionnant sur l'adresse IP 10.0.163.212 à l'aide de la commande suivante :

oc get po -o wide -n openshift-ovn-kubernetes | grep 10.0.163.212 | grep -v ovnkube-node

$ oc get po -o wide -n openshift-ovn-kubernetes | grep 10.0.163.212 | grep -v ovnkube-node

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ovnkube-master-mk6p6   6/6     Running   0              136m   10.0.163.212   ip-10-0-163-212.ec2.internal   <none>           <none>

ovnkube-master-mk6p6   6/6     Running   0              136m   10.0.163.212   ip-10-0-163-212.ec2.internal   <none>           <none>

Copy to Clipboard

Toggle word wrap

Le pod ovnkube-master-mk6p6 fonctionne sur l'adresse IP 10.0.163.212.

Exécutez la commande suivante pour afficher toutes les informations stockées dans la base de données "southbound" :

oc exec -n openshift-ovn-kubernetes -it ovnkube-master-mk6p6 \
-c northd -- ovn-sbctl show

$ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-mk6p6 \
-c northd -- ovn-sbctl show

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Chassis "8ca57b28-9834-45f0-99b0-96486c22e1be"
    hostname: ip-10-0-156-16.ec2.internal
    Encap geneve
        ip: "10.0.156.16"
        options: {csum="true"}
    Port_Binding k8s-ip-10-0-156-16.ec2.internal
    Port_Binding etor-GR_ip-10-0-156-16.ec2.internal
    Port_Binding jtor-GR_ip-10-0-156-16.ec2.internal
    Port_Binding openshift-ingress-canary_ingress-canary-hsblx
    Port_Binding rtoj-GR_ip-10-0-156-16.ec2.internal
    Port_Binding openshift-monitoring_prometheus-adapter-658fc5967-9l46x
    Port_Binding rtoe-GR_ip-10-0-156-16.ec2.internal
    Port_Binding openshift-multus_network-metrics-daemon-77nvz
    Port_Binding openshift-ingress_router-default-64fd8c67c7-df598
    Port_Binding openshift-dns_dns-default-ttpcq
    Port_Binding openshift-monitoring_alertmanager-main-0
    Port_Binding openshift-e2e-loki_loki-promtail-g2pbh
    Port_Binding openshift-network-diagnostics_network-check-target-m6tn4
    Port_Binding openshift-monitoring_thanos-querier-75b5cf8dcb-qf8qj
    Port_Binding cr-rtos-ip-10-0-156-16.ec2.internal
    Port_Binding openshift-image-registry_image-registry-7b7bc44566-mp9b8

Chassis "8ca57b28-9834-45f0-99b0-96486c22e1be"
    hostname: ip-10-0-156-16.ec2.internal
    Encap geneve
        ip: "10.0.156.16"
        options: {csum="true"}
    Port_Binding k8s-ip-10-0-156-16.ec2.internal
    Port_Binding etor-GR_ip-10-0-156-16.ec2.internal
    Port_Binding jtor-GR_ip-10-0-156-16.ec2.internal
    Port_Binding openshift-ingress-canary_ingress-canary-hsblx
    Port_Binding rtoj-GR_ip-10-0-156-16.ec2.internal
    Port_Binding openshift-monitoring_prometheus-adapter-658fc5967-9l46x
    Port_Binding rtoe-GR_ip-10-0-156-16.ec2.internal
    Port_Binding openshift-multus_network-metrics-daemon-77nvz
    Port_Binding openshift-ingress_router-default-64fd8c67c7-df598
    Port_Binding openshift-dns_dns-default-ttpcq
    Port_Binding openshift-monitoring_alertmanager-main-0
    Port_Binding openshift-e2e-loki_loki-promtail-g2pbh
    Port_Binding openshift-network-diagnostics_network-check-target-m6tn4
    Port_Binding openshift-monitoring_thanos-querier-75b5cf8dcb-qf8qj
    Port_Binding cr-rtos-ip-10-0-156-16.ec2.internal
    Port_Binding openshift-image-registry_image-registry-7b7bc44566-mp9b8

Copy to Clipboard

Toggle word wrap

Cette sortie détaillée montre le châssis et les ports qui sont attachés au châssis qui, dans ce cas, sont tous les ports du routeur et tout ce qui fonctionne comme un réseau hôte. Tous les pods communiquent avec le réseau plus large en utilisant la traduction d'adresse du réseau source (SNAT). Leur adresse IP est traduite en adresse IP du nœud sur lequel le module fonctionne, puis envoyée sur le réseau.

Outre les informations relatives au châssis, la base de données de la sortie sud contient tous les flux logiques, qui sont ensuite envoyés à ovn-controller, qui fonctionne sur chacun des nœuds. ovn-controller traduit les flux logiques en règles de flux ouvert et programme finalement OpenvSwitch afin que vos pods puissent suivre les règles de flux ouvert et sortir du réseau.

Exécutez la commande suivante pour afficher les options disponibles avec la commande ovn-sbctl:

oc exec -n openshift-ovn-kubernetes -it ovnkube-master-mk6p6 \
-c northd -- ovn-sbctl --help

$ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-mk6p6 \
-c northd -- ovn-sbctl --help

Copy to Clipboard

Toggle word wrap

24.2.6. Arguments de ligne de commande pour ovn-sbctl afin d'examiner le contenu de la base de données de la liaison descendante
Copier lien

Le tableau suivant décrit les arguments de ligne de commande qui peuvent être utilisés avec ovn-sbctl pour examiner le contenu de la base de données de la liaison descendante.

Expand

Tableau 24.3. Arguments de ligne de commande pour examiner le contenu de la base de données de la liaison descendante
Argument	Description
`ovn-sbctl show`	Vue d'ensemble du contenu de la base de données de la direction sud.
`ovn-sbctl list Port_Binding <port>`	Répertorie le contenu de la base de données de la sortie sud pour le port spécifié.
`ovn-sbctl dump-flows`	Dresser la liste des flux logiques.

24.2.7. Architecture logique OVN-Kubernetes
Copier lien

OVN est une solution de virtualisation du réseau. Il crée des commutateurs et des routeurs logiques. Ces commutateurs et routeurs sont interconnectés pour créer n'importe quelle topologie de réseau. Lorsque vous exécutez ovnkube-trace avec le niveau de journal défini sur 2 ou 5, les composants logiques OVN-Kubernetes sont exposés. Le diagramme suivant montre comment les routeurs et les commutateurs sont connectés dans OpenShift Container Platform.

Figure 24.2. Composants du routeur et du commutateur OVN-Kubernetes

Les principaux composants impliqués dans le traitement des paquets sont les suivants :

Routeurs de passerelle: Les routeurs passerelle, parfois appelés routeurs passerelle L3, sont généralement utilisés entre les routeurs distribués et le réseau physique. Les routeurs passerelle, y compris leurs ports de connexion logiques, sont liés à un emplacement physique (non distribué) ou à un châssis. Les ports de raccordement de ce routeur sont appelés ports l3gateway dans la base de données ovn-southbound (ovn-sbdb).
Routeurs logiques distribués: Les routeurs logiques distribués et les commutateurs logiques derrière eux, auxquels les machines virtuelles et les conteneurs s'attachent, résident effectivement sur chaque hyperviseur.
Rejoindre le commutateur local: Les commutateurs locaux Join sont utilisés pour connecter le routeur distribué et les routeurs de passerelle. Ils réduisent le nombre d'adresses IP nécessaires sur le routeur distribué.
Commutateurs logiques avec ports de brassage: Les commutateurs logiques avec ports de connexion sont utilisés pour virtualiser la pile du réseau. Ils connectent des ports logiques distants par le biais de tunnels.
Commutateurs logiques avec ports localnet: Les commutateurs logiques dotés de ports localnet sont utilisés pour connecter l'OVN au réseau physique. Ils relient les ports logiques distants en pontant les paquets vers les segments L2 physiques directement connectés à l'aide des ports localnet.
Ports de brassage: Les ports de brassage représentent la connectivité entre les commutateurs logiques et les routeurs logiques, ainsi qu'entre les routeurs logiques homologues. Une connexion unique possède une paire de ports de brassage à chacun de ces points de connectivité, un de chaque côté.
ports l3gateway: les ports l3gateway sont les entrées de liaison de port dans le site ovn-sbdb pour les ports de connexion logiques utilisés dans les routeurs passerelle. Ils sont appelés ports l3gateway plutôt que ports patch pour illustrer le fait que ces ports sont liés à un châssis tout comme le routeur gateway lui-même.
ports localnet: des ports localnet sont présents sur les commutateurs logiques pontés qui permettent une connexion à un réseau accessible localement à partir de chaque instance ovn-controller. Cela permet de modéliser la connectivité directe au réseau physique à partir des commutateurs logiques. Un commutateur logique ne peut être relié qu'à un seul port localnet.

24.2.7.1. Installation de network-tools sur l'hôte local
Copier lien

Installez network-tools sur votre hôte local pour disposer d'une collection d'outils permettant de déboguer les problèmes de réseau des clusters OpenShift Container Platform.

Procédure

Clonez le dépôt network-tools sur votre station de travail avec la commande suivante :
```
git clone git@github.com:openshift/network-tools.git
```
```
$ git clone git@github.com:openshift/network-tools.git
```
Copy to Clipboard Toggle word wrap
Allez dans le répertoire du dépôt que vous venez de cloner :
```
cd network-tools
```
```
$ cd network-tools
```
Copy to Clipboard Toggle word wrap
Facultatif : Liste de toutes les commandes disponibles :
```
./debug-scripts/network-tools -h
```
```
$ ./debug-scripts/network-tools -h
```
Copy to Clipboard Toggle word wrap

24.2.7.2. Exécution de network-tools
Copier lien

Obtenez des informations sur les commutateurs logiques et les routeurs en exécutant network-tools.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster en tant qu'utilisateur disposant des privilèges cluster-admin.
Vous avez installé network-tools sur l'hôte local.

Procédure

Dressez la liste des routeurs en exécutant la commande suivante :

./debug-scripts/network-tools ovn-db-run-command ovn-nbctl lr-list

$ ./debug-scripts/network-tools ovn-db-run-command ovn-nbctl lr-list

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Leader pod is ovnkube-master-vslqm
5351ddd1-f181-4e77-afc6-b48b0a9df953 (GR_helix13.lab.eng.tlv2.redhat.com)
ccf9349e-1948-4df8-954e-39fb0c2d4d06 (GR_helix14.lab.eng.tlv2.redhat.com)
e426b918-75a8-4220-9e76-20b7758f92b7 (GR_hlxcl7-master-0.hlxcl7.lab.eng.tlv2.redhat.com)
dded77c8-0cc3-4b99-8420-56cd2ae6a840 (GR_hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com)
4f6747e6-e7ba-4e0c-8dcd-94c8efa51798 (GR_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com)
52232654-336e-4952-98b9-0b8601e370b4 (ovn_cluster_router)

Leader pod is ovnkube-master-vslqm
5351ddd1-f181-4e77-afc6-b48b0a9df953 (GR_helix13.lab.eng.tlv2.redhat.com)
ccf9349e-1948-4df8-954e-39fb0c2d4d06 (GR_helix14.lab.eng.tlv2.redhat.com)
e426b918-75a8-4220-9e76-20b7758f92b7 (GR_hlxcl7-master-0.hlxcl7.lab.eng.tlv2.redhat.com)
dded77c8-0cc3-4b99-8420-56cd2ae6a840 (GR_hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com)
4f6747e6-e7ba-4e0c-8dcd-94c8efa51798 (GR_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com)
52232654-336e-4952-98b9-0b8601e370b4 (ovn_cluster_router)

Copy to Clipboard

Toggle word wrap

Dressez la liste des ports localnet en exécutant la commande suivante :

./debug-scripts/network-tools ovn-db-run-command \
ovn-sbctl find Port_Binding type=localnet

$ ./debug-scripts/network-tools ovn-db-run-command \
ovn-sbctl find Port_Binding type=localnet

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Leader pod is ovnkube-master-vslqm
_uuid               : 3de79191-cca8-4c28-be5a-a228f0f9ebfc
additional_chassis  : []
additional_encap    : []
chassis             : []
datapath            : 3f1a4928-7ff5-471f-9092-fe5f5c67d15c
encap               : []
external_ids        : {}
gateway_chassis     : []
ha_chassis_group    : []
logical_port        : br-ex_helix13.lab.eng.tlv2.redhat.com
mac                 : [unknown]
nat_addresses       : []
options             : {network_name=physnet}
parent_port         : []
port_security       : []
requested_additional_chassis: []
requested_chassis   : []
tag                 : []
tunnel_key          : 2
type                : localnet
up                  : false
virtual_parent      : []

_uuid               : dbe21daf-9594-4849-b8f0-5efbfa09a455
additional_chassis  : []
additional_encap    : []
chassis             : []
datapath            : db2a6067-fe7c-4d11-95a7-ff2321329e11
encap               : []
external_ids        : {}
gateway_chassis     : []
ha_chassis_group    : []
logical_port        : br-ex_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com
mac                 : [unknown]
nat_addresses       : []
options             : {network_name=physnet}
parent_port         : []
port_security       : []
requested_additional_chassis: []
requested_chassis   : []
tag                 : []
tunnel_key          : 2
type                : localnet
up                  : false
virtual_parent      : []

[...]

Leader pod is ovnkube-master-vslqm
_uuid               : 3de79191-cca8-4c28-be5a-a228f0f9ebfc
additional_chassis  : []
additional_encap    : []
chassis             : []
datapath            : 3f1a4928-7ff5-471f-9092-fe5f5c67d15c
encap               : []
external_ids        : {}
gateway_chassis     : []
ha_chassis_group    : []
logical_port        : br-ex_helix13.lab.eng.tlv2.redhat.com
mac                 : [unknown]
nat_addresses       : []
options             : {network_name=physnet}
parent_port         : []
port_security       : []
requested_additional_chassis: []
requested_chassis   : []
tag                 : []
tunnel_key          : 2
type                : localnet
up                  : false
virtual_parent      : []

_uuid               : dbe21daf-9594-4849-b8f0-5efbfa09a455
additional_chassis  : []
additional_encap    : []
chassis             : []
datapath            : db2a6067-fe7c-4d11-95a7-ff2321329e11
encap               : []
external_ids        : {}
gateway_chassis     : []
ha_chassis_group    : []
logical_port        : br-ex_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com
mac                 : [unknown]
nat_addresses       : []
options             : {network_name=physnet}
parent_port         : []
port_security       : []
requested_additional_chassis: []
requested_chassis   : []
tag                 : []
tunnel_key          : 2
type                : localnet
up                  : false
virtual_parent      : []

[...]

Copy to Clipboard

Toggle word wrap

Dressez la liste des ports l3gateway en exécutant la commande suivante :

./debug-scripts/network-tools ovn-db-run-command \
ovn-sbctl find Port_Binding type=l3gateway

$ ./debug-scripts/network-tools ovn-db-run-command \
ovn-sbctl find Port_Binding type=l3gateway

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Leader pod is ovnkube-master-vslqm
_uuid               : 9314dc80-39e1-4af7-9cc0-ae8a9708ed59
additional_chassis  : []
additional_encap    : []
chassis             : 336a923d-99e8-4e71-89a6-12564fde5760
datapath            : db2a6067-fe7c-4d11-95a7-ff2321329e11
encap               : []
external_ids        : {}
gateway_chassis     : []
ha_chassis_group    : []
logical_port        : etor-GR_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com
mac                 : ["52:54:00:3e:95:d3"]
nat_addresses       : ["52:54:00:3e:95:d3 10.46.56.77"]
options             : {l3gateway-chassis="7eb1f1c3-87c2-4f68-8e89-60f5ca810971", peer=rtoe-GR_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com}
parent_port         : []
port_security       : []
requested_additional_chassis: []
requested_chassis   : []
tag                 : []
tunnel_key          : 1
type                : l3gateway
up                  : true
virtual_parent      : []

_uuid               : ad7eb303-b411-4e9f-8d36-d07f1f268e27
additional_chassis  : []
additional_encap    : []
chassis             : f41453b8-29c5-4f39-b86b-e82cf344bce4
datapath            : 082e7a60-d9c7-464b-b6ec-117d3426645a
encap               : []
external_ids        : {}
gateway_chassis     : []
ha_chassis_group    : []
logical_port        : etor-GR_helix14.lab.eng.tlv2.redhat.com
mac                 : ["34:48:ed:f3:e2:2c"]
nat_addresses       : ["34:48:ed:f3:e2:2c 10.46.56.14"]
options             : {l3gateway-chassis="2e8abe3a-cb94-4593-9037-f5f9596325e2", peer=rtoe-GR_helix14.lab.eng.tlv2.redhat.com}
parent_port         : []
port_security       : []
requested_additional_chassis: []
requested_chassis   : []
tag                 : []
tunnel_key          : 1
type                : l3gateway
up                  : true
virtual_parent      : []

[...]

Leader pod is ovnkube-master-vslqm
_uuid               : 9314dc80-39e1-4af7-9cc0-ae8a9708ed59
additional_chassis  : []
additional_encap    : []
chassis             : 336a923d-99e8-4e71-89a6-12564fde5760
datapath            : db2a6067-fe7c-4d11-95a7-ff2321329e11
encap               : []
external_ids        : {}
gateway_chassis     : []
ha_chassis_group    : []
logical_port        : etor-GR_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com
mac                 : ["52:54:00:3e:95:d3"]
nat_addresses       : ["52:54:00:3e:95:d3 10.46.56.77"]
options             : {l3gateway-chassis="7eb1f1c3-87c2-4f68-8e89-60f5ca810971", peer=rtoe-GR_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com}
parent_port         : []
port_security       : []
requested_additional_chassis: []
requested_chassis   : []
tag                 : []
tunnel_key          : 1
type                : l3gateway
up                  : true
virtual_parent      : []

_uuid               : ad7eb303-b411-4e9f-8d36-d07f1f268e27
additional_chassis  : []
additional_encap    : []
chassis             : f41453b8-29c5-4f39-b86b-e82cf344bce4
datapath            : 082e7a60-d9c7-464b-b6ec-117d3426645a
encap               : []
external_ids        : {}
gateway_chassis     : []
ha_chassis_group    : []
logical_port        : etor-GR_helix14.lab.eng.tlv2.redhat.com
mac                 : ["34:48:ed:f3:e2:2c"]
nat_addresses       : ["34:48:ed:f3:e2:2c 10.46.56.14"]
options             : {l3gateway-chassis="2e8abe3a-cb94-4593-9037-f5f9596325e2", peer=rtoe-GR_helix14.lab.eng.tlv2.redhat.com}
parent_port         : []
port_security       : []
requested_additional_chassis: []
requested_chassis   : []
tag                 : []
tunnel_key          : 1
type                : l3gateway
up                  : true
virtual_parent      : []

[...]

Copy to Clipboard

Toggle word wrap

Dressez la liste des ports de correctifs en exécutant la commande suivante :

./debug-scripts/network-tools ovn-db-run-command \
ovn-sbctl find Port_Binding type=patch

$ ./debug-scripts/network-tools ovn-db-run-command \
ovn-sbctl find Port_Binding type=patch

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Leader pod is ovnkube-master-vslqm
_uuid               : c48b1380-ff26-4965-a644-6bd5b5946c61
additional_chassis  : []
additional_encap    : []
chassis             : []
datapath            : 72734d65-fae1-4bd9-a1ee-1bf4e085a060
encap               : []
external_ids        : {}
gateway_chassis     : []
ha_chassis_group    : []
logical_port        : jtor-ovn_cluster_router
mac                 : [router]
nat_addresses       : []
options             : {peer=rtoj-ovn_cluster_router}
parent_port         : []
port_security       : []
requested_additional_chassis: []
requested_chassis   : []
tag                 : []
tunnel_key          : 4
type                : patch
up                  : false
virtual_parent      : []

_uuid               : 5df51302-f3cd-415b-a059-ac24389938f7
additional_chassis  : []
additional_encap    : []
chassis             : []
datapath            : 0551c90f-e891-4909-8e9e-acc7909e06d0
encap               : []
external_ids        : {}
gateway_chassis     : []
ha_chassis_group    : []
logical_port        : rtos-hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com
mac                 : ["0a:58:0a:82:00:01 10.130.0.1/23"]
nat_addresses       : []
options             : {chassis-redirect-port=cr-rtos-hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com, peer=stor-hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com}
parent_port         : []
port_security       : []
requested_additional_chassis: []
requested_chassis   : []
tag                 : []
tunnel_key          : 4
type                : patch
up                  : false
virtual_parent      : []

[...]

Leader pod is ovnkube-master-vslqm
_uuid               : c48b1380-ff26-4965-a644-6bd5b5946c61
additional_chassis  : []
additional_encap    : []
chassis             : []
datapath            : 72734d65-fae1-4bd9-a1ee-1bf4e085a060
encap               : []
external_ids        : {}
gateway_chassis     : []
ha_chassis_group    : []
logical_port        : jtor-ovn_cluster_router
mac                 : [router]
nat_addresses       : []
options             : {peer=rtoj-ovn_cluster_router}
parent_port         : []
port_security       : []
requested_additional_chassis: []
requested_chassis   : []
tag                 : []
tunnel_key          : 4
type                : patch
up                  : false
virtual_parent      : []

_uuid               : 5df51302-f3cd-415b-a059-ac24389938f7
additional_chassis  : []
additional_encap    : []
chassis             : []
datapath            : 0551c90f-e891-4909-8e9e-acc7909e06d0
encap               : []
external_ids        : {}
gateway_chassis     : []
ha_chassis_group    : []
logical_port        : rtos-hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com
mac                 : ["0a:58:0a:82:00:01 10.130.0.1/23"]
nat_addresses       : []
options             : {chassis-redirect-port=cr-rtos-hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com, peer=stor-hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com}
parent_port         : []
port_security       : []
requested_additional_chassis: []
requested_chassis   : []
tag                 : []
tunnel_key          : 4
type                : patch
up                  : false
virtual_parent      : []

[...]

Copy to Clipboard

Toggle word wrap

24.3. Dépannage d'OVN-Kubernetes
Copier lien

OVN-Kubernetes dispose de nombreuses sources de contrôles de santé et de journaux intégrés.

24.3.1. Surveillance de l'état de santé d'OVN-Kubernetes à l'aide de sondes d'état de préparation
Copier lien

Les pods ovnkube-master et ovnkube-node ont des conteneurs configurés avec des sondes de préparation.

Conditions préalables

Accès à la CLI OpenShift (oc).
Vous avez accès au cluster avec les privilèges cluster-admin.
Vous avez installé jq.

Procédure

Examinez les détails de la sonde de préparation ovnkube-master en exécutant la commande suivante :
```
oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-master \
-o json | jq '.items[0].spec.containers[] | .name,.readinessProbe'
```
```
$ oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-master \
-o json | jq '.items[0].spec.containers[] | .name,.readinessProbe'
```
Copy to Clipboard Toggle word wrap
La sonde de préparation des conteneurs de base de données nord et sud du pod ovnkube-master vérifie l'état de santé du cluster Raft qui héberge les bases de données.
Examinez les détails de la sonde de préparation ovnkube-node en exécutant la commande suivante :
```
oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-master \
-o json | jq '.items[0].spec.containers[] | .name,.readinessProbe'
```
```
$ oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-master \
-o json | jq '.items[0].spec.containers[] | .name,.readinessProbe'
```
Copy to Clipboard Toggle word wrap
Le conteneur ovnkube-node dans le pod ovnkube-node dispose d'une sonde de préparation pour vérifier la présence du fichier de configuration CNI ovn-kubernetes, dont l'absence indiquerait que le pod ne fonctionne pas ou n'est pas prêt à accepter des demandes de configuration de pods.
Affichez tous les événements, y compris les échecs des sondes, pour l'espace de noms à l'aide de la commande suivante :
```
oc get events -n openshift-ovn-kubernetes
```
```
$ oc get events -n openshift-ovn-kubernetes
```
Copy to Clipboard Toggle word wrap

Afficher les événements pour ce seul pod :

oc describe pod ovnkube-master-tp2z8 -n openshift-ovn-kubernetes

$ oc describe pod ovnkube-master-tp2z8 -n openshift-ovn-kubernetes

Copy to Clipboard

Toggle word wrap

Affiche les messages et les statuts de l'opérateur du réseau de clusters :
```
oc get co/network -o json | jq '.status.conditions[]'
```
```
$ oc get co/network -o json | jq '.status.conditions[]'
```
Copy to Clipboard Toggle word wrap

Affichez le statut ready de chaque conteneur dans les pods ovnkube-master en exécutant le script suivant :

for p in $(oc get pods --selector app=ovnkube-master -n openshift-ovn-kubernetes \
-o jsonpath='{range.items[*]}{" "}{.metadata.name}'); do echo === $p ===;  \
oc get pods -n openshift-ovn-kubernetes $p -o json | jq '.status.containerStatuses[] | .name, .ready'; \
done

$ for p in $(oc get pods --selector app=ovnkube-master -n openshift-ovn-kubernetes \
-o jsonpath='{range.items[*]}{" "}{.metadata.name}'); do echo === $p ===;  \
oc get pods -n openshift-ovn-kubernetes $p -o json | jq '.status.containerStatuses[] | .name, .ready'; \
done

Copy to Clipboard

Toggle word wrap

Note

On s'attend à ce que tous les états des conteneurs soient signalés comme étant true. L'échec d'une enquête sur l'état de préparation fait passer le statut à false.

24.3.2. Visualisation des alertes OVN-Kubernetes dans la console
Copier lien

L'interface utilisateur des alertes fournit des informations détaillées sur les alertes ainsi que sur les règles d'alerte et les silences qui les régissent.

Conditions préalables

Vous avez accès au cluster en tant que développeur ou en tant qu'utilisateur disposant d'autorisations de visualisation pour le projet dont vous consultez les métriques.

Procédure (UI)

Dans la Administrator sélectionnez Observe → Alerting. Les trois pages principales de l'interface utilisateur d'alerte dans cette perspective sont les suivantes Alerts, Silences, et Alerting Rules sont les trois pages principales de l'interface utilisateur des alertes dans cette perspective.
Consultez les règles pour les alertes OVN-Kubernetes en sélectionnant Observe → Alerting → Alerting Rules.

24.3.3. Visualisation des alertes OVN-Kubernetes dans le CLI
Copier lien

Vous pouvez obtenir des informations sur les alertes et les règles d'alerte et de silence qui les régissent à partir de la ligne de commande.

Conditions préalables

Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
L'OpenShift CLI (oc) est installé.
Vous avez installé jq.

Procédure

Pour visualiser les alertes actives ou en cours de déclenchement, exécutez les commandes suivantes.

Définissez la variable d'environnement alert manager route en exécutant la commande suivante :

ALERT_MANAGER=$(oc get route alertmanager-main -n openshift-monitoring \
-o jsonpath='{@.spec.host}')

$ ALERT_MANAGER=$(oc get route alertmanager-main -n openshift-monitoring \
-o jsonpath='{@.spec.host}')

Copy to Clipboard

Toggle word wrap

Emettez une requête curl à l'API de route du gestionnaire d'alertes avec les détails d'autorisation corrects demandant des champs spécifiques en exécutant la commande suivante :

curl -s -k -H "Authorization: Bearer \
$(oc create token prometheus-k8s -n openshift-monitoring)" \
https://$ALERT_MANAGER/api/v1/alerts \
| jq '.data[] | "\(.labels.severity) \(.labels.alertname) \(.labels.pod) \(.labels.container) \(.labels.endpoint) \(.labels.instance)"'

$ curl -s -k -H "Authorization: Bearer \
$(oc create token prometheus-k8s -n openshift-monitoring)" \
https://$ALERT_MANAGER/api/v1/alerts \
| jq '.data[] | "\(.labels.severity) \(.labels.alertname) \(.labels.pod) \(.labels.container) \(.labels.endpoint) \(.labels.instance)"'

Copy to Clipboard

Toggle word wrap

Affichez les règles d'alerte en exécutant la commande suivante :

oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -s 'http://localhost:9090/api/v1/rules' | jq '.data.groups[].rules[] | select(((.name|contains("ovn")) or (.name|contains("OVN")) or (.name|contains("Ovn")) or (.name|contains("North")) or (.name|contains("South"))) and .type=="alerting")'

$ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -s 'http://localhost:9090/api/v1/rules' | jq '.data.groups[].rules[] | select(((.name|contains("ovn")) or (.name|contains("OVN")) or (.name|contains("Ovn")) or (.name|contains("North")) or (.name|contains("South"))) and .type=="alerting")'

Copy to Clipboard

Toggle word wrap

24.3.4. Visualisation des journaux OVN-Kubernetes à l'aide de la CLI
Copier lien

Vous pouvez consulter les journaux de chaque pod dans les pods ovnkube-master et ovnkube-node à l'aide de la CLI OpenShift (oc).

Conditions préalables

Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
Accès à la CLI OpenShift (oc).
Vous avez installé jq.

Procédure

Visualiser le journal d'un pod spécifique :
```
oc logs -f <nom_du_pod> -c <nom_du_conteneur> -n <espace_de_noms>
```
```
$ oc logs -f <nom_du_pod> -c <nom_du_conteneur> -n <espace_de_noms>
```
Copy to Clipboard Toggle word wrap
où :
-f
Facultatif : Spécifie que la sortie suit ce qui est écrit dans les journaux.
<pod_name>
Spécifie le nom du module.
<container_name>
Facultatif : Spécifie le nom d'un conteneur. Lorsqu'un module a plus d'un conteneur, vous devez spécifier le nom du conteneur.
<namespace>
Spécifie l'espace de noms dans lequel le module est exécuté.
Par exemple :
```
oc logs ovnkube-master-7h4q7 -n openshift-ovn-kubernetes
```
```
$ oc logs ovnkube-master-7h4q7 -n openshift-ovn-kubernetes
```
Copy to Clipboard Toggle word wrap
```
oc logs -f ovnkube-master-7h4q7 -n openshift-ovn-kubernetes -c ovn-dbchecker
```
```
$ oc logs -f ovnkube-master-7h4q7 -n openshift-ovn-kubernetes -c ovn-dbchecker
```
Copy to Clipboard Toggle word wrap
Le contenu des fichiers journaux est imprimé.

Examinez les entrées les plus récentes dans tous les conteneurs des modules ovnkube-master:

for p in $(oc get pods --selector app=ovnkube-master -n openshift-ovn-kubernetes \
-o jsonpath='{range.items[*]}{" "}{.metadata.name}'); \
do echo === $p ===; for container in $(oc get pods -n openshift-ovn-kubernetes $p \
-o json | jq -r '.status.containerStatuses[] | .name');do echo ---$container---; \
oc logs -c $container $p -n openshift-ovn-kubernetes --tail=5; done; done

$ for p in $(oc get pods --selector app=ovnkube-master -n openshift-ovn-kubernetes \
-o jsonpath='{range.items[*]}{" "}{.metadata.name}'); \
do echo === $p ===; for container in $(oc get pods -n openshift-ovn-kubernetes $p \
-o json | jq -r '.status.containerStatuses[] | .name');do echo ---$container---; \
oc logs -c $container $p -n openshift-ovn-kubernetes --tail=5; done; done

Copy to Clipboard

Toggle word wrap

Affichez les 5 dernières lignes de chaque journal dans chaque conteneur d'un pod ovnkube-master à l'aide de la commande suivante :
```
oc logs -l app=ovnkube-master -n openshift-ovn-kubernetes --all-containers --tail 5
```
```
$ oc logs -l app=ovnkube-master -n openshift-ovn-kubernetes --all-containers --tail 5
```
Copy to Clipboard Toggle word wrap

24.3.5. Visualisation des journaux OVN-Kubernetes à l'aide de la console web
Copier lien

Vous pouvez consulter les journaux de chaque pod dans les pods ovnkube-master et ovnkube-node dans la console web.

Conditions préalables

Accès à la CLI OpenShift (oc).

Procédure

Dans la console OpenShift Container Platform, naviguez vers Workloads → Pods ou naviguez vers le pod par le biais de la ressource que vous souhaitez étudier.
Sélectionnez le projet openshift-ovn-kubernetes dans le menu déroulant.
Cliquez sur le nom du module que vous souhaitez examiner.
Cliquez Logs. Par défaut, pour le site ovnkube-master, les journaux associés au conteneur northd sont affichés.
Utilisez le menu déroulant pour sélectionner les journaux pour chaque conteneur à tour de rôle.

24.3.5.1. Modifier les niveaux de journalisation d'OVN-Kubernetes
Copier lien

Le niveau de log par défaut d'OVN-Kubernetes est 2. Pour déboguer OVN-Kubernetes, réglez le niveau de log à 5. Suivez cette procédure pour augmenter le niveau de journalisation d'OVN-Kubernetes afin de vous aider à déboguer un problème.

Conditions préalables

Vous avez accès au cluster avec les privilèges cluster-admin.
Vous avez accès à la console web de OpenShift Container Platform.

Procédure

Exécutez la commande suivante pour obtenir des informations détaillées sur tous les pods du projet OVN-Kubernetes :

oc get po -o wide -n openshift-ovn-kubernetes

$ oc get po -o wide -n openshift-ovn-kubernetes

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                   READY   STATUS    RESTARTS      AGE   IP             NODE                           NOMINATED NODE   READINESS GATES
ovnkube-master-84nc9   6/6     Running   0             50m   10.0.134.156   ip-10-0-134-156.ec2.internal   <none>           <none>
ovnkube-master-gmlqv   6/6     Running   0             50m   10.0.209.180   ip-10-0-209-180.ec2.internal   <none>           <none>
ovnkube-master-nhts2   6/6     Running   1 (48m ago)   50m   10.0.147.31    ip-10-0-147-31.ec2.internal    <none>           <none>
ovnkube-node-2cbh8     5/5     Running   0             43m   10.0.217.114   ip-10-0-217-114.ec2.internal   <none>           <none>
ovnkube-node-6fvzl     5/5     Running   0             50m   10.0.147.31    ip-10-0-147-31.ec2.internal    <none>           <none>
ovnkube-node-f4lzz     5/5     Running   0             24m   10.0.146.76    ip-10-0-146-76.ec2.internal    <none>           <none>
ovnkube-node-jf67d     5/5     Running   0             50m   10.0.209.180   ip-10-0-209-180.ec2.internal   <none>           <none>
ovnkube-node-np9mf     5/5     Running   0             40m   10.0.165.191   ip-10-0-165-191.ec2.internal   <none>           <none>
ovnkube-node-qjldg     5/5     Running   0             50m   10.0.134.156   ip-10-0-134-156.ec2.internal   <none>           <none>

NAME                   READY   STATUS    RESTARTS      AGE   IP             NODE                           NOMINATED NODE   READINESS GATES
ovnkube-master-84nc9   6/6     Running   0             50m   10.0.134.156   ip-10-0-134-156.ec2.internal   <none>           <none>
ovnkube-master-gmlqv   6/6     Running   0             50m   10.0.209.180   ip-10-0-209-180.ec2.internal   <none>           <none>
ovnkube-master-nhts2   6/6     Running   1 (48m ago)   50m   10.0.147.31    ip-10-0-147-31.ec2.internal    <none>           <none>
ovnkube-node-2cbh8     5/5     Running   0             43m   10.0.217.114   ip-10-0-217-114.ec2.internal   <none>           <none>
ovnkube-node-6fvzl     5/5     Running   0             50m   10.0.147.31    ip-10-0-147-31.ec2.internal    <none>           <none>
ovnkube-node-f4lzz     5/5     Running   0             24m   10.0.146.76    ip-10-0-146-76.ec2.internal    <none>           <none>
ovnkube-node-jf67d     5/5     Running   0             50m   10.0.209.180   ip-10-0-209-180.ec2.internal   <none>           <none>
ovnkube-node-np9mf     5/5     Running   0             40m   10.0.165.191   ip-10-0-165-191.ec2.internal   <none>           <none>
ovnkube-node-qjldg     5/5     Running   0             50m   10.0.134.156   ip-10-0-134-156.ec2.internal   <none>           <none>

Copy to Clipboard

Toggle word wrap

Créez un fichier ConfigMap similaire à l'exemple suivant et utilisez un nom de fichier tel que env-overrides.yaml:

Exemple de fichier ConfigMap

kind: ConfigMap
apiVersion: v1
metadata:
  name: env-overrides
  namespace: openshift-ovn-kubernetes
data:
  ip-10-0-217-114.ec2.internal: | 
    # This sets the log level for the ovn-kubernetes node process:
    OVN_KUBE_LOG_LEVEL=5
    # You might also/instead want to enable debug logging for ovn-controller:
    OVN_LOG_LEVEL=dbg
  ip-10-0-209-180.ec2.internal: |
    # This sets the log level for the ovn-kubernetes node process:
    OVN_KUBE_LOG_LEVEL=5
    # You might also/instead want to enable debug logging for ovn-controller:
    OVN_LOG_LEVEL=dbg
  _master: | 
    # This sets the log level for the ovn-kubernetes master process as well as the ovn-dbchecker:
    OVN_KUBE_LOG_LEVEL=5
    # You might also/instead want to enable debug logging for northd, nbdb and sbdb on all masters:
    OVN_LOG_LEVEL=dbg

kind: ConfigMap
apiVersion: v1
metadata:
  name: env-overrides
  namespace: openshift-ovn-kubernetes
data:
  ip-10-0-217-114.ec2.internal: |

1


    # This sets the log level for the ovn-kubernetes node process:
    OVN_KUBE_LOG_LEVEL=5
    # You might also/instead want to enable debug logging for ovn-controller:
    OVN_LOG_LEVEL=dbg
  ip-10-0-209-180.ec2.internal: |
    # This sets the log level for the ovn-kubernetes node process:
    OVN_KUBE_LOG_LEVEL=5
    # You might also/instead want to enable debug logging for ovn-controller:
    OVN_LOG_LEVEL=dbg
  _master: |

2


    # This sets the log level for the ovn-kubernetes master process as well as the ovn-dbchecker:
    OVN_KUBE_LOG_LEVEL=5
    # You might also/instead want to enable debug logging for northd, nbdb and sbdb on all masters:
    OVN_LOG_LEVEL=dbg

Copy to Clipboard

Toggle word wrap

1: Indiquez le nom du nœud pour lequel vous souhaitez définir le niveau de journalisation du débogage.
2: Spécifiez _master pour définir les niveaux de journalisation des composants ovnkube-master.

Appliquez le fichier ConfigMap à l'aide de la commande suivante :

oc create configmap env-overrides.yaml -n openshift-ovn-kubernetes

$ oc create configmap env-overrides.yaml -n openshift-ovn-kubernetes

Copy to Clipboard

Toggle word wrap

Exemple de sortie

configmap/env-overrides.yaml created

configmap/env-overrides.yaml created

Copy to Clipboard

Toggle word wrap

Redémarrez les pods ovnkube pour appliquer le nouveau niveau de journalisation à l'aide des commandes suivantes :

oc delete pod -n openshift-ovn-kubernetes \
--field-selector spec.nodeName=ip-10-0-217-114.ec2.internal -l app=ovnkube-node

$ oc delete pod -n openshift-ovn-kubernetes \
--field-selector spec.nodeName=ip-10-0-217-114.ec2.internal -l app=ovnkube-node

Copy to Clipboard

Toggle word wrap

oc delete pod -n openshift-ovn-kubernetes \
--field-selector spec.nodeName=ip-10-0-209-180.ec2.internal -l app=ovnkube-node

$ oc delete pod -n openshift-ovn-kubernetes \
--field-selector spec.nodeName=ip-10-0-209-180.ec2.internal -l app=ovnkube-node

Copy to Clipboard

Toggle word wrap

oc delete pod -n openshift-ovn-kubernetes -l app=ovnkube-master

$ oc delete pod -n openshift-ovn-kubernetes -l app=ovnkube-master

Copy to Clipboard

Toggle word wrap

24.3.6. Vérification de la connectivité réseau du pod OVN-Kubernetes
Copier lien

Le contrôleur de vérification de la connectivité, dans OpenShift Container Platform 4.10 et plus, orchestre les vérifications de connexion dans votre cluster. Celles-ci incluent l'API Kubernetes, l'API OpenShift et les nœuds individuels. Les résultats des tests de connexion sont stockés dans les objets PodNetworkConnectivity de l'espace de noms openshift-network-diagnostics. Les tests de connexion sont effectués toutes les minutes en parallèle.

Conditions préalables

Accès à la CLI OpenShift (oc).
Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
Vous avez installé jq.

Procédure

Pour dresser la liste des objets PodNetworkConnectivityCheck en cours, entrez la commande suivante :
```
oc get podnetworkconnectivitychecks -n openshift-network-diagnostics
```
```
$ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics
```
Copy to Clipboard Toggle word wrap

Affichez le succès le plus récent pour chaque objet de connexion à l'aide de la commande suivante :

oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
-o json | jq '.items[]| .spec.targetEndpoint,.status.successes[0]'

$ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
-o json | jq '.items[]| .spec.targetEndpoint,.status.successes[0]'

Copy to Clipboard

Toggle word wrap

Affichez les échecs les plus récents pour chaque objet de connexion à l'aide de la commande suivante :

oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
-o json | jq '.items[]| .spec.targetEndpoint,.status.failures[0]'

$ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
-o json | jq '.items[]| .spec.targetEndpoint,.status.failures[0]'

Copy to Clipboard

Toggle word wrap

Affichez les pannes les plus récentes pour chaque objet de connexion à l'aide de la commande suivante :
```
oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
-o json | jq '.items[]| .spec.targetEndpoint,.status.outages[0]'
```
```
$ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
-o json | jq '.items[]| .spec.targetEndpoint,.status.outages[0]'
```
Copy to Clipboard Toggle word wrap
Le contrôleur de vérification de la connectivité enregistre également les mesures de ces vérifications dans Prometheus.

Affichez toutes les mesures en exécutant la commande suivante :

oc exec prometheus-k8s-0 -n openshift-monitoring -- \
promtool query instant  http://localhost:9090 \
'{component="openshift-network-diagnostics"}'

$ oc exec prometheus-k8s-0 -n openshift-monitoring -- \
promtool query instant  http://localhost:9090 \
'{component="openshift-network-diagnostics"}'

Copy to Clipboard

Toggle word wrap

Voir la latence entre le pod source et le service openshift api pour les 5 dernières minutes :

oc exec prometheus-k8s-0 -n openshift-monitoring -- \
promtool query instant  http://localhost:9090 \
'{component="openshift-network-diagnostics"}'

$ oc exec prometheus-k8s-0 -n openshift-monitoring -- \
promtool query instant  http://localhost:9090 \
'{component="openshift-network-diagnostics"}'

Copy to Clipboard

Toggle word wrap

24.4. Tracer Openflow avec ovnkube-trace
Copier lien

Les flux de trafic OVN et OVS peuvent être simulés dans un seul utilitaire appelé ovnkube-trace. L'utilitaire ovnkube-trace exécute ovn-trace, ovs-appctl ofproto/trace et ovn-detrace et met en corrélation ces informations dans un seul résultat.

Vous pouvez exécuter le binaire ovnkube-trace à partir d'un conteneur dédié. Pour les versions postérieures à OpenShift Container Platform 4.7, vous pouvez également copier le binaire sur un hôte local et l'exécuter à partir de cet hôte.

Note

Les binaires des images Quay ne fonctionnent pas actuellement pour les environnements à double pile IP ou IPv6 uniquement. Pour ces environnements, vous devez compiler à partir des sources.

24.4.1. Installation de ovnkube-trace sur l'hôte local
Copier lien

L'outil ovnkube-trace trace des simulations de paquets pour un trafic UDP ou TCP arbitraire entre des points d'un cluster OpenShift Container Platform piloté par OVN-Kubernetes. Copiez le binaire ovnkube-trace sur votre hôte local pour qu'il puisse être exécuté sur le cluster.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.

Procédure

Créez une variable pod en utilisant la commande suivante :

 POD=$(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-master -o name | head -1 | awk -F '/' '{print $NF}')

$  POD=$(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-master -o name | head -1 | awk -F '/' '{print $NF}')

Copy to Clipboard

Toggle word wrap

Exécutez la commande suivante sur votre hôte local pour copier le binaire des pods ovnkube-master:

 oc cp -n openshift-ovn-kubernetes $POD:/usr/bin/ovnkube-trace ovnkube-trace

$  oc cp -n openshift-ovn-kubernetes $POD:/usr/bin/ovnkube-trace ovnkube-trace

Copy to Clipboard

Toggle word wrap

Rendez ovnkube-trace exécutable en exécutant la commande suivante :
```
 chmod +x ovnkube-trace
```
```
$  chmod +x ovnkube-trace
```
Copy to Clipboard Toggle word wrap

Affichez les options disponibles sur ovnkube-trace en exécutant la commande suivante :

 ./ovnkube-trace -help

$  ./ovnkube-trace -help

Copy to Clipboard

Toggle word wrap

Résultats attendus

I0111 15:05:27.973305  204872 ovs.go:90] Maximum command line arguments set to: 191102
Usage of ./ovnkube-trace:
  -dst string
    	dest: destination pod name
  -dst-ip string
    	destination IP address (meant for tests to external targets)
  -dst-namespace string
    	k8s namespace of dest pod (default "default")
  -dst-port string
    	dst-port: destination port (default "80")
  -kubeconfig string
    	absolute path to the kubeconfig file
  -loglevel string
    	loglevel: klog level (default "0")
  -ovn-config-namespace string
    	namespace used by ovn-config itself
  -service string
    	service: destination service name
  -skip-detrace
    	skip ovn-detrace command
  -src string
    	src: source pod name
  -src-namespace string
    	k8s namespace of source pod (default "default")
  -tcp
    	use tcp transport protocol
  -udp
    	use udp transport protocol

I0111 15:05:27.973305  204872 ovs.go:90] Maximum command line arguments set to: 191102
Usage of ./ovnkube-trace:
  -dst string
    	dest: destination pod name
  -dst-ip string
    	destination IP address (meant for tests to external targets)
  -dst-namespace string
    	k8s namespace of dest pod (default "default")
  -dst-port string
    	dst-port: destination port (default "80")
  -kubeconfig string
    	absolute path to the kubeconfig file
  -loglevel string
    	loglevel: klog level (default "0")
  -ovn-config-namespace string
    	namespace used by ovn-config itself
  -service string
    	service: destination service name
  -skip-detrace
    	skip ovn-detrace command
  -src string
    	src: source pod name
  -src-namespace string
    	k8s namespace of source pod (default "default")
  -tcp
    	use tcp transport protocol
  -udp
    	use udp transport protocol

Copy to Clipboard

Toggle word wrap

Les arguments de ligne de commande pris en charge sont des constructions Kubernetes familières, telles que les espaces de noms, les pods, les services, de sorte que vous n'avez pas besoin de trouver l'adresse MAC, l'adresse IP des nœuds de destination ou le type ICMP.

Les niveaux d'enregistrement sont les suivants :

0 (production minimale)
2 (plus d'informations sur les résultats des commandes de suivi)
5 (sortie de débogage)

24.4.2. Exécution de ovnkube-trace
Copier lien

Lancer ovn-trace pour simuler la transmission de paquets au sein d'un réseau logique OVN.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
Vous avez installé ovnkube-trace sur l'hôte local

Exemple : Test du fonctionnement de la résolution DNS à partir d'un module déployé

Cet exemple illustre comment tester la résolution DNS d'un module déployé vers le module DNS central qui fonctionne dans le cluster.

Procédure

Démarrez un service web dans l'espace de noms par défaut en entrant la commande suivante :

oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

Copy to Clipboard

Toggle word wrap

Liste des pods fonctionnant dans l'espace de noms openshift-dns:

oc get pods -n openshift-dns

oc get pods -n openshift-dns

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                  READY   STATUS    RESTARTS   AGE
dns-default-467qw     2/2     Running   0          49m
dns-default-6prvx     2/2     Running   0          53m
dns-default-fkqr8     2/2     Running   0          53m
dns-default-qv2rg     2/2     Running   0          49m
dns-default-s29vr     2/2     Running   0          49m
dns-default-vdsbn     2/2     Running   0          53m
node-resolver-6thtt   1/1     Running   0          53m
node-resolver-7ksdn   1/1     Running   0          49m
node-resolver-8sthh   1/1     Running   0          53m
node-resolver-c5ksw   1/1     Running   0          50m
node-resolver-gbvdp   1/1     Running   0          53m
node-resolver-sxhkd   1/1     Running   0          50m

NAME                  READY   STATUS    RESTARTS   AGE
dns-default-467qw     2/2     Running   0          49m
dns-default-6prvx     2/2     Running   0          53m
dns-default-fkqr8     2/2     Running   0          53m
dns-default-qv2rg     2/2     Running   0          49m
dns-default-s29vr     2/2     Running   0          49m
dns-default-vdsbn     2/2     Running   0          53m
node-resolver-6thtt   1/1     Running   0          53m
node-resolver-7ksdn   1/1     Running   0          49m
node-resolver-8sthh   1/1     Running   0          53m
node-resolver-c5ksw   1/1     Running   0          50m
node-resolver-gbvdp   1/1     Running   0          53m
node-resolver-sxhkd   1/1     Running   0          50m

Copy to Clipboard

Toggle word wrap

Exécutez la commande suivante ovn-kube-trace pour vérifier que la résolution DNS fonctionne :

./ovnkube-trace \
  -src-namespace default \
  -src web \
  -dst-namespace openshift-dns \
  -dst dns-default-467qw \
  -udp -dst-port 53 \
  -loglevel 0

$ ./ovnkube-trace \
  -src-namespace default \

1


  -src web \

2


  -dst-namespace openshift-dns \

3


  -dst dns-default-467qw \

4


  -udp -dst-port 53 \

5


  -loglevel 0

6

Copy to Clipboard

Toggle word wrap

1: Espace de noms du pod source
2: Nom du pod source
3: Espace de noms du pod de destination
4: Nom du pod de destination
5: Utilisez le protocole de transport udp. Le port 53 est le port utilisé par le service DNS.
6: Définir le niveau de journalisation à 1 (0 est le niveau minimal et 5 est le niveau de débogage)

Résultats attendus

I0116 10:19:35.601303   17900 ovs.go:90] Maximum command line arguments set to: 191102
ovn-trace source pod to destination pod indicates success from web to dns-default-467qw
ovn-trace destination pod to source pod indicates success from dns-default-467qw to web
ovs-appctl ofproto/trace source pod to destination pod indicates success from web to dns-default-467qw
ovs-appctl ofproto/trace destination pod to source pod indicates success from dns-default-467qw to web
ovn-detrace source pod to destination pod indicates success from web to dns-default-467qw
ovn-detrace destination pod to source pod indicates success from dns-default-467qw to web

I0116 10:19:35.601303   17900 ovs.go:90] Maximum command line arguments set to: 191102
ovn-trace source pod to destination pod indicates success from web to dns-default-467qw
ovn-trace destination pod to source pod indicates success from dns-default-467qw to web
ovs-appctl ofproto/trace source pod to destination pod indicates success from web to dns-default-467qw
ovs-appctl ofproto/trace destination pod to source pod indicates success from dns-default-467qw to web
ovn-detrace source pod to destination pod indicates success from web to dns-default-467qw
ovn-detrace destination pod to source pod indicates success from dns-default-467qw to web

Copy to Clipboard

Toggle word wrap

La sortie indique le succès du pod déployé vers le port DNS et indique également qu'il est réussi dans l'autre sens. Vous savez donc que le trafic bidirectionnel est supporté sur le port UDP 53 si mon pod web veut faire de la résolution DNS à partir du core DNS.

Si, par exemple, cela n'a pas fonctionné et que vous souhaitiez obtenir ovn-trace, ovs-appctl ofproto/trace et ovn-detrace, ainsi que d'autres informations de type débogage, augmentez le niveau du journal à 2 et exécutez à nouveau la commande de la manière suivante :

./ovnkube-trace \
  -src-namespace default \
  -src web \
  -dst-namespace openshift-dns \
  -dst dns-default-467qw \
  -udp -dst-port 53 \
  -loglevel 2

$ ./ovnkube-trace \
  -src-namespace default \
  -src web \
  -dst-namespace openshift-dns \
  -dst dns-default-467qw \
  -udp -dst-port 53 \
  -loglevel 2

Copy to Clipboard

Toggle word wrap

Les résultats de cette augmentation du niveau de journalisation sont trop nombreux pour être énumérés ici. En cas d'échec, la sortie de cette commande montre quel flux laisse tomber ce trafic. Par exemple, une politique de réseau d'entrée ou de sortie peut être configurée sur le cluster qui n'autorise pas ce trafic.

Exemple : Vérification à l'aide de la sortie debug d'un refus par défaut configuré

Cet exemple montre comment identifier, à l'aide de la sortie de débogage, qu'une stratégie de refus par défaut à l'entrée bloque le trafic.

Procédure

Créez le fichier YAML suivant qui définit une politique deny-by-default pour refuser l'entrée de tous les pods dans tous les espaces de noms. Enregistrez le YAML dans le fichier deny-by-default.yaml:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
  namespace: default
spec:
  podSelector: {}
  ingress: []

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
  namespace: default
spec:
  podSelector: {}
  ingress: []

Copy to Clipboard

Toggle word wrap

Appliquez la politique en entrant la commande suivante :
```
oc apply -f deny-by-default.yaml
```
```
$ oc apply -f deny-by-default.yaml
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
networkpolicy.networking.k8s.io/deny-by-default created
```
```
networkpolicy.networking.k8s.io/deny-by-default created
```
Copy to Clipboard Toggle word wrap

Démarrez un service web dans l'espace de noms default en entrant la commande suivante :

oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

Copy to Clipboard

Toggle word wrap

Exécutez la commande suivante pour créer l'espace de noms prod:
```
oc create namespace prod
```
```
$ oc create namespace prod
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour étiqueter l'espace de noms prod:
```
oc label namespace/prod purpose=production
```
```
$ oc label namespace/prod purpose=production
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour déployer une image alpine dans l'espace de noms prod et démarrer un shell :
```
oc run test-6459 --namespace=prod --rm -i -t --image=alpine -- sh
```
```
$ oc run test-6459 --namespace=prod --rm -i -t --image=alpine -- sh
```
Copy to Clipboard Toggle word wrap
Ouvrez une autre session de terminal.

Dans cette nouvelle session de terminal, exécutez ovn-trace pour vérifier l'échec de la communication entre le pod source test-6459 fonctionnant dans l'espace de noms prod et le pod de destination fonctionnant dans l'espace de noms default:

./ovnkube-trace \
 -src-namespace prod \
 -src test-6459 \
 -dst-namespace default \
 -dst web \
 -tcp -dst-port 80 \
 -loglevel 0

$ ./ovnkube-trace \
 -src-namespace prod \
 -src test-6459 \
 -dst-namespace default \
 -dst web \
 -tcp -dst-port 80 \
 -loglevel 0

Copy to Clipboard

Toggle word wrap

Résultats attendus

I0116 14:20:47.380775   50822 ovs.go:90] Maximum command line arguments set to: 191102
ovn-trace source pod to destination pod indicates failure from test-6459 to web

I0116 14:20:47.380775   50822 ovs.go:90] Maximum command line arguments set to: 191102
ovn-trace source pod to destination pod indicates failure from test-6459 to web

Copy to Clipboard

Toggle word wrap

Augmentez le niveau de journalisation à 2 pour révéler la raison de l'échec en exécutant la commande suivante :

./ovnkube-trace \
 -src-namespace prod \
 -src test-6459 \
 -dst-namespace default \
 -dst web \
 -tcp -dst-port 80 \
 -loglevel 2

$ ./ovnkube-trace \
 -src-namespace prod \
 -src test-6459 \
 -dst-namespace default \
 -dst web \
 -tcp -dst-port 80 \
 -loglevel 2

Copy to Clipboard

Toggle word wrap

Résultats attendus

ct_lb_mark /* default (use --ct to customize) */
------------------------------------------------
 3. ls_out_acl_hint (northd.c:6092): !ct.new && ct.est && !ct.rpl && ct_mark.blocked == 0, priority 4, uuid 32d45ad4
    reg0[8] = 1;
    reg0[10] = 1;
    next;
 4. ls_out_acl (northd.c:6435): reg0[10] == 1 && (outport == @a16982411286042166782_ingressDefaultDeny), priority 2000, uuid f730a887 
    ct_commit { ct_mark.blocked = 1; };

ct_lb_mark /* default (use --ct to customize) */
------------------------------------------------
 3. ls_out_acl_hint (northd.c:6092): !ct.new && ct.est && !ct.rpl && ct_mark.blocked == 0, priority 4, uuid 32d45ad4
    reg0[8] = 1;
    reg0[10] = 1;
    next;
 4. ls_out_acl (northd.c:6435): reg0[10] == 1 && (outport == @a16982411286042166782_ingressDefaultDeny), priority 2000, uuid f730a887

1


    ct_commit { ct_mark.blocked = 1; };

Copy to Clipboard

Toggle word wrap

1: Le trafic entrant est bloqué en raison de la politique de refus par défaut en place

Créez une politique qui autorise le trafic de tous les pods dans un espace de noms particulier avec un label purpose=production. Sauvegardez le YAML dans le fichier web-allow-prod.yaml:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-prod
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: production

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-prod
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: production

Copy to Clipboard

Toggle word wrap

Appliquez la politique en entrant la commande suivante :
```
oc apply -f web-allow-prod.yaml
```
```
$ oc apply -f web-allow-prod.yaml
```
Copy to Clipboard Toggle word wrap

Exécutez ovnkube-trace pour vérifier que le trafic est maintenant autorisé en entrant la commande suivante :

./ovnkube-trace \
 -src-namespace prod \
 -src test-6459 \
 -dst-namespace default \
 -dst web \
 -tcp -dst-port 80 \
 -loglevel 0

$ ./ovnkube-trace \
 -src-namespace prod \
 -src test-6459 \
 -dst-namespace default \
 -dst web \
 -tcp -dst-port 80 \
 -loglevel 0

Copy to Clipboard

Toggle word wrap

Résultats attendus

I0116 14:25:44.055207   51695 ovs.go:90] Maximum command line arguments set to: 191102
ovn-trace source pod to destination pod indicates success from test-6459 to web
ovn-trace destination pod to source pod indicates success from web to test-6459
ovs-appctl ofproto/trace source pod to destination pod indicates success from test-6459 to web
ovs-appctl ofproto/trace destination pod to source pod indicates success from web to test-6459
ovn-detrace source pod to destination pod indicates success from test-6459 to web
ovn-detrace destination pod to source pod indicates success from web to test-6459

I0116 14:25:44.055207   51695 ovs.go:90] Maximum command line arguments set to: 191102
ovn-trace source pod to destination pod indicates success from test-6459 to web
ovn-trace destination pod to source pod indicates success from web to test-6459
ovs-appctl ofproto/trace source pod to destination pod indicates success from test-6459 to web
ovs-appctl ofproto/trace destination pod to source pod indicates success from web to test-6459
ovn-detrace source pod to destination pod indicates success from test-6459 to web
ovn-detrace destination pod to source pod indicates success from web to test-6459

Copy to Clipboard

Toggle word wrap

Dans le shell ouvert, exécutez la commande suivante :

 wget -qO- --timeout=2 http://web.default

 wget -qO- --timeout=2 http://web.default

Copy to Clipboard

Toggle word wrap

Résultats attendus

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Copy to Clipboard

Toggle word wrap

24.5. Migrer du plugin réseau SDN d'OpenShift
Copier lien

En tant qu'administrateur de cluster, vous pouvez migrer vers le plugin réseau OVN-Kubernetes à partir du plugin réseau OpenShift SDN.

Pour en savoir plus sur OVN-Kubernetes, lisez À propos du plugin réseau OVN-Kubernetes.

24.5.1. Migration vers le plugin réseau OVN-Kubernetes
Copier lien

La migration vers le plugin réseau OVN-Kubernetes est un processus manuel qui comprend un certain temps d'arrêt pendant lequel votre cluster est inaccessible. Bien qu'une procédure de retour en arrière soit fournie, la migration est conçue pour être un processus à sens unique.

Une migration vers le plugin réseau OVN-Kubernetes est prise en charge sur les plateformes suivantes :

Matériel métallique nu
Amazon Web Services (AWS)
Google Cloud Platform (GCP)
IBM Cloud
Microsoft Azure
Plate-forme Red Hat OpenStack (RHOSP)
Red Hat Virtualization (RHV)
VMware vSphere

Important

La migration vers ou depuis le plugin réseau OVN-Kubernetes n'est pas prise en charge pour les services cloud OpenShift gérés tels que OpenShift Dedicated et Red Hat OpenShift Service on AWS (ROSA).

24.5.1.1. Considérations pour la migration vers le plugin réseau OVN-Kubernetes
Copier lien

Si vous avez plus de 150 nœuds dans votre cluster OpenShift Container Platform, ouvrez un dossier de support pour obtenir des conseils sur votre migration vers le plugin réseau OVN-Kubernetes.

Les sous-réseaux attribués aux nœuds et les adresses IP attribuées aux pods individuels ne sont pas conservés pendant la migration.

Bien que le plugin réseau OVN-Kubernetes mette en œuvre de nombreuses fonctionnalités présentes dans le plugin réseau SDN d'OpenShift, la configuration n'est pas la même.

Si votre cluster utilise l'une des capacités suivantes du plugin réseau OpenShift SDN, vous devez configurer manuellement la même capacité dans le plugin réseau OVN-Kubernetes :
- Isolation de l'espace de noms
- Pods de routeurs de sortie
Si votre cluster ou le réseau environnant utilise une partie de la plage d'adresses 100.64.0.0/16, vous devez choisir une autre plage d'adresses IP inutilisée en spécifiant la spécification v4InternalSubnet sous la définition de l'objet spec.defaultNetwork.ovnKubernetesConfig. OVN-Kubernetes utilise par défaut la plage d'adresses IP 100.64.0.0/16 en interne.

Les sections suivantes mettent en évidence les différences de configuration entre les capacités susmentionnées dans les plugins réseau OVN-Kubernetes et OpenShift SDN.

Isolation de l'espace de noms

OVN-Kubernetes ne prend en charge que le mode d'isolation de la politique de réseau.

Important

Si votre cluster utilise OpenShift SDN configuré en mode multitenant ou en mode d'isolation de sous-réseau, vous ne pouvez pas migrer vers le plugin réseau OVN-Kubernetes.

Adresses IP de sortie

OpenShift SDN prend en charge deux modes IP de sortie différents :

Dans cette approche, une plage d'adresses IP de sortie est attribuée à un nœud automatically assigned une plage d'adresses IP de sortie est attribuée à un nœud.
Dans cette approche, une liste d'une ou plusieurs adresses IP de sortie est attribuée à un nœud manually assigned une liste d'une ou plusieurs adresses IP de sortie est attribuée à un nœud.

Le processus de migration prend en charge la migration des configurations IP de sortie qui utilisent le mode d'attribution automatique.

Les différences dans la configuration d'une adresse IP egress entre OVN-Kubernetes et OpenShift SDN sont décrites dans le tableau suivant :

Expand

Tableau 24.4. Différences dans la configuration des adresses IP de sortie
OVN-Kubernetes	OpenShift SDN
Créer un objet `EgressIPs` Ajouter une annotation sur un objet `Node`	Patch d'un objet `NetNamespace` Patch d'un objet `HostSubnet`

Pour plus d'informations sur l'utilisation des adresses IP de sortie dans OVN-Kubernetes, voir "Configuration d'une adresse IP de sortie".

Politiques du réseau de sortie

La différence de configuration d'une politique de réseau egress, également connue sous le nom de pare-feu egress, entre OVN-Kubernetes et OpenShift SDN est décrite dans le tableau suivant :

Expand

Tableau 24.5. Différences dans la configuration de la politique du réseau de sortie
OVN-Kubernetes	OpenShift SDN
Créer un objet `EgressFirewall` dans un espace de noms	Créer un objet `EgressNetworkPolicy` dans un espace de noms

Note

Comme le nom d'un objet EgressFirewall ne peut être défini que sur default, après la migration, tous les objets EgressNetworkPolicy migrés sont nommés default, quel que soit le nom qu'ils portaient sous OpenShift SDN.

Si vous revenez ensuite à OpenShift SDN, tous les objets EgressNetworkPolicy sont nommés default car le nom précédent est perdu.

Pour plus d'informations sur l'utilisation d'un pare-feu de sortie dans OVN-Kubernetes, voir "Configuration d'un pare-feu de sortie pour un projet".

Pods de routeurs de sortie

OVN-Kubernetes supporte les egress router pods en mode redirect. OVN-Kubernetes ne supporte pas les egress router pods en mode proxy HTTP ou DNS.

Lorsque vous déployez un routeur de sortie avec l'opérateur de réseau de cluster, vous ne pouvez pas spécifier de sélecteur de nœud pour contrôler le nœud utilisé pour héberger le module de routeur de sortie.

Multidiffusion

La différence entre l'activation du trafic multicast sur OVN-Kubernetes et OpenShift SDN est décrite dans le tableau suivant :

Expand

Tableau 24.6. Différences dans la configuration de la multidiffusion
OVN-Kubernetes	OpenShift SDN
Ajouter une annotation sur un objet `Namespace`	Ajouter une annotation sur un objet `NetNamespace`

Pour plus d'informations sur l'utilisation de la multidiffusion dans OVN-Kubernetes, voir "Activation de la multidiffusion pour un projet".

Politiques de réseau

OVN-Kubernetes supporte entièrement l'API Kubernetes NetworkPolicy dans le groupe d'API networking.k8s.io/v1. Aucun changement n'est nécessaire dans vos politiques de réseau lors de la migration depuis OpenShift SDN.

24.5.1.2. Comment fonctionne le processus de migration
Copier lien

Le tableau suivant résume le processus de migration en distinguant les étapes du processus initiées par l'utilisateur et les actions que la migration exécute en réponse.

Expand

Tableau 24.7. Migrer vers OVN-Kubernetes depuis OpenShift SDN
Étapes initiées par l'utilisateur	Activité de migration
Définissez le champ `migration` de la ressource personnalisée (CR) `Network.operator.openshift.io` nommée `cluster` sur `OVNKubernetes`. Assurez-vous que le champ `migration` est bien `null` avant de lui attribuer une valeur.	Opérateur de réseau en grappe (CNO) Met à jour le statut du CR `Network.config.openshift.io` nommé `cluster` en conséquence. Opérateur de configuration de machine (MCO) Déploie une mise à jour de la configuration systemd nécessaire pour OVN-Kubernetes ; Le MCO met à jour une seule machine par pool à la fois par défaut, ce qui fait que la durée totale de la migration augmente avec la taille du cluster.
Mettre à jour le champ `networkType` du CR `Network.config.openshift.io`.	CNO Effectue les actions suivantes : Détruit les pods du plan de contrôle OpenShift SDN. Déploie les pods du plan de contrôle OVN-Kubernetes. Met à jour les objets Multus pour refléter le nouveau plugin réseau.
Redémarrez chaque nœud du cluster.	Groupement d'entreprises Au fur et à mesure que les nœuds redémarrent, le cluster attribue des adresses IP aux pods sur le réseau du cluster OVN-Kubernetes.

Si un retour en arrière vers OpenShift SDN est nécessaire, le tableau suivant décrit le processus.

Expand

Tableau 24.8. Effectuer un retour en arrière vers OpenShift SDN
Étapes initiées par l'utilisateur	Activité de migration
Suspendre le MCO pour s'assurer qu'il n'interrompt pas la migration.	Le MCO s'arrête.
Définissez le champ `migration` de la ressource personnalisée (CR) `Network.operator.openshift.io` nommée `cluster` sur `OpenShiftSDN`. Assurez-vous que le champ `migration` est bien `null` avant de lui attribuer une valeur.	CNO Met à jour le statut du CR `Network.config.openshift.io` nommé `cluster` en conséquence.
Mettre à jour le champ `networkType`.	CNO Effectue les actions suivantes : Détruit les pods du plan de contrôle OVN-Kubernetes. Déploie les pods du plan de contrôle OpenShift SDN. Met à jour les objets Multus pour refléter le nouveau plugin réseau.
Redémarrez chaque nœud du cluster.	Groupement d'entreprises Au fur et à mesure que les nœuds redémarrent, le cluster attribue des adresses IP aux pods sur le réseau OpenShift-SDN.
Activer le MCO après le redémarrage de tous les nœuds de la grappe.	MCO Déploie une mise à jour de la configuration systemd nécessaire à OpenShift SDN ; Le MCO met à jour une seule machine par pool à la fois par défaut, de sorte que la durée totale de la migration augmente avec la taille du cluster.

24.5.2. Migration vers le plugin réseau OVN-Kubernetes
Copier lien

En tant qu'administrateur de cluster, vous pouvez changer le plugin réseau de votre cluster pour OVN-Kubernetes. Pendant la migration, vous devez redémarrer chaque nœud de votre cluster.

Important

Pendant la migration, votre cluster est indisponible et les charges de travail peuvent être interrompues. N'effectuez la migration que si une interruption de service est acceptable.

Conditions préalables

Un cluster configuré avec le plugin réseau OpenShift SDN CNI en mode d'isolation de la politique réseau.
Installez le CLI OpenShift (oc).
Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
Une sauvegarde récente de la base de données etcd est disponible.
Un redémarrage peut être déclenché manuellement pour chaque nœud.
Le cluster est dans un état connu, sans aucune erreur.

Procédure

Pour sauvegarder la configuration du réseau de clusters, entrez la commande suivante :

oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml

oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml

Copy to Clipboard

Toggle word wrap

Pour préparer tous les nœuds à la migration, définissez le champ migration sur l'objet de configuration Cluster Network Operator en entrant la commande suivante :
```
oc patch Network.operator.openshift.io cluster --type='merge' \
  --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'
```
```
$ oc patch Network.operator.openshift.io cluster --type='merge' \
  --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'
```
Copy to Clipboard Toggle word wrap
Note
Cette étape ne déploie pas OVN-Kubernetes immédiatement. Au lieu de cela, la spécification du champ migration déclenche le Machine Config Operator (MCO) pour appliquer de nouvelles configurations de machine à tous les nœuds du cluster en préparation du déploiement d'OVN-Kubernetes.

Facultatif : vous pouvez désactiver la migration automatique de plusieurs fonctionnalités OpenShift SDN vers les équivalents OVN-Kubernetes :

IP de sortie
Pare-feu de sortie
Multidiffusion

Pour désactiver la migration automatique de la configuration pour l'une des fonctionnalités OpenShift SDN mentionnées précédemment, spécifiez les clés suivantes :

oc patch Network.operator.openshift.io cluster --type='merge' \
  --patch '{
    "spec": {
      "migration": {
        "networkType": "OVNKubernetes",
        "features": {
          "egressIP": <bool>,
          "egressFirewall": <bool>,
          "multicast": <bool>
        }
      }
    }
  }'

$ oc patch Network.operator.openshift.io cluster --type='merge' \
  --patch '{
    "spec": {
      "migration": {
        "networkType": "OVNKubernetes",
        "features": {
          "egressIP": <bool>,
          "egressFirewall": <bool>,
          "multicast": <bool>
        }
      }
    }
  }'

Copy to Clipboard

Toggle word wrap

où :

bool: Spécifie si la migration de la fonctionnalité doit être activée. La valeur par défaut est true.

Facultatif : vous pouvez personnaliser les paramètres suivants pour OVN-Kubernetes afin de répondre aux exigences de votre infrastructure réseau :
- Unité de transmission maximale (MTU)
- Geneve (Generic Network Virtualization Encapsulation) port de réseau superposé
- Sous-réseau interne IPv4 d'OVN-Kubernetes
- Sous-réseau interne IPv6 d'OVN-Kubernetes
Pour personnaliser l'un ou l'autre des paramètres susmentionnés, entrez et personnalisez la commande suivante. Si vous n'avez pas besoin de modifier la valeur par défaut, omettez la clé du correctif.
```
oc patch Network.operator.openshift.io cluster --type=merge \
  --patch '{
    "spec":{
      "defaultNetwork":{
        "ovnKubernetesConfig":{
          "mtu":<mtu>,
          "genevePort":<port>,
          "v4InternalSubnet":"<ipv4_subnet>",
          "v6InternalSubnet":"<ipv6_subnet>"
    }}}}'
```
```
$ oc patch Network.operator.openshift.io cluster --type=merge \
  --patch '{
    "spec":{
      "defaultNetwork":{
        "ovnKubernetesConfig":{
          "mtu":<mtu>,
          "genevePort":<port>,
          "v4InternalSubnet":"<ipv4_subnet>",
          "v6InternalSubnet":"<ipv6_subnet>"
    }}}}'
```
Copy to Clipboard Toggle word wrap
où :
mtu
Le MTU pour le réseau superposé de Geneve. Cette valeur est normalement configurée automatiquement, mais si les nœuds de votre cluster n'utilisent pas tous le même MTU, vous devez la définir explicitement à 100 moins que la valeur du MTU du plus petit nœud.
port
Le port UDP pour le réseau superposé de Geneve. Si aucune valeur n'est spécifiée, la valeur par défaut est 6081. Le port ne peut pas être le même que le port VXLAN utilisé par OpenShift SDN. La valeur par défaut du port VXLAN est 4789.
ipv4_subnet
Une plage d'adresses IPv4 à usage interne pour OVN-Kubernetes. Vous devez vous assurer que la plage d'adresses IP ne chevauche pas un autre sous-réseau utilisé par votre installation OpenShift Container Platform. La plage d'adresses IP doit être supérieure au nombre maximum de nœuds pouvant être ajoutés au cluster. La valeur par défaut est 100.64.0.0/16.
ipv6_subnet
Une plage d'adresses IPv6 à usage interne pour OVN-Kubernetes. Vous devez vous assurer que la plage d'adresses IP ne chevauche pas un autre sous-réseau utilisé par votre installation OpenShift Container Platform. La plage d'adresses IP doit être supérieure au nombre maximum de nœuds pouvant être ajoutés au cluster. La valeur par défaut est fd98::/48.
Exemple de commande de patch pour mettre à jour le champ mtu
```
oc patch Network.operator.openshift.io cluster --type=merge \
  --patch '{
    "spec":{
      "defaultNetwork":{
        "ovnKubernetesConfig":{
          "mtu":1200
    }}}}'
```
```
$ oc patch Network.operator.openshift.io cluster --type=merge \
  --patch '{
    "spec":{
      "defaultNetwork":{
        "ovnKubernetesConfig":{
          "mtu":1200
    }}}}'
```
Copy to Clipboard Toggle word wrap
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
```
```
$ oc get mcp
```
Copy to Clipboard Toggle word wrap
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.

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

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"

$ oc describe node | egrep "hostname|machineconfig"

Copy to Clipboard

Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

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.

Pour confirmer que la configuration de la machine est correcte, entrez la commande suivante :
```
oc get machineconfig <config_name> -o yaml | grep ExecStart
```
```
oc get machineconfig <config_name> -o yaml | grep ExecStart
```
Copy to Clipboard Toggle word wrap
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/configure-ovs.sh OVNKubernetes
```
```
ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes
```
Copy to Clipboard Toggle word wrap

Si un nœud est bloqué à l'état NotReady, examinez les journaux de pods du démon de configuration de la machine et résolvez les erreurs éventuelles.

Pour dresser la liste des pods, entrez la commande suivante :

oc get pod -n openshift-machine-config-operator

$ oc get pod -n openshift-machine-config-operator

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                         READY   STATUS    RESTARTS   AGE
machine-config-controller-75f756f89d-sjp8b   1/1     Running   0          37m
machine-config-daemon-5cf4b                  2/2     Running   0          43h
machine-config-daemon-7wzcd                  2/2     Running   0          43h
machine-config-daemon-fc946                  2/2     Running   0          43h
machine-config-daemon-g2v28                  2/2     Running   0          43h
machine-config-daemon-gcl4f                  2/2     Running   0          43h
machine-config-daemon-l5tnv                  2/2     Running   0          43h
machine-config-operator-79d9c55d5-hth92      1/1     Running   0          37m
machine-config-server-bsc8h                  1/1     Running   0          43h
machine-config-server-hklrm                  1/1     Running   0          43h
machine-config-server-k9rtx                  1/1     Running   0          43h

NAME                                         READY   STATUS    RESTARTS   AGE
machine-config-controller-75f756f89d-sjp8b   1/1     Running   0          37m
machine-config-daemon-5cf4b                  2/2     Running   0          43h
machine-config-daemon-7wzcd                  2/2     Running   0          43h
machine-config-daemon-fc946                  2/2     Running   0          43h
machine-config-daemon-g2v28                  2/2     Running   0          43h
machine-config-daemon-gcl4f                  2/2     Running   0          43h
machine-config-daemon-l5tnv                  2/2     Running   0          43h
machine-config-operator-79d9c55d5-hth92      1/1     Running   0          37m
machine-config-server-bsc8h                  1/1     Running   0          43h
machine-config-server-hklrm                  1/1     Running   0          43h
machine-config-server-k9rtx                  1/1     Running   0          43h

Copy to Clipboard

Toggle word wrap

Les noms des modules de démon de configuration sont au format suivant : machine-config-daemon-<seq>. La valeur <seq> est une séquence alphanumérique aléatoire de cinq caractères.

Affichez le journal du pod pour le premier pod de démon de configuration de machine montré dans la sortie précédente en entrant la commande suivante :
```
oc logs <pod> -n openshift-machine-config-operator
```
```
$ oc logs <pod> -n openshift-machine-config-operator
```
Copy to Clipboard Toggle word wrap
où pod est le nom d'un pod de démon de configuration de machine.
Résoudre les erreurs éventuelles dans les journaux affichés par la sortie de la commande précédente.

Pour démarrer la migration, configurez le plugin réseau OVN-Kubernetes à l'aide d'une des commandes suivantes :
- Pour spécifier le fournisseur de réseau sans modifier le bloc d'adresses IP du réseau de la grappe, entrez la commande suivante :
  $ oc patch Network.config.openshift.io cluster \ --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'
  Copy to Clipboard Toggle word wrap
- Pour spécifier un autre bloc d'adresses IP du réseau cluster, entrez la commande suivante :
  $ oc patch Network.config.openshift.io cluster \ --type='merge' --patch '{ "spec": { "clusterNetwork": [ { "cidr": "<cidr>", "hostPrefix": <prefix> } ], "networkType": "OVNKubernetes" } }'
  Copy to Clipboard Toggle word wrap
  où cidr est un bloc CIDR et prefix est la tranche du bloc CIDR attribuée à chaque nœud de votre cluster. Vous ne pouvez pas utiliser un bloc CIDR qui chevauche le bloc CIDR 100.64.0.0/16 car le fournisseur de réseau OVN-Kubernetes utilise ce bloc en interne.
  Important
  Vous ne pouvez pas modifier le bloc d'adresses du réseau de service pendant la migration.

Vérifiez que le déploiement du jeu de démons Multus est terminé avant de passer aux étapes suivantes :

oc -n openshift-multus rollout status daemonset/multus

$ oc -n openshift-multus rollout status daemonset/multus

Copy to Clipboard

Toggle word wrap

Le nom des nacelles Multus se présente sous la forme multus-<xxxxx>, où <xxxxx> est une séquence aléatoire de lettres. Le redémarrage des pods peut prendre quelques instants.

Exemple de sortie

Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated...
...
Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available...
daemon set "multus" successfully rolled out

Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated...
...
Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available...
daemon set "multus" successfully rolled out

Copy to Clipboard

Toggle word wrap

Pour terminer la migration, redémarrez chaque nœud de votre cluster. Par exemple, vous pouvez utiliser un script bash similaire à l'exemple suivant. Le script suppose que vous pouvez vous connecter à chaque hôte en utilisant ssh et que vous avez configuré sudo pour ne pas demander de mot de passe.
```
#!/bin/bash

for ip in $(oc get nodes  -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}')
do
   echo "reboot node $ip"
   ssh -o StrictHostKeyChecking=no core@$ip sudo shutdown -r -t 3
done
```
```
#!/bin/bash

for ip in $(oc get nodes  -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}')
do
   echo "reboot node $ip"
   ssh -o StrictHostKeyChecking=no core@$ip sudo shutdown -r -t 3
done
```
Copy to Clipboard Toggle word wrap
Si l'accès ssh n'est pas disponible, vous pourrez peut-être redémarrer chaque nœud via le portail de gestion de votre fournisseur d'infrastructure.
Confirmez que la migration a réussi :
1. Pour confirmer que le plugin réseau est OVN-Kubernetes, entrez la commande suivante. La valeur de status.networkType doit être OVNKubernetes.
  $ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
  Copy to Clipboard Toggle word wrap
2. Pour confirmer que les nœuds du cluster sont dans l'état Ready, entrez la commande suivante :
  $ oc get nodes
  Copy to Clipboard Toggle word wrap
3. Pour confirmer que vos pods ne sont pas dans un état d'erreur, entrez la commande suivante :
  $ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'
  Copy to Clipboard Toggle word wrap
  Si les pods d'un nœud sont dans un état d'erreur, redémarrez ce nœud.
4. Pour confirmer que tous les opérateurs du cluster ne sont pas dans un état anormal, entrez la commande suivante :
  $ oc get co
  Copy to Clipboard Toggle word wrap
  L'état de chaque opérateur de cluster doit être le suivant : AVAILABLE="True", PROGRESSING="False", DEGRADED="False". Si un opérateur de cluster n'est pas disponible ou est dégradé, vérifiez les journaux de l'opérateur de cluster pour plus d'informations.
N'effectuez les étapes suivantes que si la migration a réussi et que votre cluster est en bon état :
1. Pour supprimer la configuration de la migration de l'objet de configuration CNO, entrez la commande suivante :
  $ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'
  Copy to Clipboard Toggle word wrap
2. Pour supprimer la configuration personnalisée du fournisseur de réseau OpenShift SDN, entrez la commande suivante :
  $ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'
  Copy to Clipboard Toggle word wrap
3. Pour supprimer l'espace de noms du fournisseur de réseau OpenShift SDN, entrez la commande suivante :
  $ oc delete namespace openshift-sdn
  Copy to Clipboard Toggle word wrap

24.6. Revenir au fournisseur de réseau SDN OpenShift
Copier lien

En tant qu'administrateur de cluster, vous pouvez revenir au plugin réseau OpenShift SDN à partir du plugin réseau OVN-Kubernetes si la migration vers OVN-Kubernetes échoue.

24.6.1. Repousser le plugin réseau vers OpenShift SDN
Copier lien

En tant qu'administrateur de cluster, vous pouvez revenir sur votre cluster avec le plugin réseau OpenShift SDN Container Network Interface (CNI). Pendant le rollback, vous devez redémarrer chaque nœud de votre cluster.

Important

Ne revenir à OpenShift SDN que si la migration vers OVN-Kubernetes échoue.

Conditions préalables

Installez le CLI OpenShift (oc).
Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
Un cluster installé sur une infrastructure configurée avec le plugin réseau OVN-Kubernetes.

Procédure

Arrêter tous les pools de configuration de machines gérés par le MCO (Machine Config Operator) :

Arrêter le pool de configuration maître :

oc patch MachineConfigPool master --type='merge' --patch \
  '{ "spec": { "paused": true } }'

$ oc patch MachineConfigPool master --type='merge' --patch \
  '{ "spec": { "paused": true } }'

Copy to Clipboard

Toggle word wrap

Arrêter le pool de configuration de la machine de travail :

oc patch MachineConfigPool worker --type='merge' --patch \
  '{ "spec":{ "paused" :true } }'

$ oc patch MachineConfigPool worker --type='merge' --patch \
  '{ "spec":{ "paused" :true } }'

Copy to Clipboard

Toggle word wrap

Pour commencer la migration, réinitialisez le plugin réseau à OpenShift SDN en entrant les commandes suivantes :

oc patch Network.operator.openshift.io cluster --type='merge' \
  --patch '{ "spec": { "migration": { "networkType": "OpenShiftSDN" } } }'

oc patch Network.config.openshift.io cluster --type='merge' \
  --patch '{ "spec": { "networkType": "OpenShiftSDN" } }'

$ oc patch Network.operator.openshift.io cluster --type='merge' \
  --patch '{ "spec": { "migration": { "networkType": "OpenShiftSDN" } } }'

$ oc patch Network.config.openshift.io cluster --type='merge' \
  --patch '{ "spec": { "networkType": "OpenShiftSDN" } }'

Copy to Clipboard

Toggle word wrap

Facultatif : Vous pouvez désactiver la migration automatique de plusieurs capacités OVN-Kubernetes vers les équivalents SDN d'OpenShift :

IP de sortie
Pare-feu de sortie
Multidiffusion

Pour désactiver la migration automatique de la configuration pour l'une des fonctionnalités OpenShift SDN mentionnées précédemment, spécifiez les clés suivantes :

oc patch Network.operator.openshift.io cluster --type='merge' \
  --patch '{
    "spec": {
      "migration": {
        "networkType": "OpenShiftSDN",
        "features": {
          "egressIP": <bool>,
          "egressFirewall": <bool>,
          "multicast": <bool>
        }
      }
    }
  }'

$ oc patch Network.operator.openshift.io cluster --type='merge' \
  --patch '{
    "spec": {
      "migration": {
        "networkType": "OpenShiftSDN",
        "features": {
          "egressIP": <bool>,
          "egressFirewall": <bool>,
          "multicast": <bool>
        }
      }
    }
  }'

Copy to Clipboard

Toggle word wrap

où :

bool: Spécifie si la migration de la fonctionnalité doit être activée. La valeur par défaut est true.

Facultatif : vous pouvez personnaliser les paramètres suivants pour OpenShift SDN afin de répondre aux exigences de votre infrastructure réseau :
- Unité de transmission maximale (MTU)
- Port VXLAN
Pour personnaliser l'un ou l'autre des paramètres susmentionnés, ou les deux, personnalisez et entrez la commande suivante. Si vous n'avez pas besoin de modifier la valeur par défaut, omettez la clé du correctif.
```
oc patch Network.operator.openshift.io cluster --type=merge \
  --patch '{
    "spec":{
      "defaultNetwork":{
        "openshiftSDNConfig":{
          "mtu":<mtu>,
          "vxlanPort":<port>
    }}}}'
```
```
$ oc patch Network.operator.openshift.io cluster --type=merge \
  --patch '{
    "spec":{
      "defaultNetwork":{
        "openshiftSDNConfig":{
          "mtu":<mtu>,
          "vxlanPort":<port>
    }}}}'
```
Copy to Clipboard Toggle word wrap
mtu
Le MTU pour le réseau superposé VXLAN. Cette valeur est normalement configurée automatiquement, mais si les nœuds de votre cluster n'utilisent pas tous le même MTU, vous devez la définir explicitement à 50 moins que la plus petite valeur MTU du nœud.
port
Le port UDP pour le réseau superposé VXLAN. Si aucune valeur n'est spécifiée, la valeur par défaut est 4789. Le port ne peut pas être le même que le port Geneve utilisé par OVN-Kubernetes. La valeur par défaut du port Geneve est 6081.
Exemple de commande patch
```
oc patch Network.operator.openshift.io cluster --type=merge \
  --patch '{
    "spec":{
      "defaultNetwork":{
        "openshiftSDNConfig":{
          "mtu":1200
    }}}}'
```
```
$ oc patch Network.operator.openshift.io cluster --type=merge \
  --patch '{
    "spec":{
      "defaultNetwork":{
        "openshiftSDNConfig":{
          "mtu":1200
    }}}}'
```
Copy to Clipboard Toggle word wrap

Attendez que le déploiement du jeu de démons Multus soit terminé.

oc -n openshift-multus rollout status daemonset/multus

$ oc -n openshift-multus rollout status daemonset/multus

Copy to Clipboard

Toggle word wrap

Le nom des nacelles Multus se présente sous la forme multus-<xxxxx> où <xxxxx> est une séquence aléatoire de lettres. Le redémarrage des pods peut prendre quelques instants.

Exemple de sortie

Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated...
...
Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available...
daemon set "multus" successfully rolled out

Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated...
...
Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available...
daemon set "multus" successfully rolled out

Copy to Clipboard

Toggle word wrap

Pour terminer le retour en arrière, redémarrez chaque nœud de votre cluster. Par exemple, vous pouvez utiliser un script bash similaire au suivant. Le script suppose que vous pouvez vous connecter à chaque hôte en utilisant ssh et que vous avez configuré sudo pour ne pas demander de mot de passe.
```
#!/bin/bash

for ip in $(oc get nodes  -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}')
do
   echo "reboot node $ip"
   ssh -o StrictHostKeyChecking=no core@$ip sudo shutdown -r -t 3
done
```
```
#!/bin/bash

for ip in $(oc get nodes  -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}')
do
   echo "reboot node $ip"
   ssh -o StrictHostKeyChecking=no core@$ip sudo shutdown -r -t 3
done
```
Copy to Clipboard Toggle word wrap
Si l'accès ssh n'est pas disponible, vous pourrez peut-être redémarrer chaque nœud via le portail de gestion de votre fournisseur d'infrastructure.
Une fois que les nœuds de votre cluster ont redémarré, démarrez tous les pools de configuration des machines :
- Démarrer le pool de configuration maître :
  $ oc patch MachineConfigPool master --type='merge' --patch \ '{ "spec": { "paused": false } }'
  Copy to Clipboard Toggle word wrap
- Démarrer le pool de configuration du travailleur :
  $ oc patch MachineConfigPool worker --type='merge' --patch \ '{ "spec": { "paused": false } }'
  Copy to Clipboard Toggle word wrap
Lorsque le MCO met à jour les machines de chaque pool de configuration, il redémarre chaque nœud.
Par défaut, le MCO ne met à jour qu'une seule machine par pool à la fois, de sorte que le temps nécessaire à la migration augmente avec la taille du cluster.
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"
  Copy to Clipboard Toggle word wrap
  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
  
  Copy to Clipboard Toggle word wrap
  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
  Copy to Clipboard Toggle word wrap
  où <config_name> est le nom de la machine configurée dans le champ machineconfiguration.openshift.io/currentConfig.

Confirmez que la migration a réussi :

Pour confirmer que le plugin réseau est OpenShift SDN, entrez la commande suivante. La valeur de status.networkType doit être OpenShiftSDN.
```
oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
```
```
$ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
```
Copy to Clipboard Toggle word wrap
Pour confirmer que les nœuds du cluster sont dans l'état Ready, entrez la commande suivante :
```
oc get nodes
```
```
$ oc get nodes
```
Copy to Clipboard Toggle word wrap

Si un nœud est bloqué à l'état NotReady, examinez les journaux de pods du démon de configuration de la machine et résolvez les erreurs éventuelles.

Pour dresser la liste des pods, entrez la commande suivante :

oc get pod -n openshift-machine-config-operator

$ oc get pod -n openshift-machine-config-operator

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                         READY   STATUS    RESTARTS   AGE
machine-config-controller-75f756f89d-sjp8b   1/1     Running   0          37m
machine-config-daemon-5cf4b                  2/2     Running   0          43h
machine-config-daemon-7wzcd                  2/2     Running   0          43h
machine-config-daemon-fc946                  2/2     Running   0          43h
machine-config-daemon-g2v28                  2/2     Running   0          43h
machine-config-daemon-gcl4f                  2/2     Running   0          43h
machine-config-daemon-l5tnv                  2/2     Running   0          43h
machine-config-operator-79d9c55d5-hth92      1/1     Running   0          37m
machine-config-server-bsc8h                  1/1     Running   0          43h
machine-config-server-hklrm                  1/1     Running   0          43h
machine-config-server-k9rtx                  1/1     Running   0          43h

NAME                                         READY   STATUS    RESTARTS   AGE
machine-config-controller-75f756f89d-sjp8b   1/1     Running   0          37m
machine-config-daemon-5cf4b                  2/2     Running   0          43h
machine-config-daemon-7wzcd                  2/2     Running   0          43h
machine-config-daemon-fc946                  2/2     Running   0          43h
machine-config-daemon-g2v28                  2/2     Running   0          43h
machine-config-daemon-gcl4f                  2/2     Running   0          43h
machine-config-daemon-l5tnv                  2/2     Running   0          43h
machine-config-operator-79d9c55d5-hth92      1/1     Running   0          37m
machine-config-server-bsc8h                  1/1     Running   0          43h
machine-config-server-hklrm                  1/1     Running   0          43h
machine-config-server-k9rtx                  1/1     Running   0          43h

Copy to Clipboard

Toggle word wrap

Les noms des modules de démon de configuration sont au format suivant : machine-config-daemon-<seq>. La valeur <seq> est une séquence alphanumérique aléatoire de cinq caractères.

Pour afficher le journal des pods pour chaque pod de démon de configuration de machine présenté dans la sortie précédente, entrez la commande suivante :
```
oc logs <pod> -n openshift-machine-config-operator
```
```
$ oc logs <pod> -n openshift-machine-config-operator
```
Copy to Clipboard Toggle word wrap
où pod est le nom d'un pod de démon de configuration de machine.
Résoudre les erreurs éventuelles dans les journaux affichés par la sortie de la commande précédente.

Pour confirmer que vos pods ne sont pas dans un état d'erreur, entrez la commande suivante :
```
oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'
```
```
$ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'
```
Copy to Clipboard Toggle word wrap
Si les pods d'un nœud sont dans un état d'erreur, redémarrez ce nœud.

N'effectuez les étapes suivantes que si la migration a réussi et que votre cluster est en bon état :

Pour supprimer la configuration de la migration de l'objet de configuration Opérateur de réseau de cluster, entrez la commande suivante :

oc patch Network.operator.openshift.io cluster --type='merge' \
  --patch '{ "spec": { "migration": null } }'

$ oc patch Network.operator.openshift.io cluster --type='merge' \
  --patch '{ "spec": { "migration": null } }'

Copy to Clipboard

Toggle word wrap

Pour supprimer la configuration OVN-Kubernetes, entrez la commande suivante :

oc patch Network.operator.openshift.io cluster --type='merge' \
  --patch '{ "spec": { "defaultNetwork": { "ovnKubernetesConfig":null } } }'

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

Copy to Clipboard

Toggle word wrap

Pour supprimer l'espace de noms du fournisseur de réseau OVN-Kubernetes, entrez la commande suivante :
```
oc delete namespace openshift-ovn-kubernetes
```
```
$ oc delete namespace openshift-ovn-kubernetes
```
Copy to Clipboard Toggle word wrap

24.7. Passage à un réseau à double pile IPv4/IPv6
Copier lien

En tant qu'administrateur de cluster, vous pouvez convertir votre cluster IPv4 à pile unique en un cluster à double réseau prenant en charge les familles d'adresses IPv4 et IPv6. Après la conversion, tous les pods nouvellement créés sont activés pour la double pile.

Note

Un réseau à double pile est pris en charge sur les clusters provisionnés sur du bare metal, IBM Power, l'infrastructure IBM zSystems et les clusters OpenShift à nœud unique.

24.7.1. Conversion vers un réseau en grappe à double pile
Copier lien

En tant qu'administrateur de cluster, vous pouvez convertir votre réseau de cluster à pile unique en réseau de cluster à double pile.

Note

Après la conversion au réseau à double pile, seuls les nouveaux modules créés se voient attribuer des adresses IPv6. Tout pod créé avant la conversion doit être recréé pour recevoir une adresse IPv6.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
Votre cluster utilise le plugin réseau OVN-Kubernetes.
Les nœuds du cluster ont des adresses IPv6.
Vous avez configuré un routeur IPv6 en fonction de votre infrastructure.

Procédure

Pour spécifier les blocs d'adresses IPv6 pour le cluster et les réseaux de service, créez un fichier contenant le YAML suivant :
```
- op: add
  path: /spec/clusterNetwork/-
  value: 
    cidr: fd01::/48
    hostPrefix: 64
- op: add
  path: /spec/serviceNetwork/-
  value: fd02::/112 
```
```
- op: add
  path: /spec/clusterNetwork/-
  value: 
```
1
```
    cidr: fd01::/48
    hostPrefix: 64
- op: add
  path: /spec/serviceNetwork/-
  value: fd02::/112 
```
2
Copy to Clipboard Toggle word wrap
1
Spécifiez un objet avec les champs cidr et hostPrefix. Le préfixe d'hôte doit être égal ou supérieur à 64. Le préfixe CIDR IPv6 doit être suffisamment grand pour contenir le préfixe d'hôte spécifié.
2
Spécifiez un CIDR IPv6 avec un préfixe de 112. Kubernetes n'utilise que les 16 bits les plus bas. Pour un préfixe de 112, les adresses IP sont attribuées de 112 à 128 bits.
Pour corriger la configuration du réseau de la grappe, entrez la commande suivante :
```
oc patch network.config.openshift.io cluster \
  --type='json' --patch-file <file>.yaml
```
```
$ oc patch network.config.openshift.io cluster \
  --type='json' --patch-file <file>.yaml
```
Copy to Clipboard Toggle word wrap
où :
file
Indique le nom du fichier que vous avez créé à l'étape précédente.
Exemple de sortie
```
network.config.openshift.io/cluster patched
```
```
network.config.openshift.io/cluster patched
```
Copy to Clipboard Toggle word wrap

Vérification

Effectuez l'étape suivante pour vérifier que le réseau cluster reconnaît les blocs d'adresses IPv6 que vous avez spécifiés dans la procédure précédente.

Affiche la configuration du réseau :

oc describe network

$ oc describe network

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Status:
  Cluster Network:
    Cidr:               10.128.0.0/14
    Host Prefix:        23
    Cidr:               fd01::/48
    Host Prefix:        64
  Cluster Network MTU:  1400
  Network Type:         OVNKubernetes
  Service Network:
    172.30.0.0/16
    fd02::/112

Status:
  Cluster Network:
    Cidr:               10.128.0.0/14
    Host Prefix:        23
    Cidr:               fd01::/48
    Host Prefix:        64
  Cluster Network MTU:  1400
  Network Type:         OVNKubernetes
  Service Network:
    172.30.0.0/16
    fd02::/112

Copy to Clipboard

Toggle word wrap

24.7.2. Conversion vers un réseau en grappe à pile unique
Copier lien

En tant qu'administrateur de cluster, vous pouvez convertir votre réseau de cluster à double pile en un réseau de cluster à pile unique.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
Votre cluster utilise le plugin réseau OVN-Kubernetes.
Les nœuds du cluster ont des adresses IPv6.
Vous avez activé la mise en réseau à double pile.

Procédure

Modifiez la ressource personnalisée (CR) networks.config.openshift.io en exécutant la commande suivante :
```
oc edit networks.config.openshift.io
```
```
$ oc edit networks.config.openshift.io
```
Copy to Clipboard Toggle word wrap
Supprimez la configuration spécifique à IPv6 que vous avez ajoutée aux champs cidr et hostPrefix dans la procédure précédente.

24.8. Journalisation des règles de pare-feu et de stratégie de réseau de sortie
Copier lien

En tant qu'administrateur de cluster, vous pouvez configurer la journalisation d'audit pour votre cluster et activer la journalisation pour un ou plusieurs espaces de noms. OpenShift Container Platform produit des journaux d'audit pour les pare-feu de sortie et les stratégies réseau.

Note

La journalisation des audits n'est disponible que pour le plugin réseau OVN-Kubernetes.

24.8.1. Journalisation des audits
Copier lien

Le plugin réseau OVN-Kubernetes utilise les ACL de l'Open Virtual Network (OVN) pour gérer les pare-feu de sortie et les politiques de réseau. La journalisation d'audit expose les événements d'autorisation et de refus des ACL.

Vous pouvez configurer la destination des journaux d'audit, comme un serveur syslog ou un socket de domaine UNIX. Indépendamment de toute configuration supplémentaire, un journal d'audit est toujours enregistré sur /var/log/ovn/acl-audit-log.log sur chaque pod OVN-Kubernetes dans le cluster.

L'enregistrement des audits est activé par espace de noms en annotant l'espace de noms avec la clé k8s.ovn.org/acl-logging comme dans l'exemple suivant :

Exemple d'annotation d'un espace de noms

kind: Namespace
apiVersion: v1
metadata:
  name: example1
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "info",
        "allow": "info"
      }

kind: Namespace
apiVersion: v1
metadata:
  name: example1
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "info",
        "allow": "info"
      }

Copy to Clipboard

Toggle word wrap

Le format de journalisation est compatible avec syslog tel que défini par RFC5424. L'option syslog est configurable et est définie par défaut sur local0. Un exemple d'entrée de journal peut ressembler à ce qui suit :

Exemple d'entrée de journal de refus d'ACL pour une stratégie de réseau

2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

Copy to Clipboard

Toggle word wrap

Le tableau suivant décrit les valeurs d'annotation de l'espace de noms :

Expand

Tableau 24.9. Annotation de l'espace de noms pour la journalisation des audits
Annotation	Valeur
`k8s.ovn.org/acl-logging`	Vous devez spécifier au moins l'un des éléments suivants : `allow`, `deny`, ou les deux pour activer la journalisation des audits pour un espace de noms. `deny` Optionnel : Indiquez `alert`, `warning`, `notice`, `info`, ou `debug`. `allow` Optionnel : Indiquez `alert`, `warning`, `notice`, `info`, ou `debug`.

24.8.2. Configuration de l'audit
Copier lien

La configuration de la journalisation des audits est spécifiée dans le cadre de la configuration du fournisseur de réseau du cluster OVN-Kubernetes. Le fichier YAML suivant illustre les valeurs par défaut pour la journalisation des audits :

Configuration de la journalisation des audits

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

Copy to Clipboard

Toggle word wrap

Le tableau suivant décrit les champs de configuration de la journalisation des audits.

Expand

Tableau 24.10. policyAuditConfig objet
Field	Type	Description
`rateLimit`	entier	Nombre maximal de messages à générer chaque seconde par nœud. La valeur par défaut est `20` messages par seconde.
`maxFileSize`	entier	Taille maximale du journal d'audit en octets. La valeur par défaut est `50000000` ou 50 Mo.
`destination`	chaîne de caractères	One of the following additional audit log targets: `libc` La fonction libc `syslog()` du processus journald sur l'hôte. `udp:<host>:<port>` Un serveur syslog. Remplacez `<host>:<port>` par l'hôte et le port du serveur syslog. `unix:<file>` Un fichier Unix Domain Socket spécifié par `<file>`. `null` Do not send the audit logs to any additional target.
`syslogFacility`	chaîne de caractères	L'installation syslog, telle que `kern`, telle que définie par RFC5424. La valeur par défaut est `local0`.

24.8.3. Configuration de l'audit du pare-feu de sortie et de la stratégie réseau pour un cluster
Copier lien

En tant qu'administrateur de cluster, vous pouvez personnaliser la journalisation des audits pour votre cluster.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous au cluster avec un utilisateur disposant des privilèges cluster-admin.

Procédure

Pour personnaliser la configuration de la journalisation des audits, entrez la commande suivante :

oc edit network.operator.openshift.io/cluster

$ oc edit network.operator.openshift.io/cluster

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également personnaliser et appliquer le fichier YAML suivant pour configurer l'enregistrement des audits :

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

Copy to Clipboard

Toggle word wrap

Vérification

Pour créer un espace de noms avec des stratégies de réseau, procédez comme suit :

Créer un espace de noms pour la vérification :

cat <<EOF| oc create -f -
kind: Namespace
apiVersion: v1
metadata:
  name: verify-audit-logging
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert" }'
EOF

$ cat <<EOF| oc create -f -
kind: Namespace
apiVersion: v1
metadata:
  name: verify-audit-logging
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert" }'
EOF

Copy to Clipboard

Toggle word wrap

Exemple de sortie

namespace/verify-audit-logging created

namespace/verify-audit-logging created

Copy to Clipboard

Toggle word wrap

Activer la journalisation des audits :

oc annotate namespace verify-audit-logging k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "alert" }'

$ oc annotate namespace verify-audit-logging k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "alert" }'

Copy to Clipboard

Toggle word wrap

namespace/verify-audit-logging annotated

namespace/verify-audit-logging annotated

Copy to Clipboard

Toggle word wrap

Créer des politiques de réseau pour l'espace de noms :

cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector:
    matchLabels:
  policyTypes:
  - Ingress
  - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-same-namespace
spec:
  podSelector: {}
  policyTypes:
   - Ingress
   - Egress
  ingress:
    - from:
        - podSelector: {}
  egress:
    - to:
       - namespaceSelector:
          matchLabels:
            namespace: verify-audit-logging
EOF

$ cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector:
    matchLabels:
  policyTypes:
  - Ingress
  - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-same-namespace
spec:
  podSelector: {}
  policyTypes:
   - Ingress
   - Egress
  ingress:
    - from:
        - podSelector: {}
  egress:
    - to:
       - namespaceSelector:
          matchLabels:
            namespace: verify-audit-logging
EOF

Copy to Clipboard

Toggle word wrap

Exemple de sortie

networkpolicy.networking.k8s.io/deny-all created
networkpolicy.networking.k8s.io/allow-from-same-namespace created

networkpolicy.networking.k8s.io/deny-all created
networkpolicy.networking.k8s.io/allow-from-same-namespace created

Copy to Clipboard

Toggle word wrap

Créer un pod pour le trafic source dans l'espace de noms default:

cat <<EOF| oc create -n default -f -
apiVersion: v1
kind: Pod
metadata:
  name: client
spec:
  containers:
    - name: client
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF

$ cat <<EOF| oc create -n default -f -
apiVersion: v1
kind: Pod
metadata:
  name: client
spec:
  containers:
    - name: client
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF

Copy to Clipboard

Toggle word wrap

Créer deux pods dans l'espace de noms verify-audit-logging:

for name in client server; do
cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: v1
kind: Pod
metadata:
  name: ${name}
spec:
  containers:
    - name: ${name}
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF
done

$ for name in client server; do
cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: v1
kind: Pod
metadata:
  name: ${name}
spec:
  containers:
    - name: ${name}
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF
done

Copy to Clipboard

Toggle word wrap

Exemple de sortie

pod/client created
pod/server created

pod/client created
pod/server created

Copy to Clipboard

Toggle word wrap

Pour générer du trafic et produire des entrées de journal d'audit de stratégie de réseau, procédez comme suit :

Obtenir l'adresse IP du pod nommé server dans l'espace de noms verify-audit-logging:

POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')

$ POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')

Copy to Clipboard

Toggle word wrap

Effectuez un ping de l'adresse IP de la commande précédente à partir du pod nommé client dans l'espace de noms default et confirmez que tous les paquets sont abandonnés :

oc exec -it client -n default -- /bin/ping -c 2 $POD_IP

$ oc exec -it client -n default -- /bin/ping -c 2 $POD_IP

Copy to Clipboard

Toggle word wrap

Exemple de sortie

PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data.

--- 10.128.2.55 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 2041ms

PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data.

--- 10.128.2.55 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 2041ms

Copy to Clipboard

Toggle word wrap

Effectuez un ping de l'adresse IP enregistrée dans la variable d'environnement du shell POD_IP à partir du pod nommé client dans l'espace de noms verify-audit-logging et confirmez que tous les paquets sont autorisés :

oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP

$ oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP

Copy to Clipboard

Toggle word wrap

Exemple de sortie

PING 10.128.0.86 (10.128.0.86) 56(84) bytes of data.
64 bytes from 10.128.0.86: icmp_seq=1 ttl=64 time=2.21 ms
64 bytes from 10.128.0.86: icmp_seq=2 ttl=64 time=0.440 ms

--- 10.128.0.86 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.440/1.329/2.219/0.890 ms

PING 10.128.0.86 (10.128.0.86) 56(84) bytes of data.
64 bytes from 10.128.0.86: icmp_seq=1 ttl=64 time=2.21 ms
64 bytes from 10.128.0.86: icmp_seq=2 ttl=64 time=0.440 ms

--- 10.128.0.86 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.440/1.329/2.219/0.890 ms

Copy to Clipboard

Toggle word wrap

Affiche les dernières entrées du journal d'audit de la stratégie de réseau :

for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Defaulting container name to ovn-controller.
Use 'oc describe pod/ovnkube-node-hdb8v -n openshift-ovn-kubernetes' to see all of the containers in this pod.
2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
2021-06-13T19:33:12.614Z|00006|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
2021-06-13T19:44:10.037Z|00007|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_allow-from-same-namespace_0", verdict=allow, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:3b,dl_dst=0a:58:0a:80:02:3a,nw_src=10.128.2.59,nw_dst=10.128.2.58,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
2021-06-13T19:44:11.037Z|00008|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_allow-from-same-namespace_0", verdict=allow, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:3b,dl_dst=0a:58:0a:80:02:3a,nw_src=10.128.2.59,nw_dst=10.128.2.58,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

Defaulting container name to ovn-controller.
Use 'oc describe pod/ovnkube-node-hdb8v -n openshift-ovn-kubernetes' to see all of the containers in this pod.
2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
2021-06-13T19:33:12.614Z|00006|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
2021-06-13T19:44:10.037Z|00007|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_allow-from-same-namespace_0", verdict=allow, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:3b,dl_dst=0a:58:0a:80:02:3a,nw_src=10.128.2.59,nw_dst=10.128.2.58,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
2021-06-13T19:44:11.037Z|00008|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_allow-from-same-namespace_0", verdict=allow, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:3b,dl_dst=0a:58:0a:80:02:3a,nw_src=10.128.2.59,nw_dst=10.128.2.58,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

Copy to Clipboard

Toggle word wrap

24.8.4. Activation de la journalisation d'audit du pare-feu de sortie et de la stratégie de réseau pour un espace de noms
Copier lien

En tant qu'administrateur de cluster, vous pouvez activer la journalisation d'audit pour un espace de noms.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous au cluster avec un utilisateur disposant des privilèges cluster-admin.

Procédure

Pour activer la journalisation des audits pour un espace de noms, entrez la commande suivante :

oc annotate namespace <namespace> \
  k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'

$ oc annotate namespace <namespace> \
  k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'

Copy to Clipboard

Toggle word wrap

où :

<namespace>: Spécifie le nom de l'espace de noms.

Astuce

Vous pouvez également appliquer le code YAML suivant pour activer l'enregistrement des audits :

kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "alert",
        "allow": "notice"
      }

kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "alert",
        "allow": "notice"
      }

Copy to Clipboard

Toggle word wrap

Exemple de sortie

namespace/verify-audit-logging annotated

namespace/verify-audit-logging annotated

Copy to Clipboard

Toggle word wrap

Vérification

Affiche les dernières entrées du journal d'audit :

for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

Copy to Clipboard

Toggle word wrap

Exemple de sortie

2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

Copy to Clipboard

Toggle word wrap

24.8.5. Désactivation de la journalisation d'audit du pare-feu de sortie et de la stratégie de réseau pour un espace de noms
Copier lien

En tant qu'administrateur de cluster, vous pouvez désactiver la journalisation d'audit pour un espace de noms.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous au cluster avec un utilisateur disposant des privilèges cluster-admin.

Procédure

Pour désactiver la journalisation des audits pour un espace de noms, entrez la commande suivante :

oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-

oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-

Copy to Clipboard

Toggle word wrap

où :

<namespace>: Spécifie le nom de l'espace de noms.

Astuce

Vous pouvez également appliquer le code YAML suivant pour désactiver la journalisation des audits :

kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: null

kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: null

Copy to Clipboard

Toggle word wrap

Exemple de sortie

namespace/verify-audit-logging annotated

namespace/verify-audit-logging annotated

Copy to Clipboard

Toggle word wrap

24.9. Configuration du cryptage IPsec
Copier lien

Lorsque l'option IPsec est activée, tout le trafic réseau entre les nœuds du cluster OVN-Kubernetes est crypté avec IPsec Transport mode.

IPsec est désactivé par défaut. Il peut être activé pendant ou après l'installation du cluster. Pour plus d'informations sur l'installation d'un cluster, voir OpenShift Container Platform installation overview. Si vous devez activer IPsec après l'installation du cluster, vous devez d'abord redimensionner le MTU de votre cluster pour prendre en compte la surcharge de l'en-tête IPsec ESP.

La documentation suivante décrit comment activer et désactiver IPSec après l'installation du cluster.

24.9.1. Conditions préalables
Copier lien

Vous avez diminué la taille du MTU de la grappe de 46 octets pour tenir compte de la surcharge supplémentaire de l'en-tête ESP IPsec. Pour plus d'informations sur le redimensionnement du MTU utilisé par votre cluster, reportez-vous à la section Modification du MTU pour le réseau du cluster.

24.9.2. Types de flux de trafic réseau cryptés par IPsec
Copier lien

Lorsque le protocole IPsec est activé, seuls les flux de trafic réseau suivants entre les pods sont cryptés :

Trafic entre pods sur différents nœuds du réseau de la grappe
Trafic d'un pod sur le réseau hôte vers un pod sur le réseau cluster

Les flux de trafic suivants ne sont pas cryptés :

Trafic entre les pods situés sur le même nœud du réseau de la grappe
Trafic entre les pods sur le réseau hôte
Trafic d'un pod sur le réseau cluster vers un pod sur le réseau hôte

Les flux cryptés et non cryptés sont illustrés dans le diagramme suivant :

IPsec encrypted and unencrypted traffic flows

24.9.2.1. Exigences en matière de connectivité réseau lorsque IPsec est activé
Copier lien

You must configure the network connectivity between machines to allow OpenShift Container Platform cluster components to communicate. Each machine must be able to resolve the hostnames of all other machines in the cluster.

Expand

Tableau 24.11. Ports used for all-machine to all-machine communications
Protocol	Port	Description
UDP	`500`	IPsec IKE packets
UDP	`4500`	IPsec NAT-T packets
ESP	N/A	IPsec Encapsulating Security Payload (ESP)

24.9.3. Protocole de cryptage et mode IPsec
Copier lien

Le cryptogramme utilisé est AES-GCM-16-256. La valeur de contrôle d'intégrité (ICV) est de 16 octets. La longueur de la clé est de 256 bits.

Le mode IPsec utilisé est Transport modeiPsec est un mode qui crypte les communications de bout en bout en ajoutant un en-tête ESP (Encapsulated Security Payload) à l'en-tête IP du paquet d'origine et en cryptant les données du paquet. OpenShift Container Platform n'utilise ni ne prend actuellement en charge IPsec Tunnel mode pour les communications de pod à pod.

24.9.4. Génération et rotation des certificats de sécurité
Copier lien

L'opérateur du réseau de cluster (CNO) génère une autorité de certification (CA) X.509 auto-signée qui est utilisée par IPsec pour le cryptage. Les demandes de signature de certificat (CSR) de chaque nœud sont automatiquement satisfaites par le CNO.

La validité de l'autorité de certification est de 10 ans. Les certificats individuels des nœuds sont valables 5 ans et sont automatiquement remplacés après 4 ans et demi.

24.9.5. Activation du cryptage IPsec
Copier lien

En tant qu'administrateur de cluster, vous pouvez activer le cryptage IPsec après l'installation du cluster.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous au cluster avec un utilisateur disposant des privilèges cluster-admin.
Vous avez réduit la taille du MTU de votre cluster de 46 octets pour tenir compte de la surcharge de l'en-tête IPsec ESP.

Procédure

Pour activer le cryptage IPsec, entrez la commande suivante :

oc patch networks.operator.openshift.io cluster --type=merge \
-p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipsecConfig":{ }}}}}'

$ oc patch networks.operator.openshift.io cluster --type=merge \
-p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipsecConfig":{ }}}}}'

Copy to Clipboard

Toggle word wrap

24.9.6. Vérification de l'activation d'IPsec
Copier lien

En tant qu'administrateur de cluster, vous pouvez vérifier que le protocole IPsec est activé.

Vérification

Pour trouver les noms des pods du plan de contrôle OVN-Kubernetes, entrez la commande suivante :

oc get pods -n openshift-ovn-kubernetes | grep ovnkube-master

$ oc get pods -n openshift-ovn-kubernetes | grep ovnkube-master

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ovnkube-master-4496s        1/1     Running   0          6h39m
ovnkube-master-d6cht        1/1     Running   0          6h42m
ovnkube-master-skblc        1/1     Running   0          6h51m
ovnkube-master-vf8rf        1/1     Running   0          6h51m
ovnkube-master-w7hjr        1/1     Running   0          6h51m
ovnkube-master-zsk7x        1/1     Running   0          6h42m

ovnkube-master-4496s        1/1     Running   0          6h39m
ovnkube-master-d6cht        1/1     Running   0          6h42m
ovnkube-master-skblc        1/1     Running   0          6h51m
ovnkube-master-vf8rf        1/1     Running   0          6h51m
ovnkube-master-w7hjr        1/1     Running   0          6h51m
ovnkube-master-zsk7x        1/1     Running   0          6h42m

Copy to Clipboard

Toggle word wrap

Vérifiez que le protocole IPsec est activé sur votre cluster :
```
oc -n openshift-ovn-kubernetes -c nbdb rsh ovnkube-master-<XXXXX> \
  ovn-nbctl --no-leader-only get nb_global . ipsec
```
```
$ oc -n openshift-ovn-kubernetes -c nbdb rsh ovnkube-master-<XXXXX> \
  ovn-nbctl --no-leader-only get nb_global . ipsec
```
Copy to Clipboard Toggle word wrap
où :
<XXXXX>
Spécifie la séquence aléatoire de lettres pour un pod de l'étape précédente.
Exemple de sortie
```
true
```
```
true
```
Copy to Clipboard Toggle word wrap

24.9.7. Désactivation du cryptage IPsec
Copier lien

En tant qu'administrateur de cluster, vous ne pouvez désactiver le cryptage IPsec que si vous avez activé IPsec après l'installation du cluster.

Note

Si vous avez activé IPsec lors de l'installation de votre cluster, vous ne pouvez pas désactiver IPsec avec cette procédure.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous au cluster avec un utilisateur disposant des privilèges cluster-admin.

Procédure

Pour désactiver le cryptage IPsec, entrez la commande suivante :

oc patch networks.operator.openshift.io/cluster --type=json \
  -p='[{"op":"remove", "path":"/spec/defaultNetwork/ovnKubernetesConfig/ipsecConfig"}]'

$ oc patch networks.operator.openshift.io/cluster --type=json \
  -p='[{"op":"remove", "path":"/spec/defaultNetwork/ovnKubernetesConfig/ipsecConfig"}]'

Copy to Clipboard

Toggle word wrap

Facultatif : vous pouvez augmenter la taille du MTU de votre cluster de 46 octets car il n'y a plus de surcharge due à l'en-tête ESP IPsec dans les paquets IP.

24.9.8. Ressources supplémentaires
Copier lien

24.10. Configuration d'un pare-feu de sortie pour un projet
Copier lien

En tant qu'administrateur de cluster, vous pouvez créer un pare-feu de sortie pour un projet qui restreint le trafic de sortie de votre cluster OpenShift Container Platform.

24.10.1. Fonctionnement d'un pare-feu de sortie dans un projet
Copier lien

En tant qu'administrateur de cluster, vous pouvez utiliser un egress firewall pour limiter les hôtes externes auxquels certains ou tous les pods peuvent accéder depuis le cluster. Un pare-feu de sortie prend en charge les scénarios suivants :

Un pod ne peut se connecter qu'à des hôtes internes et ne peut pas établir de connexions avec l'internet public.
Un pod ne peut se connecter qu'à l'internet public et ne peut pas initier de connexions vers des hôtes internes qui sont en dehors du cluster OpenShift Container Platform.
Un pod ne peut pas atteindre les sous-réseaux internes spécifiés ou les hôtes en dehors du cluster OpenShift Container Platform.
Un pod ne peut se connecter qu'à des hôtes externes spécifiques.

Par exemple, vous pouvez autoriser un projet à accéder à une plage d'adresses IP donnée, mais refuser le même accès à un autre projet. Vous pouvez également empêcher les développeurs d'applications d'effectuer des mises à jour à partir des miroirs de Python Pip et exiger que les mises à jour proviennent uniquement de sources approuvées.

Note

Le pare-feu de sortie ne s'applique pas à l'espace de noms du réseau hôte. Les pods dont le réseau d'hôtes est activé ne sont pas affectés par les règles de pare-feu de sortie.

Vous configurez une stratégie de pare-feu de sortie en créant un objet de ressource personnalisée (CR) EgressFirewall. Le pare-feu de sortie correspond au trafic réseau qui répond à l'un des critères suivants :

Une plage d'adresses IP au format CIDR
Un nom DNS qui se résout en une adresse IP
Un numéro de port
Un protocole qui est l'un des protocoles suivants : TCP, UDP et SCTP

Important

Si votre pare-feu de sortie comprend une règle de refus pour 0.0.0.0/0, l'accès à vos serveurs API OpenShift Container Platform est bloqué. Vous devez soit ajouter des règles d'autorisation pour chaque adresse IP, soit utiliser la règle d'autorisation de type nodeSelector dans vos règles de stratégie de sortie pour vous connecter aux serveurs API.

L'exemple suivant illustre l'ordre des règles de pare-feu de sortie nécessaires pour garantir l'accès au serveur API :

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
  namespace: <namespace> 
spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range> 
    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0 
    type: Deny

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
  namespace: <namespace>

1


spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range>

2


    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0

3


    type: Deny

Copy to Clipboard

Toggle word wrap

1: L'espace de noms pour le pare-feu de sortie.
2: La plage d'adresses IP qui comprend vos serveurs API OpenShift Container Platform.
3: Une règle de refus globale empêche l'accès aux serveurs API de OpenShift Container Platform.

Pour trouver l'adresse IP de vos serveurs API, exécutez oc get ep kubernetes -n default.

Pour plus d'informations, voir BZ#1988324.

Avertissement

Les règles de pare-feu de sortie ne s'appliquent pas au trafic qui passe par les routeurs. Tout utilisateur autorisé à créer un objet Route CR peut contourner les règles du pare-feu de sortie en créant une route qui pointe vers une destination interdite.

24.10.1.1. Limites d'un pare-feu de sortie
Copier lien

Un pare-feu de sortie présente les limitations suivantes :

Aucun projet ne peut avoir plus d'un objet EgressFirewall.
Un maximum d'un objet EgressFirewall avec un maximum de 8 000 règles peut être défini par projet.
Si vous utilisez le plugin réseau OVN-Kubernetes avec le mode passerelle partagée dans Red Hat OpenShift Networking, les réponses de retour d'entrée sont affectées par les règles de pare-feu de sortie. Si les règles de pare-feu de sortie éliminent l'IP de destination de la réponse d'entrée, le trafic est éliminé.

La violation de l'une ou l'autre de ces restrictions a pour effet de briser le pare-feu de sortie du projet et peut entraîner l'interruption de tout le trafic du réseau externe.

Une ressource Egress Firewall peut être créée dans les projets kube-node-lease, kube-public, kube-system, openshift et openshift-.

24.10.1.2. Ordre de correspondance pour les règles de politique de pare-feu de sortie
Copier lien

Les règles de pare-feu de sortie sont évaluées dans l'ordre où elles sont définies, de la première à la dernière. La première règle qui correspond à une connexion de sortie d'un pod s'applique. Les règles suivantes sont ignorées pour cette connexion.

24.10.1.3. Fonctionnement de la résolution des serveurs de noms de domaine (DNS)
Copier lien

Si vous utilisez des noms DNS dans l'une de vos règles de stratégie de pare-feu de sortie, la résolution correcte des noms de domaine est soumise aux restrictions suivantes :

Les mises à jour de noms de domaine sont interrogées sur la base d'une durée de vie (TTL). Par défaut, cette durée est de 30 minutes. Lorsque le contrôleur du pare-feu de sortie interroge les serveurs de noms locaux pour un nom de domaine, si la réponse inclut un TTL et que celui-ci est inférieur à 30 minutes, le contrôleur définit la durée pour ce nom DNS à la valeur renvoyée. Chaque nom DNS est interrogé après l'expiration du TTL de l'enregistrement DNS.
Le pod doit résoudre le domaine à partir des mêmes serveurs de noms locaux si nécessaire. Sinon, les adresses IP du domaine connues par le contrôleur du pare-feu de sortie et le module peuvent être différentes. Si les adresses IP d'un nom d'hôte diffèrent, le pare-feu de sortie risque de ne pas être appliqué de manière cohérente.
Étant donné que le contrôleur de pare-feu de sortie et les modules interrogent de manière asynchrone le même serveur de noms local, le module peut obtenir l'adresse IP mise à jour avant le contrôleur de sortie, ce qui provoque une situation de course. En raison de cette limitation actuelle, l'utilisation de noms de domaine dans les objets EgressFirewall n'est recommandée que pour les domaines dont les changements d'adresse IP sont peu fréquents.

Note

Le pare-feu de sortie permet toujours aux pods d'accéder à l'interface externe du nœud sur lequel le pod se trouve pour la résolution DNS.

Si vous utilisez des noms de domaine dans votre stratégie de pare-feu de sortie et que votre résolution DNS n'est pas gérée par un serveur DNS sur le nœud local, vous devez ajouter des règles de pare-feu de sortie qui autorisent l'accès aux adresses IP de votre serveur DNS. si vous utilisez des noms de domaine dans vos modules.

24.10.2. Objet de ressource personnalisée (CR) EgressFirewall
Copier lien

Vous pouvez définir une ou plusieurs règles pour un pare-feu de sortie. Une règle est soit une règle Allow, soit une règle Deny, avec une spécification du trafic auquel la règle s'applique.

Le fichier YAML suivant décrit un objet CR EgressFirewall :

Objet EgressFirewall

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: <name> 
spec:
  egress: 
    ...

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: <name>

1


spec:
  egress:

2

...

Copy to Clipboard

Toggle word wrap

1: Le nom de l'objet doit être default.
2: Ensemble d'une ou de plusieurs règles de politique de réseau de sortie, comme décrit dans la section suivante.

24.10.2.1. Règles EgressFirewall
Copier lien

Le fichier YAML suivant décrit un objet de règle de pare-feu de sortie. L'utilisateur peut sélectionner une plage d'adresses IP au format CIDR, un nom de domaine ou utiliser nodeSelector pour autoriser ou refuser le trafic de sortie. La strophe egress attend un tableau d'un ou plusieurs objets.

Règles de politique de sortie (Egress policy rule stanza)

egress:
- type: <type> 
  to: 
    cidrSelector: <cidr> 
    dnsName: <dns_name> 
    nodeSelector: <label_name>: <label_value> 
  ports: 
      ...

egress:
- type: <type>

1

to:

2


    cidrSelector: <cidr>

3


    dnsName: <dns_name>

4


    nodeSelector: <label_name>: <label_value>

5


  ports:

6

...

Copy to Clipboard

Toggle word wrap

1: Le type de règle. La valeur doit être Allow ou Deny.
2: Une strophe décrivant une règle de correspondance du trafic de sortie qui spécifie le champ cidrSelector ou le champ dnsName. Vous ne pouvez pas utiliser les deux champs dans la même règle.
3: Une plage d'adresses IP au format CIDR.
4: Un nom de domaine DNS.
5: Les étiquettes sont des paires clé/valeur définies par l'utilisateur. Les étiquettes sont attachées à des objets, tels que les nacelles. Le site nodeSelector permet de sélectionner un ou plusieurs labels de nœuds et de les attacher aux nacelles.
6: Facultatif : Une strophe décrivant une collection de ports réseau et de protocoles pour la règle.

Strophe portuaire

ports:
- port: <port> 
  protocol: <protocol>

ports:
- port: <port>

1


  protocol: <protocol>

2

Copy to Clipboard

Toggle word wrap

1: Un port réseau, tel que 80 ou 443. Si vous spécifiez une valeur pour ce champ, vous devez également spécifier une valeur pour protocol.
2: Un protocole de réseau. La valeur doit être soit TCP, UDP, soit SCTP.

24.10.2.2. Exemple d'objets CR EgressFirewall
Copier lien

L'exemple suivant définit plusieurs règles de stratégie de pare-feu de sortie :

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress: 
  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress:

1


  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0

Copy to Clipboard

Toggle word wrap

1: Une collection d'objets de règles de stratégie de pare-feu de sortie.

L'exemple suivant définit une règle de stratégie qui refuse le trafic vers l'hôte à l'adresse IP 172.16.1.1, si le trafic utilise le protocole TCP et le port de destination 80 ou n'importe quel protocole et le port de destination 443.

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress:
  - type: Deny
    to:
      cidrSelector: 172.16.1.1
    ports:
    - port: 80
      protocol: TCP
    - port: 443

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress:
  - type: Deny
    to:
      cidrSelector: 172.16.1.1
    ports:
    - port: 80
      protocol: TCP
    - port: 443

Copy to Clipboard

Toggle word wrap

24.10.2.3. Exemple de nodeSelector pour EgressFirewall
Copier lien

En tant qu'administrateur de cluster, vous pouvez autoriser ou refuser le trafic de sortie vers les nœuds de votre cluster en spécifiant une étiquette à l'aide de nodeSelector. Les étiquettes peuvent être appliquées à un ou plusieurs nœuds. Voici un exemple avec l'étiquette region=east:

apiVersion: v1
kind: Pod
metadata:
  name: default
spec:
    egress:
    - to:
        nodeSelector:
          matchLabels:
            region: east
      type: Allow

apiVersion: v1
kind: Pod
metadata:
  name: default
spec:
    egress:
    - to:
        nodeSelector:
          matchLabels:
            region: east
      type: Allow

Copy to Clipboard

Toggle word wrap

Astuce

Au lieu d'ajouter des règles manuelles par adresse IP de nœud, utilisez les sélecteurs de nœuds pour créer une étiquette qui permet aux pods situés derrière un pare-feu de sortie d'accéder aux pods du réseau hôte.

24.10.3. Création d'un objet de stratégie de pare-feu de sortie
Copier lien

En tant qu'administrateur de cluster, vous pouvez créer un objet de stratégie de pare-feu de sortie pour un projet.

Important

Si le projet a déjà un objet EgressFirewall défini, vous devez modifier la stratégie existante pour apporter des changements aux règles du pare-feu de sortie.

Conditions préalables

Un cluster qui utilise le plugin réseau OVN-Kubernetes.
Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster en tant qu'administrateur du cluster.

Procédure

Créer une règle de politique :
1. Créez un fichier <policy_name>.yaml dans lequel <policy_name> décrit les règles de la politique de sortie.
2. Dans le fichier que vous avez créé, définissez un objet de politique de sortie.
Entrez la commande suivante pour créer l'objet de politique. Remplacez <policy_name> par le nom de la politique et <project> par le projet auquel la règle s'applique.
```
oc create -f <policy_name>.yaml -n <project>
```
```
oc create -f <policy_name>.yaml -n <project>
```
Copy to Clipboard Toggle word wrap
Dans l'exemple suivant, un nouvel objet EgressFirewall est créé dans un projet nommé project1:
```
oc create -f default.yaml -n project1
```
```
$ oc create -f default.yaml -n project1
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
egressfirewall.k8s.ovn.org/v1 created
```
```
egressfirewall.k8s.ovn.org/v1 created
```
Copy to Clipboard Toggle word wrap
Facultatif : Enregistrez le fichier <policy_name>.yaml pour pouvoir le modifier ultérieurement.

24.11. Visualisation d'un pare-feu de sortie pour un projet
Copier lien

En tant qu'administrateur de cluster, vous pouvez dresser la liste des noms de tous les pare-feux de sortie existants et afficher les règles de trafic pour un pare-feu de sortie spécifique.

24.11.1. Visualisation d'un objet EgressFirewall
Copier lien

Vous pouvez visualiser un objet EgressFirewall dans votre cluster.

Conditions préalables

Un cluster utilisant le plugin réseau OVN-Kubernetes.
Installer l'interface de ligne de commande (CLI) d'OpenShift, communément appelée oc.
Vous devez vous connecter au cluster.

Procédure

Facultatif : Pour afficher les noms des objets EgressFirewall définis dans votre cluster, entrez la commande suivante :
```
oc get egressfirewall --all-namespaces
```
```
$ oc get egressfirewall --all-namespaces
```
Copy to Clipboard Toggle word wrap

Pour inspecter une politique, entrez la commande suivante. Remplacez <policy_name> par le nom de la stratégie à inspecter.

oc describe egressfirewall <nom_de_la_politique>

$ oc describe egressfirewall <nom_de_la_politique>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name:		default
Namespace:	project1
Created:	20 minutes ago
Labels:		<none>
Annotations:	<none>
Rule:		Allow to 1.2.3.0/24
Rule:		Allow to www.example.com
Rule:		Deny to 0.0.0.0/0

Name:		default
Namespace:	project1
Created:	20 minutes ago
Labels:		<none>
Annotations:	<none>
Rule:		Allow to 1.2.3.0/24
Rule:		Allow to www.example.com
Rule:		Deny to 0.0.0.0/0

Copy to Clipboard

Toggle word wrap

24.12. Modification d'un pare-feu de sortie pour un projet
Copier lien

En tant qu'administrateur de cluster, vous pouvez modifier les règles de trafic réseau d'un pare-feu de sortie existant.

24.12.1. Modification d'un objet EgressFirewall
Copier lien

En tant qu'administrateur de cluster, vous pouvez mettre à jour le pare-feu de sortie pour un projet.

Conditions préalables

Un cluster utilisant le plugin réseau OVN-Kubernetes.
Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster en tant qu'administrateur du cluster.

Procédure

Trouvez le nom de l'objet EgressFirewall pour le projet. Remplacez <project> par le nom du projet.
```
oc get -n <projet> egressfirewall
```
```
$ oc get -n <projet> egressfirewall
```
Copy to Clipboard Toggle word wrap
Facultatif : si vous n'avez pas enregistré une copie de l'objet EgressFirewall lors de la création du pare-feu de réseau de sortie, entrez la commande suivante pour créer une copie.
```
oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml
```
```
$ oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml
```
Copy to Clipboard Toggle word wrap
Remplacer <project> par le nom du projet. Remplacez <name> par le nom de l'objet. Remplacer <filename> par le nom du fichier dans lequel enregistrer le YAML.
Après avoir modifié les règles de stratégie, entrez la commande suivante pour remplacer l'objet EgressFirewall. Remplacez <filename> par le nom du fichier contenant l'objet EgressFirewall mis à jour.
```
oc replace -f <filename>.yaml
```
```
$ oc replace -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap

24.13. Suppression d'un pare-feu de sortie d'un projet
Copier lien

En tant qu'administrateur de cluster, vous pouvez supprimer un pare-feu de sortie d'un projet pour supprimer toutes les restrictions sur le trafic réseau du projet qui quitte le cluster OpenShift Container Platform.

24.13.1. Suppression d'un objet EgressFirewall
Copier lien

En tant qu'administrateur de cluster, vous pouvez supprimer un pare-feu de sortie d'un projet.

Conditions préalables

Un cluster utilisant le plugin réseau OVN-Kubernetes.
Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster en tant qu'administrateur du cluster.

Procédure

Trouvez le nom de l'objet EgressFirewall pour le projet. Remplacez <project> par le nom du projet.
```
oc get -n <projet> egressfirewall
```
```
$ oc get -n <projet> egressfirewall
```
Copy to Clipboard Toggle word wrap
Entrez la commande suivante pour supprimer l'objet EgressFirewall. Remplacez <project> par le nom du projet et <name> par le nom de l'objet.
```
oc delete -n <project> egressfirewall <name> $ oc delete -n <project> egressfirewall <name>
```
```
oc delete -n <project> egressfirewall <name> $ oc delete -n <project> egressfirewall <name>
```
Copy to Clipboard Toggle word wrap

24.14. Configuration d'une adresse IP de sortie
Copier lien

En tant qu'administrateur de cluster, vous pouvez configurer le plugin réseau OVN-Kubernetes Container Network Interface (CNI) pour attribuer une ou plusieurs adresses IP de sortie à un espace de noms, ou à des pods spécifiques dans un espace de noms.

24.14.1. Conception architecturale et mise en œuvre de l'adresse IP de sortie
Copier lien

La fonctionnalité d'adresse IP de sortie d'OpenShift Container Platform vous permet de vous assurer que le trafic d'un ou plusieurs pods dans un ou plusieurs espaces de noms a une adresse IP source cohérente pour les services en dehors du réseau du cluster.

Par exemple, vous pouvez avoir un pod qui interroge périodiquement une base de données hébergée sur un serveur extérieur à votre cluster. Pour appliquer les conditions d'accès au serveur, un dispositif de filtrage des paquets est configuré pour n'autoriser le trafic qu'à partir d'adresses IP spécifiques. Pour garantir la fiabilité de l'accès au serveur à partir de ce module spécifique, vous pouvez configurer une adresse IP de sortie spécifique pour le module qui envoie les requêtes au serveur.

Une adresse IP de sortie attribuée à un espace de noms est différente d'un routeur de sortie, qui est utilisé pour envoyer le trafic vers des destinations spécifiques.

Dans certaines configurations de cluster, les pods d'application et les pods de routeur d'entrée fonctionnent sur le même nœud. Si vous configurez une adresse IP de sortie pour un projet d'application dans ce scénario, l'adresse IP n'est pas utilisée lorsque vous envoyez une requête à une route à partir du projet d'application.

Important

Les adresses IP de sortie ne doivent pas être configurées dans les fichiers de configuration du réseau Linux, tels que ifcfg-eth0.

24.14.1.1. Soutien à la plate-forme
Copier lien

La prise en charge de la fonctionnalité d'adresse IP de sortie sur diverses plates-formes est résumée dans le tableau suivant :

Expand

Plate-forme	Soutenu
Métal nu	Oui
VMware vSphere	Oui
Plate-forme Red Hat OpenStack (RHOSP)	Oui
Amazon Web Services (AWS)	Oui
Google Cloud Platform (GCP)	Oui
Microsoft Azure	Oui

Important

L'attribution d'adresses IP de sortie aux nœuds du plan de contrôle avec la fonctionnalité EgressIP n'est pas prise en charge sur un cluster provisionné sur Amazon Web Services (AWS). (BZ#2039656)

24.14.1.2. Considérations relatives à la plateforme de cloud public
Copier lien

Pour les clusters provisionnés sur une infrastructure de cloud public, il existe une contrainte sur le nombre absolu d'adresses IP assignables par nœud. Le nombre maximal d'adresses IP assignables par nœud, ou le IP capacitypeut être décrit par la formule suivante :

IP capacity = public cloud default capacity - sum(current IP assignments)

IP capacity = public cloud default capacity - sum(current IP assignments)

Copy to Clipboard

Toggle word wrap

Bien que la fonction Egress IPs gère la capacité d'adresses IP par nœud, il est important de tenir compte de cette contrainte dans vos déploiements. Par exemple, pour un cluster installé sur une infrastructure bare-metal avec 8 nœuds, vous pouvez configurer 150 adresses IP de sortie. Toutefois, si un fournisseur de cloud public limite la capacité d'adresses IP à 10 adresses IP par nœud, le nombre total d'adresses IP assignables n'est que de 80. Pour obtenir la même capacité d'adresses IP dans cet exemple de fournisseur de cloud, il faudrait allouer 7 nœuds supplémentaires.

Pour confirmer la capacité IP et les sous-réseaux de n'importe quel nœud de votre environnement de cloud public, vous pouvez entrer la commande oc get node <node_name> -o yaml. L'annotation cloud.network.openshift.io/egress-ipconfig comprend des informations sur la capacité et les sous-réseaux du nœud.

La valeur d'annotation est un tableau contenant un objet unique dont les champs fournissent les informations suivantes pour l'interface réseau primaire :

interface: Spécifie l'ID de l'interface sur AWS et Azure et le nom de l'interface sur GCP.
ifaddr: Spécifie le masque de sous-réseau pour une ou les deux familles d'adresses IP.
capacity: Spécifie la capacité d'adresses IP pour le nœud. Sur AWS, la capacité d'adresses IP est fournie par famille d'adresses IP. Sur Azure et GCP, la capacité d'adresses IP comprend les adresses IPv4 et IPv6.

L'attachement et le détachement automatiques des adresses IP de sortie pour le trafic entre les nœuds sont disponibles. Cela permet au trafic de nombreux pods dans les espaces de noms d'avoir une adresse IP source cohérente vers des emplacements en dehors du cluster. Cela prend également en charge OpenShift SDN et OVN-Kubernetes, qui est le plugin de mise en réseau par défaut dans Red Hat OpenShift Networking dans OpenShift Container Platform 4.12.

Note

La fonctionnalité RHOSP egress IP address crée un port de réservation Neutron appelé egressip-<IP address>. En utilisant le même utilisateur RHOSP que celui utilisé pour l'installation du cluster OpenShift Container Platform, vous pouvez attribuer une adresse IP flottante à ce port de réservation afin de disposer d'une adresse SNAT prévisible pour le trafic de sortie. Lorsqu'une adresse IP de sortie sur un réseau RHOSP est déplacée d'un nœud à un autre, en raison d'un basculement de nœud, par exemple, le port de réservation Neutron est supprimé et recréé. Cela signifie que l'association IP flottante est perdue et que vous devez réassigner manuellement l'adresse IP flottante au nouveau port de réservation.

Note

Lorsqu'un administrateur de cluster RHOSP assigne une IP flottante au port de réservation, OpenShift Container Platform ne peut pas supprimer le port de réservation. L'objet CloudPrivateIPConfig ne peut pas effectuer d'opérations de suppression et de déplacement jusqu'à ce qu'un administrateur de cluster RHOSP désassigne l'IP flottante du port de réservation.

Les exemples suivants illustrent l'annotation des nœuds de plusieurs fournisseurs de nuages publics. Les annotations sont en retrait pour faciliter la lecture.

Exemple d'annotation cloud.network.openshift.io/egress-ipconfig sur AWS

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"eni-078d267045138e436",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ipv4":14,"ipv6":15}
  }
]

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"eni-078d267045138e436",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ipv4":14,"ipv6":15}
  }
]

Copy to Clipboard

Toggle word wrap

Exemple cloud.network.openshift.io/egress-ipconfig annotation sur GCP

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"nic0",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ip":14}
  }
]

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"nic0",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ip":14}
  }
]

Copy to Clipboard

Toggle word wrap

Les sections suivantes décrivent la capacité d'adresses IP pour les environnements de cloud public pris en charge, à utiliser dans votre calcul de capacité.

24.14.1.2.1. Limites de capacité des adresses IP d'Amazon Web Services (AWS)
Copier lien

Sur AWS, les contraintes d'attribution des adresses IP dépendent du type d'instance configuré. Pour plus d'informations, voir Adresses IP par interface réseau par type d'instance

24.14.1.2.2. Limites de capacité des adresses IP de Google Cloud Platform (GCP)
Copier lien

Sur le GCP, le modèle de réseau met en œuvre des adresses IP de nœuds supplémentaires par le biais de l'alias d'adresses IP, plutôt que par l'attribution d'adresses IP. Toutefois, la capacité d'adresses IP est directement liée à la capacité d'alias d'adresses IP.

Les limites de capacité suivantes s'appliquent à l'attribution de l'alias IP :

Le nombre maximum d'alias IP, tant IPv4 qu'IPv6, est de 10 par nœud.
Par VPC, le nombre maximum d'alias IP n'est pas spécifié, mais les tests d'évolutivité d'OpenShift Container Platform révèlent que le maximum est d'environ 15 000.

Pour plus d'informations, voir Quotas par instance et Aperçu des plages d'adresses IP alias.

24.14.1.2.3. Limites de capacité des adresses IP de Microsoft Azure
Copier lien

Sur Azure, les limites de capacité suivantes existent pour l'attribution d'adresses IP :

Par NIC, le nombre maximum d'adresses IP assignables, tant pour IPv4 que pour IPv6, est de 256.
Par réseau virtuel, le nombre maximum d'adresses IP attribuées ne peut dépasser 65 536.

Pour plus d'informations, voir Limites de mise en réseau.

24.14.1.3. Attribution d'IP de sortie aux pods
Copier lien

Pour attribuer une ou plusieurs IP de sortie à un espace de noms ou à des modules spécifiques d'un espace de noms, les conditions suivantes doivent être remplies :

Au moins un nœud de votre cluster doit avoir le label k8s.ovn.org/egress-assignable: "".
Il existe un objet EgressIP qui définit une ou plusieurs adresses IP de sortie à utiliser comme adresse IP source pour le trafic quittant le cluster à partir des pods d'un espace de noms.

Important

Si vous créez des objets EgressIP avant d'étiqueter les nœuds de votre cluster pour l'attribution d'IP de sortie, OpenShift Container Platform risque d'attribuer chaque adresse IP de sortie au premier nœud avec l'étiquette k8s.ovn.org/egress-assignable: "".

Pour garantir que les adresses IP de sortie sont largement réparties entre les nœuds du cluster, appliquez toujours l'étiquette aux nœuds destinés à héberger les adresses IP de sortie avant de créer des objets EgressIP.

24.14.1.4. Attribution des adresses IP de sortie aux nœuds
Copier lien

Lors de la création d'un objet EgressIP, les conditions suivantes s'appliquent aux nœuds portant l'étiquette k8s.ovn.org/egress-assignable: "":

Une adresse IP de sortie n'est jamais attribuée à plus d'un nœud à la fois.
Une adresse IP de sortie est répartie équitablement entre les nœuds disponibles qui peuvent héberger l'adresse IP de sortie.
Si le tableau spec.EgressIPs d'un objet EgressIP spécifie plus d'une adresse IP, les conditions suivantes s'appliquent :
- Aucun nœud n'hébergera jamais plus d'une des adresses IP spécifiées.
- Le trafic est réparti de manière à peu près égale entre les adresses IP spécifiées pour un espace de noms donné.
Si un nœud devient indisponible, les adresses IP de sortie qui lui sont attribuées sont automatiquement réattribuées, sous réserve des conditions décrites précédemment.

Lorsqu'un pod correspond au sélecteur de plusieurs objets EgressIP, il n'est pas garanti que l'adresse IP de sortie spécifiée dans les objets EgressIP soit attribuée en tant qu'adresse IP de sortie pour le pod.

En outre, si un objet EgressIP spécifie plusieurs adresses IP de sortie, il n'y a aucune garantie quant à l'adresse IP de sortie qui sera utilisée. Par exemple, si un pod correspond à un sélecteur pour un objet EgressIP avec deux adresses IP de sortie, 10.10.20.1 et 10.10.20.2, l'une ou l'autre peut être utilisée pour chaque connexion TCP ou conversation UDP.

24.14.1.5. Schéma architectural d'une configuration d'adresses IP de sortie
Copier lien

Le diagramme suivant illustre une configuration d'adresses IP de sortie. Il décrit quatre pods dans deux espaces de noms différents fonctionnant sur trois nœuds d'un cluster. Les nœuds se voient attribuer des adresses IP à partir du bloc CIDR 192.168.126.0/18 sur le réseau hôte.

Le nœud 1 et le nœud 3 sont tous deux étiquetés avec k8s.ovn.org/egress-assignable: "" et sont donc disponibles pour l'attribution d'adresses IP de sortie.

Les lignes en pointillé du diagramme représentent le flux de trafic provenant de pod1, pod2 et pod3 et transitant par le réseau de pods pour sortir de la grappe à partir du nœud 1 et du nœud 3. Lorsqu'un service externe reçoit du trafic de l'un des pods sélectionnés par l'objet EgressIP, l'adresse IP source est soit 192.168.126.10, soit 192.168.126.102. Le trafic est réparti de manière à peu près égale entre ces deux nœuds.

Les ressources suivantes du diagramme sont illustrées en détail :

Namespace objets

Les espaces de noms sont définis dans le manifeste suivant :

Objets de l'espace de noms

apiVersion: v1
kind: Namespace
metadata:
  name: namespace1
  labels:
    env: prod
---
apiVersion: v1
kind: Namespace
metadata:
  name: namespace2
  labels:
    env: prod

apiVersion: v1
kind: Namespace
metadata:
  name: namespace1
  labels:
    env: prod
---
apiVersion: v1
kind: Namespace
metadata:
  name: namespace2
  labels:
    env: prod

Copy to Clipboard

Toggle word wrap

EgressIP objet

L'objet EgressIP suivant décrit une configuration qui sélectionne tous les modules dans n'importe quel espace de noms avec l'étiquette env définie sur prod. Les adresses IP de sortie pour les modules sélectionnés sont 192.168.126.10 et 192.168.126.102.

EgressIP objet

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egressips-prod
spec:
  egressIPs:
  - 192.168.126.10
  - 192.168.126.102
  namespaceSelector:
    matchLabels:
      env: prod
status:
  items:
  - node: node1
    egressIP: 192.168.126.10
  - node: node3
    egressIP: 192.168.126.102

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egressips-prod
spec:
  egressIPs:
  - 192.168.126.10
  - 192.168.126.102
  namespaceSelector:
    matchLabels:
      env: prod
status:
  items:
  - node: node1
    egressIP: 192.168.126.10
  - node: node3
    egressIP: 192.168.126.102

Copy to Clipboard

Toggle word wrap

Pour la configuration de l'exemple précédent, OpenShift Container Platform attribue les deux adresses IP egress aux nœuds disponibles. Le champ status indique si et où les adresses IP de sortie sont attribuées.

24.14.2. Objet EgressIP
Copier lien

Le fichier YAML suivant décrit l'API de l'objet EgressIP. La portée de l'objet est à l'échelle du cluster ; il n'est pas créé dans un espace de noms.

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: <name> 
spec:
  egressIPs: 
  - <ip_address>
  namespaceSelector: 
    ...
  podSelector: 
    ...

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: <name>

1


spec:
  egressIPs:

2


  - <ip_address>
  namespaceSelector:

3


    ...
  podSelector:

4

...

Copy to Clipboard

Toggle word wrap

1: Nom de l'objet EgressIPs.
2: Un tableau d'une ou plusieurs adresses IP.
3: Un ou plusieurs sélecteurs pour les espaces de noms auxquels associer les adresses IP de sortie.
4: Facultatif : Un ou plusieurs sélecteurs de modules dans les espaces de noms spécifiés auxquels associer les adresses IP de sortie. L'application de ces sélecteurs permet de sélectionner un sous-ensemble de modules dans un espace de noms.

Le fichier YAML suivant décrit la strophe du sélecteur d'espace de noms :

Strophe de sélecteur d'espace de noms

namespaceSelector: 
  matchLabels:
    <label_name>: <label_value>

namespaceSelector:

1


  matchLabels:
    <label_name>: <label_value>

Copy to Clipboard

Toggle word wrap

1: Une ou plusieurs règles de correspondance pour les espaces de noms. Si plusieurs règles de correspondance sont fournies, tous les espaces de noms correspondants sont sélectionnés.

Le YAML suivant décrit la strophe optionnelle pour le sélecteur de pods :

Stance de sélection de pods

podSelector: 
  matchLabels:
    <label_name>: <label_value>

podSelector:

1


  matchLabels:
    <label_name>: <label_value>

Copy to Clipboard

Toggle word wrap

1: Facultatif : Une ou plusieurs règles de correspondance pour les pods dans les espaces de noms qui correspondent aux règles namespaceSelector spécifiées. Si cette option est spécifiée, seuls les pods qui correspondent aux règles sont sélectionnés. Les autres pods de l'espace de noms ne sont pas sélectionnés.

Dans l'exemple suivant, l'objet EgressIP associe les adresses IP de sortie 192.168.126.11 et 192.168.126.102 aux pods dont l'étiquette app est définie sur web et qui se trouvent dans les espaces de noms dont l'étiquette env est définie sur prod:

Exemple d'objet EgressIP

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egress-group1
spec:
  egressIPs:
  - 192.168.126.11
  - 192.168.126.102
  podSelector:
    matchLabels:
      app: web
  namespaceSelector:
    matchLabels:
      env: prod

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egress-group1
spec:
  egressIPs:
  - 192.168.126.11
  - 192.168.126.102
  podSelector:
    matchLabels:
      app: web
  namespaceSelector:
    matchLabels:
      env: prod

Copy to Clipboard

Toggle word wrap

Dans l'exemple suivant, l'objet EgressIP associe les adresses IP de sortie 192.168.127.30 et 192.168.127.40 à tous les pods dont l'étiquette environment n'est pas réglée sur development:

Exemple d'objet EgressIP

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egress-group2
spec:
  egressIPs:
  - 192.168.127.30
  - 192.168.127.40
  namespaceSelector:
    matchExpressions:
    - key: environment
      operator: NotIn
      values:
      - development

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egress-group2
spec:
  egressIPs:
  - 192.168.127.30
  - 192.168.127.40
  namespaceSelector:
    matchExpressions:
    - key: environment
      operator: NotIn
      values:
      - development

Copy to Clipboard

Toggle word wrap

24.14.3. Étiquetage d'un nœud pour l'hébergement des adresses IP de sortie
Copier lien

Vous pouvez appliquer le label k8s.ovn.org/egress-assignable="" à un nœud de votre cluster afin qu'OpenShift Container Platform puisse attribuer une ou plusieurs adresses IP de sortie au nœud.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous au cluster en tant qu'administrateur du cluster.

Procédure

Pour étiqueter un nœud afin qu'il puisse héberger une ou plusieurs adresses IP de sortie, entrez la commande suivante :
```
oc label nodes <node_name> k8s.ovn.org/egress-assignable=""
```
```
$ oc label nodes <node_name> k8s.ovn.org/egress-assignable="" 
```
1
Copy to Clipboard Toggle word wrap
1
Le nom du nœud à étiqueter.
Astuce
Vous pouvez également appliquer le langage YAML suivant pour ajouter l'étiquette à un nœud :
apiVersion: v1 kind: Node metadata: labels: k8s.ovn.org/egress-assignable: "" name: <node_name>
Copy to Clipboard Toggle word wrap

24.14.4. Prochaines étapes
Copier lien

Attribution d'IP de sortie

24.15. Attribution d'une adresse IP de sortie
Copier lien

En tant qu'administrateur de cluster, vous pouvez attribuer une adresse IP de sortie au trafic quittant le cluster à partir d'un espace de noms ou de pods spécifiques dans un espace de noms.

24.15.1. Attribution d'une adresse IP de sortie à un espace de noms
Copier lien

Vous pouvez attribuer une ou plusieurs adresses IP de sortie à un espace de noms ou à des modules spécifiques d'un espace de noms.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous au cluster en tant qu'administrateur du cluster.
Configurez au moins un nœud pour qu'il héberge une adresse IP de sortie.

Procédure

Créer un objet EgressIP:

Créer un fichier <egressips_name>.yaml où <egressips_name> est le nom de l'objet.

Dans le fichier que vous avez créé, définissez un objet EgressIP, comme dans l'exemple suivant :

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egress-project1
spec:
  egressIPs:
  - 192.168.127.10
  - 192.168.127.11
  namespaceSelector:
    matchLabels:
      env: qa

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egress-project1
spec:
  egressIPs:
  - 192.168.127.10
  - 192.168.127.11
  namespaceSelector:
    matchLabels:
      env: qa

Copy to Clipboard

Toggle word wrap

Pour créer l'objet, entrez la commande suivante.
```
oc apply -f <egressips_name>.yaml 
```
```
oc apply -f <egressips_name>.yaml 
```
1
Copy to Clipboard Toggle word wrap
1
Remplacer <egressips_name> par le nom de l'objet.
Exemple de sortie
```
egressips.k8s.ovn.org/<egressips_name> créé
```
```
egressips.k8s.ovn.org/<egressips_name> créé
```
Copy to Clipboard Toggle word wrap
Facultatif : Enregistrez le fichier <egressips_name>.yaml pour pouvoir le modifier ultérieurement.
Ajoutez des étiquettes à l'espace de noms qui nécessite des adresses IP de sortie. Pour ajouter une étiquette à l'espace de noms d'un objet EgressIP défini à l'étape 1, exécutez la commande suivante :
```
oc label ns <namespace> env=qa 
```
```
oc label ns <namespace> env=qa 
```
1
Copy to Clipboard Toggle word wrap
1
Remplacer <namespace> par l'espace de noms qui nécessite des adresses IP de sortie.

24.16. Considérations relatives à l'utilisation d'un module de routeur de sortie
Copier lien

24.16.1. À propos d'un pod de routeur de sortie
Copier lien

Le pod routeur egress d'OpenShift Container Platform redirige le trafic vers un serveur distant spécifié à partir d'une adresse IP source privée qui n'est pas utilisée à d'autres fins. Un pod routeur egress peut envoyer du trafic réseau à des serveurs qui sont configurés pour n'autoriser l'accès qu'à partir d'adresses IP spécifiques.

Note

Le module de routeur de sortie n'est pas destiné à chaque connexion sortante. La création d'un grand nombre de modules de routeur de sortie peut dépasser les limites de votre matériel réseau. Par exemple, la création d'un module de routeur de sortie pour chaque projet ou application pourrait dépasser le nombre d'adresses MAC locales que l'interface réseau peut gérer avant de revenir au filtrage des adresses MAC dans le logiciel.

Important

L'image du routeur de sortie n'est pas compatible avec Amazon AWS, Azure Cloud ou toute autre plateforme cloud qui ne prend pas en charge les manipulations de la couche 2 en raison de leur incompatibilité avec le trafic macvlan.

24.16.1.1. Modes du routeur de sortie
Copier lien

En redirect modeun pod routeur de sortie configure les règles iptables pour rediriger le trafic de sa propre adresse IP vers une ou plusieurs adresses IP de destination. Les modules clients qui doivent utiliser l'adresse IP source réservée doivent être modifiés pour se connecter au routeur de sortie plutôt que de se connecter directement à l'adresse IP de destination.

Note

Le plugin CNI egress router supporte uniquement le mode redirect. Il s'agit d'une différence avec l'implémentation du routeur egress que vous pouvez déployer avec OpenShift SDN. Contrairement au routeur de sortie pour OpenShift SDN, le plugin CNI du routeur de sortie ne prend pas en charge le mode proxy HTTP ou le mode proxy DNS.

24.16.1.2. Mise en œuvre d'un pod de routeur de sortie
Copier lien

L'implémentation du routeur de sortie utilise le plugin Container Network Interface (CNI) du routeur de sortie. Le plugin ajoute une interface réseau secondaire à un pod.

Un routeur de sortie est un module qui possède deux interfaces réseau. Par exemple, le module peut avoir des interfaces réseau eth0 et net1. L'interface eth0 se trouve sur le réseau du cluster et le pod continue à l'utiliser pour le trafic réseau ordinaire lié au cluster. L'interface net1 est sur un réseau secondaire et possède une adresse IP et une passerelle pour ce réseau. D'autres pods dans le cluster OpenShift Container Platform peuvent accéder au service de routeur de sortie et le service permet aux pods d'accéder à des services externes. Le routeur egress agit comme un pont entre les pods et un système externe.

Le trafic qui quitte le routeur de sortie passe par un nœud, mais les paquets ont l'adresse MAC de l'interface net1 du pod du routeur de sortie.

Lorsque vous ajoutez une ressource personnalisée de routeur de sortie, l'opérateur de réseau de cluster crée les objets suivants :

La définition de l'attachement réseau pour l'interface réseau secondaire net1 du pod.
Un déploiement pour le routeur de sortie.

Si vous supprimez une ressource personnalisée de routeur de sortie, l'opérateur supprime les deux objets de la liste précédente qui sont associés au routeur de sortie.

24.16.1.3. Considérations relatives au déploiement
Copier lien

Un pod routeur de sortie ajoute une adresse IP et une adresse MAC supplémentaires à l'interface réseau principale du nœud. Par conséquent, il se peut que vous deviez configurer votre hyperviseur ou votre fournisseur de cloud pour autoriser l'adresse supplémentaire.

Plate-forme Red Hat OpenStack (RHOSP)

Si vous déployez OpenShift Container Platform sur RHOSP, vous devez autoriser le trafic à partir des adresses IP et MAC du pod routeur egress sur votre environnement OpenStack. Si vous n'autorisez pas le trafic, la communication échouera:

openstack port set --allowed-address \
  ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>

$ openstack port set --allowed-address \
  ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>

Copy to Clipboard

Toggle word wrap

Red Hat Virtualization (RHV)

Si vous utilisez RHV, vous devez sélectionner No Network Filter pour le contrôleur d'interface réseau virtuel (vNIC).

VMware vSphere

Si vous utilisez VMware vSphere, consultez la documentation VMware pour sécuriser les commutateurs standard vSphere. Affichez et modifiez les paramètres par défaut de VMware vSphere en sélectionnant le commutateur virtuel de l'hôte dans le client Web vSphere.

En particulier, assurez-vous que les éléments suivants sont activés :

24.16.1.4. Configuration du basculement
Copier lien

Pour éviter les temps d'arrêt, l'opérateur du réseau de cluster déploie le module de routeur de sortie en tant que ressource de déploiement. Le nom du déploiement est egress-router-cni-deployment. Le module correspondant au déploiement a une étiquette app=egress-router-cni.

Pour créer un nouveau service pour le déploiement, utilisez la commande oc expose deployment/egress-router-cni-deployment --port <port_number> ou créez un fichier comme dans l'exemple suivant :

apiVersion: v1
kind: Service
metadata:
  name: app-egress
spec:
  ports:
  - name: tcp-8080
    protocol: TCP
    port: 8080
  - name: tcp-8443
    protocol: TCP
    port: 8443
  - name: udp-80
    protocol: UDP
    port: 80
  type: ClusterIP
  selector:
    app: egress-router-cni

apiVersion: v1
kind: Service
metadata:
  name: app-egress
spec:
  ports:
  - name: tcp-8080
    protocol: TCP
    port: 8080
  - name: tcp-8443
    protocol: TCP
    port: 8443
  - name: udp-80
    protocol: UDP
    port: 80
  type: ClusterIP
  selector:
    app: egress-router-cni

Copy to Clipboard

Toggle word wrap

24.17. Déploiement d'un pod routeur de sortie en mode redirection
Copier lien

En tant qu'administrateur de cluster, vous pouvez déployer un pod routeur de sortie pour rediriger le trafic vers des adresses IP de destination spécifiées à partir d'une adresse IP source réservée.

L'implémentation du routeur de sortie utilise le plugin CNI (Container Network Interface) du routeur de sortie.

24.17.1. Ressource personnalisée du routeur de sortie
Copier lien

Définir la configuration d'un module de routeur de sortie dans une ressource personnalisée de routeur de sortie. Le fichier YAML suivant décrit les champs de configuration d'un routeur de sortie en mode redirection :

apiVersion: network.operator.openshift.io/v1
kind: EgressRouter
metadata:
  name: <egress_router_name>
  namespace: <namespace>  <.>
spec:
  addresses: [  <.>
    {
      ip: "<egress_router>",  <.>
      gateway: "<egress_gateway>"  <.>
    }
  ]
  mode: Redirect
  redirect: {
    redirectRules: [  <.>
      {
        destinationIP: "<egress_destination>",
        port: <egress_router_port>,
        targetPort: <target_port>,  <.>
        protocol: <network_protocol>  <.>
      },
      ...
    ],
    fallbackIP: "<egress_destination>" <.>
  }

apiVersion: network.operator.openshift.io/v1
kind: EgressRouter
metadata:
  name: <egress_router_name>
  namespace: <namespace>  <.>
spec:
  addresses: [  <.>
    {
      ip: "<egress_router>",  <.>
      gateway: "<egress_gateway>"  <.>
    }
  ]
  mode: Redirect
  redirect: {
    redirectRules: [  <.>
      {
        destinationIP: "<egress_destination>",
        port: <egress_router_port>,
        targetPort: <target_port>,  <.>
        protocol: <network_protocol>  <.>
      },
      ...
    ],
    fallbackIP: "<egress_destination>" <.>
  }

Copy to Clipboard

Toggle word wrap

<.> Facultatif : Le champ namespace indique l'espace de noms dans lequel le routeur de sortie doit être créé. Si vous ne spécifiez pas de valeur dans le fichier ou sur la ligne de commande, l'espace de noms default est utilisé.

<.> Le champ addresses spécifie les adresses IP à configurer sur l'interface réseau secondaire.

<.> Le champ ip spécifie l'adresse IP source réservée et le masque de réseau du réseau physique sur lequel se trouve le nœud à utiliser avec le pod du routeur de sortie. Utilisez la notation CIDR pour spécifier l'adresse IP et le masque de réseau.

<.> Le champ gateway indique l'adresse IP de la passerelle réseau.

<.> Facultatif : Le champ redirectRules spécifie une combinaison d'adresse IP de destination de sortie, de port de routeur de sortie et de protocole. Les connexions entrantes au routeur de sortie sur le port et le protocole spécifiés sont acheminées vers l'adresse IP de destination.

<.> Facultatif : Le champ targetPort indique le port réseau de l'adresse IP de destination. Si ce champ n'est pas spécifié, le trafic est acheminé vers le même port réseau que celui par lequel il est arrivé.

<.> Le champ protocol prend en charge TCP, UDP ou SCTP.

<.> Facultatif : Le champ fallbackIP spécifie une adresse IP de destination. Si vous ne spécifiez aucune règle de redirection, le routeur de sortie envoie tout le trafic à cette adresse IP de repli. Si vous spécifiez des règles de redirection, toutes les connexions aux ports réseau qui ne sont pas définies dans les règles sont envoyées par le routeur de sortie à cette adresse IP de repli. Si vous ne spécifiez pas ce champ, le routeur de sortie rejette les connexions aux ports réseau qui ne sont pas définis dans les règles.

Exemple de spécification d'un routeur de sortie

apiVersion: network.operator.openshift.io/v1
kind: EgressRouter
metadata:
  name: egress-router-redirect
spec:
  networkInterface: {
    macvlan: {
      mode: "Bridge"
    }
  }
  addresses: [
    {
      ip: "192.168.12.99/24",
      gateway: "192.168.12.1"
    }
  ]
  mode: Redirect
  redirect: {
    redirectRules: [
      {
        destinationIP: "10.0.0.99",
        port: 80,
        protocol: UDP
      },
      {
        destinationIP: "203.0.113.26",
        port: 8080,
        targetPort: 80,
        protocol: TCP
      },
      {
        destinationIP: "203.0.113.27",
        port: 8443,
        targetPort: 443,
        protocol: TCP
      }
    ]
  }

apiVersion: network.operator.openshift.io/v1
kind: EgressRouter
metadata:
  name: egress-router-redirect
spec:
  networkInterface: {
    macvlan: {
      mode: "Bridge"
    }
  }
  addresses: [
    {
      ip: "192.168.12.99/24",
      gateway: "192.168.12.1"
    }
  ]
  mode: Redirect
  redirect: {
    redirectRules: [
      {
        destinationIP: "10.0.0.99",
        port: 80,
        protocol: UDP
      },
      {
        destinationIP: "203.0.113.26",
        port: 8080,
        targetPort: 80,
        protocol: TCP
      },
      {
        destinationIP: "203.0.113.27",
        port: 8443,
        targetPort: 443,
        protocol: TCP
      }
    ]
  }

Copy to Clipboard

Toggle word wrap

24.17.2. Déploiement d'un routeur de sortie en mode redirection
Copier lien

Vous pouvez déployer un routeur de sortie pour rediriger le trafic de sa propre adresse IP source réservée vers une ou plusieurs adresses IP de destination.

Après l'ajout d'un routeur de sortie, les modules clients qui doivent utiliser l'adresse IP source réservée doivent être modifiés pour se connecter au routeur de sortie plutôt que de se connecter directement à l'adresse IP de destination.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créer une définition de routeur de sortie.
Pour que les autres modules puissent trouver l'adresse IP du module de routeur de sortie, créez un service qui utilise le routeur de sortie, comme dans l'exemple suivant :
```
apiVersion: v1
kind: Service
metadata:
  name: egress-1
spec:
  ports:
  - name: web-app
    protocol: TCP
    port: 8080
  type: ClusterIP
  selector:
    app: egress-router-cni <.>
```
```
apiVersion: v1
kind: Service
metadata:
  name: egress-1
spec:
  ports:
  - name: web-app
    protocol: TCP
    port: 8080
  type: ClusterIP
  selector:
    app: egress-router-cni <.>
```
Copy to Clipboard Toggle word wrap
<.> Spécifier l'étiquette pour le routeur de sortie. La valeur indiquée est ajoutée par l'opérateur du réseau de cluster et n'est pas configurable.
Après avoir créé le service, vos pods peuvent se connecter au service. Le pod routeur de sortie redirige le trafic vers le port correspondant de l'adresse IP de destination. Les connexions proviennent de l'adresse IP source réservée.

Vérification

Pour vérifier que l'opérateur du réseau de clusters a démarré le routeur de sortie, suivez la procédure suivante :

Affichez la définition de l'attachement au réseau que l'opérateur a créée pour le routeur de sortie :
```
oc get network-attachment-definition egress-router-cni-nad
```
```
$ oc get network-attachment-definition egress-router-cni-nad
```
Copy to Clipboard Toggle word wrap
Le nom de la définition de l'attachement réseau n'est pas configurable.
Exemple de sortie
```
NAME                    AGE
egress-router-cni-nad   18m
```
```
NAME                    AGE
egress-router-cni-nad   18m
```
Copy to Clipboard Toggle word wrap

Affichez le déploiement du module de routeur de sortie :

oc get deployment egress-router-cni-deployment

$ oc get deployment egress-router-cni-deployment

Copy to Clipboard

Toggle word wrap

Le nom du déploiement n'est pas configurable.

Exemple de sortie

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
egress-router-cni-deployment   1/1     1            1           18m

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
egress-router-cni-deployment   1/1     1            1           18m

Copy to Clipboard

Toggle word wrap

Affichez l'état du pod du routeur de sortie :

oc get pods -l app=egress-router-cni

$ oc get pods -l app=egress-router-cni

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                            READY   STATUS    RESTARTS   AGE
egress-router-cni-deployment-575465c75c-qkq6m   1/1     Running   0          18m

NAME                                            READY   STATUS    RESTARTS   AGE
egress-router-cni-deployment-575465c75c-qkq6m   1/1     Running   0          18m

Copy to Clipboard

Toggle word wrap

Affichez les journaux et la table de routage pour le pod du routeur de sortie.

Obtenir le nom du nœud pour le pod du routeur de sortie :

POD_NODENAME=$(oc get pod -l app=egress-router-cni -o jsonpath="{.items[0].spec.nodeName}")

$ POD_NODENAME=$(oc get pod -l app=egress-router-cni -o jsonpath="{.items[0].spec.nodeName}")

Copy to Clipboard

Toggle word wrap

Entrez dans une session de débogage sur le nœud cible. Cette étape instancie un pod de débogage appelé <node_name>-debug:
```
oc debug node/$POD_NODENAME
```
```
$ oc debug node/$POD_NODENAME
```
Copy to Clipboard Toggle word wrap
Définissez /host comme répertoire racine dans le shell de débogage. Le pod de débogage monte le système de fichiers racine de l'hôte dans /host au sein du pod. En changeant le répertoire racine en /host, vous pouvez exécuter des binaires à partir des chemins d'exécution de l'hôte :
```
chroot /host
```
```
# chroot /host
```
Copy to Clipboard Toggle word wrap

Dans la console de l'environnement chroot, affichez les journaux du routeur de sortie :

cat /tmp/egress-router-log

# cat /tmp/egress-router-log

Copy to Clipboard

Toggle word wrap

Exemple de sortie

2021-04-26T12:27:20Z [debug] Called CNI ADD
2021-04-26T12:27:20Z [debug] Gateway: 192.168.12.1
2021-04-26T12:27:20Z [debug] IP Source Addresses: [192.168.12.99/24]
2021-04-26T12:27:20Z [debug] IP Destinations: [80 UDP 10.0.0.99/30 8080 TCP 203.0.113.26/30 80 8443 TCP 203.0.113.27/30 443]
2021-04-26T12:27:20Z [debug] Created macvlan interface
2021-04-26T12:27:20Z [debug] Renamed macvlan to "net1"
2021-04-26T12:27:20Z [debug] Adding route to gateway 192.168.12.1 on macvlan interface
2021-04-26T12:27:20Z [debug] deleted default route {Ifindex: 3 Dst: <nil> Src: <nil> Gw: 10.128.10.1 Flags: [] Table: 254}
2021-04-26T12:27:20Z [debug] Added new default route with gateway 192.168.12.1
2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p UDP --dport 80 -j DNAT --to-destination 10.0.0.99
2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p TCP --dport 8080 -j DNAT --to-destination 203.0.113.26:80
2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p TCP --dport 8443 -j DNAT --to-destination 203.0.113.27:443
2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat -o net1 -j SNAT --to-source 192.168.12.99

2021-04-26T12:27:20Z [debug] Called CNI ADD
2021-04-26T12:27:20Z [debug] Gateway: 192.168.12.1
2021-04-26T12:27:20Z [debug] IP Source Addresses: [192.168.12.99/24]
2021-04-26T12:27:20Z [debug] IP Destinations: [80 UDP 10.0.0.99/30 8080 TCP 203.0.113.26/30 80 8443 TCP 203.0.113.27/30 443]
2021-04-26T12:27:20Z [debug] Created macvlan interface
2021-04-26T12:27:20Z [debug] Renamed macvlan to "net1"
2021-04-26T12:27:20Z [debug] Adding route to gateway 192.168.12.1 on macvlan interface
2021-04-26T12:27:20Z [debug] deleted default route {Ifindex: 3 Dst: <nil> Src: <nil> Gw: 10.128.10.1 Flags: [] Table: 254}
2021-04-26T12:27:20Z [debug] Added new default route with gateway 192.168.12.1
2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p UDP --dport 80 -j DNAT --to-destination 10.0.0.99
2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p TCP --dport 8080 -j DNAT --to-destination 203.0.113.26:80
2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p TCP --dport 8443 -j DNAT --to-destination 203.0.113.27:443
2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat -o net1 -j SNAT --to-source 192.168.12.99

Copy to Clipboard

Toggle word wrap

L'emplacement du fichier de journalisation et le niveau de journalisation ne sont pas configurables lorsque vous démarrez le routeur de sortie en créant un objet EgressRouter comme décrit dans cette procédure.

Dans la console de l'environnement chroot, récupérez l'identifiant du conteneur :
```
crictl ps --name egress-router-cni-pod | awk '{print $1}'
```
```
# crictl ps --name egress-router-cni-pod | awk '{print $1}'
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
CONTAINER
bac9fae69ddb6
```
```
CONTAINER
bac9fae69ddb6
```
Copy to Clipboard Toggle word wrap
Déterminer l'ID du processus du conteneur. Dans cet exemple, l'ID du conteneur est bac9fae69ddb6:
```
crictl inspect -o yaml bac9fae69ddb6 | grep 'pid:' | awk '{print $2}'
```
```
# crictl inspect -o yaml bac9fae69ddb6 | grep 'pid:' | awk '{print $2}'
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
68857
```
```
68857
```
Copy to Clipboard Toggle word wrap
Entrez l'espace de noms du réseau du conteneur :
```
nsenter -n -t 68857
```
```
# nsenter -n -t 68857
```
Copy to Clipboard Toggle word wrap
Afficher la table de routage :
```
ip route
```
```
# ip route
```
Copy to Clipboard Toggle word wrap
Dans l'exemple suivant, l'interface réseau net1 est la route par défaut. Le trafic pour le réseau cluster utilise l'interface réseau eth0. Le trafic destiné au réseau 192.168.12.0/24 utilise l'interface réseau net1 et provient de l'adresse IP source réservée 192.168.12.99. Le pod achemine tout le reste du trafic vers la passerelle à l'adresse IP 192.168.12.1. Le routage pour le réseau de service n'est pas montré.
Exemple de sortie
```
default via 192.168.12.1 dev net1
10.128.10.0/23 dev eth0 proto kernel scope link src 10.128.10.18
192.168.12.0/24 dev net1 proto kernel scope link src 192.168.12.99
192.168.12.1 dev net1
```
```
default via 192.168.12.1 dev net1
10.128.10.0/23 dev eth0 proto kernel scope link src 10.128.10.18
192.168.12.0/24 dev net1 proto kernel scope link src 192.168.12.99
192.168.12.1 dev net1
```
Copy to Clipboard Toggle word wrap

24.18. Activation de la multidiffusion pour un projet
Copier lien

24.18.1. À propos de la multidiffusion
Copier lien

Avec la multidiffusion IP, les données sont diffusées simultanément à de nombreuses adresses IP.

Important

À l'heure actuelle, le multicast est utilisé de préférence pour la coordination ou la découverte de services à faible bande passante et non comme une solution à large bande passante.

Le trafic multicast entre les pods d'OpenShift Container Platform est désactivé par défaut. Si vous utilisez le plugin réseau OVN-Kubernetes, vous pouvez activer le multicast par projet.

24.18.2. Activation de la multidiffusion entre les pods
Copier lien

Vous pouvez activer le multicast entre les pods de votre projet.

Conditions préalables

Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster avec un utilisateur ayant le rôle cluster-admin.

Procédure

Exécutez la commande suivante pour activer la multidiffusion pour un projet. Remplacez <namespace> par l'espace de noms du projet pour lequel vous souhaitez activer la multidiffusion.

oc annotate namespace <namespace> \
    k8s.ovn.org/multicast-enabled=true

$ oc annotate namespace <namespace> \
    k8s.ovn.org/multicast-enabled=true

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le YAML suivant pour ajouter l'annotation :

apiVersion: v1
kind: Namespace
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/multicast-enabled: "true"

apiVersion: v1
kind: Namespace
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/multicast-enabled: "true"

Copy to Clipboard

Toggle word wrap

Vérification

Pour vérifier que la multidiffusion est activée pour un projet, suivez la procédure suivante :

Remplacez votre projet actuel par le projet pour lequel vous avez activé la multidiffusion. Remplacez <project> par le nom du projet.
```
oc project <projet>
```
```
$ oc project <projet>
```
Copy to Clipboard Toggle word wrap

Créez un pod qui servira de récepteur multicast :

cat <<EOF| oc create -f -
apiVersion: v1
kind: Pod
metadata:
  name: mlistener
  labels:
    app: multicast-verify
spec:
  containers:
    - name: mlistener
      image: registry.access.redhat.com/ubi8
      command: ["/bin/sh", "-c"]
      args:
        ["dnf -y install socat hostname && sleep inf"]
      ports:
        - containerPort: 30102
          name: mlistener
          protocol: UDP
EOF

$ cat <<EOF| oc create -f -
apiVersion: v1
kind: Pod
metadata:
  name: mlistener
  labels:
    app: multicast-verify
spec:
  containers:
    - name: mlistener
      image: registry.access.redhat.com/ubi8
      command: ["/bin/sh", "-c"]
      args:
        ["dnf -y install socat hostname && sleep inf"]
      ports:
        - containerPort: 30102
          name: mlistener
          protocol: UDP
EOF

Copy to Clipboard

Toggle word wrap

Créez un pod qui servira d'émetteur multicast :

cat <<EOF| oc create -f -
apiVersion: v1
kind: Pod
metadata:
  name: msender
  labels:
    app: multicast-verify
spec:
  containers:
    - name: msender
      image: registry.access.redhat.com/ubi8
      command: ["/bin/sh", "-c"]
      args:
        ["dnf -y install socat && sleep inf"]
EOF

$ cat <<EOF| oc create -f -
apiVersion: v1
kind: Pod
metadata:
  name: msender
  labels:
    app: multicast-verify
spec:
  containers:
    - name: msender
      image: registry.access.redhat.com/ubi8
      command: ["/bin/sh", "-c"]
      args:
        ["dnf -y install socat && sleep inf"]
EOF

Copy to Clipboard

Toggle word wrap

Dans une nouvelle fenêtre ou un nouvel onglet de terminal, démarrez l'auditeur de multidiffusion.

Obtenir l'adresse IP du pod :

POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')

$ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')

Copy to Clipboard

Toggle word wrap

Démarrez l'auditeur de multidiffusion en entrant la commande suivante :

oc exec mlistener -i -t -- \
    socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname

$ oc exec mlistener -i -t -- \
    socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname

Copy to Clipboard

Toggle word wrap

Démarrer l'émetteur de multidiffusion.

Obtenir la plage d'adresses IP du réseau de pods :

CIDR=$(oc get Network.config.openshift.io cluster \
    -o jsonpath='{.status.clusterNetwork[0].cidr}')

$ CIDR=$(oc get Network.config.openshift.io cluster \
    -o jsonpath='{.status.clusterNetwork[0].cidr}')

Copy to Clipboard

Toggle word wrap

Pour envoyer un message multicast, entrez la commande suivante :

oc exec msender -i -t -- \
    /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"

$ oc exec msender -i -t -- \
    /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"

Copy to Clipboard

Toggle word wrap

Si la multidiffusion fonctionne, la commande précédente renvoie le résultat suivant :

mlistener

mlistener

Copy to Clipboard

Toggle word wrap

24.19. Désactiver la multidiffusion pour un projet
Copier lien

24.19.1. Désactivation de la multidiffusion entre les pods
Copier lien

Vous pouvez désactiver le multicast entre les pods de votre projet.

Conditions préalables

Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster avec un utilisateur ayant le rôle cluster-admin.

Procédure

Désactivez la multidiffusion en exécutant la commande suivante :

oc annotate namespace <namespace> \
    k8s.ovn.org/multicast-enabled-

$ oc annotate namespace <namespace> \

1


    k8s.ovn.org/multicast-enabled-

Copy to Clipboard

Toggle word wrap

1: Le site namespace du projet pour lequel vous souhaitez désactiver la multidiffusion.

Astuce

Vous pouvez également appliquer le YAML suivant pour supprimer l'annotation :

apiVersion: v1
kind: Namespace
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/multicast-enabled: null

apiVersion: v1
kind: Namespace
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/multicast-enabled: null

Copy to Clipboard

Toggle word wrap

24.20. Suivi des flux du réseau
Copier lien

En tant qu'administrateur de cluster, vous pouvez collecter des informations sur les flux de réseaux de pods de votre cluster pour vous aider dans les domaines suivants :

Surveiller le trafic d'entrée et de sortie sur le réseau de pods.
Dépanner les problèmes de performance.
Recueillir des données pour la planification des capacités et les audits de sécurité.

Lorsque vous activez la collecte des flux réseau, seules les métadonnées relatives au trafic sont collectées. Par exemple, les données des paquets ne sont pas collectées, mais le protocole, l'adresse source, l'adresse de destination, les numéros de port, le nombre d'octets et d'autres informations au niveau des paquets sont collectés.

Les données sont collectées dans un ou plusieurs des formats d'enregistrement suivants :

NetFlow
sFlow
IPFIX

Lorsque vous configurez l'opérateur réseau du cluster (CNO) avec une ou plusieurs adresses IP et numéros de port de collecteurs, l'opérateur configure Open vSwitch (OVS) sur chaque nœud pour envoyer les enregistrements de flux réseau à chaque collecteur.

Vous pouvez configurer l'opérateur pour qu'il envoie des enregistrements à plusieurs types de collecteurs de flux réseau. Par exemple, vous pouvez envoyer des enregistrements aux collecteurs NetFlow et également aux collecteurs sFlow.

Lorsqu'OVS envoie des données aux collecteurs, chaque type de collecteur reçoit des enregistrements identiques. Par exemple, si vous configurez deux collecteurs NetFlow, OVS sur un nœud envoie des enregistrements identiques aux deux collecteurs. Si vous configurez également deux collecteurs sFlow, les deux collecteurs sFlow reçoivent des enregistrements identiques. Cependant, chaque type de collecteur a un format d'enregistrement unique.

La collecte des données sur les flux du réseau et l'envoi des enregistrements aux collecteurs affectent les performances. Les nœuds traitent les paquets plus lentement. Si l'impact sur les performances est trop important, vous pouvez supprimer les destinations des collecteurs pour désactiver la collecte des données de flux réseau et rétablir les performances.

Note

L'activation des collecteurs de flux réseau peut avoir un impact sur les performances globales du réseau de la grappe.

24.20.1. Configuration d'objets de réseau pour le suivi des flux de réseau
Copier lien

Les champs de configuration des collecteurs de flux réseau dans le Cluster Network Operator (CNO) sont présentés dans le tableau suivant :

Expand

Tableau 24.12. Configuration des flux du réseau
Field	Type	Description
`metadata.name`	`string`	Le nom de l'objet CNO. Ce nom est toujours `cluster`.
`spec.exportNetworkFlows`	`object`	Un ou plusieurs des sites suivants : `netFlow`, `sFlow`, ou `ipfix`.
`spec.exportNetworkFlows.netFlow.collectors`	`array`	Une liste de paires d'adresses IP et de ports réseau pour un maximum de 10 collecteurs.
`spec.exportNetworkFlows.sFlow.collectors`	`array`	Une liste de paires d'adresses IP et de ports réseau pour un maximum de 10 collecteurs.
`spec.exportNetworkFlows.ipfix.collectors`	`array`	Une liste de paires d'adresses IP et de ports réseau pour un maximum de 10 collecteurs.

Après avoir appliqué le manifeste suivant au CNO, l'Opérateur configure Open vSwitch (OVS) sur chaque nœud du cluster pour envoyer des enregistrements de flux réseau au collecteur NetFlow qui écoute à l'adresse 192.168.1.99:2056.

Exemple de configuration pour le suivi des flux du réseau

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  exportNetworkFlows:
    netFlow:
      collectors:
        - 192.168.1.99:2056

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  exportNetworkFlows:
    netFlow:
      collectors:
        - 192.168.1.99:2056

Copy to Clipboard

Toggle word wrap

24.20.2. Ajout de destinations pour les collecteurs de flux réseau
Copier lien

En tant qu'administrateur de cluster, vous pouvez configurer l'opérateur de réseau de cluster (CNO) pour qu'il envoie des métadonnées de flux réseau sur le réseau de pods à un collecteur de flux réseau.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.
Vous disposez d'un collecteur de flux réseau et vous connaissez l'adresse IP et le port sur lesquels il écoute.

Procédure

Créez un fichier patch qui spécifie le type de collecteur de flux réseau ainsi que l'adresse IP et les informations de port des collecteurs :
```
spec:
  exportNetworkFlows:
    netFlow:
      collectors:
        - 192.168.1.99:2056
```
```
spec:
  exportNetworkFlows:
    netFlow:
      collectors:
        - 192.168.1.99:2056
```
Copy to Clipboard Toggle word wrap

Configurer le CNO avec les collecteurs de flux du réseau :

oc patch network.operator cluster --type merge -p "$(cat <nom_du_fichier>.yaml)"

$ oc patch network.operator cluster --type merge -p "$(cat <nom_du_fichier>.yaml)"

Copy to Clipboard

Toggle word wrap

Exemple de sortie

network.operator.openshift.io/cluster patched

network.operator.openshift.io/cluster patched

Copy to Clipboard

Toggle word wrap

Vérification

La vérification n'est généralement pas nécessaire. Vous pouvez exécuter la commande suivante pour confirmer qu'Open vSwitch (OVS) sur chaque nœud est configuré pour envoyer des enregistrements de flux réseau à un ou plusieurs collecteurs.

Consultez la configuration de l'opérateur pour confirmer que le champ exportNetworkFlows est configuré :

oc get network.operator cluster -o jsonpath="{.spec.exportNetworkFlows}"

$ oc get network.operator cluster -o jsonpath="{.spec.exportNetworkFlows}"

Copy to Clipboard

Toggle word wrap

Exemple de sortie

{"netFlow":{"collectors":["192.168.1.99:2056"]}}

{"netFlow":{"collectors":["192.168.1.99:2056"]}}

Copy to Clipboard

Toggle word wrap

Visualiser la configuration des flux réseau dans OVS à partir de chaque nœud :

for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node -o jsonpath='{range@.items[*]}{.metadata.name}{"\n"}{end}');
  do ;
    echo;
    echo $pod;
    oc -n openshift-ovn-kubernetes exec -c ovnkube-node $pod \
      -- bash -c 'for type in ipfix sflow netflow ; do ovs-vsctl find $type ; done';
done

$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node -o jsonpath='{range@.items[*]}{.metadata.name}{"\n"}{end}');
  do ;
    echo;
    echo $pod;
    oc -n openshift-ovn-kubernetes exec -c ovnkube-node $pod \
      -- bash -c 'for type in ipfix sflow netflow ; do ovs-vsctl find $type ; done';
done

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ovnkube-node-xrn4p
_uuid               : a4d2aaca-5023-4f3d-9400-7275f92611f9
active_timeout      : 60
add_id_to_interface : false
engine_id           : []
engine_type         : []
external_ids        : {}
targets             : ["192.168.1.99:2056"]

ovnkube-node-z4vq9
_uuid               : 61d02fdb-9228-4993-8ff5-b27f01a29bd6
active_timeout      : 60
add_id_to_interface : false
engine_id           : []
engine_type         : []
external_ids        : {}
targets             : ["192.168.1.99:2056"]-

...

ovnkube-node-xrn4p
_uuid               : a4d2aaca-5023-4f3d-9400-7275f92611f9
active_timeout      : 60
add_id_to_interface : false
engine_id           : []
engine_type         : []
external_ids        : {}
targets             : ["192.168.1.99:2056"]

ovnkube-node-z4vq9
_uuid               : 61d02fdb-9228-4993-8ff5-b27f01a29bd6
active_timeout      : 60
add_id_to_interface : false
engine_id           : []
engine_type         : []
external_ids        : {}
targets             : ["192.168.1.99:2056"]-

...

Copy to Clipboard

Toggle word wrap

24.20.3. Suppression de toutes les destinations pour les collecteurs de flux réseau
Copier lien

En tant qu'administrateur de cluster, vous pouvez configurer l'opérateur de réseau de cluster (CNO) pour qu'il cesse d'envoyer des métadonnées de flux réseau à un collecteur de flux réseau.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges cluster-admin.

Procédure

Supprimer tous les collecteurs de flux réseau :

oc patch network.operator cluster --type='json' \
    -p='[{"op":"remove", "path":"/spec/exportNetworkFlows"}]'

$ oc patch network.operator cluster --type='json' \
    -p='[{"op":"remove", "path":"/spec/exportNetworkFlows"}]'

Copy to Clipboard

Toggle word wrap

Exemple de sortie

network.operator.openshift.io/cluster patched

network.operator.openshift.io/cluster patched

Copy to Clipboard

Toggle word wrap

24.21. Configuration d'un réseau hybride
Copier lien

En tant qu'administrateur de cluster, vous pouvez configurer le plugin réseau Red Hat OpenShift Networking OVN-Kubernetes pour permettre aux nœuds Linux et Windows d'héberger des charges de travail Linux et Windows, respectivement.

24.21.1. Configuring hybrid networking with OVN-Kubernetes
Copier lien

You can configure your cluster to use hybrid networking with OVN-Kubernetes. This allows a hybrid cluster that supports different node networking configurations. For example, this is necessary to run both Linux and Windows nodes in a cluster.

Important

You must configure hybrid networking with OVN-Kubernetes during the installation of your cluster. You cannot switch to hybrid networking after the installation process.

Conditions préalables

Vous avez défini OVNKubernetes pour le paramètre networking.networkType dans le fichier install-config.yaml. Pour plus d'informations, consultez la documentation d'installation pour configurer les personnalisations du réseau OpenShift Container Platform sur le fournisseur de cloud que vous avez choisi.

Procédure

Change to the directory that contains the installation program and create the manifests:
```
./openshift-install create manifests --dir <installation_directory>
```
```
$ ./openshift-install create manifests --dir <installation_directory>
```
Copy to Clipboard Toggle word wrap
où :
<installation_directory>
Spécifie le nom du répertoire qui contient le fichier install-config.yaml pour votre cluster.
Créez un fichier manifeste (stub manifest file) pour la configuration réseau avancée, nommé cluster-network-03-config.yml dans le répertoire <installation_directory>/manifests/:
```
cat <<EOF > <installation_directory>/manifests/cluster-network-03-config.yml
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
EOF
```
```
$ cat <<EOF > <installation_directory>/manifests/cluster-network-03-config.yml
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
EOF
```
Copy to Clipboard Toggle word wrap
où :
<installation_directory>
Spécifie le nom du répertoire qui contient le répertoire manifests/ pour votre cluster.
Ouvrez le fichier cluster-network-03-config.yml dans un éditeur et configurez OVN-Kubernetes avec un réseau hybride, comme dans l'exemple suivant :
Specify a hybrid networking configuration
```
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      hybridOverlayConfig:
        hybridClusterNetwork: 
        - cidr: 10.132.0.0/14
          hostPrefix: 23
        hybridOverlayVXLANPort: 9898 
```
```
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      hybridOverlayConfig:
        hybridClusterNetwork: 
```
1
```
        - cidr: 10.132.0.0/14
          hostPrefix: 23
        hybridOverlayVXLANPort: 9898 
```
2
Copy to Clipboard Toggle word wrap
1
Indiquez la configuration CIDR utilisée pour les nœuds du réseau superposé supplémentaire. Le CIDR hybridClusterNetwork ne peut pas chevaucher le CIDR clusterNetwork.
2
Spécifiez un port VXLAN personnalisé pour le réseau superposé supplémentaire. Ceci est nécessaire pour l'exécution de nœuds Windows dans un cluster installé sur vSphere, et ne doit pas être configuré pour un autre fournisseur de cloud. Le port personnalisé peut être n'importe quel port ouvert, à l'exception du port par défaut 4789. Pour plus d'informations sur cette exigence, voir la documentation Microsoft sur la connectivité Pod-to-pod entre les hôtes est rompue.
Note
Windows Server Long-Term Servicing Channel (LTSC) : Windows Server 2019 n'est pas pris en charge sur les clusters avec une valeur hybridOverlayVXLANPort personnalisée car cette version du serveur Windows ne prend pas en charge la sélection d'un port VXLAN personnalisé.
Enregistrez le fichier cluster-network-03-config.yml et quittez l'éditeur de texte.
Facultatif : Sauvegardez le fichier manifests/cluster-network-03-config.yml. Le programme d'installation supprime le répertoire manifests/ lors de la création du cluster.

Complétez toutes les autres configurations d'installation, puis créez votre cluster. La mise en réseau hybride est activée lorsque le processus d'installation est terminé.

Chapitre 25. Plugin réseau SDN OpenShift
Copier lien

25.1. À propos du plugin réseau OpenShift SDN
Copier lien

Faisant partie de Red Hat OpenShift Networking, OpenShift SDN est un plugin réseau qui utilise une approche de réseau défini par logiciel (SDN) pour fournir un réseau de cluster unifié qui permet la communication entre les pods à travers le cluster OpenShift Container Platform. Ce réseau de pods est établi et maintenu par OpenShift SDN, qui configure un réseau superposé à l'aide d'Open vSwitch (OVS).

25.1.1. Modes d'isolation du réseau OpenShift SDN
Copier lien

OpenShift SDN propose trois modes SDN pour configurer le réseau de pods :

Network policy permet aux administrateurs de projets de configurer leurs propres politiques d'isolation en utilisant les objets NetworkPolicy. La politique de réseau est le mode par défaut dans OpenShift Container Platform 4.12.
Multitenant permet d'isoler les pods et les services au niveau du projet. Les pods de différents projets ne peuvent pas envoyer de paquets aux pods et aux services d'un autre projet, ni en recevoir de leur part. Vous pouvez désactiver l'isolation d'un projet, ce qui lui permet d'envoyer du trafic réseau à tous les pods et services de l'ensemble du cluster et de recevoir du trafic réseau de ces pods et services.
Subnet fournit un réseau de pods plat où chaque pod peut communiquer avec tous les autres pods et services. Le mode "politique de réseau" offre les mêmes fonctionnalités que le mode "sous-réseau".

25.1.2. Matrice des caractéristiques des plugins réseau pris en charge
Copier lien

Red Hat OpenShift Networking offre deux options pour le plugin réseau, OpenShift SDN et OVN-Kubernetes, pour le plugin réseau. Le tableau suivant résume la prise en charge actuelle des fonctionnalités pour les deux plugins réseau :

Expand

Tableau 25.1. Comparaison des fonctionnalités du plugin réseau CNI par défaut
Fonctionnalité	OpenShift SDN	OVN-Kubernetes
IP de sortie	Soutenu	Soutenu
Pare-feu de sortie ^[1]	Soutenu	Soutenu
Routeur de sortie	Soutenu	Soutenu ^[2]
Réseau hybride	Non pris en charge	Soutenu
Cryptage IPsec	Non pris en charge	Soutenu
IPv6	Non pris en charge	Soutenu ^[3]
Politique de réseau Kubernetes	Soutenu	Soutenu
Journaux de la politique réseau de Kubernetes	Non pris en charge	Soutenu
Multidiffusion	Soutenu	Soutenu
Déchargement du matériel	Non pris en charge	Soutenu

Le pare-feu de sortie est également connu sous le nom de politique de réseau de sortie dans OpenShift SDN. Ce n'est pas la même chose que la politique de réseau de sortie.
Le routeur de sortie pour OVN-Kubernetes ne prend en charge que le mode de redirection.
IPv6 n'est pris en charge que sur les clusters bare metal, IBM Power et IBM zSystems.

25.2. Configuration des IP de sortie pour un projet
Copier lien

En tant qu'administrateur de cluster, vous pouvez configurer le plugin réseau OpenShift SDN Container Network Interface (CNI) pour attribuer une ou plusieurs adresses IP de sortie à un projet.

25.2.1. Conception architecturale et mise en œuvre de l'adresse IP de sortie
Copier lien

La fonctionnalité d'adresse IP de sortie d'OpenShift Container Platform vous permet de vous assurer que le trafic d'un ou plusieurs pods dans un ou plusieurs espaces de noms a une adresse IP source cohérente pour les services en dehors du réseau du cluster.

Par exemple, vous pouvez avoir un pod qui interroge périodiquement une base de données hébergée sur un serveur extérieur à votre cluster. Pour appliquer les conditions d'accès au serveur, un dispositif de filtrage des paquets est configuré pour n'autoriser le trafic qu'à partir d'adresses IP spécifiques. Pour garantir la fiabilité de l'accès au serveur à partir de ce module spécifique, vous pouvez configurer une adresse IP de sortie spécifique pour le module qui envoie les requêtes au serveur.

Une adresse IP de sortie attribuée à un espace de noms est différente d'un routeur de sortie, qui est utilisé pour envoyer le trafic vers des destinations spécifiques.

Dans certaines configurations de cluster, les pods d'application et les pods de routeur d'entrée fonctionnent sur le même nœud. Si vous configurez une adresse IP de sortie pour un projet d'application dans ce scénario, l'adresse IP n'est pas utilisée lorsque vous envoyez une requête à une route à partir du projet d'application.

Une adresse IP de sortie est mise en œuvre sous la forme d'une adresse IP supplémentaire sur l'interface réseau principale d'un nœud et doit se trouver dans le même sous-réseau que l'adresse IP principale du nœud. L'adresse IP supplémentaire ne doit être attribuée à aucun autre nœud de la grappe.

Important

Les adresses IP de sortie ne doivent pas être configurées dans les fichiers de configuration du réseau Linux, tels que ifcfg-eth0.

25.2.1.1. Soutien à la plate-forme
Copier lien

La prise en charge de la fonctionnalité d'adresse IP de sortie sur diverses plates-formes est résumée dans le tableau suivant :

Expand

Plate-forme	Soutenu
Métal nu	Oui
VMware vSphere	Oui
Plate-forme Red Hat OpenStack (RHOSP)	Oui
Amazon Web Services (AWS)	Oui
Google Cloud Platform (GCP)	Oui
Microsoft Azure	Oui

Important

L'attribution d'adresses IP de sortie aux nœuds du plan de contrôle avec la fonctionnalité EgressIP n'est pas prise en charge sur un cluster provisionné sur Amazon Web Services (AWS). (BZ#2039656)

25.2.1.2. Considérations relatives à la plateforme de cloud public
Copier lien

Pour les clusters provisionnés sur une infrastructure de cloud public, il existe une contrainte sur le nombre absolu d'adresses IP assignables par nœud. Le nombre maximal d'adresses IP assignables par nœud, ou le IP capacitypeut être décrit par la formule suivante :

IP capacity = public cloud default capacity - sum(current IP assignments)

IP capacity = public cloud default capacity - sum(current IP assignments)

Copy to Clipboard

Toggle word wrap

Bien que la fonction Egress IPs gère la capacité d'adresses IP par nœud, il est important de tenir compte de cette contrainte dans vos déploiements. Par exemple, pour un cluster installé sur une infrastructure bare-metal avec 8 nœuds, vous pouvez configurer 150 adresses IP de sortie. Toutefois, si un fournisseur de cloud public limite la capacité d'adresses IP à 10 adresses IP par nœud, le nombre total d'adresses IP assignables n'est que de 80. Pour obtenir la même capacité d'adresses IP dans cet exemple de fournisseur de cloud, il faudrait allouer 7 nœuds supplémentaires.

Pour confirmer la capacité IP et les sous-réseaux de n'importe quel nœud de votre environnement de cloud public, vous pouvez entrer la commande oc get node <node_name> -o yaml. L'annotation cloud.network.openshift.io/egress-ipconfig comprend des informations sur la capacité et les sous-réseaux du nœud.

La valeur d'annotation est un tableau contenant un objet unique dont les champs fournissent les informations suivantes pour l'interface réseau primaire :

interface: Spécifie l'ID de l'interface sur AWS et Azure et le nom de l'interface sur GCP.
ifaddr: Spécifie le masque de sous-réseau pour une ou les deux familles d'adresses IP.
capacity: Spécifie la capacité d'adresses IP pour le nœud. Sur AWS, la capacité d'adresses IP est fournie par famille d'adresses IP. Sur Azure et GCP, la capacité d'adresses IP comprend les adresses IPv4 et IPv6.

L'attachement et le détachement automatiques des adresses IP de sortie pour le trafic entre les nœuds sont disponibles. Cela permet au trafic de nombreux pods dans les espaces de noms d'avoir une adresse IP source cohérente vers des emplacements en dehors du cluster. Cela prend également en charge OpenShift SDN et OVN-Kubernetes, qui est le plugin de mise en réseau par défaut dans Red Hat OpenShift Networking dans OpenShift Container Platform 4.12.

Note

La fonctionnalité RHOSP egress IP address crée un port de réservation Neutron appelé egressip-<IP address>. En utilisant le même utilisateur RHOSP que celui utilisé pour l'installation du cluster OpenShift Container Platform, vous pouvez attribuer une adresse IP flottante à ce port de réservation afin de disposer d'une adresse SNAT prévisible pour le trafic de sortie. Lorsqu'une adresse IP de sortie sur un réseau RHOSP est déplacée d'un nœud à un autre, en raison d'un basculement de nœud, par exemple, le port de réservation Neutron est supprimé et recréé. Cela signifie que l'association IP flottante est perdue et que vous devez réassigner manuellement l'adresse IP flottante au nouveau port de réservation.

Note

Lorsqu'un administrateur de cluster RHOSP assigne une IP flottante au port de réservation, OpenShift Container Platform ne peut pas supprimer le port de réservation. L'objet CloudPrivateIPConfig ne peut pas effectuer d'opérations de suppression et de déplacement jusqu'à ce qu'un administrateur de cluster RHOSP désassigne l'IP flottante du port de réservation.

Les exemples suivants illustrent l'annotation des nœuds de plusieurs fournisseurs de nuages publics. Les annotations sont en retrait pour faciliter la lecture.

Exemple d'annotation cloud.network.openshift.io/egress-ipconfig sur AWS

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"eni-078d267045138e436",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ipv4":14,"ipv6":15}
  }
]

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"eni-078d267045138e436",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ipv4":14,"ipv6":15}
  }
]

Copy to Clipboard

Toggle word wrap

Exemple cloud.network.openshift.io/egress-ipconfig annotation sur GCP

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"nic0",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ip":14}
  }
]

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"nic0",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ip":14}
  }
]

Copy to Clipboard

Toggle word wrap

Les sections suivantes décrivent la capacité d'adresses IP pour les environnements de cloud public pris en charge, à utiliser dans votre calcul de capacité.

25.2.1.2.1. Limites de capacité des adresses IP d'Amazon Web Services (AWS)
Copier lien

Sur AWS, les contraintes d'attribution des adresses IP dépendent du type d'instance configuré. Pour plus d'informations, voir Adresses IP par interface réseau par type d'instance

25.2.1.2.2. Limites de capacité des adresses IP de Google Cloud Platform (GCP)
Copier lien

Sur le GCP, le modèle de réseau met en œuvre des adresses IP de nœuds supplémentaires par le biais de l'alias d'adresses IP, plutôt que par l'attribution d'adresses IP. Toutefois, la capacité d'adresses IP est directement liée à la capacité d'alias d'adresses IP.

Les limites de capacité suivantes s'appliquent à l'attribution de l'alias IP :

Le nombre maximum d'alias IP, tant IPv4 qu'IPv6, est de 10 par nœud.
Par VPC, le nombre maximum d'alias IP n'est pas spécifié, mais les tests d'évolutivité d'OpenShift Container Platform révèlent que le maximum est d'environ 15 000.

Pour plus d'informations, voir Quotas par instance et Aperçu des plages d'adresses IP alias.

25.2.1.2.3. Limites de capacité des adresses IP de Microsoft Azure
Copier lien

Sur Azure, les limites de capacité suivantes existent pour l'attribution d'adresses IP :

Par NIC, le nombre maximum d'adresses IP assignables, tant pour IPv4 que pour IPv6, est de 256.
Par réseau virtuel, le nombre maximum d'adresses IP attribuées ne peut dépasser 65 536.

Pour plus d'informations, voir Limites de mise en réseau.

25.2.1.3. Limites
Copier lien

Les limitations suivantes s'appliquent lors de l'utilisation d'adresses IP de sortie avec le plugin réseau SDN OpenShift :

Vous ne pouvez pas utiliser des adresses IP de sortie attribuées manuellement et automatiquement sur les mêmes nœuds.
Si vous attribuez manuellement des adresses IP de sortie à partir d'une plage d'adresses IP, vous ne devez pas rendre cette plage disponible pour l'attribution automatique d'adresses IP.
Vous ne pouvez pas partager les adresses IP de sortie entre plusieurs espaces de noms en utilisant l'implémentation de l'adresse IP de sortie d'OpenShift SDN.

Si vous devez partager des adresses IP entre plusieurs espaces de noms, l'implémentation de l'adresse IP de sortie du plugin réseau OVN-Kubernetes vous permet de répartir les adresses IP entre plusieurs espaces de noms.

Note

Si vous utilisez OpenShift SDN en mode multitenant, vous ne pouvez pas utiliser d'adresses IP de sortie avec un espace de noms qui est joint à un autre espace de noms par les projets qui leur sont associés. Par exemple, si project1 et project2 sont joints en exécutant la commande oc adm pod-network join-projects --to=project1 project2, aucun des deux projets ne peut utiliser d'adresse IP de sortie. Pour plus d'informations, voir BZ#1645577.

25.2.1.4. Méthodes d'attribution des adresses IP
Copier lien

Vous pouvez attribuer des adresses IP de sortie à des espaces de noms en définissant le paramètre egressIPs de l'objet NetNamespace. Une fois qu'une adresse IP de sortie est associée à un projet, OpenShift SDN vous permet d'attribuer des adresses IP de sortie à des hôtes de deux manières :

Dans cette approche, une plage d'adresses IP de sortie est attribuée à un nœud automatically assigned une plage d'adresses IP de sortie est attribuée à un nœud.
Dans cette approche, une liste d'une ou plusieurs adresses IP de sortie est attribuée à un nœud manually assigned une liste d'une ou plusieurs adresses IP de sortie est attribuée à un nœud.

Les espaces de noms qui demandent une adresse IP de sortie sont mis en correspondance avec les nœuds qui peuvent héberger ces adresses IP de sortie, puis les adresses IP de sortie sont attribuées à ces nœuds. Si le paramètre egressIPs est défini sur un objet NetNamespace, mais qu'aucun nœud n'héberge cette adresse IP de sortie, le trafic de sortie de l'espace de noms sera abandonné.

La haute disponibilité des nœuds est automatique. Si un nœud hébergeant une adresse IP de sortie est inaccessible et qu'il existe des nœuds capables d'héberger cette adresse IP de sortie, l'adresse IP de sortie est déplacée vers un nouveau nœud. Lorsque le nœud inaccessible revient en ligne, l'adresse IP de sortie est automatiquement déplacée afin d'équilibrer les adresses IP de sortie entre les nœuds.

25.2.1.4.1. Points à prendre en compte lors de l'utilisation d'adresses IP de sortie attribuées automatiquement
Copier lien

Les considérations suivantes s'appliquent lors de l'utilisation de l'approche d'attribution automatique pour les adresses IP de sortie :

Vous définissez le paramètre egressCIDRs de la ressource HostSubnet de chaque nœud pour indiquer la plage d'adresses IP de sortie pouvant être hébergées par un nœud. OpenShift Container Platform définit le paramètre egressIPs de la ressource HostSubnet en fonction de la plage d'adresses IP spécifiée.

Si le nœud hébergeant l'adresse IP de sortie de l'espace de noms est inaccessible, OpenShift Container Platform réattribuera l'adresse IP de sortie à un autre nœud avec une plage d'adresses IP de sortie compatible. L'approche d'attribution automatique fonctionne mieux pour les clusters installés dans des environnements offrant une certaine flexibilité dans l'association d'adresses IP supplémentaires aux nœuds.

25.2.1.4.2. Points à prendre en considération lors de l'utilisation d'adresses IP de sortie attribuées manuellement
Copier lien

Cette approche permet de contrôler quels nœuds peuvent héberger une adresse IP de sortie.

Note

Si votre cluster est installé sur une infrastructure de cloud public, vous devez vous assurer que chaque nœud auquel vous attribuez des adresses IP de sortie dispose d'une capacité de réserve suffisante pour héberger les adresses IP. Pour plus d'informations, voir "Considérations sur la plate-forme" dans une section précédente.

Les considérations suivantes s'appliquent à l'attribution manuelle des adresses IP de sortie :

Le paramètre egressIPs de la ressource HostSubnet de chaque nœud indique les adresses IP qui peuvent être hébergées par un nœud.
Plusieurs adresses IP de sortie par espace de noms sont prises en charge.

Si un espace de noms possède plusieurs adresses IP de sortie et que ces adresses sont hébergées sur plusieurs nœuds, les considérations supplémentaires suivantes s'appliquent :

Si un pod se trouve sur un nœud hébergeant une adresse IP de sortie, ce pod utilise toujours l'adresse IP de sortie du nœud.
Si un pod ne se trouve pas sur un nœud hébergeant une adresse IP de sortie, il utilise une adresse IP de sortie aléatoire.

25.2.2. Configuration des adresses IP de sortie attribuées automatiquement à un espace de noms
Copier lien

Dans OpenShift Container Platform, vous pouvez activer l'attribution automatique d'une adresse IP de sortie pour un espace de noms spécifique sur un ou plusieurs nœuds.

Conditions préalables

Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
Vous avez installé l'OpenShift CLI (oc).

Procédure

Mettez à jour l'objet NetNamespace avec l'adresse IP de sortie en utilisant le JSON suivant :
```
oc patch netnamespace <project_name> --type=merge -p \
  '{
    "egressIPs": [
      "<ip_address>"
    ]
  }'
```
```
 $ oc patch netnamespace <project_name> --type=merge -p \
  '{
    "egressIPs": [
      "<ip_address>"
    ]
  }'
```
Copy to Clipboard Toggle word wrap
où :
<project_name>
Spécifie le nom du projet.
<ip_address>
Spécifie une ou plusieurs adresses IP de sortie pour le réseau egressIPs.
Par exemple, pour attribuer à project1 une adresse IP de 192.168.1.100 et à project2 une adresse IP de 192.168.1.101 :
```
oc patch netnamespace project1 --type=merge -p \
  '{"egressIPs": ["192.168.1.100"]}'
oc patch netnamespace project2 --type=merge -p \
  '{"egressIPs": ["192.168.1.101"]}'
```
```
$ oc patch netnamespace project1 --type=merge -p \
  '{"egressIPs": ["192.168.1.100"]}'
$ oc patch netnamespace project2 --type=merge -p \
  '{"egressIPs": ["192.168.1.101"]}'
```
Copy to Clipboard Toggle word wrap
Note
Comme OpenShift SDN gère l'objet NetNamespace, vous ne pouvez effectuer des changements qu'en modifiant l'objet NetNamespace existant. Ne créez pas de nouvel objet NetNamespace.
Indiquez quels nœuds peuvent héberger des adresses IP de sortie en définissant le paramètre egressCIDRs pour chaque hôte à l'aide du JSON suivant :
```
oc patch hostsubnet <node_name> --type=merge -p \
  '{
    "egressCIDRs": [
      "<ip_address_range>", "<ip_address_range>"
    ]
  }'
```
```
$ oc patch hostsubnet <node_name> --type=merge -p \
  '{
    "egressCIDRs": [
      "<ip_address_range>", "<ip_address_range>"
    ]
  }'
```
Copy to Clipboard Toggle word wrap
où :
<node_name>
Spécifie un nom de nœud.
<ip_address_range>
Spécifie une plage d'adresses IP au format CIDR. Vous pouvez spécifier plusieurs plages d'adresses pour le réseau egressCIDRs.
Par exemple, pour configurer node1 et node2 afin qu'ils hébergent des adresses IP de sortie dans la plage 192.168.1.0 à 192.168.1.255 :
```
oc patch hostsubnet node1 --type=merge -p \
  '{"egressCIDRs": ["192.168.1.0/24"]}'
oc patch hostsubnet node2 --type=merge -p \
  '{"egressCIDRs": ["192.168.1.0/24"]}'
```
```
$ oc patch hostsubnet node1 --type=merge -p \
  '{"egressCIDRs": ["192.168.1.0/24"]}'
$ oc patch hostsubnet node2 --type=merge -p \
  '{"egressCIDRs": ["192.168.1.0/24"]}'
```
Copy to Clipboard Toggle word wrap
OpenShift Container Platform attribue automatiquement des adresses IP de sortie spécifiques aux nœuds disponibles de manière équilibrée. Dans ce cas, elle attribue l'adresse IP de sortie 192.168.1.100 à node1 et l'adresse IP de sortie 192.168.1.101 à node2 ou vice versa.

25.2.3. Configuration des adresses IP de sortie attribuées manuellement pour un espace de noms
Copier lien

Dans OpenShift Container Platform, vous pouvez associer une ou plusieurs adresses IP de sortie à un espace de noms.

Conditions préalables

Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
Vous avez installé l'OpenShift CLI (oc).

Procédure

Mettez à jour l'objet NetNamespace en spécifiant l'objet JSON suivant avec les adresses IP souhaitées :
```
oc patch netnamespace <project_name> --type=merge -p \
  '{
    "egressIPs": [
      "<ip_address>"
    ]
  }'
```
```
 $ oc patch netnamespace <project_name> --type=merge -p \
  '{
    "egressIPs": [
      "<ip_address>"
    ]
  }'
```
Copy to Clipboard Toggle word wrap
où :
<project_name>
Spécifie le nom du projet.
<ip_address>
Spécifie une ou plusieurs adresses IP de sortie pour le réseau egressIPs.
Par exemple, pour attribuer le projet project1 aux adresses IP 192.168.1.100 et 192.168.1.101:
```
oc patch netnamespace project1 --type=merge \
  -p '{"egressIPs": ["192.168.1.100","192.168.1.101"]}'
```
```
$ oc patch netnamespace project1 --type=merge \
  -p '{"egressIPs": ["192.168.1.100","192.168.1.101"]}'
```
Copy to Clipboard Toggle word wrap
Pour assurer une haute disponibilité, définissez la valeur egressIPs sur deux adresses IP ou plus sur des nœuds différents. Si plusieurs adresses IP de sortie sont définies, les pods utilisent toutes les adresses IP de sortie de manière à peu près égale.
Note
Comme OpenShift SDN gère l'objet NetNamespace, vous ne pouvez effectuer des changements qu'en modifiant l'objet NetNamespace existant. Ne créez pas de nouvel objet NetNamespace.
Attribuer manuellement l'adresse IP de sortie aux hôtes du nœud.
Si votre cluster est installé sur une infrastructure de cloud public, vous devez confirmer que le nœud dispose d'une capacité d'adresses IP disponible.
Définissez le paramètre egressIPs sur l'objet HostSubnet de l'hôte du nœud. En utilisant le JSON suivant, incluez autant d'adresses IP que vous souhaitez attribuer à cet hôte de nœud :
```
oc patch hostsubnet <node_name> --type=merge -p \
  '{
    "egressIPs": [
      "<ip_address>",
      "<ip_address>"
      ]
  }'
```
```
$ oc patch hostsubnet <node_name> --type=merge -p \
  '{
    "egressIPs": [
      "<ip_address>",
      "<ip_address>"
      ]
  }'
```
Copy to Clipboard Toggle word wrap
où :
<node_name>
Spécifie un nom de nœud.
<ip_address>
Spécifie une adresse IP. Vous pouvez spécifier plusieurs adresses IP pour la matrice egressIPs.
Par exemple, pour spécifier que node1 doit avoir les IP de sortie 192.168.1.100, 192.168.1.101 et 192.168.1.102:
```
oc patch hostsubnet node1 --type=merge -p \
  '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'
```
```
$ oc patch hostsubnet node1 --type=merge -p \
  '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'
```
Copy to Clipboard Toggle word wrap
Dans l'exemple précédent, tout le trafic de sortie pour project1 sera acheminé vers le nœud hébergeant l'adresse IP de sortie spécifiée, puis connecté à cette adresse IP via la traduction d'adresses de réseau (NAT).

25.2.4. Ressources supplémentaires
Copier lien

Si vous configurez l'attribution manuelle d'adresses IP de sortie, reportez-vous à la section Considérations relatives à la plate-forme pour obtenir des informations sur la planification de la capacité IP.

25.3. Configuration d'un pare-feu de sortie pour un projet
Copier lien

En tant qu'administrateur de cluster, vous pouvez créer un pare-feu de sortie pour un projet qui restreint le trafic de sortie de votre cluster OpenShift Container Platform.

25.3.1. Fonctionnement d'un pare-feu de sortie dans un projet
Copier lien

En tant qu'administrateur de cluster, vous pouvez utiliser un egress firewall pour limiter les hôtes externes auxquels certains ou tous les pods peuvent accéder depuis le cluster. Un pare-feu de sortie prend en charge les scénarios suivants :

Un pod ne peut se connecter qu'à des hôtes internes et ne peut pas établir de connexions avec l'internet public.
Un pod ne peut se connecter qu'à l'internet public et ne peut pas initier de connexions vers des hôtes internes qui sont en dehors du cluster OpenShift Container Platform.
Un pod ne peut pas atteindre les sous-réseaux internes spécifiés ou les hôtes en dehors du cluster OpenShift Container Platform.
Un pod ne peut se connecter qu'à des hôtes externes spécifiques.

Par exemple, vous pouvez autoriser un projet à accéder à une plage d'adresses IP donnée, mais refuser le même accès à un autre projet. Vous pouvez également empêcher les développeurs d'applications d'effectuer des mises à jour à partir des miroirs de Python Pip et exiger que les mises à jour proviennent uniquement de sources approuvées.

Note

Le pare-feu de sortie ne s'applique pas à l'espace de noms du réseau hôte. Les pods dont le réseau d'hôtes est activé ne sont pas affectés par les règles de pare-feu de sortie.

Vous configurez une stratégie de pare-feu de sortie en créant un objet de ressource personnalisée (CR) EgressNetworkPolicy. Le pare-feu de sortie correspond au trafic réseau qui répond à l'un des critères suivants :

Une plage d'adresses IP au format CIDR
Un nom DNS qui se résout en une adresse IP

Important

Si votre pare-feu de sortie comprend une règle de refus pour 0.0.0.0/0, l'accès à vos serveurs API OpenShift Container Platform est bloqué. Vous devez soit ajouter des règles d'autorisation pour chaque adresse IP, soit utiliser la règle d'autorisation de type nodeSelector dans vos règles de stratégie de sortie pour vous connecter aux serveurs API.

L'exemple suivant illustre l'ordre des règles de pare-feu de sortie nécessaires pour garantir l'accès au serveur API :

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
  namespace: <namespace> 
spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range> 
    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0 
    type: Deny

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
  namespace: <namespace>

1


spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range>

2


    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0

3


    type: Deny

Copy to Clipboard

Toggle word wrap

1: L'espace de noms pour le pare-feu de sortie.
2: La plage d'adresses IP qui comprend vos serveurs API OpenShift Container Platform.
3: Une règle de refus globale empêche l'accès aux serveurs API de OpenShift Container Platform.

Pour trouver l'adresse IP de vos serveurs API, exécutez oc get ep kubernetes -n default.

Pour plus d'informations, voir BZ#1988324.

Important

Vous devez avoir OpenShift SDN configuré pour utiliser soit la politique de réseau, soit le mode multitenant pour configurer un pare-feu de sortie.

Si vous utilisez le mode stratégie réseau, un pare-feu de sortie n'est compatible qu'avec une seule stratégie par espace de noms et ne fonctionnera pas avec les projets qui partagent un réseau, tels que les projets globaux.

Avertissement

Les règles de pare-feu de sortie ne s'appliquent pas au trafic qui passe par les routeurs. Tout utilisateur autorisé à créer un objet Route CR peut contourner les règles du pare-feu de sortie en créant une route qui pointe vers une destination interdite.

25.3.1.1. Limites d'un pare-feu de sortie
Copier lien

Un pare-feu de sortie présente les limitations suivantes :

Aucun projet ne peut avoir plus d'un objet EgressNetworkPolicy.
Un maximum d'un objet EgressNetworkPolicy avec un maximum de 1 000 règles peut être défini par projet.
Le projet default ne peut pas utiliser de pare-feu de sortie.
Lors de l'utilisation du plugin réseau OpenShift SDN en mode multitenant, les limitations suivantes s'appliquent :
- Les projets globaux ne peuvent pas utiliser de pare-feu de sortie. Vous pouvez rendre un projet global en utilisant la commande oc adm pod-network make-projects-global.
- Les projets fusionnés à l'aide de la commande oc adm pod-network join-projects ne peuvent utiliser un pare-feu de sortie dans aucun des projets fusionnés.

La violation de l'une ou l'autre de ces restrictions a pour effet de briser le pare-feu de sortie du projet et peut entraîner l'interruption de tout le trafic du réseau externe.

Une ressource Egress Firewall peut être créée dans les projets kube-node-lease, kube-public, kube-system, openshift et openshift-.

25.3.1.2. Ordre de correspondance pour les règles de politique de pare-feu de sortie
Copier lien

Les règles de pare-feu de sortie sont évaluées dans l'ordre où elles sont définies, de la première à la dernière. La première règle qui correspond à une connexion de sortie d'un pod s'applique. Les règles suivantes sont ignorées pour cette connexion.

25.3.1.3. Fonctionnement de la résolution des serveurs de noms de domaine (DNS)
Copier lien

Si vous utilisez des noms DNS dans l'une de vos règles de stratégie de pare-feu de sortie, la résolution correcte des noms de domaine est soumise aux restrictions suivantes :

Les mises à jour de noms de domaine sont interrogées sur la base d'une durée de vie (TTL). Par défaut, cette durée est de 30 secondes. Lorsque le contrôleur du pare-feu de sortie interroge les serveurs de noms locaux pour un nom de domaine, si la réponse comprend un TTL inférieur à 30 secondes, le contrôleur définit la durée sur la valeur renvoyée. Si le TTL de la réponse est supérieur à 30 minutes, le contrôleur fixe la durée à 30 minutes. Si le TTL est compris entre 30 secondes et 30 minutes, le contrôleur ignore la valeur et fixe la durée à 30 secondes.
Le pod doit résoudre le domaine à partir des mêmes serveurs de noms locaux si nécessaire. Sinon, les adresses IP du domaine connues par le contrôleur du pare-feu de sortie et le module peuvent être différentes. Si les adresses IP d'un nom d'hôte diffèrent, le pare-feu de sortie risque de ne pas être appliqué de manière cohérente.
Étant donné que le contrôleur de pare-feu de sortie et les modules interrogent de manière asynchrone le même serveur de noms local, le module peut obtenir l'adresse IP mise à jour avant le contrôleur de sortie, ce qui provoque une situation de course. En raison de cette limitation actuelle, l'utilisation de noms de domaine dans les objets EgressNetworkPolicy n'est recommandée que pour les domaines dont les changements d'adresse IP sont peu fréquents.

Note

Le pare-feu de sortie permet toujours aux pods d'accéder à l'interface externe du nœud sur lequel le pod se trouve pour la résolution DNS.

Si vous utilisez des noms de domaine dans votre stratégie de pare-feu de sortie et que votre résolution DNS n'est pas gérée par un serveur DNS sur le nœud local, vous devez ajouter des règles de pare-feu de sortie qui autorisent l'accès aux adresses IP de votre serveur DNS. si vous utilisez des noms de domaine dans vos modules.

25.3.2. Objet de ressource personnalisée (CR) EgressNetworkPolicy
Copier lien

Vous pouvez définir une ou plusieurs règles pour un pare-feu de sortie. Une règle est soit une règle Allow, soit une règle Deny, avec une spécification du trafic auquel la règle s'applique.

Le fichier YAML suivant décrit un objet CR EgressNetworkPolicy :

Objet EgressNetworkPolicy

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: <name> 
spec:
  egress: 
    ...

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: <name>

1


spec:
  egress:

2

...

Copy to Clipboard

Toggle word wrap

1: Un nom pour votre politique de pare-feu de sortie.
2: Ensemble d'une ou de plusieurs règles de politique de réseau de sortie, comme décrit dans la section suivante.

25.3.2.1. Règles de politique de réseau de sortie (EgressNetworkPolicy)
Copier lien

Le fichier YAML suivant décrit un objet de règle de pare-feu de sortie. L'utilisateur peut sélectionner une plage d'adresses IP au format CIDR, un nom de domaine ou utiliser nodeSelector pour autoriser ou refuser le trafic de sortie. La strophe egress attend un tableau d'un ou plusieurs objets.

Règles de politique de sortie (Egress policy rule stanza)

egress:
- type: <type> 
  to: 
    cidrSelector: <cidr> 
    dnsName: <dns_name>

egress:
- type: <type>

1

to:

2


    cidrSelector: <cidr>

3


    dnsName: <dns_name>

4

Copy to Clipboard

Toggle word wrap

1: Le type de règle. La valeur doit être Allow ou Deny.
2: Une strophe décrivant une règle de correspondance du trafic de sortie. Une valeur pour le champ cidrSelector ou le champ dnsName de la règle. Vous ne pouvez pas utiliser les deux champs dans la même règle.
3: Une plage d'adresses IP au format CIDR.
4: Un nom de domaine.

25.3.2.2. Exemple d'objets CR EgressNetworkPolicy
Copier lien

L'exemple suivant définit plusieurs règles de stratégie de pare-feu de sortie :

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
spec:
  egress: 
  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Allow
    to:
      dnsName: www.example.com
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
spec:
  egress:

1


  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Allow
    to:
      dnsName: www.example.com
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0

Copy to Clipboard

Toggle word wrap

1: Une collection d'objets de règles de stratégie de pare-feu de sortie.

25.3.3. Création d'un objet de stratégie de pare-feu de sortie
Copier lien

En tant qu'administrateur de cluster, vous pouvez créer un objet de stratégie de pare-feu de sortie pour un projet.

Important

Si le projet a déjà un objet EgressNetworkPolicy défini, vous devez modifier la stratégie existante pour apporter des changements aux règles du pare-feu de sortie.

Conditions préalables

Un cluster qui utilise le plugin réseau OpenShift SDN.
Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster en tant qu'administrateur du cluster.

Procédure

Créer une règle de politique :
1. Créez un fichier <policy_name>.yaml dans lequel <policy_name> décrit les règles de la politique de sortie.
2. Dans le fichier que vous avez créé, définissez un objet de politique de sortie.
Entrez la commande suivante pour créer l'objet de politique. Remplacez <policy_name> par le nom de la politique et <project> par le projet auquel la règle s'applique.
```
oc create -f <policy_name>.yaml -n <project>
```
```
oc create -f <policy_name>.yaml -n <project>
```
Copy to Clipboard Toggle word wrap
Dans l'exemple suivant, un nouvel objet EgressNetworkPolicy est créé dans un projet nommé project1:
```
oc create -f default.yaml -n project1
```
```
$ oc create -f default.yaml -n project1
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
egressnetworkpolicy.network.openshift.io/v1 created
```
```
egressnetworkpolicy.network.openshift.io/v1 created
```
Copy to Clipboard Toggle word wrap
Facultatif : Enregistrez le fichier <policy_name>.yaml pour pouvoir le modifier ultérieurement.

25.4. Modification d'un pare-feu de sortie pour un projet
Copier lien

En tant qu'administrateur de cluster, vous pouvez modifier les règles de trafic réseau d'un pare-feu de sortie existant.

25.4.1. Visualisation d'un objet EgressNetworkPolicy
Copier lien

Vous pouvez visualiser un objet EgressNetworkPolicy dans votre cluster.

Conditions préalables

Un cluster utilisant le plugin réseau OpenShift SDN.
Installer l'interface de ligne de commande (CLI) d'OpenShift, communément appelée oc.
Vous devez vous connecter au cluster.

Procédure

Facultatif : Pour afficher les noms des objets EgressNetworkPolicy définis dans votre cluster, entrez la commande suivante :
```
oc get egressnetworkpolicy --all-namespaces
```
```
$ oc get egressnetworkpolicy --all-namespaces
```
Copy to Clipboard Toggle word wrap

Pour inspecter une politique, entrez la commande suivante. Remplacez <policy_name> par le nom de la stratégie à inspecter.

oc describe egressnetworkpolicy <nom_de_la_politique>

$ oc describe egressnetworkpolicy <nom_de_la_politique>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name:		default
Namespace:	project1
Created:	20 minutes ago
Labels:		<none>
Annotations:	<none>
Rule:		Allow to 1.2.3.0/24
Rule:		Allow to www.example.com
Rule:		Deny to 0.0.0.0/0

Name:		default
Namespace:	project1
Created:	20 minutes ago
Labels:		<none>
Annotations:	<none>
Rule:		Allow to 1.2.3.0/24
Rule:		Allow to www.example.com
Rule:		Deny to 0.0.0.0/0

Copy to Clipboard

Toggle word wrap

25.5. Modification d'un pare-feu de sortie pour un projet
Copier lien

En tant qu'administrateur de cluster, vous pouvez modifier les règles de trafic réseau d'un pare-feu de sortie existant.

25.5.1. Modification d'un objet EgressNetworkPolicy
Copier lien

En tant qu'administrateur de cluster, vous pouvez mettre à jour le pare-feu de sortie pour un projet.

Conditions préalables

Un cluster utilisant le plugin réseau OpenShift SDN.
Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster en tant qu'administrateur du cluster.

Procédure

Trouvez le nom de l'objet EgressNetworkPolicy pour le projet. Remplacez <project> par le nom du projet.
```
oc get -n <project> egressnetworkpolicy
```
```
oc get -n <project> egressnetworkpolicy
```
Copy to Clipboard Toggle word wrap
Facultatif : si vous n'avez pas enregistré une copie de l'objet EgressNetworkPolicy lors de la création du pare-feu de réseau de sortie, entrez la commande suivante pour créer une copie.
```
oc get -n <project> egressnetworkpolicy <name> -o yaml > <filename>.yaml
```
```
$ oc get -n <project> egressnetworkpolicy <name> -o yaml > <filename>.yaml
```
Copy to Clipboard Toggle word wrap
Remplacer <project> par le nom du projet. Remplacez <name> par le nom de l'objet. Remplacer <filename> par le nom du fichier dans lequel enregistrer le YAML.
Après avoir modifié les règles de stratégie, entrez la commande suivante pour remplacer l'objet EgressNetworkPolicy. Remplacez <filename> par le nom du fichier contenant l'objet EgressNetworkPolicy mis à jour.
```
oc replace -f <filename>.yaml
```
```
$ oc replace -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap

25.6. Suppression d'un pare-feu de sortie d'un projet
Copier lien

En tant qu'administrateur de cluster, vous pouvez supprimer un pare-feu de sortie d'un projet pour supprimer toutes les restrictions sur le trafic réseau du projet qui quitte le cluster OpenShift Container Platform.

25.6.1. Suppression d'un objet EgressNetworkPolicy
Copier lien

En tant qu'administrateur de cluster, vous pouvez supprimer un pare-feu de sortie d'un projet.

Conditions préalables

Un cluster utilisant le plugin réseau OpenShift SDN.
Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster en tant qu'administrateur du cluster.

Procédure

Trouvez le nom de l'objet EgressNetworkPolicy pour le projet. Remplacez <project> par le nom du projet.
```
oc get -n <project> egressnetworkpolicy
```
```
oc get -n <project> egressnetworkpolicy
```
Copy to Clipboard Toggle word wrap
Entrez la commande suivante pour supprimer l'objet EgressNetworkPolicy. Remplacez <project> par le nom du projet et <name> par le nom de l'objet.
```
oc delete -n <project> egressnetworkpolicy <name>
```
```
oc delete -n <project> egressnetworkpolicy <name>
```
Copy to Clipboard Toggle word wrap

25.7. Considérations relatives à l'utilisation d'un module de routeur de sortie
Copier lien

25.7.1. À propos d'un pod de routeur de sortie
Copier lien

Le pod routeur egress d'OpenShift Container Platform redirige le trafic vers un serveur distant spécifié à partir d'une adresse IP source privée qui n'est pas utilisée à d'autres fins. Un pod routeur egress peut envoyer du trafic réseau à des serveurs qui sont configurés pour n'autoriser l'accès qu'à partir d'adresses IP spécifiques.

Note

Le module de routeur de sortie n'est pas destiné à chaque connexion sortante. La création d'un grand nombre de modules de routeur de sortie peut dépasser les limites de votre matériel réseau. Par exemple, la création d'un module de routeur de sortie pour chaque projet ou application pourrait dépasser le nombre d'adresses MAC locales que l'interface réseau peut gérer avant de revenir au filtrage des adresses MAC dans le logiciel.

Important

L'image du routeur de sortie n'est pas compatible avec Amazon AWS, Azure Cloud ou toute autre plateforme cloud qui ne prend pas en charge les manipulations de la couche 2 en raison de leur incompatibilité avec le trafic macvlan.

25.7.1.1. Modes du routeur de sortie
Copier lien

En redirect modeun pod routeur de sortie configure les règles iptables pour rediriger le trafic de sa propre adresse IP vers une ou plusieurs adresses IP de destination. Les modules clients qui doivent utiliser l'adresse IP source réservée doivent être modifiés pour se connecter au routeur de sortie plutôt que de se connecter directement à l'adresse IP de destination.

En HTTP proxy modeun pod de routeur de sortie fonctionne comme un proxy HTTP sur le port 8080. Ce mode ne fonctionne que pour les clients qui se connectent à des services basés sur HTTP ou HTTPS, mais il nécessite généralement moins de modifications des pods clients pour les faire fonctionner. Il est possible de demander à de nombreux programmes d'utiliser un proxy HTTP en définissant une variable d'environnement.

En DNS proxy modeun pod routeur de sortie fonctionne comme un proxy DNS pour les services basés sur TCP depuis sa propre adresse IP vers une ou plusieurs adresses IP de destination. Pour utiliser l'adresse IP source réservée, les modules clients doivent être modifiés pour se connecter au module de routeur de sortie plutôt que de se connecter directement à l'adresse IP de destination. Cette modification garantit que les destinations externes traitent le trafic comme s'il provenait d'une source connue.

Le mode de redirection fonctionne pour tous les services, à l'exception des services HTTP et HTTPS. Pour les services HTTP et HTTPS, utilisez le mode proxy HTTP. Pour les services basés sur TCP avec des adresses IP ou des noms de domaine, utilisez le mode proxy DNS.

25.7.1.2. Mise en œuvre d'un pod de routeur de sortie
Copier lien

La configuration du pod du routeur de sortie est effectuée par un conteneur d'initialisation. Ce conteneur s'exécute dans un contexte privilégié afin de pouvoir configurer l'interface macvlan et définir les règles iptables. Une fois que le conteneur d'initialisation a fini de configurer les règles iptables, il se termine. Ensuite, le module routeur de sortie exécute le conteneur pour gérer le trafic du routeur de sortie. L'image utilisée varie en fonction du mode du routeur de sortie.

Les variables d'environnement déterminent les adresses utilisées par l'image egress-router. L'image configure l'interface macvlan pour qu'elle utilise EGRESS_SOURCE comme adresse IP, avec EGRESS_GATEWAY comme adresse IP pour la passerelle.

Des règles de traduction d'adresses réseau (NAT) sont mises en place pour que les connexions à l'adresse IP du cluster du pod sur n'importe quel port TCP ou UDP soient redirigées vers le même port sur l'adresse IP spécifiée par la variable EGRESS_DESTINATION.

Si seuls certains nœuds de votre cluster sont capables de revendiquer l'adresse IP source spécifiée et d'utiliser la passerelle spécifiée, vous pouvez spécifier nodeName ou nodeSelector pour identifier les nœuds acceptables.

25.7.1.3. Considérations relatives au déploiement
Copier lien

Un pod routeur de sortie ajoute une adresse IP et une adresse MAC supplémentaires à l'interface réseau principale du nœud. Par conséquent, il se peut que vous deviez configurer votre hyperviseur ou votre fournisseur de cloud pour autoriser l'adresse supplémentaire.

Plate-forme Red Hat OpenStack (RHOSP)

Si vous déployez OpenShift Container Platform sur RHOSP, vous devez autoriser le trafic à partir des adresses IP et MAC du pod routeur egress sur votre environnement OpenStack. Si vous n'autorisez pas le trafic, la communication échouera:

openstack port set --allowed-address \
  ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>

$ openstack port set --allowed-address \
  ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>

Copy to Clipboard

Toggle word wrap

Red Hat Virtualization (RHV)

Si vous utilisez RHV, vous devez sélectionner No Network Filter pour le contrôleur d'interface réseau virtuel (vNIC).

VMware vSphere

Si vous utilisez VMware vSphere, consultez la documentation VMware pour sécuriser les commutateurs standard vSphere. Affichez et modifiez les paramètres par défaut de VMware vSphere en sélectionnant le commutateur virtuel de l'hôte dans le client Web vSphere.

En particulier, assurez-vous que les éléments suivants sont activés :

25.7.1.4. Configuration du basculement
Copier lien

Pour éviter les temps d'arrêt, vous pouvez déployer un module de routeur de sortie avec une ressource Deployment, comme dans l'exemple suivant. Pour créer un nouvel objet Service pour l'exemple de déploiement, utilisez la commande oc expose deployment/egress-demo-controller.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: egress-demo-controller
spec:
  replicas: 1 
  selector:
    matchLabels:
      name: egress-router
  template:
    metadata:
      name: egress-router
      labels:
        name: egress-router
      annotations:
        pod.network.openshift.io/assign-macvlan: "true"
    spec: 
      initContainers:
        ...
      containers:
        ...

apiVersion: apps/v1
kind: Deployment
metadata:
  name: egress-demo-controller
spec:
  replicas: 1

1


  selector:
    matchLabels:
      name: egress-router
  template:
    metadata:
      name: egress-router
      labels:
        name: egress-router
      annotations:
        pod.network.openshift.io/assign-macvlan: "true"
    spec:

2


      initContainers:
        ...
      containers:
        ...

Copy to Clipboard

Toggle word wrap

1: Veillez à ce que le paramètre replicas soit défini sur 1, car un seul pod peut utiliser une adresse IP source de sortie donnée à tout moment. Cela signifie qu'une seule copie du routeur fonctionne sur un nœud.
2: Spécifiez le modèle d'objet Pod pour le pod du routeur de sortie.

25.8. Déploiement d'un pod routeur de sortie en mode redirection
Copier lien

En tant qu'administrateur de cluster, vous pouvez déployer un module de routeur de sortie configuré pour rediriger le trafic vers des adresses IP de destination spécifiées.

25.8.1. Spécification du pod du routeur de sortie pour le mode redirection
Copier lien

Définir la configuration d'un module de routeur de sortie dans l'objet Pod. Le fichier YAML suivant décrit les champs pour la configuration d'un module de routeur de sortie en mode redirection :

apiVersion: v1
kind: Pod
metadata:
  name: egress-1
  labels:
    name: egress-1
  annotations:
    pod.network.openshift.io/assign-macvlan: "true" 
spec:
  initContainers:
  - name: egress-router
    image: registry.redhat.io/openshift4/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE 
      value: <egress_router>
    - name: EGRESS_GATEWAY 
      value: <egress_gateway>
    - name: EGRESS_DESTINATION 
      value: <egress_destination>
    - name: EGRESS_ROUTER_MODE
      value: init
  containers:
  - name: egress-router-wait
    image: registry.redhat.io/openshift4/ose-pod

apiVersion: v1
kind: Pod
metadata:
  name: egress-1
  labels:
    name: egress-1
  annotations:
    pod.network.openshift.io/assign-macvlan: "true"

1


spec:
  initContainers:
  - name: egress-router
    image: registry.redhat.io/openshift4/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE

2


      value: <egress_router>
    - name: EGRESS_GATEWAY

3


      value: <egress_gateway>
    - name: EGRESS_DESTINATION

4


      value: <egress_destination>
    - name: EGRESS_ROUTER_MODE
      value: init
  containers:
  - name: egress-router-wait
    image: registry.redhat.io/openshift4/ose-pod

Copy to Clipboard

Toggle word wrap

1: L'annotation indique à OpenShift Container Platform de créer une interface réseau macvlan sur le contrôleur d'interface réseau (NIC) primaire et de déplacer cette interface macvlan dans l'espace de noms réseau du pod. Vous devez inclure les guillemets autour de la valeur "true". Pour qu'OpenShift Container Platform crée l'interface macvlan sur une interface NIC différente, définissez la valeur d'annotation au nom de cette interface. Par exemple, eth1.
2: Adresse IP du réseau physique sur lequel se trouve le nœud, réservée à l'usage du routeur de sortie. Facultatif : vous pouvez inclure la longueur du sous-réseau, le suffixe /24, afin qu'une route appropriée vers le sous-réseau local soit définie. Si vous ne spécifiez pas de longueur de sous-réseau, le routeur de sortie ne peut accéder qu'à l'hôte spécifié par la variable EGRESS_GATEWAY et à aucun autre hôte du sous-réseau.
3: Même valeur que la passerelle par défaut utilisée par le nœud.
4: Serveur externe vers lequel diriger le trafic. Dans cet exemple, les connexions au pod sont redirigées vers 203.0.113.25, avec une adresse IP source de 192.168.12.99.

Exemple de spécification de pod de routeur de sortie

apiVersion: v1
kind: Pod
metadata:
  name: egress-multi
  labels:
    name: egress-multi
  annotations:
    pod.network.openshift.io/assign-macvlan: "true"
spec:
  initContainers:
  - name: egress-router
    image: registry.redhat.io/openshift4/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE
      value: 192.168.12.99/24
    - name: EGRESS_GATEWAY
      value: 192.168.12.1
    - name: EGRESS_DESTINATION
      value: |
        80   tcp 203.0.113.25
        8080 tcp 203.0.113.26 80
        8443 tcp 203.0.113.26 443
        203.0.113.27
    - name: EGRESS_ROUTER_MODE
      value: init
  containers:
  - name: egress-router-wait
    image: registry.redhat.io/openshift4/ose-pod

apiVersion: v1
kind: Pod
metadata:
  name: egress-multi
  labels:
    name: egress-multi
  annotations:
    pod.network.openshift.io/assign-macvlan: "true"
spec:
  initContainers:
  - name: egress-router
    image: registry.redhat.io/openshift4/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE
      value: 192.168.12.99/24
    - name: EGRESS_GATEWAY
      value: 192.168.12.1
    - name: EGRESS_DESTINATION
      value: |
        80   tcp 203.0.113.25
        8080 tcp 203.0.113.26 80
        8443 tcp 203.0.113.26 443
        203.0.113.27
    - name: EGRESS_ROUTER_MODE
      value: init
  containers:
  - name: egress-router-wait
    image: registry.redhat.io/openshift4/ose-pod

Copy to Clipboard

Toggle word wrap

25.8.2. Format de configuration de la destination de sortie
Copier lien

Lorsqu'un module de routeur de sortie est déployé en mode redirection, vous pouvez spécifier des règles de redirection en utilisant un ou plusieurs des formats suivants :

<port> <protocol> <ip_address> - Les connexions entrantes vers le site <port> doivent être redirigées vers le même port sur le site <ip_address>. <protocol> est soit tcp soit udp.
<port> <protocol> <ip_address> <remote_port> - Comme ci-dessus, sauf que la connexion est redirigée vers un autre <remote_port> sur <ip_address>.
<ip_address> - Si la dernière ligne est une adresse IP unique, toute connexion sur un autre port sera redirigée vers le port correspondant à cette adresse IP. S'il n'y a pas d'adresse IP de repli, les connexions sur les autres ports sont rejetées.

Dans l'exemple qui suit, plusieurs règles sont définies :

La première ligne redirige le trafic du port local 80 vers le port 80 sur 203.0.113.25.
Les deuxième et troisième lignes redirigent les ports locaux 8080 et 8443 vers les ports distants 80 et 443 sur 203.0.113.26.
La dernière ligne correspond au trafic pour tous les ports non spécifiés dans les règles précédentes.

Exemple de configuration

80   tcp 203.0.113.25
8080 tcp 203.0.113.26 80
8443 tcp 203.0.113.26 443
203.0.113.27

80   tcp 203.0.113.25
8080 tcp 203.0.113.26 80
8443 tcp 203.0.113.26 443
203.0.113.27

Copy to Clipboard

Toggle word wrap

25.8.3. Déploiement d'un pod routeur de sortie en mode redirection
Copier lien

En redirect modeun pod routeur de sortie configure des règles iptables pour rediriger le trafic de sa propre adresse IP vers une ou plusieurs adresses IP de destination. Les modules clients qui doivent utiliser l'adresse IP source réservée doivent être modifiés pour se connecter au routeur de sortie plutôt que de se connecter directement à l'adresse IP de destination.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créer un module de routeur de sortie.
Pour que les autres modules puissent trouver l'adresse IP du module de routeur de sortie, créez un service qui pointe vers le module de routeur de sortie, comme dans l'exemple suivant :
```
apiVersion: v1
kind: Service
metadata:
  name: egress-1
spec:
  ports:
  - name: http
    port: 80
  - name: https
    port: 443
  type: ClusterIP
  selector:
    name: egress-1
```
```
apiVersion: v1
kind: Service
metadata:
  name: egress-1
spec:
  ports:
  - name: http
    port: 80
  - name: https
    port: 443
  type: ClusterIP
  selector:
    name: egress-1
```
Copy to Clipboard Toggle word wrap
Vos pods peuvent maintenant se connecter à ce service. Leurs connexions sont redirigées vers les ports correspondants sur le serveur externe, en utilisant l'adresse IP de sortie réservée.

25.9. Déploiement d'un pod routeur de sortie en mode proxy HTTP
Copier lien

En tant qu'administrateur de cluster, vous pouvez déployer un pod de routeur de sortie configuré pour acheminer le trafic vers les services HTTP et HTTPS spécifiés.

25.9.1. Spécification du pod du routeur de sortie pour le mode HTTP
Copier lien

Définir la configuration d'un module de routeur de sortie dans l'objet Pod. Le fichier YAML suivant décrit les champs pour la configuration d'un module de routeur de sortie en mode HTTP :

apiVersion: v1
kind: Pod
metadata:
  name: egress-1
  labels:
    name: egress-1
  annotations:
    pod.network.openshift.io/assign-macvlan: "true" 
spec:
  initContainers:
  - name: egress-router
    image: registry.redhat.io/openshift4/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE 
      value: <egress-router>
    - name: EGRESS_GATEWAY 
      value: <egress-gateway>
    - name: EGRESS_ROUTER_MODE
      value: http-proxy
  containers:
  - name: egress-router-pod
    image: registry.redhat.io/openshift4/ose-egress-http-proxy
    env:
    - name: EGRESS_HTTP_PROXY_DESTINATION 
      value: |-
        ...
    ...

apiVersion: v1
kind: Pod
metadata:
  name: egress-1
  labels:
    name: egress-1
  annotations:
    pod.network.openshift.io/assign-macvlan: "true"

1


spec:
  initContainers:
  - name: egress-router
    image: registry.redhat.io/openshift4/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE

2


      value: <egress-router>
    - name: EGRESS_GATEWAY

3


      value: <egress-gateway>
    - name: EGRESS_ROUTER_MODE
      value: http-proxy
  containers:
  - name: egress-router-pod
    image: registry.redhat.io/openshift4/ose-egress-http-proxy
    env:
    - name: EGRESS_HTTP_PROXY_DESTINATION

4


      value: |-
        ...
    ...

Copy to Clipboard

Toggle word wrap

1: L'annotation indique à OpenShift Container Platform de créer une interface réseau macvlan sur le contrôleur d'interface réseau (NIC) primaire et de déplacer cette interface macvlan dans l'espace de noms réseau du pod. Vous devez inclure les guillemets autour de la valeur "true". Pour qu'OpenShift Container Platform crée l'interface macvlan sur une interface NIC différente, définissez la valeur d'annotation au nom de cette interface. Par exemple, eth1.
2: Adresse IP du réseau physique sur lequel se trouve le nœud, réservée à l'usage du routeur de sortie. Facultatif : vous pouvez inclure la longueur du sous-réseau, le suffixe /24, afin qu'une route appropriée vers le sous-réseau local soit définie. Si vous ne spécifiez pas de longueur de sous-réseau, le routeur de sortie ne peut accéder qu'à l'hôte spécifié par la variable EGRESS_GATEWAY et à aucun autre hôte du sous-réseau.
3: Même valeur que la passerelle par défaut utilisée par le nœud.
4: Une chaîne ou une chaîne de plusieurs lignes YAML spécifiant comment configurer le proxy. Notez que ceci est spécifié en tant que variable d'environnement dans le conteneur de proxy HTTP, et non avec les autres variables d'environnement dans le conteneur init.

25.9.2. Format de configuration de la destination de sortie
Copier lien

Lorsqu'un module de routeur de sortie est déployé en mode proxy HTTP, vous pouvez spécifier des règles de redirection en utilisant un ou plusieurs des formats suivants. Chaque ligne de la configuration spécifie un groupe de connexions à autoriser ou à refuser :

Une adresse IP autorise les connexions à cette adresse IP, par exemple 192.168.1.1.
Une plage CIDR autorise les connexions à cette plage CIDR, par exemple 192.168.1.0/24.
Un nom d'hôte permet d'accéder à cet hôte par procuration, par exemple www.example.com.
Un nom de domaine précédé de *. permet d'accéder par procuration à ce domaine et à tous ses sous-domaines, comme *.example.com.
Une adresse ! suivie de l'une des expressions de correspondance précédentes refuse la connexion.
Si la dernière ligne est *, tout ce qui n'est pas explicitement refusé est autorisé. Sinon, tout ce qui n'est pas autorisé est refusé.

Vous pouvez également utiliser * pour autoriser les connexions vers toutes les destinations distantes.

Exemple de configuration

!*.example.com
!192.168.1.0/24
192.168.2.1
*

!*.example.com
!192.168.1.0/24
192.168.2.1
*

Copy to Clipboard

Toggle word wrap

25.9.3. Déploiement d'un pod routeur de sortie en mode proxy HTTP
Copier lien

En HTTP proxy modeun pod de routeur de sortie fonctionne comme un proxy HTTP sur le port 8080. Ce mode ne fonctionne que pour les clients qui se connectent à des services basés sur HTTP ou HTTPS, mais il nécessite généralement moins de modifications des pods clients pour les faire fonctionner. Il est possible de demander à de nombreux programmes d'utiliser un proxy HTTP en définissant une variable d'environnement.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créer un module de routeur de sortie.

Pour que les autres modules puissent trouver l'adresse IP du module de routeur de sortie, créez un service qui pointe vers le module de routeur de sortie, comme dans l'exemple suivant :

apiVersion: v1
kind: Service
metadata:
  name: egress-1
spec:
  ports:
  - name: http-proxy
    port: 8080 
  type: ClusterIP
  selector:
    name: egress-1

apiVersion: v1
kind: Service
metadata:
  name: egress-1
spec:
  ports:
  - name: http-proxy
    port: 8080

1


  type: ClusterIP
  selector:
    name: egress-1

Copy to Clipboard

Toggle word wrap

1: Assurez-vous que le port http est défini sur 8080.

Pour configurer le pod client (et non le pod proxy egress) afin qu'il utilise le proxy HTTP, définissez les variables http_proxy ou https_proxy:

apiVersion: v1
kind: Pod
metadata:
  name: app-1
  labels:
    name: app-1
spec:
  containers:
    env:
    - name: http_proxy
      value: http://egress-1:8080/ 
    - name: https_proxy
      value: http://egress-1:8080/
    ...

apiVersion: v1
kind: Pod
metadata:
  name: app-1
  labels:
    name: app-1
spec:
  containers:
    env:
    - name: http_proxy
      value: http://egress-1:8080/

1


    - name: https_proxy
      value: http://egress-1:8080/
    ...

Copy to Clipboard

Toggle word wrap

1: Le service créé à l'étape précédente.

Note

L'utilisation des variables d'environnement http_proxy et https_proxy n'est pas nécessaire pour toutes les configurations. Si vous ne parvenez pas à créer une configuration fonctionnelle, consultez la documentation de l'outil ou du logiciel que vous utilisez dans le module.

25.10. Déploiement d'un pod routeur egress en mode proxy DNS
Copier lien

En tant qu'administrateur de cluster, vous pouvez déployer un pod routeur de sortie configuré pour acheminer le trafic vers des noms DNS et des adresses IP spécifiques.

25.10.1. Spécification du pod du routeur de sortie pour le mode DNS
Copier lien

Définir la configuration d'un module de routeur de sortie dans l'objet Pod. Le fichier YAML suivant décrit les champs pour la configuration d'un module de routeur de sortie en mode DNS :

apiVersion: v1
kind: Pod
metadata:
  name: egress-1
  labels:
    name: egress-1
  annotations:
    pod.network.openshift.io/assign-macvlan: "true" 
spec:
  initContainers:
  - name: egress-router
    image: registry.redhat.io/openshift4/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE 
      value: <egress-router>
    - name: EGRESS_GATEWAY 
      value: <egress-gateway>
    - name: EGRESS_ROUTER_MODE
      value: dns-proxy
  containers:
  - name: egress-router-pod
    image: registry.redhat.io/openshift4/ose-egress-dns-proxy
    securityContext:
      privileged: true
    env:
    - name: EGRESS_DNS_PROXY_DESTINATION 
      value: |-
        ...
    - name: EGRESS_DNS_PROXY_DEBUG 
      value: "1"
    ...

apiVersion: v1
kind: Pod
metadata:
  name: egress-1
  labels:
    name: egress-1
  annotations:
    pod.network.openshift.io/assign-macvlan: "true"

1


spec:
  initContainers:
  - name: egress-router
    image: registry.redhat.io/openshift4/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE

2


      value: <egress-router>
    - name: EGRESS_GATEWAY

3


      value: <egress-gateway>
    - name: EGRESS_ROUTER_MODE
      value: dns-proxy
  containers:
  - name: egress-router-pod
    image: registry.redhat.io/openshift4/ose-egress-dns-proxy
    securityContext:
      privileged: true
    env:
    - name: EGRESS_DNS_PROXY_DESTINATION

4


      value: |-
        ...
    - name: EGRESS_DNS_PROXY_DEBUG

5


      value: "1"
    ...

Copy to Clipboard

Toggle word wrap

1: L'annotation indique à OpenShift Container Platform de créer une interface réseau macvlan sur le contrôleur d'interface réseau (NIC) primaire et de déplacer cette interface macvlan dans l'espace de noms réseau du pod. Vous devez inclure les guillemets autour de la valeur "true". Pour qu'OpenShift Container Platform crée l'interface macvlan sur une interface NIC différente, définissez la valeur d'annotation au nom de cette interface. Par exemple, eth1.
2: Adresse IP du réseau physique sur lequel se trouve le nœud, réservée à l'usage du routeur de sortie. Facultatif : vous pouvez inclure la longueur du sous-réseau, le suffixe /24, afin qu'une route appropriée vers le sous-réseau local soit définie. Si vous ne spécifiez pas de longueur de sous-réseau, le routeur de sortie ne peut accéder qu'à l'hôte spécifié par la variable EGRESS_GATEWAY et à aucun autre hôte du sous-réseau.
3: Même valeur que la passerelle par défaut utilisée par le nœud.
4: Spécifiez une liste d'une ou plusieurs destinations proxy.
5: En option, spécifiez la sortie du journal du proxy DNS vers : Spécifiez la sortie du journal du proxy DNS sur stdout.

25.10.2. Format de configuration de la destination de sortie
Copier lien

Lorsque le routeur est déployé en mode proxy DNS, vous spécifiez une liste de mappages de ports et de destinations. Une destination peut être une adresse IP ou un nom DNS.

Un pod de routeur de sortie prend en charge les formats suivants pour spécifier les mappages de port et de destination :

Port et adresse distante: Vous pouvez spécifier un port source et un hôte de destination en utilisant le format à deux champs : <port> <remote_address>.

L'hôte peut être une adresse IP ou un nom DNS. Si un nom DNS est fourni, la résolution DNS se fait au moment de l'exécution. Pour un hôte donné, le proxy se connecte au port source spécifié sur l'hôte de destination lorsqu'il se connecte à l'adresse IP de l'hôte de destination.

Exemple de paire de ports et d'adresses distantes

80 172.16.12.11
100 example.com

80 172.16.12.11
100 example.com

Copy to Clipboard

Toggle word wrap

Port, adresse distante et port distant: Vous pouvez spécifier un port source, un hôte de destination et un port de destination en utilisant le format à trois champs : <port> <remote_address> <remote_port>.

Le format à trois champs se comporte de la même manière que la version à deux champs, à l'exception du fait que le port de destination peut être différent du port source.

Exemple de port, d'adresse distante et de port distant

8080 192.168.60.252 80
8443 web.example.com 443

8080 192.168.60.252 80
8443 web.example.com 443

Copy to Clipboard

Toggle word wrap

25.10.3. Déploiement d'un pod routeur egress en mode proxy DNS
Copier lien

En DNS proxy modeun pod routeur de sortie agit comme un proxy DNS pour les services basés sur TCP de sa propre adresse IP vers une ou plusieurs adresses IP de destination.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créer un module de routeur de sortie.

Créer un service pour le pod du routeur de sortie :

Créez un fichier nommé egress-router-service.yaml qui contient le YAML suivant. Attribuez à spec.ports la liste des ports que vous avez définie précédemment pour la variable d'environnement EGRESS_DNS_PROXY_DESTINATION.

apiVersion: v1
kind: Service
metadata:
  name: egress-dns-svc
spec:
  ports:
    ...
  type: ClusterIP
  selector:
    name: egress-dns-proxy

apiVersion: v1
kind: Service
metadata:
  name: egress-dns-svc
spec:
  ports:
    ...
  type: ClusterIP
  selector:
    name: egress-dns-proxy

Copy to Clipboard

Toggle word wrap

Par exemple :

apiVersion: v1
kind: Service
metadata:
  name: egress-dns-svc
spec:
  ports:
  - name: con1
    protocol: TCP
    port: 80
    targetPort: 80
  - name: con2
    protocol: TCP
    port: 100
    targetPort: 100
  type: ClusterIP
  selector:
    name: egress-dns-proxy

apiVersion: v1
kind: Service
metadata:
  name: egress-dns-svc
spec:
  ports:
  - name: con1
    protocol: TCP
    port: 80
    targetPort: 80
  - name: con2
    protocol: TCP
    port: 100
    targetPort: 100
  type: ClusterIP
  selector:
    name: egress-dns-proxy

Copy to Clipboard

Toggle word wrap

Pour créer le service, entrez la commande suivante :
```
oc create -f egress-router-service.yaml
```
```
$ oc create -f egress-router-service.yaml
```
Copy to Clipboard Toggle word wrap
Les pods peuvent maintenant se connecter à ce service. Les connexions sont dirigées vers les ports correspondants du serveur externe, en utilisant l'adresse IP de sortie réservée.

25.11. Configuration d'une liste de destination de pods de routeur de sortie à partir d'une carte de configuration
Copier lien

En tant qu'administrateur de cluster, vous pouvez définir un objet ConfigMap qui spécifie les mappages de destination pour un module de routeur de sortie. Le format spécifique de la configuration dépend du type de module de routeur de sortie. Pour plus de détails sur le format, reportez-vous à la documentation du module de routeur de sortie spécifique.

25.11.1. Configuration des mappages de destination d'un routeur de sortie à l'aide d'une carte de configuration
Copier lien

Pour un ensemble de mappages de destination important ou changeant fréquemment, vous pouvez utiliser une carte de configuration pour gérer la liste de manière externe. L'avantage de cette approche est que l'autorisation de modifier la carte de configuration peut être déléguée à des utilisateurs ne disposant pas des privilèges cluster-admin. Le pod de routeur de sortie nécessitant un conteneur privilégié, les utilisateurs ne disposant pas des privilèges cluster-admin ne peuvent pas modifier directement la définition du pod.

Note

Le module de routeur de sortie n'est pas automatiquement mis à jour lorsque la carte de configuration est modifiée. Vous devez redémarrer le module de routeur de sortie pour obtenir les mises à jour.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créez un fichier contenant les données de mappage pour le pod du routeur de sortie, comme dans l'exemple suivant :

# Egress routes for Project "Test", version 3

80   tcp 203.0.113.25

8080 tcp 203.0.113.26 80
8443 tcp 203.0.113.26 443

# Fallback
203.0.113.27

# Egress routes for Project "Test", version 3

80   tcp 203.0.113.25

8080 tcp 203.0.113.26 80
8443 tcp 203.0.113.26 443

# Fallback
203.0.113.27

Copy to Clipboard

Toggle word wrap

Vous pouvez insérer des lignes vierges et des commentaires dans ce fichier.

Créer un objet ConfigMap à partir du fichier :

oc delete configmap egress-routes --ignore-not-found

$ oc delete configmap egress-routes --ignore-not-found

Copy to Clipboard

Toggle word wrap

oc create configmap egress-routes \
  --from-file=destination=my-egress-destination.txt

$ oc create configmap egress-routes \
  --from-file=destination=my-egress-destination.txt

Copy to Clipboard

Toggle word wrap

Dans la commande précédente, la valeur egress-routes est le nom de l'objet ConfigMap à créer et my-egress-destination.txt est le nom du fichier à partir duquel les données sont lues.

Astuce

Vous pouvez également appliquer le YAML suivant pour créer la carte de configuration :

apiVersion: v1
kind: ConfigMap
metadata:
  name: egress-routes
data:
  destination: |
    # Egress routes for Project "Test", version 3

    80   tcp 203.0.113.25

    8080 tcp 203.0.113.26 80
    8443 tcp 203.0.113.26 443

    # Fallback
    203.0.113.27

apiVersion: v1
kind: ConfigMap
metadata:
  name: egress-routes
data:
  destination: |
    # Egress routes for Project "Test", version 3

    80   tcp 203.0.113.25

    8080 tcp 203.0.113.26 80
    8443 tcp 203.0.113.26 443

    # Fallback
    203.0.113.27

Copy to Clipboard

Toggle word wrap

Créez une définition de pod de routeur de sortie et spécifiez la strophe configMapKeyRef pour le champ EGRESS_DESTINATION dans la strophe d'environnement :

...
env:
- name: EGRESS_DESTINATION
  valueFrom:
    configMapKeyRef:
      name: egress-routes
      key: destination
...

...
env:
- name: EGRESS_DESTINATION
  valueFrom:
    configMapKeyRef:
      name: egress-routes
      key: destination
...

Copy to Clipboard

Toggle word wrap

25.12. Activation de la multidiffusion pour un projet
Copier lien

25.12.1. À propos de la multidiffusion
Copier lien

Avec la multidiffusion IP, les données sont diffusées simultanément à de nombreuses adresses IP.

Important

À l'heure actuelle, le multicast est utilisé de préférence pour la coordination ou la découverte de services à faible bande passante et non comme une solution à large bande passante.

Le trafic multicast entre les pods de OpenShift Container Platform est désactivé par défaut. Si vous utilisez le plugin réseau OpenShift SDN, vous pouvez activer le multicast par projet.

Lors de l'utilisation du plugin réseau OpenShift SDN en mode d'isolation networkpolicy:

Les paquets de multidiffusion envoyés par un pod seront distribués à tous les autres pods du projet, indépendamment des objets NetworkPolicy. Les modules peuvent être en mesure de communiquer par multidiffusion même s'ils ne peuvent pas communiquer par monodiffusion.
Les paquets de multidiffusion envoyés par un pod dans un projet ne seront jamais transmis aux pods d'un autre projet, même s'il existe des objets NetworkPolicy qui permettent la communication entre les projets.

Lors de l'utilisation du plugin réseau OpenShift SDN en mode d'isolation multitenant:

Les paquets de multidiffusion envoyés par un pod seront distribués à tous les autres pods du projet.
Les paquets multicast envoyés par un pod dans un projet seront délivrés aux pods dans d'autres projets seulement si chaque projet est joint et que le multicast est activé dans chaque projet joint.

25.12.2. Activation de la multidiffusion entre les pods
Copier lien

Vous pouvez activer le multicast entre les pods de votre projet.

Conditions préalables

Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster avec un utilisateur ayant le rôle cluster-admin.

Procédure

Exécutez la commande suivante pour activer la multidiffusion pour un projet. Remplacez <namespace> par l'espace de noms du projet pour lequel vous souhaitez activer la multidiffusion.
```
oc annotate netnamespace <namespace> \
    netnamespace.network.openshift.io/multicast-enabled=true
```
```
$ oc annotate netnamespace <namespace> \
    netnamespace.network.openshift.io/multicast-enabled=true
```
Copy to Clipboard Toggle word wrap

Vérification

Pour vérifier que la multidiffusion est activée pour un projet, suivez la procédure suivante :

Remplacez votre projet actuel par le projet pour lequel vous avez activé la multidiffusion. Remplacez <project> par le nom du projet.
```
oc project <projet>
```
```
$ oc project <projet>
```
Copy to Clipboard Toggle word wrap

Créez un pod qui servira de récepteur multicast :

cat <<EOF| oc create -f -
apiVersion: v1
kind: Pod
metadata:
  name: mlistener
  labels:
    app: multicast-verify
spec:
  containers:
    - name: mlistener
      image: registry.access.redhat.com/ubi8
      command: ["/bin/sh", "-c"]
      args:
        ["dnf -y install socat hostname && sleep inf"]
      ports:
        - containerPort: 30102
          name: mlistener
          protocol: UDP
EOF

$ cat <<EOF| oc create -f -
apiVersion: v1
kind: Pod
metadata:
  name: mlistener
  labels:
    app: multicast-verify
spec:
  containers:
    - name: mlistener
      image: registry.access.redhat.com/ubi8
      command: ["/bin/sh", "-c"]
      args:
        ["dnf -y install socat hostname && sleep inf"]
      ports:
        - containerPort: 30102
          name: mlistener
          protocol: UDP
EOF

Copy to Clipboard

Toggle word wrap

Créez un pod qui servira d'émetteur multicast :

cat <<EOF| oc create -f -
apiVersion: v1
kind: Pod
metadata:
  name: msender
  labels:
    app: multicast-verify
spec:
  containers:
    - name: msender
      image: registry.access.redhat.com/ubi8
      command: ["/bin/sh", "-c"]
      args:
        ["dnf -y install socat && sleep inf"]
EOF

$ cat <<EOF| oc create -f -
apiVersion: v1
kind: Pod
metadata:
  name: msender
  labels:
    app: multicast-verify
spec:
  containers:
    - name: msender
      image: registry.access.redhat.com/ubi8
      command: ["/bin/sh", "-c"]
      args:
        ["dnf -y install socat && sleep inf"]
EOF

Copy to Clipboard

Toggle word wrap

Dans une nouvelle fenêtre ou un nouvel onglet de terminal, démarrez l'auditeur de multidiffusion.

Obtenir l'adresse IP du pod :

POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')

$ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')

Copy to Clipboard

Toggle word wrap

Démarrez l'auditeur de multidiffusion en entrant la commande suivante :

oc exec mlistener -i -t -- \
    socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname

$ oc exec mlistener -i -t -- \
    socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname

Copy to Clipboard

Toggle word wrap

Démarrer l'émetteur de multidiffusion.

Obtenir la plage d'adresses IP du réseau de pods :

CIDR=$(oc get Network.config.openshift.io cluster \
    -o jsonpath='{.status.clusterNetwork[0].cidr}')

$ CIDR=$(oc get Network.config.openshift.io cluster \
    -o jsonpath='{.status.clusterNetwork[0].cidr}')

Copy to Clipboard

Toggle word wrap

Pour envoyer un message multicast, entrez la commande suivante :

oc exec msender -i -t -- \
    /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"

$ oc exec msender -i -t -- \
    /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"

Copy to Clipboard

Toggle word wrap

Si la multidiffusion fonctionne, la commande précédente renvoie le résultat suivant :

mlistener

mlistener

Copy to Clipboard

Toggle word wrap

25.13. Désactiver la multidiffusion pour un projet
Copier lien

25.13.1. Désactivation de la multidiffusion entre les pods
Copier lien

Vous pouvez désactiver le multicast entre les pods de votre projet.

Conditions préalables

Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster avec un utilisateur ayant le rôle cluster-admin.

Procédure

Désactivez la multidiffusion en exécutant la commande suivante :
```
oc annotate netnamespace <namespace> \
    netnamespace.network.openshift.io/multicast-enabled-
```
```
$ oc annotate netnamespace <namespace> \ 
```
1
```
    netnamespace.network.openshift.io/multicast-enabled-
```
Copy to Clipboard Toggle word wrap
1
Le site namespace du projet pour lequel vous souhaitez désactiver la multidiffusion.

25.14. Configurer l'isolation du réseau à l'aide d'OpenShift SDN
Copier lien

Lorsque votre cluster est configuré pour utiliser le mode d'isolation multitenant pour le plugin réseau OpenShift SDN, chaque projet est isolé par défaut. Le trafic réseau n'est pas autorisé entre les pods ou les services de différents projets en mode d'isolation multitenant.

Vous pouvez modifier le comportement de l'isolation multitenant pour un projet de deux manières :

Vous pouvez rejoindre un ou plusieurs projets, ce qui permet le trafic réseau entre les pods et les services de différents projets.
Vous pouvez désactiver l'isolation du réseau pour un projet. Il sera globalement accessible et acceptera le trafic réseau des pods et des services de tous les autres projets. Un projet globalement accessible peut accéder aux pods et aux services de tous les autres projets.

25.14.1. Conditions préalables
Copier lien

Vous devez avoir un cluster configuré pour utiliser le plugin réseau OpenShift SDN en mode d'isolation multitenant.

25.14.2. Rejoindre des projets
Copier lien

Vous pouvez joindre deux projets ou plus pour permettre le trafic réseau entre les pods et les services dans différents projets.

Conditions préalables

Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster avec un utilisateur ayant le rôle cluster-admin.

Procédure

Utilisez la commande suivante pour joindre des projets à un réseau de projets existant :
```
oc adm pod-network join-projects --to=<projet1> <projet2> <projet3>
```
```
$ oc adm pod-network join-projects --to=<projet1> <projet2> <projet3>
```
Copy to Clipboard Toggle word wrap
Au lieu de spécifier des noms de projets spécifiques, vous pouvez utiliser l'option --selector=<project_selector> pour spécifier des projets sur la base d'une étiquette associée.
Facultatif : Exécutez la commande suivante pour afficher les réseaux de pods que vous avez réunis :
```
oc get netnamespaces
```
```
$ oc get netnamespaces
```
Copy to Clipboard Toggle word wrap
Les projets du même réseau de pods ont le même ID de réseau dans la colonne NETID dans la colonne

25.14.3. Isoler un projet
Copier lien

Vous pouvez isoler un projet de sorte que les pods et les services d'autres projets ne puissent pas accéder à ses pods et à ses services.

Conditions préalables

Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster avec un utilisateur ayant le rôle cluster-admin.

Procédure

Pour isoler les projets dans le cluster, exécutez la commande suivante :
```
oc adm pod-network isolate-projects <projet1> <projet2> $ oc adm pod-network isolate-projects <projet2>
```
```
oc adm pod-network isolate-projects <projet1> <projet2> $ oc adm pod-network isolate-projects <projet2>
```
Copy to Clipboard Toggle word wrap
Au lieu de spécifier des noms de projets spécifiques, vous pouvez utiliser l'option --selector=<project_selector> pour spécifier des projets sur la base d'une étiquette associée.

25.14.4. Désactiver l'isolation du réseau pour un projet
Copier lien

Vous pouvez désactiver l'isolation du réseau pour un projet.

Conditions préalables

Installez le CLI OpenShift (oc).
Vous devez vous connecter au cluster avec un utilisateur ayant le rôle cluster-admin.

Procédure

Exécutez la commande suivante pour le projet :
```
oc adm pod-network make-projects-global <projet1> <projet2> $ oc adm pod-network make-projects-global <projet2>
```
```
oc adm pod-network make-projects-global <projet1> <projet2> $ oc adm pod-network make-projects-global <projet2>
```
Copy to Clipboard Toggle word wrap
Au lieu de spécifier des noms de projets spécifiques, vous pouvez utiliser l'option --selector=<project_selector> pour spécifier des projets sur la base d'une étiquette associée.

25.15. Configuration de kube-proxy
Copier lien

Le proxy réseau Kubernetes (kube-proxy) s'exécute sur chaque nœud et est géré par le Cluster Network Operator (CNO). kube-proxy maintient les règles réseau pour transférer les connexions pour les points d'extrémité associés aux services.

25.15.1. À propos de la synchronisation des règles d'iptables
Copier lien

La période de synchronisation détermine la fréquence à laquelle le proxy réseau Kubernetes (kube-proxy) synchronise les règles iptables sur un nœud.

Une synchronisation commence lorsque l'un des événements suivants se produit :

Un événement se produit, tel que l'ajout ou la suppression d'un service ou d'un point d'extrémité dans le cluster.
Le temps écoulé depuis la dernière synchronisation dépasse la période de synchronisation définie pour kube-proxy.

25.15.2. paramètres de configuration de kube-proxy
Copier lien

Vous pouvez modifier les paramètres suivants kubeProxyConfig.

Note

En raison des améliorations de performance introduites dans OpenShift Container Platform 4.3 et plus, l'ajustement du paramètre iptablesSyncPeriod n'est plus nécessaire.

Expand

Tableau 25.2. Parameters
Paramètres	Description	Valeurs	Défaut
`iptablesSyncPeriod`	La période de rafraîchissement des règles `iptables`.	Un intervalle de temps, tel que `30s` ou `2m`. Les suffixes valides incluent `s`, `m`, et `h` et sont décrits dans la documentation du paquet Go time.	`30s`
`proxyArguments.iptables-min-sync-period`	Durée minimale avant l'actualisation des règles `iptables`. Ce paramètre permet de s'assurer que l'actualisation n'est pas trop fréquente. Par défaut, l'actualisation commence dès qu'une modification affectant les règles `iptables` se produit.	Un intervalle de temps, tel que `30s` ou `2m`. Les suffixes valides comprennent `s`, `m` et `h` et sont décrits dans le paquet Go time	`0s`

25.15.3. Modifier la configuration de kube-proxy
Copier lien

Vous pouvez modifier la configuration du proxy réseau Kubernetes pour votre cluster.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous à un cluster en cours d'exécution avec le rôle cluster-admin.

Procédure

Modifiez la ressource personnalisée (CR) Network.operator.openshift.io en exécutant la commande suivante :
```
oc edit network.operator.openshift.io cluster
```
```
$ oc edit network.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap

Modifiez le paramètre kubeProxyConfig dans le CR avec les changements apportés à la configuration de kube-proxy, comme dans l'exemple de CR suivant :

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  kubeProxyConfig:
    iptablesSyncPeriod: 30s
    proxyArguments:
      iptables-min-sync-period: ["30s"]

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  kubeProxyConfig:
    iptablesSyncPeriod: 30s
    proxyArguments:
      iptables-min-sync-period: ["30s"]

Copy to Clipboard

Toggle word wrap

Enregistrez le fichier et quittez l'éditeur de texte.
La syntaxe est validée par la commande oc lorsque vous enregistrez le fichier et quittez l'éditeur. Si vos modifications contiennent une erreur de syntaxe, l'éditeur ouvre le fichier et affiche un message d'erreur.

Entrez la commande suivante pour confirmer la mise à jour de la configuration :

oc get networks.operator.openshift.io -o yaml

$ oc get networks.operator.openshift.io -o yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: Network
  metadata:
    name: cluster
  spec:
    clusterNetwork:
    - cidr: 10.128.0.0/14
      hostPrefix: 23
    defaultNetwork:
      type: OpenShiftSDN
    kubeProxyConfig:
      iptablesSyncPeriod: 30s
      proxyArguments:
        iptables-min-sync-period:
        - 30s
    serviceNetwork:
    - 172.30.0.0/16
  status: {}
kind: List

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: Network
  metadata:
    name: cluster
  spec:
    clusterNetwork:
    - cidr: 10.128.0.0/14
      hostPrefix: 23
    defaultNetwork:
      type: OpenShiftSDN
    kubeProxyConfig:
      iptablesSyncPeriod: 30s
      proxyArguments:
        iptables-min-sync-period:
        - 30s
    serviceNetwork:
    - 172.30.0.0/16
  status: {}
kind: List

Copy to Clipboard

Toggle word wrap

En option : Entrez la commande suivante pour confirmer que l'opérateur du réseau de clusters a accepté la modification de la configuration :
```
oc get clusteroperator network
```
```
$ oc get clusteroperator network
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
network   4.1.0-0.9   True        False         False      1m
```
```
NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
network   4.1.0-0.9   True        False         False      1m
```
Copy to Clipboard Toggle word wrap
Le champ AVAILABLE est True lorsque la mise à jour de la configuration est appliquée avec succès.

Chapitre 26. Configuration des itinéraires
Copier lien

26.1. Configuration des itinéraires
Copier lien

26.1.1. Création d'un itinéraire basé sur HTTP
Copier lien

Une route vous permet d'héberger votre application à une URL publique. Elle peut être sécurisée ou non, en fonction de la configuration de sécurité du réseau de votre application. Une route basée sur HTTP est une route non sécurisée qui utilise le protocole de routage HTTP de base et expose un service sur un port d'application non sécurisé.

La procédure suivante décrit comment créer une route simple basée sur le protocole HTTP vers une application web, en utilisant l'application hello-openshift comme exemple.

Conditions préalables

Vous avez installé l'OpenShift CLI (oc).
Vous êtes connecté en tant qu'administrateur.
Vous avez une application web qui expose un port et un point de terminaison TCP qui écoute le trafic sur le port.

Procédure

Créez un projet appelé hello-openshift en exécutant la commande suivante :
```
oc new-project hello-openshift
```
```
$ oc new-project hello-openshift
```
Copy to Clipboard Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

Créez un service appelé hello-openshift en exécutant la commande suivante :
```
oc expose pod/hello-openshift
```
```
$ oc expose pod/hello-openshift
```
Copy to Clipboard Toggle word wrap
Créez une route non sécurisée vers l'application hello-openshift en exécutant la commande suivante :
```
oc expose svc hello-openshift
```
```
$ oc expose svc hello-openshift
```
Copy to Clipboard Toggle word wrap

Vérification

Pour vérifier que la ressource route que vous avez créée fonctionne, exécutez la commande suivante :
```
oc get routes -o yaml <name of resource>
```
```
$ oc get routes -o yaml <name of resource> 
```
1
Copy to Clipboard Toggle word wrap
1
Dans cet exemple, la route est nommée hello-openshift.

Exemple de définition YAML de la route non sécurisée créée :

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: hello-openshift
spec:
  host: hello-openshift-hello-openshift.<Ingress_Domain> 
  port:
    targetPort: 8080 
  to:
    kind: Service
    name: hello-openshift

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: hello-openshift
spec:
  host: hello-openshift-hello-openshift.<Ingress_Domain>

1


  port:
    targetPort: 8080

2


  to:
    kind: Service
    name: hello-openshift

Copy to Clipboard

Toggle word wrap

<Ingress_Domain> est le nom de domaine d'entrée par défaut. L'objet ingresses.config/cluster est créé lors de l'installation et ne peut pas être modifié. Si vous souhaitez spécifier un domaine différent, vous pouvez spécifier un autre domaine de cluster à l'aide de l'option appsDomain.