whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge master into dev-1.22 to keep in sync

Browse Source
This commit is contained in:
Victor Palade
2021-05-20 19:17:30 +02:00
parent 09a6795d12 d398b75e19
commit 5cb4f973a4
290 changed files with 14292 additions and 10271 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
-7
View File
@@ -196,13 +196,6 @@ the slightly simpler syntax:
kubectl port-forward deployment/mongo :27017
```
The output is similar to this:
```
Forwarding from 127.0.0.1:63753 -> 27017
Forwarding from [::1]:63753 -> 27017
```
The `kubectl` tool finds a local port number that is not in use (avoiding low ports numbers,
because these might be used by other applications). The output is similar to:
content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
+1 -1
View File
@@ -34,7 +34,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.0.0/aio/deploy/recommended.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml
```
## Accessing the Dashboard UI
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+1 -1
View File
@@ -229,7 +229,7 @@ serverTLSBootstrap: true
If you have already created the cluster you must adapt it by doing the following:
- Find and edit the `kubelet-config-{{< skew latestVersion >}}` ConfigMap in the `kube-system` namespace.
In that ConfigMap, the `config` key has a
In that ConfigMap, the `kubelet` key has a
[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
document as its value. Edit the KubeletConfiguration document to set `serverTLSBootstrap: true`.
- On each node, add the `serverTLSBootstrap: true` field in `/var/lib/kubelet/config.yaml`
content/en/docs/tasks/administer-cluster/nodelocaldns.md
+1 -1
View File
@@ -79,7 +79,7 @@ If you are using the sample manifest from the previous point, this will require
* If kube-proxy is running in IPVS mode:
``` bash
sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml
sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/,__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml
```
In this mode, node-local-dns pods listen only on `<node-local-address>`. The node-local-dns interface cannot bind the kube-dns cluster IP since the interface used for IPVS loadbalancing already uses this address.
`__PILLAR__UPSTREAM__SERVERS__` will be populated by the node-local-dns pods.
content/en/docs/tasks/configmap-secret/managing-secret-using-config-file.md
+4 -4
View File
@@ -131,6 +131,8 @@ The output is similar to:
```yaml
apiVersion: v1
data:
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:40:59Z
@@ -139,8 +141,6 @@ metadata:
resourceVersion: "7225"
uid: c280ad2e-e916-11e8-98f2-025000000001
type: Opaque
data:
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
```
The commands `kubectl get` and `kubectl describe` avoid showing the contents of a `Secret` by
@@ -168,6 +168,8 @@ Results in the following Secret:
```yaml
apiVersion: v1
data:
username: YWRtaW5pc3RyYXRvcg==
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:46:46Z
@@ -176,8 +178,6 @@ metadata:
resourceVersion: "7579"
uid: 91460ecb-e917-11e8-98f2-025000000001
type: Opaque
data:
username: YWRtaW5pc3RyYXRvcg==
```
Where `YWRtaW5pc3RyYXRvcg==` decodes to `administrator`.
content/en/docs/tasks/configmap-secret/managing-secret-using-kubectl.md
+17 -17
View File
@@ -1,5 +1,5 @@
---
title: Managing Secret using kubectl
title: Managing Secrets using kubectl
content_type: task
weight: 10
description: Creating Secret objects using kubectl command line.
@@ -15,7 +15,7 @@ description: Creating Secret objects using kubectl command line.
## Create a Secret
A `Secret` can contain user credentials required by Pods to access a database.
A `Secret` can contain user credentials required by pods to access a database.
For example, a database connection string consists of a username and password.
You can store the username in a file `./username.txt` and the password in a
file `./password.txt` on your local machine.
@@ -24,11 +24,10 @@ file `./password.txt` on your local machine.
echo -n 'admin' > ./username.txt
echo -n '1f2d1e2e67df' > ./password.txt
```
The `-n` flag in the above two commands ensures that the generated files will
not contain an extra newline character at the end of the text. This is
important because when `kubectl` reads a file and encode the content into
base64 string, the extra newline character gets encoded too.
In these commands, the `-n` flag ensures that the generated files do not have
an extra newline character at the end of the text. This is important because
when `kubectl` reads a file and encodes the content into a base64 string, the
extra newline character gets encoded too.
The `kubectl create secret` command packages these files into a Secret and creates
the object on the API server.
@@ -45,7 +44,7 @@ The output is similar to:
secret/db-user-pass created
```
Default key name is the filename. You may optionally set the key name using
The default key name is the filename. You can optionally set the key name using
`--from-file=[key=]source`. For example:
```shell
@@ -54,17 +53,18 @@ kubectl create secret generic db-user-pass \
--from-file=password=./password.txt
```
You do not need to escape special characters in passwords from files
(`--from-file`).
You do not need to escape special characters in password strings that you
include in a file.
You can also provide Secret data using the `--from-literal=<key>=<value>` tag.
This tag can be specified more than once to provide multiple key-value pairs.
Note that special characters such as `$`, `\`, `*`, `=`, and `!` will be
interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing))
and require escaping.
In most shells, the easiest way to escape the password is to surround it with
single quotes (`'`). For example, if your actual password is `S!B\*d$zDsb=`,
you should execute the command this way:
single quotes (`'`). For example, if your password is `S!B\*d$zDsb=`,
run the following command:
```shell
kubectl create secret generic dev-db-secret \
@@ -74,7 +74,7 @@ kubectl create secret generic dev-db-secret \
## Verify the Secret
You can check that the secret was created:
Check that the Secret was created:
```shell
kubectl get secrets
@@ -111,7 +111,7 @@ username: 5 bytes
The commands `kubectl get` and `kubectl describe` avoid showing the contents
of a `Secret` by default. This is to protect the `Secret` from being exposed
accidentally to an onlooker, or from being stored in a terminal log.
accidentally, or from being stored in a terminal log.
## Decoding the Secret {#decoding-secret}
@@ -141,7 +141,7 @@ The output is similar to:
## Clean Up
To delete the Secret you have created:
Delete the Secret you created:
```shell
kubectl delete secret db-user-pass
@@ -152,5 +152,5 @@ kubectl delete secret db-user-pass
## {{% heading "whatsnext" %}}
- Read more about the [Secret concept](/docs/concepts/configuration/secret/)
- Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
- Learn how to [manage Secrets using config files](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- Learn how to [manage Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md
+13 -1
View File
@@ -48,7 +48,19 @@ secretGenerator:
- password=1f2d1e2e67df
```
Note that in both cases, you don't need to base64 encode the values.
You can also define the `secretGenerator` in the `kustomization.yaml`
file by providing `.env` files.
For example, the following `kustomization.yaml` file pulls in data from
`.env.secret` file:
```yaml
secretGenerator:
- name: db-user-pass
envs:
- .env.secret
```
Note that in all cases, you don't need to base64 encode the values.
## Create the Secret
content/en/docs/tasks/configure-pod-container/configure-gmsa.md
+71 -18
View File
@@ -197,21 +197,70 @@ As Pod specs with GMSA fields populated (as described above) are applied in a cl
1. The container runtime configures each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity.
## Containerd
On Windows Server 2019, in order to use GMSA with containerd, you must be running OS Build 17763.1817 (or later) which can be installed using the patch [KB5000822](https://support.microsoft.com/en-us/topic/march-9-2021-kb5000822-os-build-17763-1817-2eb6197f-e3b1-4f42-ab51-84345e063564).
There is also a known issue with containerd that occurs when trying to connect to SMB shares from Pods. Once you have configured GMSA, the pod will be unable to connect to the share using the hostname or FQDN, but connecting to the share using an IP address works as expected.
```PowerShell
ping adserver.ad.local
```
and correctly resolves the hostname to an IPv4 address. The output is similar to:
```
Pinging adserver.ad.local [192.168.111.18] with 32 bytes of data:
Reply from 192.168.111.18: bytes=32 time=6ms TTL=124
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
```
However, when attempting to browse the directory using the hostname
```PowerShell
cd \\adserver.ad.local\test
```
you see an error that implies the target share doesn't exist:
```
cd : Cannot find path '\\adserver.ad.local\test' because it does not exist.
At line:1 char:1
+ cd \\adserver.ad.local\test
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (\\adserver.ad.local\test:String) [Set-Location], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand
```
but you notice that the error disappears if you browse to the share using its IPv4 address instead; for example:
```PowerShell
cd \\192.168.111.18\test
```
After you change into a directory within the share, you see a prompt similar to:
```
Microsoft.PowerShell.Core\FileSystem::\\192.168.111.18\test>
```
To correct the behaviour you must run the following on the node `reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1` to add the required registry key. This node change will only take effect in newly created pods, meaning you must now recreate any running pods which require access to SMB shares.
## Troubleshooting
If you are having difficulties getting GMSA to work in your environment, there are a few troubleshooting steps you can take.
First, make sure the credspec has been passed to the Pod. To do this you will need to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command. In the example below the Pod did not get the credspec correctly:
First, make sure the credspec has been passed to the Pod. To do this you will need to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command.
```shell
In the example below the Pod did not get the credspec correctly:
```PowerShell
kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
PS C:\> nltest.exe /parentdomain
```
nltest.exe /parentdomain` results in the following error:
```
Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
PS C:\>
```
If your Pod did get the credspec correctly, then next check communication with the domain. First, from inside of your Pod, quickly do an nslookup to find the root of your domain.
@@ -224,23 +273,30 @@ This will tell us 3 things:
If the DNS and communication test passes, next you will need to check if the Pod has established secure channel communication with the domain. To do this, again, `exec` into your Pod and run the `nltest.exe /query` command.
```shell
PS C:\> nltest.exe /query
```PowerShell
nltest.exe /query
```
Results in the following output:
```
I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
```
This tells us that for some reason, the Pod was unable to logon to the domain using the account specified in the credspec. You can try to repair the secure channel by running the `nltest.exe /sc_reset:domain.example` command.
This tells us that for some reason, the Pod was unable to logon to the domain using the account specified in the credspec. You can try to repair the secure channel by running the following:
```shell
PS C:\> nltest /sc_reset:domain.example
```PowerShell
nltest /sc_reset:domain.example
```
If the command is successful you will see and output similar to this:
```
Flags: 30 HAS_IP HAS_TIMESERV
Trusted DC Name \\dc10.domain.example
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully
PS C:\>
```
If the above command corrects the error, you can automate the step by adding the following lifecycle hook to your Pod spec. If it did not correct the error, you will need to examine your credspec again and confirm that it is correct and complete.
If the above corrects the error, you can automate the step by adding the following lifecycle hook to your Pod spec. If it did not correct the error, you will need to examine your credspec again and confirm that it is correct and complete.
```yaml
image: registry.domain.example/iis-auth:1809v1
@@ -252,6 +308,3 @@ If the above command corrects the error, you can automate the step by adding the
```
If you add the `lifecycle` section show above to your Pod spec, the Pod will execute the commands listed to restart the `netlogon` service until the `nltest.exe /query` command exits without error.
## GMSA limitations
When using the [ContainerD runtime for Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) accessing restricted network shares via the GMSA domain identity fails. The container will receive the identity of and calls from `nltest.exe /query` will work. It is recommended to use the [Docker EE runtime](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee) if access to network shares is required. The Windows Server team is working on resolving the issue in the Windows Kernel and will release a patch to resolve this issue in the future. Look for updates on the [Microsoft Windows Containers issue tracker](https://github.com/microsoft/Windows-Containers/issues/44).
content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md
+12 -1
View File
@@ -624,9 +624,20 @@ Like before, all previous files in the `/etc/config/` directory will be deleted.
You can project keys to specific paths and specific permissions on a per-file
basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) user guide explains the syntax.
### Optional References
A ConfigMap reference may be marked "optional". If the ConfigMap is non-existent, the mounted volume will be empty. If the ConfigMap exists, but the referenced
key is non-existent the path will be absent beneath the mount point.
### Mounted ConfigMaps are updated automatically
When a ConfigMap already being consumed in a volume is updated, projected keys are eventually updated as well. Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync. However, it is using its local ttl-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period (1 minute by default) + ttl of ConfigMaps cache (1 minute by default) in kubelet. You can trigger an immediate refresh by updating one of the pod's annotations.
When a mounted ConfigMap is updated, the projected content is eventually updated too. This applies in the case where an optionally referenced ConfigMap comes into
existence after a pod has started.
Kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, it uses its local TTL-based cache for getting the current value of the
ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as
kubelet sync period (1 minute by default) + TTL of ConfigMaps cache (1 minute by default) in kubelet. You can trigger an immediate refresh by updating one of
the pod's annotations.
{{< note >}}
A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates.
content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md
+1 -1
View File
@@ -146,7 +146,7 @@ All modifications to a cron job, especially its `.spec`, are applied only to the
The `.spec.schedule` is a required field of the `.spec`.
It takes a [Cron](https://en.wikipedia.org/wiki/Cron) format string, such as `0 * * * *` or `@hourly`, as schedule time of its jobs to be created and executed.
The format also includes extended `vixie cron` step values. As explained in the
The format also includes extended "Vixie cron" step values. As explained in the
[FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29):
> Step values can be used in conjunction with ranges. Following a range
content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
+37 -1
View File
@@ -86,6 +86,43 @@ metadata:
name: example-configmap-1-8mbdf7882g
```
To generate a ConfigMap from an env file, add an entry to the `envs` list in `configMapGenerator`. Here is an example of generating a ConfigMap with a data item from a `.env` file:
```shell
# Create a .env file
cat <<EOF >.env
FOO=Bar
EOF
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: example-configmap-1
envs:
- .env
EOF
```
The generated ConfigMap can be examined with the following command:
```shell
kubectl kustomize ./
```
The generated ConfigMap is:
```yaml
apiVersion: v1
data:
FOO=Bar
kind: ConfigMap
metadata:
name: example-configmap-1-8mbdf7882g
```
{{< note >}}
Each variable in the `.env` file becomes a separate key in the ConfigMap that you generate. This is different from the previous example which embeds a file named `.properties` (and all its entries) as the value for a single key.
{{< /note >}}
ConfigMaps can also be generated from literal key-value pairs. To generate a ConfigMap from a literal key-value pair, add an entry to the `literals` list in configMapGenerator. Here is an example of generating a ConfigMap with a data item from a key-value pair:
```shell
@@ -975,4 +1012,3 @@ deployment.apps "dev-my-nginx" deleted
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md
+4 -4
View File
@@ -310,10 +310,10 @@ Patch your Deployment:
{{< tabs name="kubectl_retainkeys_example" >}}
{{{< tab name="Bash" codelang="bash" >}}
kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-no-retainkeys.yaml)"
kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-no-retainkeys.yaml)"
{{< /tab >}}
{{< tab name="PowerShell" codelang="posh" >}}
kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw)
kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw)
{{< /tab >}}}
{{< /tabs >}}
@@ -341,10 +341,10 @@ Patch your Deployment again with this new patch:
{{< tabs name="kubectl_retainkeys2_example" >}}
{{{< tab name="Bash" codelang="bash" >}}
kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-retainkeys.yaml)"
kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-retainkeys.yaml)"
{{< /tab >}}
{{< tab name="PowerShell" codelang="posh" >}}
kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-retainkeys.yaml -Raw)
kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-retainkeys.yaml -Raw)
{{< /tab >}}}
{{< /tabs >}}
content/en/docs/tasks/run-application/delete-stateful-set.md
+3 -3
View File
@@ -43,14 +43,14 @@ You may need to delete the associated headless service separately after the Stat
kubectl delete service <service-name>
```
When deleting a StatefulSet through `kubectl`, the StatefulSet scales down to 0. All Pods that are part of this workload are also deleted. If you want to delete only the StatefulSet and not the Pods, use `--cascade=false`.
When deleting a StatefulSet through `kubectl`, the StatefulSet scales down to 0. All Pods that are part of this workload are also deleted. If you want to delete only the StatefulSet and not the Pods, use `--cascade=orphan`.
For example:
```shell
kubectl delete -f <file.yaml> --cascade=false
kubectl delete -f <file.yaml> --cascade=orphan
```
By passing `--cascade=false` to `kubectl delete`, the Pods managed by the StatefulSet are left behind even after the StatefulSet object itself is deleted. If the pods have a label `app=myapp`, you can then delete them as follows:
By passing `--cascade=orphan` to `kubectl delete`, the Pods managed by the StatefulSet are left behind even after the StatefulSet object itself is deleted. If the pods have a label `app=myapp`, you can then delete them as follows:
```shell
kubectl delete pods -l app=myapp