Merge branch 'master' into release-1.8
This commit is contained in:
steveperry-53
+24
@@ -22,6 +22,30 @@ defaults:
|
||||
version: "v1.7"
|
||||
githubbranch: "master"
|
||||
docsbranch: "master"
|
||||
versions:
|
||||
- fullversion: "v1.7.3"
|
||||
version: "v1.7"
|
||||
githubbranch: "v1.7.3"
|
||||
docsbranch: "release-1.7"
|
||||
url: https://kubernetes.io/docs/home/
|
||||
- fullversion: "v1.6.8"
|
||||
version: "v1.6"
|
||||
githubbranch: "v1.6.8"
|
||||
docsbranch: "release-1.6"
|
||||
url: https://v1-6.docs.kubernetes.io/docs/home/
|
||||
- fullversion: "v1.5.7"
|
||||
version: "v1.5"
|
||||
githubbranch: "v1.5.7"
|
||||
docsbranch: "release-1.5"
|
||||
url: https://v1-5.docs.kubernetes.io/docs/
|
||||
- fullversion: "v1.4.12"
|
||||
version: "v1.4"
|
||||
githubbranch: "v1.4.12"
|
||||
docsbranch: "release-1.4"
|
||||
url: https://v1-4.docs.kubernetes.io/docs/
|
||||
deprecated: false
|
||||
currentUrl: https://kubernetes.io/docs/home/
|
||||
nextUrl: http://kubernetes-io-vnext-staging.netlify.com/
|
||||
-
|
||||
scope:
|
||||
path: "docs"
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
{% if page.deprecated %}
|
||||
<section id="deprecationWarning">
|
||||
<main>
|
||||
<div class="content deprecation-warning">
|
||||
<h3>
|
||||
Documentation for Kubernetes {{ page.version}} is no longer actively maintained. The version you are currently viewing is a static snapshot.
|
||||
For up-to-date documentation, see the <a href="{{ page.currentUrl }}">latest</a> version.
|
||||
</h3>
|
||||
</div>
|
||||
</main>
|
||||
</section>
|
||||
{% endif %}
|
||||
@@ -8,6 +8,7 @@
|
||||
<link rel="stylesheet" type="text/css" href="/css/jquery-ui.min.css">
|
||||
<link rel="stylesheet" type="text/css" href="/css/sweetalert.css">
|
||||
<link rel="stylesheet" type="text/css" href="/css/callouts.css">
|
||||
{% if page.deprecated %}<link rel="stylesheet" type="text/css" href="/css/deprecation-warning.css">{% endif %}
|
||||
{% if page.class == "gridPage" %}<link rel="stylesheet" type="text/css" href="/css/gridpage.css">{% endif %}
|
||||
{% if page.css %}<link rel="stylesheet" type="text/css" href="{{ page.css }}"><!-- custom css added -->{% else %}<!-- no custom css detected -->{% endif %}
|
||||
|
||||
|
||||
@@ -10,6 +10,17 @@
|
||||
<li><a href="/partners/">Partners</a></li>
|
||||
<li><a href="/community/">Community</a></li>
|
||||
<li><a href="/case-studies/">Case Studies</a></li>
|
||||
<li>
|
||||
<a href="#">
|
||||
{{page.version}} <span class="ui-icon ui-icon-carat-1-s"></span>
|
||||
</a>
|
||||
<ul>
|
||||
{% for version in page.versions %}
|
||||
<li><a href="{{ version.url }}">{{ version.version }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
</li>
|
||||
</li>
|
||||
</ul>
|
||||
<!-- <a href="/docs/home" class="button" id="viewDocs" data-auto-burger-exclude>View Documentation</a> -->
|
||||
<a href="/docs/tutorials/kubernetes-basics/" class="button" id="tryKubernetes" data-auto-burger-exclude>Try Kubernetes</a>
|
||||
|
||||
+68
-13
@@ -72,10 +72,10 @@
|
||||
},
|
||||
{
|
||||
type: 0,
|
||||
name: 'Rancher',
|
||||
logo: 'rancher',
|
||||
name: 'Rancher Labs',
|
||||
logo: 'rancher-labs',
|
||||
link: 'http://rancher.com/kubernetes/',
|
||||
blurb: 'Rancher is an open-source, production-ready container management platform that makes it easy to deploy and leverage Kubernetes in the enterprise.'
|
||||
blurb: 'Rancher is an open-source, production-ready container management platform that makes it easy to deploy and manage Kubernetes.'
|
||||
},
|
||||
{
|
||||
type: 0,
|
||||
@@ -263,7 +263,7 @@
|
||||
type: 0,
|
||||
name: 'Tigera',
|
||||
logo: 'tigera',
|
||||
link: 'http://docs.projectcalico.org/v1.5/getting-started/kubernetes/',
|
||||
link: 'http://docs.projectcalico.org/latest/getting-started/kubernetes/',
|
||||
blurb: 'Tigera builds high performance, policy driven, cloud native networking solutions for Kubernetes.'
|
||||
},
|
||||
{
|
||||
@@ -280,13 +280,6 @@
|
||||
link: 'https://harbur.io/',
|
||||
blurb: 'Based in Barcelona, Harbur is a consulting firm that helps companies deploy self-healing solutions empowered by Container technologies'
|
||||
},
|
||||
{
|
||||
type: 1,
|
||||
name: 'Endocode',
|
||||
logo: 'endocode',
|
||||
link: 'https://endocode.com/kubernetes/',
|
||||
blurb: 'Endocode practices and teaches the open source way. Kernel to cluster - Dev to Ops. We offer Kubernetes trainings, services and support.'
|
||||
},
|
||||
{
|
||||
type: 0,
|
||||
name: 'Spotinst',
|
||||
@@ -424,7 +417,7 @@
|
||||
type: 0,
|
||||
name: 'Cobe',
|
||||
logo: 'cobe',
|
||||
link: 'https://cobe.io/blog/posts/problems-within-your-kubernetes-cluster/',
|
||||
link: 'https://cobe.io/product-page/',
|
||||
blurb: 'Manage Kubernetes clusters with a live, searchable model that captures all relationships and performance data in full visualised context.'
|
||||
},
|
||||
{
|
||||
@@ -510,8 +503,70 @@
|
||||
logo: 'codedellemc',
|
||||
link: 'https://blog.codedellemc.com',
|
||||
blurb: 'Respected as a thought leader in storage persistence for containerized applications. Contributed significant work to K8 and Ecosystem'
|
||||
},
|
||||
{
|
||||
type: 0,
|
||||
name: 'SUSE Llc.',
|
||||
logo: 'suse',
|
||||
link: 'https://www.suse.com/products/caas-platform/',
|
||||
blurb: 'SUSE delivers Kubernetes as part of SUSE CaaS Platform and SUSE OpenStack Cloud, for enterprises that want truly open, open source solutions for cloud-native applications.'
|
||||
},
|
||||
{
|
||||
type: 0,
|
||||
name: 'Instana',
|
||||
logo: 'instana',
|
||||
link: 'https://www.instana.com/supported-technologies/',
|
||||
blurb: 'Instana monitors the infrastructure, containers and services deployed on a Kubernetes cluster.'
|
||||
},
|
||||
{
|
||||
type: 0,
|
||||
name: 'Netsil',
|
||||
logo: 'netsil',
|
||||
link: 'https://netsil.com/kubernetes/',
|
||||
blurb: 'Generate a real-time, auto-discovered application topology map! Monitor Kubernetes pods and namespaces without any code instrumentation.'
|
||||
},
|
||||
{
|
||||
type: 0,
|
||||
name: 'Treasure Data',
|
||||
logo: 'treasure-data',
|
||||
link: 'https://fluentd.treasuredata.com/kubernetes-logging/',
|
||||
blurb: 'Fluentd Enterprise brings smart, secure logging to Kubernetes, and brings integrations with backends such as Splunk, Kafka, or AWS S3.'
|
||||
},
|
||||
{
|
||||
type: 0,
|
||||
name: 'IBM',
|
||||
logo: 'IBM',
|
||||
link: 'https://www.ibm.com/cloud-computing/bluemix/containers',
|
||||
blurb: 'IBM Container Service is a managed k8s environment with built-in cluster security and isolation while leveraging services including Watson, IoT, Weather, etc.'
|
||||
},
|
||||
{
|
||||
type: 1,
|
||||
name: 'IBM',
|
||||
logo: 'IBM',
|
||||
link: 'https://www.ibm.com/cloud-computing/bluemix/containers',
|
||||
blurb: 'IBM Container Service is a managed k8s environment with built-in cluster security and isolation while leveraging services including Watson, IoT, Weather, etc.'
|
||||
},
|
||||
{
|
||||
type: 1,
|
||||
name: 'Kenzan',
|
||||
logo: 'Kenzan',
|
||||
link: 'http://kenzan.com/?ref=kubernetes',
|
||||
blurb: 'Kenzan is a software engineering and full-service consulting firm that provides customized, end-to-end solutions that drive change through digital transformation.'
|
||||
},
|
||||
{
|
||||
type: 0,
|
||||
name: 'Kublr',
|
||||
logo: 'kublr',
|
||||
link: 'http://kublr.com',
|
||||
blurb: 'Simplify your Kubernetes experience with a fully production-ready, enterprise-grade cluster management platform.'
|
||||
},
|
||||
{
|
||||
type: 0,
|
||||
name: 'Endocode AG',
|
||||
logo: 'endocode',
|
||||
link: 'https://endocode.com/kubernetes/',
|
||||
blurb: 'Endocode practices and teaches the open source way. Kernel to cluster - Dev to Ops. We offer Kubernetes trainings, services and support.'
|
||||
}
|
||||
|
||||
]
|
||||
|
||||
var isvContainer = document.getElementById('isvContainer')
|
||||
|
||||
@@ -35,6 +35,8 @@
|
||||
</div>
|
||||
</section>
|
||||
|
||||
{% include deprecation-warning.html %}
|
||||
|
||||
<section id="encyclopedia">
|
||||
<div id="docsToc">
|
||||
<div class="pi-accordion">
|
||||
|
||||
+29
-1
@@ -258,12 +258,40 @@ ul.global-nav
|
||||
left: 0
|
||||
background: #fff
|
||||
|
||||
ul
|
||||
display: none
|
||||
position: fixed
|
||||
top: 40px
|
||||
text-align: left
|
||||
|
||||
li
|
||||
display: block
|
||||
height: 28px
|
||||
|
||||
a
|
||||
background: $dark-grey
|
||||
color: #fff
|
||||
padding: 7px
|
||||
|
||||
li:last-child
|
||||
a
|
||||
border-radius: 7px
|
||||
|
||||
li:hover
|
||||
ul
|
||||
display: block
|
||||
|
||||
|
||||
.flip-nav ul.global-nav li a,
|
||||
.open-nav ul.global-nav li a,
|
||||
color: #333
|
||||
color: $dark-grey
|
||||
|
||||
.flip-nav ul.global-nav li ul li a,
|
||||
background: #fff
|
||||
color: $dark-grey
|
||||
|
||||
.flip-nav ul.global-nav li a.active:after,
|
||||
.flip-nav ul.global-nav li ul li a.active:after,
|
||||
.open-nav ul.global-nav li a.active:after,
|
||||
|
||||
background: $blue
|
||||
|
||||
@@ -26,8 +26,9 @@ title: 运行应用程序的多个实例
|
||||
<div class="col-md-8">
|
||||
<h3>应用程序伸缩</h3>
|
||||
|
||||
<p>在之前的模块中，我们创建了一个 <a href="http://kubernetes.io/docs/user-guide/deployments/"> Deployment</a>，然后通过 <a href="http://kubernetes.io/docs/user-guide/services/">Service</a>让应用程序外部可见。Deployment 仅为我们的应用程序创建了一个 Pod。 当流量增加时，我们将需要
|
||||
应用程序以跟上用户需求。</p>
|
||||
<p>在之前的模块中，我们创建了一个 <a href="http://kubernetes.io/docs/user-guide/deployments/"> Deployment</a>，然后通过 <a href="http://kubernetes.io/docs/user-guide/services/">Service</a>让应用程序外部可见。
|
||||
Deployment 仅为我们的应用程序创建了一个 Pod。
|
||||
当流量增加时，我们将需要扩展应用程序以跟上用户需求。</p>
|
||||
|
||||
<p><b>Scaling</b> 是通过更改 Deployment 中的副本数量实现的。</p>
|
||||
|
||||
@@ -86,7 +87,8 @@ title: 运行应用程序的多个实例
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
|
||||
<p>扩展 Deployment 将确保新创建的 Pods 会调度到可用资源的 Node 节点上，收缩会保证 Pods 数量减少至新的所需状态。 Kubernetes 还支持 Pods 的 <a href="http://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/"> 自动缩放版 </a> ，但不在本教程范围之内。收缩到零也是可以的，此时它将终止指定 Deployment 的所有 Pod。 </p>
|
||||
<p>扩展 Deployment 将确保创建新的 Pods 并将其调度到拥有可用资源的 Node 节点上，收缩会保证 Pods 数量减少至新的所需状态。
|
||||
Kubernetes 还支持 Pods 的 <a href="http://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/"> 自动缩放 </a> ，但不在本教程范围之内。收缩到零也是可以的，此时它将终止指定 Deployment 的所有 Pod。 </p>
|
||||
|
||||
<p>运行应用程序的多个实例需要一种将流量分发给所有实例的方法。服务有内置的负载均衡器，可将网络流量分配给 Deployment 暴露的所有 Pods。服务通过使用 endpoints 持续监控运行的 Pods，以确保流量仅发送到可用的 Pods。</p>
|
||||
|
||||
@@ -102,7 +104,7 @@ title: 运行应用程序的多个实例
|
||||
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<p> 一旦您有应用程序的多个实例，您将能够滚动更新，而不会停止服务————我们将在下一个模块中介绍这些。现在，我们去在线终端对我们的应用程序进行伸缩。</p>
|
||||
<p> 一旦您有应用程序的多个实例，您将能够滚动更新，而不会停止服务，我们将在下一个模块中介绍这些。现在，我们去在线终端对我们的应用程序进行伸缩。</p>
|
||||
</div>
|
||||
</div>
|
||||
<br>
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
.deprecation-warning {
|
||||
padding: 20px;
|
||||
margin: 20px 0;
|
||||
border-radius: 3px;
|
||||
background-color: #eeeeee;
|
||||
}
|
||||
@@ -43,7 +43,7 @@ with the request:
|
||||
|
||||
* Username: a string which identifies the end user. Common values might be `kube-admin` or `jane@example.com`.
|
||||
* UID: a string which identifies the end user and attempts to be more consistent and unique than username.
|
||||
* Groups: a set of strings which associate users with as set of commonly grouped users.
|
||||
* Groups: a set of strings which associate users with a set of commonly grouped users.
|
||||
* Extra fields: a map of strings to list of strings which holds additional information authorizers may find useful.
|
||||
|
||||
All values are opaque to the authentication system and only hold significance
|
||||
|
||||
@@ -79,7 +79,7 @@ cluster. This is also the address used to construct the suggested `kubeadm
|
||||
join` line at the end of the init process. If not set (or set to 0.0.0.0) then
|
||||
IP for the default interface will be used.
|
||||
|
||||
This address is also added to the certifcate that the API Server uses.
|
||||
This address is also added to the certificate that the API Server uses.
|
||||
|
||||
- `--apiserver-bind-port`
|
||||
|
||||
|
||||
@@ -73,6 +73,18 @@ available and can tolerate the loss of a zone, the control plane is
|
||||
located in a single zone. Users that want a highly available control
|
||||
plane should follow the [high availability](/docs/admin/high-availability) instructions.
|
||||
|
||||
* StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with
|
||||
pod affinity or anti-affinity policies.
|
||||
|
||||
* If the name of the StatefulSet contains dashes ("-"), volume zone spreading
|
||||
may not provide a uniform distribution of storage across zones.
|
||||
|
||||
* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass
|
||||
needs to be configured for a specific, single zone, or the PVs need to be
|
||||
statically provisioned in a specific zone. Another workaround is to use a
|
||||
StatefulSet, which will ensure that all the volumes for a replica are
|
||||
provisioned in the same zone.
|
||||
|
||||
|
||||
## Walkthrough
|
||||
|
||||
|
||||
@@ -123,7 +123,7 @@ On IaaS providers such as Google Compute Engine or Amazon Web Services, a VM exi
|
||||
zone](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html).
|
||||
We suggest that all the VMs in a Kubernetes cluster should be in the same availability zone, because:
|
||||
|
||||
- compared to having a single global Kubernetes cluster, there are fewer single-points of failure
|
||||
- compared to having a single global Kubernetes cluster, there are fewer single-points of failure.
|
||||
- compared to a cluster that spans availability zones, it is easier to reason about the availability properties of a
|
||||
single-zone cluster.
|
||||
- when the Kubernetes developers are designing the system (e.g. making assumptions about latency, bandwidth, or
|
||||
@@ -132,8 +132,8 @@ We suggest that all the VMs in a Kubernetes cluster should be in the same availa
|
||||
It is okay to have multiple clusters per availability zone, though on balance we think fewer is better.
|
||||
Reasons to prefer fewer clusters are:
|
||||
|
||||
- improved bin packing of Pods in some cases with more nodes in one cluster (less resource fragmentation)
|
||||
- reduced operational overhead (though the advantage is diminished as ops tooling and processes matures)
|
||||
- improved bin packing of Pods in some cases with more nodes in one cluster (less resource fragmentation).
|
||||
- reduced operational overhead (though the advantage is diminished as ops tooling and processes matures).
|
||||
- reduced costs for per-cluster fixed resource costs, e.g. apiserver VMs (but small as a percentage
|
||||
of overall cluster cost for medium to large clusters).
|
||||
|
||||
|
||||
@@ -69,7 +69,7 @@ When you then run `kubectl create -f pod.yaml`, the pod will get scheduled on th
|
||||
|
||||
## Interlude: built-in node labels
|
||||
|
||||
In addition to labels you [attach yourself](#step-one-attach-label-to-the-node), nodes come pre-populated
|
||||
In addition to labels you [attach](#step-one-attach-label-to-the-node), nodes come pre-populated
|
||||
with a standard set of labels. As of Kubernetes v1.4 these labels are
|
||||
|
||||
* `kubernetes.io/hostname`
|
||||
@@ -147,7 +147,7 @@ For more information on node affinity, see the design doc
|
||||
### Inter-pod affinity and anti-affinity (beta feature)
|
||||
|
||||
Inter-pod affinity and anti-affinity were introduced in Kubernetes 1.4.
|
||||
Inter-pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to schedule on *based on
|
||||
Inter-pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to be scheduled *based on
|
||||
labels on pods that are already running on the node* rather than based on labels on nodes. The rules are of the form "this pod should (or, in the case of
|
||||
anti-affinity, should not) run in an X if that X is already running one or more pods that meet rule Y." Y is expressed
|
||||
as a LabelSelector with an associated list of namespaces (or "all" namespaces); unlike nodes, because pods are namespaced
|
||||
@@ -214,7 +214,7 @@ be co-located in the same defined topology, eg., the same node.
|
||||
|
||||
##### Always co-located in the same node
|
||||
|
||||
In a three node cluster, a web application has in-memory cache such as redis, we want the web-servers to be co-located with the cache as much as possible.
|
||||
In a three node cluster, a web application has in-memory cache such as redis. We want the web-servers to be co-located with the cache as much as possible.
|
||||
Here is the yaml snippet of a simple redis deployment with three replicas and selector label `app=store`
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -509,7 +509,7 @@ Create a secret containing some ssh keys:
|
||||
$ kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub
|
||||
```
|
||||
|
||||
**Security Note:** think carefully before sending your own ssh keys: other users of the cluster may have access to the secret. Use a service account which you want to have accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised.
|
||||
**Security Note:** think carefully before sending your own ssh keys: other users of the cluster may have access to the secret. Use a service account which you want to be accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised.
|
||||
|
||||
|
||||
Now we can create a pod which references the secret with the ssh key and
|
||||
|
||||
@@ -45,7 +45,7 @@ into three categories:
|
||||
- *Controlled by a boolean*: Fields of this type default to the most
|
||||
restrictive value.
|
||||
- *Controlled by an allowable set*: Fields of this type are checked
|
||||
against the set to ensure their value is allowed.
|
||||
against the set to ensure their values are allowed.
|
||||
- *Controlled by a strategy*: Items that have a strategy to provide
|
||||
a mechanism to generate the value and a mechanism to ensure that a
|
||||
specified value falls into the set of allowable values.
|
||||
|
||||
@@ -233,7 +233,7 @@ restrictions around nodes: pods from several namespaces may run on the same node
|
||||
|
||||
## Example
|
||||
|
||||
See a [detailed example for how to use resource quota](/docs/tasks/configure-pod-container/apply-resource-quota-limit/).
|
||||
See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/).
|
||||
|
||||
## Read More
|
||||
|
||||
|
||||
@@ -513,6 +513,7 @@ You can pause a Deployment before triggering one or more updates and then resume
|
||||
apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.
|
||||
|
||||
For example, with a Deployment that was just created:
|
||||
|
||||
```shell
|
||||
$ kubectl get deploy
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
@@ -523,18 +524,21 @@ nginx-2142116321 3 3 3 1m
|
||||
```
|
||||
|
||||
Pause by running the following command:
|
||||
|
||||
```shell
|
||||
$ kubectl rollout pause deployment/nginx-deployment
|
||||
deployment "nginx-deployment" paused
|
||||
```
|
||||
|
||||
Then update the image of the Deployment:
|
||||
|
||||
```shell
|
||||
$ kubectl set image deploy/nginx-deployment nginx=nginx:1.9.1
|
||||
deployment "nginx-deployment" image updated
|
||||
```
|
||||
|
||||
Notice that no new rollout started:
|
||||
|
||||
```shell
|
||||
$ kubectl rollout history deploy/nginx-deployment
|
||||
deployments "nginx"
|
||||
@@ -547,6 +551,7 @@ nginx-2142116321 3 3 3 2m
|
||||
```
|
||||
|
||||
You can make as many updates as you wish, for example, update the resources that will be used:
|
||||
|
||||
```shell
|
||||
$ kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi
|
||||
deployment "nginx" resource requirements updated
|
||||
@@ -556,6 +561,7 @@ The initial state of the Deployment prior to pausing it will continue its functi
|
||||
the Deployment will not have any effect as long as the Deployment is paused.
|
||||
|
||||
Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates:
|
||||
|
||||
```shell
|
||||
$ kubectl rollout resume deploy/nginx-deployment
|
||||
deployment "nginx" resumed
|
||||
|
||||
@@ -291,7 +291,7 @@ unique to the pods of that job, and which matches unrelated pods, then pods of t
|
||||
job may be deleted, or this job may count other pods as completing it, or one or both
|
||||
of the jobs may refuse to create pods or run to completion. If a non-unique selector is
|
||||
chosen, then other controllers (e.g. ReplicationController) and their pods may behave
|
||||
in unpredicatable ways too. Kubernetes will not stop you from making a mistake when
|
||||
in unpredictable ways too. Kubernetes will not stop you from making a mistake when
|
||||
specifying `spec.selector`.
|
||||
|
||||
Here is an example of a case when you might want to use this feature.
|
||||
|
||||
@@ -19,7 +19,7 @@ A Pod encapsulates an application container (or, in some cases, multiple contain
|
||||
|
||||
> [Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other container runtimes as well.
|
||||
|
||||
Pods are employed in a number of ways in a Kubernetes cluster, including:
|
||||
Pods in a Kubernetes cluster can be used in two main ways:
|
||||
|
||||
* **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
|
||||
* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.
|
||||
@@ -63,9 +63,9 @@ A Controller can create and manage multiple Pods for you, handling replication a
|
||||
|
||||
Some examples of Controllers that contain one or more pods include:
|
||||
|
||||
* Deployment
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/)
|
||||
* DaemonSet
|
||||
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
|
||||
|
||||
In general, Controllers use a Pod Template that you provide to create the Pods for which it is responsible.
|
||||
|
||||
@@ -81,7 +81,7 @@ Rather than specifying the current desired state of all replicas, pod templates
|
||||
|
||||
{% capture whatsnext %}
|
||||
* Learn more about Pod behavior:
|
||||
* Pod Termination
|
||||
* [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
* Other Pod Topics
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
@@ -211,14 +211,14 @@ Please select one of the tabs to see installation instructions for the respectiv
|
||||
|
||||
{% capture calico %}
|
||||
|
||||
The official Calico guide is [here](http://docs.projectcalico.org/v2.3/getting-started/kubernetes/installation/hosted/kubeadm/)
|
||||
The official Calico guide is [here](http://docs.projectcalico.org/latest/getting-started/kubernetes/installation/hosted/kubeadm/)
|
||||
|
||||
**Note:**
|
||||
- In order for Network Policy to work correctly, you need to pass `--pod-network-cidr=192.168.0.0/16` to `kubeadm init`
|
||||
- Calico works on `amd64` only.
|
||||
|
||||
```shell
|
||||
kubectl apply -f http://docs.projectcalico.org/v2.3/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml
|
||||
kubectl apply -f http://docs.projectcalico.org/v2.4/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml
|
||||
```
|
||||
{% endcapture %}
|
||||
|
||||
@@ -267,7 +267,8 @@ The official Weave Net set-up guide is [here](https://www.weave.works/docs/net/l
|
||||
**Note:** Weave Net works on `amd64`, `arm` and `arm64` without any extra action required.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://git.io/weave-kube-1.6
|
||||
export kubever=$(kubectl version | base64 | tr -d '\n')
|
||||
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever"
|
||||
```
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ Select one of the tabs.
|
||||
|
||||
{% capture calico %}
|
||||
```shell
|
||||
kubectl apply -f "http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml"
|
||||
kubectl apply -f "http://docs.projectcalico.org/v2.4/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml"
|
||||
```
|
||||
{% endcapture %}
|
||||
|
||||
@@ -54,7 +54,7 @@ Select one of the tabs.
|
||||
|
||||
{{ "{% capture calico " }}%}
|
||||
```shell
|
||||
kubectl apply -f "http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml"
|
||||
kubectl apply -f "http://docs.projectcalico.org/v2.4/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml"
|
||||
```
|
||||
{{ "{% endcapture " }}%}
|
||||
|
||||
@@ -87,7 +87,7 @@ kubectl apply -f "https://git.io/weave-kube"
|
||||
````liquid
|
||||
{{ "{% capture calico " }}%}
|
||||
```shell
|
||||
kubectl apply -f "http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml"
|
||||
kubectl apply -f "http://docs.projectcalico.org/v2.4/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml"
|
||||
```
|
||||
{{ "{% endcapture " }}%}
|
||||
````
|
||||
|
||||
@@ -104,7 +104,7 @@ To create a new secret perform the following steps:
|
||||
1. Generate a 32 byte random key and base64 encode it. If you're on Linux or Mac OS X, run the following command:
|
||||
|
||||
```
|
||||
head -c 32 /dev/urandom | base64 -i - -o -
|
||||
head -c 32 /dev/urandom | base64
|
||||
```
|
||||
|
||||
2. Place that value in the secret field.
|
||||
|
||||
@@ -230,7 +230,7 @@ In particular, Federated ReplicaSets ensure that the desired number of
|
||||
pods are kept running in each cluster, even in the event of node
|
||||
failures. In the event of entire cluster or availability zone
|
||||
failures, Federated ReplicaSets automatically place additional
|
||||
replacas in the other available clusters in the federation to accommodate the
|
||||
replicas in the other available clusters in the federation to accommodate the
|
||||
traffic which was previously being served by the now unavailable
|
||||
cluster. While the Federated ReplicaSet ensures that sufficient replicas are
|
||||
kept running, the Federated Ingress ensures that user traffic is
|
||||
|
||||
@@ -157,7 +157,7 @@ behind a Service and you don't intend to increase the number of Pods.
|
||||
Run a MySQL client to connect to the server:
|
||||
|
||||
```
|
||||
kubectl run -it --rm --image=mysql:5.6 mysql-client -- mysql -h <pod-ip> -ppassword
|
||||
kubectl run -it --rm --image=mysql:5.6 mysql-client -- mysql -h <pod-ip> -p <password>
|
||||
```
|
||||
|
||||
This command creates a new Pod in the cluster running a mysql client
|
||||
|
||||
@@ -776,7 +776,7 @@ drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data
|
||||
## Managing the ZooKeeper Process
|
||||
|
||||
The [ZooKeeper documentation](https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supervision)
|
||||
documentation indicates that "You will want to have a supervisory process that
|
||||
indicates that "You will want to have a supervisory process that
|
||||
manages each of your ZooKeeper server processes (JVM)." Utilizing a watchdog
|
||||
(supervisory process) to restart failed processes in a distributed system is a
|
||||
common pattern. When deploying an application in Kubernetes, rather than using
|
||||
|
||||
+1
-1
@@ -12,7 +12,7 @@ $( document ).ready(function() {
|
||||
$("#generalInstructions").hide();
|
||||
$("#continueEdit").show();
|
||||
$("#continueEditButton").text("Edit " + forwarding);
|
||||
$("#continueEditButton").attr("href", "https://github.com/kubernetes/kubernetes.github.io/edit/master/" + forwarding)
|
||||
$("#continueEditButton").attr("href", "https://github.com/kubernetes/kubernetes.github.io/edit/{{ page.docsbranch }}/" + forwarding)
|
||||
$("#viewOnGithubButton").text("View " + forwarding + " on GitHub");
|
||||
$("#viewOnGithubButton").attr("href", "https://git.k8s.io/kubernetes.github.io/" + forwarding)
|
||||
} else {
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 8.8 KiB After Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.3 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.3 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 8.1 KiB After Width: | Height: | Size: 4.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.1 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.1 KiB |
@@ -21,6 +21,8 @@ cid: home
|
||||
<!--</div>-->
|
||||
</section>
|
||||
|
||||
{% include deprecation-warning.html %}
|
||||
|
||||
<!-- OCEAN NODES -->
|
||||
<section id="oceanNodes">
|
||||
<main>
|
||||
|
||||
Reference in New Issue
Block a user