Private Docker Registry
The docker-registry charm deploys a local image registry for your cluster, taking care of the storage and distribution of container images. There are a few reasons why this may be a useful option for your cluster:
- Providing the images required by Charmed Kubernetes without requiring access to a public registry (e.g. in environments where network access is controlled, expensive or otherwise problematic).
- Providing images required by workloads running on the cluster.
When deployed and related to the cluster as described below, this registry will be checked first for any image requests, so it can be used in addition to public registries. For more details of the mechanics of the Docker Registry, see the upstream documentation at https://docs.docker.com/registry.
Deploying
The registry is deployed as a stand-alone application. Many deployment scenarios are described in the charm readme. The most common scenario for Kubernetes integration is to configure a registry with TLS and basic (htpasswd) authentication enabled.
If needed, consult the quickstart guide to install
Charmed Kubernetes. Then deploy and configure docker-registry
as
follows.
Custom Certificates
Relating docker-registry
to easyrsa
above will generate new TLS data
to support secure communication with the registry. Alternatively, custom
TLS data may be provided as base64-encoded config options to the charm:
Proxied Registry
Advanced networking or highly available deployment scenarios may require
multiple docker-registry
units to be deployed behind a proxy. In this case,
the network information of the proxy will be shared with the container runtime
units when the registry is related.
The environment described in the Deploy
section above can be adjusted to
create a highly available registry as follows:
Verify
Make note of the registry address. By default, this address is only accessible within the deployment model. See the charm readme for host and proxy configuration options if desired.
Verify basic authentication is working:
Connecting to a Charmed Kubernetes cluster
Relate the deployed registry to the appropriate container runtime for your cluster. This configures the runtime with authentication, proxy, and/or TLS data from the registry, and allows your registry to be used by the cluster to pull images for pods.
Containerd
Docker
Kubernetes images
A list of images that may be used by Charmed Kubernetes can be found in the container-images.txt document. This is a comprehensive list sorted by release; not all images are required for all deployments. Take note of the images required by your deployment that will need to be hosted in your private registry. A list of images required by a specific release is also included on the ‘components’ page in the documentation, for example, the list for the 1.24 release is located on the 1.24 components page
Hosting images
To make an image available in the deployed registry, it must be tagged and
pushed. As an example, push the defaultbackend-amd64
image to
docker-registry
:
The above procedure should be repeated for all required images.
Using the registry for cluster components
The image registry used by Charmed Kubernetes for images used in managing
or supporting components of the cluster itself is controlled by a kubernetes-control-plane
config option. Configure kubernetes-control-plane
to use your private registry as follows:
See the guide to contributing or discuss these docs in our public Mattermost channel.