[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-96128":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":9,"totalLinesOfCode":9,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":9,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":16,"stars30d":17,"stars90d":16,"forks30d":16,"starsTrendScore":16,"compositeScore":18,"rankGlobal":9,"rankLanguage":9,"license":9,"archived":19,"fork":19,"defaultBranch":20,"hasWiki":19,"hasPages":19,"topics":9,"createdAt":9,"pushedAt":9,"updatedAt":21,"readmeContent":22,"aiSummary":23,"trendingCount":16,"starSnapshotCount":16,"syncStatus":24,"lastSyncTime":25,"discoverSource":26},96128,"krops","polarsquad\u002Fkrops","polarsquad","Kubernetes-Native Resource Operations",null,"https:\u002F\u002Fgithub.com\u002Fpolarsquad\u002Fkrops","Rust",136,14,3,33,0,8,41.33,false,"main","2026-09-20 04:01:32","# krops\n## kubernetes resource operations\n\n![krops logo](docs\u002Fkrops-logo.svg)\n\nkrops is a GitOps pattern for managing infrastructure through the Kubernetes API\nwith plain declarative YAML. Terraform and OpenTofu use HCL, a state file, and\ndiscrete plan\u002Fapply runs; krops stores desired state as Kubernetes resources in\nGit. [Flux](https:\u002F\u002Ffluxcd.io\u002F) delivers those resources, and controllers\ncontinuously reconcile the infrastructure to match them. Kubernetes provides\none API, RBAC model, policy surface, and audit trail for infrastructure and\nworkloads. No HCL, no `.tfstate`, no second toolchain.\n\n[Crossplane](https:\u002F\u002Fwww.crossplane.io\u002F) is the closer comparison because it\nalso runs infrastructure reconciliation inside Kubernetes. Its providers expose\nmanaged resources, while XRDs and compositions can turn them into higher-level\nplatform APIs. krops introduces no krops-specific CRD or controller: it combines\n[Cluster API](https:\u002F\u002Fcluster-api.sigs.k8s.io\u002F) for clusters,\n[ACK](https:\u002F\u002Faws-controllers-k8s.github.io\u002Fdocs\u002F) for AWS resources, and Flux\nfor GitOps. If those resource APIs already say what you mean, krops does not\nwrap them to say it again.\n\nThis repository demonstrates the pattern end to end on AWS EKS, local Docker\nclusters, and a Tinkerbell-provisioned [Talos Linux](https:\u002F\u002Fwww.talos.dev\u002F)\nmachine. A disposable [kind](https:\u002F\u002Fkind.sigs.k8s.io\u002F) cluster bootstraps Flux,\nCAPI pivots control to a self-managed management cluster, and the Rust\n[`krops-bootstrap`](docs\u002Fbootstrap-cli.md) CLI handles bootstrap, pivot, and\nteardown. After that, everything is declared in Git, with a\n[Zarf](https:\u002F\u002Fzarf.dev\u002F) bundle for air-gapped local installs. It is a working\nreference implementation, not a product, so fork it, strip it down, and adapt\nit to your own cloud and clusters.\n\n## Who this is for\n\nPlatform engineers who already run Kubernetes and want to manage their own\ncloud infrastructure with the same API, RBAC, audit trail, and GitOps workflow\nthey use for workloads. If you're reaching for Terraform\u002FOpenTofu, Pulumi, or\nCrossplane to stand up cloud resources for Kubernetes, this pattern is the\nalternative: the cluster you already operate becomes the control plane. It is\nnot a developer self-service portal; you are the consumer.\n\n## Problems the pattern solves\n\n- **State files**: drift, locking, corruption. Controllers reconcile actual\n  state continuously instead of diffing a snapshot.\n- **The plan\u002Fapply gap**: PRs are reviewed as **rendered** Flux diffs (blast\n  radius, image changes, render failures) by\n  [konflate](https:\u002F\u002Fgithub.com\u002Fhome-operations\u002Fkonflate): a GitHub Actions\n  workflow runs it on every PR push as a merge gate, and an in-cluster\n  instance posts the summary to the PR. You review byte-for-byte what\n  reconciles. See [docs\u002Fkonflate.md](docs\u002Fkonflate.md).\n- **Two toolchains**: HCL for infra, YAML for workloads. One control plane\n  means RBAC, policy, and audit cover both.\n- **Lifecycle split**: Terraform builds the cluster but can't manage what's\n  in it. CAPI + Flux is one dependency graph from cluster to workload.\n- **A control plane on a laptop**: the management cluster is not a long-lived\n  local kind cluster. The bootstrap kind cluster is disposable, and after the\n  pivot the management cluster manages itself through the same GitOps flow it\n  drives.\n\n![krops aws architecture](docs\u002Faws-infra.svg)\n\n![krops local-host architecture](docs\u002Flocal-host-infra.svg)\n\n![krops air-gap architecture](docs\u002Fair-gap-infra.svg)\n\n## Prerequisites\n\nThe toolbox container is the primary lifecycle interface. A container user\nneeds only the repository checkout and a running engine:\n\n- Docker, or Podman 5.5+; kind creates clusters through the mounted engine\n  socket\n- The toolbox image. No semver release has been published yet, so build the\n  current checkout with\n  `docker build -f bootstrap-rs\u002FDockerfile -t krops-toolbox:dev .`\n\nA future matching `v*` tag publishes\n`ghcr.io\u002Fpolarsquad\u002Fkrops-toolbox` for Linux amd64 and arm64 as `X.Y.Z`,\n`X.Y`, and stable `latest`, with a keyless signature and SPDX SBOM\nattestation. The `aws` environment additionally requires a GitHub PAT with\nread access, AWS credentials and service quotas, and an age private key. The\n`local-talos` environment needs the PAT and age key too (it syncs from\nGitHub), plus a reachable Tinkerbell stack and the site values in\n`mgmt\u002Flocal-talos\u002Fclusters\u002Fmanagement\u002Fcluster.yaml`; see\n[Operations](docs\u002Foperations.md).\n\nNative development and air-gap work additionally need:\n\n- Mise 2026.8.10 or newer\n- Rust via [rustup](https:\u002F\u002Frustup.rs\u002F) when building the CLI outside the\n  image; the pin lives in `bootstrap-rs\u002Frust-toolchain.toml`\n\n## Quickstart\n\nBuild the current checkout and run the complete local-host lifecycle with only\nDocker installed:\n\n```sh\ndocker build -f bootstrap-rs\u002FDockerfile -t krops-toolbox:dev .\nmkdir -p .kube\ndocker run --rm -it \\\n  -v \"$PWD:\u002Fworkspace\" -w \u002Fworkspace \\\n  -v \u002Fvar\u002Frun\u002Fdocker.sock:\u002Fvar\u002Frun\u002Fdocker.sock \\\n  -v \"$PWD\u002F.kube:\u002Froot\u002F.kube\" \\\n  -e KUBECONFIG=\u002Fworkspace\u002F.kube\u002Fkind.yaml \\\n  krops-toolbox:dev local-host\n\n# Teardown uses the same mounts and the teardown subcommand:\ndocker run --rm -it \\\n  -v \"$PWD:\u002Fworkspace\" -w \u002Fworkspace \\\n  -v \u002Fvar\u002Frun\u002Fdocker.sock:\u002Fvar\u002Frun\u002Fdocker.sock \\\n  -v \"$PWD\u002F.kube:\u002Froot\u002F.kube\" \\\n  -e KUBECONFIG=\u002Fworkspace\u002F.kube\u002Fkind.yaml \\\n  krops-toolbox:dev teardown local-host\n```\n\nUse `ghcr.io\u002Fpolarsquad\u002Fkrops-toolbox:\u003Cversion>` instead of the local image\nfor a published release. The AWS form must also pass the Git source, PAT, age\nkey path, and any AWS credential variables. Podman socket paths vary by host.\n`scripts\u002Ftoolbox-run.sh` handles those mounts, loads `.env` without preserving\nquote characters, and persists kubeconfigs under `.kube\u002F`; see\n[Operations](docs\u002Foperations.md) for both forms.\n\nFor hosts with mise, the lifecycle tasks call that wrapper. Installing the\npinned native tools also enables key generation, validation, and inspection:\n\n```sh\ndocker build -f bootstrap-rs\u002FDockerfile -t krops-toolbox:dev .\nexport TOOLBOX_IMAGE=krops-toolbox:dev\nmise trust\nmise install\ncp .env.example .env        # aws and local-talos: fill in the Git source and PAT\nmise run sops-keygen         # first time only: age key for SOPS\nmise run bootstrap           # toolbox: bootstrap, Flux handoff, then pivot\nexport KUBECONFIG=\"$PWD\u002F.kube\u002Fkrops-mgmt.yaml\"\nflux get kustomizations --watch\nmise run validate            # shell syntax, bootstrap.toml cross-check, overlays\nmise run teardown            # toolbox: reverse-order lifecycle cleanup\n```\n\nDependency versions are managed by Renovate\n([renovate.json5](renovate.json5)) running as the hosted GitHub App; they live\nin their native consumer files and update PRs open weekly. See\n[Dependencies](docs\u002Fdependencies.md).\n\n### Environments\n\nThe shared toolchain is defined in `mise.toml`. AWS-specific tools are layered\nthrough `mise.aws.toml`; use the `aws` environment when those tools are\nneeded. The `local-host` environment creates the management kind cluster, a\nlocal OCI registry, and the Flux Operator and FluxInstance. It publishes the\n`mgmt\u002Flocal-host\u002F` and `workload\u002Flocal-host\u002F` folders as the `krops:latest`\nOCI artifact. Flux installs CAPI with its Docker infrastructure provider (CAPD),\nprovisions a local one-control-plane\u002Fone-worker workload cluster, and installs\na separate Flux instance there. That workload Flux instance reconciles Podinfo,\nproviding an end-to-end local path from management-cluster bootstrap through\nworkload delivery and application access. This covers the complete GitOps and\nCAPI lifecycle without provisioning AWS resources:\n\n```sh\ndocker build -f bootstrap-rs\u002FDockerfile -t krops-toolbox:dev .\nexport TOOLBOX_IMAGE=krops-toolbox:dev\nmise -E local-host install\nmise -E local-host run bootstrap\nexport KUBECONFIG=\"$PWD\u002F.kube\u002Fkrops-mgmt.yaml\"\nmise -E local-host run oci-push  # republish local management and workload paths\nmise -E local-host run kubeconfigs\nmise -E local-host run podinfo-port-forward  # http:\u002F\u002Flocalhost:9898\nmise -E local-host run teardown\n```\n\nThe Flux charts are pulled anonymously. The AWS environment requires a\nGitHub PAT so Flux can clone this repository; the local-host environment does\nnot require GitHub or AWS credentials.\n\n`mise -E local-host run bootstrap` waits for both the management and workload\nFlux reconciliation chains and surfaces workload reconciliation errors. A\nsuccessful bootstrap, followed by the Podinfo port-forward, verifies the\nend-to-end local-host flow.\n\nLocal-host teardown deletes the CAPD workload cluster first, then removes the\npre-pivot kind cluster or the post-pivot self-managed management containers,\nand removes the local registry last. AWS teardown discovers the active\ncontroller host, deletes the workload clusters, sweeps orphaned resources in\nboth workload regions plus the self-managed management cluster, and removes\nthe `clusterawsadm` CloudFormation stack.\n\nThe `local-talos` environment targets a physical machine through Tinkerbell:\na PXE install of Talos Linux, then the same bootstrap, pivot, and\nself-management flow, synced from GitHub. It needs the GitHub PAT and age\nkey, a reachable Tinkerbell stack with a `Hardware` resource for the\nmachine, and the site values in\n`mgmt\u002Flocal-talos\u002Fclusters\u002Fmanagement\u002Fcluster.yaml`:\n\n```sh\nmise -E local-talos install  # adds talosctl\nmise -E local-talos run bootstrap\nexport KUBECONFIG=\"$PWD\u002F.kube\u002Fkrops-mgmt.yaml\"\nmise -E local-talos run kubeconfigs\nmise -E local-talos run teardown  # releases the Hardware; never wipes the machine\n```\n\nThe `azure` environment builds an AKS management cluster with CAPZ and\nmanages Azure resources with Azure Service Operator on the workload\nclusters; see [docs\u002Fazure.md](docs\u002Fazure.md):\n\n```sh\nmise -E azure install            # adds az\nmise -E azure run azure-bootstrap\nmise -E azure run bootstrap\n```\n\n## The bootstrap CLI\n\nThe single `krops-bootstrap` binary implements bootstrap, the default pivot, and\n`krops-bootstrap teardown`. Repository-owned cluster names, paths, chart\nversions, provider manifests, and teardown targets come from\n[`bootstrap.toml`](bootstrap.toml); `mise run validate` cross-checks that file\nagainst the Git manifests. Sequence-level behavior and generic fallback\ndefaults remain in the binary.\n\n`mise run bootstrap`, `pivot`, and `teardown` now run the CLI through the\ntoolbox wrapper. The shell scripts remain native reference and fallback paths\nuntil all environments complete parity runs; local-host has passed the full\nlifecycle, while AWS parity still gates retirement. See\n[The bootstrap CLI](docs\u002Fbootstrap-cli.md) for the interface, configuration,\nteardown controls, toolbox release, and current parity status.\n\n## Documentation\n\n| Page | Contents |\n|---|---|\n| [docs\u002Fbootstrap-cli.md](docs\u002Fbootstrap-cli.md) | The `krops-bootstrap` lifecycle CLI: toolbox distribution, interface, `bootstrap.toml`, pivot, teardown, parity status |\n| [docs\u002Fdependencies.md](docs\u002Fdependencies.md) | Renovate-managed dependency updates: covered surfaces, update procedure, intentional differences |\n| [docs\u002Farchitecture.md](docs\u002Farchitecture.md) | Architecture diagram, reconciliation order, how workload apps are delivered |\n| [docs\u002Faws-iam.md](docs\u002Faws-iam.md) | EKS Pod Identity, ACK controller IAM roles, per-cluster reader roles, the `krops-reader` console user |\n| [docs\u002Fworkload-resources.md](docs\u002Fworkload-resources.md) | S3 bucket security posture, RDS instances, known limitations |\n| [docs\u002Fkonflate.md](docs\u002Fkonflate.md) | Rendered Flux PR review: GitHub Actions gate, in-cluster instance, write-back to PRs, tokens |\n| [docs\u002Fsecrets.md](docs\u002Fsecrets.md) | SOPS + age secret management, key setup, credential rotation |\n| [docs\u002Foperations.md](docs\u002Foperations.md) | Toolbox runtime, prerequisites, quotas, bootstrap, pivot recovery, teardown, validation |\n| [docs\u002Fextending.md](docs\u002Fextending.md) | Adding a workload cluster, adding apps to the workload clusters, adding other providers (Azure, Talos, k0smotron) |\n| [docs\u002Fazure.md](docs\u002Fazure.md) | Azure environment: subscription prep, credentials, AKS clusters, ASO on workload clusters, upgrades |\n| [docs\u002Fairgap.md](docs\u002Fairgap.md) | Zarf air-gap bundle: package build, offline deploy, verification checklist, update drill |\n\n## Repository layout\n\n```\n├── .github\u002Fworkflows\u002F             Validation, Rust\u002Ftoolbox CI, docs CI and\n│                                  Pages deploy, signed releases\n├── airgap\u002F                        Zarf air-gap bundle, image inventory, scripts\n├── bootstrap-rs\u002F                  Lifecycle CLI, toolbox Dockerfile, Rust tests\n├── bootstrap.toml                 Repository-owned lifecycle configuration\n├── bootstrap.sh \u002F pivot.sh \u002F      Native shell references and fallback paths;\n│   teardown.sh                    retained until both parity gates pass\n├── scripts\u002Ftoolbox-run.sh         Docker\u002FPodman wrapper used by lifecycle tasks\n├── tests\u002F                         Config and Renovate coverage cross-checks\n├── mkdocs.yml                     MkDocs Material config for the docs site\n├── pyproject.toml \u002F uv.lock       Python project for the docs site build\n├── tools\u002Fassemble_docs.py         Assembles build\u002Fdocs\u002F from README.md + docs\u002F\n├── website\u002F                       Docs site assets: colour scheme CSS, CNAME\n├── docs\u002F                          Detailed documentation (see table above)\n├── mise.toml \u002F mise.*.toml        Pinned toolchain and per-environment\n│                                  task layers (aws, azure, local-host, local-talos)\n├── renovate.json5                 Hosted Renovate discovery and grouping rules\n├── mgmt\u002Faws\u002F                      Synced by the MANAGEMENT cluster's Flux\n│   ├── infrastructure\u002F           cert-manager, CAPI operator, CAPA identity,\n│   │                              ACK controllers, pod-identity roles,\n│   │                              account-global IAM (reader console user),\n│   │                              konflate (rendered Flux PR review)\n│   ├── capi-providers\u002F           capi-system, capa-system (SOPS creds),\n│   │                              caaph-system\n│   ├── addons\u002Fflux-apps\u002F         Installs Flux on each workload cluster\n│   │                              (HelmChartProxy + ClusterResourceSets)\n│   └── clusters\u002F                 EKS cluster defs: eu-north-1, eu-west-1\n│                                  (ARM + GPU MachinePools); eu-north-1 also\n│                                  carries the self-managed management cluster\n├── mgmt\u002Flocal-host\u002F              OCI-synced CAPI\u002FCAPD local workload cluster\n│   │                              and its management cluster definition\n│   ├── infrastructure\u002F           capi-operator, cert-manager\n│   ├── capi-providers\u002F           caaph-system, capd-system, capi-system\n│   ├── addons\u002F                   kindnet CNI, flux-apps\n│   └── clusters\u002F                 docker (workload), management (self-managed)\n├── mgmt\u002Flocal-talos\u002F             Single-node Talos management cluster on\n│   │                              bare metal via Tinkerbell (CAPT);\n│   │                              GitHub-synced like mgmt\u002Faws\n│   ├── infrastructure\u002F           capi-operator, cert-manager\n│   ├── capi-providers\u002F           cabpt-system, cacppt-system, capi-system,\n│   │                              capt-system (Tinkerbell)\n│   └── clusters\u002F                 management (self-managed)\n├── mgmt\u002Fazure\u002F                    AKS management cluster (CAPZ + ASO)\n└── workload\u002F                     Synced by each WORKLOAD cluster's Flux\n    ├── base\u002F                     ACK S3\u002FRDS\u002FIAM controllers, Bucket CRs,\n    │                              DBInstance CRs, reader Role CRs\n    ├── azure-base\u002F               cert-manager, ASO, and the Azure workload\n    │                              resources (VNet, storage, PostgreSQL)\n    ├── local-host\u002F               OCI-synced Podinfo workload overlay\n    ├── eu-north-01\u002F              Per-cluster overlay (sync target)\n    └── eu-west-01\u002F               Per-cluster overlay (sync target)\n```\n\n## License\n\nThis repository is licensed under the [Apache License 2.0](LICENSE).\n","krops 是一个面向 Kubernetes 原生基础设施管理的 GitOps 实践参考实现，通过纯声明式 YAML 将云资源（如 EKS 集群、AWS 服务）建模为 Kubernetes 原生资源，由 Flux 实现 GitOps 同步，并依托 Cluster API、ACK 等成熟控制器完成持续调和。它不引入新 CRD 或专用控制器，复用现有 Kubernetes 生态（RBAC、审计、策略），消除 Terraform 类工具的状态文件与 plan\u002Fapply 分离问题。适用于已运行 Kubernetes 的平台工程团队，统一管理底层云设施与上层工作负载，尤其适合 AWS 环境下的自管理集群建设与多环境 GitOps 落地。",2,"2026-09-10 02:30:09","trending"]