Een Kubernetes cluster implementeren
ro:Implementarea unui cluster Kubernetes
ru:Развертывание кластера Kubernetes
pl:Wdrażanie klastra Kubernetes
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 :
- 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):
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/tutorials/stateful-application/mysql-wordpress-persistent-volume/