Ich hatte in meinem Beitrag Promox auf einem Hetznerserver mit virtuellen Netzwerken beschrieben, wie man virtuelle Netzwerke auf einem Hypervisor mit Hilfe von Linux Bridges erstellt. Diese Netzwerke können dazu verwendet werden, eigene Infrastrukturen aufzubauen und so sehr isoliert VMs zu betreiben.
Wenn nun aber die Ressourcen eines Hosts zur Neige gehen und man einen weiteren Host aufstellt, dann kommt irgendwann vielleicht der Wunsch auf VMs übergreifend in einem dieser virtuellen Netzwerke betreiben zu können. Damit diese möglich ist, muss es aber eine Verbindung dieser beiden Bridges (Netzwerke) geben, welche die Kommunikation ermöglicht.
Dazu kann man super OpenVSwitch einsetzen. Dieses Projekt ist ohnhin sehr interessant, da es sich bei vielen Lösungen wiederfindet - so zum Beispiel auch bei Proxmox und OpenStack.
Damit man über Hardwaregrenzen hinweg ein virtuelles Netzwerk aufspannen kann, muss man sich erst einen virtuelle Switch aufbauen. Zur Sicherheit aktivieren ich auch gleich STP
ovs-vsctl add-br vmbr2
ovs-vsctl set bridge vmbr2 stp_enable=trueIn diesem Switch packt man dann die Netzwerkkarten der virtuellen Maschinen.
ovs-vsctl add-port vmbr2 tap100i2Sobald dies auf beiden Hosts passiert ist, kann man mit Hilfe eines GRE Tunnels diese beiden Switches verbinden.
ovs-vsctl add-port vmbr2 gre1 -- set interface gre1 type=gre options:remote_ip=XXX.XXX.XXX.XXXXXX.XXX.XXX.XXX ist natürlich die IP-Adresse des anderen Servers.
Und weil ich ein Fan von Proxmox bin und grundsätzlich schon recht bequem, hab ich keine Lust das jedes Mal von Hand zu machen und trage es daher einfach in die /etc/network/interfaces ein.
auto vmbr2
allow-ovs vmbr2
iface vmbr2 inet manual
ovs_type OVSBridge
post-up ovs-vsctl set bridge vmbr2 stp_enable=true
post-up ovs-vsctl add-port vmbr2 gre1 -- set interface gre1 type=gre options:remote_ip=XXX.XXX.XXX.XXX**Quellen und Links: *** http://docs.openvswitch.org/en/latest/faq/configuration/
Auch wenn es mir manchmal so scheint, als wäre es nicht mehr üblich, so versuche ich die Software in meinem Lager aktuell zu halten. Allein schon um mir keine Sorgen machen zu müssen, wenn es mal in Richtung Sicherheit geht.
Bei so Funky-Software-Products wie Kubernetes ist es um so wichtiger - ansonsten hat man richtig Arbeit, wenn es mal wirklich sein muss.
In vorausgesetzt man hat genug Platz auf / kann man auf einem CentOS wie folgt ein Upgrade von zum Beispiel 1.13.x auf 1.14.x durchführen:
yum clean all
yum makecache
yum list --showduplicates kubeadm --disableexcludes=kubernetes
**Hier sucht man sich die aktuellste Version heraus**
yum install -y kubeadm-**1.14.1-0** --disableexcludes=kubernetes
kubeadm upgrade plan
**Nun bekommt man gesagt, was man tun muss**
kubeadm upgrade apply v1.14.1
systemctl daemon-reload
systemctl restart kubeletWenn man dann irgendwann
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.14.1". Enjoy!
auf dem Schirm hat ist schon die Hälfte gewonnen. Mal sollte nun natürlich noch schauen, dass man seine restlichen Komponenten aktuell hält:
yum install -y kubelet-1.14.1-0 kubectl-1.14.1-0 --disableexcludes=kubernetesJetzt geht es weiter bei den Minions.
yum clean all
yum makecache
yum install -y kubeadm-1.14.1-0 --disableexcludes=kubernetes
kubeadm upgrade node config --kubelet-version v1.14.1
yum install -y kubelet-1.14.1-0 kubectl-1.14.x-0 --disableexcludes=kubernetes
systemctl daemon-reload
systemctl restart kubeletKontrolle ist besser als Vertrauen. Daher auf einem Knoten das folgende Kommando ausführen:
kubectl get nodes
und hoffen das nirgends ein NotReady steht... Ansonsten ist dann wohl alles getan.
Wenn man mehrer Knoten hat und keinen Bock verspürt ein Ansible Skript zu bauen, dann kann man super ClusterSSH nutzen und sich ein bischen mehr wie ein Operator fühlen.
Quellen und Links: