Hinweis:

Mit dem CNI-Plug-in für OCI-VCN-native Pods Networking können Sie Networking-Services für Oracle Cloud Infrastructure Container Engine for Kubernetes bereitstellen

Einführung

Standardmäßig verwendet Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) das Oracle Cloud Infrastructure-(OCI-)VCN-Native Container Network Interface-(CNI-)Plug-in, um Netzwerk- oder Sicherheitsfeatures für containerisierte Anwendungen bereitzustellen. In diesem Tutorial zeigen wir Ihnen, wie Sie prüfen können, welches CNI-Plug-in verwendet wird und wie wir dieses Standard-CNI-Plug-in (OCI-VCN-natives CNI-Plug-in) verwenden können, um einen OCI Load Balancer-Service zu konfigurieren und an eine Anwendung anzuhängen, die in einem Container ausgeführt wird.

image

Der Vorteil der Verwendung des CNI-Plug-ins für OCI-VCN-native Pods Networking besteht darin, dass die Pods oder Container eine IP-Adresse aus dem privaten Subnetz im VCN erhalten. Das bedeutet, dass sich Ihre Kubernetes-Pods im selben Netzwerk wie Ihre VMs (Instanzen) oder Ihre baremetalen Knoten oder andere Workloads befinden.

Ziele

Aufgabe 1: Kubernetes-Cluster mit OKE bereitstellen

Weitere Informationen zu den verschiedenen OKE-Deployment-Modellen, die wir auswählen können, finden Sie unter Beispielkonfigurationen für Netzwerkressourcen.

Beispiele für OKE-Deployment-Modelle:

Sie wählen das Deployment-Modell Beispiel 3 aus. Weitere Informationen finden Sie unter Oracle Cloud Infrastructure Container Engine for Kubernetes mit drei Worker-Knoten einrichten.

Aufgabe 2: Installiertes CNI-Plug-in prüfen

Wenn das Kubernetes-Cluster mit OKE vollständig bereitgestellt ist und Sie Zugriff darauf haben, können Sie den folgenden Befehl ausführen.

  1. Führen Sie den folgenden Befehl aus.

    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. Beachten Sie, dass der Name in der Ausgabe im Podabschnitt vcn-native lautet.

  3. Beachten Sie, dass der Name in der Ausgabe im Daemonset-Abschnitt vcn-native lautet.

image

Dadurch wird angezeigt, dass das CNI-Plug-in für OCI-VCN-native Pods Networking derzeit für dieses bereitgestellte OKE-Deployment verwendet wird.

Aufgabe 3: Beispielanwendung bereitstellen

Wir verwenden diese Beispielanwendung zusammen mit dem CNI-Plug-in für OCI-VCN-native Pods Networking und aktivieren den OCI Load Balancer-Servicetyp in der nächsten Aufgabe.

  1. Führen Sie den folgenden Befehl aus, um eine Nginx-Beispielanwendung in OKE bereitzustellen.

    iwan_hooge@cloudshell:~ (eu-amsterdam-1)$ kubectl apply -f https://k8s.io/examples/application/deployment.yaml 
    deployment.apps/nginx-deployment created
    
  2. Führen Sie den folgenden Befehl aus, um die Details der bereitgestellten Nginx-Beispielanwendung zu prüfen.

    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. Beachten Sie, dass die Anwendung mit zwei Pods bereitgestellt wird.

image

  1. Führen Sie den folgenden Befehl aus, um die bereitgestellten Pods genauer zu betrachten.

    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. Beachten Sie, dass zwei Instanzen oder Pods oder Replikate der Nginx-Anwendung vorhanden sind und der Status auf Wird ausgeführt gesetzt ist.

image

Eine visuelle Darstellung der Bereitstellung finden Sie im folgenden Diagramm. Konzentrieren Sie sich auf die beiden bereitgestellten Pods innerhalb der Worker-Knoten.

image

Der Vorteil der Verwendung des CNI-Plug-ins für OCI-VCN-native Pods Networking besteht darin, dass die Pods oder Container eine IP-Adresse aus dem privaten Subnetz im VCN erhalten. Das bedeutet, dass sich Ihre Kubernetes-Pods im selben Netzwerk wie Ihre VMs (Instanzen) oder Ihre baremetalen Knoten oder andere Workloads befinden.

Aufgabe 4: Kubernetes-Services des Load-Balancer-Typs konfigurieren

Unsere Beispielanwendung wird in OKE ausgeführt. Es ist an der Zeit, die Anwendung dem Netzwerk oder dem Internet zugänglich zu machen, indem der Anwendung ein Netzwerkservice vom Typ Load Balancer zugeordnet wird.

Eine visuelle Darstellung des Load Balancer Deployments finden Sie im folgenden Diagramm. Konzentrieren Sie sich auf den Load Balancer.

image

Aufgabe 5: Beispielanwendung und Kubernetes-Services vom Load-Balancer-Typ entfernen

Wir haben eine Beispielanwendung bereitgestellt und einen neuen Kubernetes-Netzwerkservice vom Load-Balancer-Typ erstellt. Es ist an der Zeit, die Anwendung und den Service zu bereinigen.

Beachten Sie, dass kein Load Balancer mehr bereitgestellt ist.

image

Eine visuelle Darstellung des Löschens des Load Balancers finden Sie im folgenden Diagramm. Konzentrieren Sie sich auf den Teil, in dem der Load Balancer nicht mehr bereitgestellt wird.

image

Danksagungen

Weitere Lernressourcen

Lernen Sie andere Übungen auf docs.oracle.com/learn kennen, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning YouTube Channel zu. Außerdem können Sie education.oracle.com/learning-explorer besuchen, um Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.