Remarques :

Utilisation du module d'extension CNI de mise en réseau de pods natifs OCI VCN pour fournir des services de mise en réseau à Oracle Cloud Infrastructure Container Engine for Kubernetes

Introduction

Par défaut, Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) utilise le module d'extension Oracle Cloud Infrastructure (OCI) VCN-Native Container Network Interface (CNI) pour fournir des fonctionnalités de réseau ou de sécurité aux applications en conteneur. Dans ce tutoriel, nous vous montrerons comment vérifier quel module d'extension CNI est utilisé et comment utiliser ce module d'extension CNI par défaut (module d'extension CNI natif OCI VCN) pour configurer un service OCI Load Balancer et l'attacher à une application exécutée dans un conteneur.

image

L'avantage d'utiliser le module d'extension CNI de mise en réseau de pods natifs OCI VCN est que les pods ou les conteneurs obtiendront une adresse IP du sous-réseau privé dans le VCN. Cela signifie que vos pods Kubernetes se trouvent sur le même réseau que vos machines virtuelles (instances), vos noeuds Baremetal ou d'autres charges de travail.

Objectifs

Tâche 1 : déploiement d'un cluster Kubernetes à l'aide d'OKE

Pour plus d'informations sur les différents modèles de déploiement OKE que nous pouvons choisir, reportez-vous à la section Example Network Resource Configurations.

Les exemples de modèles de déploiement OKE sont les suivants :

Nous allons sélectionner l'exemple 3 de modèle de déploiement. Pour plus d'informations, reportez-vous à Configuration d'Oracle Cloud Infrastructure Container Engine for Kubernetes avec trois noeuds de processus actifs.

Tâche 2 : vérifier le plug-in CNI installé

Lorsque le cluster Kubernetes utilisant OKE est entièrement déployé et que vous y avez accès, vous pouvez exécuter la commande suivante.

  1. Exécutez la commande suivante .

    iwan_hooge@cloudshell:~ (eu-amsterdam-1)$ **kubectl get all -n kube-system** 
    NAME                                      READY   STATUS    RESTARTS     AGE
    pod/coredns-64ffdf5cf7-lvrhq              1/1     Running   0            2d
    pod/coredns-64ffdf5cf7-rmxt8              1/1     Running   0            2d
    pod/coredns-64ffdf5cf7-vq76p              1/1     Running   0            2d
    pod/csi-oci-node-ghff6                    1/1     Running   0            2d
    pod/csi-oci-node-jrjpr                    1/1     Running   0            2d
    pod/csi-oci-node-r68qz                    1/1     Running   1 (2d ago)   2d
    pod/kube-dns-autoscaler-5bb955d5c-r2j2q   1/1     Running   0            2d
    pod/kube-proxy-5cznp                      1/1     Running   0            2d
    pod/kube-proxy-fddrd                      1/1     Running   0            2d
    pod/kube-proxy-sb769                      1/1     Running   0            2d
    pod/proxymux-client-7s7f9                 1/1     Running   0            2d
    pod/proxymux-client-lngrm                 1/1     Running   0            2d
    pod/proxymux-client-qxlf2                 1/1     Running   0            2d
    **pod/vcn-native-ip-cni-hkfjz               1/1     Running   0            2d
    pod/vcn-native-ip-cni-pdv4c               1/1     Running   0            2d
    pod/vcn-native-ip-cni-qfvk8               1/1     Running   0            2d**
    
    NAME               TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
    service/kube-dns   ClusterIP   10.96.5.5    <none>        53/UDP,53/TCP,9153/TCP   2d
    
    NAME                                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                                 AGE
    daemonset.apps/csi-oci-node               3         3         3       3            3           <none>                                        2d
    daemonset.apps/kube-proxy                 3         3         3       3            3           beta.kubernetes.io/os=linux                   2d
    daemonset.apps/node-termination-handler   0         0         0       0            0           oci.oraclecloud.com/oke-is-preemptible=true   2d
    daemonset.apps/nvidia-gpu-device-plugin   0         0         0       0            0           <none>                                        2d
    daemonset.apps/proxymux-client            3         3         3       3            3           node.info.ds_proxymux_client=true             2d
    **daemonset.apps/vcn-native-ip-cni          3         3         3       3            3           <none>                                        2d**
    
    NAME                                  READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/coredns               3/3     3            3           2d
    deployment.apps/kube-dns-autoscaler   1/1     1            1           2d
    
    NAME                                            DESIRED   CURRENT   READY   AGE
    replicaset.apps/coredns-64ffdf5cf7              3         3         3       2d
    replicaset.apps/kube-dns-autoscaler-5bb955d5c   1         1         1       2d
    iwan_hooge@cloudshell:~ (eu-amsterdam-1)$ 
    
  2. Le nom est vcn-native dans la sortie de la section pod.

  3. Le nom est vcn-native dans la sortie de la section daemonset.

image

Cela vous montrera que le module d'extension CNI de mise en réseau de pods natifs OCI VCN est actuellement utilisé pour ce déploiement OKE déployé.

Tâche 3 : déploiement d'une application échantillon

Nous allons utiliser cet exemple d'application avec le module d'extension CNI de mise en réseau de pods natifs OCI VCN et activer le type de service OCI Load Balancer dans la tâche suivante.

  1. Exécutez la commande suivante pour déployer un exemple d'application Nginx dans OKE.

    iwan_hooge@cloudshell:~ (eu-amsterdam-1)$ kubectl apply -f https://k8s.io/examples/application/deployment.yaml 
    deployment.apps/nginx-deployment created
    
  2. Exécutez la commande suivante pour vérifier les détails de l'exemple d'application Nginx déployé.

    iwan_hooge@cloudshell:~ (eu-amsterdam-1)$ kubectl describe deployment nginx-deployment
    Name:                   nginx-deployment
    Namespace:              default
    CreationTimestamp:      Fri, 08 Mar 2024 07:57:02 +0000
    Labels:                 <none>
    Annotations:            deployment.kubernetes.io/revision: 1
    Selector:               app=nginx
    Replicas:               2 desired | 2 updated | 2 total | 2 available | 0 unavailable
    StrategyType:           RollingUpdate
    MinReadySeconds:        0
    RollingUpdateStrategy:  25% max unavailable, 25% max surge
    Pod Template:
      Labels:  app=nginx
      Containers:
       nginx:
        Image:        nginx:1.14.2
        Port:         80/TCP
        Host Port:    0/TCP
        Environment:  <none>
        Mounts:       <none>
      Volumes:        <none>
    Conditions:
      Type           Status  Reason
      ----           ------  ------
      Available      True    MinimumReplicasAvailable
      Progressing    True    NewReplicaSetAvailable
    OldReplicaSets:  <none>
    NewReplicaSet:   nginx-deployment-86dcfdf4c6 (2/2 replicas created)
    Events:
      Type    Reason             Age   From                   Message
      ----    ------             ----  ----                   -------
      Normal  ScalingReplicaSet  14s   deployment-controller  Scaled up replica set nginx-deployment-86dcfdf4c6 to 2
    iwan_hooge@cloudshell:~ (eu-amsterdam-1)$
    
  3. Notez que l'application est déployée à l'aide de deux pods.

image

  1. Exécutez la commande suivante pour examiner de plus près les pods déployés.

    iwan_hooge@cloudshell:~ (eu-amsterdam-1)$ kubectl get pods
    NAME                                READY   STATUS    RESTARTS   AGE
    nginx-deployment-86dcfdf4c6-fdxgz   1/1     Running   0          3m46s
    nginx-deployment-86dcfdf4c6-fqrkh   1/1     Running   0          3m46s
    iwan_hooge@cloudshell:~ (eu-amsterdam-1)$ 
    
  2. Notez qu'il existe deux instances, pods ou répliques de l'application Nginx et que le statut est défini sur RUNNING.

image

Vous trouverez une représentation visuelle du déploiement dans le diagramme suivant. Concentrez-vous sur les deux pods déployés à l'intérieur des noeuds de processus actif.

image

L'avantage de l'utilisation du module d'extension CNI de mise en réseau de pods natifs OCI VCN est que les pods ou les conteneurs obtiendront une adresse IP du sous-réseau privé dans le VCN. Cela signifie que vos pods Kubernetes se trouvent sur le même réseau que vos machines virtuelles (instances), vos noeuds Baremetal ou d'autres charges de travail.

Tâche 4 : configurer les services Kubernetes de type équilibreur de charge

Notre exemple d'application est exécuté dans OKE. Il est temps d'exposer l'application au réseau ou à Internet en associant un service réseau de type équilibreur de charge à l'application.

Une représentation visuelle du déploiement de l'équilibreur de charge est disponible dans le diagramme suivant. Concentrez-vous sur l'équilibreur de charge.

image

Tâche 5 : enlever l'exemple d'application et les services Kubernetes de type d'équilibreur de charge

Nous avons déployé un exemple d'application et créé un service réseau Kubernetes de type équilibreur de charge. Il est temps de nettoyer l'application et le service.

Aucun équilibreur de charge n'est déployé.

image

Vous trouverez une représentation visuelle de la suppression de l'équilibreur de charge dans le diagramme suivant. Concentrez-vous sur la partie où l'équilibreur de charge n'est plus déployé.

image

Remerciements

Ressources de formation supplémentaires

Parcourez d'autres ateliers sur docs.oracle.com/learn ou accédez à davantage de contenus de formation gratuits sur le canal Oracle Learning YouTube. De plus, rendez-vous sur education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir de la documentation sur le produit, visitez Oracle Help Center.