In links to ref pages, use {{page.version}}.

This commit is contained in:
steveperry-53
2017-07-25 09:37:19 -07:00
committed by Andrew Chen
parent 28f3cfdd4f
commit f9ac865c5f
28 changed files with 98 additions and 98 deletions
@@ -241,7 +241,7 @@ the node.
The amount of resources available to Pods is less than the node capacity, because
system daemons use a portion of the available resources. The `allocatable` field
[NodeStatus](/docs/resources-reference/v1.6/#nodestatus-v1-core)
[NodeStatus](/docs/resources-reference/{{page.version}}/#nodestatus-v1-core)
gives the amount of resources that are available to Pods. For more information, see
[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md).
@@ -430,9 +430,9 @@ consistency across providers and platforms.
* Get hands-on experience
[assigning CPU and RAM resources to a container](/docs/tasks/configure-pod-container/assign-cpu-ram-container/).
* [Container](/docs/api-reference/v1.6/#container-v1-core)
* [Container](/docs/api-reference/{{page.version}}/#container-v1-core)
* [ResourceRequirements](/docs/resources-reference/v1.6/#resourcerequirements-v1-core)
* [ResourceRequirements](/docs/resources-reference/{{page.version}}/#resourcerequirements-v1-core)
{% endcapture %}
@@ -67,7 +67,7 @@ This is equivalent to `kubectl create -f` the following yaml:
{% include code.html language="yaml" file="nginx-svc.yaml" ghlink="/docs/concepts/services-networking/nginx-svc.yaml" %}
This specification will create a Service which targets TCP port 80 on any Pod with the `run: my-nginx` label, and expose it on an abstracted Service port (`targetPort`: is the port the container accepts traffic on, `port`: is the abstracted Service port, which can be any port other pods use to access the Service). View [service API object](/docs/api-reference/v1.6/#service-v1-core) to see the list of supported fields in service definition.
This specification will create a Service which targets TCP port 80 on any Pod with the `run: my-nginx` label, and expose it on an abstracted Service port (`targetPort`: is the port the container accepts traffic on, `port`: is the abstracted Service port, which can be any port other pods use to access the Service). View [service API object](/docs/api-reference/{{page.version}}/#service-v1-core) to see the list of supported fields in service definition.
Check your Service:
```shell
@@ -181,7 +181,7 @@ secret "nginxsecret" created
$ kubectl get secrets
NAME TYPE DATA AGE
default-token-il9rc kubernetes.io/service-account-token 1 1d
nginxsecret Opaque 2 1m
nginxsecret Opaque 2 1m
```
Now modify your nginx replicas to start an https server using the certificate in the secret, and the Service, to expose both ports (80 and 443):
@@ -28,7 +28,7 @@ Pods become isolated by having a NetworkPolicy that selects them. Once there is
## The `NetworkPolicy` Resource
See the [api-reference](/docs/api-reference/v1.7/#networkpolicy-v1-networking) for a full definition of the resource.
See the [api-reference](/docs/api-reference/{{page.version}}/#networkpolicy-v1-networking) for a full definition of the resource.
An example `NetworkPolicy` might look like this:
+6 -6
View File
@@ -102,7 +102,7 @@ voluntary disruptions. For example, a quorum-based application would
like to ensure that the number of replicas running is never brought below the
number needed for a quorum. A web front end might want to
ensure that the number of replicas serving load never falls below a certain
percentage of the total.
percentage of the total.
Cluster managers and hosting providers should use tools which
respect Pod Disruption Budgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)
@@ -136,7 +136,7 @@ during application updates is configured in the controller spec.
(Learn about [updating a deployment](/docs/concepts/cluster-administration/manage-deployment/#updating-your-application-without-a-service-outage).)
When a pod is evicted using the eviction API, it is gracefully terminated (see
`terminationGracePeriodSeconds` in [PodSpec](/docs/resources-reference/v1.6/#podspec-v1-core).)
`terminationGracePeriodSeconds` in [PodSpec](/docs/resources-reference/{{page.version}}/#podspec-v1-core).)
## PDB Example
@@ -200,7 +200,7 @@ The cluster state now looks like this:
| | pod-d *available* | pod-y |
Now, the cluster admin tries to drain `node-2`.
The drain command will try to evict the two pods in some order, say
The drain command will try to evict the two pods in some order, say
`pod-b` first and then `pod-d`. It will succeed at evicting `pod-b`.
But, when it tries to evict `pod-d`, it will be refused because that would leave only
one pod available for the deployment.
@@ -234,7 +234,7 @@ and Application Owner as separate roles with limited knowledge
of each other. This separation of responsibilities
may make sense in these scenarios:
- when there are many application teams sharing a Kubernetes cluster, and
- when there are many application teams sharing a Kubernetes cluster, and
there is natural specialization of roles
- when third-party tools or services are used to automate cluster management
@@ -249,7 +249,7 @@ you may not need to use Pod Disruption Budgets.
If you are a Cluster Administrator, and you need to perform a disruptive action on all
the nodes in your cluster, such as a node or system software upgrade, here are some options:
- Accept downtime during the upgrade.
- Accept downtime during the upgrade.
- Fail over to another complete replica cluster.
- No downtime, but may be costly both for the duplicated nodes,
and for human effort to orchestrate the switchover.
@@ -270,7 +270,7 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
* Learn more about [draining nodes](/docs/tasks/administer-cluster//safely-drain-node.md)
{% endcapture %}
{% endcapture %}
{% include templates/concept.md %}
@@ -36,7 +36,7 @@ Init Containers are exactly like regular Containers, except:
If an Init Container fails for a Pod, Kubernetes restarts the Pod repeatedly until the Init
Container succeeds. However, if the Pod has a `restartPolicy` of Never, it is not restarted.
To specify a Container as an Init Container, add the `initContainers` field on the PodSpec as a JSON array of objects of type [v1.Container](/docs/api-reference/v1.6/#container-v1-core) alongside the app `containers` array.
To specify a Container as an Init Container, add the `initContainers` field on the PodSpec as a JSON array of objects of type [v1.Container](/docs/api-reference/{{page.version}}/#container-v1-core) alongside the app `containers` array.
The status of the init containers is returned in `status.initContainerStatuses`
field as an array of the container statuses (similar to the `status.containerStatuses`
field).
@@ -185,7 +185,7 @@ pod "myapp-pod" created
$ kubectl get -f myapp.yaml
NAME READY STATUS RESTARTS AGE
myapp-pod 0/1 Init:0/2 0 6m
$ kubectl describe -f myapp.yaml
$ kubectl describe -f myapp.yaml
Name: myapp-pod
Namespace: default
[...]
@@ -20,7 +20,7 @@ This page describes the lifecycle of a Pod.
## Pod phase
A Pod's `status` field is a
[PodStatus](/docs/resources-reference/v1.6/#podstatus-v1-core)
[PodStatus](/docs/resources-reference/{{page.version}}/#podstatus-v1-core)
object, which has a `phase` field.
The phase of a Pod is a simple, high-level summary of where the Pod is in its
@@ -55,7 +55,7 @@ Here are the possible values for `phase`:
## Pod conditions
A Pod has a PodStatus, which has an array of
[PodConditions](/docs/resources-reference/v1.6/#podcondition-v1-core). Each element
[PodConditions](/docs/resources-reference/{{page.version}}/#podcondition-v1-core). Each element
of the PodCondition array has a `type` field and a `status` field. The `type`
field is a string, with possible values PodScheduled, Ready, Initialized, and
Unschedulable. The `status` field is a string, with possible values True, False,
@@ -63,22 +63,22 @@ and Unknown.
## Container probes
A [Probe](/docs/resources-reference/v1.6/#probe-v1-core) is a diagnostic
A [Probe](/docs/resources-reference/{{page.version}}/#probe-v1-core) is a diagnostic
performed periodically by the [kubelet](/docs/admin/kubelet/)
on a Container. To perform a diagnostic,
the kubelet calls a
[Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implemented by
the Container. There are three types of handlers:
* [ExecAction](/docs/resources-reference/v1.6/#execaction-v1-core):
* [ExecAction](/docs/resources-reference/{{page.version}}/#execaction-v1-core):
Executes a specified command inside the Container. The diagnostic
is considered successful if the command exits with a status code of 0.
* [TCPSocketAction](/docs/resources-reference/v1.6/#tcpsocketaction-v1-core):
* [TCPSocketAction](/docs/resources-reference/{{page.version}}/#tcpsocketaction-v1-core):
Performs a TCP check against the Container's IP address on
a specified port. The diagnostic is considered successful if the port is open.
* [HTTPGetAction](/docs/resources-reference/v1.6/#httpgetaction-v1-core):
* [HTTPGetAction](/docs/resources-reference/{{page.version}}/#httpgetaction-v1-core):
Performs an HTTP Get request against the Container's IP
address on a specified port and path. The diagnostic is considered successful
if the response has a status code greater than or equal to 200 and less than 400.
@@ -132,11 +132,11 @@ to stop.
## Pod and Container status
For detailed information about Pod Container status, see
[PodStatus](/docs/resources-reference/v1.6/#podstatus-v1-core)
[PodStatus](/docs/resources-reference/{{page.version}}/#podstatus-v1-core)
and
[ContainerStatus](/docs/resources-reference/v1.6/#containerstatus-v1-core).
[ContainerStatus](/docs/resources-reference/{{page.version}}/#containerstatus-v1-core).
Note that the information reported as Pod status depends on the current
[ContainerState](/docs/resources-reference/v1.6/#containerstatus-v1-core).
[ContainerState](/docs/resources-reference/{{page.version}}/#containerstatus-v1-core).
## Restart policy
+2 -2
View File
@@ -153,7 +153,7 @@ Pod is exposed as a primitive in order to facilitate:
* clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller"
* high-availability applications, which will expect pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions, image prefetching, or live pod migration [#3949](http://issue.k8s.io/3949)
There is new first-class support for stateful pods with the [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) controller (currently in beta). The feature was alpha in 1.4 and was called [PetSet](/docs/concepts/workloads/controllers/petset/). For prior versions of Kubernetes, best practice for having stateful pods is to create a replication controller with `replicas` equal to `1` and a corresponding service, see [this MySQL deployment example](/docs/tutorials/stateful-application/run-stateful-application/).
There is new first-class support for stateful pods with the [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) controller (currently in beta). The feature was alpha in 1.4 and was called [PetSet](/docs/concepts/workloads/controllers/petset/). For prior versions of Kubernetes, best practice for having stateful pods is to create a replication controller with `replicas` equal to `1` and a corresponding service, see [this MySQL deployment example](/docs/tutorials/stateful-application/run-stateful-application/).
## Termination of Pods
@@ -196,4 +196,4 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'
Pod is a top-level resource in the Kubernetes REST API. More details about the
API object can be found at: [Pod API
object](/docs/api-reference/v1.6/#pod-v1-core).
object](/docs/api-reference/{{page.version}}/#pod-v1-core).