Merge branch 'kubernetes:main' into patch-1
This commit is contained in:
Fabrice Jammes
@@ -64,17 +64,17 @@ kubectl cluster-info
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
Kubernetes master is running at https://104.197.5.247
|
||||
elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
|
||||
kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
|
||||
kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
|
||||
grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
|
||||
heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
|
||||
Kubernetes master is running at https://192.0.2.1
|
||||
elasticsearch-logging is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
|
||||
kibana-logging is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/kibana-logging/proxy
|
||||
kube-dns is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/kube-dns/proxy
|
||||
grafana is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
|
||||
heapster is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
|
||||
```
|
||||
|
||||
This shows the proxy-verb URL for accessing each service.
|
||||
For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached
|
||||
at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed, or through a kubectl proxy at, for example:
|
||||
at `https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed, or through a kubectl proxy at, for example:
|
||||
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
|
||||
|
||||
{{< note >}}
|
||||
@@ -104,13 +104,13 @@ The supported formats for the `<service_name>` segment of the URL are:
|
||||
* To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use:
|
||||
|
||||
```
|
||||
http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
|
||||
http://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
|
||||
```
|
||||
|
||||
* To access the Elasticsearch cluster health information `_cluster/health?pretty=true`, you would use:
|
||||
|
||||
```
|
||||
https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true
|
||||
https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true
|
||||
```
|
||||
|
||||
The health information is similar to this:
|
||||
@@ -133,7 +133,7 @@ The supported formats for the `<service_name>` segment of the URL are:
|
||||
* To access the *https* Elasticsearch service health information `_cluster/health?pretty=true`, you would use:
|
||||
|
||||
```
|
||||
https://104.197.5.247/api/v1/namespaces/kube-system/services/https:elasticsearch-logging/proxy/_cluster/health?pretty=true
|
||||
https://192.0.2.1/api/v1/namespaces/kube-system/services/https:elasticsearch-logging:/proxy/_cluster/health?pretty=true
|
||||
```
|
||||
|
||||
#### Using web browsers to access services running on the cluster
|
||||
|
||||
@@ -233,7 +233,7 @@ There are several different proxies you may encounter when using Kubernetes:
|
||||
- locates apiserver
|
||||
- adds authentication headers
|
||||
|
||||
1. The [apiserver proxy](#discovering-builtin-services):
|
||||
1. The [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster-services/#discovering-builtin-services):
|
||||
|
||||
- is a bastion built into the apiserver
|
||||
- connects a user outside of the cluster to cluster IPs which otherwise might not be reachable
|
||||
|
||||
+8
-7
@@ -22,7 +22,8 @@ It does not mean that there is a file named `kubeconfig`.
|
||||
|
||||
|
||||
{{< warning >}}
|
||||
Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure.
|
||||
Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig
|
||||
file could result in malicious code execution or file exposure.
|
||||
If you must use an untrusted kubeconfig file, inspect it carefully first, much as you would a shell script.
|
||||
{{< /warning>}}
|
||||
|
||||
@@ -50,7 +51,7 @@ to the scratch cluster requires authentication by username and password.
|
||||
Create a directory named `config-exercise`. In your
|
||||
`config-exercise` directory, create a file named `config-demo` with this content:
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
preferences: {}
|
||||
@@ -115,7 +116,7 @@ kubectl config --kubeconfig=config-demo view
|
||||
|
||||
The output shows the two clusters, two users, and three contexts:
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
@@ -271,7 +272,7 @@ For example:
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG_SAVED=$KUBECONFIG
|
||||
export KUBECONFIG_SAVED="$KUBECONFIG"
|
||||
```
|
||||
|
||||
### Windows PowerShell
|
||||
@@ -290,7 +291,7 @@ Temporarily append two paths to your `KUBECONFIG` environment variable. For exam
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
|
||||
export KUBECONFIG="${KUBECONFIG}:config-demo:config-demo-2"
|
||||
```
|
||||
|
||||
### Windows PowerShell
|
||||
@@ -356,7 +357,7 @@ For example:
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
|
||||
export KUBECONFIG="${KUBECONFIG}:${HOME}/.kube/config"
|
||||
```
|
||||
|
||||
### Windows Powershell
|
||||
@@ -379,7 +380,7 @@ Return your `KUBECONFIG` environment variable to its original value. For example
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG_SAVED
|
||||
export KUBECONFIG="$KUBECONFIG_SAVED"
|
||||
```
|
||||
|
||||
### Windows PowerShell
|
||||
|
||||
+102
-116
@@ -11,180 +11,169 @@ This page shows how to use `kubectl port-forward` to connect to a MongoDB
|
||||
server running in a Kubernetes cluster. This type of connection can be useful
|
||||
for database debugging.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* Install [MongoDB Shell](https://www.mongodb.com/try/download/shell).
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Creating MongoDB deployment and service
|
||||
|
||||
1. Create a Deployment that runs MongoDB:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
|
||||
```
|
||||
|
||||
The output of a successful command verifies that the deployment was created:
|
||||
The output of a successful command verifies that the deployment was created:
|
||||
|
||||
```
|
||||
deployment.apps/mongo created
|
||||
```
|
||||
```
|
||||
deployment.apps/mongo created
|
||||
```
|
||||
|
||||
View the pod status to check that it is ready:
|
||||
View the pod status to check that it is ready:
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
The output displays the pod created:
|
||||
The output displays the pod created:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mongo-75f59d57f4-4nd6q 1/1 Running 0 2m4s
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mongo-75f59d57f4-4nd6q 1/1 Running 0 2m4s
|
||||
```
|
||||
|
||||
View the Deployment's status:
|
||||
View the Deployment's status:
|
||||
|
||||
```shell
|
||||
kubectl get deployment
|
||||
```
|
||||
```shell
|
||||
kubectl get deployment
|
||||
```
|
||||
|
||||
The output displays that the Deployment was created:
|
||||
The output displays that the Deployment was created:
|
||||
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
mongo 1/1 1 1 2m21s
|
||||
```
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
mongo 1/1 1 1 2m21s
|
||||
```
|
||||
|
||||
The Deployment automatically manages a ReplicaSet.
|
||||
View the ReplicaSet status using:
|
||||
The Deployment automatically manages a ReplicaSet.
|
||||
View the ReplicaSet status using:
|
||||
|
||||
```shell
|
||||
kubectl get replicaset
|
||||
```
|
||||
```shell
|
||||
kubectl get replicaset
|
||||
```
|
||||
|
||||
The output displays that the ReplicaSet was created:
|
||||
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
mongo-75f59d57f4 1 1 1 3m12s
|
||||
```
|
||||
The output displays that the ReplicaSet was created:
|
||||
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
mongo-75f59d57f4 1 1 1 3m12s
|
||||
```
|
||||
|
||||
2. Create a Service to expose MongoDB on the network:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
|
||||
```
|
||||
|
||||
The output of a successful command verifies that the Service was created:
|
||||
The output of a successful command verifies that the Service was created:
|
||||
|
||||
```
|
||||
service/mongo created
|
||||
```
|
||||
```
|
||||
service/mongo created
|
||||
```
|
||||
|
||||
Check the Service created:
|
||||
Check the Service created:
|
||||
|
||||
```shell
|
||||
kubectl get service mongo
|
||||
```
|
||||
```shell
|
||||
kubectl get service mongo
|
||||
```
|
||||
|
||||
The output displays the service created:
|
||||
The output displays the service created:
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
mongo ClusterIP 10.96.41.183 <none> 27017/TCP 11s
|
||||
```
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
mongo ClusterIP 10.96.41.183 <none> 27017/TCP 11s
|
||||
```
|
||||
|
||||
3. Verify that the MongoDB server is running in the Pod, and listening on port 27017:
|
||||
|
||||
```shell
|
||||
# Change mongo-75f59d57f4-4nd6q to the name of the Pod
|
||||
kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
|
||||
```
|
||||
```shell
|
||||
# Change mongo-75f59d57f4-4nd6q to the name of the Pod
|
||||
kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
|
||||
```
|
||||
|
||||
The output displays the port for MongoDB in that Pod:
|
||||
The output displays the port for MongoDB in that Pod:
|
||||
|
||||
```
|
||||
27017
|
||||
```
|
||||
```
|
||||
27017
|
||||
```
|
||||
|
||||
(this is the TCP port allocated to MongoDB on the internet).
|
||||
27017 is the TCP port allocated to MongoDB on the internet.
|
||||
|
||||
## Forward a local port to a port on the Pod
|
||||
|
||||
1. `kubectl port-forward` allows using resource name, such as a pod name, to select a matching pod to port forward to.
|
||||
1. `kubectl port-forward` allows using resource name, such as a pod name, to select a matching pod to port forward to.
|
||||
|
||||
|
||||
```shell
|
||||
# Change mongo-75f59d57f4-4nd6q to the name of the Pod
|
||||
kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017
|
||||
```
|
||||
```shell
|
||||
# Change mongo-75f59d57f4-4nd6q to the name of the Pod
|
||||
kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017
|
||||
```
|
||||
|
||||
which is the same as
|
||||
which is the same as
|
||||
|
||||
```shell
|
||||
kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017
|
||||
```
|
||||
```shell
|
||||
kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017
|
||||
```
|
||||
|
||||
or
|
||||
or
|
||||
|
||||
```shell
|
||||
kubectl port-forward deployment/mongo 28015:27017
|
||||
```
|
||||
```shell
|
||||
kubectl port-forward deployment/mongo 28015:27017
|
||||
```
|
||||
|
||||
or
|
||||
or
|
||||
|
||||
```shell
|
||||
kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017
|
||||
```
|
||||
```shell
|
||||
kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017
|
||||
```
|
||||
|
||||
or
|
||||
or
|
||||
|
||||
```shell
|
||||
kubectl port-forward service/mongo 28015:27017
|
||||
```
|
||||
```shell
|
||||
kubectl port-forward service/mongo 28015:27017
|
||||
```
|
||||
|
||||
Any of the above commands works. The output is similar to this:
|
||||
Any of the above commands works. The output is similar to this:
|
||||
|
||||
```
|
||||
Forwarding from 127.0.0.1:28015 -> 27017
|
||||
Forwarding from [::1]:28015 -> 27017
|
||||
```
|
||||
```
|
||||
Forwarding from 127.0.0.1:28015 -> 27017
|
||||
Forwarding from [::1]:28015 -> 27017
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
{{< note >}}
|
||||
`kubectl port-forward` does not return. To continue with the exercises, you will need to open another terminal.
|
||||
{{< /note >}}
|
||||
|
||||
`kubectl port-forward` does not return. To continue with the exercises, you will need to open another terminal.
|
||||
2. Start the MongoDB command line interface:
|
||||
|
||||
{{< /note >}}
|
||||
```shell
|
||||
mongosh --port 28015
|
||||
```
|
||||
|
||||
2. Start the MongoDB command line interface:
|
||||
3. At the MongoDB command line prompt, enter the `ping` command:
|
||||
|
||||
```shell
|
||||
mongosh --port 28015
|
||||
```
|
||||
```
|
||||
db.runCommand( { ping: 1 } )
|
||||
```
|
||||
|
||||
3. At the MongoDB command line prompt, enter the `ping` command:
|
||||
A successful ping request returns:
|
||||
|
||||
```
|
||||
db.runCommand( { ping: 1 } )
|
||||
```
|
||||
|
||||
A successful ping request returns:
|
||||
|
||||
```
|
||||
{ ok: 1 }
|
||||
```
|
||||
```
|
||||
{ ok: 1 }
|
||||
```
|
||||
|
||||
### Optionally let _kubectl_ choose the local port {#let-kubectl-choose-local-port}
|
||||
|
||||
@@ -204,7 +193,6 @@ Forwarding from 127.0.0.1:63753 -> 27017
|
||||
Forwarding from [::1]:63753 -> 27017
|
||||
```
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## Discussion
|
||||
@@ -219,9 +207,7 @@ The support for UDP protocol is tracked in
|
||||
[issue 47862](https://github.com/kubernetes/kubernetes/issues/47862).
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Learn more about [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward).
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Certificates
|
||||
title: Generate Certificates Manually
|
||||
content_type: task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
@@ -150,7 +150,7 @@ access to clients with the certificate `k8sclient.cert`.
|
||||
|
||||
Once etcd is configured correctly, only clients with valid certificates can
|
||||
access it. To give Kubernetes API servers the access, configure them with the
|
||||
flags `--etcd-certfile=k8sclient.cert`,`--etcd-keyfile=k8sclient.key` and
|
||||
flags `--etcd-certfile=k8sclient.cert`, `--etcd-keyfile=k8sclient.key` and
|
||||
`--etcd-cafile=ca.cert`.
|
||||
|
||||
{{< note >}}
|
||||
@@ -319,7 +319,7 @@ employed to recover the data of a failed cluster.
|
||||
|
||||
Before starting the restore operation, a snapshot file must be present. It can
|
||||
either be a snapshot file from a previous backup operation, or from a remaining
|
||||
[data directory]( https://etcd.io/docs/current/op-guide/configuration/#--data-dir).
|
||||
[data directory](https://etcd.io/docs/current/op-guide/configuration/#--data-dir).
|
||||
Here is an example:
|
||||
|
||||
```shell
|
||||
|
||||
@@ -88,8 +88,8 @@ Name | Encryption | Strength | Speed | Key Length | Other Considerations
|
||||
`identity` | None | N/A | N/A | N/A | Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written.
|
||||
`secretbox` | XSalsa20 and Poly1305 | Strong | Faster | 32-byte | A newer standard and may not be considered acceptable in environments that require high levels of review.
|
||||
`aesgcm` | AES-GCM with random nonce | Must be rotated every 200k writes | Fastest | 16, 24, or 32-byte | Is not recommended for use except when an automated key rotation scheme is implemented.
|
||||
`aescbc` | AES-CBC with PKCS#7 padding | Weak | Fast | 32-byte | Not recommended due to CBC's vulnerability to padding oracle attacks.
|
||||
`kms` | Uses envelope encryption scheme: Data is encrypted by data encryption keys (DEKs) using AES-CBC with PKCS#7 padding, DEKs are encrypted by key encryption keys (KEKs) according to configuration in Key Management Service (KMS) | Strongest | Fast | 32-bytes | The recommended choice for using a third party tool for key management. Simplifies key rotation, with a new DEK generated for each encryption, and KEK rotation controlled by the user. [Configure the KMS provider](/docs/tasks/administer-cluster/kms-provider/)
|
||||
`aescbc` | AES-CBC with [PKCS#7](https://datatracker.ietf.org/doc/html/rfc2315) padding | Weak | Fast | 32-byte | Not recommended due to CBC's vulnerability to padding oracle attacks.
|
||||
`kms` | Uses envelope encryption scheme: Data is encrypted by data encryption keys (DEKs) using AES-CBC with [PKCS#7](https://datatracker.ietf.org/doc/html/rfc2315) padding, DEKs are encrypted by key encryption keys (KEKs) according to configuration in Key Management Service (KMS) | Strongest | Fast | 32-bytes | The recommended choice for using a third party tool for key management. Simplifies key rotation, with a new DEK generated for each encryption, and KEK rotation controlled by the user. [Configure the KMS provider](/docs/tasks/administer-cluster/kms-provider/)
|
||||
|
||||
Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider
|
||||
is the first provider, the first key is used for encryption.
|
||||
|
||||
@@ -68,9 +68,7 @@ and passing it to the local node kubelet.
|
||||
|
||||
## Using the `cgroupfs` driver
|
||||
|
||||
As this guide explains using the `cgroupfs` driver with kubeadm is not recommended.
|
||||
|
||||
To continue using `cgroupfs` and to prevent `kubeadm upgrade` from modifying the
|
||||
To use `cgroupfs` and to prevent `kubeadm upgrade` from modifying the
|
||||
`KubeletConfiguration` cgroup driver on existing setups, you must be explicit
|
||||
about its value. This applies to a case where you do not wish future versions
|
||||
of kubeadm to apply the `systemd` driver by default.
|
||||
|
||||
@@ -276,7 +276,7 @@ By default, these serving certificate will expire after one year. Kubeadm sets t
|
||||
`KubeletConfiguration` field `rotateCertificates` to `true`, which means that close
|
||||
to expiration a new set of CSRs for the serving certificates will be created and must
|
||||
be approved to complete the rotation. To understand more see
|
||||
[Certificate Rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#certificate-rotation).
|
||||
[Certificate Rotation](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#certificate-rotation).
|
||||
|
||||
If you are looking for a solution for automatic approval of these CSRs it is recommended
|
||||
that you contact your cloud provider and ask if they have a CSR signer that verifies
|
||||
|
||||
@@ -29,7 +29,7 @@ The upgrade workflow at high level is the following:
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
- Make sure you read the [release notes]({{< latest-release-notes >}}) carefully.
|
||||
- Make sure you read the [release notes](https://git.k8s.io/kubernetes/CHANGELOG) carefully.
|
||||
- The cluster should use a static control plane and etcd pods or external etcd.
|
||||
- Make sure to back up any important components, such as app-level state stored in a database.
|
||||
`kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice.
|
||||
@@ -79,83 +79,87 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc
|
||||
|
||||
**For the first control plane node**
|
||||
|
||||
- Upgrade kubeadm:
|
||||
- Upgrade kubeadm:
|
||||
|
||||
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
|
||||
apt-mark unhold kubeadm && \
|
||||
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubeadm
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
<br />
|
||||
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
```shell
|
||||
# replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
|
||||
apt-mark unhold kubeadm && \
|
||||
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubeadm
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
```shell
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
<br />
|
||||
|
||||
- Verify that the download works and has the expected version:
|
||||
- Verify that the download works and has the expected version:
|
||||
|
||||
```shell
|
||||
kubeadm version
|
||||
```
|
||||
```shell
|
||||
kubeadm version
|
||||
```
|
||||
|
||||
- Verify the upgrade plan:
|
||||
- Verify the upgrade plan:
|
||||
|
||||
```shell
|
||||
kubeadm upgrade plan
|
||||
```
|
||||
```shell
|
||||
kubeadm upgrade plan
|
||||
```
|
||||
|
||||
This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to.
|
||||
It also shows a table with the component config version states.
|
||||
This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to.
|
||||
It also shows a table with the component config version states.
|
||||
|
||||
{{< note >}}
|
||||
`kubeadm upgrade` also automatically renews the certificates that it manages on this node.
|
||||
To opt-out of certificate renewal the flag `--certificate-renewal=false` can be used.
|
||||
For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs).
|
||||
{{</ note >}}
|
||||
{{< note >}}
|
||||
`kubeadm upgrade` also automatically renews the certificates that it manages on this node.
|
||||
To opt-out of certificate renewal the flag `--certificate-renewal=false` can be used.
|
||||
For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs).
|
||||
{{</ note >}}
|
||||
|
||||
{{< note >}}
|
||||
If `kubeadm upgrade plan` shows any component configs that require manual upgrade, users must provide
|
||||
a config file with replacement configs to `kubeadm upgrade apply` via the `--config` command line flag.
|
||||
Failing to do so will cause `kubeadm upgrade apply` to exit with an error and not perform an upgrade.
|
||||
{{</ note >}}
|
||||
|
||||
{{< note >}}
|
||||
If `kubeadm upgrade plan` shows any component configs that require manual upgrade, users must provide
|
||||
a config file with replacement configs to `kubeadm upgrade apply` via the `--config` command line flag.
|
||||
Failing to do so will cause `kubeadm upgrade apply` to exit with an error and not perform an upgrade.
|
||||
{{</ note >}}
|
||||
- Choose a version to upgrade to, and run the appropriate command. For example:
|
||||
|
||||
- Choose a version to upgrade to, and run the appropriate command. For example:
|
||||
```shell
|
||||
# replace x with the patch version you picked for this upgrade
|
||||
sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x
|
||||
```
|
||||
|
||||
```shell
|
||||
# replace x with the patch version you picked for this upgrade
|
||||
sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x
|
||||
```
|
||||
Once the command finishes you should see:
|
||||
|
||||
Once the command finishes you should see:
|
||||
```
|
||||
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy!
|
||||
|
||||
```
|
||||
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy!
|
||||
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
|
||||
```
|
||||
|
||||
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
|
||||
```
|
||||
- Manually upgrade your CNI provider plugin.
|
||||
|
||||
- Manually upgrade your CNI provider plugin.
|
||||
Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow.
|
||||
Check the [addons](/docs/concepts/cluster-administration/addons/) page to
|
||||
find your CNI provider and see whether additional upgrade steps are required.
|
||||
|
||||
Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow.
|
||||
Check the [addons](/docs/concepts/cluster-administration/addons/) page to
|
||||
find your CNI provider and see whether additional upgrade steps are required.
|
||||
|
||||
This step is not required on additional control plane nodes if the CNI provider runs as a DaemonSet.
|
||||
This step is not required on additional control plane nodes if the CNI provider runs as a DaemonSet.
|
||||
|
||||
**For the other control plane nodes**
|
||||
|
||||
Same as the first control plane node but use:
|
||||
|
||||
```
|
||||
```shell
|
||||
sudo kubeadm upgrade node
|
||||
```
|
||||
|
||||
instead of:
|
||||
|
||||
```
|
||||
```shell
|
||||
sudo kubeadm upgrade apply
|
||||
```
|
||||
|
||||
@@ -163,46 +167,50 @@ Also calling `kubeadm upgrade plan` and upgrading the CNI provider plugin is no
|
||||
|
||||
### Drain the node
|
||||
|
||||
- Prepare the node for maintenance by marking it unschedulable and evicting the workloads:
|
||||
- Prepare the node for maintenance by marking it unschedulable and evicting the workloads:
|
||||
|
||||
```shell
|
||||
# replace <node-to-drain> with the name of your node you are draining
|
||||
kubectl drain <node-to-drain> --ignore-daemonsets
|
||||
```
|
||||
```shell
|
||||
# replace <node-to-drain> with the name of your node you are draining
|
||||
kubectl drain <node-to-drain> --ignore-daemonsets
|
||||
```
|
||||
|
||||
### Upgrade kubelet and kubectl
|
||||
|
||||
- Upgrade the kubelet and kubectl:
|
||||
- Upgrade the kubelet and kubectl:
|
||||
|
||||
{{< tabs name="k8s_install_kubelet" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
|
||||
apt-mark unhold kubelet kubectl && \
|
||||
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubelet kubectl
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
<br />
|
||||
{{< tabs name="k8s_install_kubelet" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
```shell
|
||||
# replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
|
||||
apt-mark unhold kubelet kubectl && \
|
||||
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubelet kubectl
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
```shell
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
<br />
|
||||
|
||||
- Restart the kubelet:
|
||||
- Restart the kubelet:
|
||||
|
||||
```shell
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart kubelet
|
||||
```
|
||||
```shell
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart kubelet
|
||||
```
|
||||
|
||||
### Uncordon the node
|
||||
|
||||
- Bring the node back online by marking it schedulable:
|
||||
- Bring the node back online by marking it schedulable:
|
||||
|
||||
```shell
|
||||
# replace <node-to-drain> with the name of your node
|
||||
kubectl uncordon <node-to-drain>
|
||||
```
|
||||
```shell
|
||||
# replace <node-to-drain> with the name of your node
|
||||
kubectl uncordon <node-to-drain>
|
||||
```
|
||||
|
||||
## Upgrade worker nodes
|
||||
|
||||
@@ -211,76 +219,83 @@ without compromising the minimum required capacity for running your workloads.
|
||||
|
||||
### Upgrade kubeadm
|
||||
|
||||
- Upgrade kubeadm:
|
||||
- Upgrade kubeadm:
|
||||
|
||||
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
|
||||
apt-mark unhold kubeadm && \
|
||||
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubeadm
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
```shell
|
||||
# replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
|
||||
apt-mark unhold kubeadm && \
|
||||
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubeadm
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
```shell
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
### Call "kubeadm upgrade"
|
||||
|
||||
- For worker nodes this upgrades the local kubelet configuration:
|
||||
- For worker nodes this upgrades the local kubelet configuration:
|
||||
|
||||
```shell
|
||||
sudo kubeadm upgrade node
|
||||
```
|
||||
```shell
|
||||
sudo kubeadm upgrade node
|
||||
```
|
||||
|
||||
### Drain the node
|
||||
|
||||
- Prepare the node for maintenance by marking it unschedulable and evicting the workloads:
|
||||
- Prepare the node for maintenance by marking it unschedulable and evicting the workloads:
|
||||
|
||||
```shell
|
||||
# replace <node-to-drain> with the name of your node you are draining
|
||||
kubectl drain <node-to-drain> --ignore-daemonsets
|
||||
```
|
||||
```shell
|
||||
# replace <node-to-drain> with the name of your node you are draining
|
||||
kubectl drain <node-to-drain> --ignore-daemonsets
|
||||
```
|
||||
|
||||
### Upgrade kubelet and kubectl
|
||||
|
||||
- Upgrade the kubelet and kubectl:
|
||||
- Upgrade the kubelet and kubectl:
|
||||
|
||||
{{< tabs name="k8s_kubelet_and_kubectl" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
|
||||
apt-mark unhold kubelet kubectl && \
|
||||
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubelet kubectl
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
<br />
|
||||
{{< tabs name="k8s_kubelet_and_kubectl" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
```shell
|
||||
# replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
|
||||
apt-mark unhold kubelet kubectl && \
|
||||
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubelet kubectl
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
```shell
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
<br />
|
||||
|
||||
- Restart the kubelet:
|
||||
- Restart the kubelet:
|
||||
|
||||
```shell
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart kubelet
|
||||
```
|
||||
```shell
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart kubelet
|
||||
```
|
||||
|
||||
### Uncordon the node
|
||||
|
||||
- Bring the node back online by marking it schedulable:
|
||||
- Bring the node back online by marking it schedulable:
|
||||
|
||||
```shell
|
||||
# replace <node-to-drain> with the name of your node
|
||||
kubectl uncordon <node-to-drain>
|
||||
```
|
||||
```shell
|
||||
# replace <node-to-drain> with the name of your node
|
||||
kubectl uncordon <node-to-drain>
|
||||
```
|
||||
|
||||
## Verify the status of the cluster
|
||||
|
||||
After the kubelet is upgraded on all nodes verify that all nodes are available again by running the following command
|
||||
from anywhere kubectl can access the cluster:
|
||||
After the kubelet is upgraded on all nodes verify that all nodes are available again by running
|
||||
the following command from anywhere kubectl can access the cluster:
|
||||
|
||||
```shell
|
||||
kubectl get nodes
|
||||
@@ -296,6 +311,7 @@ This command is idempotent and eventually makes sure that the actual state is th
|
||||
To recover from a bad state, you can also run `kubeadm upgrade apply --force` without changing the version that your cluster is running.
|
||||
|
||||
During upgrade kubeadm writes the following backup folders under `/etc/kubernetes/tmp`:
|
||||
|
||||
- `kubeadm-backup-etcd-<date>-<time>`
|
||||
- `kubeadm-backup-manifests-<date>-<time>`
|
||||
|
||||
@@ -334,3 +350,4 @@ and post-upgrade manifest file for a certain component, a backup file for it wil
|
||||
|
||||
- Fetches the kubeadm `ClusterConfiguration` from the cluster.
|
||||
- Upgrades the kubelet configuration for this node.
|
||||
|
||||
|
||||
+7
-4
@@ -27,7 +27,7 @@ in the namespace.
|
||||
|
||||
You must have access to create namespaces in your cluster.
|
||||
|
||||
Your cluster must have at least 1.0 CPU available for use to run the task examples.
|
||||
Each node in your cluster must have at least 1.0 CPU available for Pods.
|
||||
See [meaning of CPU](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu)
|
||||
to learn what Kubernetes means by “1 CPU”.
|
||||
|
||||
@@ -45,7 +45,7 @@ kubectl create namespace constraints-cpu-example
|
||||
|
||||
## Create a LimitRange and a Pod
|
||||
|
||||
Here's an example manifest for a LimitRange:
|
||||
Here's a manifest for an example {{< glossary_tooltip text="LimitRange" term_id="limitrange" >}}:
|
||||
|
||||
{{< codenew file="admin/resource/cpu-constraints.yaml" >}}
|
||||
|
||||
@@ -96,7 +96,7 @@ on these resources, the two values must be the same.
|
||||
|
||||
Here's a manifest for a Pod that has one container. The container manifest
|
||||
specifies a CPU request of 500 millicpu and a CPU limit of 800 millicpu. These satisfy the
|
||||
minimum and maximum CPU constraints imposed by the LimitRange.
|
||||
minimum and maximum CPU constraints imposed by the LimitRange for this namespace.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-constraints-pod.yaml" >}}
|
||||
|
||||
@@ -214,7 +214,10 @@ applied the
|
||||
[default CPU request and limit](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
|
||||
from the LimitRange for this namespace.
|
||||
|
||||
At this point, your Pod might be running or it might not be running. Recall that a prerequisite for this task is that your cluster must have at least 1 CPU available for use. If each of your Nodes has only 1 CPU, then there might not be enough allocatable CPU on any Node to accommodate a request of 800 millicpu. If you happen to be using Nodes with 2 CPU, then you probably have enough CPU to accommodate the 800 millicpu request.
|
||||
At this point, your Pod may or may not be running. Recall that a prerequisite for
|
||||
this task is that your Nodes must have at least 1 CPU available for use. If each of your Nodes has only 1 CPU,
|
||||
then there might not be enough allocatable CPU on any Node to accommodate a request of 800 millicpu.
|
||||
If you happen to be using Nodes with 2 CPU, then you probably have enough CPU to accommodate the 800 millicpu request.
|
||||
|
||||
Delete your Pod:
|
||||
|
||||
|
||||
+5
-4
@@ -11,8 +11,9 @@ description: >-
|
||||
<!-- overview -->
|
||||
|
||||
This page shows how to set minimum and maximum values for memory used by containers
|
||||
running in a namespace. You specify minimum and maximum memory values in a
|
||||
[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
|
||||
running in a {{< glossary_tooltip text="namespace" term_id="namespace" >}}.
|
||||
You specify minimum and maximum memory values in a
|
||||
[LimitRange](/docs/reference/kubernetes-api/policy-resources/limit-range-v1/)
|
||||
object. If a Pod does not meet the constraints imposed by the LimitRange,
|
||||
it cannot be created in the namespace.
|
||||
|
||||
@@ -76,8 +77,8 @@ file for the LimitRange, they were created automatically.
|
||||
Now whenever you define a Pod within the constraints-mem-example namespace, Kubernetes
|
||||
performs these steps:
|
||||
|
||||
* If any container in that Pod does not specify its own memory request and limit, assign
|
||||
the default memory request and limit to that container.
|
||||
* If any container in that Pod does not specify its own memory request and limit,
|
||||
the control plane assigns the default memory request and limit to that container.
|
||||
|
||||
* Verify that every container in that Pod requests at least 500 MiB of memory.
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ installations. Our [Dockershim Removal FAQ](/blog/2022/02/17/dockershim-faq/) is
|
||||
to understand the problem better.
|
||||
|
||||
Dockershim was removed from Kubernetes with the release of v1.24.
|
||||
If you use Docker via dockershim as your container runtime, and wish to upgrade to v1.24,
|
||||
If you use Docker Engine via dockershim as your container runtime, and wish to upgrade to v1.24,
|
||||
it is recommended that you either migrate to another runtime or find an alternative means to obtain Docker Engine support.
|
||||
Check out [container runtimes](/docs/setup/production-environment/container-runtimes/)
|
||||
section to know your options. Make sure to
|
||||
@@ -30,7 +30,7 @@ configuration.
|
||||
These tasks will help you to migrate:
|
||||
|
||||
* [Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
|
||||
* [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/)
|
||||
* [Migrate Docker Engine nodes from dockershim to cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/)
|
||||
* [Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)
|
||||
|
||||
|
||||
|
||||
+1
-1
@@ -44,7 +44,7 @@ for detailed steps to install containerd.
|
||||
1. Install the `containerd.io` package from the official Docker repositories.
|
||||
Instructions for setting up the Docker repository for your respective Linux distribution and
|
||||
installing the `containerd.io` package can be found at
|
||||
[Install Docker Engine](https://docs.docker.com/engine/install/#server).
|
||||
[Getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md).
|
||||
|
||||
1. Configure containerd:
|
||||
|
||||
|
||||
+5
-4
@@ -41,7 +41,7 @@ node-2 Ready v1.16.15 docker://19.3.1
|
||||
node-3 Ready v1.16.15 docker://19.3.1
|
||||
```
|
||||
If your runtime shows as Docker Engine, you still might not be affected by the
|
||||
removal of dockershim in Kubernetes 1.24. [Check the runtime
|
||||
removal of dockershim in Kubernetes v1.24. [Check the runtime
|
||||
endpoint](#which-endpoint) to see if you use dockershim. If you don't use
|
||||
dockershim, you aren't affected.
|
||||
|
||||
@@ -64,7 +64,7 @@ The container runtime talks to the kubelet over a Unix socket using the [CRI
|
||||
protocol](/docs/concepts/architecture/cri/), which is based on the gRPC
|
||||
framework. The kubelet acts as a client, and the runtime acts as the server.
|
||||
In some cases, you might find it useful to know which socket your nodes use. For
|
||||
example, with the removal of dockershim in Kubernetes 1.24 and later, you might
|
||||
example, with the removal of dockershim in Kubernetes v1.24 and later, you might
|
||||
want to know whether you use Docker Engine with dockershim.
|
||||
|
||||
{{<note>}}
|
||||
@@ -93,6 +93,7 @@ nodes.
|
||||
name to find out which runtime you use. For example,
|
||||
`unix:///run/containerd/containerd.sock` is the containerd endpoint.
|
||||
|
||||
If you use Docker Engine with the dockershim, [migrate to a different runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/),
|
||||
or, if you want to continue using Docker Engine in v1.24 and later, migrate to a
|
||||
If you want to change the Container Runtime on a Node from Docker Engine to containerd,
|
||||
you can find out more information on [migrating from Docker Engine to containerd](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/),
|
||||
or, if you want to continue using Docker Engine in Kubernetes v1.24 and later, migrate to a
|
||||
CRI-compatible adapter like [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd).
|
||||
@@ -71,7 +71,7 @@ to define *Hard* resource usage limits that a *Namespace* may consume.
|
||||
A limit range defines min/max constraints on the amount of resources a single entity can consume in
|
||||
a *Namespace*.
|
||||
|
||||
See [Admission control: Limit Range](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)
|
||||
See [Admission control: Limit Range](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)
|
||||
|
||||
A namespace can be in one of two phases:
|
||||
|
||||
@@ -112,7 +112,7 @@ The name of your namespace must be a valid
|
||||
|
||||
There's an optional field `finalizers`, which allows observables to purge resources whenever the namespace is deleted. Keep in mind that if you specify a nonexistent finalizer, the namespace will be created but will get stuck in the `Terminating` state if the user tries to delete it.
|
||||
|
||||
More information on `finalizers` can be found in the namespace [design doc](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers).
|
||||
More information on `finalizers` can be found in the namespace [design doc](https://git.k8s.io/design-proposals-archive/architecture/namespaces.md#finalizers).
|
||||
|
||||
## Deleting a namespace
|
||||
|
||||
@@ -314,7 +314,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
|
||||
|
||||
* Learn more about [setting the namespace preference](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference).
|
||||
* Learn more about [setting the namespace for a request](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request)
|
||||
* See [namespaces design](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/namespaces.md).
|
||||
* See [namespaces design](https://git.k8s.io/design-proposals-archive/architecture/namespaces.md).
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -89,7 +89,7 @@ kubectl get persistentvolumeclaims --namespace=quota-object-example
|
||||
|
||||
The output shows that the PersistentVolumeClaim exists and has status Pending:
|
||||
|
||||
```shell
|
||||
```
|
||||
NAME STATUS
|
||||
pvc-quota-demo Pending
|
||||
```
|
||||
|
||||
@@ -13,15 +13,10 @@ content_type: task
|
||||
This document covers topics related to protecting a cluster from accidental or malicious access
|
||||
and provides recommendations on overall security.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Controlling access to the Kubernetes API
|
||||
@@ -77,11 +72,13 @@ Consult the [authorization reference section](/docs/reference/access-authn-authz
|
||||
|
||||
## Controlling access to the Kubelet
|
||||
|
||||
Kubelets expose HTTPS endpoints which grant powerful control over the node and containers. By default Kubelets allow unauthenticated access to this API.
|
||||
Kubelets expose HTTPS endpoints which grant powerful control over the node and containers.
|
||||
By default Kubelets allow unauthenticated access to this API.
|
||||
|
||||
Production clusters should enable Kubelet authentication and authorization.
|
||||
|
||||
Consult the [Kubelet authentication/authorization reference](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization) for more information.
|
||||
Consult the [Kubelet authentication/authorization reference](/docs/reference/access-authn-authz/kubelet-authn-authz/)
|
||||
for more information.
|
||||
|
||||
## Controlling the capabilities of a workload or user at runtime
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ An increasing number of systems leverage a combination of CPUs and hardware acce
|
||||
|
||||
In order to extract the best performance, optimizations related to CPU isolation, memory and device locality are required. However, in Kubernetes, these optimizations are handled by a disjoint set of components.
|
||||
|
||||
_Topology Manager_ is a Kubelet component that aims to co-ordinate the set of components that are responsible for these optimizations.
|
||||
_Topology Manager_ is a Kubelet component that aims to coordinate the set of components that are responsible for these optimizations.
|
||||
|
||||
|
||||
|
||||
@@ -267,4 +267,4 @@ Using this information the Topology Manager calculates the optimal hint for the
|
||||
### Known Limitations
|
||||
1. The maximum number of NUMA nodes that Topology Manager allows is 8. With more than 8 NUMA nodes there will be a state explosion when trying to enumerate the possible NUMA affinities and generating their hints.
|
||||
|
||||
2. The scheduler is not topology-aware, so it is possible to be scheduled on a node and then fail on the node due to the Topology Manager.
|
||||
2. The scheduler is not topology-aware, so it is possible to be scheduled on a node and then fail on the node due to the Topology Manager.
|
||||
|
||||
@@ -171,7 +171,7 @@ kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example
|
||||
|
||||
The output shows that the Container was killed because it is out of memory (OOM):
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
lastState:
|
||||
terminated:
|
||||
containerID: 65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
|
||||
@@ -278,7 +278,7 @@ kubectl describe pod memory-demo-3 --namespace=mem-example
|
||||
|
||||
The output shows that the Container cannot be scheduled because of insufficient memory on the Nodes:
|
||||
|
||||
```shell
|
||||
```
|
||||
Events:
|
||||
... Reason Message
|
||||
------ -------
|
||||
@@ -291,8 +291,8 @@ The memory resource is measured in bytes. You can express memory as a plain inte
|
||||
fixed-point integer with one of these suffixes: E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki.
|
||||
For example, the following represent approximately the same value:
|
||||
|
||||
```shell
|
||||
128974848, 129e6, 129M , 123Mi
|
||||
```
|
||||
128974848, 129e6, 129M, 123Mi
|
||||
```
|
||||
|
||||
Delete your Pod:
|
||||
|
||||
+1
-1
@@ -282,7 +282,7 @@ PersistentVolume are not present on the Pod resource itself.
|
||||
|
||||
|
||||
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
|
||||
* Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md).
|
||||
* Read the [Persistent Storage design document](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md).
|
||||
|
||||
### Reference
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ card:
|
||||
<!-- overview -->
|
||||
Many applications rely on configuration which is used during either application initialization or runtime.
|
||||
Most of the times there is a requirement to adjust values assigned to configuration parameters.
|
||||
ConfigMaps is the kubernetes way to inject application pods with configuration data.
|
||||
ConfigMaps is the kubernetes way to inject application pods with configuration data.
|
||||
ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps.
|
||||
|
||||
|
||||
@@ -461,35 +461,35 @@ configmap/special-config-2-c92b5mmcf2 created
|
||||
|
||||
### Define a container environment variable with data from a single ConfigMap
|
||||
|
||||
1. Define an environment variable as a key-value pair in a ConfigMap:
|
||||
1. Define an environment variable as a key-value pair in a ConfigMap:
|
||||
|
||||
```shell
|
||||
kubectl create configmap special-config --from-literal=special.how=very
|
||||
```
|
||||
```shell
|
||||
kubectl create configmap special-config --from-literal=special.how=very
|
||||
```
|
||||
|
||||
2. Assign the `special.how` value defined in the ConfigMap to the `SPECIAL_LEVEL_KEY` environment variable in the Pod specification.
|
||||
2. Assign the `special.how` value defined in the ConfigMap to the `SPECIAL_LEVEL_KEY` environment variable in the Pod specification.
|
||||
|
||||
{{< codenew file="pods/pod-single-configmap-env-variable.yaml" >}}
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml
|
||||
```
|
||||
|
||||
Now, the Pod's output includes environment variable `SPECIAL_LEVEL_KEY=very`.
|
||||
|
||||
### Define container environment variables with data from multiple ConfigMaps
|
||||
|
||||
* As with the previous example, create the ConfigMaps first.
|
||||
* As with the previous example, create the ConfigMaps first.
|
||||
|
||||
{{< codenew file="configmap/configmaps.yaml" >}}
|
||||
{{< codenew file="configmap/configmaps.yaml" >}}
|
||||
|
||||
Create the ConfigMap:
|
||||
Create the ConfigMap:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml
|
||||
```
|
||||
|
||||
* Define the environment variables in the Pod specification.
|
||||
|
||||
@@ -497,9 +497,9 @@ configmap/special-config-2-c92b5mmcf2 created
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml
|
||||
```
|
||||
|
||||
Now, the Pod's output includes environment variables `SPECIAL_LEVEL_KEY=very` and `LOG_LEVEL=INFO`.
|
||||
|
||||
@@ -515,21 +515,21 @@ This functionality is available in Kubernetes v1.6 and later.
|
||||
|
||||
Create the ConfigMap:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
|
||||
```
|
||||
|
||||
* Use `envFrom` to define all of the ConfigMap's data as container environment variables. The key from the ConfigMap becomes the environment variable name in the Pod.
|
||||
|
||||
{{< codenew file="pods/pod-configmap-envFrom.yaml" >}}
|
||||
{{< codenew file="pods/pod-configmap-envFrom.yaml" >}}
|
||||
|
||||
Create the Pod:
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml
|
||||
```
|
||||
|
||||
Now, the Pod's output includes environment variables `SPECIAL_LEVEL=very` and `SPECIAL_TYPE=charm`.
|
||||
Now, the Pod's output includes environment variables `SPECIAL_LEVEL=very` and `SPECIAL_TYPE=charm`.
|
||||
|
||||
|
||||
## Use ConfigMap-defined environment variables in Pod commands
|
||||
@@ -548,7 +548,7 @@ kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-env-var-valu
|
||||
|
||||
produces the following output in the `test-container` container:
|
||||
|
||||
```shell
|
||||
```
|
||||
very charm
|
||||
```
|
||||
|
||||
@@ -582,7 +582,7 @@ kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml
|
||||
|
||||
When the pod runs, the command `ls /etc/config/` produces the output below:
|
||||
|
||||
```shell
|
||||
```
|
||||
SPECIAL_LEVEL
|
||||
SPECIAL_TYPE
|
||||
```
|
||||
@@ -610,7 +610,7 @@ kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-speci
|
||||
|
||||
When the pod runs, the command `cat /etc/config/keys` produces the output below:
|
||||
|
||||
```shell
|
||||
```
|
||||
very
|
||||
```
|
||||
|
||||
@@ -680,15 +680,15 @@ data:
|
||||
|
||||
- If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example:
|
||||
|
||||
```shell
|
||||
kubectl get events
|
||||
```
|
||||
```shell
|
||||
kubectl get events
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
```
|
||||
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
|
||||
0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.
|
||||
```
|
||||
The output is similar to this:
|
||||
```
|
||||
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
|
||||
0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.
|
||||
```
|
||||
|
||||
- ConfigMaps reside in a specific {{< glossary_tooltip term_id="namespace" >}}. A ConfigMap can only be referenced by pods residing in the same namespace.
|
||||
|
||||
@@ -699,4 +699,3 @@ data:
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Follow a real world example of [Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/).
|
||||
|
||||
|
||||
@@ -83,5 +83,5 @@ kubectl delete secret user pass
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Learn more about [`projected`](/docs/concepts/storage/volumes/#projected) volumes.
|
||||
* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md) design document.
|
||||
* Read the [all-in-one volume](https://git.k8s.io/design-proposals-archive/node/all-in-one-volume.md) design document.
|
||||
|
||||
|
||||
@@ -57,7 +57,7 @@ echo $env:USERNAME
|
||||
|
||||
The output should be:
|
||||
|
||||
```shell
|
||||
```
|
||||
ContainerUser
|
||||
```
|
||||
|
||||
@@ -97,7 +97,7 @@ echo $env:USERNAME
|
||||
|
||||
The output should be:
|
||||
|
||||
```shell
|
||||
```
|
||||
ContainerAdministrator
|
||||
```
|
||||
|
||||
@@ -120,7 +120,7 @@ For more information about these limtations, check [here](https://support.micros
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [Guide for scheduling Windows containers in Kubernetes](/docs/setup/production-environment/windows/user-guide-windows-containers/)
|
||||
* [Managing Workload Identity with Group Managed Service Accounts (GMSA)](/docs/setup/production-environment/windows/user-guide-windows-containers/#managing-workload-identity-with-group-managed-service-accounts)
|
||||
* [Guide for scheduling Windows containers in Kubernetes](/docs/concepts/windows/user-guide/)
|
||||
* [Managing Workload Identity with Group Managed Service Accounts (GMSA)](/docs/concepts/windows/user-guide/#managing-workload-identity-with-group-managed-service-accounts)
|
||||
* [Configure GMSA for Windows pods and containers](/docs/tasks/configure-pod-container/configure-gmsa/)
|
||||
|
||||
|
||||
@@ -42,7 +42,7 @@ You can access the API from inside a pod using automatically mounted service acc
|
||||
The API permissions of the service account depend on the
|
||||
[authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use.
|
||||
|
||||
In version 1.6+, you can opt out of automounting API credentials for a service account by setting `automountServiceAccountToken: false` on the service account:
|
||||
You can opt out of automounting API credentials on `/var/run/secrets/kubernetes.io/serviceaccount/token` for a service account by setting `automountServiceAccountToken: false` on the ServiceAccount:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
||||
@@ -214,3 +214,10 @@ container, aiming to limit the degree of privileges so as to avoid accidental (o
|
||||
malicious) damage to the host. The LocalSystem service account has the highest level
|
||||
of privilege of the three and should be used only if absolutely necessary. Where possible,
|
||||
use the LocalService service account as it is the least privileged of the three options.
|
||||
|
||||
## Troubleshooting HostProcess containers
|
||||
|
||||
- HostProcess containers fail to start with `failed to create user process token: failed to logon user: Access is denied.: unknown`
|
||||
|
||||
Ensure containerd is running as `LocalSystem` or `LocalService` service accounts. User accounts (even Administrator accounts) do not have permissions to create logon tokens for any of the supported [user accounts](#choosing-a-user-account).
|
||||
|
||||
@@ -452,7 +452,7 @@ applied to Volumes as follows:
|
||||
|
||||
* `fsGroup`: Volumes that support ownership management are modified to be owned
|
||||
and writable by the GID specified in `fsGroup`. See the
|
||||
[Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
|
||||
[Ownership Management design document](https://git.k8s.io/design-proposals-archive/storage/volume-ownership-management.md)
|
||||
for more details.
|
||||
|
||||
* `seLinuxOptions`: Volumes that support SELinux labeling are relabeled to be accessible
|
||||
@@ -482,10 +482,10 @@ kubectl delete pod security-context-demo-4
|
||||
* [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)
|
||||
* [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
|
||||
* [Tuning Docker with the newest security enhancements](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
|
||||
* [Security Contexts design document](https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md)
|
||||
* [Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
|
||||
* [Security Contexts design document](https://git.k8s.io/design-proposals-archive/auth/security_context.md)
|
||||
* [Ownership Management design document](https://git.k8s.io/design-proposals-archive/storage/volume-ownership-management.md)
|
||||
* [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/)
|
||||
* [AllowPrivilegeEscalation design
|
||||
document](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md)
|
||||
document](https://git.k8s.io/design-proposals-archive/auth/no-new-privs.md)
|
||||
* For more information about security mechanisms in Linux, see
|
||||
[Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features) (Note: Some information is out of date)
|
||||
|
||||
@@ -156,5 +156,5 @@ to make sure that your `Service` is running, has `Endpoints`, and your `Pods` ar
|
||||
actually serving; you have DNS working, iptables rules installed, and kube-proxy
|
||||
does not seem to be misbehaving.
|
||||
|
||||
You may also visit [troubleshooting document](/docs/tasks/debug/overview/) for more information.
|
||||
You may also visit [troubleshooting document](/docs/tasks/debug/) for more information.
|
||||
|
||||
|
||||
@@ -728,13 +728,13 @@ Service is not working. Please let us know what is going on, so we can help
|
||||
investigate!
|
||||
|
||||
Contact us on
|
||||
[Slack](/docs/tasks/debug/overview/#slack) or
|
||||
[Slack](https://slack.k8s.io/) or
|
||||
[Forum](https://discuss.kubernetes.io) or
|
||||
[GitHub](https://github.com/kubernetes/kubernetes).
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Visit the [troubleshooting overview document](/docs/tasks/debug/overview/)
|
||||
Visit the [troubleshooting overview document](/docs/tasks/debug/)
|
||||
for more information.
|
||||
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ This document describes using `telepresence` to develop and debug services runni
|
||||
|
||||
## Connecting your local machine to a remote Kubernetes cluster
|
||||
|
||||
After installing `telepresence`, run `telepresence connect` to launch it's Daemon and connect your local workstation to the cluster.
|
||||
After installing `telepresence`, run `telepresence connect` to launch its Daemon and connect your local workstation to the cluster.
|
||||
|
||||
```
|
||||
$ telepresence connect
|
||||
|
||||
@@ -173,7 +173,7 @@ repository. You must enable the [API aggregation layer](/docs/tasks/extend-kuber
|
||||
and register an [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/)
|
||||
for the `metrics.k8s.io` API.
|
||||
|
||||
To learn more about the Metrics API, see [resource metrics API design](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/resource-metrics-api.md),
|
||||
To learn more about the Metrics API, see [resource metrics API design](https://git.k8s.io/design-proposals-archive/instrumentation/resource-metrics-api.md),
|
||||
the [metrics-server repository](https://github.com/kubernetes-sigs/metrics-server) and the
|
||||
[resource metrics API](https://github.com/kubernetes/metrics#resource-metrics-api).
|
||||
|
||||
@@ -237,7 +237,7 @@ To learn more about the metrics-server, see the
|
||||
|
||||
You can also check out the following:
|
||||
|
||||
* [metrics-server design](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)
|
||||
* [metrics-server design](https://git.k8s.io/design-proposals-archive/instrumentation/metrics-server.md)
|
||||
* [metrics-server FAQ](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md)
|
||||
* [metrics-server known issues](https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md)
|
||||
* [metrics-server releases](https://github.com/kubernetes-sigs/metrics-server/releases)
|
||||
|
||||
@@ -0,0 +1,170 @@
|
||||
---
|
||||
reviewers:
|
||||
- aravindhp
|
||||
- jayunit100
|
||||
- jsturtevant
|
||||
- marosset
|
||||
title: Windows debugging tips
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Node-level troubleshooting {#troubleshooting-node}
|
||||
|
||||
1. My Pods are stuck at "Container Creating" or restarting over and over
|
||||
|
||||
Ensure that your pause image is compatible with your Windows OS version.
|
||||
See [Pause container](/docs/setup/production-environment/windows/intro-windows-in-kubernetes#pause-container)
|
||||
to see the latest / recommended pause image and/or get more information.
|
||||
|
||||
{{< note >}}
|
||||
If using containerd as your container runtime the pause image is specified in the
|
||||
`plugins.plugins.cri.sandbox_image` field of the of config.toml configration file.
|
||||
{{< /note >}}
|
||||
|
||||
1. My pods show status as `ErrImgPull` or `ImagePullBackOff`
|
||||
|
||||
Ensure that your Pod is getting scheduled to a [compatable](https://docs.microsoft.com/virtualization/windowscontainers/deploy-containers/version-compatibility) Windows Node.
|
||||
|
||||
More information on how to specify a compatable node for your Pod can be found in [this guide](/docs/setup/production-environment/windows/user-guide-windows-containers/#ensuring-os-specific-workloads-land-on-the-appropriate-container-host).
|
||||
|
||||
## Network troubleshooting {#troubleshooting-network}
|
||||
|
||||
1. My Windows Pods do not have network connectivity
|
||||
|
||||
If you are using virtual machines, ensure that MAC spoofing is **enabled** on all
|
||||
the VM network adapter(s).
|
||||
|
||||
1. My Windows Pods cannot ping external resources
|
||||
|
||||
Windows Pods do not have outbound rules programmed for the ICMP protocol. However,
|
||||
TCP/UDP is supported. When trying to demonstrate connectivity to resources
|
||||
outside of the cluster, substitute `ping <IP>` with corresponding
|
||||
`curl <IP>` commands.
|
||||
|
||||
If you are still facing problems, most likely your network configuration in
|
||||
[cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)
|
||||
deserves some extra attention. You can always edit this static file. The
|
||||
configuration update will apply to any new Kubernetes resources.
|
||||
|
||||
One of the Kubernetes networking requirements
|
||||
(see [Kubernetes model](/docs/concepts/cluster-administration/networking/)) is
|
||||
for cluster communication to occur without
|
||||
NAT internally. To honor this requirement, there is an
|
||||
[ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20)
|
||||
for all the communication where you do not want outbound NAT to occur. However,
|
||||
this also means that you need to exclude the external IP you are trying to query
|
||||
from the `ExceptionList`. Only then will the traffic originating from your Windows
|
||||
pods be SNAT'ed correctly to receive a response from the outside world. In this
|
||||
regard, your `ExceptionList` in `cni.conf` should look as follows:
|
||||
|
||||
```conf
|
||||
"ExceptionList": [
|
||||
"10.244.0.0/16", # Cluster subnet
|
||||
"10.96.0.0/12", # Service subnet
|
||||
"10.127.130.0/24" # Management (host) subnet
|
||||
]
|
||||
```
|
||||
|
||||
1. My Windows node cannot access `NodePort` type Services
|
||||
|
||||
Local NodePort access from the node itself fails. This is a known
|
||||
limitation. NodePort access works from other nodes or external clients.
|
||||
|
||||
1. vNICs and HNS endpoints of containers are being deleted
|
||||
|
||||
This issue can be caused when the `hostname-override` parameter is not passed to
|
||||
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/). To resolve
|
||||
it, users need to pass the hostname to kube-proxy as follows:
|
||||
|
||||
```powershell
|
||||
C:\k\kube-proxy.exe --hostname-override=$(hostname)
|
||||
```
|
||||
|
||||
1. My Windows node cannot access my services using the service IP
|
||||
|
||||
This is a known limitation of the networking stack on Windows. However, Windows Pods can access the Service IP.
|
||||
|
||||
1. No network adapter is found when starting the kubelet
|
||||
|
||||
The Windows networking stack needs a virtual adapter for Kubernetes networking to work.
|
||||
If the following commands return no results (in an admin shell),
|
||||
virtual network creation — a necessary prerequisite for the kubelet to work — has failed:
|
||||
|
||||
```powershell
|
||||
Get-HnsNetwork | ? Name -ieq "cbr0"
|
||||
Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
|
||||
```
|
||||
|
||||
Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) parameter of the `start.ps1` script,
|
||||
in cases where the host's network adapter isn't "Ethernet".
|
||||
Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation.
|
||||
|
||||
1. DNS resolution is not properly working
|
||||
|
||||
Check the DNS limitations for Windows in this [section](#dns-limitations).
|
||||
|
||||
1. `kubectl port-forward` fails with "unable to do port forwarding: wincat not found"
|
||||
|
||||
This was implemented in Kubernetes 1.15 by including `wincat.exe` in the pause infrastructure container `mcr.microsoft.com/oss/kubernetes/pause:3.6`.
|
||||
Be sure to use a supported version of Kubernetes.
|
||||
If you would like to build your own pause infrastructure container be sure to include [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat).
|
||||
|
||||
1. My Kubernetes installation is failing because my Windows Server node is behind a proxy
|
||||
|
||||
If you are behind a proxy, the following PowerShell environment variables must be defined:
|
||||
|
||||
```PowerShell
|
||||
[Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
|
||||
[Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
|
||||
```
|
||||
|
||||
### Flannel troubleshooting
|
||||
|
||||
1. With Flannel, my nodes are having issues after rejoining a cluster
|
||||
|
||||
Whenever a previously deleted node is being re-joined to the cluster, flannelD
|
||||
tries to assign a new pod subnet to the node. Users should remove the old pod
|
||||
subnet configuration files in the following paths:
|
||||
|
||||
```powershell
|
||||
Remove-Item C:\k\SourceVip.json
|
||||
Remove-Item C:\k\SourceVipRequest.json
|
||||
```
|
||||
|
||||
1. Flanneld is stuck in "Waiting for the Network to be created"
|
||||
|
||||
There are numerous reports of this [issue](https://github.com/coreos/flannel/issues/1066);
|
||||
most likely it is a timing issue for when the management IP of the flannel network is set.
|
||||
A workaround is to relaunch `start.ps1` or relaunch it manually as follows:
|
||||
|
||||
```powershell
|
||||
[Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
|
||||
C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1
|
||||
```
|
||||
|
||||
1. My Windows Pods cannot launch because of missing `/run/flannel/subnet.env`
|
||||
|
||||
This indicates that Flannel didn't launch correctly. You can either try
|
||||
to restart `flanneld.exe` or you can copy the files over manually from
|
||||
`/run/flannel/subnet.env` on the Kubernetes master to `C:\run\flannel\subnet.env`
|
||||
on the Windows worker node and modify the `FLANNEL_SUBNET` row to a different
|
||||
number. For example, if node subnet 10.244.4.1/24 is desired:
|
||||
|
||||
```env
|
||||
FLANNEL_NETWORK=10.244.0.0/16
|
||||
FLANNEL_SUBNET=10.244.4.1/24
|
||||
FLANNEL_MTU=1500
|
||||
FLANNEL_IPMASQ=true
|
||||
```
|
||||
|
||||
### Further investigation
|
||||
|
||||
If these steps don't resolve your problem, you can get help running Windows containers on Windows nodes in Kubernetes through:
|
||||
|
||||
* StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container) topic
|
||||
* Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io/)
|
||||
* Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows)
|
||||
+2
-2
@@ -444,7 +444,7 @@ spec:
|
||||
served: true
|
||||
# One and only one version must be marked as the storage version.
|
||||
storage: true
|
||||
# Each version can define it's own schema when there is no top-level
|
||||
# Each version can define its own schema when there is no top-level
|
||||
# schema is defined.
|
||||
schema:
|
||||
openAPIV3Schema:
|
||||
@@ -512,7 +512,7 @@ spec:
|
||||
served: true
|
||||
# One and only one version must be marked as the storage version.
|
||||
storage: true
|
||||
# Each version can define it's own schema when there is no top-level
|
||||
# Each version can define its own schema when there is no top-level
|
||||
# schema is defined.
|
||||
schema:
|
||||
openAPIV3Schema:
|
||||
|
||||
+2
-1
@@ -811,7 +811,7 @@ Validation Rules Examples:
|
||||
| `'Available' in self.stateCounts` | Validate that an entry with the 'Available' key exists in a map |
|
||||
| `(size(self.list1) == 0) != (size(self.list2) == 0)` | Validate that one of two lists is non-empty, but not both |
|
||||
| <code>!('MY_KEY' in self.map1) || self['MY_KEY'].matches('^[a-zA-Z]*$')</code> | Validate the value of a map for a specific key, if it is in the map |
|
||||
| `self.envars.filter(e, e.name = 'MY_ENV').all(e, e.value.matches('^[a-zA-Z]*$')` | Validate the 'value' field of a listMap entry where key field 'name' is 'MY_ENV' |
|
||||
| `self.envars.filter(e, e.name == 'MY_ENV').all(e, e.value.matches('^[a-zA-Z]*$')` | Validate the 'value' field of a listMap entry where key field 'name' is 'MY_ENV' |
|
||||
| `has(self.expired) && self.created + self.ttl < self.expired` | Validate that 'expired' date is after a 'create' date plus a 'ttl' duration |
|
||||
| `self.health.startsWith('ok')` | Validate a 'health' string field has the prefix 'ok' |
|
||||
| `self.widgets.exists(w, w.key == 'x' && w.foo < 10)` | Validate that the 'foo' property of a listMap item with a key 'x' is less than 10 |
|
||||
@@ -819,6 +819,7 @@ Validation Rules Examples:
|
||||
| `self.metadata.name.startsWith(self.prefix)` | Validate that an object's name has the prefix of another field value |
|
||||
| `self.set1.all(e, !(e in self.set2))` | Validate that two listSets are disjoint |
|
||||
| `size(self.names) == size(self.details) && self.names.all(n, n in self.details)` | Validate the 'details' map is keyed by the items in the 'names' listSet |
|
||||
| `size(self.clusters.filter(c, c.name == self.primary)) == 1` | Validate that the 'primary' property has one and only one occurrence in the 'clusters' listMap |
|
||||
|
||||
Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6.0/doc/langdef.md#evaluation)
|
||||
|
||||
|
||||
+1
-1
@@ -23,7 +23,7 @@ in a Kubernetes Pod.
|
||||
When you create a Pod, you can set dependent environment variables for the containers that run in the Pod. To set dependent environment variables, you can use $(VAR_NAME) in the `value` of `env` in the configuration file.
|
||||
|
||||
In this exercise, you create a Pod that runs one container. The configuration
|
||||
file for the Pod defines an dependent environment variable with common usage defined. Here is the configuration manifest for the
|
||||
file for the Pod defines a dependent environment variable with common usage defined. Here is the configuration manifest for the
|
||||
Pod:
|
||||
|
||||
{{< codenew file="pods/inject/dependent-envars.yaml" >}}
|
||||
|
||||
+2
-2
@@ -69,7 +69,7 @@ kubectl logs kubernetes-downwardapi-volume-example
|
||||
|
||||
The output shows the contents of the `labels` file and the `annotations` file:
|
||||
|
||||
```shell
|
||||
```
|
||||
cluster="test-cluster1"
|
||||
rack="rack-22"
|
||||
zone="us-est-coast"
|
||||
@@ -155,7 +155,7 @@ file for a Pod that has one Container:
|
||||
{{< codenew file="pods/inject/dapi-volume-resources.yaml" >}}
|
||||
|
||||
In the configuration file, you can see that the Pod has a
|
||||
[`downwardAPI` volume](/concepts/storage/volumes/#downwardapi),
|
||||
[`downwardAPI` volume](/docs/concepts/storage/volumes/#downwardapi),
|
||||
and the Container mounts the volume at `/etc/podinfo`.
|
||||
|
||||
Look at the `items` array under `downwardAPI`. Each element of the array is a
|
||||
|
||||
@@ -79,7 +79,7 @@ kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml --dr
|
||||
|
||||
The output from both commands should be:
|
||||
|
||||
```shell
|
||||
```
|
||||
RollingUpdate
|
||||
```
|
||||
|
||||
|
||||
@@ -82,7 +82,7 @@ kubectl get deployment patch-demo --output yaml
|
||||
|
||||
The output shows that the PodSpec in the Deployment has two Containers:
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
containers:
|
||||
- image: redis
|
||||
imagePullPolicy: Always
|
||||
@@ -309,7 +309,7 @@ kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-no
|
||||
|
||||
In the output, you can see that it is not possible to set `type` as `Recreate` when a value is defined for `spec.strategy.rollingUpdate`:
|
||||
|
||||
```shell
|
||||
```
|
||||
The Deployment "retainkeys-demo" is invalid: spec.strategy.rollingUpdate: Forbidden: may not be specified when strategy `type` is 'Recreate'
|
||||
```
|
||||
|
||||
@@ -341,7 +341,7 @@ kubectl get deployment retainkeys-demo --output yaml
|
||||
|
||||
The output shows that the strategy object in the Deployment does not contain the `rollingUpdate` key anymore:
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
spec:
|
||||
strategy:
|
||||
type: Recreate
|
||||
|
||||
@@ -337,9 +337,9 @@ APIs, cluster administrators must ensure that:
|
||||
* For external metrics, this is the `external.metrics.k8s.io` API. It may be provided by the custom metrics adapters provided above.
|
||||
|
||||
For more information on these different metrics paths and how they differ please see the relevant design proposals for
|
||||
[the HPA V2](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md),
|
||||
[custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md)
|
||||
and [external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md).
|
||||
[the HPA V2](https://git.k8s.io/design-proposals-archive/autoscaling/hpa-v2.md),
|
||||
[custom.metrics.k8s.io](https://git.k8s.io/design-proposals-archive/instrumentation/custom-metrics-api.md)
|
||||
and [external.metrics.k8s.io](https://git.k8s.io/design-proposals-archive/instrumentation/external-metrics-api.md).
|
||||
|
||||
For examples of how to use them see [the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
|
||||
and [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects).
|
||||
@@ -400,7 +400,7 @@ scaling in that direction.
|
||||
### Stabilization window
|
||||
|
||||
The stabilization window is used to restrict the [flapping](#flapping) of
|
||||
replicas count when the metrics used for scaling keep fluctuating. The autoscaling algorithm
|
||||
replica count when the metrics used for scaling keep fluctuating. The autoscaling algorithm
|
||||
uses this window to infer a previous desired state and avoid unwanted changes to workload
|
||||
scale.
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ default, these certificates are issued with one year expiration so that they do
|
||||
not need to be renewed too frequently.
|
||||
|
||||
Kubernetes contains [kubelet certificate
|
||||
rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/),
|
||||
rotation](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/),
|
||||
that will automatically generate a new key and request a new certificate from
|
||||
the Kubernetes API as the current certificate approaches expiration. Once the
|
||||
new certificate is available, it will be used for authenticating connections to
|
||||
|
||||
@@ -43,7 +43,7 @@ If you have an alias for kubectl, you can extend shell completion to work with t
|
||||
|
||||
```bash
|
||||
echo 'alias k=kubectl' >>~/.bashrc
|
||||
echo 'complete -F __start_kubectl k' >>~/.bashrc
|
||||
echo 'complete -o default -F __start_kubectl k' >>~/.bashrc
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
||||
@@ -77,7 +77,7 @@ You now have to ensure that the kubectl completion script gets sourced in all yo
|
||||
|
||||
```bash
|
||||
echo 'alias k=kubectl' >>~/.bash_profile
|
||||
echo 'complete -F __start_kubectl k' >>~/.bash_profile
|
||||
echo 'complete -o default -F __start_kubectl k' >>~/.bash_profile
|
||||
```
|
||||
|
||||
- If you installed kubectl with Homebrew (as explained [here](/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything.
|
||||
|
||||
@@ -138,7 +138,7 @@ For example, to download version {{< param "fullversion" >}} on Linux, type:
|
||||
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
|
||||
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
repo_gpgcheck=1
|
||||
|
||||
Reference in New Issue
Block a user