Merge branch 'master' into release-1.7
This commit is contained in:
steveperry-53
+24
@@ -22,6 +22,30 @@ defaults:
|
||||
version: "v1.7"
|
||||
githubbranch: "v1.7.3"
|
||||
docsbranch: "release-1.7"
|
||||
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 " }}%}
|
||||
````
|
||||
|
||||
@@ -105,7 +105,7 @@ provides load balancing for an application that has two running instances.
|
||||
|
||||
1. Use the node address and node port to access the Hello World application:
|
||||
|
||||
curl http://<public-node-ip>:<node-port>
|
||||
curl http://<public-node-ip>:<node-port>
|
||||
|
||||
where `<public-node-ip>` is the public IP address of your node,
|
||||
and `<node-port>` is the NodePort value for your service.
|
||||
|
||||
@@ -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
|
||||
@@ -256,7 +256,7 @@ Check that:
|
||||
1. Your clusters are correctly registered in the Cluster Federation API (`kubectl describe clusters`)
|
||||
2. Your clusters are all 'Active'. This means that the cluster
|
||||
Federation system was able to connect and authenticate against the
|
||||
clusters' endpoints. If not, consult the event logs of the federation-controller-manager pod to ascertain what the failure might be. (`kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -oname`)
|
||||
clusters' endpoints. If not, consult the event logs of the federation-controller-manager pod to ascertain what the failure might be. (`kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -o name`)
|
||||
3. That the login credentials provided to the Cluster Federation API
|
||||
for the clusters have the correct authorization and quota to create
|
||||
ingresses/services/replicasets in the relevant namespace in the
|
||||
|
||||
@@ -207,8 +207,8 @@ ports:
|
||||
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /healthz
|
||||
port: liveness-port
|
||||
path: /healthz
|
||||
port: liveness-port
|
||||
```
|
||||
|
||||
## Define readiness probes
|
||||
|
||||
@@ -356,7 +356,7 @@ how to bring up a cluster federation correctly (or have your cluster administrat
|
||||
Check that:
|
||||
|
||||
1. Your clusters are correctly registered in the Cluster Federation API (`kubectl describe clusters`)
|
||||
2. Your clusters are all 'Active'. This means that the cluster Federation system was able to connect and authenticate against the clusters' endpoints. If not, consult the logs of the federation-controller-manager pod to ascertain what the failure might be. (`kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -oname`)
|
||||
2. Your clusters are all 'Active'. This means that the cluster Federation system was able to connect and authenticate against the clusters' endpoints. If not, consult the logs of the federation-controller-manager pod to ascertain what the failure might be. (`kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -o name`)
|
||||
3. That the login credentials provided to the Cluster Federation API for the clusters have the correct authorization and quota to create services in the relevant namespace in the clusters. Again you should see associated error messages providing more detail in the above log file if this is not the case.
|
||||
4. Whether any other error is preventing the service creation operation from succeeding (look for `service-controller` errors in the output of `kubectl logs federation-controller-manager --namespace federation`).
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
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