Een Kubernetes cluster implementeren

ja:Kubernetesクラスタのデプロイ zh:部署一个Kubernetes集群 de:Bereitstellen eines Kubernetes-Clusters fr:Deployer un cluster Kubernetes
Dit artikel is vertaald door middel van automatische vertalingssoftware. U kunt het artikel bron hier te bekijken.

pt:Implantação de um aglomerado Kubernetes es:Despliegue de un clúster Kubernetes en:Deploying a Kubernetes cluster it:Configurare un cluster Kubernetes fr:Deployer un cluster Kubernetes

Wat is Kubernetes?

Kubernetes is een open-source platform voor het beheer van gecontaineriseerde workloads en diensten. Het ondersteunt declaratief configuratie schrijven maar ook automatisering. Kubernetes is een groot en snel groeiend ecosysteem.

Deze procedure zal u toelaten om snel en gemakkelijk een cluster van drie knooppunten op te zetten Kubernetes (k8s) Met deze procedure kunt u snel en eenvoudig een cluster van drie knooppunten implementeren vanaf drie CentOS 7 instances die binnen hetzelfde netwerk in een voorwaartse zone zijn geïmplementeerd.

Eén van deze drie instanties zal onze master node zijn en de andere twee zullen onze worker nodes zijn. Eenvoudig samengevat is de master node de node van waaruit we de Kubernetes cluster (container orchestrator) beheren vanuit zijn API en de worker nodes zijn de nodes waarop de pods of containers (Docker in ons geval) zullen draaien.

We zullen aannemen dat uw 3 CentOS 7 instances al zijn uitgerold en dat u ssh toegang tot ze hebt om de commando's uit te voeren die zullen volgen.

Hier is de configuratie die we in ons voorbeeld hebben en die in deze hele procedure als voorbeeld zal worden gebruikt:

Node master: "k8s-master" / 10.1.1.16
Eerste nodewerker: "k8s-werker01" / 10.1.1.169
Tweede nodewerker: "k8s-werker02" / 10.1.1.87

Systeemvoorbereiding en Kubernetes installatie tutorial

De volgende acties moeten uitgevoerd worden op alle instanties (master en workers) als root (of met de nodige sudo rechten).

Begin met het vullen van het /etc/hosts bestand op elk van je instances zodat ze hun respectievelijke hostnaam kunnen oplossen (normaal gezien reeds het geval in een geavanceerd zonenetwerk waar de virtuele router een DNS resolver is).

In ons voorbeeld geeft dit het volgende /etc/hosts bestand op onze drie instances (pas het aan met de naam en ip van je instances):

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

Schakel de bridge module en de iptables regels ervoor in met de volgende drie commando's:

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

Voeg de YUM Docker repository toe :

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

Voeg de YUM Kubernetes repository toe :

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
        https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

Docker installeren :

yum install -y docker-ce

Installeer dan de nodige Kubernetes pakketten:

yum install -y kubeadm kubelet kubectl

Bewerk het configuratiebestand van het systemd kubelet (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) configuratiebestand om de volgende regel toe te voegen in de "[Service]" sectie:

Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"

zodanig dat :

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

Herlaad de configuratie, activeer en start de docker en kubelet diensten via de volgende drie commando's:

systemctl daemon-reload systemctl enable docker kubelet systemctl start docker kubelet </syntaxhighlight>

Schakel de systeemswap uit (kubelet ondersteunt geen swap geheugen, je zult een fout krijgen tijdens de pre-flight checks bij het initialiseren van je cluster via kubeadms als je het niet uitschakelt):

swapoff -a

vergeet niet om ook de swap regel te commentariëren/verwijderen in het /etc/fstab bestand van elk van uw instanties zoals :

#/dev/mapper/vg01-swap  swap            swap    defaults                0       0

Initialisatie van het Kubernetes cluster

De volgende acties moeten alleen worden uitgevoerd op de node master instance

Start de initialisatie van je Kubernetes cluster via het onderstaande commando, en zorg ervoor dat je de waarde van de "--apiserver-advertise-address=" parameter aanpast met het ip adres van je master instance.

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

Opmerking: Wijzig het netwerk ip "10.244.0.0/16" aangegeven in de "--pod-network-cidr=" parameter niet omdat deze parameter ons toelaat om aan te duiden dat we de CNI Flannel plugin gaan gebruiken om het netwerk gedeelte van onze pods te beheren.

Hier is hoe de terugkeer van dit commando eruit zou moeten zien als het cluster succesvol initialiseert:

[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

Wij voeren de gevraagde operaties uit om de initialisatie van ons cluster af te ronden:

We maken een directory en een configuratiebestand aan in de directory van onze gebruiker (root in ons geval):

mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

We zetten ons pod Flannel netwerk in voor ons cluster:

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

opmerking: we zullen het laatste commando bewaren dat wordt geleverd door de terugkeer van het zij-initialisatiecommando ("kubeadm join...") om het later uit te voeren op onze worker instances om ze aan ons cluster toe te voegen.

We kunnen nu de eerste controles van ons cluster doen vanaf onze master instantie:

Type het commando "kubectl get nodes" om de nodes te controleren die momenteel in je cluster aanwezig zijn:

[root@k8s-master ~]# kubectl get nodes
NAME                             STATUS   ROLES    AGE   VERSION
k8s-master.cs437cloud.internal   Ready    master   41m   v1.12.2

Merk op: er is momenteel alleen uw master node, wat normaal is aangezien we de andere nodes nog niet aan het cluster hebben toegevoegd.

Type het commando "kubectl get pods --all-namespaces" om de pods/containers te controleren die momenteel aanwezig zijn in je cluster:

[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

Opmerking: Er zijn alleen pods die overeenkomen met de Kubernetes componenten die nodig zijn voor onze master node (kube-apiserver, etcd, kube-scheduler, etc).

We kunnen de status van deze componenten controleren met het volgende commando:

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

Werkknooppunten toevoegen aan het cluster

Acties die alleen op werkersinstanties/nodes moeten worden uitgevoerd

Voer op elk van je worker instances (doe dit niet op je master instantie), het "kubeadm join ..." commando uit dat aan het einde van je cluster initialisatie hierboven staat:

[root@k8s-worker01 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
        [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
 1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker01.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.

[root@k8s-worker02 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
        [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_wrr ip_vs_sh ip_vs ip_vs_rr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
 1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker02.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.

De status van het cluster controleren

Acties die moeten worden uitgevoerd vanaf de master instantie/node

Controleer of je worker nodes zijn toegevoegd aan je cluster door het commando "kubectl get nodes" opnieuw uit te voeren:

[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

Opmerking : We kunnen onze twee worker nodes zien (k8s-worker01 en k8s-worker02), dus ze zijn toegevoegd aan ons cluster.

Laten we nu het "kubectl get pods --all-namespaces" commando opnieuw uitvoeren:

[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

Opmerking: U kunt zien dat er net zoveel "kube-flannel" en "kube-proxy" pods/containers zijn als we nodes in ons cluster hebben.

Inzet van een eerste peul

We zullen onze eerste pod in onze Kubernetes cluster.

Om het eenvoudig te houden, kiezen we ervoor om een pod te deployen (zonder replicas) met de naam "nginx" en gebruikmakend van het "nginx" image:

[root@k8s-master ~]# kubectl create deployment nginx --image=nginx
deployment.apps/nginx created

Als we controleren, verschijnt deze goed bij de terugkeer van het commando dat de pods van ons cluster opsomt:

[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

Het verschijnt bovenaan de lijst in een andere namespace dan "kube-system" omdat het geen component is die specifiek is voor de werking van Kubernetes.

Het is ook mogelijk om het weergeven van pods die specifiek zijn voor de kube-systeemnaamruimte te vermijden door ditzelfde commando uit te voeren zonder de "--all-namespace" parameter:

[root@k8s-master ~]# kubectl get pods
NAME                      READY   STATUS    RESTARTS   AGE
nginx-55bd7c9fd-vs4fq     1/1     Running   0          3d2h

Om de etiketten weer te geven :

[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

We kunnen ook onze implementaties controleren met het volgende commando:

[root@k8s-master ~]# kubectl get deployments
NAME    DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx   1         1         1            1           93m

Dus we hebben een nginx pod uitgerold en gestart, maar hij is nog niet toegankelijk van buitenaf. Om het extern toegankelijk te maken, moeten we de poort van onze pod blootstellen door de service (van het type NodePort) aan te maken via het volgende commando:

[root@k8s-master ~]# kubectl create service nodeport nginx --tcp=80:80
service/nginx created

Zo is onze dienst ontstaan:

[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

Opmerking: Het luistert op poort 80/tcp en zal van buitenaf beschikbaar/openbaar zijn op poort 30566/tcp

We kunnen het flannel ip van onze pod opvragen en de naam van het knooppunt waar hij momenteel op draait via het volgende commando:

[root@k8s-master ~]# kubectl get pods --selector="app=nginx" --output=wide
NAME                    READY   STATUS    RESTARTS   AGE    IP           NODE                               NOMINATED NODE
nginx-55bd7c9fd-vs4fq   1/1     Running   0          174m   10.244.2.2   k8s-worker02.cs437cloud.internal   <none>

Hier heeft onze nginx pod het ip 10.244.2.2 en draait op onze node k8s-worker02.

Je kan ook gewoon een commando uitvoeren of een shell openen op onze nginx pod via het volgende commando (heel gelijkaardig aan het docker commando):

[root@k8s-master ~]# kubectl exec -it nginx-55bd7c9fd-vs4fq -- /bin/bash
root@nginx-55bd7c9fd-vs4fq:/#

Het enige wat je moet doen is een load balancing regel aanmaken op je Ikoula One Cloud netwerk om je web server (nginx pod) te benaderen / publiek te maken:

- Aansluiten op de Wolk Ikoula Een

- ga naar "Netwerk" in het linker verticale menu

- klik op je netwerk waarin je je Kubernetes instances hebt geïmplementeerd, dan op "View IP Addresses" en op je NAT Source ip en ga naar de "Configuration" tab

- klik op "Load Balancing" en creëer uw regel door een naam op te geven, de publieke poort "80" in ons geval, de private poort "30566" in ons geval (zie hierboven), door een LB algoritme te kiezen (bijv. round-robin) zoals :

Kubernetes-instance

- vink al je werkinstanties aan:

Controleer uw kubernetes worker instances

Test de toegang tot je webserver / nginx pod vanuit je browser (via het publieke ip van je netwerk waarop je de LB regel hebt aangemaakt):

Toegang tot uw webserver

Het feit dat je nginx pod benaderd kan worden vanaf elk van je nodes wordt mogelijk gemaakt door de "kube-proxy" component die verantwoordelijk is voor het doorverwijzen van verbindingen naar de node(s) waarop hij draait (in het geval van replicaties).

Dus je hebt net een basis Kubernetes cluster van 3 nodes met een master en twee workers opgezet.

Ga verder

Je kan verder gaan door het Kubernetes dashboard te implementeren of door persistente volumes te creëren voor je pods, door het aantal van je worker nodes te verhogen, of zelfs door de master rol redundant toe te wijzen voor hoge beschikbaarheid of door nodes toe te wijzen aan bepaalde componenten zoals Etcd bijvoorbeeld.

Hier zijn enkele nuttige links:

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

https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/

https://kubernetes.io/docs/concepts/storage/volumes/

https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

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