it-wiki:kubernetes:installation
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
it-wiki:kubernetes:installation [2022/11/06 17:51] – angelegt marko | it-wiki:kubernetes:installation [2025/04/04 08:40] (aktuell) – marko | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
====== Kubernetes Installation ====== | ====== Kubernetes Installation ====== | ||
+ | ===== Manuelle Installation der Kubernetes-Binaries ===== | ||
+ | **Kernel-Module in die ''/ | ||
+ | <code bash> | ||
+ | br_netfilter | ||
+ | overlay | ||
+ | </ | ||
+ | **Kernel-Module laden:** | ||
+ | <code bash> | ||
+ | modprobe br_netfilter | ||
+ | modprobe overlay | ||
+ | </ | ||
+ | **System-Konfiguration anpassen (''/ | ||
+ | <code bash> | ||
+ | net.ipv4.ip_forward=1 | ||
+ | net.bridge.bridge-nf-call-iptables=1 | ||
+ | net.bridge.bridge-nf-call-ip6tables=1 | ||
+ | </ | ||
+ | |||
+ | **System-Konfiguration laden: ** | ||
+ | <code bash> | ||
+ | sysctl -p / | ||
+ | </ | ||
+ | |||
+ | **Docker-Repository-Schlüssel vertrauen: ** | ||
+ | <code bash> | ||
+ | apt install gpg | ||
+ | curl -fsSL https:// | ||
+ | </ | ||
+ | |||
+ | **Docker-Repository hinzufügen (''/ | ||
+ | <code bash> | ||
+ | deb https:// | ||
+ | </ | ||
+ | |||
+ | **Repositories aktuallisieren: | ||
+ | <code bash> | ||
+ | apt update | ||
+ | </ | ||
+ | |||
+ | **containerd installieren: | ||
+ | <code bash> | ||
+ | apt install ' | ||
+ | </ | ||
+ | |||
+ | **containerd-Standard-Konfiguration speichern: ** | ||
+ | <ode bash> | ||
+ | containerd config default > / | ||
+ | </ | ||
+ | |||
+ | '' | ||
+ | <code bash> | ||
+ | sandbox_image = " | ||
+ | |||
+ | [plugins." | ||
+ | SystemdCgroup = true | ||
+ | </ | ||
+ | |||
+ | Bei einer eigenen Registry muss dies noch zusätzlich als Mirror eingetragen werden. | ||
+ | <code bash> | ||
+ | [plugins." | ||
+ | endpoint = [" | ||
+ | </ | ||
+ | |||
+ | **containerd neustarten: ** | ||
+ | <code bash> | ||
+ | systemctl restart containerd.service | ||
+ | </ | ||
+ | |||
+ | **''/ | ||
+ | code bash> | ||
+ | runtime-endpoint: | ||
+ | image-endpoint: | ||
+ | </ | ||
+ | |||
+ | **Kubernetes-Repository-Schlüssel vertrauen: ** | ||
+ | <code bash> | ||
+ | curl -fsSL https:// | ||
+ | </ | ||
+ | |||
+ | **Kubernetes-Repository hinzufügen (''/ | ||
+ | <code bash> | ||
+ | deb https:// | ||
+ | </ | ||
+ | |||
+ | **Repositories aktuallisieren: | ||
+ | <code bash> | ||
+ | apt update | ||
+ | </ | ||
+ | |||
+ | **Kubernetes-Binaries installieren: | ||
+ | <code bash> | ||
+ | apt install kubeadm=1.31.7-00 kubectl=1.31.7-00 kubelet=1.31.7-00 | ||
+ | </ | ||
+ | |||
+ | **Automatische Upgrades verhindern: ** | ||
+ | <code bash> | ||
+ | apt-mark hold kubeadm kubectl kubelet | ||
+ | </ | ||
+ | |||
+ | ===== Installation des Clusters ===== | ||
+ | |||
+ | Das Setup des Clusters erfolgt in drei Schritten: | ||
+ | 1. auf dem ersten Knoten ('' | ||
+ | 2. die Control-Plane des Clusters wird um zwei Knoten erweitert ('' | ||
+ | 3. dem Cluster werden zwei Worker-Knoten hinzugefügt ('' | ||
+ | |||
+ | ==== Initialisierung des Clusters ==== | ||
+ | **kube-vip.yml** | ||
+ | |||
+ | <code yaml> | ||
+ | --- | ||
+ | # task: install kube-vip for HA Kubernetes Controlplane | ||
+ | # hint: see https:// | ||
+ | # | ||
+ | apiVersion: v1 | ||
+ | kind: Pod | ||
+ | metadata: | ||
+ | creationTimestamp: | ||
+ | name: kube-vip | ||
+ | namespace: kube-system | ||
+ | spec: | ||
+ | containers: | ||
+ | - args: | ||
+ | - manager | ||
+ | env: | ||
+ | - name: address | ||
+ | value: need-to-be-set | ||
+ | - name: port | ||
+ | value: " | ||
+ | - name: vip_arp | ||
+ | value: " | ||
+ | - name: vip_interface | ||
+ | value: ens3 # | ||
+ | - name: vip_cidr | ||
+ | value: " | ||
+ | - name: cp_enable | ||
+ | value: " | ||
+ | - name: cp_namespace | ||
+ | value: kube-system | ||
+ | - name: vip_ddns | ||
+ | value: " | ||
+ | - name: svc_enable | ||
+ | value: " | ||
+ | - name: vip_leaderelection | ||
+ | value: " | ||
+ | - name: vip_leaseduration | ||
+ | value: " | ||
+ | - name: vip_renewdeadline | ||
+ | value: " | ||
+ | - name: vip_retryperiod | ||
+ | value: " | ||
+ | image: ghcr.io/ | ||
+ | imagePullPolicy: | ||
+ | name: kube-vip | ||
+ | resources: {} | ||
+ | securityContext: | ||
+ | capabilities: | ||
+ | add: | ||
+ | - NET_ADMIN | ||
+ | - NET_RAW | ||
+ | - SYS_TIME | ||
+ | volumeMounts: | ||
+ | - mountPath: / | ||
+ | name: kubeconfig | ||
+ | hostAliases: | ||
+ | - hostnames: | ||
+ | - kubernetes | ||
+ | ip: 127.0.0.1 | ||
+ | hostNetwork: | ||
+ | volumes: | ||
+ | - hostPath: | ||
+ | path: / | ||
+ | name: kubeconfig | ||
+ | </ | ||
+ | Die kube-vip.yaml muss auf alle controlplan Nodes unter `/ | ||
+ | Desweiteren muss **nach dem Initialisieren** und **vor dem joinen** der anderen control plane Nodes in den Cluster die `/ | ||
+ | |||
+ | |||
+ | Für die Initialisierung des Clusters wird auf dem ersten Knoten ('' | ||
+ | <code yaml> | ||
+ | apiVersion: kubeadm.k8s.io/ | ||
+ | kind: ClusterConfiguration | ||
+ | kubernetesVersion: | ||
+ | controlPlaneEndpoint: | ||
+ | networking: | ||
+ | podSubnet: 100.73.0.0/ | ||
+ | serviceSubnet: | ||
+ | --- | ||
+ | apiVersion: kubelet.config.k8s.io/ | ||
+ | kind: KubeletConfiguration | ||
+ | cgroupDriver: | ||
+ | serverTLSBootstrap: | ||
+ | resolvConf: / | ||
+ | </ | ||
+ | |||
+ | Die beiden Subnetze können angepasst werden und sollten sich nicht mit der Netzwerkkonfiguration des Hosts überschneiden. | ||
+ | |||
+ | **Mit der Cluster-Konfiguration wird der Cluster initialisiert**: | ||
+ | <code bash> | ||
+ | kubeadm init --config=init.yml --upload-certs | ||
+ | </ | ||
+ | |||
+ | Die Option '' | ||
+ | |||
+ | Hat alles funktioniert, | ||
+ | |||
+ | ==== Erweiterung der Control-Plane ==== | ||
+ | |||
+ | Wenn die Cluster-Initialisierung abgeschlossen ist, kann die Control-Plane um zwei Knoten ('' | ||
+ | <code bash> | ||
+ | kubeadm join kubeapi.tuxnet.lab: | ||
+ | </ | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | Der Certificate-Key ist zwei Stunden gültig. Falls seit der Cluster-Initialisierung mehr als zwei Stunden vergangen sind, kann ein neuer Schlüssel erzeugt werden (die Doppelung im Befehl ist notwendig): | ||
+ | <code bash> | ||
+ | kubeadm init phase upload-certs --upload-certs | ||
+ | </ | ||
+ | |||
+ | ==== Hinzufügen der Worker-Knoten ==== | ||
+ | |||
+ | Ist die Control-Plane vollständig, | ||
+ | <code bash> | ||
+ | kubeadm join kubeapi.tuxnet.lab: | ||
+ | </ | ||
+ | |||
+ | Der Token ist 24 Stunden gültig. Soll nach Ablauf dieser Zeit ein Knoten hinzugefügt werden, muss ein neuer Token erzeugt werden: | ||
+ | <code bash> | ||
+ | kubeadm token create --print-join-command | ||
+ | </ | ||
+ | |||
+ | ===== kubectl auf dem Jumphost einrichten ===== | ||
+ | |||
+ | Das Cluster ist jetzt vollständig. Die weitere Administration des Clusters soll vom Jumphost aus erfolgen. | ||
+ | |||
+ | Dazu wird zunächst '' | ||
+ | <code bash> | ||
+ | mkdir bin | ||
+ | source .profile | ||
+ | wget -O bin/kubectl https:// | ||
+ | chmod +x bin/kubectl | ||
+ | </ | ||
+ | |||
+ | Die Konfiguration für '' | ||
+ | <code bash> | ||
+ | mkdir -m 700 .kube | ||
+ | scp root@control1.tuxnet.lab:/ | ||
+ | </ | ||
+ | |||
+ | Jetzt ist der Zugriff auf Clusters vom Jumphost aus möglich: | ||
+ | <code bash> | ||
+ | user0@jumphost: | ||
+ | NAME STATUS | ||
+ | control1 | ||
+ | control2 | ||
+ | control3 | ||
+ | node1 NotReady | ||
+ | node2 NotReady | ||
+ | </ | ||
+ | |||
+ | ===== Abschluss der Cluster-Installation ===== | ||
+ | ==== Calico installieren ==== | ||
+ | |||
+ | Bisher werden die Knoten als '' | ||
+ | |||
+ | Daher wird jetzt '' | ||
+ | <code bash> | ||
+ | kubectl apply -f https:// | ||
+ | </ | ||
+ | |||
+ | Nach einer Weile sind die Knoten '' | ||
+ | <code bash> | ||
+ | user0@jumphost: | ||
+ | NAME STATUS | ||
+ | control1 | ||
+ | control2 | ||
+ | control3 | ||
+ | node1 | ||
+ | node2 | ||
+ | </ | ||
+ | |||
+ | ==== Kubelet-Zertifikate signieren ==== | ||
+ | |||
+ | Als letzter Schritt müssen die Kubelet-Zertifikate signiert werden. Dazu werden zunächst die offenen Zertifikatsanfragen angezeigt: | ||
+ | <code bash> | ||
+ | kubectl get certificatesigningrequests | grep -i pending | ||
+ | </ | ||
+ | |||
+ | Die jeweils jüngste Anfrage eines Knotens wird signiert: | ||
+ | <code bash> | ||
+ | kubectl certificate approve csr-xxxxx csr-yyyyy csr-zzzzz | ||
+ | </ | ||
+ | |||
+ | Alternativ | ||
+ | '' | ||
+ | '' | ||
+ | '' | ||
+ | |||
+ | An dieser Stelle ist das Setup des Cluster abgeschlossen. | ||
+ | |||
+ | |||
+ | ==== kubectl von Adminworkstation ==== | ||
+ | |||
+ | https:// | ||
+ | |||
+ | <code bash> | ||
+ | mkdir bin | ||
+ | source .profile | ||
+ | wget https:// | ||
+ | chmod +x kubectl | ||
+ | mv kubectl bin | ||
+ | mkdir .kube | ||
+ | scp root@master-x:/ | ||
+ | </ | ||
+ | |||
+ | ==== Bash Anpassungen ==== | ||
+ | '' | ||
+ | <code bash> | ||
+ | # enable bash completion | ||
+ | source < | ||
+ | alias k=kubectl | ||
+ | complete -F __start_kubectl k | ||
+ | </ | ||
+ | |||
+ | '' | ||
+ | |||
+ | === oder === | ||
+ | <code bash> | ||
+ | mkdir -p ~/ | ||
+ | kubectl completion bash > ~/ | ||
+ | </ | ||
+ | und in der .bashrc dann | ||
+ | <code bash> | ||
+ | # kubectl bash complition | ||
+ | source < | ||
+ | </ | ||
+ | |||
+ | === oder === | ||
+ | am Ende der .profile | ||
+ | <code bash> | ||
+ | # kubectl alias and bash completion | ||
+ | # https:// | ||
+ | source < | ||
+ | alias k=kubectl | ||
+ | complete -F __start_kubectl k | ||
+ | </ | ||
+ | |||
+ | |||
+ | Für Helm würde selbiges funktionieren | ||
+ | <code bash> | ||
+ | mkdir -p ~/ | ||
+ | helm completion bash > ~/ | ||
+ | </ | ||
+ | ==== Installation Krew PlugIn Manager ===== | ||
+ | <code yaml> | ||
+ | ( set -x; cd " | ||
+ | export PATH=" | ||
+ | echo ' | ||
+ | kubectl krew | ||
+ | kubectl krew update | ||
+ | kubectl krew install ctx | ||
+ | kubectl krew install neat | ||
+ | </ |
it-wiki/kubernetes/installation.1667757076.txt.gz · Zuletzt geändert: 2022/11/06 17:51 von marko