Kubernetes Cluster in Proxmox VE (AlmaLinux/CentOS): Unterschied zwischen den Versionen

Zur Navigation springen Zur Suche springen
K
keine Bearbeitungszusammenfassung
KKeine Bearbeitungszusammenfassung
KKeine Bearbeitungszusammenfassung
 
(40 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
__NOINDEX__
{{Infobox
| Titel      = Testumgebung
| Bildname  =
| Bildbreite =
| Bildtext  =
| Stil            = 2
| Titelfarbe      = 6
| Abschnittsfarbe =
| Farbe          =
| Style          =
| Feldstyle      =
| Feldname1 = OS    | Daten1 = AlmaLinux 8.7
| Feldname3 = Kubernetes    | Daten3 = 1.26.0
| Feldname4 = K8s-Dashboard    | Daten4 = 2.7.0
| Feldname5 = Metrics-Server    | Daten5 = 0.6.2
}}


Anleitung um ein Kubernetes Cluster innerhalb von Proxmox VE einzurichten.
Anleitung um ein Kubernetes Cluster innerhalb von Proxmox VE einzurichten.
Zeile 5: Zeile 20:
Die Installation in einem VM Cluster wie Proxmox bietet sich aufgrund der Zeitersparnis an, dennoch sollte aber alles hier beschriebene grundsätzlich auch auf "echten" Maschinen funktionieren.
Die Installation in einem VM Cluster wie Proxmox bietet sich aufgrund der Zeitersparnis an, dennoch sollte aber alles hier beschriebene grundsätzlich auch auf "echten" Maschinen funktionieren.


'''''Getestet auf AlmaLinux 8'''''


== Vorbereitungen ==
== Vorbereitungen ==
Zeile 20: Zeile 32:
Mindestanforderungen: 2 GB RAM / 2 Cores / 32 GB Speicherplatz
Mindestanforderungen: 2 GB RAM / 2 Cores / 32 GB Speicherplatz


Hinweis:
'''''Hinweis:'''''


''Viele Kubernetes Deployments nutzen MongoDB als Datenbank.''
''Einige Kubernetes Deployments nutzen MongoDB als Datenbank.''


''Ab MongoDB 5.0 werden keine Systeme mehr unterstützt die das AVX-Flag nicht haben.''
''Ab MongoDB 5.0 werden keine Systeme mehr unterstützt deren CPU das AVX-Flag nicht gesetzt hat.''


''Damit es später keine Probleme gibt, sollte als CPU daher nicht 'kvm64' sondern 'host' ausgewählt werden.''
''Damit es später keine Probleme gibt, sollte daher als CPU nicht 'kvm64' sondern 'host' ausgewählt werden.''
 
Dies wird ebenfalls empfohlen um "Nested Virtualization" zu nutzen, wodurch die Performance erheblich verbessert werden kann.<ref>https://pve.proxmox.com/wiki/Nested_Virtualization</ref>


=== Controller und Worker ===
=== Controller und Worker ===
Zeile 56: Zeile 70:
</syntaxhighlight>Die neu erzeugte config.toml bearbeiten:<syntaxhighlight lang="bash">
</syntaxhighlight>Die neu erzeugte config.toml bearbeiten:<syntaxhighlight lang="bash">
vi /etc/containerd/config.toml
vi /etc/containerd/config.toml
</syntaxhighlight>Damit Kubernetes die Ressourcen(RAM/CPU) des Hosts verwalten kann, muss in der config.toml eine Option angepasst werden.
</syntaxhighlight>
Damit Kubernetes die Ressourcen(RAM/CPU) des Hosts verwalten kann, muss in der config.toml eine Option angepasst werden.


Folgenden Absatz suchen und <code>SystemdCgroup</code> auf '''true''' setzen (Suchen in vi mit <code>/<Suchbegriff></code>)<ref>https://kubernetes.io/docs/setup/production-environment/container-runtimes/#cgroup-drivers</ref>:<syntaxhighlight lang="bash" line="1">
Folgenden Absatz suchen und <code>SystemdCgroup</code> auf '''true''' setzen (Suchen in vi mit <code>/<Suchbegriff></code>)<ref>https://kubernetes.io/docs/setup/production-environment/container-runtimes/#cgroup-drivers</ref>:<syntaxhighlight lang="bash" line="1">
Zeile 75: Zeile 90:
</syntaxhighlight>Folgende Zeile am Ende einfügen, bzw. auskommentieren, falls schon vorhanden:<syntaxhighlight lang="bash">
</syntaxhighlight>Folgende Zeile am Ende einfügen, bzw. auskommentieren, falls schon vorhanden:<syntaxhighlight lang="bash">
net.ipv4.ip_forward=1
net.ipv4.ip_forward=1
</syntaxhighlight>Damit Kubernetes die internen VxLAN erstellen kann und die Pods(Container) untereinander kommunizieren können, muss das '''br_netfilter''' Modul aktiviert werden.<ref>https://docs.oracle.com/en/operating-systems/olcne/1.1/start/netfilter.html</ref>
</syntaxhighlight>
Damit Kubernetes die internen VxLAN erstellen kann und die Pods(Container) untereinander kommunizieren können, muss das '''br_netfilter''' Modul aktiviert werden.<ref>https://docs.oracle.com/en/operating-systems/olcne/1.1/start/netfilter.html</ref>


Hierfür wird eine neue Config-Datei erstellt:<syntaxhighlight lang="bash">
Hierfür wird eine neue Config-Datei erstellt:
<syntaxhighlight lang="bash">
vi /etc/modules-load.d/k8s.conf
vi /etc/modules-load.d/k8s.conf
</syntaxhighlight>Dort einfach den Namen des zu ladenden Moduls einfügen:<syntaxhighlight lang="bash">
</syntaxhighlight>Dort einfach den Namen des zu ladenden Moduls einfügen:<syntaxhighlight lang="bash">
br_netfilter
br_netfilter
</syntaxhighlight>Wenn man versucht den Kubernetes Cluster zu initialisieren kommt eine Warnung, dass der Swap noch aktiv ist und dass das für eine Produktivumgebung nicht geeignet ist.
</syntaxhighlight>
Wenn man versucht den Kubernetes Cluster zu initialisieren kommt eine Warnung, dass der Swap noch aktiv ist und dass das für eine Produktivumgebung nicht geeignet ist.


Daher deaktivieren wir ihn kurzerhand in der /etc/fstab:<syntaxhighlight lang="bash">
Daher deaktivieren wir ihn kurzerhand in der /etc/fstab:
<syntaxhighlight lang="bash">
vi /etc/fstab
vi /etc/fstab
</syntaxhighlight>Den Eintrag mit 'swap' suchen und mit # auskommentieren:<syntaxhighlight lang="bash" line="1">
</syntaxhighlight>Den Eintrag mit 'swap' suchen und mit # auskommentieren:<syntaxhighlight lang="bash" line="1">
Zeile 92: Zeile 111:
reboot
reboot
</syntaxhighlight>
</syntaxhighlight>
=== Controller ===
=== Controller ===
'''Feste IP einrichten'''
'''Feste IP einrichten'''
Für erste geben wir nur dem Controller eine feste IP, damit aus der Worker-VM später ein Template erstellt werden kann.


Grafische Oberfläche:<syntaxhighlight lang="bash">
Grafische Oberfläche:<syntaxhighlight lang="bash">
Zeile 133: Zeile 155:
exclude=kubelet kubeadm kubectl
exclude=kubelet kubeadm kubectl
EOF
EOF
</syntaxhighlight>Da <code>kubelet</code> nicht für SELinux optimimert ist und sich eine individuelle Konfiguration sehr aufwändig gestalten kann sollte es am besten dauerhaft deaktiviert werden.
</syntaxhighlight>
Da <code>kubelet</code> nicht für SELinux optimimert ist und sich eine individuelle Konfiguration sehr aufwändig gestalten kann, sollte es am besten dauerhaft deaktiviert werden.


Nur so können die Container z.B. auf das Dateisystem des Hosts zugreifen.<syntaxhighlight lang="bash">
Nur so können die Container z.B. auf das Dateisystem des Hosts zugreifen.
<syntaxhighlight lang="bash">
setenforce 0
setenforce 0
sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
</syntaxhighlight>Jetzt können die Tool für den Cluster installiert werden:<syntaxhighlight lang="bash">
</syntaxhighlight>Jetzt können die Tools für den Cluster installiert werden:<syntaxhighlight lang="bash">
dnf update
dnf update
dnf install -y kubeadm kubectl kubelet nfs-utils --disableexcludes=kubernetes
dnf install -y kubeadm kubectl kubelet nfs-utils --disableexcludes=kubernetes
Zeile 147: Zeile 171:
- '''kubelet''' / Steuert die Kommunikation zwischen den Nodes und der API
- '''kubelet''' / Steuert die Kommunikation zwischen den Nodes und der API


- '''nfs-utils''' / Um NFS Exports in den Cluster einzubinden
- '''nfs-utils''' / Um NFS Exports als "Persistent Volume" in den Cluster einzubinden
 


Den kubelet beim Neustart automatisch starten:<syntaxhighlight lang="bash">
Kubelet beim Neustart automatisch starten:<syntaxhighlight lang="bash">
systemctl enable kubelet
systemctl enable kubelet
</syntaxhighlight>
</syntaxhighlight>
=== Firewall konfigurieren ===
=== Firewall konfigurieren ===


Zeile 211: Zeile 237:




Wenn alle VMs aus dem selben Template erstellt wurden, muss auf den Nodes die 'machine-id' neu generiert werden damit sie nicht identisch sind.<syntaxhighlight lang="bash">
Wenn alle VMs aus dem selben Template erstellt wurden, muss auf den Nodes die 'machine-id' neu generiert werden damit sie nicht identisch sind.[[Datei:Proxmox vm uuid.png|mini|VM UUID in Proxmox]]<syntaxhighlight lang="bash">
rm /etc/machine-id
rm /etc/machine-id
systemd-machine-id-setup
systemd-machine-id-setup
Zeile 219: Zeile 245:


Das bedeutet, dass die machine-id aus der UUID der Proxmox VM generiert wurde.
Das bedeutet, dass die machine-id aus der UUID der Proxmox VM generiert wurde.
[[Datei:Proxmox vm uuid.png|ohne|mini|VM UUID in Proxmox]]
=== Controller ===
=== Controller ===
Nun endlich kann der Cluster initialisiert werden:<syntaxhighlight lang="bash">
Nun endlich kann der Cluster initialisiert werden:<syntaxhighlight lang="bash">
Zeile 239: Zeile 263:
Wenn ihr als root angemeldet seid muss nur folgender Befehl ausgeführt werden:<syntaxhighlight lang="bash">
Wenn ihr als root angemeldet seid muss nur folgender Befehl ausgeführt werden:<syntaxhighlight lang="bash">
export KUBECONFIG=/etc/kubernetes/admin.conf
export KUBECONFIG=/etc/kubernetes/admin.conf
</syntaxhighlight>Damit das nicht bei jeder neuen Sitzung wiederholt werden muss, kann die Zeile am Ende von <code>.bash_profile</code> eingefügt werden:<syntaxhighlight lang="bash">
</syntaxhighlight>
Damit das nicht bei jeder neuen Sitzung wiederholt werden muss, kann die Zeile am Ende von <code>.bash_profile</code> eingefügt werden:
<syntaxhighlight lang="bash">
vi ~/.bash_profile
vi ~/.bash_profile
</syntaxhighlight>'''''Die Join Kommandos brauch man sich nicht zu speichern, da der Token jederzeit mit''''' <code>kubeadm token create --print-join-command</code> '''''neu generiert werden kann.'''''
</syntaxhighlight>'''''Die Join Kommandos braucht man sich nicht zu speichern, da der Token jederzeit mit''''' <code>kubeadm token create --print-join-command</code> '''''neu generiert werden kann.'''''




Mit <code>kubectl get nodes</code> kann überprüft werden ob der Controller läuft:<syntaxhighlight lang="bash">
NAME          STATUS  ROLES          AGE    VERSION
k8s-ctrlr-1  Ready    control-plane  8m7s  v1.26.0
</syntaxhighlight>
'''''Es kann ein, zwei Minuten dauern bis der Status READY ist.'''''


Wenn man jetzt mit <code>kubectl get nodes</code> den Status des einen Nodes abfragt wird man feststellen, dass dieser auf "Not Ready" bleibt...


Mit <code>kubectl get pods -n kube-system</code> sieht man, dass die Pods "coredns" im Status "Pending" sind.<syntaxhighlight lang="bash">
NAME                                  READY  STATUS    RESTARTS        AGE
coredns-787d4945fb-k4q67              1/1    Pending  0              5m16s
coredns-787d4945fb-klgw4              1/1    Pending  0              5m16s
etcd-k8s-ctrlr-1                      1/1    Running  0              6m31s
kube-apiserver-k8s-ctrlr-1            1/1    Running  0              6m30s
kube-controller-manager-k8s-ctrlr-1  1/1    Running  0              6m29s
kube-proxy-8gstv                      1/1    Running  0              5m13s
kube-scheduler-k8s-ctrlr-1            1/1    Running  0              6m31s
</syntaxhighlight>Das liegt daran, dass der "coredns" auf eine interne IP im Bereich 10.244.0.0/16 wartet.


Als erster müssen wir auf unserem neuem Cluster den [https://github.com/flannel-io/flannel flannel-Agent] installieren.
Damit der Node eine IP zugewiesen bekommt, müssen wir als erstes den [https://github.com/flannel-io/flannel flannel-Agent] installieren.


Dieser ist so eine Art interner Router der den Nodes eigene Subnetze zuweist, aus welchen sich die Pods dann ihre IP-Adressen beziehen.
Dieser ist so eine Art interner Router der den Nodes eigene Subnetze zuweist, aus welchen sich die Pods dann ihre IP-Adressen beziehen.
Zeile 264: Zeile 296:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
</syntaxhighlight>Jetzt können die Worker zu dem Cluster hinzugefügt werden.
</syntaxhighlight>
 
Anschließend kann mit <code>kubectl get nodes</code> überprüft werden, ob der Controller läuft:<syntaxhighlight lang="bash">
NAME          STATUS  ROLES          AGE    VERSION
k8s-ctrlr-1  Ready    control-plane  8m7s  v1.26.0
</syntaxhighlight>
'''''Es kann ein, zwei Minuten dauern bis der Status READY ist.'''''
 
 
[[File:Kubernetes.png|thumb|Kubernetes Schema]]
'''Jetzt können die Worker zu dem Cluster hinzugefügt werden.'''
 




Zeile 274: Zeile 317:
Den neu generierten Join-Befehl auf jedem Worker ausführen:<syntaxhighlight lang="bash">
Den neu generierten Join-Befehl auf jedem Worker ausführen:<syntaxhighlight lang="bash">
  kubeadm join 192.168.2.65:6443 --token b1j6iu.s91gq99vytd2x096 --discovery-token-ca-cert-hash sha256:244dcacceb61419bc00d6dff2bea8ec694732be1d03b289308a58436da5e17d0
  kubeadm join 192.168.2.65:6443 --token b1j6iu.s91gq99vytd2x096 --discovery-token-ca-cert-hash sha256:244dcacceb61419bc00d6dff2bea8ec694732be1d03b289308a58436da5e17d0
</syntaxhighlight>Auf dem Controller kann mit <code>kubectl get nodes</code> überprüft werden ob der Worker registriert wurde:<syntaxhighlight lang="bash">
</syntaxhighlight>
Auf dem Controller kann mit <code>kubectl get nodes</code> überprüft werden ob der Worker registriert wurde:
<syntaxhighlight lang="bash">
kubectl get nodes
kubectl get nodes
</syntaxhighlight>Ausgabe:<syntaxhighlight lang="bash">
</syntaxhighlight>Ausgabe:<syntaxhighlight lang="bash">
k8s-ctrlr  Ready  control-plane  19m    v1.26.0
k8s-ctrlr  Ready  control-plane  19m    v1.26.0
k8s-node-1  Ready  <none>          3m1s    v1.26.0
k8s-node-1  Ready  <none>          3m1s    v1.26.0
</syntaxhighlight>'''''Es kann ein, zwei Minuten dauern bis der Status READY ist.'''''
</syntaxhighlight>''Es kann ein, zwei Minuten dauern bis der Status READY ist.''
 
 
'''Glückwunsch zu eurem neuen Kubernetes Cluster!'''


== Dashboard ==
== Dashboard ==
Zeile 287: Zeile 335:
Das Kubernetes Dashboard ist standardmäßig nicht installiert.
Das Kubernetes Dashboard ist standardmäßig nicht installiert.


Zum Betrieb ist es nicht notwendig aber es eignet sich hervorragend zur Fehlersuche oder um YAML-Skripte auszuführen.
Zum Betrieb ist es nicht notwendig, aber es eignet sich hervorragend zur Fehlersuche oder um YAML-Skripte auszuführen bzw. zu bearbeiten.
 
 


Mit folgendem Befehl kann das Dashboard installiert werden.<syntaxhighlight lang="bash">
Mit folgendem Befehl kann das Dashboard installiert werden:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml
<syntaxhighlight lang="bash">
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml
</syntaxhighlight>
</syntaxhighlight>






Nach ein paar Minuten sollten die Pods laufen und das Dashboard ist über https://localhost:&#x3C;NodePort> erreichbar.
Nach ein paar Minuten sollten die Pods laufen und das Dashboard über https://localhost<nowiki/>:&#x3C;NodePort> erreichbar sein.


Damit man auch über das LAN Zugriff hat muss der Dashboard Service angepasst werden.
Damit man auch über das LAN Zugriff hat, muss der Dashboard Service angepasst werden.


Den Dashboard Service editieren:<syntaxhighlight lang="bash">
Den Dashboard Service editieren:<syntaxhighlight lang="bash">
kubectl -n kubernetes-dashboard edit service kubernetes-dashboard
kubectl edit service kubernetes-dashboard -n kubernetes-dashboard
</syntaxhighlight><code>-n kubernetes-dashboard</code> / Das Dashboard erzeugt standardmäßig einen neuen Namespace. Um auf den Service zugreifen zu können, muss dieser im Befehl mit angegeben werden.
</syntaxhighlight><code>-n kubernetes-dashboard</code> / Das Dashboard erzeugt standardmäßig einen neuen Namespace. Um auf den Service zugreifen zu können, muss dieser im Befehl mit angegeben werden.


Zeile 338: Zeile 389:
status:
status:
   loadBalancer: {}
   loadBalancer: {}
</syntaxhighlight>Mit folgendem Befehl kann überprüft werden auf welchem Port der Service läuft:<syntaxhighlight lang="bash">
</syntaxhighlight>Mit '''NodePort''' wird der Service auf einen Host-Port zwischen '''30000''' und '''32767''' weitergeleitet.
 
 
 
Mit folgendem Befehl kann überprüft werden auf welchem Port der Service läuft:<syntaxhighlight lang="bash">
kubectl get service -n kubernetes-dashboard
kubectl get service -n kubernetes-dashboard
</syntaxhighlight>In diesem Fall ist der Port 31447:<syntaxhighlight lang="bash">
</syntaxhighlight><syntaxhighlight lang="bash">
NAME                        TYPE        CLUSTER-IP      EXTERNAL-IP  PORT(S)        AGE
NAME                        TYPE        CLUSTER-IP      EXTERNAL-IP  PORT(S)        AGE
dashboard-metrics-scraper  ClusterIP  10.101.128.128  <none>        8000/TCP        10m
dashboard-metrics-scraper  ClusterIP  10.101.128.128  <none>        8000/TCP        10m
kubernetes-dashboard        NodePort    10.96.102.224    <none>        443:31447/TCP  10m
kubernetes-dashboard        NodePort    10.96.102.224    <none>        443:31447/TCP  10m


</syntaxhighlight>Das Dashboard sollte jetzt über https://<Node-IP>:31447 erreichbar sein.
</syntaxhighlight>In diesem Fall ist der Port '''31447'''...
 
Das Dashboard sollte jetzt über '''https://<Node-IP>:31447''' erreichbar sein.
 
Als Node-IP kann jede IP von einem der Hosts genommen werden.


Als Node-IP kann jede IP von einem der Hosts genommen werden.<nowiki>#</nowiki> Create admin-user


=== Benutzer Anmeldung ===
=== Benutzer Anmeldung ===
Zeile 356: Zeile 414:
Auf dem Controller in einem beliebigen Ordner folgende Dateien anlegen:
Auf dem Controller in einem beliebigen Ordner folgende Dateien anlegen:


admin-user.yaml<syntaxhighlight lang="bash" line="1">
admin-user.yaml / Manifest um einen Service Account anzulegen.<syntaxhighlight lang="bash" line="1">
apiVersion: v1
apiVersion: v1
kind: ServiceAccount
kind: ServiceAccount
Zeile 362: Zeile 420:
   name: admin-user
   name: admin-user
   namespace: kubernetes-dashboard
   namespace: kubernetes-dashboard
</syntaxhighlight>cluster-admin.yaml<syntaxhighlight lang="bash" line="1">
</syntaxhighlight>cluster-admin.yaml / Manifest um dem Service Account Adminrechte zuzuweisen.<syntaxhighlight lang="bash" line="1">
apiVersion: rbac.authorization.k8s.io/v1
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
kind: ClusterRoleBinding
Zeile 379: Zeile 437:
kubectl apply -f cluster-admin.yaml
kubectl apply -f cluster-admin.yaml
</syntaxhighlight>Jetzt haben wir einen Service Account mit dem Namen 'admin-user' und Administrator Berechtigung angelegt.
</syntaxhighlight>Jetzt haben wir einen Service Account mit dem Namen 'admin-user' und Administrator Berechtigung angelegt.


Um einen Token für die Anmeldung im Dashboard zu generieren reicht folgender Befehl:<syntaxhighlight lang="bash">
Um einen Token für die Anmeldung im Dashboard zu generieren reicht folgender Befehl:<syntaxhighlight lang="bash">
Zeile 385: Zeile 444:


==== Keycloak (OIDC) ====
==== Keycloak (OIDC) ====
Folgt...
Siehe [[Kubernetes Dashboard mit Keycloak OIDC]]
 




=== Metrics Server installieren ===
=== Metrics Server installieren ===
Das Installations Manifest für den Metrics-Server herunterladen:<syntaxhighlight lang="bash">
Um die Auslastung der einzelnen Pods, bzw der Nodes im Dashboard zu sehen, muss der Metrics-Server installiert werden.
 
Darüber hinaus kann der Metrics-Server verwendet werden um die Pods gleichmäßig auf die Nodes aufzuteilen ('''Horizontal Autoscaling''') oder
 
um die zugeteilten Ressourcen (CPU, RAM) automatisch an der Verbrauch anzupassen ('''Vertical Autoscaling''').
 
 
Zuerst das Installations Manifest für den Metrics-Server herunterladen:<syntaxhighlight lang="bash">
curl -LO https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
curl -LO https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
</syntaxhighlight><code>- --kubelet-insecure-tls</code> in deployment.spec.template.spec.containers.args<ref>https://www.scmgalaxy.com/tutorials/kubernetes-metrics-server-error-readiness-probe-failed-http-probe-failed-with-statuscode/</ref><syntaxhighlight lang="bash" line="1">
</syntaxhighlight><code>- --kubelet-insecure-tls</code> in deployment.spec.template.spec.containers.args<ref>https://www.scmgalaxy.com/tutorials/kubernetes-metrics-server-error-readiness-probe-failed-http-probe-failed-with-statuscode/</ref><syntaxhighlight lang="bash" line="1">
Zeile 429: Zeile 496:
k8s-worker-2  42m          2%    481Mi          13%
k8s-worker-2  42m          2%    481Mi          13%
</syntaxhighlight>
</syntaxhighlight>
<nowiki>###############################</nowiki>
<nowiki>###</nowiki>Speziell gitlab
<nowiki>###############################</nowiki>
<nowiki>#</nowiki> DNS zur gitlab-runner config
[runners.kubernetes.dns_config]
nameservers = [
  "10.16.0.3",
  "10.16.0.4"
]


== Weiterführende Links ==
== Weiterführende Links ==
*[https://krew.sigs.k8s.io/plugins/ Plugins für kubectl Kommando]
*[https://krew.sigs.k8s.io/plugins/ Plugins für kubectl Kommando]
*[https://github.com/collabnix/kubetools Liste mit Tools für Kubernetes]
*[https://github.com/collabnix/kubetools Liste mit Tools für Kubernetes]
*[https://artifacthub.io/ Sammlung von Kubernetes Packages (Helm)]
== Quellen ==
== Quellen ==
https://www.youtube.com/watch?v=U1VzcjCB_sY
https://docs.docker.com/engine/install/centos/
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/


https://www.thegeekdiary.com/how-to-access-kubernetes-dashboard-externally/
* https://www.youtube.com/watch?v=U1VzcjCB_sY
* https://docs.docker.com/engine/install/centos/
* https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
* https://www.thegeekdiary.com/how-to-access-kubernetes-dashboard-externally/


=== Einzelnachweise ===
=== Einzelnachweise ===
<references />
<references />
== Kommentare ==
<comments nocache=true />

Navigationsmenü