Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

8.10. Configuration du réseau RHOSP après l'installation

download PDF

Vous pouvez configurer certains aspects d'un cluster OpenShift Container Platform on Red Hat OpenStack Platform (RHOSP) après l'installation.

8.10.1. Configuration de l'accès aux applications avec des adresses IP flottantes

Après avoir installé OpenShift Container Platform, configurez Red Hat OpenStack Platform (RHOSP) pour autoriser le trafic réseau des applications.

Note

Vous n'avez pas besoin d'effectuer cette procédure si vous avez fourni des valeurs pour platform.openstack.apiFloatingIP et platform.openstack.ingressFloatingIP dans le fichier install-config.yaml, ou os_api_fip et os_ingress_fip dans le playbook inventory.yaml, lors de l'installation. Les adresses IP flottantes sont déjà définies.

Conditions préalables

  • Le cluster OpenShift Container Platform doit être installé
  • Les adresses IP flottantes sont activées comme décrit dans la documentation d'installation d'OpenShift Container Platform on RHOSP.

Procédure

Après avoir installé le cluster OpenShift Container Platform, attachez une adresse IP flottante au port d'entrée :

  1. Afficher le port : 

    openstack port show <cluster_name>-<cluster_ID>-ingress-port

  2. Attachez le port à l'adresse IP : 

    $ openstack floating ip set --port <ingress_port_ID> <apps_FIP>

  3. Ajoutez un enregistrement A pour *apps. à votre fichier DNS : 

    *.apps.<cluster_name>.<base_domain>  IN  A  <apps_FIP>
Note

Si vous ne contrôlez pas le serveur DNS mais que vous souhaitez autoriser l'accès à l'application à des fins de non-production, vous pouvez ajouter ces noms d'hôtes à /etc/hosts: 

<apps_FIP> console-openshift-console.apps.<cluster name>.<base domain>
<apps_FIP> integrated-oauth-server-openshift-authentication.apps.<cluster name>.<base domain>
<apps_FIP> oauth-openshift.apps.<cluster name>.<base domain>
<apps_FIP> prometheus-k8s-openshift-monitoring.apps.<cluster name>.<base domain>
<apps_FIP> <app name>.apps.<cluster name>.<base domain>

8.10.2. Kuryr ports pools

A Kuryr ports pool maintains a number of ports on standby for pod creation.

Keeping ports on standby minimizes pod creation time. Without ports pools, Kuryr must explicitly request port creation or deletion whenever a pod is created or deleted.

The Neutron ports that Kuryr uses are created in subnets that are tied to namespaces. These pod ports are also added as subports to the primary port of OpenShift Container Platform cluster nodes.

Because Kuryr keeps each namespace in a separate subnet, a separate ports pool is maintained for each namespace-worker pair.

Prior to installing a cluster, you can set the following parameters in the cluster-network-03-config.yml manifest file to configure ports pool behavior:

  • The enablePortPoolsPrepopulation parameter controls pool prepopulation, which forces Kuryr to add Neutron ports to the pools when the first pod that is configured to use the dedicated network for pods is created in a namespace. The default value is false.
  • The poolMinPorts parameter is the minimum number of free ports that are kept in the pool. The default value is 1.

  • The poolMaxPorts parameter is the maximum number of free ports that are kept in the pool. A value of 0 disables that upper bound. This is the default setting.

    If your OpenStack port quota is low, or you have a limited number of IP addresses on the pod network, consider setting this option to ensure that unneeded ports are deleted.

  • The poolBatchPorts parameter defines the maximum number of Neutron ports that can be created at once. The default value is 3.

8.10.3. Ajustement des paramètres du pool de ports Kuryr dans les déploiements actifs sur RHOSP

Vous pouvez utiliser une ressource personnalisée (CR) pour configurer la façon dont Kuryr gère les ports Neutron de Red Hat OpenStack Platform (RHOSP) afin de contrôler la vitesse et l'efficacité de la création de pods sur un cluster déployé.

Procédure

  1. À partir d'une ligne de commande, ouvrez le CR Cluster Network Operator (CNO) pour l'éditer : 

    $ oc edit networks.operator.openshift.io cluster

  2. Edit the settings to meet your requirements. The following file is provided as an example: 

    apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork:
  - 172.30.0.0/16
  defaultNetwork:
    type: Kuryr
    kuryrConfig:
      enablePortPoolsPrepopulation: false 1
      poolMinPorts: 1 2
      poolBatchPorts: 3 3
      poolMaxPorts: 5 4
    1
    Définissez enablePortPoolsPrepopulation à true pour que Kuryr crée des ports Neutron lorsque le premier pod configuré pour utiliser le réseau dédié aux pods est créé dans un espace de noms. Ce paramètre augmente le quota de ports Neutron mais peut réduire le temps nécessaire à la création de pods. La valeur par défaut est false.
    2
    Kuryr creates new ports for a pool if the number of free ports in that pool is lower than the value of poolMinPorts. The default value is 1.
    3
    poolBatchPorts controls the number of new ports that are created if the number of free ports is lower than the value of poolMinPorts. The default value is 3.
    4
    Si le nombre de ports libres dans un pool est supérieur à la valeur de poolMaxPorts, Kuryr les supprime jusqu'à ce que leur nombre corresponde à cette valeur. La valeur 0 désactive cette limite supérieure, ce qui empêche les pools de se réduire. La valeur par défaut est 0.
  3. Enregistrez vos modifications et quittez l'éditeur de texte pour valider vos modifications.
Important

La modification de ces options sur un cluster en fonctionnement oblige les pods kuryr-controller et kuryr-cni à redémarrer. Par conséquent, la création de nouveaux pods et services sera retardée.

8.10.4. Activation du délestage du matériel OVS

Pour les clusters qui s'exécutent sur Red Hat OpenStack Platform (RHOSP), vous pouvez activer le déchargement matériel d'Open vSwitch (OVS).

OVS est un commutateur virtuel multicouche qui permet la virtualisation de réseaux multiserveurs à grande échelle.

Conditions préalables

  • Vous avez installé un cluster sur RHOSP qui est configuré pour la virtualisation des entrées/sorties à racine unique (SR-IOV).
  • Vous avez installé l'opérateur de réseau SR-IOV sur votre cluster.
  • Vous avez créé deux interfaces de fonction virtuelle (VF) de type hw-offload sur votre cluster.

Procédure

  1. Créez une politique SriovNetworkNodePolicy pour les deux interfaces hw-offload type VF qui se trouvent sur votre cluster :

    La première interface de fonction virtuelle

    apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy 1
metadata:
  name: "hwoffload9"
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  nicSelector:
    pfNames: 2
    - ens6
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: 'true'
  numVfs: 1
  priority: 99
  resourceName: "hwoffload9"

    1
    Insérer la valeur SriovNetworkNodePolicy ici.
    2
    Les deux interfaces doivent inclure des noms de fonctions physiques (PF).

    La deuxième interface de fonction virtuelle

    apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy 1
metadata:
  name: "hwoffload10"
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  nicSelector:
    pfNames: 2
    - ens5
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: 'true'
  numVfs: 1
  priority: 99
  resourceName: "hwoffload10"

    1
    Insérer la valeur SriovNetworkNodePolicy ici.
    2
    Les deux interfaces doivent inclure des noms de fonctions physiques (PF).

  2. Créer des ressources NetworkAttachmentDefinition pour les deux interfaces :

    Une ressource NetworkAttachmentDefinition pour la première interface

    apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload9
  name: hwoffload9
  namespace: default
spec:
    config: '{ "cniVersion":"0.3.1", "name":"hwoffload9","type":"host-device","device":"ens6"
    }'

    Une ressource NetworkAttachmentDefinition pour la deuxième interface

    apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload10
  name: hwoffload10
  namespace: default
spec:
    config: '{ "cniVersion":"0.3.1", "name":"hwoffload10","type":"host-device","device":"ens5"
    }'

  3. Utilisez les interfaces que vous avez créées avec un pod. Par exemple :

    Un pod qui utilise les deux interfaces de déchargement OVS

    apiVersion: v1
kind: Pod
metadata:
  name: dpdk-testpmd
  namespace: default
  annotations:
    irq-load-balancing.crio.io: disable
    cpu-quota.crio.io: disable
    k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload9
    k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload10
spec:
  restartPolicy: Never
  containers:
  - name: dpdk-testpmd
    image: quay.io/krister/centos8_nfv-container-dpdk-testpmd:latest

8.10.5. Attachement d'un réseau de délestage matériel OVS

Vous pouvez attacher un réseau de déchargement matériel Open vSwitch (OVS) à votre cluster.

Conditions préalables

  • Votre cluster est installé et fonctionne.
  • Vous avez provisionné un réseau de déchargement matériel OVS sur Red Hat OpenStack Platform (RHOSP) pour l'utiliser avec votre cluster.

Procédure

  1. Créez un fichier nommé network.yaml à partir du modèle suivant : 

    spec:
  additionalNetworks:
  - name: hwoffload1
    namespace: cnf
    rawCNIConfig: '{ "cniVersion": "0.3.1", "name": "hwoffload1", "type": "host-device","pciBusId": "0000:00:05.0", "ipam": {}}' 1
    type: Raw

    où :

    pciBusId

    Spécifie l'appareil connecté au réseau de délestage. Si vous ne l'avez pas, vous pouvez trouver cette valeur en exécutant la commande suivante : 

    $ oc describe SriovNetworkNodeState -n openshift-sriov-network-operator

  2. A partir d'une ligne de commande, entrez la commande suivante pour patcher votre cluster avec le fichier : 

    $ oc apply -f network.yaml

8.10.6. Activation de la connectivité IPv6 aux pods sur RHOSP

Pour permettre la connectivité IPv6 entre les modules qui ont des réseaux supplémentaires sur des nœuds différents, désactivez la sécurité des ports pour le port IPv6 du serveur. La désactivation de la sécurité des ports évite de devoir créer des paires d'adresses autorisées pour chaque adresse IPv6 attribuée aux modules et permet le trafic sur le groupe de sécurité.

Important

Seules les configurations réseau supplémentaires IPv6 suivantes sont prises en charge :

  • SLAAC et dispositif hôte
  • SLAAC et MACVLAN
  • DHCP stateless et host-device
  • DHCP sans état et MACVLAN

Procédure

  • Sur une ligne de commande, entrez la commande suivante : 

    openstack port set --no-security-group --disable-port-security <compute_ipv6_port>
    Important

    Cette commande supprime les groupes de sécurité du port et désactive la sécurité du port. Les restrictions de trafic sont entièrement supprimées du port.

où :

<compute_ipv6_port>
Spécifie le port IPv6 du serveur de calcul.

8.10.7. Ajouter la connectivité IPv6 aux pods sur RHOSP

Après avoir activé la connectivité IPv6 dans les pods, ajoutez-y une connectivité en utilisant une configuration CNI (Container Network Interface).

Procédure

  1. Pour modifier l'opérateur de réseau de cluster (CNO), entrez la commande suivante : 

    $ oc edit networks.operator.openshift.io cluster

  2. Spécifiez votre configuration CNI dans le champ spec. Par exemple, la configuration suivante utilise un mode d'adresse SLAAC avec MACVLAN : 

    ...
spec:
  additionalNetworks:
  - name: ipv6
    namespace: ipv6 1
    rawCNIConfig: '{ "cniVersion": "0.3.1", "name": "ipv6", "type": "macvlan", "master": "ens4"}' 2
    type: Raw
    1 1
    Veillez à créer des pods dans le même espace de noms.
    2
    L'interface dans le champ de l'attachement au réseau "master" peut différer de "ens4" lorsque plusieurs réseaux sont configurés ou lorsqu'un pilote de noyau différent est utilisé.
    Note

    Si vous utilisez le mode d'adressage avec état, incluez la gestion des adresses IP (IPAM) dans la configuration de CNI.

    DHCPv6 n'est pas pris en charge par Multus.

  3. Enregistrez vos modifications et quittez l'éditeur de texte pour valider vos modifications.

Vérification

  • Sur une ligne de commande, entrez la commande suivante : 

    $ oc get network-attachment-definitions -A

    Exemple de sortie

    NAMESPACE       NAME            AGE
ipv6            ipv6            21h

Vous pouvez maintenant créer des pods qui ont des connexions IPv6 secondaires.

Ressources supplémentaires

8.10.8. Créer des pods qui ont une connectivité IPv6 sur RHOSP

Après avoir activé la connectivité IPv6 pour les modules et l'avoir ajoutée à ces derniers, créez des modules dotés de connexions IPv6 secondaires.

Procédure

  1. Définissez des pods qui utilisent votre espace de noms IPv6 et l'annotation k8s.v1.cni.cncf.io/networks: <additional_network_name>, où <additional_network_name est le nom du réseau supplémentaire. Par exemple, dans le cadre d'un objet Deployment: 

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-openshift
  namespace: ipv6
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - hello-openshift
  replicas: 2
  selector:
    matchLabels:
      app: hello-openshift
  template:
    metadata:
      labels:
        app: hello-openshift
      annotations:
        k8s.v1.cni.cncf.io/networks: ipv6
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: hello-openshift
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
        image: quay.io/openshift/origin-hello-openshift
        ports:
        - containerPort: 8080

  2. Créez le pod. Par exemple, sur une ligne de commande, entrez la commande suivante : 

    oc create -f <ipv6_enabled_resource>

où :

<ipv6_enabled_resource>
Indique le fichier qui contient la définition de la ressource.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.