Kubernetes mehre fragen

[Milchbroetchen]

Ich würde wie bereits angesprochen wegen den ganzen Sicherheits-, Konfigurations- und Funktionsumfängen (welche ganze Verwaltungsteams bräuchte) gar nicht auf pures Kubernetes setzen sondern auf eine Distro. Bei Suse's Rancher ist der Support optional, bei Redhat Openshift heisst die freie Variante OKD statt Openshift.

Openshift btw. OKD ist doch im Prinzip das selbe wie Kubernetes? Dachte immer das Openshift so etwas ist wie z.B. Proxmox (grob gesagt) auf denen man ganze KVM VM's hosten kann.

Falls du Consulting anbieten willst oder den Werbesatz "zertifiziert" verwenden können willst ist es eine sehr gute Idee. Für den Arbeitsmarkt auch nicht unbedingt schlecht. Wie viele Zertifikate ist es aber im Allgemeinen aber nur das Geld was du durch die entsprechende Werbung/Stelle kriegen kannst wert. Will heissen; die Kurse bringen einem bereits eingestiegenen und interessierten Teilnehmer eigentlich keinen Mehrwert in der eigentlichen Arbeit, sie ermöglichen aber oft die Arbeit überhaupt zu haben.
Wenn es dir um den Lerninhalt gibt, so geben Udemy, Pluralsight, Coursera Leistung-für-Geld, .. von Dokumentation und Foren und Trial&Error ganz zu schweigen.

Consulting wird es definitiv nicht, hatte es einfach nur als "Lerneffekt" angemacht.

Du darfst nicht erwarten dass Kubernetes eine Linux-Anwendung ist wie eine andere auch welche binnen 2 Tagen läuft. Allein die Container-Methodik (Theorie und Praxis) ist bereits bei "simplen" Docker-Umgebungen überwältigend und komplex, Kubernetes ist nochmal ein Brockhaus voller Möglichkeiten, Einschränkungen und Probleme obendrauf.
Am besten lernt es sich -meines Erachtens- im Realbetrieb einer Testumgebung. Und dabei haben wir bislang kaum an der Thematik Sicherheit gekratzt, EgressIP, NetworkPolicies, Namespace-Separation, Robot- und User-Roles sind genau so spassig wie Container-Scanning (die Registry Harbor bringt zB Aqua's Trivy mit) und Ressourcen-Limits/-Reservations.

Das hab ich nie erwartet, dass dies ein ganz ganz weiter unterschied ist im Gegensatz zu einem"normalen" vServer, Webhosting etc. war mir bewusst. Das mit der Testumgebung stimmt wohl, deshalb betreibe ich zur Zeit auch nur reines testen, rumtüfteln etc.welches ich für mich auch sehr genau dokumentiere. (Dies klappt übrigens hervorragend mit Confluence). Aktuell läuft das Testcluster erstmal mit 3 Master plane Servern sowie 3 Worker Nodes, der nächste schritt ist halt der nächste Loadbalancer und Ingress um eine Anwendung (die ich zu Testzwecken erstellt habe mit php und SQL) öffentlich verfügbar zu machen. Dann kommt noch das Thema Namespaces etc. Habe jetzt gestern noch auf dem Master Server Flannel für die Netzwerk Geschichte installiert/angewendet mittels "kubectl -f URL-FLANNEL".

 

[d4f]

Openshift btw. OKD ist doch im Prinzip das selbe wie Kubernetes?

Jein - Openshift, Rancher und Co basieren auf Kubernetes, bringen aber eigene Features, Erweiterungen und Philosophien mit.
Die grundlegenden Befehle sind identisch aber es beispielweise das Operatoren-Konzept gibt es in Kubernetes nicht. Will heissen, ein Kubernetes-kompatibles Produkt läuft generell auch auf Openshift (teilweise erst nach Lockerung der standardmässigen Sicherheitskonfiguration für einen Namespace), aber nicht umgekehrt.

Dachte immer das Openshift so etwas ist wie z.B. Proxmox (grob gesagt) auf denen man ganze KVM VM's hosten kann.

Du meinst Redhat Openstack Ähnlicher Name, aber anderes Produkt.
Nachdem "Redhat Enterprise <langweiliger Produktname>" zu alt wurde, ist die neue Produktstruktur wohl "Open<generischer Marketingname>".
Genauer gesagt reden wir hier von OCP (Openshift Container Platform) wessen Federo-äquivalenter Upstream OKD ist. Openshift beinhaltet mehrere "cloud-native" Produkte welche aber im Kern immer auf der OCP und damit Kubernetes aufbauen.

Consulting wird es definitiv nicht, hatte es einfach nur als "Lerneffekt" angemacht.

Sag niemals nie Wie du selber festgestellt hast ist Kubernetes ein grosser Topf und ich denke dass viele Firmen ihre Container-Runtimes auf eigenen Server aber nicht unter eigener Verantwortung betreiben werden wollen. Also spätestens nachdem die erste Kreditkartenabrechnung der ach-so-billigen Cloudprovider wie Amazon oder Google reinkommt...

um eine Anwendung (die ich zu Testzwecken erstellt habe mit php und SQL)

Ohne die Details zu kennen wie du sie aufgebaut hast, so solltest du hier eigentlich mindestens 3 Container haben wenn du die Microservice-Ideologie der Container befolgt hast
- Ein Webserver-Container (bestenfalls 2+ Pods zur Redundanz) welcher statische Dateien ausliefert
- Ein PHP-Container (bestenfalls 2+ Pods zur Redundanz) welcher die PHP-Applikation als FCGI betreibt
- Ein Datenbank-Container oder über Helmchart ein Master-Slave/Master-Master Cluster
Natürlich ist es absolut nicht verboten nur 2 Container (Frontend + DB) zu verwenden, aber dann benutzt du komplexere Container als strikt notwendig und Webserver sowie Applikation werden ohne Zwang aneinander gebunden.

Dann kommt noch das Thema Namespaces etc.

Grundlegend ist das Thema sehr einfach. Jedes Produkt kriegt pro Lebenszyklus (Entwicklungsumgebung, Acceptance Test, Produktion) jeweils eigene Namespaces. Dann trennt man die Namespaces intern noch so wie man "instinktiv" die Linux-Machinen trennen würde (backend/frontend, ...) und das ist es dann. Absolutes No-GO ist natürlich *irgendwas* im default-Namespace zu betreiben oder in den system-eigenen Namespaces.

Habe jetzt gestern noch auf dem Master Server Flannel für die Netzwerk Geschichte installiert/angewendet mittels "kubectl -f URL-FLANNEL".

Das ist ein Thema das ist komplett in unserer Diskussion übersehen habe, mea culpa. Die meisten Distros (so auch OCP) richten es vollautomatisch ein und K3S bringt von Haus flannel mit. Die meiste Erfahrung habe ich persönlich mit kube-ovn

Das hab ich nie erwartet, dass dies ein ganz ganz weiter unterschied ist im Gegensatz zu einem"normalen" vServer, Webhosting etc. war mir bewusst.

Langsam aber sicher ist dein Cluster für den Erstflug bereit.

 

[Milchbroetchen]

Jein - Openshift, Rancher und Co basieren auf Kubernetes, bringen aber eigene Features, Erweiterungen und Philosophien mit.
Die grundlegenden Befehle sind identisch aber es beispielweise das Operatoren-Konzept gibt es in Kubernetes nicht. Will heissen, ein Kubernetes-kompatibles Produkt läuft generell auch auf Openshift (teilweise erst nach Lockerung der standardmässigen Sicherheitskonfiguration für einen Namespace), aber nicht umgekehrt.

Ahhh wieder etwas gelernt, danke dir! Sprich OpenStack = vServer Hosting und Openshift und/oder Rancher = Containerisierung? Grob gesagt?

Sag niemals nie Wie du selber festgestellt hast ist Kubernetes ein grosser Topf und ich denke dass viele Firmen ihre Container-Runtimes auf eigenen Server aber nicht unter eigener Verantwortung betreiben werden wollen. Also spätestens nachdem die erste Kreditkartenabrechnung der ach-so-billigen Cloudprovider wie Amazon oder Google reinkommt...

Stimmt, aber bis dahin (wenn überhaupt) wird noch viel Zeit verstreichen, bis ich halt auch mehr Ahnung habe. Ich muss zugeben AWS, Google, Azure und wie Sie alle heißen habe ich noch nie ausprobiert.

Ohne die Details zu kennen wie du sie aufgebaut hast, so solltest du hier eigentlich mindestens 3 Container haben wenn du die Microservice-Ideologie der Container befolgt hast
- Ein Webserver-Container (bestenfalls 2+ Pods zur Redundanz) welcher statische Dateien ausliefert
- Ein PHP-Container (bestenfalls 2+ Pods zur Redundanz) welcher die PHP-Applikation als FCGI betreibt
- Ein Datenbank-Container oder über Helmchart ein Master-Slave/Master-Master Cluster
Natürlich ist es absolut nicht verboten nur 2 Container (Frontend + DB) zu verwenden, aber dann benutzt du komplexere Container als strikt notwendig und Webserver sowie Applikation werden ohne Zwang aneinander gebunden.

Es ist tatsächlich einfach nur was ganz einfaches, quasi ein Login System mit "Gästebuch" Funktion, war halt "mal eben" was gesprintetes zum testen. Microservices ist definitiv eine verdammt interessante Sache und genau dieses Konzept möchte ich unbedingt anwenden, es bringt einfach meiner Meinung nach eine enorme Sicherheit sowie Flexibilität (Sowohl im Betrieb als auch Entwicklung und Updates) mit sich was ein enormer Vorteil ist. Vielen Dank nochmals für die Tipps mit den Pods, ich denke alles andere unter 2 Pods macht wohl auch keinen Sinn und man kann sich dies wohl dann auch schenken?

Grundlegend ist das Thema sehr einfach. Jedes Produkt kriegt pro Lebenszyklus (Entwicklungsumgebung, Acceptance Test, Produktion) jeweils eigene Namespaces. Dann trennt man die Namespaces intern noch so wie man "instinktiv" die Linux-Machinen trennen würde (backend/frontend, ...) und das ist es dann. Absolutes No-GO ist natürlich *irgendwas* im default-Namespace zu betreiben oder in den system-eigenen Namespaces.

Das dachte ich mir schon, im Prinzip eigentlich relativ simpel habe mal in der offiziellen Doku durchgescrollt und mal grob rüber geschaut. Das gleiche gilt dann auch für Kunden oder? Sprich, ich "Sperre" Sie in ein eigenen Namespace rein wo sie Deployen können ohne, dass Sie in andere Namespaces reinkommen oder?

Das ist ein Thema das ist komplett in unserer Diskussion übersehen habe, mea culpa. Die meisten Distros (so auch OCP) richten es vollautomatisch ein und K3S bringt von Haus flannel mit. Die meiste Erfahrung habe ich persönlich mit kube-ovn

Ach alles gut, du kannst auch nicht an alles denken bei den Tipps die du hier schon geleistet hast! Habe dies auch tatsächlich mehr durch Zufall gefunden/gelesen in der Doku. Bin da aber noch nicht weiter gekommen mit mangels Zeit heute. kube-ovn schaue ich mir direkt mal an.

Im Prinzip sind diese Netzwerk Configs/Controller doch eigentlich so etwas wie z.B. bei KVM die vmbr0 Bridge oder? Um die einzelnen Pods mit Netzwerk zu versorgen oder?

Langsam aber sicher ist dein Cluster für den Erstflug bereit.

Ich hoffe doch, ich muss sagen es macht auch echt Spaß sich damit zu beschäftigen auch wenn es wie jeder Anfang sehr schwer ist und man desöfteren auch mal von vorne anfängt, aber da wollte ich mir tatsächlich mal Ansible anschauen bzw. mal einen bekannten fragen der damit sehr viel arbeitet ob man sich nicht damit was bauen kann.

Mal ein kurzes offtopic:
@Thorsten kann man hier im SSF nicht mal eine eigene Forums Kategorie für Docker, Kubernetes und co einrichten? Ich hätte da auch schon einen sehr guten Mod @d4f

 

[d4f]

Sprich OpenStack = vServer Hosting und Openshift und/oder Rancher = Containerisierung? Grob gesagt?

Ja. Wobei Openshift auto-deployment auf Openstack machen kann um nach Bedarf die Worker-Zahl zu skalieren (so wie auf vielen Plattformen)
Es gibt auch noch andere Plattformen, Rancher und Openshift sind halt die populärsten Optionen. Vmware's Tanzu wird vermutlich auch eine hohe Adoptionsrate kriegen.

Ich muss zugeben AWS, Google, Azure und wie Sie alle heißen habe ich noch nie ausprobiert.

Genau wie Kubernetes "eigentlich" nur Docker-Container mit viel Automatisierung und Steuerung sind, so sind Cloud-Anbieter nur vServer mit viel Automatisierung, Flexibilität und Steuerung.

Dank nochmals für die Tipps mit den Pods, ich denke alles andere unter 2 Pods macht wohl auch keinen Sinn und man kann sich dies wohl dann auch schenken?

Wenn du flexible aber produktionsfähige Umgebungen haben willst, solltest du mind. 3 Container mit jeweils 2 Pods haben, also 6 Instanzen. Wenn es unbedingt sein muss, Webserver und PHP auf dem gleichen Container, aber dann kannst du keine Fertigcontainer der jeweiligen Anbieter nehmen und musst eigene Software installieren was nachteilig für Standardisierung und Upgradefähigkeit ist.

Sprich, ich "Sperre" Sie in ein eigenen Namespace rein wo sie Deployen können ohne, dass Sie in andere Namespaces reinkommen oder?

Genau, du kannst auf Namespace-Ebene auch Quotes definieren. Beachte aber dass alle Kubernetes-Limits nicht Real-Werte sondern Maximal-Werte sind. Sprich wenn das Namespace 1CPU und 1GB RAM Quota hat, so müssen alle Pods im Namespace entweder requests und/oder limits für sowohl CPU als RAM deklarieren, und diese werden dann appliziert. Bei 3 Container mit requests.cpu=500m wird der Dritte dadurch wegen ResourceConstraint-Fehler gar nicht erst scheduled da du über 1 CPU belegen könntest - auch wenn die Container jeweils nur 10mCPU real verwenden.
Beachte dass Multi-Tenant und die damit einhergehende Rechteverwaltung (RBAC) sehr unübersichtlich und skurrile Funktionsweisen hat.
So kann ein User im Namespace eine PVC-Ressource anlegen aber kein PV. Falls aber ein passendes PV existiert wird es ihm zugewiesen, egal was du eigentlich damit vorhattest. Man kann dies über dynamic Provisioner oder das Vorassignieren der PVC im PV teilweise umgehen, aber wirklich unabhängig sind deine Devops nicht. Gott sei Dank.......

Im Prinzip sind diese Netzwerk Configs/Controller doch eigentlich so etwas wie z.B. bei KVM die vmbr0 Bridge oder? Um die einzelnen Pods mit Netzwerk zu versorgen oder?

Nicht ganz, es ist eine "echte" software-defined Network (SDN) Lösung. Von IP-Assignation über Routing der internen Netzwerke zwischen den Hosts über Kontrolle von Ingress- und Egressverkehr bis hin zu Firewalllogik (NetworkPolicies) oder gar Transportverschlüsslung des Datenverkehrs steuert es schlicht alles was irgendwie Netzwerk ist. Die Host-Bridge ist eher ein gemeinsamer Knotenpunkt für Verkehr und damit Sub-Teil eines SDN.

aber da wollte ich mir tatsächlich mal Ansible anschauen bzw. mal einen bekannten fragen der damit sehr viel arbeitet ob man sich nicht damit was bauen kann

Da ist man bei OCP deutlich verwöhnt. Das Konzept eines MachineConfigOperator welcher Konfigurationsdateien/Skripte/... automatisch auf alle Hosts deployed und verwaltet ist sehr schön und spart das ganze manuelle Einrichten der Nodes. Passt gut zur Kubernetes-Logik dass alles eine YAML-Datei ist; man führt eigentlich nie einen Befehl direkt auf den Maschinen.

kann man hier im SSF nicht mal eine eigene Forums Kategorie für Docker, Kubernetes und co einrichten?

Ach internal/smalltalk passt doch gut. Alle Container sind nur cluster-intern erreichbar und sollten small sein
"+" aber für die Einführung eines Container-Subforums, es passt einfach nicht in die bestehenden Kategorien und ich hoffe dass es in den kommenden Jahren hier noch populärer wird.

 

[Milchbroetchen]

Ja. Wobei Openshift auto-deployment auf Openstack machen kann um nach Bedarf die Worker-Zahl zu skalieren (so wie auf vielen Plattformen)
Es gibt auch noch andere Plattformen, Rancher und Openshift sind halt die populärsten Optionen. Vmware's Tanzu wird vermutlich auch eine hohe Adoptionsrate kriegen.

Werde mir Openshift und Rancher definitiv mal ansehen, warum dass Rad "neuerfinden" wenn es gute Lösungen gibt. Nochmals danke für den Tipp!

Genau wie Kubernetes "eigentlich" nur Docker-Container mit viel Automatisierung und Steuerung sind, so sind Cloud-Anbieter nur vServer mit viel Automatisierung, Flexibilität und Steuerung.

Ahh ok

Wenn du flexible aber produktionsfähige Umgebungen haben willst, solltest du mind. 3 Container mit jeweils 2 Pods haben, also 6 Instanzen. Wenn es unbedingt sein muss, Webserver und PHP auf dem gleichen Container, aber dann kannst du keine Fertigcontainer der jeweiligen Anbieter nehmen und musst eigene Software installieren was nachteilig für Standardisierung und Upgradefähigkeit ist.

Genau so hatte ich es mir gedacht und das die Anwendung zusammen auf dem Webserver laufen muss ist tatsächlich nur die Testanwendung jetzt, in Zukunft soll dies strikt getrennt werden und halt auch die Microarchitektur zum Vorbild werden.

Genau, du kannst auf Namespace-Ebene auch Quotes definieren. Beachte aber dass alle Kubernetes-Limits nicht Real-Werte sondern Maximal-Werte sind. Sprich wenn das Namespace 1CPU und 1GB RAM Quota hat, so müssen alle Pods im Namespace entweder requests und/oder limits für sowohl CPU als RAM deklarieren, und diese werden dann appliziert. Bei 3 Container mit requests.cpu=500m wird der Dritte dadurch wegen ResourceConstraint-Fehler gar nicht erst scheduled da du über 1 CPU belegen könntest - auch wenn die Container jeweils nur 10mCPU real verwenden.
Beachte dass Multi-Tenant und die damit einhergehende Rechteverwaltung (RBAC) sehr unübersichtlich und skurrile Funktionsweisen hat.
So kann ein User im Namespace eine PVC-Ressource anlegen aber kein PV. Falls aber ein passendes PV existiert wird es ihm zugewiesen, egal was du eigentlich damit vorhattest. Man kann dies über dynamic Provisioner oder das Vorassignieren der PVC im PV teilweise umgehen, aber wirklich unabhängig sind deine Devops nicht. Gott sei Dank.......

Dann lag ich da ja schon einmal nicht ganz so falsch, ich denke dass Thema wird noch viele viele Stunden verschlingen aber die SIchehriet ist mir definitiv wichtig, weswegen ich auch viel versuche Private und Public netze zu trennen.

Nicht ganz, es ist eine "echte" software-defined Network (SDN) Lösung. Von IP-Assignation über Routing der internen Netzwerke zwischen den Hosts über Kontrolle von Ingress- und Egressverkehr bis hin zu Firewalllogik (NetworkPolicies) oder gar Transportverschlüsslung des Datenverkehrs steuert es schlicht alles was irgendwie Netzwerk ist. Die Host-Bridge ist eher ein gemeinsamer Knotenpunkt für Verkehr und damit Sub-Teil eines SDN.

Ahh ok, hab es mir jetzt tatsächlich als virtuelle Lösung vorgestellt, aber wieder etwas gelernt.

Ach internal/smalltalk passt doch gut. Alle Container sind nur cluster-intern erreichbar und sollten small sein
"+" aber für die Einführung eines Container-Subforums, es passt einfach nicht in die bestehenden Kategorien und ich hoffe dass es in den kommenden Jahren hier noch populärer wird.

Haha stimmt Ich denke es wird nicht mehr lange dauern bis das wirklich noch populärer wird, btw. mir fällt grad ein das es glaube ich keinen wirklichen Anbieter für Containerlösungen Made in Germany gibt oder?

 

[d4f]

weswegen ich auch viel versuche Private und Public netze zu trennen.

In einem klassischen Kubernetes-Setup ist die Netzwerke systematisch getrennt; (etwas unterschiedlich je nach gewählter NetzwerkFabric)
- Pods sind nur im gleichen Namespace ansprechbar
- Service-Definitionen bilden die Zugriffsmöglichkeit um aus dem Cluster raus - aus dem gleichen Namespace oder -übergreifend - auf ein Pod zu zu greifen (oder über mehrere Pods zu loadbalancen)
- Routen/Ingress bilden die Möglichkeit um von extern oder im Cluster auf HTTP(s)-Ressourcen zuzugreifen und binden im Hintergrund auf ein Service
- Port-Exports (NodePort, ClusterPort, ...) sind Service-Definitionen welche einen Dienst öffentlich erreichbar machen

Um die Empfehlungen von OCD/OKD zu nehmen, dein Kubernetes hat folgende Netzwerke:
- Machine: Das Netzwerk wo die Hosts laufen, mindestens /24
- POD: Das "fiktive" Netzwerk für die Container, mindestens /14
- Service: Das "fiktive" Netzwerk für die Service-Definitionen, mindestens /16
*: Mit "fiktiv" meine ich Netzwerke die es nur auf den internen SDN-Router der Plattform gibt und nicht in deinem Hostnetz. Dieses Netz sollte zwischen deinen Cluster identisch sein

 

[Milchbroetchen]

In einem klassischen Kubernetes-Setup ist die Netzwerke systematisch getrennt; (etwas unterschiedlich je nach gewählter NetzwerkFabric)
- Pods sind nur im gleichen Namespace ansprechbar
- Service-Definitionen bilden die Zugriffsmöglichkeit um aus dem Cluster raus - aus dem gleichen Namespace oder -übergreifend - auf ein Pod zu zu greifen (oder über mehrere Pods zu loadbalancen)
- Routen/Ingress bilden die Möglichkeit um von extern oder im Cluster auf HTTP(s)-Ressourcen zuzugreifen und binden im Hintergrund auf ein Service
- Port-Exports (NodePort, ClusterPort, ...) sind Service-Definitionen welche einen Dienst öffentlich erreichbar machen

Vielen Dank, dass werde ich mir nochmal genauer ansehen. Für mich klingt dies gerade so, dass jeder Namespace ein eigenes Netzwerksegment zugewiesen bekommt auf denen dann Routing, Loadbalanceing etc. stattfindet?

- Machine: Das Netzwerk wo die Hosts laufen, mindestens /24

Wie genau meinst du dies? Das ich jedem einzelnem Worker Node ein /24 LAN Netz anhänge? oder das alle Worker Nodes in dem selben /24 LAN sind?

- POD: Das "fiktive" Netzwerk für die Container, mindestens /14
- Service: Das "fiktive" Netzwerk für die Service-Definitionen, mindestens /16
*: Mit "fiktiv" meine ich Netzwerke die es nur auf den internen SDN-Router der Plattform gibt und nicht in deinem Hostnetz. Dieses Netz sollte zwischen deinen Cluster identisch sein

SDN ist dann dies was ich bereits angesprochen hatte mit Flannel und co oder? Das heißt jeder POD bekommt ein /16 LAN zugewiesen? innerhalb dieses POD's bekommen dann die einzelnen Container jeweils eine IP aus diesem /16? und dies wird dann intern auf die IP's des /24 Netzes des Hosts geroutet und von da aus nach "außerhalb" verteilt? Ich werde mich da heute mal mit beschäftigen und mir mal Dokus dazu durchlesen und ggf. auch mal bildlich darstellen um dies besser zu verstehen.

 

[Milchbroetchen]

Kleines Update, gerade gemerkt, dass mein HA Setup leider nicht so funktioniert wie es soll. Aufbau ist zur Zeit folgender:

Hetzner Cloud
- LAN Netz (192.168.178.0/24) in diesem befinden sich ein LoadBalancer und die beiden MasterPlane Server
- LB und Master1, 2 haben beide auch eine öffentliche Adresse
- Alle Server sind im internen Netz singbar und der Loadbalancer auch
- Auf dem Loadbalancer habe ich einen TCP Service eingerichtet für den Port 6443->6443

Master Plane Server wurde mittels:

kubeadm init --apiserver-advertise-address=192.168.178.2 --apiserver-cert-extra-sans=K8S-MCP01-DE-NBG1-DC3,k8s-mcp01-de-nbg1-dc3,lb01-de-nbg1,116.203.144.192,142.132.181.0,K8S-MCP02-DE-FSN1-DC14,k8s-mcp02-de-fsn1-dc14,api.k8s.DOMAIN.net,K8S-MCP01-DE-NBG1-DC3.DOMAIN.net,k8s-mcp01-de-nbg1-dc3.DOMAIN.net,lb01-de-nbg1.DOMAIN.net,K8S-MCP02-DE-FSN1-DC14.DOMAIN.net,k8s-mcp02-de-fsn1-dc14.DOMAIN.net,162.55.153.44,192.168.178.3,192.168.178.2,192.168.178.4 --pod-network-cidr=10.98.0.0/16 --control-plane-endpoint=162.55.153.44 --upload-certs --ignore-preflight-errors=NumCPU

Soweit so gut, der zweite Masterplane Server wurde mittels:

kubeadm join 162.55.153.44:6443 --token vyxi8e.q62q0xkhmqgl5dpj --discovery-token-ca-cert-hash sha256:c0716d1b84860dda094b4dcd215fabdb1aa6d9c5afcfa15ed6f8b4850876826d --control-plane --apiserver-advertise-address=192.168.178.4 --ignore-preflight-errors=NumCPU --certificate-key 5bc8fc22e62549677665ad7e6f1e2144c0383721069c29df11eddb8ea5ed05af

gejoint. Wobei die IP 162.55.153.44:6443 diese vom Loadbalancer ist. Ansicht funktioniert alles auf beiden Seiten funktioniert kubectl und ich kann diese darüber administrieren. Nehme ich aber nun testweise den ersten Masterplane server vom Netz tut sich garnichts mehr

[root::K8S-MCP02-DE-FSN1-DC14]
~: kubectl get nodes
Unable to connect to the server: EOF

Das selbe ebenfalls wenn ich von meiner Mac Workstation von zuhause aus zugreife. Normalerweise sollte dies durch den Loadbalcer und das ControlPlane Master Setup ja nicht passieren oder?

Edit:

192.168.178.3 = LB
192.168.178.2 = Master Plane
192.168.178.4 = MasterPlane 2

 

[d4f]

Für mich klingt dies gerade so, dass jeder Namespace ein eigenes Netzwerksegment zugewiesen bekommt auf denen dann Routing, Loadbalanceing etc. stattfindet?

Das heißt jeder POD bekommt ein /16 LAN zugewiesen? innerhalb dieses POD's bekommen dann die einzelnen Container jeweils eine IP aus diesem /16?

Nein, die Trennung wird firewall-ähnlich durchgeführt. Du hast 2 virtuelle Töpfe und einen realen Topf an IP-Adressen:

- das Hostnet. Meistens schlicht die Gesamtheit aller IPs welche deinen VM's zugewiesen wurden aber du könntest für Ingress/Egress/Node-Assignation auch dem Cluster ein Netzwerksegment dedizieren

- das Service-Netz: Hier werden *clusterintern* IP-Adressen einem Service (zB: Namespace 'meinblog' , Service 'https' , ClusterPort 443) assigniert. Dieser Service wird dann in Echtzeit von Kubernetes mittels Selektoren auf tatsächlich laufende Pods zugewiesen. Im Beispiel sagen wir dass alle Container mit dem Tag "webserver" auf Port 8443 erreichbar sind.
Wenn mindestens 1 Pod mit Tag "webserver" alle Checks( startup + readiness + liveness) besteht und "ready" ist, dann ist er über die IP des Service erreichbar. Wenn mehrere Pods es sind, so wird zwischen den Pods loadbalanced. Falls kein POD es ist, so hängt die TCP-Verbindung einfach.
Dies ermöglicht es dass du zB eine neue Apache-Version ausspielen kannst. Der neue Server startet, wird "ready", der alte Pod wird non-ready und wird terminiert.

- das Pod-Netzwerk: Hier laufen die eigentlichen Container. (Mehrere Container eines Pods teilen sich eine IP)
Die IPs werden im Normalfall automatisch assigniert und ändern zwischen 2 Starts. Man kann es als grosses DHCP-Netz für die einzelnen Applikationen ansehen. Die Verkehrsssteuerung erfolgt auf SDN-Ebene und nicht auf CIDR-Ebene so dass Pods aus 2 Namespaces nebeneinanderliegende IPs haben können.

Wie genau meinst du dies? Das ich jedem einzelnem Worker Node ein /24 LAN Netz anhänge? oder das alle Worker Nodes in dem selben /24 LAN sind?

Nein Kubernetes will wissen wie das Hotnetzwerk aufgebaut ist. Bei einer manuellen Konfiguration vermutlich weniger relevant, OCD/OKD will aber zumindest dass alle Maschinen im gleichen Netzwerk sind. So kannst du nicht ein 192.168.1.x/24 haben und dann einen Worker mit 172.0.0.2 beisetzen.

SDN ist dann dies was ich bereits angesprochen hatte mit Flannel und co oder?

Genau, "software-defined networking". Also quasi Router, Switch, Firewall, Loadbalancer, ... nur halt in Software definiert statt fester Netzwerkkonfiguration.

Sehr interessant wird das Konzept wenn man Hardware- oder Cloudunterstützung hat, also dein Kubernetes dem Anbieter sagen kann was es braucht. Du willst einen Loadbalancer? Kein Problem, das System gibt den Router oder Loadbalancer bescheid dass TCP auf IP X Service Y nun round-robin auf 2 IP's verteilt werden soll. Diesen "network-Support" gibt es sowohl für enterprise on-premise (Vmware NSX, Juniper Contrail, Cisco ACI, ...) als auch für die grossen Cloud-Anbieter (Azure, AWS, ...)

und dies wird dann intern auf die IP's des /24 Netzes des Hosts geroutet und von da aus nach "außerhalb" verteilt?

Ich bin mir nicht sicher was du mit "nach ausserhalb" meinst. Du musst aber ein Kubernetes Cluster ansehen als ob es hinter einem NAT hängt; von aussen siehst du nur die Router (Hostmachinen), von innen musst du ausgehend über die Router fahren und reinkommen kann Verkehr nur über Portforwarding (hier NodePort)

Nehme ich aber nun testweise den ersten Masterplane server vom Netz tut sich garnichts mehr

Ins Blaue rein geraten; du hast eine Controlplane mit 2 Master was nicht unterstützt ist. Falls ein Master ausfällt ist der andere non-quorate und weigert zu arbeiten. Das sollte normalerweise in den Logs und in der Statusabfrage von ETCD bemängelt werden falls das so ist.
Erklärung: Nur beide Master zusammen sind quorate. Du brauchst entweder einen dritten Master (dann bleibt das Cluster quorate solange du 2 hast) oder einen Single-Node Master. Der Fall eines Two-Node Clusters mit externem Quorum (bspw corosync-qdevice) ist afaik nicht möglich für ETCD.

 

[Milchbroetchen]

Nein, die Trennung wird firewall-ähnlich durchgeführt. Du hast 2 virtuelle Töpfe und einen realen Topf an IP-Adressen:

- das Hostnet. Meistens schlicht die Gesamtheit aller IPs welche deinen VM's zugewiesen wurden aber du könntest für Ingress/Egress/Node-Assignation auch dem Cluster ein Netzwerksegment dedizieren

- das Service-Netz: Hier werden *clusterintern* IP-Adressen einem Service (zB: Namespace 'meinblog' , Service 'https' , ClusterPort 443) assigniert. Dieser Service wird dann in Echtzeit von Kubernetes mittels Selektoren auf tatsächlich laufende Pods zugewiesen. Im Beispiel sagen wir dass alle Container mit dem Tag "webserver" auf Port 8443 erreichbar sind.
Wenn mindestens 1 Pod mit Tag "webserver" alle Checks( startup + readiness + liveness) besteht und "ready" ist, dann ist er über die IP des Service erreichbar. Wenn mehrere Pods es sind, so wird zwischen den Pods loadbalanced. Falls kein POD es ist, so hängt die TCP-Verbindung einfach.
Dies ermöglicht es dass du zB eine neue Apache-Version ausspielen kannst. Der neue Server startet, wird "ready", der alte Pod wird non-ready und wird terminiert.

- das Pod-Netzwerk: Hier laufen die eigentlichen Container. (Mehrere Container eines Pods teilen sich eine IP)
Die IPs werden im Normalfall automatisch assigniert und ändern zwischen 2 Starts. Man kann es als grosses DHCP-Netz für die einzelnen Applikationen ansehen. Die Verkehrsssteuerung erfolgt auf SDN-Ebene und nicht auf CIDR-Ebene so dass Pods aus 2 Namespaces nebeneinanderliegende IPs haben können.

Vielen Dank für das Beispiel, denke nun verstehe ich ein wenig die Arbeitsweise.

Sehr interessant wird das Konzept wenn man Hardware- oder Cloudunterstützung hat, also dein Kubernetes dem Anbieter sagen kann was es braucht. Du willst einen Loadbalancer? Kein Problem, das System gibt den Router oder Loadbalancer bescheid dass TCP auf IP X Service Y nun round-robin auf 2 IP's verteilt werden soll. Diesen "network-Support" gibt es sowohl für enterprise on-premise (Vmware NSX, Juniper Contrail, Cisco ACI, ...) als auch für die grossen Cloud-Anbieter (Azure, AWS, ...)

Das kling Interessant, soweit ich weiß gibt es da auch etwas für die Hetzner Cloud das wäre zum testen natürlich optimal.
Angenommen, ich packe demnächst eigene Hardware in eine Colo, dann müsste ich quasi für mich ein eigenes Plugin schreiben welches ggf. mit meinem Backend kommuniziert welches dazu da ist Ressourcen bereitzustellen oder?

Ich bin mir nicht sicher was du mit "nach ausserhalb" meinst. Du musst aber ein Kubernetes Cluster ansehen als ob es hinter einem NAT hängt; von aussen siehst du nur die Router (Hostmachinen), von innen musst du ausgehend über die Router fahren und reinkommen kann Verkehr nur über Portforwarding (hier NodePort)

Mit außerhalb meine ich das WWW, d.h. die Router (Hostmaschinen) sind quasi die Worker Nodes auf denen die einzelnen Pods laufen? Die Router, NAT, Port Forwarding Funktion wird dann durch dieses SDN verwaltet z.B. Flannel oder?

ns Blaue rein geraten; du hast eine Controlplane mit 2 Master was nicht unterstützt ist. Falls ein Master ausfällt ist der andere non-quorate und weigert zu arbeiten. Das sollte normalerweise in den Logs und in der Statusabfrage von ETCD bemängelt werden falls das so ist.
Erklärung: Nur beide Master zusammen sind quorate. Du brauchst entweder einen dritten Master (dann bleibt das Cluster quorate solange du 2 hast) oder einen Single-Node Master. Der Fall eines Two-Node Clusters mit externem Quorum (bspw corosync-qdevice) ist afaik nicht möglich für ETCD.

Das könnte es tatsächlich sein, hatte nur zwei Control Planes im Einsatz, werde heute Abend den 3 mal mit hinzufügen und dies nochmals testen.

Btw: Habe mir jetzt ein sehr interessantes Buch bestellt, welches bei Amazon auch gute Bewertungen hatte.
Skalierbare Container-Infrastrukturen: Das Handbuch für Admins & DevOps-Teams, inkl. Docker und Container-Orchestrierung mit Kubernetes und OpenShif

 

[d4f]

Angenommen, ich packe demnächst eigene Hardware in eine Colo, dann müsste ich quasi für mich ein eigenes Plugin schreiben welches ggf. mit meinem Backend kommuniziert welches dazu da ist Ressourcen bereitzustellen oder?

Nein, aber *irgendwas* muss provisionen, im Zweifelsfall deine Tippfinger
Bei sogenannten baremetal-Installationen (egal ob echtes Metall oder eine VM) musst du entweder eine Storage-Interfaces (CSI), VM-Provisioner, .... bauen oder es schlicht händisch machen.
Ich führe ausnahmslos bei allen meinen Cluster diese Aktionen manuell aus, das beschränkt sich in der Regel auf
- gelegentliches Hinzufügen oder Neuinstallieren eines Workers
- Erstellen von NFS-Shares und den zugehörigen PV (Über ein Bash-Skript semi-automatisiert) **

**: NFS ist auf Seiten des NFS-Server aufwendiger als auf Cluster-Seite. Du willst generell zumindest getrennte Mountpoints pro Namespace wenn nicht sogar pro PV. Da crossmounts absolut nicht funktioniert ist das nicht unerheblich falls du viele NFS-Exports hast. ISCSI, Cluster-interner Speicher oder CSI-Provider vereinfachen das Leben bei vielen Änderungen etwas.

h. die Router (Hostmaschinen) sind quasi die Worker Nodes auf denen die einzelnen Pods laufen?

Genau, in einem klassischen Kubernetes-System ist der Host für das Egress-Routing über seine eigene IP zuständig.
Ich bevorzuge (zumal bei kube-ovn) über EgressIP jedem Namespace seine eigenen IPs zu geben so dass man die Datenflüsse viel besser applikativ als auch benutzermässig trennen kann. In dem Fall hat dann ein Node des Clusters die Alias-IP und alle anderen Worker leiten ihren Egress-Traffic an ihn weiter. Stirbt der Node, übernimmt ein anderer die IP. Du kannst bei kube-ovn zumindest angeben welche Nodes EgressIP-fähig sind, so dass du Worker-Nodes an einem reinen internen Netzwerk und Worker- oder Infrastruktur/Verbindungs-Nodes ohne Kundenapplikationen als Gateway haben kannst.

Btw: Habe mir jetzt ein sehr interessantes Buch bestellt, welches bei Amazon auch gute Bewertungen hatte.

Bei Bücher kann ich leider keinerlei Empfehlung abgeben, ich bin seit jeher "learning by doing" und mag Lernstoff gar nicht. Zum Leid meiner Lehrer, Dozenten und Formationen

 

[Milchbroetchen]

Nein, aber *irgendwas* muss provisionen, im Zweifelsfall deine Tippfinger
Bei sogenannten baremetal-Installationen (egal ob echtes Metall oder eine VM) musst du entweder eine Storage-Interfaces (CSI), VM-Provisioner, .... bauen oder es schlicht händisch machen.
Ich führe ausnahmslos bei allen meinen Cluster diese Aktionen manuell aus, das beschränkt sich in der Regel auf
- gelegentliches Hinzufügen oder Neuinstallieren eines Workers
- Erstellen von NFS-Shares und den zugehörigen PV (Über ein Bash-Skript semi-automatisiert) **

**: NFS ist auf Seiten des NFS-Server aufwendiger als auf Cluster-Seite. Du willst generell zumindest getrennte Mountpoints pro Namespace wenn nicht sogar pro PV. Da crossmounts absolut nicht funktioniert ist das nicht unerheblich falls du viele NFS-Exports hast. ISCSI, Cluster-interner Speicher oder CSI-Provider vereinfachen das Leben bei vielen Änderungen etwas.

Ahhh ok, vielen Dank das bringt mich deutlich weiter. Zum installieren bzw. für die Basiskonfiguration könnte man ja Theoretisch auf Ansible setzen oder sehe ich dies verkehrt? Ich mache auch vieles lieber händisch von Hand einfach aus dem Grund, ich weiß dann was dort passiert oder auf den Systemen läuft. Aber gegen eine einfache Basisinstallation und Konfiguration mit Ansible spricht ja nix gegen.

Genau, in einem klassischen Kubernetes-System ist der Host für das Egress-Routing über seine eigene IP zuständig.
Ich bevorzuge (zumal bei kube-ovn) über EgressIP jedem Namespace seine eigenen IPs zu geben so dass man die Datenflüsse viel besser applikativ als auch benutzermässig trennen kann. In dem Fall hat dann ein Node des Clusters die Alias-IP und alle anderen Worker leiten ihren Egress-Traffic an ihn weiter. Stirbt der Node, übernimmt ein anderer die IP. Du kannst bei kube-ovn zumindest angeben welche Nodes EgressIP-fähig sind, so dass du Worker-Nodes an einem reinen internen Netzwerk und Worker- oder Infrastruktur/Verbindungs-Nodes ohne Kundenapplikationen als Gateway haben kannst.

Super, ich glaube soglangsam bekomme ich einen groben überblick was Netzwerk, Ingress, Egress etc. angeht bei Kubernetes. Es wird aber noch einiges an Zeit und Errors dauern bis ich mich da wirklich mal zurecht finde, würde mich aber freuen wenn ich dich bei Bedarf nochmals Löschern darf.

Bei Bücher kann ich leider keinerlei Empfehlung abgeben, ich bin seit jeher "learning by doing" und mag Lernstoff gar nicht. Zum Leid meiner Lehrer, Dozenten und Formationen

Haha ok, ich bin meistens auch mehr der Learning by Doing Typ, dass Buch jedoch fand ich sehr ansprechend und die Rezensionen. Nichts desto trotz ist die offizielle Doku von K8S definitiv unschlagbar.

 

[Milchbroetchen]

Mal eine blöde andere Frage, gibt es eigentlich spezielle Distributions Empfehlungen für Kubernetes Cluster? Ich nutze Debian, aber habe jetzt schon desöfteren gelesen das CentOS bzw. RHEL besser geeignet sind? RHEL wahrscheinlich aus dem Grund, da es dort einen Enterprise Support gibt oder?

 

[Thunderbyte]

Kurzes Offtopic: https://dagger.io/ (vom Docker Gründer) ist heute gelauncht.

 

[Milchbroetchen]

Das sieht definitiv mal interessant aus, zur Zeit nutze ich Gitlab (selbst gehostet) für CI/CD

 

[d4f]

Zum installieren bzw. für die Basiskonfiguration könnte man ja Theoretisch auf Ansible setzen oder sehe ich dies verkehrt?

Natürlich, bei einem "on-top" Deployment auf einem normalen Linux und keinem vorgefertigten OS ist Ansible eine perfekt adequate Lösung.
Ich würde sogar empfehlen ein automatisiertes Skript für Worker-Installationen zu haben, im Fall eines Problems ist es schlicht einfacher die Worker neu zu installieren als zu debuggen. Wegwerfgesellschaft mal anders

Aber gegen eine einfache Basisinstallation und Konfiguration mit Ansible spricht ja nix gegen.

Du kannst auch weitergehen und deine Projekt-Deployments, egal ob Helm oder andere Steuerungsplattformen dahinter liegen, über Ansible automatisieren. Hier ist die zugehörige Collection: https://github.com/ansible-collections/kubernetes.core
Darüber kannst du dann bspw auch Systemwartungen natürlich automatisieren (wenn wir schon dabei sind, wie wäre es mit AWX aka AnsibleTower? ) inklusive der "lästigen" Cordoning/Drain Geschichte.

Mal eine blöde andere Frage, gibt es eigentlich spezielle Distributions Empfehlungen für Kubernetes Cluster? Ich nutze Debian, aber habe jetzt schon desöfteren gelesen das CentOS bzw. RHEL besser geeignet sind?

Er hat Jehova gesagt!!!
Meines Erachtens bringen Distributionen mit modernen Kernel potentiell signifikante Performance-Vorteile aber ansonsten... wähl was dir am angenehmsten bist. Zumindest kenne ich keine grossen Unterschiede. RHEL hat natürlich einen guten Support sofern du nicht im Free-Tier bist, aber der gleiche Anbieter verkauft auch Openshift so dass ich von einem recht reduzierten Support für DIY-Cluster ausgehe
Natürlich gibt es noch Container-optimisierte Distros wie CoreOS (die Basis für OKD/OCD), K3OS (gedacht als Basis für K3S) oder Amazon's Bottlerocket. Eigentlich sollten Kubernetes-Host keine Drittpakete enthalten so dass diese Distros teilweise viel Arbeitsaufwand abnehmen können.

 

[Milchbroetchen]

Natürlich, bei einem "on-top" Deployment auf einem normalen Linux und keinem vorgefertigten OS ist Ansible eine perfekt adequate Lösung.
Ich würde sogar empfehlen ein automatisiertes Skript für Worker-Installationen zu haben, im Fall eines Problems ist es schlicht einfacher die Worker neu zu installieren als zu debuggen. Wegwerfgesellschaft mal anders

Super danke, dass mit den Workern ist ne mega gute Idee. Der cli command für den Join in das Cluster bleibt ja gleich.

Du kannst auch weitergehen und deine Projekt-Deployments, egal ob Helm oder andere Steuerungsplattformen dahinter liegen, über Ansible automatisieren. Hier ist die zugehörige Collection: https://github.com/ansible-collections/kubernetes.core
Darüber kannst du dann bspw auch Systemwartungen natürlich automatisieren (wenn wir schon dabei sind, wie wäre es mit AWX aka AnsibleTower? ) inklusive der "lästigen" Cordoning/Drain Geschichte.

Danke dir, glaube das wird eine Laaaaange Nacht heute

Er hat Jehova gesagt!!!
Meines Erachtens bringen Distributionen mit modernen Kernel potentiell signifikante Performance-Vorteile aber ansonsten... wähl was dir am angenehmsten bist. Zumindest kenne ich keine grossen Unterschiede. RHEL hat natürlich einen guten Support sofern du nicht im Free-Tier bist, aber der gleiche Anbieter verkauft auch Openshift so dass ich von einem recht reduzierten Support für DIY-Cluster ausgehe
Natürlich gibt es noch Container-optimisierte Distros wie CoreOS (die Basis für OKD/OCD), K3OS (gedacht als Basis für K3S) oder Amazon's Bottlerocket. Eigentlich sollten Kubernetes-Host keine Drittpakete enthalten so dass diese Distros teilweise viel Arbeitsaufwand abnehmen können.

Danke für die Erläuterung, ich denke ich fahre wohl doch ganz gut mit Debian.

 

[Milchbroetchen]

Ich bin auf meinem Weg mit Kubernetes nun auf eine interessante Sache gestoßen und zwar das z.B. redHat mit Openshift und andere Anbieter von Docker als Container Runtime Abschied genommen haben und auf andere Runtimes setzen. RedHat z.B. ist wohl maßgeblich an der Entwicklung von Cri-O beteiligt, welches Sie auch auf der Openshift Platform einsetzen. Da stellt sich mir die Frage als leihe ob Docker wirklich so viel schlechter ist? Bei meinen Rechenen bin ich drauf gestoßen, dass Docker z.B. diesen Ooen Container Runtime nicht direkt unterstützt? @d4f wie ist deine persönliche Meinung dazu und auf welchen Unterbau setzt du?

 

[d4f]

Da stellt sich mir die Frage als leihe ob Docker wirklich so viel schlechter ist?

Rein korrekt gesehen ist "docker" hier der falsche Begriff.
Die Docker-Umgebung (Tools, Daemon, ...) setzt auf der Containerd Laufzeitumgebung auf welche auf der Universallaufzeitumgebung runc aufsetzt. Openshift setzt auf die Crio Laufzeitumgebung welche auf der runc Universallaufzeitumgebung aufsetzt.

Das was man als "Docker-Container" bezeichnet ist eigentlich ein OCI-compliant Container (Open Container Initiative ) welche von sowohl Docker als Containerd unterstützt wird. Technisch sind beide also kompatibel , haben aber einen Fokus auf andere Besonderheiten. CRI-O ist hauptsächlich auf Sicherheit/Schlanksein ausgelegt und braucht externe Hilfsprogramme zur vollen Funktionsentfaltung während der Docker Softwarestack eher auf Standalone und Flexibilität ausgelegt ist.
Hier ein guter Artikel: https://www.tutorialworks.com/difference-docker-containerd-runc-crio-oci/

Deine realen Probleme werden nicht von Unterschieden zwischen docker und Kubernetes kommen sondern von Entwickler die nicht verstehen (wollen) dass man Container nicht als root oder User-1001 unter Kubernetes ausführen soll. Versprochen

@d4f wie ist deine persönliche Meinung dazu und auf welchen Unterbau setzt du?

Im Realbetrieb mische ich wild je nach Umgebung und Bedarf. Podman, Docker, Openshift...
Generell starte ich zickige Kubernetes-Container auch gerne mal lokal unter Podman zum debuggen oder rebuilden. Die Idee der Laufzeitumgebung ist dass sogar wenn M$ oder AW$ ihr eigenes Süppchen kochen wollen deine Container noch immer starten - solange sie die OCI einhalten.

 

[Firewire2002]

dass man Container nicht als root oder User-1001 unter Kubernetes ausführen soll

Die root-Geschichte ist selbsterklärend. Aber für die User-1001 (ich geh mal davon aus, es ist die uid gemeint) fehlen mir grad Details. Magst du das kurz etwas weiter ausführen?