Kubernetes K8 dyndns über fritzbox mit letsencrypt wildcard ingress und metallb

Echt jetzt ohne zusätzliche Kosten von Zuhause mit allen Möglichkeiten wie in einer echten Cloud ?

jap !!! 😉

Was Du benötigst ist:

1 x Eigenen Rechner oder Laptop oder raspberry pi (4/5)
1 x Fritzbox mit Internet (gehen aber auch andere)

! ACHTUNG zu aller erst ein WARNUNG !
Ihr solltet Euch selbst auch ein wenig auskennen mit Netzwerk Konfiguration etc. den schließlich gebt ihr Euren Rechner / Server / Raspberry im Internet frei. Also aufgepasst !
Immer alle zugriffe mit SSH auf dem System absichern, gute Passwörter,und besten falls die Firewall mit iptables / ufw absichern , so dass nur noch Port 80 und 443 offen bleibt. auch gerne „fail2ban“ zusätzlich einrichten, gegen SSH attacken!
Die Anwendung der folgenden Schritte geschieht auf eigene Gefahr hin!

Fritzbox für den Zugriff auf Euren ziel Rechner einrichten zB extra Server oder Raspberry:

Legt Euch bei zB. https://ddnss.de/ eine eigene kostenlose Dyndns Adresse an.
Diese könnt ihr in der Fritzbox dann mit Dyndns Freigabe verknüpfen so das Eure IP des Internet Providers immer auf Eure Adresse zeigt und bei evtl. wechsel automatisch aktualisiert wird.
Die benötigten Login Daten werden Euch bei ddnss.de angezeigt!

In der Fritzbox solltet ihr unter Freigabe Euren Rechner freigeben, es reichen zu aller erst Port 80 und 443 !
Dieser Port wird dann mit Eurer neuen Dyndns Adresse erreichbar sein!

Wenn alles richtig gelaufen ist müsste Eure neue Dyndns Adresse jetzt auf Eure IP zeigen.
Kann auf der Fritzbox manchmal auch einen kleinen Moment dauern!
Testen könnt ihr das mit zB. nslookup <Eure-neue-dyndns-Adresse>

KIND Cluster und weitere benötigte Tools und konfigs anlegen:

Ich installiere zuerst einen KIND Cluster auf Docker Basis.
Ich gehe daher davon aus das ihr Docker bereits auf eurem System installiert habt!
Legt Euch für diverse folgenden Dateien ein eigenes Verzeichnis an zB. „Kind-Cluster“

Helm Package Manager installieren.

curl -o helm-v3.10.3-linux-amd64.tar.gz https://get.helm.sh/helm-v3.10.3-linux-amd64.tar.gz
chmod 777 helm-v3.10.3-linux-amd64.tar.gz
tar -zxvf helm-v3.10.3-linux-amd64.tar.gz
mv linux-amd64/helm /usr/local/bin/helm
ll /usr/local/bin/helm
rm helm-v3.10.3-linux-amd64.tar.gz

Fügt Euch das „Kubnertes Repository“ hinzu für Centos oder Ubuntu je nach Eurem verwendeten Betriebssystem:

cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.29/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.29/rpm/repodata/repomd.xml.key
EOF

Installiere das Command Line Tool „kubectl“, und die bash completion, falls nicht schon vorhanden:

yum update
yum install -y kubectl
kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null 
echo 'alias k=kubectl' >>~/.bashrc 
echo 'complete -o default -F __start_kubectl k' >>~/.bashrc

Installieren das KIND Packet:

[ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.22.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

Dann lege ich eine Konfiguration für den Kind Cluster an (minimalistisch one Node), könnt ihr gerne auf 3 erweitern. File-> kind-config

# wenn ihr mehr worker wollt nehm unten die Kommentare raus!

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4

nodes:
- role: control-plane
  kubeadmConfigPatches:
- |
  kind: InitConfiguration
  nodeRegistration:
    kubeletExtraArgs:
      node-labels: "ingress-ready=true"
extraPortMappings:
- containerPort: 80
  hostPort: 80
  protocol: TCP
- containerPort: 443
  hostPort: 443
  protocol: TCP

# - role: worker
# - role: worker
# - role: worker

Und jetzt den Cluster installieren und starten:

kind create cluster --config kind-config

Aber der stelle sollte der Kind Cluster laufen, gerne prüfen mit:
kubectl get all -A

Installieren den Cert-Manager:

kubectl create namespace cert-manager
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.4/cert-manager.crds.yaml
helm repo add jetstack https://charts.jetstack.io
helm install my-release --namespace cert-manager --version v1.14.4 jetstack/cert-manager -f values.yaml

Ich empfehle für Letsencrypt zwei Config definition für „staging“ zum testen und danch „production“.
Staging ist wichtig, denn wenn bei dem Letsencrypt versuchen am Anfang etwas schief laufen sollte, lauft ihr nicht gleich in ein Rate Limit bei dem Letsencrypt Anbieter. Datei Anlegen -> clusterissuer.yaml

# clusterissuer.yaml 
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-production
  namespace: cert-manager
spec:
  acme:
    email: <Deine eMail>
    privateKeySecretRef:
      name: letsencrypt-production
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - http01:
        ingress:
          class: nginx

---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
  namespace: cert-manager
spec:
  acme:
    email: <Deine eMail>
    privateKeySecretRef:
      name: letsencrypt-staging
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    solvers:
    - http01:
        ingress:
          class: nginx

Tausche in der Datei <Deine eMail> mit Deiner EMail Adresse aus ohne dabei die Klammern zu belassen 😉
Die Datei muss auf dem Cluster mit kubectl apply-f clusterissuer.yaml ausgeführt / installiert werden.

Metallb installieren.

Das wichtigste von allem. Der metallb holt sich von deiner Fritzbox ein pool an IP’s prinzipiell nur eine 😉
Damit er dies tun kann benötigt er einen Scope Bereich welcher für die Fritzbox unten konform angegeben ist. Vergleiche deine Einstellungen in der Fritzbox und schau das diese mit deinen DHCP konform wären.
zb:

Datei anelgen -> values-metal.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
      - name: default
        protocol: layer2
        addresses:
        - 192.168.178.53-192.168.178.200

Metallb nun installieren mit

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.10.2/manifests/namespace.yaml kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.10.2/manifests/metallb.yaml kubectl apply-f values-metal.yaml

nginx-webserver installieren:

Nun benötigen wir noch einen test nginx-webserver, den könnt ihr später gerne gegen Eure Rollouts von Applikationen austauschen. Datei anlegen -> test-deploy-service.yaml

# DEPLOYMENT
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: httpd
  name: httpd
  namespace: webserver

  spec:
    selector:
      matchLabels:
        app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
      - image: httpd:2.4.46
      name: httpd
status: {}

# SERVICE
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: httpd
  name: httpd
  namespace: webserver

spec:
  selector:
    app: httpd
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  type: LoadBalancer
  selector:
    app: httpd
status:
  loadBalancer: {}

Auch die Datei wieder mit kubectl apply -f test-deploy-service.yaml ausführen.

Jetzt noch eine Ingress Konfiguration Datei Ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpd-ingress
  namespace: webserver
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
  # cert-manager.io/cluster-issuer: "letsencrypt-production"
    cert-manager.io/cluster-issuer: "letsencrypt-staging"

spec:
  tls:
  - hosts:
     - Deine.ddnss.org
     - subdomain.Deine.ddnss.org
     secretName: Deine.ddnss.org

rules:
- host: Deine.ddnss.org
  http:
    paths:
      - path: /
      pathType: Prefix
      backend:
        service:
          name: httpd
          port:
           number: 80

- host: subdomain.Deine.ddnss.org
  http:
    paths:
    - path: /
    pathType: Prefix
    backend:
    service:
      name: httpd
      port:
        number: 80

Vorher die Namen: subdomain  mit einem Namen Deiner wahl austauschen.
Vorher auch den Namen  „Deine“ gegen Deine Dyndns Adresse austauschen!

Auch die Datei wieder mit kubectl apply -f ingress.yaml ausführen.

Das sollte es gewesen sein.
Es sollten zwei Domains zu Verfügung stehen mit https.
Auch wenn die Domains noch als unsicher bemeckert werden so ist dies ein staging Zertifikat und normal!
Ihr könnt in der Config oben, den Kommentar von staging auf production wechseln, dann sollte es ein production Zertifikat geben.

Ein paar Befehle für die Analyse diverser Kubernetes Configs:

kubectl get clusterissuer
kubectl describe clusterissuer

kubectl get ingress 
kubectl describe ingress

kubectl get svc

kubectl delete cert mywebsite-tls -n <cert_namespace>

kubectl get certificate --all-namespaces
kubectl describe issuer letsencrypt-staging
kubectl describe secret quickstart-example-tls


kubectl describe certificaterequest
kubectl describe order
kubectl describe challenge
kubectl get challenges

show logs

=========

kubectl -n cert-manager logs -f --tail 20 $(kubectl -n cert-manager get pod -l app=cert-manager -o jsonpath='{.items[0].metadata.name}')
kubectl -n cert-manager logs $(kubectl -n cert-manager get pod -l app=cert-manager -o jsonpath='{.items[0].metadata.name}')

HELM Commands
=============
helm search repo -l 


INSTALL Cert_amanger CLI
========================
OS=$(go env GOOS); ARCH=$(go env GOARCH); curl -fsSL -o cmctl https://github.com/cert-manager/cmctl/releases/latest/download/cmctl_${OS}_${ARCH}
chmod +x cmctl
sudo mv cmctl /usr/local/bin