k8s.io: the infrastructure repository behind the Kubernetes project's own sites

Infrastructure for the project's own web properties

The repository is described as code and configuration to manage Kubernetes project infrastructure, including the various k8s.io sites, and it is managed by the Kubernetes community through the sig-k8s-infra special interest group. The first thing to get clear is what it is not. It is not the Kubernetes source code, it is not the cluster API, and it is not a tutorial for running containers. What it holds is the machinery that keeps the project's own web presence running, which turns out to be a useful thing to read precisely because it is ordinary infrastructure work rather than product code. The homepage points at the sig-k8s-infra community page for more information, and the top level of the tree shows the shape immediately: an apps directory, artifacts, audit, dns, groups, hack, images, infra, kubernetes, policy, a registry.k8s.io directory, and the usual project files including an OWNERS file, an OWNERS_ALIASES file and a SECURITY_CONTACTS file. The primary language of the repository is recorded as HCL, which tells you the Terraform side is the largest body of code.

The apps directory, and who owns each deployment

The apps directory holds the community-managed applications that run on the community-managed aaa cluster, and the readme lists each one with its owner, which is the detail that makes the repository legible. The codesearch instance at cs.k8s.io is owned by sig-k8s-infra. The elekto instance, the election tooling, is owned by the Elections officers on behalf of sig-contributor-experience. The gcsweb instance is owned by sig-testing. The k8s.io entry is an nginx that provides redirects and reverse proxying for k8s.io and its subdomains, and it is owned by sig-contributor-experience and sig-testing together. The kubernetes-external-secrets instance is owned by sig-testing, the perfdash instance is owned by sig-scalability, publishing-bot is owned by sig-release, slack-infra, which includes slack.k8s.io, is owned by sig-contributor-experience, and triageparty-cli is owned by sig-cli. Nine services, six owners, and a shared nginx in the middle. Anyone who wants to change one of these needs to know which group reviews the change, and that mapping is in the readme rather than in a wiki.

The GCP side: namespaces, Prow projects, IAM roles and Terraform

The infra/gcp directory is where the Google Cloud side lives, and it is split into scripts and Terraform. Under bash/namespaces there are scripts and data to manage Kubernetes namespaces and RBAC for the aaa cluster. Under bash/prow there are scripts and data used to manage the projects used for end-to-end testing, and those are managed by boskos. Under bash/roles are the scripts and data that manage custom GCP IAM roles, which is the piece that decides who can do what inside the project. The Terraform side has two parts: terraform/modules holds modules intended for reuse within this repository, and terraform/projects holds the Terraform that manages parts of the GCP projects. The separation is the one to copy if you take anything from here, because the modules are the part that is meant to be general and the projects are the part that is necessarily specific. The repository also carries an audit directory with scripts to export all relevant GCP resources and the most recently reviewed export, which is how the project keeps a record of what it actually has.

Policy as code, checked with conftest and OPA

The policy directory contains Open Policy Agent policies that are used by conftest to validate resources in this repository. That is the mechanism worth understanding. Rather than reviewing Terraform and configuration by eye in a pull request, the rules are written as policies and enforced mechanically, which is the same approach a platform team applies to the resources it manages on behalf of others. The tooling it relies on is deliberately small, and the requirements file at the root pins just two Python packages, yamllint at 1.18.0 and yq at 2.12.0, which is a signal about the scope of the validation, since the YAML linting and the yq based manipulation cover the configuration files while conftest covers the policy side. A repository that validates its own infrastructure with a policy engine is a better reference for a platform team than any tutorial, because the rules are in the tree and you can read what the project considers acceptable.

Registry.k8s.io and the cross-cloud mirroring problem

The registry.k8s.io directory is described as work in progress to support cross-cloud mirroring and hosting of containers and binaries. It is the least finished part of the repository and also the part with the largest consequences, because the container registry is where the ecosystem actually depends on the project. The stated goal is that the images and binaries the Kubernetes project publishes can be mirrored and hosted across clouds, which removes a single vendor from the path between a user and a released image. The images directory already publishes container images to gcr.io/k8s-staging-infra-tools, and the artifacts directory publishes non-image artifacts to artifacts.k8s.io, so the project already has two separate distribution surfaces for the two kinds of payload. The wording in the readme is careful, work in progress, and that is the honest status to plan around if you are depending on the mirroring behaviour rather than just reading about it.

The supporting directories: DNS, artifacts, images, groups and hack

The rest of the tree is the connective tissue of running a project at this scale, and the readme describes each one in a line. The dns directory holds the DNS for kubernetes.io and k8s.io, which for a project with this many subdomains is a piece of infrastructure in its own right. The artifacts directory holds non-image artifacts published to artifacts.k8s.io, and the images directory holds the container images published to the staging registry. The groups directory holds the Google groups on the kubernetes.io domain, which is how the mailing lists that the whole governance model runs on are administered. The hack directory holds the scripts used for development, testing and everything else that does not fit elsewhere, the traditional home for a project's helper scripts. The audit directory, mentioned above, exports the relevant GCP resources and keeps the most recently reviewed export, and that pair, a script and a snapshot of the result, is a pattern that more infrastructure repositories would benefit from copying.

Ownership, security contacts and the billing report

A few files in the root say more about how the project works than the applications do. OWNERS and OWNERS_ALIASES record who reviews what, and the aliases are the mechanism that lets a group rotate its reviewers without editing every file. SECURITY.md and SECURITY_CONTACTS handle vulnerability reporting, which for a project whose repositories are pulled into almost every cluster is a substantial responsibility. There is a code of conduct, a contributing guide, and an.atlantis.yaml configuration file. The readme also mentions a publicly viewable billing report for members of the sig-k8s-infra mailing list, so the cost side of the infrastructure is visible to the people who are accountable for it. The licence is Apache-2.0, the repository publishes no GitHub releases, and the last push was on 2026-10-19.

Editorial conclusion

The k8s.io repository is worth reading if you work on Kubernetes infrastructure or want to see how a large project runs its own services, its IAM roles and its policy checks in the open, because the Terraform modules and the conftest policies are a rare example of that work being visible. It is not a reference for using Kubernetes and it is not a template you can copy wholesale, because the names, the projects and the groups are specific to this project. Before you draw any conclusion from it, check the ownership files to see which special interest group owns the part you are reading, and note that the repository publishes no GitHub releases and that the registry.k8s.io work is explicitly still in progress.

Frequently asked questions

Official sources

1. Issues
2. kubernetes/k8s.io on GitHub
3. License: Apache-2.0
4. Project website
5. README