Merge branch 'master' into patch-54
This commit is contained in:
Cody Clark
@@ -5,7 +5,7 @@ Initialize a federation control plane
|
||||
### Synopsis
|
||||
|
||||
|
||||
Init initializes a federation control plane.
|
||||
Initialize a federation control plane.
|
||||
|
||||
Federation control plane is hosted inside a Kubernetes
|
||||
cluster. The host cluster must be specified using the
|
||||
|
||||
@@ -476,7 +476,7 @@ $ kubectl set image deploy/nginx-deployment nginx=nginx:sometag
|
||||
deployment "nginx-deployment" image updated
|
||||
```
|
||||
|
||||
The image update starts a new rollout with ReplicaSet nginx-deployment-1989198191 but it's blocked due to the
|
||||
The image update starts a new rollout with ReplicaSet nginx-deployment-1989198191, but it's blocked due to the
|
||||
maxUnavailable requirement that we mentioned above.
|
||||
|
||||
```shell
|
||||
|
||||
@@ -889,7 +889,7 @@ At this point you should be able to run through one of the basic examples, such
|
||||
|
||||
### Running the Conformance Test
|
||||
|
||||
You may want to try to run the [Conformance test](http://releases.k8s.io/{{page.githubbranch}}/hack/conformance-test.sh). Any failures may give a hint as to areas that need more attention.
|
||||
You may want to try to run the [Conformance test](http://releases.k8s.io/{{page.githubbranch}}/test/e2e_node/conformance/run_test.sh). Any failures may give a hint as to areas that need more attention.
|
||||
|
||||
### Networking
|
||||
|
||||
|
||||
@@ -16,8 +16,8 @@ In future Kubernetes releases, cloud vendors should link code that satisfies the
|
||||
|
||||
To build cloud-controller-manager for your cloud, follow these steps:
|
||||
|
||||
* Write a cloudprovider that satisfies the [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go).
|
||||
* Link the cloudprovider to cloud-controller-manager
|
||||
1. Write a cloudprovider that satisfies the [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go).
|
||||
2. Link the cloudprovider to cloud-controller-manager.
|
||||
|
||||
The methods in [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go) are self-explanatory. All of the
|
||||
[existing providers](https://git.k8s.io/kubernetes/pkg/cloudprovider/providers) satisfy this interface. If your cloud is already a part
|
||||
|
||||
@@ -78,7 +78,7 @@ kubectl --context=rivendell label cluster gondor key1=value1 key2=value2
|
||||
|
||||
Starting in Kubernetes 1.7, there is alpha support for directing objects across the federated clusters with the annotation `federation.alpha.kubernetes.io/cluster-selector`. The *ClusterSelector* is conceptually similar to `nodeSelector`, but instead of selecting against labels on nodes, it selects against labels on federated clusters.
|
||||
|
||||
The annotation value must be json formatted and must be parsable into the [ClusterSelector API type](/docs/reference/federation/v1beta1/definitions/#_v1beta1_clusterselector). For example: `[{"key": "load", "operator": "Lt", "values": ["10"]}]`. Content that doesn't parse correctly will throw an error and prevent distribution of the object to any federated clusters. Objects of type Configmap, Secret, Daemonset, Service and Ingress are included in the alpha implementation.
|
||||
The annotation value must be JSON formatted and must be parsable into the [ClusterSelector API type](/docs/reference/federation/v1beta1/definitions/#_v1beta1_clusterselector). For example: `[{"key": "load", "operator": "Lt", "values": ["10"]}]`. Content that doesn't parse correctly will throw an error and prevent distribution of the object to any federated clusters. Objects of type ConfigMap, Secret, Daemonset, Service and Ingress are included in the alpha implementation.
|
||||
|
||||
Here is an example ClusterSelector annotation, which will only select clusters WITH the label `pci=true` and WITHOUT the label `environment=test`:
|
||||
|
||||
|
||||
@@ -180,7 +180,7 @@ can’t it is considered a failure.
|
||||
|
||||
{% include code.html language="yaml" file="tcp-liveness-readiness.yaml" ghlink="/docs/tasks/configure-pod-container/tcp-liveness-readiness.yaml" %}
|
||||
|
||||
As you can see, configuration for a TCP check is quite similar to a HTTP check.
|
||||
As you can see, configuration for a TCP check is quite similar to an HTTP check.
|
||||
This example uses both readiness and liveness probes. The kubelet will send the
|
||||
first readiness probe 5 seconds after the container starts. This will attempt to
|
||||
connect to the `goproxy` container on port 8080. If the probe succeeds, the pod
|
||||
|
||||
@@ -48,7 +48,7 @@ for configuring where and how audit logs are handled:
|
||||
- `audit-log-path` - enables the audit log pointing to a file where the requests are being logged to, '-' means standard out.
|
||||
- `audit-log-maxage` - specifies maximum number of days to retain old audit log files based on the timestamp encoded in their filename.
|
||||
- `audit-log-maxbackup` - specifies maximum number of old audit log files to retain.
|
||||
- `audit-log-maxsize` - specifies maximum size in megabytes of the audit log file before it gets rotated. Defaults to 100MB
|
||||
- `audit-log-maxsize` - specifies maximum size in megabytes of the audit log file before it gets rotated. Defaults to 100MB.
|
||||
|
||||
If an audit log file already exists, Kubernetes appends new audit logs to that file.
|
||||
Otherwise, Kubernetes creates an audit log file at the location you specified in
|
||||
@@ -80,7 +80,7 @@ webhooks.
|
||||
The structure of audit events changes when enabling the `AdvancedAuditing` feature
|
||||
flag. This includes some cleanups, such as the `method` reflecting the verb evaluated
|
||||
by the [authorization layer](/docs/admin/authorization/) instead of the [HTTP verb](/docs/admin/authorization/#determine-the-request-verb).
|
||||
Also, instead of always generating two events per request, events are recorded with an associated "stage."
|
||||
Also, instead of always generating two events per request, events are recorded with an associated "stage".
|
||||
The known stages are:
|
||||
|
||||
- `RequestReceived` - The stage for events generated as soon as the audit handler receives the request.
|
||||
@@ -107,7 +107,7 @@ The policy file holds rules that determine the level of an event. Known audit le
|
||||
- `Request` - log event metadata and request body but not response body.
|
||||
- `RequestResponse` - log event metadata, request and response bodies.
|
||||
|
||||
When an event is processed it's compared against the list of rules in order.
|
||||
When an event is processed, it's compared against the list of rules in order.
|
||||
The first matching rule sets the audit level of the event. The audit policy is
|
||||
defined by the [`audit.k8s.io` API group][audit-api].
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ Pod:
|
||||
|
||||
1. In your shell, run the `printenv` command to list the environment variables.
|
||||
|
||||
root@envar-demo:/# printenv
|
||||
root@envar-demo:/# printenv
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ This page describes how users can consume GPUs and the current limitations.
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
1. Kubernetes nodes have to be pre-installed with Nvidia drivers. Kubelet will not detect Nvidia GPUs otherwise. Try to re-install nvidia drivers if kubelet fails to expose Nvidia GPUs as part of Node Capacity. After installing the driver, run `nvidia-docker-plugin` to confirm that all drivers have been loaded.
|
||||
1. Kubernetes nodes have to be pre-installed with Nvidia drivers. Kubelet will not detect Nvidia GPUs otherwise. Try to re-install Nvidia drivers if kubelet fails to expose Nvidia GPUs as part of Node Capacity. After installing the driver, run `nvidia-docker-plugin` to confirm that all drivers have been loaded.
|
||||
2. A special **alpha** feature gate `Accelerators` has to be set to true across the system: `--feature-gates="Accelerators=true"`.
|
||||
3. Nodes must be using `docker engine` as the container runtime.
|
||||
|
||||
|
||||
@@ -14,8 +14,8 @@ nodes.
|
||||
{% capture prerequisites %}
|
||||
* You are the owner of an application running on a Kubernetes cluster that requires
|
||||
high availability.
|
||||
* You should know how to deploy [Replicated Stateless Applications](/docs/tasks/run-application/run-stateless-application-deployment.md)
|
||||
and/or [Replicated Stateful Applications](/docs/tasks/run-application/run-replicated-stateful-application.md).
|
||||
* You should know how to deploy [Replicated Stateless Applications](/docs/tasks/run-application/run-stateless-application-deployment/)
|
||||
and/or [Replicated Stateful Applications](/docs/tasks/run-application/run-replicated-stateful-application/).
|
||||
* You should have read about [Pod Disruptions](/docs/concepts/workloads/pods/disruptions/).
|
||||
* You should confirm with your cluster owner or service provider that they respect
|
||||
Pod Disruption Budgets.
|
||||
|
||||
@@ -54,7 +54,7 @@ kubectl run [-i] [--tty] --attach <name> --image=<image>
|
||||
Unlike `docker run ...`, if `--attach` is specified, we attach to `stdin`, `stdout` and `stderr`, there is no ability to control which streams are attached (`docker -a ...`).
|
||||
|
||||
Because we start a Deployment for your container, it will be restarted if you terminate the attached process (e.g. `ctrl-c`), this is different from `docker run -it`.
|
||||
To destroy the Deployment (and its pods) you need to run `kubectl delete deployment <name>`
|
||||
To destroy the Deployment (and its pods) you need to run `kubectl delete deployment <name>`.
|
||||
|
||||
#### docker ps
|
||||
|
||||
@@ -78,7 +78,7 @@ nginx-app-5jyvm 1/1 Running 0 1h
|
||||
|
||||
#### docker attach
|
||||
|
||||
How do I attach to a process that is already running in a container? Checkout [kubectl attach](/docs/user-guide/kubectl/{{page.version}}/#attach)
|
||||
How do I attach to a process that is already running in a container? Checkout [kubectl attach](/docs/user-guide/kubectl/{{page.version}}/#attach).
|
||||
|
||||
With docker:
|
||||
|
||||
@@ -178,7 +178,7 @@ See [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administrat
|
||||
|
||||
How do I stop and delete a running process? Checkout [kubectl delete](/docs/user-guide/kubectl/{{page.version}}/#delete).
|
||||
|
||||
With docker
|
||||
With docker:
|
||||
|
||||
```shell
|
||||
$ docker ps
|
||||
|
||||
@@ -231,7 +231,7 @@ $ kubectl taint nodes foo dedicated=special-user:NoSchedule
|
||||
|
||||
## Resource types
|
||||
|
||||
The following table includes a list of all the supported resource types and their abbreviated aliases.
|
||||
The following table includes a list of all the supported resource types and their abbreviated aliases:
|
||||
|
||||
Resource type | Abbreviated alias
|
||||
-------------------- | --------------------
|
||||
|
||||
@@ -26,12 +26,16 @@ where `command`, `TYPE`, `NAME`, and `flags` are:
|
||||
* `NAME`: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example `$ kubectl get pods`.
|
||||
|
||||
When performing an operation on multiple resources, you can specify each resource by type and name or specify one or more files:
|
||||
|
||||
* To specify resources by type and name:
|
||||
* To group resources if they are all the same type: `TYPE1 name1 name2 name<#>`<br/>.
|
||||
|
||||
* To group resources if they are all the same type: `TYPE1 name1 name2 name<#>`.<br/>
|
||||
Example: `$ kubectl get pod example-pod1 example-pod2`
|
||||
* To specify multiple resource types individually: `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`<br/>.
|
||||
|
||||
* To specify multiple resource types individually: `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`.<br/>
|
||||
Example: `$ kubectl get pod/example-pod1 replicationcontroller/example-rc1`
|
||||
* To specify resources with one or more files: `-f file1 -f file2 -f file<#>`
|
||||
|
||||
* To specify resources with one or more files: `-f file1 -f file2 -f file<#>`
|
||||
[Use YAML rather than JSON](/docs/concepts/configuration/overview/#general-config-tips) since YAML tends to be more user-friendly, especially for configuration files.<br/>
|
||||
Example: `$ kubectl get pod -f ./pod.yaml`
|
||||
* `flags`: Specifies optional flags. For example, you can use the `-s` or `--server` flags to specify the address and port of the Kubernetes API server.<br/>
|
||||
|
||||
Reference in New Issue
Block a user