Ikoula Wiki - Contributions de l’utilisateur [fr]

Deployer vos instances avec Ansible

2019-11-28T10:14:15Z

Lhulotf79a8 : /* Déploiement d'une instance avec un playbook Ansible */

== Description ==

Nous allons voir comment déployer rapidement des instance(s) Cloud IKOULA One via l'outils Ansible

Tout d'abord vous devrez installer Ansible (https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html) puis le module "cs_instance" (peut être installé via "pip install cs" cf. https://docs.ansible.com/ansible/2.6/modules/cs_instance_module.html) permettant d'utiliser l'API de Cloud Ikoula One, si ce n'est pas déjà fait et disposer d'un compte Cloud IKOULA One.

Ansible est disponible pour la plupart des distributions GNU/Linux, MacOS mais est aussi utilisable via Cygwin par exemple sous Microsoft Windows.

== Déploiement d'une instance en une commande avec Ansible ==

Vous devrez tout d'abord créer et renseigner/adapter le fichier de configuration ".cloudstack.ini" du module "cs_instance" de Ansible :

<pre>
[CloudIkoulaOne]
endpoint = https://cloudstack.ikoula.com/client/api
key = <clé API de votre utilisateur/compte Cloud IKOULA One>
secret = <clé privée de votre utilisateur/compte Cloud IKOULA One>
timeout = 30
</pre>

Ensuite il suffit de lancer cette commande en adaptant les valeurs des paramètres (nom de votre instance, nom du réseau, etc.) et les paramètres en eux-mêmes (si vous avez/voulez utliser ou non une paire de clé SSH par exemple) :

<pre>
ansible -i "localhost," -c local all -m cs_instance -a "name=<Nom de la VM> display_name=<Nom de la VM> state=present template=< Nom entre simples quotes ou ID du template voulu> api_region=CloudIkoulaOne zone=<Nom de la zone voulu> service_offering=< Nom de l’offre de calcul voulu > networks=<Nom du réseau existant voulu> ssh_key=<Nom de la paire de clés ssh CIO existante>"
</pre>

où "<Nom de l’offre de calcul voulu >" correspond au choix à :

<pre>
"t1.pico" (1/2 Core CPU with 512MB RAM and 100Mbps NIC)
"t1.micro" (1 Core CPU with 1GB RAM and 100Mbps NIC)
"m1.small" (1 Core CPU with 1.7GB RAM and 100Mbps NIC)
"m1.medium" (2 Cores CPU with 3.8GB RAM and 100Mbps NIC)
"m1.large" (4 Cores CPU with 7.6GB RAM and 100Mbps NIC)
"m1.extralarge" (8 Cores CPU with 15.3GB RAM and 100Mbps NIC)
</pre>

Voici un exemple ainsi que le retour de son exécution :

<pre>
$ ansible -i "localhost," -c local all -m cs_instance -a "name=Debian9advz1 display_name=Debian9adv1 state=present template='Debian 9 - Minimal - 64bits' api_region=CloudIkoulaOne zone=EU-FR-IKDC1-Z1-ADV service_offering=t1.micro networks=My-Network-Z1 ssh_key=MY_SSHKEY"
localhost | SUCCESS => {
"account": "ikoula",
"affinity_groups": [],
"changed": true,
"created": "2018-09-12T10:05:00+0200",
"default_ip": "10.1.1.176",
"display_name": "Debian9adv1",
"domain": "ROOT",
"hypervisor": "XenServer",
"id": "3c60acc9-1480-48bc-ab78-934f0e607d6c",
"instance_name": "i-1079-67026-VM",
"name": "Debian9advz1",
"password": "KYqrT3h28qOs",
"password_enabled": true,
"security_groups": [],
"service_offering": "t1.micro",
"ssh_key": "MY_SSHKEY",
"state": "Running",
"tags": [],
"template": "Debian 9 - Minimal - 64bits",
"user_data": "",
"zone": "EU-FR-IKDC1-Z1-ADV"
}
</pre>

Dans cet exemple, nous déployons une instance Debian 9 en zone avancée (EU-FR-IKDC1-Z1-ADV), utilisant l'offre de calcul "t1.micro" dans notre réseau nommé "My-Network-Z1" avec notre paire de clés SSH nommée "MY_SSHKEY"

Pour voir l'ensemble des paramètres utilisables et d'autres exemples, vous pouvez utiliser le ansible-doc du module "cs_instance" :

<pre>
$ ansible-doc cs_instance
> CS_INSTANCE (/usr/lib/python2.7/site-packages/ansible/modules/cloud/cloudstack/cs_instance.py)

Deploy, start, update, scale, restart, restore, stop and destroy instances.

Options (= is mandatory):

- account
Account the instance is related to.
[Default: None]
- affinity_groups
Affinity groups names to be applied to the new instance.
[Default: []]
- api_http_method
HTTP method used.
(Choices: get, post)[Default: get]
- api_key
API key of the CloudStack API.
[Default: None]
- api_region
Name of the ini section in the `cloustack.ini' file.
[Default: cloudstack]
- api_secret
Secret key of the CloudStack API.
[Default: None]
- api_timeout
HTTP timeout.
[Default: 10]
- api_url
URL of the CloudStack API e.g. https://cloud.example.com/client/api.
[Default: None]
- cpu
The number of CPUs to allocate to the instance, used with custom service offerings
[Default: None]
- cpu_speed
The clock speed/shares allocated to the instance, used with custom service offerings
[Default: None]
- disk_offering
Name of the disk offering to be used.
[Default: None]
- disk_size
Disk size in GByte required if deploying instance from ISO.
[Default: None]
...
</pre>

Note : la sortie de la commande est volontairement tronquée du fait de sa longueur.

== Déploiement d'une instance avec un playbook Ansible ==

De la même façon que ci-dessus vous devez tout d'abord créer et renseigner/adapter le fichier de configuration ".cloudstack.ini" du module "cs_instance" de Ansible :

<pre>
[CloudIkoulaOne]
endpoint = https://cloudstack.ikoula.com/client/api
key = <clé API de votre utilisateur/compte Cloud IKOULA One>
secret = <clé privée de votre utilisateur/compte Cloud IKOULA One>
timeout = 30
</pre>

Ensuite il suffit de créer un fichier de playbook (extension yml / format YAML), comme ci-dessous, en adaptant les valeurs des paramètres (nom de votre instance, nom du réseau, etc.) et les paramètres en eux-mêmes (si vous avez/voulez utliser ou non une paire de clé SSH par exemple) :

Exemple de playbook de déploiement d'une instance en zone avancée :

<pre>
$ cat deploy_instance_adv.yml
---

- hosts: all
connection: local
user: root

tasks:

- name: 'Create Debian instance in Cloud IKOULA One with Ansible Playbook'
cs_instance:
name: "<Nom de la VM>"
state: present
display_name: "<Nom de la VM>"
template: "<Nom entre simples quotes ou ID du template CIO voulu>"
api_region: "CloudIkoulaOne"
zone: "<Nom de la zone voulu>"
service_offering: "<Nom de l’offre de calcul voulu >"
networks: "<Nom du réseau existant voulu>"
ssh_key: "<Nom de la paire de clés ssh CIO existante>"
...
</pre>

Exemple de playbook de déploiement d'une instance en zone basic (où on remplace simplement le paramètre réseau par celui des security groups et on ajoute le retour post-déploiement de l'adresse ip publique attribuée à la vm) :

<pre>
$ cat deploy_instance_basic.yml
---

- hosts: all
connection: local
user: root

tasks:

- name: 'Create Debian instance in Cloud IKOULA One with Ansible Playbook'
cs_instance:
name: "<Nom de la VM>"
state: present
display_name: "<Nom de la VM>"
template: "<Nom entre simples quotes ou ID du template CIO voulu>"
api_region: "CloudIkoulaOne"
zone: "<Nom de la zone voulu>"
service_offering: "<Nom de l’offre de calcul voulu >"
security_groups: "<Nom du groupe de sécurité existant voulu>"
ssh_key: "<Nom de la paire de clés ssh CIO existante>"

- name: "VM ip address:"
debug:
var: vminfo.default_ip
...
</pre>

Une fois les paramètres et leurs valeurs adapté(e)s, voici un exemple d'exécution du playbook (adaptez le nom de votre fichier playbook au besoin):

<pre>
$ ansible-playbook -i "localhost," -c local deploy_instance_adv.yml

PLAY [all] ********************************************************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ********************************************************************************************************************************************************************************************************************************************************
ok: [localhost]

TASK [Create Debian instance in Cloud IKOULA One with Ansible Playbook] ********************************************************************************************************************************************************************************************************************************
changed: [localhost]

PLAY RECAP ********************************************************************************************************************************************************************************************************************************************************************
localhost : ok=2 changed=1 unreachable=0 failed=0
</pre>

[[Catégorie :Cloudstack]]
[[Catégorie :Cloud public]]
[[Catégorie:API]]

Deployer vos instances avec Ansible

2019-11-28T10:08:52Z

Lhulotf79a8 : /* Déploiement d'une instance avec un playbook Ansible */

Deployer vos instances avec Ansible

2019-11-28T10:08:07Z

Lhulotf79a8 : /* Déploiement d'une instance avec un playbook Ansible */

2018-11-26T16:25:01Z

Lhulotf79a8 :

Cet article décrit comment créer un volume Docker de type NFS, c'est à dire créer un volume qui va présenter les données d'un export NFS (par exemple un partage nfs depuis un NAS type Synology) puis utiliser celui-ci depuis des containers Docker.

Nous avons effectué cette procédure depuis une instance Cloud Ikoula One et utiliser l'export NFS d'un NAS Synology mais cette procédure est tout à fait opérationnelle sur un serveur dédié et avec un export NFS standard.

Nous partirons du principe que vous avez déjà accès à un système avec Docker installé et d'un export NFS existant.

== Création du volume Docker de type NFS : ==

Voici la commande permettant de créer un volume Docker de type NFS en accès lecture/écriture depuis un export NFS existant :

<syntaxhighlight lang="bash">
[root@ikoula ~]# docker volume create --driver local --opt type=nfs --opt o=addr=<adresse ip serveur nfs>,rw --opt device=:<chemin export nfs> <nom du volume NFS Docker>
</syntaxhighlight>

Note: vous pouvez évidemment nommer votre volume Docker comme vous le souhaitez.

ce qui donne dans notre cas (notre volume est créé à partir d'un export NFS "/volume1/datas" d'un NAS synology) :

<syntaxhighlight lang="bash">
[root@CentOS7 ~]# docker volume create --driver local --opt type=nfs --opt o=addr=213.246.x.x,rw --opt device=:/volume1/datas synodatas
synodatas
</syntaxhighlight>

Notre volume NFS est maintenant présent dans la liste des volumes Docker :

<syntaxhighlight lang="bash">
[root@CentOS7 ~]# docker volume ls
DRIVER VOLUME NAME
local synodatas
</syntaxhighlight>

Nous pouvons également inspecter notre volume :

<syntaxhighlight lang="bash">
[root@CentOS7 ~]# docker volume inspect synodatas
[
{
"CreatedAt": "2018-11-26T11:00:27+01:00",
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/synodatas/_data",
"Name": "synodatas",
"Options": {
"device": ":/volume1/datas",
"o": "addr=213.246.x.x,rw",
"type": "nfs"
},
"Scope": "local"
}
]
</syntaxhighlight>

== Utilisation du volume Docker de type NFS sur des containers Docker : ==

'''Il faut préalablement avoir installé le client NFS sur l'hôte.'''

Dans notre cas, l'hôte (une instance CIO) est en "Centos7", il suffit d'installer le paquet "nfs-utils" :

<syntaxhighlight lang="bash">
[root@CentOS7 ~]# yum install nfs-utils
</syntaxhighlight>

Nous pouvons maintenant utiliser notre volume Docker de type NFS créé précédemment sur un ou plusieurs container via la commande suivante :

<syntaxhighlight lang="bash">
[root@CentOS7 ~]# docker run -d -it --name <Nom container> --mount source=<Nom du volume NFS>,target=<point de montage du contenu du volume NFS dans le container> <Nom image docker>
</syntaxhighlight>

Ce qui donne dans notre cas (on crée un container nommé "deb9" à partir de l'image debian dans lequel on monte le contenu de notre volume NFS "synodatas" sur le point de montage /mnt) :

<syntaxhighlight lang="bash">
[root@CentOS7 ~]# docker run -d -it --name deb9 --mount source=synodatas,target=/mnt debian
ce6328ab1a44c8c7a07e2fd9c4022d33d394828376d3cb10171bbdeec745371a
</syntaxhighlight>

La section "mount" de notre container ("docker inspect deb9) :

<syntaxhighlight lang="bash">
"Mounts": [
{
"Type": "volume",
"Name": "synodatas",
"Source": "/var/lib/docker/volumes/synodatas/_data",
"Destination": "/mnt",
"Driver": "local",
"Mode": "z",
"RW": true,
"Propagation": ""
}
],
</syntaxhighlight>

Si on se connecte à notre container deb9, on peut lister les fichiers de notre export/volume docker NFS depuis le point de montage :

<syntaxhighlight lang="bash">
[root@CentOS7 ~]# docker exec -it deb9 /bin/bash
root@ce6328ab1a44:/# ls -1 /mnt/
file_test1
file_test2
file_test3
file_test4
file_test5
</syntaxhighlight>

Comme nous avons crée notre volume Docker en lecture/écriture, nous pouvons également créer ou modifier des fichiers sur ce dernier depuis notre container :

<syntaxhighlight lang="bash">
root@ce6328ab1a44:/# touch /mnt/testfromdocker
root@ce6328ab1a44:/#
</syntaxhighlight>

Vous l'aurez compris cette procédure vous permet d'utiliser du stockage persistant au sein d'un ou plusieurs containers Docker (simultanément ou non) via un volume Docker de type NFS en utilisant par exemple un export NFS de votre NAS.

Pour aller plus loin :

https://docs.docker.com/storage/volumes/

[[category:cloudstack]]
[[category:cloud public]]
[[category:cloud privé]]
[[category:Docker]]
[[category:Synology]]
[[Catégorie:FLEX]]
[[category:Serveur_dédié]]
[[Catégorie:Linux]]

2018-11-06T07:48:19Z

Lhulotf79a8 : /* Actions à effectuer sur toutes les instances (master et workers) en tant que root ou avec les droits sudo nécessaires : */

Cette procédure va vous permettre de déployer rapidement et facilement un cluster de trois nodes Kubernetes (nommé également via le raccourci "k8s") à partir de trois instances CentOS 7 déployées dans le 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 le node master est le node depuis lequel on gère le cluster Kubernetes depuis l'API et les nodes workers sont les nodes sur lesquelles s'exécuteront les conteneurs Docker. Ce n'est pas l'objet de cette procédure mais sachez qu'il est possible d'avoir une configuration Haute Disponibilité avec par exemple deux nodes master.

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.

Voici la configuration que nous avons dans notre exemple :

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

== Actions à 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 de vos instances afin qu'elles puissent résoudre leur nom d'hôte respectivement (normalement déjà le cas dans un réseau en zone avancé où le routeur virtuel fait notamment office de résolveur DNS interne). 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>

Installez Docker :

<syntaxhighlight lang="bash">
yum install -y docker-ce
</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 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 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 kubeadm) :

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

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

== Action à n'effectuer que sur l'instance node master : ==

Lancez l'initilalisation de votre cluster Kubernetes via la commande suivante en prenant soin de modifier l'ip du paramètre "--apiserver-advertise-address=" par celle 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 garder tel quel l'ip du réseau "10.244.0.0/16" indiquée dans le paramètre "--pod-network-cidr=" qui permet d'indiquer que nous allons utiliser le plugin CNI Flannel pour gérer la partie réseau de nos pods.

Voici à quoi ressemble le retour de cette commande quand le cluster s'initalise 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 :

soit la création d'un répertoire et fichie de config pour notre utilisateur courante (root dans notre cas) :

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

le déploiement de 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 de côté afin de l'exécuter ensuite sur nos instances workers pour les faire joindre notre cluster.

On peut maintenant effectuer les premières vérifications de notre cluster :

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

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>

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, 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 à faire 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" depuis

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

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>

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 de notre premier pod / conteneur : ==

Nous allons déployer notre premier pod/conteneur dans notre cluster Kubernetes fraichement créé.

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 notre 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 notre liste dans un namespace différent de "kube-system" puisqu'il ne s'agit pas d'un composant propre à Kubernetes.

Il est d'ailleurs possible de ne pas afficher les pods propre au namespace kube-system en effectuant la 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 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>

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.

Nous pouvons également simplement exécuté 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 nous reste plus qu'à créer notre règle de load balancing sur Cloud Ikoula One pour accéder à /rendre publique notre serveur web :

- Connectez-vous à l'interface Cloud Ikoula One (https://cloudstack.ikoula.com/client)
- 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]]

ce qui donne :

[[File:faq_k8s_regle_lb-03.png]]

Tester l'accès à votre server web / pod nginx depuis votre navigateur :

[[File:faq_k8s_browser_nginx.png]]

Le fait que votre pod nginx soit accessible depuis n'importe lequel de vos nodes est 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.