update kubeadm pages to use registry.k8s.io
k8s.gcr.io is a deprecated in favor of registry.k8s.io. The kubeadm code in k/k was already changed to use the new domain name.
This commit is contained in:
Lubomir I. Ivanov
parent
9213f0775f
commit
edb74f1dec
|
|
@ -199,7 +199,7 @@ Static Pod manifest share a set of common properties:
|
|||
|
||||
Please note that:
|
||||
|
||||
1. All images will be pulled from k8s.gcr.io by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository
|
||||
1. All images will be pulled from registry.k8s.io by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository
|
||||
2. In case of kubeadm is executed in the `--dry-run` mode, static Pods files are written in a temporary folder
|
||||
3. Static Pod manifest generation for control plane components can be invoked individually with the [`kubeadm init phase control-plane all`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-control-plane) command
|
||||
|
||||
|
|
@ -289,7 +289,7 @@ a local etcd instance running in a Pod with following attributes:
|
|||
|
||||
Please note that:
|
||||
|
||||
1. The etcd image will be pulled from `k8s.gcr.io` by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository
|
||||
1. The etcd image will be pulled from `registry.k8s.io` by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository
|
||||
2. in case of kubeadm is executed in the `--dry-run` mode, the etcd static Pod manifest is written in a temporary folder
|
||||
3. Static Pod manifest generation for local etcd can be invoked individually with the [`kubeadm init phase etcd local`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-etcd) command
|
||||
|
||||
|
|
|
|||
|
|
@ -212,11 +212,11 @@ kubeadm config images pull
|
|||
You can pass `--config` to the above commands with a [kubeadm configuration file](#config-file)
|
||||
to control the `kubernetesVersion` and `imageRepository` fields.
|
||||
|
||||
All default `k8s.gcr.io` images that kubeadm requires support multiple architectures.
|
||||
All default `registry.k8s.io` images that kubeadm requires support multiple architectures.
|
||||
|
||||
### Using custom images {#custom-images}
|
||||
|
||||
By default, kubeadm pulls images from `k8s.gcr.io`. If the
|
||||
By default, kubeadm pulls images from `registry.k8s.io`. If the
|
||||
requested Kubernetes version is a CI label (such as `ci/latest`)
|
||||
`gcr.io/k8s-staging-ci-images` is used.
|
||||
|
||||
|
|
@ -225,18 +225,18 @@ Allowed customization are:
|
|||
|
||||
* To provide `kubernetesVersion` which affects the version of the images.
|
||||
* To provide an alternative `imageRepository` to be used instead of
|
||||
`k8s.gcr.io`.
|
||||
`registry.k8s.io`.
|
||||
* To provide a specific `imageRepository` and `imageTag` for etcd or CoreDNS.
|
||||
|
||||
Image paths between the default `k8s.gcr.io` and a custom repository specified using
|
||||
Image paths between the default `registry.k8s.io` and a custom repository specified using
|
||||
`imageRepository` may differ for backwards compatibility reasons. For example,
|
||||
one image might have a subpath at `k8s.gcr.io/subpath/image`, but be defaulted
|
||||
one image might have a subpath at `registry.k8s.io/subpath/image`, but be defaulted
|
||||
to `my.customrepository.io/image` when using a custom repository.
|
||||
|
||||
To ensure you push the images to your custom repository in paths that kubeadm
|
||||
can consume, you must:
|
||||
|
||||
* Pull images from the defaults paths at `k8s.gcr.io` using `kubeadm config images {list|pull}`.
|
||||
* Pull images from the defaults paths at `registry.k8s.io` using `kubeadm config images {list|pull}`.
|
||||
* Push images to the paths from `kubeadm config images list --config=config.yaml`,
|
||||
where `config.yaml` contains the custom `imageRepository`, and/or `imageTag`
|
||||
for etcd and CoreDNS.
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ After you initialize your control-plane, the kubelet runs normally.
|
|||
### Preparing the required container images
|
||||
|
||||
This step is optional and only applies in case you wish `kubeadm init` and `kubeadm join`
|
||||
to not download the default container images which are hosted at `k8s.gcr.io`.
|
||||
to not download the default container images which are hosted at `registry.k8s.io`.
|
||||
|
||||
Kubeadm has commands that can help you pre-pull the required images
|
||||
when creating a cluster without an internet connection on its nodes.
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ _See [External etcd topology](/docs/setup/production-environment/tools/kubeadm/h
|
|||
|
||||
### Container images
|
||||
|
||||
Each host should have access read and fetch images from the Kubernetes container image registry, `k8s.gcr.io`.
|
||||
Each host should have access read and fetch images from the Kubernetes container image registry, `registry.k8s.io`.
|
||||
If you want to deploy a highly-available cluster where the hosts do not have access to pull images, this is possible. You must ensure by some other means that the correct container images are already available on the relevant hosts.
|
||||
|
||||
### Command line interface {#kubectl}
|
||||
|
|
@ -226,8 +226,8 @@ option. Your cluster requirements may need a different configuration.
|
|||
As stated in the command output, the certificate key gives access to cluster sensitive data, keep it secret!
|
||||
{{< /caution >}}
|
||||
|
||||
1. Apply the CNI plugin of your choice:
|
||||
[Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)
|
||||
1. Apply the CNI plugin of your choice:
|
||||
[Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)
|
||||
to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the
|
||||
kubeadm configuration file (if applicable).
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ etcd cluster of three members that can be used by kubeadm during cluster creatio
|
|||
the kubeadm config file.
|
||||
* Each host must have systemd and a bash compatible shell installed.
|
||||
* Each host must [have a container runtime, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
|
||||
* Each host should have access to the Kubernetes container image registry (`k8s.gcr.io`) or list/pull the required etcd image using
|
||||
* Each host should have access to the Kubernetes container image registry (`registry.k8s.io`) or list/pull the required etcd image using
|
||||
`kubeadm config images list/pull`. This guide will setup etcd instances as
|
||||
[static pods](/docs/tasks/configure-pod-container/static-pod/) managed by a kubelet.
|
||||
* Some infrastructure to copy files between hosts. For example `ssh` and `scp`
|
||||
|
|
@ -276,7 +276,7 @@ on Kubernetes dual-stack support see [Dual-stack support with kubeadm](/docs/set
|
|||
```sh
|
||||
docker run --rm -it \
|
||||
--net host \
|
||||
-v /etc/kubernetes:/etc/kubernetes k8s.gcr.io/etcd:${ETCD_TAG} etcdctl \
|
||||
-v /etc/kubernetes:/etc/kubernetes registry.k8s.io/etcd:${ETCD_TAG} etcdctl \
|
||||
--cert /etc/kubernetes/pki/etcd/peer.crt \
|
||||
--key /etc/kubernetes/pki/etcd/peer.key \
|
||||
--cacert /etc/kubernetes/pki/etcd/ca.crt \
|
||||
|
|
|
|||
Loading…
Reference in New Issue