Registry and Registry Mirrors

DKP supports operation with several local registry tools.

Registry mirrors are local copies of images from a public registry that follows (or mirrors) the file structure of a public registry. If you need to set up a private registry with a registry mirror, see this page for details on using the flag(s).
Container registries are collections of container repositories, and can also offer API paths and access rules.
Container repositories are a collection of related container images. The container image has everything a piece of software may need to run, including code, resources, and tools. Container repositories store container images for setup and deployment, and you use the repositories to manage, pull, and push images during cluster operations.

Kubernetes does not natively provide a registry for hosting the container images you will use to run the applications you want to deploy on Kubernetes. Instead, Kubernetes requires you to use an external solution for storing and sharing container images. There are a variety of Kubernetes-compatible registry options that are compatible with DKP.

How Does it Work?

The first time you request an image from your local registry mirror, it pulls the image from the public registry (such as Docker) and stores it locally before handing it back to you. On subsequent requests, the local registry mirror is able to serve the image from its own storage.

Air-gapped vs Non-air-gapped Environments

In a non-air-gapped environment, you have access to the Internet. You retrieve artifacts from specialized repositories dedicated to them, such as Docker images contained in DockerHub and Helm Charts that come from a dedicated Helm Chart repository. You can also create your own local repository to hold the downloaded container images needed or any custom images you’ve created with the Konvoy Image Builder tool.

In an air-gapped environment, you need a local repository to store Helm charts, Docker images, and other artifacts. Private registries provide security and privacy into enterprise container image storage, whether hosted remotely or on-premises locally in an air-gapped environment. DKP in an air-gapped environment requires a local container registry of trusted images to enable production-level Kubernetes cluster management. However, a local registry is an option in a non-air-gapped environment as well for speed and security.

If you want to use images from this local registry to deploy applications inside your Kubernetes cluster, you’ll need to set up a secret for a private registry. The secret contains your login data, which Kubernetes needs to connect to your private repository.

It is not required to export any variables for most of the command examples. However, the export, along with the use of an arbitrary variable name, is primarily to make it clearer what values in the commands need to be substituted. Also, that makes it easier to copy and paste the examples. Furthermore, if there are multiple steps in a procedure that need you to specify a variable, you export it once with the export, and then reuse it in future commands.

For example,

CODE

export REGISTRY_URL="<https/http>://<registry-address>:<registry-port>"

To run the create cluster command using that variable created above, use the example command replacing azure with your choice of provider [gcp, vsphere, vcd, pre-provisioned, aws]:

CODE

dkp create cluster azure --registry-mirror-url=${REGISTRY_URL}

A cluster administrator uses DKP CLI commands to upload the image bundle to your registry with parameters:

CODE

dkp push bundle --bundle <bundle> --to-registry=${REGISTRY_URL}

Parameter definitions:

--bundle <bundle> the group of images. The example below is for the DKP air-gapped environment bundle
Either use exported variable${REGISTRY_URL} or --to-registry=<registry-address>/<registry-name> to provide registry location for push

An example command would be:

CODE

dkp push bundle --bundle container-images/konvoy-image-bundle-v2.8.1.tar --to-registry=333000009999.dkr.ecr.us-west-2.amazonaws.com/can-test

Any URL can contain an optional port specification. If no port is specified, then the default port for the protocol is assumed. For example, for HTTPS protocol, port 443 is the default meaning these two URL’s are equivalent:

CODE

https://docs.d2iq.com
https://docs.d2iq.com:443

A port specification is only required if the URL target is using a port number other than the default.

Next Topic

Subnets and Pods

OR

Return to Installation:

If using the Day 1 - Basic Installs by Infrastructure instructions, proceed (or return) to that section to install and setup DKP based on your infrastructure environment provider.
If using the Custom Installation and Additional Infrastructure Tools instructions, proceed (or return) to that section and select the infrastructure provider you are using.

How Does it Work?

Air-gapped vs Non-air-gapped Environments

Related Topics

Next Topic