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

Merge pull request #19793 from VineethReddy02/vineeth-merge-master-into-dev-1.18-for-syncup

Browse Source 
Merge master into dev-1.18 for sync-up
This commit is contained in:
Kubernetes Prow Robot
2020-03-22 13:26:46 -07:00
committed by GitHub
parent 797ae19d40 f1d9ebc578
commit f7d6bac8d0
298 changed files with 10720 additions and 4146 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/administer-cluster/change-default-storage-class.md
+3 -3
View File
@@ -62,10 +62,10 @@ for details about addon manager and how to disable individual addons.
To mark a StorageClass as non-default, you need to change its value to `false`:
```bash
kubectl patch storageclass <your-class-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
```
where `<your-class-name>` is the name of your chosen StorageClass.
where `standard` is the name of your chosen StorageClass.
1. Mark a StorageClass as default:
@@ -73,7 +73,7 @@ for details about addon manager and how to disable individual addons.
`storageclass.kubernetes.io/is-default-class=true`.
```bash
kubectl patch storageclass <your-class-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
kubectl patch storageclass gold -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
```
Please note that at most one StorageClass can be marked as default. If two
content/en/docs/tasks/administer-cluster/cluster-management.md
+1 -1
View File
@@ -24,7 +24,7 @@ To install Kubernetes on a set of machines, consult one of the existing [Getting
## Upgrading a cluster
The current state of cluster upgrades is provider dependent, and some releases may require special care when upgrading. It is recommended that administrators consult both the [release notes](https://git.k8s.io/kubernetes/CHANGELOG.md), as well as the version specific upgrade notes prior to upgrading their clusters.
The current state of cluster upgrades is provider dependent, and some releases may require special care when upgrading. It is recommended that administrators consult both the [release notes](https://git.k8s.io/kubernetes/CHANGELOG/README.md), as well as the version specific upgrade notes prior to upgrading their clusters.
### Upgrading an Azure Kubernetes Service (AKS) cluster
content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
-9
View File
@@ -265,15 +265,6 @@ work properly owing to a known issue with Alpine.
Check [here](https://github.com/kubernetes/kubernetes/issues/30215)
for more information.
## Kubernetes Federation (Multiple Zone support)
Release 1.3 introduced Cluster Federation support for multi-site Kubernetes
installations. This required some minor (backward-compatible) changes to the
way the Kubernetes cluster DNS server processes DNS queries, to facilitate
the lookup of federated services (which span multiple Kubernetes clusters).
See the [Cluster Federation Administrators' Guide](/docs/concepts/cluster-administration/federation/)
for more details on Cluster Federation and multi-site support.
## References
- [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/)
content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
+5 -3
View File
@@ -224,12 +224,14 @@ At this point, all requests we make to the Kubernetes cluster from the command l
Let's create some contents.
{{< codenew file="admin/snowflake-deployment.yaml" >}}
Apply the manifest to create a Deployment
```shell
kubectl run snowflake --image=k8s.gcr.io/serve_hostname --replicas=2
kubectl apply -f https://k8s.io/examples/admin/snowflake-deployment.yaml
```
We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname.
Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) for more details.
```shell
kubectl get deployment
content/en/docs/tasks/administer-cluster/namespaces.md
+8 -78
View File
@@ -188,88 +188,22 @@ This delete is asynchronous, so for a time you will see the namespace in the `Te
To demonstrate this, let's spin up a simple Deployment and Pods in the `development` namespace.
We first check what is the current context:
```shell
kubectl config view
```
```yaml
apiVersion: v1
clusters:
cluster:
certificate-authority-data: REDACTED
server: https://130.211.122.180
name: lithe-cocoa-92103_kubernetes
contexts:
context:
cluster: lithe-cocoa-92103_kubernetes
user: lithe-cocoa-92103_kubernetes
name: lithe-cocoa-92103_kubernetes
current-context: lithe-cocoa-92103_kubernetes
kind: Config
preferences: {}
users:
name: lithe-cocoa-92103_kubernetes
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
name: lithe-cocoa-92103_kubernetes-basic-auth
user:
password: h5M0FtUUIflBSdI7
username: admin
```
```shell
kubectl config current-context
```
```
lithe-cocoa-92103_kubernetes
```
The next step is to define a context for the kubectl client to work in each namespace. The values of "cluster" and "user" fields are copied from the current context.
```shell
kubectl config set-context dev --namespace=development --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
kubectl config set-context prod --namespace=production --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
```
The above commands provided two request contexts you can alternate against depending on what namespace you
wish to work against.
Let's switch to operate in the `development` namespace.
```shell
kubectl config use-context dev
```
You can verify your current context by doing the following:
```shell
kubectl config current-context
dev
```
At this point, all requests we make to the Kubernetes cluster from the command line are scoped to the `development` namespace.
Let's create some contents.
```shell
kubectl run snowflake --image=k8s.gcr.io/serve_hostname --replicas=2
kubectl run snowflake --image=k8s.gcr.io/serve_hostname --replicas=2 -n=development
```
We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname.
Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) for more details.
```shell
kubectl get deployment
kubectl get deployment -n=development
```
```
NAME READY UP-TO-DATE AVAILABLE AGE
snowflake 2/2 2 2 2m
```
```shell
kubectl get pods -l run=snowflake
kubectl get pods -l run=snowflake -n=development
```
```
NAME READY STATUS RESTARTS AGE
@@ -281,23 +215,19 @@ This delete is asynchronous, so for a time you will see the namespace in the `Te
Let's switch to the `production` namespace and show how resources in one namespace are hidden from the other.
```shell
kubectl config use-context prod
```
The `production` namespace should be empty, and the following commands should return nothing.
```shell
kubectl get deployment
kubectl get pods
kubectl get deployment -n=production
kubectl get pods -n=production
```
Production likes to run cattle, so let's create some cattle pods.
```shell
kubectl run cattle --image=k8s.gcr.io/serve_hostname --replicas=5
kubectl run cattle --image=k8s.gcr.io/serve_hostname --replicas=5 -n=production
kubectl get deployment
kubectl get deployment -n=production
```
```
NAME READY UP-TO-DATE AVAILABLE AGE
@@ -305,7 +235,7 @@ This delete is asynchronous, so for a time you will see the namespace in the `Te
```
```shell
kubectl get pods -l run=cattle
kubectl get pods -l run=cattle -n=production
```
```
NAME READY STATUS RESTARTS AGE
content/en/docs/tasks/administer-cluster/nodelocaldns.md
+34 -7
View File
@@ -2,6 +2,7 @@
reviewers:
- bowei
- zihongz
- sftim
title: Using NodeLocal DNSCache in Kubernetes clusters
content_template: templates/task
---
@@ -47,18 +48,44 @@ This is the path followed by DNS Queries after NodeLocal DNSCache is enabled:
{{< figure src="/images/docs/nodelocaldns.jpg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCache flow" caption="This image shows how NodeLocal DNSCache handles DNS queries." >}}
## Configuration
{{< note >}} The local listen IP address for NodeLocal DNSCache can be any IP in the 169.254.20.0/16 space or any other IP address that can be guaranteed to not collide with any existing IP. This document uses 169.254.20.10 as an example.
{{< /note >}}
This feature can be enabled using the command:
This feature can be enabled using the following steps:
`KUBE_ENABLE_NODELOCAL_DNS=true kubetest --up`
* Prepare a manifest similar to the sample [`nodelocaldns.yaml`](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml) and save it as `nodelocaldns.yaml.`
* Substitute the variables in the manifest with the right values:
This works for e2e clusters created on GCE. On all other environments, the following steps will setup NodeLocal DNSCache:
* kubedns=`kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}`
* domain=`<cluster-domain>`
* localdns=`<node-local-address>`
`<cluster-domain>` is "cluster.local" by default. `<node-local-address>` is the local listen IP address chosen for NodeLocal DNSCache.
* A yaml similar to [this](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml) can be applied using `kubectl create -f` command.
* No need to modify the --cluster-dns flag since NodeLocal DNSCache listens on both the kube-dns service IP as well as a link-local IP (169.254.20.10 by default)
* If kube-proxy is running in IPTABLES mode:
``` bash
sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__/$kubedns/g" nodelocaldns.yaml
```
`__PILLAR__CLUSTER__DNS__` and `__PILLAR__UPSTREAM__SERVERS__` will be populated by the node-local-dns pods.
In this mode, node-local-dns pods listen on both the kube-dns service IP as well as `<node-local-address>`, so pods can lookup DNS records using either IP address.
* 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
```
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.
* Run `kubectl create -f nodelocaldns.yaml`
* If using kube-proxy in IPVS mode, `--cluster-dns` flag to kubelet needs to be modified to use `<node-local-address>` that NodeLocal DNSCache is listening on.
Otherwise, there is no need to modify the value of the `--cluster-dns` flag, since NodeLocal DNSCache listens on both the kube-dns service IP as well as `<node-local-address>`.
Once enabled, node-local-dns Pods will run in the kube-system namespace on each of the cluster nodes. This Pod runs [CoreDNS](https://github.com/coredns/coredns) in cache mode, so all CoreDNS metrics exposed by the different plugins will be available on a per-node basis.
The feature can be disabled by removing the daemonset, using `kubectl delete -f` command. On e2e clusters created on GCE, the daemonset can be removed by deleting the node-local-dns yaml from `/etc/kubernetes/addons/0-dns/nodelocaldns.yaml`
You can disable this feature by removing the DaemonSet, using `kubectl delete -f <manifest>` . You should also revert any changes you made to the kubelet configuration.
{{% /capture %}}
content/en/docs/tasks/administer-cluster/reserve-compute-resources.md
+1 -7
View File
@@ -98,13 +98,7 @@ be configured to use the `systemd` cgroup driver.
`kube-reserved` is meant to capture resource reservation for kubernetes system
daemons like the `kubelet`, `container runtime`, `node problem detector`, etc.
It is not meant to reserve resources for system daemons that are run as pods.
`kube-reserved` is typically a function of `pod density` on the nodes. [This
performance dashboard](http://node-perf-dash.k8s.io/#/builds) exposes `cpu` and
`memory` usage profiles of `kubelet` and `docker engine` at multiple levels of
pod density. [This blog
post](https://kubernetes.io/blog/2016/11/visualize-kubelet-performance-with-node-dashboard)
explains how the dashboard can be interpreted to come up with a suitable
`kube-reserved` reservation.
`kube-reserved` is typically a function of `pod density` on the nodes.
In addition to `cpu`, `memory`, and `ephemeral-storage`, `pid` may be
specified to reserve the specified number of process IDs for