Merge remote-tracking branch 'upstream/main' into dev-1.23
This commit is contained in:
Jesse Butler
@@ -27,7 +27,7 @@ Kubernetes {{< glossary_tooltip term_id="service" >}} object.
|
||||
This task uses
|
||||
[Services with external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/), which
|
||||
require a supported environment. If your environment does not support this, you can use a Service of type
|
||||
[NodePort](/docs/concepts/services-networking/service/#nodeport) instead.
|
||||
[NodePort](/docs/concepts/services-networking/service/#type-nodeport) instead.
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
|
||||
@@ -182,7 +182,7 @@ The following manifest defines an Ingress that sends traffic to your Service via
|
||||
```
|
||||
|
||||
1. Add the following line to the bottom of the `/etc/hosts` file on
|
||||
your computer (you will need adminstrator access):
|
||||
your computer (you will need administrator access):
|
||||
|
||||
```
|
||||
172.17.0.15 hello-world.info
|
||||
|
||||
@@ -35,7 +35,7 @@ Dashboard also provides information on the state of Kubernetes resources in your
|
||||
The Dashboard UI is not deployed by default. To deploy it, run the following command:
|
||||
|
||||
```
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.3.1/aio/deploy/recommended.yaml
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml
|
||||
```
|
||||
|
||||
## Accessing the Dashboard UI
|
||||
|
||||
@@ -325,7 +325,7 @@ Here is an example:
|
||||
```shell
|
||||
ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 snapshot restore snapshotdb
|
||||
```
|
||||
Another example for restoring using etcdutl options:
|
||||
Another example for restoring using etcdctl options:
|
||||
```shell
|
||||
ETCDCTL_API=3 etcdctl --data-dir <data-dir-location> snapshot restore snapshotdb
|
||||
```
|
||||
|
||||
@@ -1,225 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- jszczepkowski
|
||||
title: Set up a High-Availability Control Plane
|
||||
content_type: task
|
||||
aliases: [ '/docs/tasks/administer-cluster/highly-available-master/' ]
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
|
||||
|
||||
You can replicate Kubernetes control plane nodes in `kube-up` or `kube-down` scripts for Google Compute Engine. However this scripts are not suitable for any sort of production use, it's widely used in the project's CI.
|
||||
This document describes how to use kube-up/down scripts to manage a highly available (HA) control plane and how HA control planes are implemented for use with GCE.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Starting an HA-compatible cluster
|
||||
|
||||
To create a new HA-compatible cluster, you must set the following flags in your `kube-up` script:
|
||||
|
||||
* `MULTIZONE=true` - to prevent removal of control plane kubelets from zones different than server's default zone.
|
||||
Required if you want to run control plane nodes in different zones, which is recommended.
|
||||
|
||||
* `ENABLE_ETCD_QUORUM_READ=true` - to ensure that reads from all API servers will return most up-to-date data.
|
||||
If true, reads will be directed to leader etcd replica.
|
||||
Setting this value to true is optional: reads will be more reliable but will also be slower.
|
||||
|
||||
Optionally, you can specify a GCE zone where the first control plane node is to be created.
|
||||
Set the following flag:
|
||||
|
||||
* `KUBE_GCE_ZONE=zone` - zone where the first control plane node will run.
|
||||
|
||||
The following sample command sets up a HA-compatible cluster in the GCE zone europe-west1-b:
|
||||
|
||||
```shell
|
||||
MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
Note that the commands above create a cluster with one control plane node;
|
||||
however, you can add new control plane nodes to the cluster with subsequent commands.
|
||||
|
||||
## Adding a new control plane node
|
||||
|
||||
After you have created an HA-compatible cluster, you can add control plane nodes to it.
|
||||
You add control plane nodes by using a `kube-up` script with the following flags:
|
||||
|
||||
* `KUBE_REPLICATE_EXISTING_MASTER=true` - to create a replica of an existing control plane
|
||||
node.
|
||||
|
||||
* `KUBE_GCE_ZONE=zone` - zone where the control plane node will run.
|
||||
Must be in the same region as other control plane nodes' zones.
|
||||
|
||||
You don't need to set the `MULTIZONE` or `ENABLE_ETCD_QUORUM_READS` flags,
|
||||
as those are inherited from when you started your HA-compatible cluster.
|
||||
|
||||
The following sample command replicates the control plane node on an existing
|
||||
HA-compatible cluster:
|
||||
|
||||
```shell
|
||||
KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
## Removing a control plane node
|
||||
|
||||
You can remove a control plane node from an HA cluster by using a `kube-down` script with the following flags:
|
||||
|
||||
* `KUBE_DELETE_NODES=false` - to restrain deletion of kubelets.
|
||||
|
||||
* `KUBE_GCE_ZONE=zone` - the zone from where the control plane node will be removed.
|
||||
|
||||
* `KUBE_REPLICA_NAME=replica_name` - (optional) the name of control plane node to
|
||||
remove. If empty: any replica from the given zone will be removed.
|
||||
|
||||
The following sample command removes a control plane node from an existing HA cluster:
|
||||
|
||||
```shell
|
||||
KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
|
||||
```
|
||||
|
||||
## Handling control plane node failures
|
||||
|
||||
If one of the control plane nodes in your HA cluster fails,
|
||||
the best practice is to remove the node from your cluster and add a new control plane
|
||||
node in the same zone.
|
||||
The following sample commands demonstrate this process:
|
||||
|
||||
1. Remove the broken replica:
|
||||
|
||||
```shell
|
||||
KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
|
||||
```
|
||||
|
||||
<ol start="2"><li>Add a new node in place of the old one:</li></ol>
|
||||
|
||||
```shell
|
||||
KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
## Best practices for replicating control plane nodes for HA clusters
|
||||
|
||||
* Try to place control plane nodes in different zones. During a zone failure, all
|
||||
control plane nodes placed inside the zone will fail.
|
||||
To survive zone failure, also place nodes in multiple zones
|
||||
(see [multiple-zones](/docs/setup/best-practices/multiple-zones/) for details).
|
||||
|
||||
* Do not use a cluster with two control plane nodes. Consensus on a two-node
|
||||
control plane requires both nodes running when changing persistent state.
|
||||
As a result, both nodes are needed and a failure of any node turns the cluster
|
||||
into majority failure state.
|
||||
A two-node control plane is thus inferior, in terms of HA, to a cluster with
|
||||
one control plane node.
|
||||
|
||||
* When you add a control plane node, cluster state (etcd) is copied to a new instance.
|
||||
If the cluster is large, it may take a long time to duplicate its state.
|
||||
This operation may be sped up by migrating the etcd data directory, as described in
|
||||
the [etcd administration guide](https://etcd.io/docs/v2.3/admin_guide/#member-migration)
|
||||
(we are considering adding support for etcd data dir migration in the future).
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## Implementation notes
|
||||
|
||||
|
||||
|
||||
### Overview
|
||||
The figure above illustrates three control plane nodes and their components in a highly available cluster. The control plane node’s components employ the following methods:
|
||||
|
||||
- etcd: instances are clustered together using consensus.
|
||||
|
||||
- Controllers, scheduler and cluster auto-scaler: only one instance of each will be active in a cluster using a lease mechanism.
|
||||
|
||||
- Add-on manager: each works independently to keep add-ons in sync.
|
||||
|
||||
In addition, a load balancer operating in front of the API servers routes external and internal traffic to the control plane nodes.
|
||||
Each of the control plane nodes will run the following components in the following mode:
|
||||
|
||||
* etcd instance: all instances will be clustered together using consensus;
|
||||
|
||||
* API server: each server will talk to local etcd - all API servers in the cluster will be available;
|
||||
|
||||
* controllers, scheduler, and cluster auto-scaler: will use lease mechanism - only one instance of each of them will be active in the cluster;
|
||||
|
||||
* add-on manager: each manager will work independently trying to keep add-ons in sync.
|
||||
|
||||
In addition, there will be a load balancer in front of API servers that will route external and internal traffic to them.
|
||||
|
||||
### Load balancing
|
||||
|
||||
When starting the second control plane node, a load balancer containing the two replicas will be created
|
||||
and the IP address of the first replica will be promoted to IP address of load balancer.
|
||||
Similarly, after removal of the penultimate control plane node, the load balancer will be removed and its IP address will be assigned to the last remaining replica.
|
||||
Please note that creation and removal of load balancer are complex operations and it may take some time (~20 minutes) for them to propagate.
|
||||
|
||||
### Control plane service & kubelets
|
||||
|
||||
Instead of trying to keep an up-to-date list of Kubernetes apiserver in the Kubernetes service,
|
||||
the system directs all traffic to the external IP:
|
||||
|
||||
* in case of a single node control plane, the IP points to the control plane node,
|
||||
|
||||
* in case of an HA control plane, the IP points to the load balancer in-front of the control plane nodes.
|
||||
|
||||
Similarly, the external IP will be used by kubelets to communicate with the control plane.
|
||||
|
||||
### Control plane node certificates
|
||||
|
||||
Kubernetes generates TLS certificates for the external public IP and local IP for each control plane node.
|
||||
There are no certificates for the ephemeral public IP for control plane nodes;
|
||||
to access a control plane node via its ephemeral public IP, you must skip TLS verification.
|
||||
|
||||
### Clustering etcd
|
||||
|
||||
To allow etcd clustering, ports needed to communicate between etcd instances will be opened (for inside cluster communication).
|
||||
To make such deployment secure, communication between etcd instances is authorized using SSL.
|
||||
|
||||
### API server identity
|
||||
|
||||
{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
|
||||
|
||||
The API Server Identity feature is controlled by a
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
and is not enabled by default. You can activate API Server Identity by enabling
|
||||
the feature gate named `APIServerIdentity` when you start the
|
||||
{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}:
|
||||
|
||||
```shell
|
||||
kube-apiserver \
|
||||
--feature-gates=APIServerIdentity=true \
|
||||
# …and other flags as usual
|
||||
```
|
||||
|
||||
During bootstrap, each kube-apiserver assigns a unique ID to itself. The ID is
|
||||
in the format of `kube-apiserver-{UUID}`. Each kube-apiserver creates a
|
||||
[Lease](/docs/reference/generated/kubernetes-api/{{< param "version" >}}//#lease-v1-coordination-k8s-io)
|
||||
in the _kube-system_ {{< glossary_tooltip text="namespaces" term_id="namespace">}}.
|
||||
The Lease name is the unique ID for the kube-apiserver. The Lease contains a
|
||||
label `k8s.io/component=kube-apiserver`. Each kube-apiserver refreshes its
|
||||
Lease every `IdentityLeaseRenewIntervalSeconds` (defaults to 10s). Each
|
||||
kube-apiserver also checks all the kube-apiserver identity Leases every
|
||||
`IdentityLeaseDurationSeconds` (defaults to 3600s), and deletes Leases that
|
||||
hasn't got refreshed for more than `IdentityLeaseDurationSeconds`.
|
||||
`IdentityLeaseRenewIntervalSeconds` and `IdentityLeaseDurationSeconds` can be
|
||||
configured by kube-apiserver flags `identity-lease-renew-interval-seconds`
|
||||
and `identity-lease-duration-seconds`.
|
||||
|
||||
Enabling this feature is a prerequisite for using features that involve HA API
|
||||
server coordination (for example, the `StorageVersionAPI` feature gate).
|
||||
|
||||
## Additional reading
|
||||
|
||||
[Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
|
||||
|
||||
@@ -165,7 +165,7 @@ These are advanced topics for users who need to integrate their organization's c
|
||||
### Set up a signer
|
||||
|
||||
The Kubernetes Certificate Authority does not work out of the box.
|
||||
You can configure an external signer such as [cert-manager](https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html), or you can use the built-in signer.
|
||||
You can configure an external signer such as [cert-manager](https://cert-manager.io/docs/configuration/ca/), or you can use the built-in signer.
|
||||
|
||||
The built-in signer is part of [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/).
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ without root privileges, by using a {{< glossary_tooltip text="user namespace" t
|
||||
This technique is also known as _rootless mode_.
|
||||
|
||||
{{< note >}}
|
||||
This document describes how to run Kubernetes Node components (and hence pods) a non-root user.
|
||||
This document describes how to run Kubernetes Node components (and hence pods) as a non-root user.
|
||||
|
||||
If you are just looking for how to run a pod as a non-root user, see [SecurityContext](/docs/tasks/configure-pod-container/security-context/).
|
||||
{{< /note >}}
|
||||
@@ -141,6 +141,7 @@ the host with an external port forwarder, such as RootlessKit, slirp4netns, or
|
||||
You can use the port forwarder from K3s.
|
||||
See [Running K3s in Rootless Mode](https://rancher.com/docs/k3s/latest/en/advanced/#known-issues-with-rootless-mode)
|
||||
for more details.
|
||||
The implementation can be found in [the `pkg/rootlessports` package](https://github.com/k3s-io/k3s/blob/v1.22.3+k3s1/pkg/rootlessports/controller.go) of k3s.
|
||||
|
||||
### Configuring CRI
|
||||
|
||||
@@ -152,8 +153,7 @@ containerd or CRI-O and ensure that it is running within the user namespace befo
|
||||
|
||||
Running CRI plugin of containerd in a user namespace is supported since containerd 1.4.
|
||||
|
||||
Running containerd within a user namespace requires the following configurations
|
||||
in `/etc/containerd/containerd-config.toml`.
|
||||
Running containerd within a user namespace requires the following configurations.
|
||||
|
||||
```toml
|
||||
version = 2
|
||||
@@ -176,6 +176,9 @@ version = 2
|
||||
SystemdCgroup = false
|
||||
```
|
||||
|
||||
The default path of the configuration file is `/etc/containerd/config.toml`.
|
||||
The path can be specified with `containerd -c /path/to/containerd/config.toml`.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="CRI-O" %}}
|
||||
|
||||
@@ -183,7 +186,7 @@ Running CRI-O in a user namespace is supported since CRI-O 1.22.
|
||||
|
||||
CRI-O requires an environment variable `_CRIO_ROOTLESS=1` to be set.
|
||||
|
||||
The following configurations (in `/etc/crio/crio.conf`) are also recommended:
|
||||
The following configurations are also recommended:
|
||||
|
||||
```toml
|
||||
[crio]
|
||||
@@ -197,6 +200,8 @@ The following configurations (in `/etc/crio/crio.conf`) are also recommended:
|
||||
cgroup_manager = "cgroupfs"
|
||||
```
|
||||
|
||||
The default path of the configuration file is `/etc/crio/crio.conf`.
|
||||
The path can be specified with `crio --config /path/to/crio/crio.conf`.
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
+10
-5
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Check whether Dockershim deprecation affects you
|
||||
content_type: task
|
||||
content_type: task
|
||||
reviewers:
|
||||
- SergeyKanzhelev
|
||||
weight: 20
|
||||
@@ -26,16 +26,21 @@ When alternative container runtime is used, executing Docker commands may either
|
||||
not work or yield unexpected output. This is how you can find whether you have a
|
||||
dependency on Docker:
|
||||
|
||||
1. Make sure no privileged Pods execute Docker commands.
|
||||
2. Check that scripts and apps running on nodes outside of Kubernetes
|
||||
1. Make sure no privileged Pods execute Docker commands (like `docker ps`),
|
||||
restart the Docker service (commands such as `systemctl restart docker.service`),
|
||||
or modify Docker-specific files such as `/etc/docker/daemon.json`.
|
||||
1. Check for any private registries or image mirror settings in the Docker
|
||||
configuration file (like `/etc/docker/daemon.json`). Those typically need to
|
||||
be reconfigured for another container runtime.
|
||||
1. Check that scripts and apps running on nodes outside of your Kubernetes
|
||||
infrastructure do not execute Docker commands. It might be:
|
||||
- SSH to nodes to troubleshoot;
|
||||
- Node startup scripts;
|
||||
- Monitoring and security agents installed on nodes directly.
|
||||
3. Third-party tools that perform above mentioned privileged operations. See
|
||||
1. Third-party tools that perform above mentioned privileged operations. See
|
||||
[Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents)
|
||||
for more information.
|
||||
4. Make sure there is no indirect dependencies on dockershim behavior.
|
||||
1. Make sure there is no indirect dependencies on dockershim behavior.
|
||||
This is an edge case and unlikely to affect your application. Some tooling may be configured
|
||||
to react to Docker-specific behaviors, for example, raise alert on specific metrics or search for
|
||||
a specific log message as part of troubleshooting instructions.
|
||||
|
||||
+52
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: Find Out What Container Runtime is Used on a Node
|
||||
content_type: task
|
||||
reviewers:
|
||||
- SergeyKanzhelev
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This page outlines steps to find out what [container runtime](/docs/setup/production-environment/container-runtimes/)
|
||||
the nodes in your cluster use.
|
||||
|
||||
Depending on the way you run your cluster, the container runtime for the nodes may
|
||||
have been pre-configured or you need to configure it. If you're using a managed
|
||||
Kubernetes service, there might be vendor-specific ways to check what container runtime is
|
||||
configured for the nodes. The method described on this page should work whenever
|
||||
the execution of `kubectl` is allowed.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
Install and configure `kubectl`. See [Install Tools](/docs/tasks/tools/#kubectl) section for details.
|
||||
|
||||
## Find out the container runtime used on a Node
|
||||
|
||||
Use `kubectl` to fetch and show node information:
|
||||
|
||||
```shell
|
||||
kubectl get nodes -o wide
|
||||
```
|
||||
|
||||
The output is similar to the following. The column `CONTAINER-RUNTIME` outputs
|
||||
the runtime and its version.
|
||||
|
||||
```none
|
||||
# For dockershim
|
||||
NAME STATUS VERSION CONTAINER-RUNTIME
|
||||
node-1 Ready v1.16.15 docker://19.3.1
|
||||
node-2 Ready v1.16.15 docker://19.3.1
|
||||
node-3 Ready v1.16.15 docker://19.3.1
|
||||
```
|
||||
|
||||
```none
|
||||
# For containerd
|
||||
NAME STATUS VERSION CONTAINER-RUNTIME
|
||||
node-1 Ready v1.19.6 containerd://1.4.1
|
||||
node-2 Ready v1.19.6 containerd://1.4.1
|
||||
node-3 Ready v1.19.6 containerd://1.4.1
|
||||
```
|
||||
|
||||
Find out more information about container runtimes
|
||||
on [Container Runtimes](/docs/setup/production-environment/container-runtimes/) page.
|
||||
@@ -292,7 +292,7 @@ command line arguments to `kube-apiserver`:
|
||||
* `--service-account-issuer`
|
||||
* `--service-account-key-file`
|
||||
* `--service-account-signing-key-file`
|
||||
* `--api-audiences`
|
||||
* `--api-audiences` (can be omitted)
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
+1
-1
@@ -90,7 +90,7 @@ plugins:
|
||||
# Array of authenticated usernames to exempt.
|
||||
usernames: []
|
||||
# Array of runtime class names to exempt.
|
||||
runtimeClassNames: []
|
||||
runtimeClasses: []
|
||||
# Array of namespaces to exempt.
|
||||
namespaces: []
|
||||
```
|
||||
|
||||
@@ -6,29 +6,36 @@ weight: 100
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This page shows how to create a Pod that uses a Secret to pull an image from a
|
||||
private Docker registry or repository.
|
||||
This page shows how to create a Pod that uses a
|
||||
{{< glossary_tooltip text="Secret" term_id="secret" >}} to pull an image from a
|
||||
private container image registry or repository.
|
||||
|
||||
{{% thirdparty-content single="true" %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
* {{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
* To do this exercise, you need a
|
||||
[Docker ID](https://docs.docker.com/docker-id/) and password.
|
||||
* To do this exercise, you need the `docker` command line tool, and a
|
||||
[Docker ID](https://docs.docker.com/docker-id/) for which you know the password.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Log in to Docker
|
||||
## Log in to Docker Hub
|
||||
|
||||
On your laptop, you must authenticate with a registry in order to pull a private image:
|
||||
On your laptop, you must authenticate with a registry in order to pull a private image.
|
||||
|
||||
Use the `docker` tool to log in to Docker Hub. See the _log in_ section of
|
||||
[Docker ID accounts](https://docs.docker.com/docker-id/#log-in) for more information.
|
||||
|
||||
```shell
|
||||
docker login
|
||||
```
|
||||
|
||||
When prompted, enter your Docker username and password.
|
||||
When prompted, enter your Docker ID, and then the credential you want to use (access token,
|
||||
or the password for your Docker ID).
|
||||
|
||||
The login process creates or updates a `config.json` file that holds an authorization token.
|
||||
The login process creates or updates a `config.json` file that holds an authorization token. Review [how Kubernetes interprets this file](/docs/concepts/containers/images#config-json).
|
||||
|
||||
View the `config.json` file:
|
||||
|
||||
@@ -171,14 +178,14 @@ You have successfully set your Docker credentials as a Secret called `regcred` i
|
||||
|
||||
## Create a Pod that uses your Secret
|
||||
|
||||
Here is a configuration file for a Pod that needs access to your Docker credentials in `regcred`:
|
||||
Here is a manifest for an example Pod that needs access to your Docker credentials in `regcred`:
|
||||
|
||||
{{< codenew file="pods/private-reg-pod.yaml" >}}
|
||||
|
||||
Download the above file:
|
||||
Download the above file onto your computer:
|
||||
|
||||
```shell
|
||||
wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml
|
||||
curl -L -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml
|
||||
```
|
||||
|
||||
In file `my-private-reg-pod.yaml`, replace `<your-private-image>` with the path to an image in a private registry such as:
|
||||
@@ -200,10 +207,10 @@ kubectl get pod private-reg
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Learn more about [Secrets](/docs/concepts/configuration/secret/).
|
||||
* Learn more about [Secrets](/docs/concepts/configuration/secret/)
|
||||
* or read the API reference for {{< api-reference page="config-and-storage-resources/secret-v1" >}}
|
||||
* Learn more about [using a private registry](/docs/concepts/containers/images/#using-a-private-registry).
|
||||
* Learn more about [adding image pull secrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account).
|
||||
* See [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-).
|
||||
* See [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core).
|
||||
* See the `imagePullSecrets` field of [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
|
||||
* See the `imagePullSecrets` field within the [container definitions](/docs/reference/kubernetes-api/workload-resources/pod-v1/#containers) of a Pod
|
||||
|
||||
|
||||
@@ -213,6 +213,13 @@ In order to highlight the full range of configuration, the Service you created
|
||||
here uses a different port number than the Pods. For many real-world
|
||||
Services, these values might be the same.
|
||||
|
||||
## Any Network Policy Ingress rules affecting the target Pods?
|
||||
|
||||
If you have deployed any Network Policy Ingress rules which may affect incoming
|
||||
traffic to `hostnames-*` Pods, these need to be reviewed.
|
||||
|
||||
Please refer to [Network Policies](/docs/concepts/services-networking/network-policies/) for more details.
|
||||
|
||||
## Does the Service work by DNS name?
|
||||
|
||||
One of the most common ways that clients consume a Service is through a DNS
|
||||
|
||||
@@ -71,15 +71,26 @@ config. Save it as `my-scheduler.yaml`:
|
||||
|
||||
{{< codenew file="admin/sched/my-scheduler.yaml" >}}
|
||||
|
||||
An important thing to note here is that the name of the scheduler specified as an
|
||||
argument to the scheduler command in the container spec should be unique. This is the name that is matched against the value of the optional `spec.schedulerName` on pods, to determine whether this scheduler is responsible for scheduling a particular pod.
|
||||
In the above manifest, you use a [KubeSchedulerConfiguration](/docs/reference/scheduling/config/)
|
||||
to customize the behavior of your scheduler implementation. This configuration has been passed to
|
||||
the `kube-scheduler` during initialization with the `--config` option. The `my-scheduler-config` ConfigMap stores the configuration file. The Pod of the`my-scheduler` Deployment mounts the `my-scheduler-config` ConfigMap as a volume.
|
||||
|
||||
Note also that we created a dedicated service account `my-scheduler` and bind the cluster role
|
||||
In the aforementioned Scheduler Configuration, your scheduler implementation is represented via
|
||||
a [KubeSchedulerProfile](/docs/reference/config-api/kube-scheduler-config.v1beta2/#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerProfile).
|
||||
{{< note >}}
|
||||
To determine if a scheduler is responsible for scheduling a specific Pod, the `spec.schedulerName` field in a
|
||||
PodTemplate or Pod manifest must match the `schedulerName` field of the `KubeSchedulerProfile`.
|
||||
All schedulers running in the cluster must have unique names.
|
||||
{{< /note >}}
|
||||
|
||||
Also, note that you create a dedicated service account `my-scheduler` and bind the ClusterRole
|
||||
`system:kube-scheduler` to it so that it can acquire the same privileges as `kube-scheduler`.
|
||||
|
||||
Please see the
|
||||
[kube-scheduler documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for
|
||||
detailed description of other command line arguments.
|
||||
detailed description of other command line arguments and
|
||||
[Scheduler Configuration reference](https://kubernetes.io/docs/reference/config-api/kube-scheduler-config.v1beta2/) for
|
||||
detailed description of other customizable `kube-scheduler` configurations.
|
||||
|
||||
## Run the second scheduler in the cluster
|
||||
|
||||
@@ -110,11 +121,11 @@ pod in this list.
|
||||
|
||||
To run multiple-scheduler with leader election enabled, you must do the following:
|
||||
|
||||
First, update the following fields in your YAML file:
|
||||
Update the following fields for the KubeSchedulerConfiguration in the `my-scheduler-config` ConfigMap in your YAML file:
|
||||
|
||||
* `--leader-elect=true`
|
||||
* `--lock-object-namespace=<lock-object-namespace>`
|
||||
* `--lock-object-name=<lock-object-name>`
|
||||
* `leaderElection.leaderElect` to `true`
|
||||
* `leaderElection.resourceNamespace` to `<lock-object-namespace>`
|
||||
* `leaderElection.resourceName` to `<lock-object-name>`
|
||||
|
||||
{{< note >}}
|
||||
The control plane creates the lock objects for you, but the namespace must already exist.
|
||||
@@ -168,8 +179,8 @@ scheduler in that pod spec. Let's look at three examples.
|
||||
{{< codenew file="admin/sched/pod3.yaml" >}}
|
||||
|
||||
In this case, we specify that this pod should be scheduled using the scheduler that we
|
||||
deployed - `my-scheduler`. Note that the value of `spec.schedulerName` should match the name supplied to the scheduler
|
||||
command as an argument in the deployment config for the scheduler.
|
||||
deployed - `my-scheduler`. Note that the value of `spec.schedulerName` should match the name supplied for the scheduler
|
||||
in the `schedulerName` field of the mapping `KubeSchedulerProfile`.
|
||||
|
||||
Save this file as `pod3.yaml` and submit it to the Kubernetes cluster.
|
||||
|
||||
|
||||
@@ -25,15 +25,8 @@ You need to configure the API Server to use the Konnectivity service
|
||||
and direct the network traffic to the cluster nodes:
|
||||
|
||||
1. Make sure that
|
||||
the `ServiceAccountTokenVolumeProjection` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
is enabled. You can enable
|
||||
[service account token volume protection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)
|
||||
by providing the following flags to the kube-apiserver:
|
||||
```
|
||||
--service-account-issuer=api
|
||||
--service-account-signing-key-file=/etc/kubernetes/pki/sa.key
|
||||
--api-audiences=system:konnectivity-server
|
||||
```
|
||||
[Service Account Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)
|
||||
feature enabled in your cluster. It is enabled by default since Kubernetes v1.20.
|
||||
1. Create an egress configuration file such as `admin/konnectivity/egress-selector-configuration.yaml`.
|
||||
1. Set the `--egress-selector-config-file` flag of the API Server to the path of
|
||||
your API Server egress configuration file.
|
||||
|
||||
@@ -12,8 +12,8 @@ card:
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew latestVersion >}} client can communicate with v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, and v{{< skew nextMinorVersion >}} control planes.
|
||||
Using the latest version of kubectl helps avoid unforeseen issues.
|
||||
You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew currentVersion >}} client can communicate with v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersionAddMinor 0 >}}, and v{{< skew currentVersionAddMinor 1 >}} control planes.
|
||||
Using the latest compatible version of kubectl helps avoid unforeseen issues.
|
||||
|
||||
## Install kubectl on Linux
|
||||
|
||||
@@ -130,7 +130,7 @@ For example, to download version {{< param "fullversion" >}} on Linux, type:
|
||||
{{% /tab %}}
|
||||
|
||||
{{< tab name="Red Hat-based distributions" codelang="bash" >}}
|
||||
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
|
||||
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
|
||||
[kubernetes]
|
||||
name=Kubernetes
|
||||
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
|
||||
@@ -139,7 +139,7 @@ gpgcheck=1
|
||||
repo_gpgcheck=1
|
||||
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
|
||||
EOF
|
||||
yum install -y kubectl
|
||||
sudo yum install -y kubectl
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
@@ -12,8 +12,8 @@ card:
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew latestVersion >}} client can communicate with v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, and v{{< skew nextMinorVersion >}} control planes.
|
||||
Using the latest version of kubectl helps avoid unforeseen issues.
|
||||
You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew currentVersion >}} client can communicate with v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersionAddMinor 0 >}}, and v{{< skew currentVersionAddMinor 1 >}} control planes.
|
||||
Using the latest compatible version of kubectl helps avoid unforeseen issues.
|
||||
|
||||
## Install kubectl on macOS
|
||||
|
||||
|
||||
@@ -12,8 +12,8 @@ card:
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew latestVersion >}} client can communicate with v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, and v{{< skew nextMinorVersion >}} control planes.
|
||||
Using the latest version of kubectl helps avoid unforeseen issues.
|
||||
You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew currentVersion >}} client can communicate with v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersionAddMinor 0 >}}, and v{{< skew currentVersionAddMinor 1 >}} control planes.
|
||||
Using the latest compatible version of kubectl helps avoid unforeseen issues.
|
||||
|
||||
## Install kubectl on Windows
|
||||
|
||||
|
||||
Reference in New Issue
Block a user