Wdrażanie klastra Kubernetes
ro:Implementarea unui cluster Kubernetes
ru:Развертывание кластера Kubernetes
fr:Deployer un cluster Kubernetes
Artykuł ten jest wynikiem translacji automatycznej wykonywane przez oprogramowanie. Możesz przeglądać źródła artykułu tutaj.
ja:Kubernetesクラスタのデプロイ
zh:部署一个Kubernetes集群
de:Bereitstellen eines Kubernetes-Clusters
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
Czym jest Kubernetes?
Kubernetes jest platformą open-source do zarządzania skonteneryzowanymi obciążeniami i usługami. Wspiera deklaratywne pisanie konfiguracji, ale także automatyzację. Kubernetes jest dużym i szybko rozwijającym się ekosystemem.
Ta procedura pozwoli Ci szybko i łatwo wdrożyć klaster składający się z trzech węzłów. Kubernetes (k8s) Ta procedura pozwoli Ci szybko i łatwo wdrożyć trójwęzłowy klaster z trzech instancji CentOS 7 rozmieszczonych w tej samej sieci w strefie forward.
Jedna z tych trzech instancji będzie naszym węzłem głównym, a pozostałe dwie będą naszymi węzłami robotniczymi. Podsumowując najprościej, węzeł główny to węzeł, z którego zarządzamy klastrem Kubernetes (orkiestrator kontenerów) z poziomu jego API, a węzły robotnicze to węzły, na których będą uruchamiane strąki lub kontenery (w naszym przypadku Docker).
Założymy, że Twoje 3 instancje CentOS 7 są już wdrożone i że masz do nich dostęp przez ssh, aby wykonać polecenia, które za chwilę wykonamy.
Oto konfiguracja, którą mamy w naszym przykładzie i która będzie używana jako przykład w całej tej procedurze:
Węzeł główny: "k8s-master" / 10.1.1.16
Pierwszy węzeł worker: "k8s-worker01" / 10.1.1.169
Drugi węzeł worker: "k8s-worker02" / 10.1.1.87
Samouczek przygotowania systemu i instalacji Kubernetes
Poniższe czynności muszą być wykonane na wszystkich instancjach (master i workers) jako root (lub z odpowiednimi prawami sudo).
Zacznij od wypełnienia pliku /etc/hosts na każdej z instancji, tak aby mogły one rozwiązywać swoje nazwy hostów (zazwyczaj tak się dzieje w zaawansowanych sieciach strefowych, gdzie wirtualny router jest resolverem DNS).
W naszym przykładzie daje to następujący plik /etc/hosts na naszych trzech instancjach (dostosuj go do nazwy i ip swoich instancji):
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
Włącz moduł bridge i reguły iptables dla niego za pomocą następujących trzech poleceń:
modprobe bridge
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf
Dodaj repozytorium YUM Docker :
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
Dodaj repozytorium YUM Kubernetes :
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
Zainstaluj Docker :
yum install -y docker-ce
Następnie zainstaluj niezbędne pakiety Kubernetes:
yum install -y kubeadm kubelet kubectl
Edytuj plik konfiguracyjny kubeletu systemd (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) plik konfiguracyjny, aby dodać następującą linię w sekcji "[Service]":
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"
takie, że :
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
Przeładuj konfigurację, włącz, a następnie uruchom usługi docker i kubelet za pomocą następujących trzech poleceń:
systemctl daemon-reload
systemctl enable docker kubelet
systemctl start docker kubelet
</syntaxhighlight>
Wyłącz swap systemu (kubelet nie obsługuje pamięci swap, otrzymasz błąd podczas kontroli przed lotem podczas inicjalizacji klastra przez kubeadms, jeśli nie wyłączysz tej funkcji):
swapoff -a
Proszę pamiętać, aby również skomentować/usunąć linię swap w pliku /etc/fstab każdej z twoich instancji, np :
#/dev/mapper/vg01-swap swap swap defaults 0 0
Inicjalizacja klastra Kubernetes
Następujące czynności mogą być wykonywane tylko na instancji głównej węzła
Rozpocznij inicjalizację klastra Kubernetes za pomocą poniższej komendy, zwracając uwagę na zmianę wartości parametru "--apiserver-advertise-address=" na adres ip Twojej instancji master.
kubeadm init --apiserver-advertise-address=<ip de votre instance master> --pod-network-cidr=10.244.0.0/16
Uwaga: Proszę nie modyfikować network ip "10.244.0.0/16" wskazanego w parametrze "--pod-network-cidr=" ponieważ ten parametr pozwala nam wskazać, że będziemy używać pluginu CNI Flannel do zarządzania częścią sieciową naszych strąków.
Oto jak powinien wyglądać komunikat zwrotny tego polecenia po pomyślnym zainicjowaniu klastra:
[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
Wykonujemy żądane operacje w celu zakończenia inicjalizacji naszego klastra:
Tworzymy katalog i plik konfiguracyjny w katalogu naszego użytkownika (w naszym przypadku root):
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
Wdrażamy naszą sieć pod Flannel dla naszego klastra:
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
Uwaga: zachowamy ostatnią komendę dostarczoną przez zwrot bocznej komendy inicjalizacyjnej ("kubeadm join..."), aby uruchomić ją później na naszych instancjach robotniczych w celu dołączenia ich do naszego klastra.
Możemy teraz wykonać pierwsze kontrole naszego klastra z naszej instancji master:
Wpisz polecenie "kubectl get nodes", aby sprawdzić węzły aktualnie obecne w klastrze:
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 41m v1.12.2
Uwaga: obecnie w klastrze znajduje się tylko węzeł główny, co jest normalne, ponieważ nie dodaliśmy jeszcze innych węzłów do klastra.
Wpisz polecenie "kubectl get pods --all-namespaces", aby sprawdzić strąki/kontenery obecne w Twoim klastrze:
[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
Uwaga: Istnieją tylko strąki odpowiadające komponentom Kubernetes potrzebnym dla naszego węzła głównego (kube-apiserver, etcd, kube-scheduler, etc).
Możemy sprawdzić status tych komponentów za pomocą następującego polecenia:
[root@k8s-master ~]# kubectl get cs
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health": "true"}
Dodawanie węzłów robotniczych do klastra
Akcje, które mają być wykonywane tylko na instancjach/węzłach robotniczych
Na każdej z instancji robotniczych (nie rób tego na instancji master), uruchom polecenie "kubeadm join ..." podane na końcu powyższej inicjalizacji klastra:
[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.
Sprawdzanie stanu klastra
Akcje, które mają być wykonywane z instancji/węzła nadrzędnego
Sprawdź, czy węzły robocze zostały dodane do klastra, wykonując ponownie polecenie "kubectl get nodes":
[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
Uwaga: Widzimy nasze dwa węzły robotnicze (k8s-worker01 i k8s-worker02), więc zostały one dodane do naszego klastra.
Uruchommy teraz ponownie polecenie "kubectl get pods --all-namespaces":
[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
Uwaga: Możesz zobaczyć, że jest tyle pods/kontenerów "kube-flannel" i "kube-proxy" ile mamy węzłów w naszym klastrze.
Rozmieszczanie pierwszego strąka
Rozmieścimy nasze pierwsze pod w naszym klastrze Kubernetes.
Dla uproszczenia, wybieramy wdrożenie strąka (bez replik) o nazwie "nginx" i używając obrazu "nginx":
[root@k8s-master ~]# kubectl create deployment nginx --image=nginx
deployment.apps/nginx created
Jeśli sprawdzimy, to ten pojawia się dobrze na końcu polecenia wypisującego strąki naszego klastra:
[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
Pojawia się on na górze listy w innej przestrzeni nazw niż "kube-system", ponieważ nie jest to komponent specyficzny dla działania Kubernetes.
Możliwe jest również uniknięcie wyświetlania strąków specyficznych dla przestrzeni nazw kube-system poprzez wykonanie tego samego polecenia bez parametru "--all-namespace":
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 3d2h
Aby wyświetlić etykiety :
[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
Możemy również sprawdzić nasze wdrożenia za pomocą następującego polecenia:
[root@k8s-master ~]# kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 1 1 1 1 93m
Mamy więc wdrożony i uruchomiony strąk nginx, ale nie jest on jeszcze dostępny z zewnątrz. Aby uczynić go zewnętrznie dostępnym, musimy wyeksponować port naszego strąka poprzez utworzenie usługi (typu NodePort) za pomocą następującej komendy:
[root@k8s-master ~]# kubectl create service nodeport nginx --tcp=80:80
service/nginx created
W ten sposób powstaje nasz serwis:
[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
Uwaga: Nasłuchuje na porcie 80/tcp i będzie dostępny/wyświetlany z zewnątrz na porcie 30566/tcp
Możemy uzyskać flanelowe ip naszego strąka oraz nazwę węzła, na którym jest on aktualnie uruchomiony za pomocą następującego polecenia:
[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>
Tutaj nasz nginx pod ma ip 10.244.2.2 i jest uruchomiony na naszym węźle k8s-worker02.
Możesz również po prostu uruchomić komendę lub otworzyć powłokę na naszym nginx pod za pomocą następującej komendy (bardzo podobnej do komendy docker):
[root@k8s-master ~]# kubectl exec -it nginx-55bd7c9fd-vs4fq -- /bin/bash
root@nginx-55bd7c9fd-vs4fq:/#
Wszystko, co musisz zrobić, to stworzyć regułę równoważenia obciążenia w sieci Ikoula One Cloud, aby uzyskać dostęp / upublicznić swój serwer WWW (nginx pod):
- Podłącz do Chmura Ikoula Jeden
- przejdź do "Sieć" w lewym pionowym menu
- kliknij na swoją sieć, w której masz rozmieszczone instancje Kubernetes, następnie na "View IP Addresses" i na NAT Source ip i przejdź do zakładki "Configuration".
- kliknij na "Load Balancing" i stwórz swoją regułę podając nazwę, port publiczny "80" w naszym przypadku, port prywatny "30566" w naszym przypadku (patrz wyżej), wybierając algorytm LB (np. round-robin) taki jak :
- zaznacz wszystkie instancje worker:
Sprawdź instancje robotnicze kubernetes
Przetestuj dostęp do swojego serwera WWW / nginx z poziomu przeglądarki (poprzez publiczne IP Twojej sieci, na którym utworzyłeś regułę LB):
To, że do Twojego nginxa można się dostać z dowolnego węzła, jest możliwe dzięki komponentowi "kube-proxy", który odpowiada za kierowanie połączeń do węzła(ów), na którym(ch) jest uruchomiony (w przypadku replik).
Więc właśnie wdrożyłeś podstawowy klaster Kubernetes składający się z 3 węzłów z masterem i dwoma robotnikami.
Idź dalej
Możesz pójść dalej, wdrażając dashboard Kubernetes lub tworząc trwałe wolumeny dla strąków, zwiększając liczbę węzłów robotniczych, a nawet redundantnie przypisując rolę master dla wysokiej dostępności lub dedykując węzły dla określonych komponentów, takich jak na przykład Etcd.
Oto kilka przydatnych linków:
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/