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

Merge remote-tracking branch 'upstream/main' into dev-1.23

Browse Source
This commit is contained in:
Jesse Butler
2021-10-26 14:13:06 -04:00
parent 0af4dd9687 2cf8506197
commit 4e755b2f2c
403 changed files with 11265 additions and 7503 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/access-application-cluster/ingress-minikube.md
+135 -150
View File
@@ -2,6 +2,7 @@
title: Set up Ingress on Minikube with the NGINX Ingress Controller
content_type: task
weight: 100
min-kubernetes-server-version: 1.19
---
<!-- overview -->
@@ -17,23 +18,21 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
If you are using an older Kubernetes version, switch to the documentation
for that version.
### Create a Minikube cluster
Using Katacoda
: {{< kat-button >}}
Locally
: If you already [installed Minikube](/docs/tasks/tools/#minikube)
locally, run `minikube start` to create a cluster.
<!-- steps -->
## Create a Minikube cluster
1. Click **Launch Terminal**
{{< kat-button >}}
1. (Optional) If you installed Minikube locally, run the following command:
```shell
minikube start
```
## Enable the Ingress controller
1. To enable the NGINX Ingress controller, run the following command:
@@ -45,14 +44,14 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
1. Verify that the NGINX Ingress controller is running
{{< tabs name="tab_with_md" >}}
{{% tab name="minikube v1.19 or later" %}}
{{< tabs name="tab_with_md" >}}
{{% tab name="minikube v1.19 or later" %}}
```shell
kubectl get pods -n ingress-nginx
```
{{< note >}}This can take up to a minute.{{< /note >}}
{{< note >}}It can take up to a minute before you see these pods running OK.{{< /note >}}
Output:
The output is similar to:
```
NAME READY STATUS RESTARTS AGE
@@ -60,15 +59,14 @@ ingress-nginx-admission-create-g9g49 0/1 Completed 0 11m
ingress-nginx-admission-patch-rqp78 0/1 Completed 1 11m
ingress-nginx-controller-59b45fb494-26npt 1/1 Running 0 11m
```
{{% /tab %}}
{{% tab name="minikube v1.18.1 or earlier" %}}
{{% /tab %}}
{{% tab name="minikube v1.18.1 or earlier" %}}
```shell
kubectl get pods -n kube-system
```
{{< note >}}This can take up to a minute.{{< /note >}}
{{< note >}}It can take up to a minute before you see these pods running OK.{{< /note >}}
Output:
The output is similar to:
```
NAME READY STATUS RESTARTS AGE
@@ -79,133 +77,121 @@ kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m
nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m
storage-provisioner 1/1 Running 0 2m
```
{{% /tab %}}
{{< /tabs >}}
```shell
kubectl get pods -n ingress-nginx
```
{{< note >}}This can take up to a minute.{{< /note >}}
Output:
```shell
NAME READY STATUS RESTARTS AGE
ingress-nginx-admission-create-2tgrf 0/1 Completed 0 3m28s
ingress-nginx-admission-patch-68b98 0/1 Completed 0 3m28s
ingress-nginx-controller-59b45fb494-lzmw2 1/1 Running 0 3m28s
```
Make sure that you see a Pod with a name that starts with `nginx-ingress-controller-`.
{{% /tab %}}
{{< /tabs >}}
## Deploy a hello, world app
1. Create a Deployment using the following command:
```shell
kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
```
```shell
kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
```
Output:
The output should be:
```shell
deployment.apps/web created
```
```
deployment.apps/web created
```
1. Expose the Deployment:
```shell
kubectl expose deployment web --type=NodePort --port=8080
```
```shell
kubectl expose deployment web --type=NodePort --port=8080
```
Output:
The output should be:
```shell
service/web exposed
```
```
service/web exposed
```
1. Verify the Service is created and is available on a node port:
```shell
kubectl get service web
```
kubectl get service web
```
Output:
The output is similar to:
```shell
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web NodePort 10.104.133.249 <none> 8080:31637/TCP 12m
```
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web NodePort 10.104.133.249 <none> 8080:31637/TCP 12m
```
1. Visit the service via NodePort:
1. Visit the Service via NodePort:
```shell
minikube service web --url
```
```shell
minikube service web --url
```
Output:
The output is similar to:
```shell
http://172.17.0.15:31637
```
```
http://172.17.0.15:31637
```
{{< note >}}Katacoda environment only: at the top of the terminal panel, click the plus sign, and then click **Select port to view on Host 1**. Enter the NodePort, in this case `31637`, and then click **Display Port**.{{< /note >}}
{{< note >}}Katacoda environment only: at the top of the terminal panel, click the plus sign, and then click **Select port to view on Host 1**. Enter the NodePort, in this case `31637`, and then click **Display Port**.{{< /note >}}
Output:
The output is similar to:
```shell
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
```
```
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
```
You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access
the app using the Ingress resource.
You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access
the app using the Ingress resource.
## Create an Ingress resource
## Create an Ingress
The following file is an Ingress resource that sends traffic to your Service via hello-world.info.
The following manifest defines an Ingress that sends traffic to your Service via hello-world.info.
1. Create `example-ingress.yaml` from the following file:
{{< codenew file="service/networking/example-ingress.yaml" >}}
{{< codenew file="service/networking/example-ingress.yaml" >}}
1. Create the Ingress resource by running the following command:
1. Create the Ingress object by running the following command:
```shell
kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
```
```shell
kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
```
Output:
The output should be:
```shell
ingress.networking.k8s.io/example-ingress created
```
```
ingress.networking.k8s.io/example-ingress created
```
1. Verify the IP address is set:
```shell
kubectl get ingress
```
```shell
kubectl get ingress
```
{{< note >}}This can take a couple of minutes.{{< /note >}}
{{< note >}}This can take a couple of minutes.{{< /note >}}
```shell
NAME CLASS HOSTS ADDRESS PORTS AGE
example-ingress <none> hello-world.info 172.17.0.15 80 38s
```
You should see an IPv4 address in the ADDRESS column; for example:
1. Add the following line to the bottom of the `/etc/hosts` file.
```
NAME CLASS HOSTS ADDRESS PORTS AGE
example-ingress <none> hello-world.info 172.17.0.15 80 38s
```
{{< note >}}If you are running Minikube locally, use `minikube ip` to get the external IP. The IP address displayed within the ingress list will be the internal IP.{{< /note >}}
1. Add the following line to the bottom of the `/etc/hosts` file on
your computer (you will need adminstrator access):
```
172.17.0.15 hello-world.info
```
This sends requests from hello-world.info to Minikube.
{{< note >}}If you are running Minikube locally, use `minikube ip` to get the external IP. The IP address displayed within the ingress list will be the internal IP.{{< /note >}}
After you make this change, your web browser sends requests for
hello-world.info URLs to Minikube.
1. Verify that the Ingress controller is directing traffic:
@@ -213,9 +199,9 @@ The following file is an Ingress resource that sends traffic to your Service via
curl hello-world.info
```
Output:
You should see:
```shell
```
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
@@ -223,34 +209,35 @@ The following file is an Ingress resource that sends traffic to your Service via
{{< note >}}If you are running Minikube locally, you can visit hello-world.info from your browser.{{< /note >}}
## Create Second Deployment
## Create a second Deployment
1. Create a v2 Deployment using the following command:
1. Create another Deployment using the following command:
```shell
kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
```
Output:
```shell
kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
```
The output should be:
```shell
deployment.apps/web2 created
```
```
deployment.apps/web2 created
```
1. Expose the Deployment:
1. Expose the second Deployment:
```shell
kubectl expose deployment web2 --port=8080 --type=NodePort
```
```shell
kubectl expose deployment web2 --port=8080 --type=NodePort
```
Output:
The output should be:
```shell
service/web2 exposed
```
```
service/web2 exposed
```
## Edit Ingress
## Edit the existing Ingress {#edit-ingress}
1. Edit the existing `example-ingress.yaml` and add the following lines:
1. Edit the existing `example-ingress.yaml` manifest, and add the
following lines at the end:
```yaml
- path: /v2
@@ -264,47 +251,47 @@ The following file is an Ingress resource that sends traffic to your Service via
1. Apply the changes:
```shell
kubectl apply -f example-ingress.yaml
```
```shell
kubectl apply -f example-ingress.yaml
```
Output:
You should see:
```shell
ingress.networking/example-ingress configured
```
```
ingress.networking/example-ingress configured
```
## Test Your Ingress
## Test your Ingress
1. Access the 1st version of the Hello World app.
```shell
curl hello-world.info
```
```shell
curl hello-world.info
```
Output:
The output is similar to:
```shell
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
```
```
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
```
1. Access the 2nd version of the Hello World app.
```shell
curl hello-world.info/v2
```
```shell
curl hello-world.info/v2
```
Output:
The output is similar to:
```shell
Hello, world!
Version: 2.0.0
Hostname: web2-75cd47646f-t8cjk
```
```
Hello, world!
Version: 2.0.0
Hostname: web2-75cd47646f-t8cjk
```
{{< note >}}If you are running Minikube locally, you can visit hello-world.info and hello-world.info/v2 from your browser.{{< /note >}}
{{< note >}}If you are running Minikube locally, you can visit hello-world.info and hello-world.info/v2 from your browser.{{< /note >}}
@@ -315,5 +302,3 @@ The following file is an Ingress resource that sends traffic to your Service via
* Read more about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/)
* Read more about [Services](/docs/concepts/services-networking/service/)
content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
+4 -4
View File
@@ -88,11 +88,11 @@ kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\"
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
* Learn more about [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
### Reference
### References {#reference}
* [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
* See the `persistentVolumeReclaimPolicy` field of [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core).
* {{< api-reference page="config-and-storage-resources/persistent-volume-v1" >}}
* Pay attention to the `.spec.persistentVolumeReclaimPolicy` [field](https://kubernetes.io/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec) of PersistentVolume.
* {{< api-reference page="config-and-storage-resources/persistent-volume-claim-v1" >}}
content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
+4
View File
@@ -325,6 +325,10 @@ Here is an example:
```shell
ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 snapshot restore snapshotdb
```
Another example for restoring using etcdutl options:
```shell
ETCDCTL_API=3 etcdctl --data-dir <data-dir-location> snapshot restore snapshotdb
```
For more information and examples on restoring a cluster from a snapshot file, see
[etcd disaster recovery documentation](https://etcd.io/docs/current/op-guide/recovery/#restoring-a-cluster).
content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
+1 -1
View File
@@ -67,7 +67,7 @@ If the `nslookup` command fails, check the following:
### Check the local DNS configuration first
Take a look inside the resolv.conf file.
(See [Inheriting DNS from the node](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) and
(See [Customizing DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers) and
[Known issues](#known-issues) below for more information)
```shell
content/en/docs/tasks/administer-cluster/encrypt-data.md
+2 -5
View File
@@ -58,8 +58,7 @@ resources:
Each `resources` array item is a separate config and contains a complete configuration. The
`resources.resources` field is an array of Kubernetes resource names (`resource` or `resource.group`)
that should be encrypted. The `providers` array is an ordered list of the possible encryption
providers. Only one provider type may be specified per entry (`identity` or `aescbc` may be provided,
but not both in the same item).
providers. Only one provider type may be specified per entry (`identity` or `aescbc` may be provided, but not both in the same item).
The first provider in the list is used to encrypt resources going into storage. When reading
resources from storage each provider that matches the stored data attempts to decrypt the data in
@@ -78,9 +77,9 @@ read that resource will fail until it is deleted or a valid decryption key is pr
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.
`aescbc` | AES-CBC with PKCS#7 padding | Strongest | Fast | 32-byte | The recommended choice for encryption at rest but may be slightly slower than `secretbox`.
`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/)
Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider
@@ -215,5 +214,3 @@ and restart all `kube-apiserver` processes. Then run:
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
```
to force all secrets to be decrypted.
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+8 -9
View File
@@ -88,6 +88,7 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc
yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
<br />
- Verify that the download works and has the expected version:
@@ -166,11 +167,10 @@ Also calling `kubeadm upgrade plan` and upgrading the CNI provider plugin is no
### 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" >}}
<pre>
{{% 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 && \
@@ -179,15 +179,13 @@ Also calling `kubeadm upgrade plan` and upgrading the CNI provider plugin is no
# since apt-get version 1.1 you can also use the following method
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
</pre>
{{< /tab >}}
{{< tab name="CentOS, RHEL or Fedora" >}}
<pre>
{{% /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
</pre>
{{< /tab >}}
{{% /tab %}}
{{< /tabs >}}
<br />
- Restart the kubelet:
@@ -268,6 +266,7 @@ without compromising the minimum required capacity for running your workloads.
yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
<br />
- Restart the kubelet:
content/en/docs/tasks/administer-cluster/kubelet-in-userns.md
+25 -14
View File
@@ -27,8 +27,7 @@ If you are just looking for how to run a pod as a non-root user, see [SecurityCo
* [Enable systemd with user session](https://rootlesscontaine.rs/getting-started/common/login/)
* [Configure several sysctl values, depending on host Linux distribution](https://rootlesscontaine.rs/getting-started/common/sysctl/)
* [Ensure that your unprivileged user is listed in `/etc/subuid` and `/etc/subgid`](https://rootlesscontaine.rs/getting-started/common/subuid/)
* `KubeletInUserNamespace` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
* Enable the `KubeletInUserNamespace` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
<!-- steps -->
@@ -86,9 +85,10 @@ Rootless Docker/Podman or LXC/LXD, you are all set, and you can go to the next s
Otherwise you have to create a user namespace by yourself, by calling `unshare(2)` with `CLONE_NEWUSER`.
A user namespace can be also unshared by using command line tools such as:
- [`unshare(1)`](https://man7.org/linux/man-pages/man1/unshare.1.html)
- [RootlessKit](https://github.com/rootless-containers/rootlesskit)
- [become-root](https://github.com/giuseppe/become-root)
- [`unshare(1)`](https://man7.org/linux/man-pages/man1/unshare.1.html)
After unsharing the user namespace, you will also have to unshare other namespaces such as mount namespace.
@@ -123,29 +123,37 @@ On your node, systemd must already be configured to allow delegation; for more d
Containers documentation.
### Configuring network
{{% thirdparty-content %}}
The network namespace of the Node components has to have a non-loopback interface, which can be for example configured with
slirp4netns, VPNKit, or lxc-user-nic.
[slirp4netns](https://github.com/rootless-containers/slirp4netns),
[VPNKit](https://github.com/moby/vpnkit), or
[lxc-user-nic(1)](https://www.man7.org/linux/man-pages/man1/lxc-user-nic.1.html).
The network namespaces of the Pods can be configured with regular CNI plugins.
For multi-node networking, Flannel (VXLAN, 8472/UDP) is known to work.
Ports such as the kubelet port (10250/TCP) and `NodePort` service ports have to be exposed from the Node network namespace to
the host with an external port forwarder, such as RootlessKit, slirp4netns, or socat.
the host with an external port forwarder, such as RootlessKit, slirp4netns, or
[socat(1)](https://linux.die.net/man/1/socat).
You can use the port forwarder from K3s; see https://github.com/k3s-io/k3s/blob/v1.21.2+k3s1/pkg/rootlessports/controller.go
You can use the port forwarder from K3s.
See [Running K3s in Rootless Mode](https://rancher.com/docs/k3s/latest/en/advanced/#known-issues-with-rootless-mode)
for more details.
### Configuring CRI
The kubelet relies on a container runtime. You should deploy a container runtime such as containerd or CRI-O and ensure that it is running within the user namespace before the kubelet starts.
The kubelet relies on a container runtime. You should deploy a container runtime such as
containerd or CRI-O and ensure that it is running within the user namespace before the kubelet starts.
{{< tabs name="cri" >}}
{{% tab name="containerd" %}}
Running CRI plugin of containerd in a user namespace is supported since containerd 1.4.
Running containerd within a user namespace requires the following configuration:
Running containerd within a user namespace requires the following configurations
in `/etc/containerd/containerd-config.toml`.
```toml
version = 2
@@ -175,7 +183,7 @@ Running CRI-O in a user namespace is supported since CRI-O 1.22.
CRI-O requires an environment variable `_CRIO_ROOTLESS=1` to be set.
The following configuration is also recommended:
The following configurations (in `/etc/crio/crio.conf`) are also recommended:
```toml
[crio]
@@ -197,8 +205,8 @@ The following configuration is also recommended:
Running kubelet in a user namespace requires the following configuration:
```yaml
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
KubeletInUserNamespace: true
# We use cgroupfs that is delegated by systemd, so we do not use "systemd" driver
@@ -206,22 +214,23 @@ featureGates:
cgroupDriver: "cgroupfs"
```
When the `KubeletInUserNamespace` feature gate is enabled, kubelet ignores errors that may happen during setting the following sysctl values:
When the `KubeletInUserNamespace` feature gate is enabled, the kubelet ignores errors
that may happen during setting the following sysctl values on the node.
- `vm.overcommit_memory`
- `vm.panic_on_oom`
- `kernel.panic`
- `kernel.panic_on_oops`
- `kernel.keys.root_maxkeys`
- `kernel.keys.root_maxbytes`.
(these are sysctl values for the host, not for the containers).
Within a user namespace, the kubelet also ignores any error raised from trying to open `/dev/kmsg`.
This feature gate also allows kube-proxy to ignore an error during setting `RLIMIT_NOFILE`.
The `KubeletInUserNamespace` feature gate was introduced in Kubernetes v1.22 with "alpha" status.
Running kubelet in a user namespace without using this feature gate is also possible by mounting a specially crafted proc filesystem,
but not officially supported.
Running kubelet in a user namespace without using this feature gate is also possible
by mounting a specially crafted proc filesystem, but not officially supported.
### Configuring kube-proxy
@@ -251,9 +260,11 @@ For more on this, see the [Caveats and Future work](https://rootlesscontaine.rs/
on the rootlesscontaine.rs website.
## {{% heading "seealso" %}}
- [rootlesscontaine.rs](https://rootlesscontaine.rs/)
- [Rootless Containers 2020 (KubeCon NA 2020)](https://www.slideshare.net/AkihiroSuda/kubecon-na-2020-containerd-rootless-containers-2020)
- [Running kind with Rootless Docker](https://kind.sigs.k8s.io/docs/user/rootless/)
- [Usernetes](https://github.com/rootless-containers/usernetes)
- [Running K3s with rootless mode](https://rancher.com/docs/k3s/latest/en/advanced/#running-k3s-with-rootless-mode-experimental)
- [KEP-2033: Kubelet-in-UserNS (aka Rootless mode)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2033-kubelet-in-userns-aka-rootless)
content/en/docs/tasks/administer-cluster/nodelocaldns.md
+1 -1
View File
@@ -46,7 +46,7 @@ Having a local cache will help improve the latency in such scenarios.
This is the path followed by DNS Queries after NodeLocal DNSCache is enabled:
{{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCache flow" caption="This image shows how NodeLocal DNSCache handles DNS queries." >}}
{{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCache flow" caption="This image shows how NodeLocal DNSCache handles DNS queries." class="diagram-medium" >}}
## Configuration
{{< note >}} The local listen IP address for NodeLocal DNSCache can be any address that can be guaranteed to not collide with any existing IP in your cluster. It's recommended to use an address with a local scope, per example, from the link-local range 169.254.0.0/16 for IPv4 or from the Unique Local Address range in IPv6 fd00::/8.
content/en/docs/tasks/configure-pod-container/configure-gmsa.md
+1 -1
View File
@@ -258,7 +258,7 @@ In the example below the Pod did not get the credspec correctly:
```PowerShell
kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
```
nltest.exe /parentdomain` results in the following error:
`nltest.exe /parentdomain` results in the following error:
```
Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
```
content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
+3 -3
View File
@@ -29,13 +29,13 @@ Kompose is released via GitHub on a three-week cycle, you can see all current re
```sh
# Linux
curl -L https://github.com/kubernetes/kompose/releases/download/v1.22.0/kompose-linux-amd64 -o kompose
curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-linux-amd64 -o kompose
# macOS
curl -L https://github.com/kubernetes/kompose/releases/download/v1.22.0/kompose-darwin-amd64 -o kompose
curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-darwin-amd64 -o kompose
# Windows
curl -L https://github.com/kubernetes/kompose/releases/download/v1.22.0/kompose-windows-amd64.exe -o kompose.exe
curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-windows-amd64.exe -o kompose.exe
chmod +x kompose
sudo mv ./kompose /usr/local/bin/kompose
content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+2 -2
View File
@@ -82,8 +82,8 @@ Now that the server is running, we will create the autoscaler using
The following command will create a Horizontal Pod Autoscaler that maintains between 1 and 10 replicas of the Pods
controlled by the php-apache deployment we created in the first step of these instructions.
Roughly speaking, HPA will increase and decrease the number of replicas
(via the deployment) to maintain an average CPU utilization across all Pods of 50%
(since each pod requests 200 milli-cores by `kubectl run`), this means average CPU usage of 100 milli-cores).
(via the deployment) to maintain an average CPU utilization across all Pods of 50%.
Since each pod requests 200 milli-cores by `kubectl run`, this means an average CPU usage of 100 milli-cores.
See [here](/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) for more details on the algorithm.
```shell