Bereitstellen eines Kubernetes-Clusters
ro:Implementarea unui cluster Kubernetes
ru:Развертывание кластера Kubernetes
pl:Wdrażanie klastra Kubernetes
ja:Kubernetesクラスタのデプロイ
zh:部署一个Kubernetes集群
fr:Deployer un cluster Kubernetes
Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle hier ansehen.
nl:Een Kubernetes cluster implementeren
pt:Implantação de um aglomerado Kubernetes
es:Despliegue de un clúster Kubernetes
en:Deploying a Kubernetes cluster
it:Configurare un cluster Kubernetes
fr:Deployer un cluster Kubernetes
Was ist Kubernetes?
Kubernetes ist eine Open-Source-Plattform für die Verwaltung von containerisierten Arbeitslasten und Diensten. Es unterstützt die deklarative Konfigurationserstellung, aber auch die Automatisierung. Kubernetes ist ein großes und schnell wachsendes Ökosystem.
Mit diesem Verfahren können Sie schnell und einfach einen Drei-Knoten-Cluster einrichten Kubernetes (k8s) Mit diesem Verfahren können Sie schnell und einfach einen Drei-Knoten-Cluster aus drei CentOS 7-Instanzen einrichten, die innerhalb desselben Netzwerks in einer Forward Zone installiert sind.
Eine dieser drei Instanzen wird unser Masterknoten sein, die anderen beiden werden unsere Arbeitsknoten sein. Zusammenfassend lässt sich sagen, dass der Master-Knoten der Knoten ist, von dem aus wir den Kubernetes-Cluster (Container-Orchestrator) über seine API verwalten, und die Worker-Knoten die Knoten sind, auf denen die Pods oder Container (in unserem Fall Docker) ausgeführt werden.
Wir gehen davon aus, dass Ihre 3 CentOS 7-Instanzen bereits eingerichtet sind und dass Sie per ssh Zugriff auf sie haben, um die folgenden Befehle auszuführen.
Hier ist die Konfiguration, die wir in unserem Beispiel haben und die in diesem Verfahren als Beispiel verwendet wird:
Knotenmaster: "k8s-master" / 10.1.1.16
Erster Arbeitsknoten: "k8s-worker01" / 10.1.1.169
Zweiter Arbeitsknoten: "k8s-worker02" / 10.1.1.87
Tutorial zur Systemvorbereitung und Kubernetes-Installation
Die folgenden Aktionen müssen auf allen Instanzen (Master und Worker) als root (oder mit den erforderlichen sudo-Rechten) durchgeführt werden.
Beginnen Sie damit, die Datei /etc/hosts auf jeder Ihrer Instanzen aufzufüllen, so dass sie ihren jeweiligen Hostnamen auflösen können (normalerweise ist dies in einem erweiterten Zonennetzwerk, in dem der virtuelle Router ein DNS-Auflöser ist, bereits der Fall).
In unserem Beispiel ergibt dies die folgende /etc/hosts Datei auf unseren drei Instanzen (passen Sie sie mit dem Namen und der IP Ihrer Instanzen an):
cat /etc/hosts
127.0.0.1 localhost
::1 localhost
10.1.1.16 k8s-master
10.1.1.169 k8s-worker01
10.1.1.87 k8s-worker02
Aktivieren Sie das Bridge-Modul und die iptables-Regeln für dieses Modul mit den folgenden drei Befehlen:
modprobe bridge
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf
Fügen Sie das YUM-Docker-Repository hinzu:
cat <<EOF > /etc/yum.repos.d/docker.repo
[docker-ce-stable]
name=Docker CE Stable - \$basearch
baseurl=https://download.docker.com/linux/centos/7/\$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg
EOF
Fügen Sie das YUM-Kubernetes-Repository hinzu:
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
Docker installieren :
yum install -y docker-ce
Installieren Sie dann die erforderlichen Kubernetes-Pakete:
yum install -y kubeadm kubelet kubectl
Bearbeiten Sie die Konfigurationsdatei des systemd kubelet (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) Konfigurationsdatei die folgende Zeile in den Abschnitt "[Service]" ein:
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"
derart, dass :
cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf # Note: This dropin only works with kubeadm and kubelet v1.11+ [Service] Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf" Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml" *Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"* # This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env # This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use # the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file. EnvironmentFile=-/etc/sysconfig/kubelet ExecStart= ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
Laden Sie die Konfiguration neu, aktivieren Sie die Docker- und Kubelet-Dienste und starten Sie sie dann mit den folgenden drei Befehlen:
systemctl daemon-reload
systemctl enable docker kubelet
systemctl start docker kubelet
</syntaxhighlight>
Deaktivieren Sie den System-Swap (kubelet unterstützt keinen Swap-Speicher, Sie erhalten eine Fehlermeldung während der Pre-Flight Checks bei der Initialisierung Ihres Clusters über kubeadms, wenn Sie ihn nicht deaktivieren):
swapoff -a
Bitte denken Sie daran, auch die Swap-Zeile in der /etc/fstab Datei jeder Ihrer Instanzen zu kommentieren/entfernen, wie z.B. :
#/dev/mapper/vg01-swap swap swap defaults 0 0
Initialisierung des Kubernetes-Clusters
Die folgenden Aktionen dürfen nur auf der Node-Master-Instanz durchgeführt werden
Starten Sie die Initialisierung Ihres Kubernetes-Clusters mit dem unten stehenden Befehl. Achten Sie darauf, den Wert des Parameters "--apiserver-advertise-address=" durch die IP-Adresse Ihrer Master-Instanz zu ändern.
kubeadm init --apiserver-advertise-address=<ip de votre instance master> --pod-network-cidr=10.244.0.0/16
Hinweis: Bitte ändern Sie die im Parameter "--pod-network-cidr=" angegebene Netzwerk-IP "10.244.0.0/16" nicht, da dieser Parameter angibt, dass wir das CNI Flannel-Plugin zur Verwaltung des Netzwerkteils unserer Pods verwenden werden.
So sollte die Rückgabe dieses Befehls aussehen, wenn der Cluster erfolgreich initialisiert wurde:
[root@k8s-master ~]# kubeadm init --apiserver-advertise-address=10.1.1.16 --pod-network-cidr=10.244.0.0/16
[init] using Kubernetes version: v1.12.2
[preflight] running pre-flight checks
[preflight/images] Pulling images required for setting up a Kubernetes cluster
[preflight/images] This might take a minute or two, depending on the speed of your internet connection
[preflight/images] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[preflight] Activating the kubelet service
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [k8s-master.cs437cloud.internal kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.1.1.16]
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [127.0.0.1 ::1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [10.1.1.16 127.0.0.1 ::1]
[certificates] Generated etcd/healthcheck-client certificate and key.
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] valid certificates and keys now exist in "/etc/kubernetes/pki"
[certificates] Generated sa key and public key.
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[controlplane] wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
[init] this might take a minute or longer if the control plane images have to be pulled
[apiclient] All control plane components are healthy after 32.502898 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.12" in namespace kube-system with the configuration for the kubelets in the cluster
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the label "node-role.kubernetes.io/master=''"
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-master.cs437cloud.internal" as an annotation
[bootstraptoken] using token: e83pes.u3igpccj2metetu8
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
Your Kubernetes master has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
You can now join any number of machines by running the following on each node
as root:
kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
Wir führen die geforderten Operationen durch, um die Initialisierung unseres Clusters abzuschließen:
Wir erstellen ein Verzeichnis und eine Konfigurationsdatei in dem Verzeichnis unseres Benutzers (in unserem Fall root):
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
Wir stellen unser Pod-Flannel-Netzwerk für unseren Cluster bereit:
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created
Hinweis: Wir werden den letzten Befehl, der durch die Rückgabe des Seiteninitialisierungsbefehls ("kubeadm join...") bereitgestellt wird, behalten, um ihn später auf unseren Worker-Instanzen auszuführen, um sie in unseren Cluster einzubinden.
Wir können nun die ersten Prüfungen unseres Clusters von unserer Master-Instanz aus durchführen:
Geben Sie den Befehl "kubectl get nodes" ein, um die derzeit in Ihrem Cluster vorhandenen Knoten zu überprüfen:
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 41m v1.12.2
Hinweis: Derzeit gibt es nur Ihren Masterknoten, was normal ist, da wir die anderen Knoten noch nicht zum Cluster hinzugefügt haben.
Geben Sie den Befehl "kubectl get pods --all-namespaces" ein, um die derzeit in Ihrem Cluster vorhandenen Pods/Container zu überprüfen:
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 41m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 41m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 84s
kube-system kube-proxy-h94bs 1/1 Running 0 41m
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 40m
Hinweis: Es gibt nur Pods, die den Kubernetes-Komponenten entsprechen, die für unseren Master-Knoten benötigt werden (kube-apiserver, etcd, kube-scheduler, etc.).
Wir können den Status dieser Komponenten mit dem folgenden Befehl überprüfen:
[root@k8s-master ~]# kubectl get cs
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health": "true"}
Hinzufügen von Arbeitsknoten zum Cluster
Aktionen, die nur auf Arbeitsinstanzen/Knoten ausgeführt werden
Führen Sie auf jeder Ihrer Worker-Instanzen (nicht auf Ihrer Master-Instanz) den Befehl "kubeadm join ..." aus, der am Ende der obigen Cluster-Initialisierung angegeben ist:
[root@k8s-worker01 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
[WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support
[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker01.cs437cloud.internal" as an annotation
This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.
Run 'kubectl get nodes' on the master to see this node join the cluster.
[root@k8s-worker02 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
[WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_wrr ip_vs_sh ip_vs ip_vs_rr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support
[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker02.cs437cloud.internal" as an annotation
This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.
Run 'kubectl get nodes' on the master to see this node join the cluster.
Überprüfung des Status des Clusters
Von der Master-Instanz/dem Master-Knoten auszuführende Aktionen
Überprüfen Sie, ob Ihre Arbeitsknoten Ihrem Cluster hinzugefügt wurden, indem Sie den Befehl "kubectl get nodes" erneut ausführen:
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 46m v1.12.2
k8s-worker01.cs437cloud.internal Ready <none> 103s v1.12.2
k8s-worker02.cs437cloud.internal Ready <none> 48s v1.12.2
Bemerkung: Wir können unsere beiden Arbeiterknoten (k8s-worker01 und k8s-worker02) sehen, sie wurden also zu unserem Cluster hinzugefügt.
Führen wir nun erneut den Befehl "kubectl get pods --all-namespaces" aus:
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 46m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 46m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-flannel-ds-amd64-724nl 1/1 Running 0 2m6s
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 6m31s
kube-system kube-flannel-ds-amd64-z7mwg 1/1 Running 3 70s
kube-system kube-proxy-8r7wg 1/1 Running 0 2m6s
kube-system kube-proxy-h94bs 1/1 Running 0 46m
kube-system kube-proxy-m2f5r 1/1 Running 0 70s
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 46m
Hinweis: Wie Sie sehen, gibt es so viele "kube-flannel"- und "kube-proxy"-Pods/Container, wie wir Knoten in unserem Cluster haben.
Einsatz eines ersten Pods
Wir werden unsere erste pod in unserem Kubernetes-Cluster.
Der Einfachheit halber entscheiden wir uns für die Bereitstellung eines Pods (ohne Replikate) mit dem Namen "nginx" und dem Image "nginx":
[root@k8s-master ~]# kubectl create deployment nginx --image=nginx
deployment.apps/nginx created
Wenn wir nachsehen, erscheint dieser auch bei der Rückkehr des Befehls, der die Pods unseres Clusters auflistet:
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
default nginx-55bd7c9fd-5bghl 1/1 Running 0 104s
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 57m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 57m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-flannel-ds-amd64-724nl 1/1 Running 0 13m
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 17m
kube-system kube-flannel-ds-amd64-z7mwg 1/1 Running 3 12m
kube-system kube-proxy-8r7wg 1/1 Running 0 13m
kube-system kube-proxy-h94bs 1/1 Running 0 57m
kube-system kube-proxy-m2f5r 1/1 Running 0 12m
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 57m
Es erscheint am Anfang der Liste in einem anderen Namensraum als "kube-system", da es sich nicht um eine für den Betrieb von Kubernetes spezifische Komponente handelt.
Es ist auch möglich, die Anzeige von Pods, die für den kube-system-Namensraum spezifisch sind, zu vermeiden, indem man denselben Befehl ohne den Parameter "--all-namespace" ausführt:
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 3d2h
So zeigen Sie die Beschriftungen an:
[root@k8s-master ~]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-55bd7c9fd-ckltn 1/1 Running 0 8m2s app=nginx,pod-template-hash=55bd7c9fd
Wir können unsere Bereitstellungen auch mit dem folgenden Befehl überprüfen:
[root@k8s-master ~]# kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 1 1 1 1 93m
Wir haben also einen Nginx-Pod eingerichtet und gestartet, aber er ist noch nicht von außen zugänglich. Um ihn von außen zugänglich zu machen, müssen wir den Port unseres Pods offenlegen, indem wir den Dienst (vom Typ NodePort) mit dem folgenden Befehl erstellen:
[root@k8s-master ~]# kubectl create service nodeport nginx --tcp=80:80
service/nginx created
So entsteht unser Service:
[root@k8s-master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 147m
nginx NodePort 10.108.251.178 <none> 80:30566/TCP 20s
Hinweis: Er lauscht auf Port 80/tcp und ist von außen über Port 30566/tcp erreichbar/offenbar.
Wir können die Flannel-IP unseres Pods und den Namen des Knotens, auf dem er gerade läuft, mit dem folgenden Befehl abrufen:
[root@k8s-master ~]# kubectl get pods --selector="app=nginx" --output=wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 174m 10.244.2.2 k8s-worker02.cs437cloud.internal <none>
Hier hat unser nginx-Pod die IP 10.244.2.2 und läuft auf unserem Knoten k8s-worker02.
Sie können auch einfach einen Befehl ausführen oder eine Shell auf unserem nginx-Pod über den folgenden Befehl öffnen (sehr ähnlich wie der Docker-Befehl):
[root@k8s-master ~]# kubectl exec -it nginx-55bd7c9fd-vs4fq -- /bin/bash
root@nginx-55bd7c9fd-vs4fq:/#
Alles, was Sie tun müssen, ist Ihre Lastausgleichsregel in Ihrem Ikoula One Cloud-Netzwerk zu erstellen, um auf Ihren Webserver (nginx pod) zuzugreifen bzw. ihn zu veröffentlichen:
- Verbinden Sie mit dem Wolke Ikoula Eins
- Gehen Sie auf "Netzwerk" im linken vertikalen Menü
- Klicken Sie auf Ihr Netzwerk, in dem Sie Ihre Kubernetes-Instanzen eingerichtet haben, dann auf "IP-Adressen anzeigen" und auf Ihre NAT-Quell-IP und gehen Sie auf die Registerkarte "Konfiguration".
- klicken Sie auf "Load Balancing" und erstellen Sie Ihre Regel, indem Sie einen Namen angeben, den öffentlichen Port "80" in unserem Fall, den privaten Port "30566" in unserem Fall (siehe oben), indem Sie einen LB-Algorithmus wählen (z.B. Round-Robin) wie :
- alle Ihre Arbeitsinstanzen ankreuzen:
Überprüfen Sie Ihre Kubernetes-Arbeitsinstanzen
Testen Sie den Zugriff auf Ihren Webserver/Nginx-Pod von Ihrem Browser aus (über die öffentliche IP Ihres Netzwerks, in dem Sie die LB-Regel erstellt haben):
Die Tatsache, dass Ihr nginx-Pod von jedem Ihrer Knoten aus zugänglich ist, wird durch die Komponente "kube-proxy" ermöglicht, die für die Weiterleitung von Verbindungen zu dem/den Knoten verantwortlich ist, auf dem/denen sie läuft (im Falle von Replikaten).
Sie haben also gerade einen einfachen Kubernetes-Cluster mit 3 Knoten, einem Master und zwei Workern eingerichtet.
Weiter gehen
Sie können noch weiter gehen, indem Sie das Kubernetes-Dashboard einsetzen oder persistente Volumes für Ihre Pods erstellen, die Anzahl Ihrer Worker-Nodes erhöhen oder sogar die Master-Rolle redundant zuweisen, um eine hohe Verfügbarkeit zu gewährleisten, oder indem Sie Nodes für bestimmte Komponenten wie z. B. Etcd reservieren.
Hier sind einige nützliche Links:
https://kubernetes.io/docs/reference/kubectl/cheatsheet/
https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/
https://kubernetes.io/docs/concepts/storage/volumes/
https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/
https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/