Voir la source de Deployer un cluster Kubernetes

Cette procédure va vous permettre de déployer rapidement et facilement un cluster Kubernetes (k8s) de trois nodes à partir de trois instances CentOS 7 déployées au sein d'un même réseau en zone avancée.


L'une de ces trois instances sera notre node master et les deux autres seront nos nodes workers. Pour résumer simplement, le node master est le node depuis lequel on gère le cluster Kubernetes depuis son API et les nodes workers sont les nodes sur lesquelles s'exécuteront les pod soit les conteneurs Docker. 


Nous partirons du principe que vos 3 instances CentOS 7 sont déjà déployées et que vous y avez accès en ssh pour y exécuter les commandes qui suivront.


Voici la configuration que nous avons dans notre exemple et qui servira d'exemple tout au long de cette procédure :


Node master : "k8s-master" / 10.1.1.16<br>
Premier node worker : "k8s-worker01" / 10.1.1.169<br>
Second node worker : "k8s-worker02" / 10.1.1.87<br>


== Préparation du système et installation de Kubernetes ==

Les actions suivantes sont à effectuer sur toutes les instances (master et workers) en tant que root (ou avec les droits sudo nécessaires).


Commencez par peupler le fichier /etc/hosts sur chacune de vos instances afin qu'elles puissent résoudre leur nom d'hôte respectif (normalement déjà le cas dans un réseau en zone avancé où le routeur virtuel fait résolveur DNS). 


Dans notre exemple cela donne le fichier /etc/hosts suivant sur nos trois instances (adaptez celui-ci avec le nom et l'ip de vos instances) :

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


Activez le module bridge et les règles iptables pour ce dernier via les trois commandes suivantes :

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


Ajoutez le dépôt 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>


Ajouter le dépôt 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>


Installez Docker :

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


Puis installez les paquets Kubernetes nécessaires :

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


Editez le fichier de configuration de l'unité systemd kubelet (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf)  pour y ajouter la ligne suivante dans la partie  "[Service]" :

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


tel que :

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


Rechargez la configuration, activez puis démarrez les services docker et kubelet via les trois commandes suivantes :

<syntaxhighlight lang="bash">
systemctl daemon-reload
systemctl enable docker kubelet
systemctl start docker kubelet
</syntaxhighlight>


Désactivez la swap du système (kubelet ne supportant pas la mémoire swap, vous obtiendrez une erreur lors des "pre-flight checks à l'initialisation de votre cluster via kubeadmsi vous ne désactivez pas celle-ci) :

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


veuillez penser à également commenter/retirer la ligne concernant la swap dans le fichier /etc/fstab de chacune de vos instances tel que :

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

== Initialisation du cluster Kubernetes ==

Les actions suivantes ne sont à effectuer que sur l'instance node master 


Lancez l’initialisation de votre cluster Kubernetes via la commande ci-dessous en prenant soin de modifier la valeur du paramètre "--apiserver-advertise-address=" par l'adresse ip de votre instance master.

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

Note : Veuillez ne pas modifier l'ip du réseau "10.244.0.0/16" indiquée dans le paramètre "--pod-network-cidr=" car celui-ci permet d'indiquer que nous allons utiliser le plugin CNI Flannel pour gérer la partie réseau de nos pods.


Voici à quoi doit ressembler le retour de cette commande quand le cluster s’initialise avec succès :

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


Nous effectuons les opérations demandées afin de finaliser l'initialisation de notre cluster :

On crée un répertoire et fichier de configuration dans le répertoire de notre utilisateur (root dans notre cas) :

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

On déploie notre réseau pod Flannel pour notre cluster :

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

remarque : nous allons garder la dernière commande fournie par le retour  de la commande d'initialisation de côté ("kubeadm join...") afin d'exécuter celle-ci sur nos instances workers par la suite pour les joindre à notre cluster.


On peut maintenant faire les premières vérifications de notre cluster depuis notre instance master  :

Tapez la commande "kubectl get nodes" pour vérifier les nodes actuellement présent dans votre cluster :

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

Note : il n'y a actuellement que votre node master ce qui est normal car nous n'avons pas encore ajouté les autres nodes au cluster.


Tapez la commande "kubectl get pods --all-namespaces" pour vérifier les pods/conteneurs actuellement présent dans votre cluster : 

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

Remarque : Il n'y a que les pods correspondant aux composants Kubernetes nécessaires pour notre node master (kube-apiserver, etcd, kube-scheduler, etc.).


On peut vérifier l'état de ces composants avec la commande suivante :

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

== Actions à n'effectuer que sur les instances/nodes worker ==

Sur chacune de vos instances worker (ne pas faire sur votre instance master), lancez la commande "kubeadm join ..." fournie à la fin de l'initialisation de votre cluster un peu plus haut :

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


== Vérification de l'état du cluster  ==

Actions à effectuer depuis l'instance/node master


Vérifiez que vos nodes worker ont bien été ajouté à votre cluster en ré-exécutant la commande "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>

Remarque : On voit bien nos deux nodes worker (k8s-worker01 et k8s-worker02), ils ont donc bien été ajouté à notre cluster.


Relançons maintenant la commande "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>

Remarque: On peut constater qu'il y a autant de pods/conteneurs "kube-flannel" et "kube-proxy" que nous avons de nodes dans notre cluster.


== Déploiement d'un premier pod ==

Nous allons déployer notre premier [https://kubernetes.io/docs/concepts/workloads/pods/pod/ pod] dans notre cluster Kubernetes.


Par simplicité, nous choisissons de déployer un pod (sans réplicat) nommé "nginx" et utilisant l'image "nginx" :

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


Si on vérifie, celui-ci apparait bien au retour de la commande listant les pods de notre cluster :

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

Il figure en haut de la liste dans un namespace différent de "kube-system" puisqu'il ne s'agit pas d'un composant propre au fonctionnement de Kubernetes.


Il est d'ailleurs possible de ne pas afficher les pods propre au namespace kube-system en effectuant cette même commande sans le paramètre "--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>


Pour afficher les labels :

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


Nous pouvons également vérifié nos déploiements via la commande suivante :

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


Nous avons donc un pod nginx de déployé et démarré mais qui n'est pour l'instant pas accessible de l'extérieur. Pour le rendre accessible depuis l'extérieur, nous devons exposer le port de notre pod en créant le service (de type NodePort) via la commande suivante :

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


Notre service est ainsi crée :

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

Remarque : Il écoute sur le port 80/tcp et sera disponible/exposé depuis l'extérieur sur le port 30566/tcp


Nous pouvons obtenir l'ip flannel de notre pod ainsi que le nom du node sur lequel il tourne actuellement via la commande suivante :

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

Ici notre pod nginx a donc l'ip 10.244.2.2 et tourne sur notre node k8s-worker02.


Vous pouvez également simplement exécuter une commande ou ouvrir un shell sur notre pod nginx via la commande suivante (très similaire à la commande docker) :

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


Il ne vous reste donc plus qu'à créer votre règle de load balancing sur votre réseau Cloud Ikoula One pour accéder à /rendre publique votre serveur web (pod nginx)  :

- Connectez-vous à l'interface [https://cloudstack.ikoula.com/client Cloud Ikoula One]
- allez dans "Network" dans le menu vertical gauche
- cliquez sur votre réseau dans lequel vous avez déployé vos instances Kubernetes puis sur "View IP Addresses" et sur votre ip Source NAT et allez dans l'onglet "Configuration"
- cliquez sur "Load Balancing" et créé votre règle en spécifiant un nom, le port public "80" dans notre cas, le port privé "30566" dans notre cas (cf. plus haut), en choisissant un algorithme LB (ex: round-robin) tel que :

[[File:faq_k8s_regle_lb-01.png]]


- cochez l'ensemble de vos instances worker :

[[File:faq_k8s_regle_lb-02.png]]



Tester l'accès à votre server web / pod nginx depuis votre navigateur (via l'ip publique de votre réseau sur laquelle vous avez crée la règle LB) :


[[File:faq_k8s_browser_nginx.png]]


Le fait que votre pod nginx soit accessible depuis n'importe lequel de vos nodes est rendu possible grâce au composant "kube-proxy" qui se charge de faire pointer les connexions sur le/les node(s) sur lequel tourne celui-ci/ceux-ci (en cas de réplicats).


Vous venez donc de déployer un cluster Kubernetes de base de 3 nodes avec un master et deux worker.

== Allez plus loin ==

Il vous est possible d'allez plus loin en en déployant le dashboard Kubernetes ou en créant par exemple des volumes persistants pour vos pods, en augmentant le nombre de vos nodes worker, voir en redondant le rôle master pour faire de la haute disponibilité ou encore de dédier des nodes à certains composants tel que Etcd par exemple. . 


Voici quelques liens utiles :


https://kubernetes.io/docs/reference/kubectl/cheatsheet/ 

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/