infinity-learn/docs — German @ Infinity Labs Translation: 7. structure-live-first

Zen

	English	German	Actions
	A Kubernetes pod doesn't run your source — it runs a container image, a sealed tarball of your app + its dependencies. That image has to live somewhere the cluster can pull it from: a registry. Here it's Harbor, at `docker.registry.infinity.labs` (on the infinix VPN IP).	Ein Kubernetes-Pod führt nicht deinen Quellcode aus — er führt ein Container-Image aus, einen versiegelten Tarball deiner App + ihrer Abhängigkeiten. Dieses Image muss irgendwo liegen, wo der Cluster es ziehen kann: einer Registry. Hier ist es Harbor, unter `docker.registry.infinity.labs` (auf der infinix-VPN-IP).
	> Recon caught a real bug here: the manifests carried a wrong registry host > (`registry.infinix.labs.ooo`) that would have made every image ref > unresolvable. The read-only recon step fixed it to the real > `docker.registry.infinity.labs` before anything tried to pull. This is why > recon-first earns its keep.	> Recon fing hier einen echten Bug: die Manifeste trugen einen falschen > Registry-Host (`registry.infinix.labs.ooo`), der jede Image-Referenz unauflösbar > gemacht hätte. Der read-only-Recon-Schritt korrigierte ihn auf den echten > `docker.registry.infinity.labs`, bevor irgendetwas zu ziehen versuchte. Genau > darum verdient recon-first seinen Lohn.
	Two credentials touch the registry, and they're different directions:	Zwei Credentials berühren die Registry, und sie zeigen in verschiedene Richtungen:
	push (write): `docker login` + `docker push` — needs a robot account that can write to `lernreise/*`.	push (schreiben): `docker login` + `docker push` — braucht ein Robot-Konto, das nach `lernreise/*` schreiben darf.
	pull (read): the pod needs a `harbor-registry` pull-secret so the kubelet can fetch the image when it schedules.	pull (lesen): der Pod braucht ein `harbor-registry`-Pull-Secret, damit das kubelet das Image beim Einplanen holen kann.
	Both derive from one external robot credential that Harbor mints. Harbor is an outside system — you cannot conjure that credential locally; a human seeds it once (this is residual R2, §8). The image is pinned by digest (`@sha256:…`), never a mutable `:latest` tag, so the deployment can never silently drift to a different image.	Beide leiten sich aus einem externen Robot-Credential ab, das Harbor erzeugt. Harbor ist ein Außensystem — du kannst dieses Credential nicht lokal heraufbeschwören; ein Mensch sät es einmal (das ist Restposten R2, §8). Das Image wird per Digest gepinnt (`@sha256:…`), nie per mutierbarem `:latest`-Tag, sodass das Deployment nie stillschweigend zu einem anderen Image abdriften kann.
	6. iSecrets: the audited key-ring	6. iSecrets: der auditierte Schlüsselbund
	Secrets never live in git and never get typed by hand. They flow through iSecrets — the concept — whose real store is `pass.manager` (`~/my/ai/agents/infinity/pass.manager/`): GPG-encrypted `pass`, wrapped by an audited library `haiku/lib.sh` that logs every access to `data/audit.log`.	Secrets leben nie in git und werden nie von Hand getippt. Sie fließen durch iSecrets — das Konzept — dessen echter Store `pass.manager` ist (`~/my/ai/agents/infinity/pass.manager/`): GPG-verschlüsseltes `pass`, umhüllt von einer auditierten Bibliothek `haiku/lib.sh`, die jeden Zugriff nach `data/audit.log` protokolliert.
	source ~/my/ai/agents/infinity/pass.manager/haiku/lib.sh pass_get <path> [fallback] # retrieve — audited GET by EXACT path pass_set <path> [value] # store — audited SET (stdin if no value) pass_exists <path> # presence — fail-closed, leaks no value pass_generate <path> [len] # generate + store a strong secret	source ~/my/ai/agents/infinity/pass.manager/haiku/lib.sh pass_get <path> [fallback] # abrufen — auditierter GET per EXAKTEM Pfad pass_set <path> [value] # speichern — auditierter SET (stdin wenn kein value) pass_exists <path> # Präsenz — fail-closed, leakt keinen Wert pass_generate <path> [len] # ein starkes Secret erzeugen + speichern
	The rule is named retrieval, never vault scanning: you ask for the exact path, the access is audited, and that is the only sanctioned read. Sweeping the GPG store hunting for "a token that might work" is the anti-pattern this replaces.	Die Regel ist benannter Abruf, nie Vault-Scannen: du fragst nach dem exakten Pfad, der Zugriff wird auditiert, und das ist die einzige sanktionierte Lesung. Den GPG-Store nach »einem Token, das funktionieren könnte« zu durchforsten ist das Anti-Muster, das dies ersetzt.
	Two ways a secret becomes a live k8s `Secret`, both sourced from `pass` at apply-time (never committed, never in the image):	Zwei Wege, wie ein Secret zu einem Live-k8s-`Secret` wird, beide aus `pass` zur Apply-Zeit bezogen (nie committet, nie im Image):
	# (a) the registry pull-secret, born from iSecrets: kubectl create secret docker-registry harbor-registry \ --namespace lernreise-garden \ --docker-server=docker.registry.infinity.labs \ --docker-username="$(pass_get harbor/lernreise-garden/robot-user)" \ --docker-password="$(pass_get harbor/lernreise-garden/robot-password)" \ --dry-run=client -o yaml \| kubectl apply -f - # (b) a keypair, GENERATED ON INFINIX, split by trust: # private key → the MINTER namespace; public key → the VERIFIER namespace kubectl create secret generic lernreise-session-privkey --namespace grow-main \ --from-literal=session.key="$(pass_get keys/lernreise-session-ed25519)" \ --dry-run=client -o yaml \| kubectl apply -f - kubectl create secret generic lernreise-session-pubkey --namespace lernreise-garden \ --from-literal=session.pub="$(pass_get keys/lernreise-session-ed25519.pub)" \ --dry-run=client -o yaml \| kubectl apply -f -	# (a) das Registry-Pull-Secret, aus iSecrets geboren: kubectl create secret docker-registry harbor-registry \ --namespace lernreise-garden \ --docker-server=docker.registry.infinity.labs \ --docker-username="$(pass_get harbor/lernreise-garden/robot-user)" \ --docker-password="$(pass_get harbor/lernreise-garden/robot-password)" \ --dry-run=client -o yaml \| kubectl apply -f - # (b) ein Keypair, AUF INFINIX ERZEUGT, nach Vertrauen aufgeteilt: # privater Schlüssel → der MINTER-Namespace; öffentlicher Schlüssel → der VERIFIER-Namespace kubectl create secret generic lernreise-session-privkey --namespace grow-main \ --from-literal=session.key="$(pass_get keys/lernreise-session-ed25519)" \ --dry-run=client -o yaml \| kubectl apply -f - kubectl create secret generic lernreise-session-pubkey --namespace lernreise-garden \ --from-literal=session.pub="$(pass_get keys/lernreise-session-ed25519.pub)" \ --dry-run=client -o yaml \| kubectl apply -f -
	> Why generate the keypair on infinix, not sync it from pad? The production > private key should be born where it's used and never travel. pad's keypair > was a throwaway test key (minted this session to prove the crypto locally). > Syncing the prod private key pad→infinix would needlessly put it in three > places (pad fs + `pass` + infinix). So: generate fresh on infinix; the > private half stays on the node, in the minter's namespace, never in an image. > The public half goes to the verifier. (This split — minter holds private, > verifier holds public — is just asymmetric crypto: sign with private, check > with public.)	> Warum das Keypair auf infinix erzeugen, nicht von pad synchronisieren? Der > private Produktionsschlüssel sollte dort geboren werden, wo er genutzt wird, und > nie reisen. pads Keypair war ein Wegwerf-Testschlüssel (in dieser Sitzung erzeugt, > um die Krypto lokal zu beweisen). Den privaten Prod-Schlüssel pad→infinix zu > synchronisieren würde ihn unnötig an drei Orte legen (pad-fs + `pass` + infinix). > Also: frisch auf infinix erzeugen; die private Hälfte bleibt auf dem Knoten, im > Namespace des Minters, nie in einem Image. Die öffentliche Hälfte geht zum Verifier. > (Diese Aufteilung — Minter hält privat, Verifier hält öffentlich — ist einfach > asymmetrische Krypto: signieren mit privat, prüfen mit öffentlich.)
	The honest split for this deploy:	Die ehrliche Aufteilung für dieses Deploy:
	\| Item \| Source \| Status \| \|------\|--------\|--------\| \| Ed25519 keypair (private + public) \| auto-generated on infinix, mirrored into iSecrets \| ✅ already present \| \| Harbor robot credential (user + password) \| operator seeds ONCE (external system) \| ⛔ residual R2 \| \| `harbor-registry` pull-secret \| derived from iSecrets at apply-time \| waits on R2 \| \| `…-privkey` / `…-pubkey` Secrets \| derived from iSecrets \| ready \|	\| Posten \| Quelle \| Status \| \|------\|--------\|--------\| \| Ed25519-Keypair (privat + öffentlich) \| auto-erzeugt auf infinix, in iSecrets gespiegelt \| ✅ bereits vorhanden \| \| Harbor-Robot-Credential (user + password) \| Operator sät EINMAL (externes System) \| ⛔ Restposten R2 \| \| `harbor-registry`-Pull-Secret \| aus iSecrets zur Apply-Zeit abgeleitet \| wartet auf R2 \| \| `…-privkey` / `…-pubkey`-Secrets \| aus iSecrets abgeleitet \| bereit \|
	7. structure-live-first	7. structure-live-first
	Here is the real `replicas: 0` walk-through — the cheapest possible proof that the path works, run before any image exists.	Hier ist der echte `replicas: 0`-Durchgang — der billigstmögliche Beweis, dass der Pfad funktioniert, ausgeführt bevor irgendein Image existiert.
	After `gitops-write` staged the manifests (deployment pinned at `replicas: 0`, image ref a `REPLACE_WITH_DIGEST` placeholder) and the per-app CR was applied, Flux reconciled `main@sha1:14ce433` and brought up — with zero pods:	Nachdem `gitops-write` die Manifeste bereitgestellt hatte (Deployment auf `replicas: 0` gepinnt, Image-Referenz ein `REPLACE_WITH_DIGEST`-Platzhalter) und der Per-App-CR angewandt war, reconcilte Flux `main@sha1:14ce433` und brachte hoch — mit null Pods:
	namespace lernreise-garden created ResourceQuota lernreise-garden-quota enforced (rejects pods missing requests+limits) Service lernreise (80/8082) created Ingress lernreise.grow.b0x.store created Deployment lernreise 0/0 ← replicas:0, no image needed, can't crash Certificate lernreise-grow-tls True ← Let's Encrypt prod, ISSUED at 0/0 (!) PVC Pending (WaitForFirstConsumer — normal at 0 replicas)	namespace lernreise-garden created ResourceQuota lernreise-garden-quota enforced (weist Pods ohne requests+limits ab) Service lernreise (80/8082) created Ingress lernreise.grow.b0x.store created Deployment lernreise 0/0 ← replicas:0, kein Image nötig, kann nicht abstürzen Certificate lernreise-grow-tls True ← Let's Encrypt prod, AUSGESTELLT bei 0/0 (!) PVC Pending (WaitForFirstConsumer — normal bei 0 replicas)
	The headline: the TLS certificate issued while the app was dark. That single fact proves DNS resolves, the ingress routes correctly, and the ACME challenge completes end-to-end — all the things most likely to be wrong — with nothing running that could break. Legacy `lernreise` (264d) and `grow-main` (120d) were untouched; the node's ~99% CPU-request booking did not bite cert issuance.	Die Schlagzeile: das TLS-Zertifikat wurde ausgestellt, während die App dunkel war. Diese eine Tatsache beweist, dass DNS auflöst, der Ingress korrekt routet und die ACME-Challenge Ende-zu-Ende abschließt — all die Dinge, die am wahrscheinlichsten falsch sind — mit nichts Laufendem, das kaputtgehen könnte. Das alte `lernreise` (264d) und `grow-main` (120d) waren unangetastet; die ~99%-CPU-Request-Buchung des Knotens biss bei der Zertifikatsausstellung nicht.
	Only after this proof do you flip the irreversible switch:	Erst nach diesem Beweis legst du den unumkehrbaren Schalter um:
	sudo gitops-write deployment.yaml 's/replicas: 0/replicas: 1/' sudo flux reconcile kustomization lernreise-garden --with-source kubectl -n lernreise-garden rollout status deployment/lernreise --timeout=300s	sudo gitops-write deployment.yaml 's/replicas: 0/replicas: 1/' sudo flux reconcile kustomization lernreise-garden --with-source kubectl -n lernreise-garden rollout status deployment/lernreise --timeout=300s
	…and then verify in the cluster, not in your head (Rule 2 from the overview):	…und dann verifiziere im Cluster, nicht in deinem Kopf (Regel 2 aus dem Überblick):
	curl -sI https://lernreise.grow.b0x.store \| head -1 # expect: 200 # the app's OWN gate — a websocket join WITHOUT a valid token must be rejected: curl -sk -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" \ -H "Sec-WebSocket-Version: 13" \ -H "Sec-WebSocket-Key: $(head -c16 /dev/urandom \| base64)" \ https://lernreise.grow.b0x.store/ws \| head -1 # expect: 403 # …and WITH a valid Ed25519 token → 101 Switching Protocols.	curl -sI https://lernreise.grow.b0x.store \| head -1 # erwarte: 200 # das EIGENE Tor der App — ein Websocket-Join OHNE gültiges Token muss abgewiesen werden: curl -sk -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" \ -H "Sec-WebSocket-Version: 13" \ -H "Sec-WebSocket-Key: $(head -c16 /dev/urandom \| base64)" \ https://lernreise.grow.b0x.store/ws \| head -1 # erwarte: 403 # …und MIT einem gültigen Ed25519-Token → 101 Switching Protocols.
	"Done" is the 200 + the issued cert served + the app's own auth gate passing — not a green `apply`.	»Fertig« ist der 200 + das ausgestellte Zertifikat ausgeliefert + das eigene Auth-Tor der App, das besteht — nicht ein grünes `apply`.
	8. The two residuals	8. Die zwei Restposten
	This is the heart of the lesson, and the cleanest thing in the whole deploy. Everything about the cluster's state is solved — structure live, cert issued, flux resumed. What remains are two keys to the outside world, and they are worth understanding precisely because they have nothing to do with Kubernetes.	Das ist das Herz der Lektion und das Sauberste im ganzen Deploy. Alles am Zustand des Clusters ist gelöst — Struktur live, Zertifikat ausgestellt, Flux wiederaufgenommen. Was bleibt, sind zwei Schlüssel zur Außenwelt, und sie sind gerade deshalb verständnis-würdig, weil sie nichts mit Kubernetes zu tun haben.
	R1 — the missing GitLab deploy-key (you wrote the letter, but lack the key to the postbox)	R1 — der fehlende GitLab-Deploy-Key (du hast den Brief geschrieben, dir fehlt aber der Schlüssel zum Briefkasten)
	The 13 GitOps commits are written, committed, and live on infinix — Flux reads the local repo, so the cluster already runs `14ce433`. The only thing that failed is mirroring those commits to the durable external remote `git@git.labs.ooo:infinity/k8s-gitops.git`:	Die 13 GitOps-Commits sind geschrieben, committet und live auf infinix — Flux liest das lokale Repo, also läuft der Cluster bereits `14ce433`. Das Einzige, was scheiterte, ist das Spiegeln dieser Commits zum dauerhaften externen Remote `git@git.labs.ooo:infinity/k8s-gitops.git`:
	git push origin main → Too many authentication failures diagnosis: root's ~/.ssh has 6 keys + NO Host config for git.labs.ooo, so the server trips MaxAuthTries before the right key — AND explicit per-key tests all returned: Permission denied (publickey) → root on infinix holds NO key authorized for this GitLab repo.	git push origin main → Too many authentication failures Diagnose: roots ~/.ssh hat 6 Schlüssel + KEINE Host-Konfig für git.labs.ooo, also stolpert der Server über MaxAuthTries vor dem richtigen Schlüssel — UND explizite Tests pro Schlüssel gaben alle zurück: Permission denied (publickey) → root auf infinix hält KEINEN für dieses GitLab-Repo autorisierten Schlüssel.
	We stopped and did not force. Why this is the easy residual to misjudge: it looks like a deploy failure, but it has zero cluster impact — Flux's source is the local repo, which already carries all 13 commits. It's a durability/mirroring gap. The letter is written and already in the local inbox; you simply can't drop a copy in the external postbox because you don't hold a key that postbox accepts.	Wir stoppten und erzwangen nicht. Warum das der leicht fehlzudeutende Restposten ist: es sieht aus wie ein Deploy-Fehler, hat aber null Cluster-Auswirkung — Flux' Quelle ist das lokale Repo, das bereits alle 13 Commits trägt. Es ist eine Haltbarkeits-/Spiegelungs-Lücke. Der Brief ist geschrieben und schon im lokalen Posteingang; du kannst nur keine Kopie in den externen Briefkasten werfen, weil du keinen Schlüssel hältst, den dieser Briefkasten akzeptiert.

Loading…

None

String updated in the repository

English

German 23 characters edited Current translation Translated

a month ago

None

String added in the repository

English

German 0 characters edited Empty

a month ago

Browse all string changes

Things to check

Unchanged translation

Source and translation are identical

Reset

Glossary

English	German
structure-live-first	structure-live-first	glossary
coined iDeploy term (tied to replicas: 0); keep English anchor

String information

Source string description

type: Title ##

Flags

no-wrap

Source string location

ideploy/DEEPDIVE.md:267

String age

a month ago

Last updated

a month ago

Source string age

a month ago

Translation file

po/de.po, string 520

	English	German	Actions
	A Kubernetes pod doesn't run your source — it runs a container image, a sealed tarball of your app + its dependencies. That image has to live somewhere the cluster can pull it from: a registry. Here it's Harbor, at `docker.registry.infinity.labs` (on the infinix VPN IP).	Ein Kubernetes-Pod führt nicht deinen Quellcode aus — er führt ein Container-Image aus, einen versiegelten Tarball deiner App + ihrer Abhängigkeiten. Dieses Image muss irgendwo liegen, wo der Cluster es ziehen kann: einer Registry. Hier ist es Harbor, unter `docker.registry.infinity.labs` (auf der infinix-VPN-IP).
	> Recon caught a real bug here: the manifests carried a wrong registry host > (`registry.infinix.labs.ooo`) that would have made every image ref > unresolvable. The read-only recon step fixed it to the real > `docker.registry.infinity.labs` before anything tried to pull. This is why > recon-first earns its keep.	> Recon fing hier einen echten Bug: die Manifeste trugen einen falschen > Registry-Host (`registry.infinix.labs.ooo`), der jede Image-Referenz unauflösbar > gemacht hätte. Der read-only-Recon-Schritt korrigierte ihn auf den echten > `docker.registry.infinity.labs`, bevor irgendetwas zu ziehen versuchte. Genau > darum verdient recon-first seinen Lohn.
	Two credentials touch the registry, and they're different directions:	Zwei Credentials berühren die Registry, und sie zeigen in verschiedene Richtungen:
	push (write): `docker login` + `docker push` — needs a robot account that can write to `lernreise/*`.	push (schreiben): `docker login` + `docker push` — braucht ein Robot-Konto, das nach `lernreise/*` schreiben darf.
	pull (read): the pod needs a `harbor-registry` pull-secret so the kubelet can fetch the image when it schedules.	pull (lesen): der Pod braucht ein `harbor-registry`-Pull-Secret, damit das kubelet das Image beim Einplanen holen kann.
	Both derive from one external robot credential that Harbor mints. Harbor is an outside system — you cannot conjure that credential locally; a human seeds it once (this is residual R2, §8). The image is pinned by digest (`@sha256:…`), never a mutable `:latest` tag, so the deployment can never silently drift to a different image.	Beide leiten sich aus einem externen Robot-Credential ab, das Harbor erzeugt. Harbor ist ein Außensystem — du kannst dieses Credential nicht lokal heraufbeschwören; ein Mensch sät es einmal (das ist Restposten R2, §8). Das Image wird per Digest gepinnt (`@sha256:…`), nie per mutierbarem `:latest`-Tag, sodass das Deployment nie stillschweigend zu einem anderen Image abdriften kann.
	6. iSecrets: the audited key-ring	6. iSecrets: der auditierte Schlüsselbund
	Secrets never live in git and never get typed by hand. They flow through iSecrets — the concept — whose real store is `pass.manager` (`~/my/ai/agents/infinity/pass.manager/`): GPG-encrypted `pass`, wrapped by an audited library `haiku/lib.sh` that logs every access to `data/audit.log`.	Secrets leben nie in git und werden nie von Hand getippt. Sie fließen durch iSecrets — das Konzept — dessen echter Store `pass.manager` ist (`~/my/ai/agents/infinity/pass.manager/`): GPG-verschlüsseltes `pass`, umhüllt von einer auditierten Bibliothek `haiku/lib.sh`, die jeden Zugriff nach `data/audit.log` protokolliert.
	source ~/my/ai/agents/infinity/pass.manager/haiku/lib.sh pass_get <path> [fallback] # retrieve — audited GET by EXACT path pass_set <path> [value] # store — audited SET (stdin if no value) pass_exists <path> # presence — fail-closed, leaks no value pass_generate <path> [len] # generate + store a strong secret	source ~/my/ai/agents/infinity/pass.manager/haiku/lib.sh pass_get <path> [fallback] # abrufen — auditierter GET per EXAKTEM Pfad pass_set <path> [value] # speichern — auditierter SET (stdin wenn kein value) pass_exists <path> # Präsenz — fail-closed, leakt keinen Wert pass_generate <path> [len] # ein starkes Secret erzeugen + speichern
	The rule is named retrieval, never vault scanning: you ask for the exact path, the access is audited, and that is the only sanctioned read. Sweeping the GPG store hunting for "a token that might work" is the anti-pattern this replaces.	Die Regel ist benannter Abruf, nie Vault-Scannen: du fragst nach dem exakten Pfad, der Zugriff wird auditiert, und das ist die einzige sanktionierte Lesung. Den GPG-Store nach »einem Token, das funktionieren könnte« zu durchforsten ist das Anti-Muster, das dies ersetzt.
	Two ways a secret becomes a live k8s `Secret`, both sourced from `pass` at apply-time (never committed, never in the image):	Zwei Wege, wie ein Secret zu einem Live-k8s-`Secret` wird, beide aus `pass` zur Apply-Zeit bezogen (nie committet, nie im Image):
	# (a) the registry pull-secret, born from iSecrets: kubectl create secret docker-registry harbor-registry \ --namespace lernreise-garden \ --docker-server=docker.registry.infinity.labs \ --docker-username="$(pass_get harbor/lernreise-garden/robot-user)" \ --docker-password="$(pass_get harbor/lernreise-garden/robot-password)" \ --dry-run=client -o yaml \| kubectl apply -f - # (b) a keypair, GENERATED ON INFINIX, split by trust: # private key → the MINTER namespace; public key → the VERIFIER namespace kubectl create secret generic lernreise-session-privkey --namespace grow-main \ --from-literal=session.key="$(pass_get keys/lernreise-session-ed25519)" \ --dry-run=client -o yaml \| kubectl apply -f - kubectl create secret generic lernreise-session-pubkey --namespace lernreise-garden \ --from-literal=session.pub="$(pass_get keys/lernreise-session-ed25519.pub)" \ --dry-run=client -o yaml \| kubectl apply -f -	# (a) das Registry-Pull-Secret, aus iSecrets geboren: kubectl create secret docker-registry harbor-registry \ --namespace lernreise-garden \ --docker-server=docker.registry.infinity.labs \ --docker-username="$(pass_get harbor/lernreise-garden/robot-user)" \ --docker-password="$(pass_get harbor/lernreise-garden/robot-password)" \ --dry-run=client -o yaml \| kubectl apply -f - # (b) ein Keypair, AUF INFINIX ERZEUGT, nach Vertrauen aufgeteilt: # privater Schlüssel → der MINTER-Namespace; öffentlicher Schlüssel → der VERIFIER-Namespace kubectl create secret generic lernreise-session-privkey --namespace grow-main \ --from-literal=session.key="$(pass_get keys/lernreise-session-ed25519)" \ --dry-run=client -o yaml \| kubectl apply -f - kubectl create secret generic lernreise-session-pubkey --namespace lernreise-garden \ --from-literal=session.pub="$(pass_get keys/lernreise-session-ed25519.pub)" \ --dry-run=client -o yaml \| kubectl apply -f -
	> Why generate the keypair on infinix, not sync it from pad? The production > private key should be born where it's used and never travel. pad's keypair > was a throwaway test key (minted this session to prove the crypto locally). > Syncing the prod private key pad→infinix would needlessly put it in three > places (pad fs + `pass` + infinix). So: generate fresh on infinix; the > private half stays on the node, in the minter's namespace, never in an image. > The public half goes to the verifier. (This split — minter holds private, > verifier holds public — is just asymmetric crypto: sign with private, check > with public.)	> Warum das Keypair auf infinix erzeugen, nicht von pad synchronisieren? Der > private Produktionsschlüssel sollte dort geboren werden, wo er genutzt wird, und > nie reisen. pads Keypair war ein Wegwerf-Testschlüssel (in dieser Sitzung erzeugt, > um die Krypto lokal zu beweisen). Den privaten Prod-Schlüssel pad→infinix zu > synchronisieren würde ihn unnötig an drei Orte legen (pad-fs + `pass` + infinix). > Also: frisch auf infinix erzeugen; die private Hälfte bleibt auf dem Knoten, im > Namespace des Minters, nie in einem Image. Die öffentliche Hälfte geht zum Verifier. > (Diese Aufteilung — Minter hält privat, Verifier hält öffentlich — ist einfach > asymmetrische Krypto: signieren mit privat, prüfen mit öffentlich.)
	The honest split for this deploy:	Die ehrliche Aufteilung für dieses Deploy:
	\| Item \| Source \| Status \| \|------\|--------\|--------\| \| Ed25519 keypair (private + public) \| auto-generated on infinix, mirrored into iSecrets \| ✅ already present \| \| Harbor robot credential (user + password) \| operator seeds ONCE (external system) \| ⛔ residual R2 \| \| `harbor-registry` pull-secret \| derived from iSecrets at apply-time \| waits on R2 \| \| `…-privkey` / `…-pubkey` Secrets \| derived from iSecrets \| ready \|	\| Posten \| Quelle \| Status \| \|------\|--------\|--------\| \| Ed25519-Keypair (privat + öffentlich) \| auto-erzeugt auf infinix, in iSecrets gespiegelt \| ✅ bereits vorhanden \| \| Harbor-Robot-Credential (user + password) \| Operator sät EINMAL (externes System) \| ⛔ Restposten R2 \| \| `harbor-registry`-Pull-Secret \| aus iSecrets zur Apply-Zeit abgeleitet \| wartet auf R2 \| \| `…-privkey` / `…-pubkey`-Secrets \| aus iSecrets abgeleitet \| bereit \|
	7. structure-live-first	7. structure-live-first
	Here is the real `replicas: 0` walk-through — the cheapest possible proof that the path works, run before any image exists.	Hier ist der echte `replicas: 0`-Durchgang — der billigstmögliche Beweis, dass der Pfad funktioniert, ausgeführt bevor irgendein Image existiert.
	After `gitops-write` staged the manifests (deployment pinned at `replicas: 0`, image ref a `REPLACE_WITH_DIGEST` placeholder) and the per-app CR was applied, Flux reconciled `main@sha1:14ce433` and brought up — with zero pods:	Nachdem `gitops-write` die Manifeste bereitgestellt hatte (Deployment auf `replicas: 0` gepinnt, Image-Referenz ein `REPLACE_WITH_DIGEST`-Platzhalter) und der Per-App-CR angewandt war, reconcilte Flux `main@sha1:14ce433` und brachte hoch — mit null Pods:
	namespace lernreise-garden created ResourceQuota lernreise-garden-quota enforced (rejects pods missing requests+limits) Service lernreise (80/8082) created Ingress lernreise.grow.b0x.store created Deployment lernreise 0/0 ← replicas:0, no image needed, can't crash Certificate lernreise-grow-tls True ← Let's Encrypt prod, ISSUED at 0/0 (!) PVC Pending (WaitForFirstConsumer — normal at 0 replicas)	namespace lernreise-garden created ResourceQuota lernreise-garden-quota enforced (weist Pods ohne requests+limits ab) Service lernreise (80/8082) created Ingress lernreise.grow.b0x.store created Deployment lernreise 0/0 ← replicas:0, kein Image nötig, kann nicht abstürzen Certificate lernreise-grow-tls True ← Let's Encrypt prod, AUSGESTELLT bei 0/0 (!) PVC Pending (WaitForFirstConsumer — normal bei 0 replicas)
	The headline: the TLS certificate issued while the app was dark. That single fact proves DNS resolves, the ingress routes correctly, and the ACME challenge completes end-to-end — all the things most likely to be wrong — with nothing running that could break. Legacy `lernreise` (264d) and `grow-main` (120d) were untouched; the node's ~99% CPU-request booking did not bite cert issuance.	Die Schlagzeile: das TLS-Zertifikat wurde ausgestellt, während die App dunkel war. Diese eine Tatsache beweist, dass DNS auflöst, der Ingress korrekt routet und die ACME-Challenge Ende-zu-Ende abschließt — all die Dinge, die am wahrscheinlichsten falsch sind — mit nichts Laufendem, das kaputtgehen könnte. Das alte `lernreise` (264d) und `grow-main` (120d) waren unangetastet; die ~99%-CPU-Request-Buchung des Knotens biss bei der Zertifikatsausstellung nicht.
	Only after this proof do you flip the irreversible switch:	Erst nach diesem Beweis legst du den unumkehrbaren Schalter um:
	sudo gitops-write deployment.yaml 's/replicas: 0/replicas: 1/' sudo flux reconcile kustomization lernreise-garden --with-source kubectl -n lernreise-garden rollout status deployment/lernreise --timeout=300s	sudo gitops-write deployment.yaml 's/replicas: 0/replicas: 1/' sudo flux reconcile kustomization lernreise-garden --with-source kubectl -n lernreise-garden rollout status deployment/lernreise --timeout=300s
	…and then verify in the cluster, not in your head (Rule 2 from the overview):	…und dann verifiziere im Cluster, nicht in deinem Kopf (Regel 2 aus dem Überblick):
	curl -sI https://lernreise.grow.b0x.store \| head -1 # expect: 200 # the app's OWN gate — a websocket join WITHOUT a valid token must be rejected: curl -sk -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" \ -H "Sec-WebSocket-Version: 13" \ -H "Sec-WebSocket-Key: $(head -c16 /dev/urandom \| base64)" \ https://lernreise.grow.b0x.store/ws \| head -1 # expect: 403 # …and WITH a valid Ed25519 token → 101 Switching Protocols.	curl -sI https://lernreise.grow.b0x.store \| head -1 # erwarte: 200 # das EIGENE Tor der App — ein Websocket-Join OHNE gültiges Token muss abgewiesen werden: curl -sk -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" \ -H "Sec-WebSocket-Version: 13" \ -H "Sec-WebSocket-Key: $(head -c16 /dev/urandom \| base64)" \ https://lernreise.grow.b0x.store/ws \| head -1 # erwarte: 403 # …und MIT einem gültigen Ed25519-Token → 101 Switching Protocols.
	"Done" is the 200 + the issued cert served + the app's own auth gate passing — not a green `apply`.	»Fertig« ist der 200 + das ausgestellte Zertifikat ausgeliefert + das eigene Auth-Tor der App, das besteht — nicht ein grünes `apply`.
	8. The two residuals	8. Die zwei Restposten
	This is the heart of the lesson, and the cleanest thing in the whole deploy. Everything about the cluster's state is solved — structure live, cert issued, flux resumed. What remains are two keys to the outside world, and they are worth understanding precisely because they have nothing to do with Kubernetes.	Das ist das Herz der Lektion und das Sauberste im ganzen Deploy. Alles am Zustand des Clusters ist gelöst — Struktur live, Zertifikat ausgestellt, Flux wiederaufgenommen. Was bleibt, sind zwei Schlüssel zur Außenwelt, und sie sind gerade deshalb verständnis-würdig, weil sie nichts mit Kubernetes zu tun haben.
	R1 — the missing GitLab deploy-key (you wrote the letter, but lack the key to the postbox)	R1 — der fehlende GitLab-Deploy-Key (du hast den Brief geschrieben, dir fehlt aber der Schlüssel zum Briefkasten)
	The 13 GitOps commits are written, committed, and live on infinix — Flux reads the local repo, so the cluster already runs `14ce433`. The only thing that failed is mirroring those commits to the durable external remote `git@git.labs.ooo:infinity/k8s-gitops.git`:	Die 13 GitOps-Commits sind geschrieben, committet und live auf infinix — Flux liest das lokale Repo, also läuft der Cluster bereits `14ce433`. Das Einzige, was scheiterte, ist das Spiegeln dieser Commits zum dauerhaften externen Remote `git@git.labs.ooo:infinity/k8s-gitops.git`:
	git push origin main → Too many authentication failures diagnosis: root's ~/.ssh has 6 keys + NO Host config for git.labs.ooo, so the server trips MaxAuthTries before the right key — AND explicit per-key tests all returned: Permission denied (publickey) → root on infinix holds NO key authorized for this GitLab repo.	git push origin main → Too many authentication failures Diagnose: roots ~/.ssh hat 6 Schlüssel + KEINE Host-Konfig für git.labs.ooo, also stolpert der Server über MaxAuthTries vor dem richtigen Schlüssel — UND explizite Tests pro Schlüssel gaben alle zurück: Permission denied (publickey) → root auf infinix hält KEINEN für dieses GitLab-Repo autorisierten Schlüssel.
	We stopped and did not force. Why this is the easy residual to misjudge: it looks like a deploy failure, but it has zero cluster impact — Flux's source is the local repo, which already carries all 13 commits. It's a durability/mirroring gap. The letter is written and already in the local inbox; you simply can't drop a copy in the external postbox because you don't hold a key that postbox accepts.	Wir stoppten und erzwangen nicht. Warum das der leicht fehlzudeutende Restposten ist: es sieht aus wie ein Deploy-Fehler, hat aber null Cluster-Auswirkung — Flux' Quelle ist das lokale Repo, das bereits alle 13 Commits trägt. Es ist eine Haltbarkeits-/Spiegelungs-Lücke. Der Brief ist geschrieben und schon im lokalen Posteingang; du kannst nur keine Kopie in den externen Briefkasten werfen, weil du keinen Schlüssel hältst, den dieser Briefkasten akzeptiert.