Tekst źródłowy strony Wdrażanie klastra Kubernetes

<span data-link_translate_ru_title="Развертывание кластера Kubernetes"  data-link_translate_ru_url="Развертывание кластера Kubernetes"></span>[[:ru:Развертывание кластера Kubernetes]][[ru:Развертывание кластера Kubernetes]]
<span data-link_translate_fr_title="Deployer un cluster Kubernetes"  data-link_translate_fr_url="Deployer un cluster Kubernetes"></span>[[:fr:Deployer un cluster Kubernetes]][[fr:Deployer un cluster Kubernetes]]
<br />Artykuł ten jest wynikiem translacji automatycznej wykonywane przez oprogramowanie. Możesz przeglądać źródła artykułu [[:fr:Array|tutaj]].<br /><span data-translate="fr"></span><br />
<span data-link_translate_ja_title="Kubernetesクラスタのデプロイ"  data-link_translate_ja_url="Kubernetesクラスタのデプロイ"></span>[[:ja:Kubernetesクラスタのデプロイ]][[ja:Kubernetesクラスタのデプロイ]]
<span data-link_translate_zh_title="部署一个Kubernetes集群"  data-link_translate_zh_url="部署一个Kubernetes集群"></span>[[:zh:部署一个Kubernetes集群]][[zh:部署一个Kubernetes集群]]
<span data-link_translate_de_title="Bereitstellen eines Kubernetes-Clusters"  data-link_translate_de_url="Bereitstellen eines Kubernetes-Clusters"></span>[[:de:Bereitstellen eines Kubernetes-Clusters]][[de:Bereitstellen eines Kubernetes-Clusters]]
<span data-link_translate_nl_title="Een Kubernetes cluster implementeren"  data-link_translate_nl_url="Een Kubernetes cluster implementeren"></span>[[:nl:Een Kubernetes cluster implementeren]][[nl:Een Kubernetes cluster implementeren]]
<span data-link_translate_pt_title="Implantação de um aglomerado Kubernetes"  data-link_translate_pt_url="Implantação de um aglomerado Kubernetes"></span>[[:pt:Implantação de um aglomerado Kubernetes]][[pt:Implantação de um aglomerado Kubernetes]]
<span data-link_translate_es_title="Despliegue de un clúster Kubernetes"  data-link_translate_es_url="Despliegue de un clúster Kubernetes"></span>[[:es:Despliegue de un clúster Kubernetes]][[es:Despliegue de un clúster Kubernetes]]
<span data-link_translate_en_title="Deploying a Kubernetes cluster"  data-link_translate_en_url="Deploying a Kubernetes cluster"></span>[[:en:Deploying a Kubernetes cluster]][[en:Deploying a Kubernetes cluster]]
<span data-link_translate_it_title="Configurare un cluster Kubernetes"  data-link_translate_it_url="Configurare un cluster Kubernetes"></span>[[:it:Configurare un cluster Kubernetes]][[it:Configurare un cluster Kubernetes]]
<span data-link_translate_fr_title="Deployer un cluster Kubernetes"  data-link_translate_fr_url="Deployer un cluster Kubernetes"></span>[[:fr:Deployer un cluster Kubernetes]][[fr:Deployer un cluster Kubernetes]]


{{#seo:
|title=Instalacja kubernetes
|titlemode=replace
|keywords=ikoula wiki, ikoula wiki, ikoula knowledge base, kubernetes is what, kubernetes installation, kubernetes tutorial
|description=Kubernetes może być uważany za: platformę kontenerową, platformę mikroserwisów, przenośną platformę chmurową i wiele więcej...Dowiedz się jak go zainstalować.
|og:type=article
|og:image=https://fr-wiki.ikoula.com/resources/assets/logo_ikwiki.png
}} 

==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. [https://www.ikoula.com/fr/cloud-public/oneclick 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<br>
Pierwszy węzeł worker: "k8s-worker01" / 10.1.1.169<br>
Drugi węzeł worker: "k8s-worker02" / 10.1.1.87<br>


== 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):

<syntaxhighlight lang="bash">
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
</syntaxhighlight>


Włącz moduł bridge i reguły iptables dla niego za pomocą następujących trzech poleceń:

<syntaxhighlight lang="bash">
modprobe bridge
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf
</syntaxhighlight>


Dodaj repozytorium YUM Docker :

<syntaxhighlight lang="bash">
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
</syntaxhighlight>


Dodaj repozytorium YUM Kubernetes : 

<syntaxhighlight lang="bash">
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
</syntaxhighlight>


Zainstaluj Docker :

<syntaxhighlight lang="bash">
yum install -y docker-ce
</syntaxhighlight>


Następnie zainstaluj niezbędne pakiety Kubernetes:

<syntaxhighlight lang="bash">
yum install -y kubeadm kubelet kubectl
</syntaxhighlight>


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]":

<pre>
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"
</pre>


takie, że :

<pre>
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
</pre>


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):

<syntaxhighlight lang="bash">
swapoff -a
</syntaxhighlight>


Proszę pamiętać, aby również skomentować/usunąć linię swap w pliku /etc/fstab każdej z twoich instancji, np :

<pre>
#/dev/mapper/vg01-swap  swap            swap    defaults                0       0
</pre>

== 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.

<syntaxhighlight lang="bash">
kubeadm init --apiserver-advertise-address=<ip de votre instance master> --pod-network-cidr=10.244.0.0/16
</syntaxhighlight>

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:

<syntaxhighlight lang="bash">
[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
</syntaxhighlight>


Wykonujemy żądane operacje w celu zakończenia inicjalizacji naszego klastra:


Tworzymy katalog i plik konfiguracyjny w katalogu naszego użytkownika (w naszym przypadku root):

<syntaxhighlight lang="bash">
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
</syntaxhighlight>


Wdrażamy naszą sieć pod Flannel dla naszego klastra:

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

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:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get nodes
NAME                             STATUS   ROLES    AGE   VERSION
k8s-master.cs437cloud.internal   Ready    master   41m   v1.12.2
</syntaxhighlight>

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: 

<syntaxhighlight lang="bash">
[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
</syntaxhighlight>

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:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get cs
NAME                 STATUS    MESSAGE              ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health": "true"}
</syntaxhighlight>

== 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:

<syntaxhighlight lang="bash">
[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.
</syntaxhighlight>

<syntaxhighlight lang="bash">
[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.
</syntaxhighlight>

== 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":

<syntaxhighlight lang="bash">
[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
</syntaxhighlight>

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":

<syntaxhighlight lang="bash">
[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
</syntaxhighlight>

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 [https://kubernetes.io/docs/concepts/workloads/pods/pod/ pod] w naszym klastrze Kubernetes.


Dla uproszczenia, wybieramy wdrożenie strąka (bez replik) o nazwie "nginx" i używając obrazu "nginx":

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl create deployment nginx --image=nginx
deployment.apps/nginx created
</syntaxhighlight>


Jeśli sprawdzimy, to ten pojawia się dobrze na końcu polecenia wypisującego strąki naszego klastra:

<syntaxhighlight lang="bash">
[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
</syntaxhighlight>

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":

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods
NAME                      READY   STATUS    RESTARTS   AGE
nginx-55bd7c9fd-vs4fq     1/1     Running   0          3d2h
</syntaxhighlight>


Aby wyświetlić etykiety :

<syntaxhighlight lang="bash">
[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
</syntaxhighlight>


Możemy również sprawdzić nasze wdrożenia za pomocą następującego polecenia:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get deployments
NAME    DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx   1         1         1            1           93m
</syntaxhighlight>


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:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl create service nodeport nginx --tcp=80:80
service/nginx created
</syntaxhighlight>


W ten sposób powstaje nasz serwis:

<syntaxhighlight lang="bash">
[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
</syntaxhighlight>

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:

<syntaxhighlight lang="bash">
[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>
</syntaxhighlight>

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):

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl exec -it nginx-55bd7c9fd-vs4fq -- /bin/bash
root@nginx-55bd7c9fd-vs4fq:/#
</syntaxhighlight>


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 [https://cloudstack.ikoula.com/client 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 :


[[File:faq_k8s_regle_lb-01.png|Instancja Kubernetes]]


- zaznacz wszystkie instancje worker:


[[File:faq_k8s_regle_lb-02.png|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):


[[File:faq_k8s_browser_nginx.png|Dostęp do serwera WWW]]


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/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/



[[Category:cloudstack]]
[[Category:chmura publiczna]]
[[Category:chmura prywatna]]
[[Category:Docker]]
[[Category:CoreOS]]
[[Category:Chmura]]