Private Registry Configuration

Containerd can be configured to connect to private registries and use them to pull private images on the node.

Upon startup, K3s will check to see if a registries.yaml file exists at /etc/rancher/k3s/ and instruct containerd to use any registries defined in the file. If you wish to use a private registry, then you will need to create this file as root on each node that will be using the registry.

Note that server nodes are schedulable by default. If you have not tainted the server nodes and will be running workloads on them, please ensure you also create the registries.yaml file on each server as well.

Configuration in containerd can be used to connect to a private registry with a TLS connection and with registries that enable authentication as well. The following section will explain the registries.yaml file and give different examples of using private registry configuration in K3s.

Registries Configuration File

The file consists of two main sections:

  • mirrors
  • configs

Mirrors

Mirrors is a directive that defines the names and endpoints of the private registries, for example:

  1. mirrors:
  2. mycustomreg.com:
  3. endpoint:
  4. - "https://mycustomreg.com:5000"

Each mirror must have a name and set of endpoints. When pulling an image from a registry, containerd will try these endpoint URLs one by one, and use the first working one.

Redirects

If a public registry is used as a mirror, such as when configuring a pull through cache, images pulls are transparently redirected.

For example, if you have a mirror configured for docker.io:

  1. mirrors:
  2. docker.io:
  3. endpoint:
  4. - "https://mycustomreg.com:5000"

Then pulling docker.io/rancher/coredns-coredns:1.6.3 will transparently pull the image from https://mycustomreg.com:5000/rancher/coredns-coredns:1.6.3.

Rewrites

Each mirror can have a set of rewrites. Rewrites can change the tag of an image based on a regular expression. This is useful if the organization/project structure in the mirror registry is different to the upstream one.

For example, the following configuration would transparently pull the image docker.io/rancher/coredns-coredns:1.6.3 from registry.example.com:5000/mirrorproject/rancher-images/coredns-coredns:1.6.3:

  1. mirrors:
  2. docker.io:
  3. endpoint:
  4. - "https://registry.example.com:5000"
  5. rewrite:
  6. "^rancher/(.*)": "mirrorproject/rancher-images/$1"

The image will still be stored under the original name so that a crictl image ls will show docker.io/rancher/coredns-coredns:1.6.3 as available on the node, even though the image was pulled from the mirrored registry with a different name.

Configs

The configs section defines the TLS and credential configuration for each mirror. For each mirror you can define auth and/or tls.

The tls part consists of:

DirectiveDescription
cert_fileThe client certificate path that will be used to authenticate with the registry
key_fileThe client key path that will be used to authenticate with the registry
ca_fileDefines the CA certificate path to be used to verify the registry’s server cert file
insecure_skip_verifyBoolean that defines if TLS verification should be skipped for the registry

The auth part consists of either username/password or authentication token:

DirectiveDescription
usernameuser name of the private registry basic auth
passworduser password of the private registry basic auth
authauthentication token of the private registry basic auth

Below are basic examples of using private registries in different modes:

With TLS

Below are examples showing how you may configure /etc/rancher/k3s/registries.yaml on each node when using TLS.

  • With Authentication
  • Without Authentication
  1. mirrors:
  2. docker.io:
  3. endpoint:
  4. - "https://mycustomreg.com:5000"
  5. configs:
  6. "mycustomreg:5000":
  7. auth:
  8. username: xxxxxx # this is the registry username
  9. password: xxxxxx # this is the registry password
  10. tls:
  11. cert_file: # path to the cert file used in the registry
  12. key_file: # path to the key file used in the registry
  13. ca_file: # path to the ca file used in the registry
  1. mirrors:
  2. docker.io:
  3. endpoint:
  4. - "https://mycustomreg.com:5000"
  5. configs:
  6. "mycustomreg:5000":
  7. tls:
  8. cert_file: # path to the cert file used in the registry
  9. key_file: # path to the key file used in the registry
  10. ca_file: # path to the ca file used in the registry

Without TLS

Below are examples showing how you may configure /etc/rancher/k3s/registries.yaml on each node when not using TLS.

  • With Authentication
  • Without Authentication
  1. mirrors:
  2. docker.io:
  3. endpoint:
  4. - "http://mycustomreg.com:5000"
  5. configs:
  6. "mycustomreg:5000":
  7. auth:
  8. username: xxxxxx # this is the registry username
  9. password: xxxxxx # this is the registry password
  1. mirrors:
  2. docker.io:
  3. endpoint:
  4. - "http://mycustomreg.com:5000"

In case of no TLS communication, you need to specify http:// for the endpoints, otherwise it will default to https.

In order for the registry changes to take effect, you need to restart K3s on each node.

Adding Images to the Private Registry

First, obtain the k3s-images.txt file from GitHub for the release you are working with. Pull the K3s images listed on the k3s-images.txt file from docker.io

Example: docker pull docker.io/rancher/coredns-coredns:1.6.3

Then, retag the images to the private registry.

Example: docker tag rancher/coredns-coredns:1.6.3 mycustomreg.com:5000/coredns-coredns

Last, push the images to the private registry.

Example: docker push mycustomreg.com:5000/coredns-coredns