Wenn man einen Kubernetes Cluster mit Rancher betreibt, dann ist man leider auf die eine der andere Komponente angewiesen, damitman diese schöne bunte Oberfläche betreiben kann. Eine dieser Komponenten ist der Rancher Agent, den es bei einem funktionierenden Cluster dann als Node-Agent und als Cluster-Agent zu finden gibt.
Wenn man mal mit einem Glas Bier auf dem Tisch den Rancher aktualisiert, dann passiert es bei einem Versionssprung auch, dass eben dieser seine Agenten auf die gleiche Version nachzieht wie er sie selbst hat.
Betreibt man das ganze mit einer privaten CA, dann könnte man sich hier den Tag versauen.
Daher sollte man aufpassen, dass man bei einem
helm install rancher rancher-latest/rancher --namespace cattle-system --set hostname=rancher.my.org --set ingress.tls.source=secret --set privateCA=trueGenau das --set privateCA=true nicht vergisst. Denn sollte man das tun, dann findet sich im Deployment der Agenten eine leere Variable CATTLE_CA_CHECKSUM die auch dann nicht mit Leben gefüllt wird, wenn man das oben genannte Flag setzt. Das muss man dann schon selbst machen. Ansonsten bleiben die Agenten mit einem CrashLoopBackOff einfach stehen.
Verpennt man das einmal, muss man es wie gesagt selbst machen, ein aus der Hüfte kommendes:
kubectl edit deployment -n cattle-system cattle-cluster-agenthilft dabei aber enorm.
Ich hab bei meinen Reisen durch das Internet mal wieder allerhand gefunden.
Eine richtige coole und brauche Kubernetes-UI... damit kann man sich auch das Dashboard in seinem Cluster sparen. Wirklich nett finde ich, das man sich mehrere cluster einrichten kann, die man dann natürlich auch damit im Wechsel ansprechen und verwalten kann.
https://opensource.com/article/20/6/kubernetes-lens
Kubernetes as a Service... so wird die Zukunft lauten... Ebene auf Ebene auf Ebene auf Ebene... wer sich schon mal damit befassen will, kann sich OpenInfra anschauen.
https://github.com/oneinfra/oneinfra?utm_sq=ge2xx3zj5m
Ich steh ja total auf dieses ganze Mesh Zeug. Schon immer war ich an verteilten Systemen interessiert. Nebula macht quasi MeshVPN... ein bisschen wie tinc auf steroiden... Sehr, sehr cool.
https://github.com/slackhq/nebula https://www.innoq.com/de/blog/nebula-vpn/ https://haxys.net/tutorials/toolkit/0-dropbox/3-nebula/
OpenGPG Milter ist quasi en Addon für deinen Mailserver und vereinfacht dir das Arbeiten mit OpenGPG.
https://github.com/letoams/openpgpkey-milter
Ich war sehr froh zu sehen, das man auch mit der Hetznercloud so autoscaling Dingens machen kann - und zwar super easy. Wer also seine Infrastruktur ein wenig dynamischer haben will, kann es mal mit diesem super Artikel versuchen.
Bei der Pod-Security-Policy habe ich doch die eine oder andere Minute gebraucht um dahinter zu steigen wo ich wie und was am besten machen kann. Dieser Artikel war wirklich eine Hilfe um da einmal den Einstieg zu finden. Es geht natürlich um Kubernetes.
https://octetz.com/docs/2018/2018-12-07-psp/?utm_sq=gf4j2xy1er
Storage ist bei Kubernetes ein wahrer PainPoint. Wer sich mal die für mich gängigen Lösungen - auch im Vergleich - anschauen möchte, sollte einen Blick riskieren. ich mag ja die einfachen Lösungen...
https://vitobotta.com/2019/08/06/kubernetes-storage-openebs-rook-longhorn-storageos-robin-portworx/ https://openebs.io/ https://storageos.com/ https://longhorn.io/
Ich arbeite ja gern mit verteilten Systemen und auch das ganze provisionierungszeug macht mir eine Menge Spaß. Weil das aber immer Fehleranfällig ist, wenn man nicht schon in einer durchgestylen Umgebung arbeitet, mache ich mir beim Aufbau einer solchen immer ein paar wiederverwendbare Notitzen in Form eines "quick and dirty" Skriptes.
So hat es sich mittlerweile als ganz brauchbar herausgestellt die folgenden Schritte beim Setup eines RKE Nodes für die Nutzung von Kubernetes zu gehen:
yum upgrade -y
yum install -y arptables.x86_64 ebtables.x86_64 nscd.x86_64 iptables.x86_64 nftables.x86_64 conntrack-tools.x86_64
systemctl start nscd nftables
systemctl enable nscd nftablesuseradd -m -G docker rke
passwd rke
su - rke
mkdir $HOME/.ssh
chmod 700 $HOME/.ssh
touch $HOME/.ssh/authorized_keys
echo "PLEASE PUT YOUR SSH KEY HERE" >> /home/rke/.ssh/authorized_keysDieser Schritt ist nur für Knoten notwendig die etcd hosten werden.
groupadd --gid 52034 etcd
useradd --comment "etcd service account" --uid 52034 --gid 52034 etcdSofern vorhanden richte ich immer ganz gern die wichtigsten Knoten in einem Cluster so ein, das sie auch im Falle eines DNS Ausfalls miteinander sprechen können .
111.222.000.111 node1 node1.localdomain 111.222.000.112 node2 node3.localdomain 111.222.000.113 node3 node3.localdomain 127.0.0.1 localhost localhost.local
cat << EOF > /etc/sysctl.d/90-kubelet.conf
vm.overcommit_memory=1
vm.panic_on_oom=0
kernel.panic=10
kernel.panic_on_oops=1
kernel.keys.root_maxbytes=25000000
EOF
sysctl -p /etc/sysctl.d/90-kubelet.confWenn man der offizielle Doku folgt, dann ist das hier gar nicht so unwichtig
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sudo sysctl --systemIch brauche in den Netzwerken in denen ich arbeite kein IPv6. Daher kommt raus was keine Miete zahlt.
cat <<EOF | sudo tee /etc/sysctl.d/disable-ipv6.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
EOF
sudo sysctl -p -f /etc/sysctl.d/disable-ipv6.conftimedatectl set-timezone "Europe/Berlin"
Die Module werden immer wieder gern vergessen. Daher habe ich sie immer in einem meiner Skripte mit dabei.
cat <<EOF | sudo tee /etc/modules-load.d/rke.conf
ip6_udp_tunnel
ip_set
ip_set_hash_ip
ip_set_hash_net
iptable_mangle
iptable_raw
nf_conntrack
veth
vxlan
xt_comment
xt_mark
xt_multiport
xt_nat
xt_recent
xt_set
xt_statistic
xt_tcpudp
nf_conntrack
EOF
for i in $(cat /etc/modules-load.d/rke.conf)
do
modprobe $i
doneVertrauen ist gut - Kontrolle ist besser
for module in br_netfilter ip6_udp_tunnel ip_set ip_set_hash_ip ip_set_hash_net iptable_filter iptable_nat iptable_mangle iptable_raw nf_conntrack_netlink nf_conntrack nf_defrag_ipv4 nf_nat nf_nat_ipv4 nfnetlink udp_tunnel veth vxlan x_tables xt_addrtype xt_conntrack xt_comment xt_mark xt_multiport xt_nat xt_recent xt_set xt_statistic xt_tcpudp;
do
if ! lsmod | grep -q $module; then
echo "module $module is not present";
fi;
doneRancher hat ja schon alles für eine einfache Installation vorbereitet. Daher nutze ich auch einfach deren Skript zur Installation von Docker.
curl https://raw.githubusercontent.com/rancher/install-docker/master/19.03.12.sh | sh
systemctl enable docker
systemctl stop docker
systemctl start docker# For etcd nodes, run the following commands:
firewall-cmd --permanent --add-port=2376/tcp
firewall-cmd --permanent --add-port=2379/tcp
firewall-cmd --permanent --add-port=2380/tcp
firewall-cmd --permanent --add-port=8472/udp
firewall-cmd --permanent --add-port=9099/tcp
firewall-cmd --permanent --add-port=10250/tcp
# For control plane nodes, run the following commands:
firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --permanent --add-port=443/tcp
firewall-cmd --permanent --add-port=2376/tcp
firewall-cmd --permanent --add-port=6443/tcp
firewall-cmd --permanent --add-port=8472/udp
firewall-cmd --permanent --add-port=9099/tcp
firewall-cmd --permanent --add-port=10250/tcp
firewall-cmd --permanent --add-port=10254/tcp
firewall-cmd --permanent --add-port=30000-32767/tcp
firewall-cmd --permanent --add-port=30000-32767/udp
# For worker nodes, run the following commands:
firewall-cmd --permanent --add-port=22/tcp
firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --permanent --add-port=443/tcp
firewall-cmd --permanent --add-port=2376/tcp
firewall-cmd --permanent --add-port=8472/udp
firewall-cmd --permanent --add-port=9099/tcp
firewall-cmd --permanent --add-port=10250/tcp
firewall-cmd --permanent --add-port=10254/tcp
firewall-cmd --permanent --add-port=30000-32767/tcp
firewall-cmd --permanent --add-port=30000-32767/udp
firewall-cmd --reload