Kubernetes und CI

Was Sie erreichen werden

Wann Sie das brauchen

Was Sie brauchen

Bevor Sie beginnen

Einrichtung

1. 1

   Den Schlüssel des Clusters anlegen und als Secret ablegen

   Access › Enrollment keys › Create enrollment key:

   • Name - k8s-prod-router.
   • Make this key reusable - an, damit sich ein Pod, der sein Volume verloren hat, neu registrieren kann.
   • Expires in - leer, dann läuft der Schlüssel nie ab.
   • Usage limit - 5. Nur ein neues Gerät verbraucht eine Nutzung, ein Neustart nicht.
   • Temporary devices, Allow Extra DNS Labels - aus. Ein Routing-Gerät muss während des Reschedulings seines Pods in der Liste bleiben.
   • Auto-assigned groups - tippen Sie k8s-routers ein und drücken Sie Enter.

   Wählen Sie Create enrollment key und kopieren Sie den Schlüssel: Er wird nur einmal angezeigt.

   Führen Sie den Block unten, wie auch Schritt 2, dort aus, wo kubectl den Cluster heute schon erreicht. Er legt den Schlüssel als Secret in einem Namespace ab, der die Capabilities des Agenten erlaubt, und hält ihn aus Ihrer Shell-Historie und Ihren Manifesten heraus. Führen Sie den Block in bash oder zsh aus (macOS, Linux, WSL). Fügen Sie den ganzen Block ein und drücken Sie einmal Enter. Sobald Enrollment key: erscheint, fügen Sie den Schlüssel ein, und nur ihn, und drücken Sie Enter. Der Schlüssel wird nicht angezeigt, und bei einer leeren Zeile fragt der Block erneut.

   Sie sehen: secret/sxaccess-key created.

   shellKopieren

   kubectl create namespace sxaccesskubectl label namespace sxaccess pod-security.kubernetes.io/enforce=privileged{  KEY=''  until [ -n "$KEY" ]; do printf 'Enrollment key: '; read -rs KEY || break; echo; done  [ -n "$KEY" ] && kubectl -n sxaccess create secret generic sxaccess-key --from-literal=enrollment-key="$KEY"  unset KEY}

2. 2

   Den Agenten als einzelnes Deployment betreiben

   Speichern Sie das Manifest unten als sxaccess-router.yaml, ersetzen Sie den Platzhalter durch das Image aus Add device › Docker und führen Sie kubectl apply -f sxaccess-router.yaml aus. Setzt der Befehl dort weitere Variablen mit -e, übernehmen Sie sie unter env.

   Das Image startet den Agenten und führt sxaccess start aus, mit dem Schlüssel aus SX_ENROLLMENT_KEY und dem Namen aus SX_HOSTNAME. BPF ist optional. strategy: Recreate beendet den alten Pod, bevor der neue startet; so teilen sich nie zwei Pods die Identität auf dem Volume.

   Sie sehen: Nach etwa einer Minute beginnt die Ausgabe von kubectl -n sxaccess exec deploy/sxaccess-router -- sxaccess info mit Connected, und k8s-router-prod steht unter Devices in k8s-routers. Running allein beweist nicht, dass sich der Pod registriert hat.

   shellKopieren

   apiVersion: v1kind: PersistentVolumeClaimmetadata:  name: sxaccess-state  namespace: sxaccessspec:  accessModes: ["ReadWriteOnce"]  resources:    requests:      storage: 1Gi---apiVersion: apps/v1kind: Deploymentmetadata:  name: sxaccess-router  namespace: sxaccessspec:  replicas: 1  strategy:    type: Recreate  selector:    matchLabels: { app: sxaccess-router }  template:    metadata:      labels: { app: sxaccess-router }    spec:      containers:        - name: sxaccess          image: IMAGE-FROM-ADD-DEVICE-DOCKER   # aus Add device > Docker kopieren          securityContext:            capabilities:              add: ["NET_ADMIN", "NET_RAW"]     # "BPF" ist optional          env:            - name: SX_ENROLLMENT_KEY              valueFrom:                secretKeyRef:                  name: sxaccess-key                  key: enrollment-key            - name: SX_HOSTNAME              value: k8s-router-prod          volumeMounts:            - name: state              mountPath: /var/lib/sxaccess      volumes:        - name: state          persistentVolumeClaim:            claimName: sxaccess-state

3. 3

   Sich selbst in die Gruppe platform aufnehmen

   Die Regel aus Schritt 4 lässt die Gruppe platform den API-Server erreichen. Legen Sie die Gruppe gleich mit Ihrem Notebook an: Öffnen Sie People › Members › Ihren Eintrag › Access, tippen Sie platform unter Auto-assigned groups ein, drücken Sie Enter und wählen Sie Save Changes. Wiederholen Sie das für jeden Entwickler. Ihr Notebook kommt sofort hinein, weil die Gruppenweitergabe standardmäßig eingeschaltet ist.

   Sie sehen: platform neben Ihrem Notebook unter Devices.

4. 4

   Den API-Server veröffentlichen

   Networks › Internal networks › Add internal network: Network Name k8s-prod, dann Add Network. Drei Formulare folgen:

   • Add Resource - Name Kubernetes API; so zeigen die Apps und sxaccess reach list die Ressource an. Address: der Host aus der Zeile server: Ihrer kubeconfig, ohne https:// und Port. Destination Groups: Tippen Sie k8s-prod-api ein und drücken Sie Enter. Wählen Sie dann Add Resource.
   • Create access rule - das Ziel ist bereits Kubernetes API. Wählen Sie platform als Quelle, dann TCP. Klicken Sie in das Port-Feld, tippen Sie den Port aus der Zeile server: ein (443, wenn sie keinen nennt) und drücken Sie Enter: Das Feld zeigt ihn statt All. Wählen Sie dann Create access rule.
   • Add Routing Device - wählen Sie unter Device group k8s-routers, dann Continue. Lassen Sie Masquerade eingeschaltet und wählen Sie Add Routing Device. Die Gruppe deckt auch einen Pod ab, der sich neu registriert.

   Sie sehen: Die Zeile k8s-prod zeigt 1 resource, 1 device und platform. Wie Sie zusätzlich einen Service veröffentlichen, steht unter Erweiterte Konfiguration.

5. 5

   CI einen eigenen Schlüssel und eine eigene Zugriffsregel geben

   Legen Sie für die Runner einen zweiten Schlüssel an, unter Access › Enrollment keys › Create enrollment key:

   • Name - ci-runners. Make this key reusable - an.
   • Expires in - 90. Ersetzen Sie den Schlüssel vorher: neuer Schlüssel, neues CI-Secret, alter Schlüssel widerrufen.
   • Usage limit - leer. Jeder Job verbraucht eine Nutzung, ein Limit würde CI also irgendwann anhalten.
   • Temporary devices - an: Ein fertiger Runner wird etwa 10 Minuten, nachdem er offline gegangen ist, entfernt. Später lässt sich das nicht mehr einschalten. Allow Extra DNS Labels - aus.
   • Auto-assigned groups - tippen Sie ci-runners ein und drücken Sie Enter.

   Wählen Sie Create enrollment key und hinterlegen Sie den Schlüssel, der nur einmal angezeigt wird, als maskierte geheime CI-Variable namens CI_SXACCESS_KEY. Klicken Sie dann in der Netzwerkliste auf k8s-prod und wählen Sie in der Zeile Kubernetes API Add Access rule. Wählen Sie ci-runners, TCP und denselben Port, dann Create access rule. Mehr bekommen Runner nicht: Ein Build führt Code aus Pull Requests aus.

   Sie sehen: In der Zeile Kubernetes API zeigt die Spalte Access rules 2, und in der Netzwerkliste steht in der Zeile k8s-prod jetzt ci-runners neben platform.

6. 6

   Jeden Job verbinden und am Ende trennen

   Auf einem VM-Runner, auf dem der Job root oder sudo hat, nehmen Sie den Block unten. Die Startzeilen kommen an den Anfang des Jobs, sxaccess stop in den Schritt, den Ihr CI-System nach jedem Job ausführt, ob erfolgreich oder nicht. CI_JOB_ID steht für die Jobnummer Ihres CI-Systems, damit jeder Runner einen eigenen Namen bekommt.

   Ein Job in einem Container hat keine Dienstverwaltung; nehmen Sie dort den Block nach diesen Schritten, der den Agenten selbst startet und wartet, bis der Agent antwortet. Der Job braucht root, NET_ADMIN und NET_RAW. Wo Ihr CI das nicht gewähren kann, wie bei den meisten geteilten Container-Runnern, nehmen Sie einen VM-Runner.

   Sie sehen: Während der Job läuft, steht der Runner unter Devices als ci- mit der Jobnummer. Etwa 10 Minuten nach Jobende ist er verschwunden.

   shellKopieren

   # Zu Beginn des Jobs, auf einem VM-Runner.curl -fsSL https://pkgs.sxaccess.com/install.sh | shSX_ENROLLMENT_KEY="$CI_SXACCESS_KEY" sxaccess start --hostname "ci-$CI_JOB_ID"# Am Ende des Jobs, ob erfolgreich oder nicht: im Nach-Job-Schritt Ihres CI-Systems.sxaccess stop

Prüfen

Fehlersuche

Erweiterte Konfiguration

Verwandte Themen