Merge branch 'master' of git://github.com/kubernetes/website into release-1.12
* 'master' of git://github.com/kubernetes/website: (222 commits) Add temporary owners for 1.13 release (#11453) fix Minikube 404 error. (#11461) Resolve conflicts against dev-1.13 for /ko contents (#11439) replace `run` with `create deployment` (#11392) Updated list all pods with -o wide comment (#11394) fix broken link for KubeletConfiguration (#11423) Update on pod-priority-preemption.md (#11418) Add guidelines for working with localized content (#11415) Update what-is-kubernetes.md (#11399) Remove redundant close tags and little bit formatting (#11389) Add SysEleven MetaKube as hosted solution (#11393) Add rui to sig-docs-zh team (#11391) fix Improper translation (#11384) Add pigletfly(WangBing) as a sig-docs-zh-reviewer (#11370) update link to CloudProvider Interface (#11228) Fix the "my-scheduler-as-kube-scheduler" ClusterRoleBinding. (#11112) fix non-existing "CloudProvider Interface" link (#10953) Updated ingress.md (#11213) Further updates to TLS Bootstrapping (#11258) Updated 'exec' description (#11365) ...
This commit is contained in:
Rui Chen
@@ -32,7 +32,7 @@ Bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 系统进行工作。
|
||||
|
||||
所有与启动引导令牌相关的特性在 Kubernetes v1.6 版本中默认都是禁用的。
|
||||
|
||||
你可以在 API 服务器上通过 `--experimental-bootstrap-token-auth` 参数启用启动引导令牌。
|
||||
你可以在 API 服务器上通过 `--enable-bootstrap-token-auth` 参数启用启动引导令牌。
|
||||
你可以设置控制管理器的 `--controllers` 参数来启用启动引导令牌相关的控制器，例如 `--controllers=*,tokencleaner,bootstrapsigner` 。
|
||||
在使用 `kubeadm` 时，这是自动完成的。
|
||||
|
||||
|
||||
@@ -104,7 +104,7 @@ kube-apiserver
|
||||
|
||||
--event-ttl duration 事件驻留时间。（默认值1h0m0s)
|
||||
|
||||
--experimental-bootstrap-token-auth 启用此选项以允许'kube-system'命名空间中的'bootstrap.kubernetes.io/token'类型密钥可以被用于TLS的启动认证。
|
||||
--enable-bootstrap-token-auth 启用此选项以允许'kube-system'命名空间中的'bootstrap.kubernetes.io/token'类型密钥可以被用于TLS的启动认证。
|
||||
|
||||
--experimental-encryption-provider-config string 包含加密提供程序的配置的文件，该加密提供程序被用于在etcd中保存密钥。
|
||||
|
||||
|
||||
@@ -186,11 +186,13 @@ kubectl config set-credentials kubelet-bootstrap --token=${BOOTSTRAP_TOKEN} --ku
|
||||
|
||||
When starting the kubelet, if the file specified by `--kubeconfig` does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On approval of the certificate request and receipt back by the kubelet, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by `--kubeconfig`. The certificate and key file will be placed in the directory specified by `--cert-dir`.
|
||||
|
||||
**Note:** The following flags are required to enable this bootstrapping when starting the kubelet:
|
||||
{{< note >}}
|
||||
The following flags are required to enable this bootstrapping when starting the kubelet:
|
||||
|
||||
```
|
||||
--bootstrap-kubeconfig="/path/to/bootstrap/kubeconfig"
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
Additionally, in 1.7 the kubelet implements __alpha__ features for enabling rotation of both its client and/or serving certs.
|
||||
These can be enabled through the respective `RotateKubeletClientCertificate` and `RotateKubeletServerCertificate` feature
|
||||
|
||||
@@ -43,7 +43,7 @@ Master 组件通过非安全（没有加密或认证）端口和集群的 apiser
|
||||
### apiserver -> kubelet
|
||||
|
||||
|
||||
从 apiserver 到 kubelet 的连接用于获取 pods 日志、连接（通过 kubectl）运行中的 pods，以及使用 kubele 的端口转发功能。这些连接终止于 kubelet 的 HTTPS endpoint。
|
||||
从 apiserver 到 kubelet 的连接用于获取 pods 日志、连接（通过 kubectl）运行中的 pods，以及使用 kubelet 的端口转发功能。这些连接终止于 kubelet 的 HTTPS endpoint。
|
||||
|
||||
|
||||
默认的，apiserver 不会验证 kubelet 的服务证书，这会导致连接遭到中间人攻击，因而在不可信或公共网络上是不安全的。
|
||||
|
||||
@@ -357,7 +357,7 @@ based on the Ready NodeCondition is disabled.
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note:** To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/)
|
||||
To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/)
|
||||
behavior of pod evictions due to node problems, the system actually adds the taints
|
||||
in a rate-limited way. This prevents massive pod evictions in scenarios such
|
||||
as the master becoming partitioned from the nodes.
|
||||
|
||||
@@ -26,7 +26,7 @@ Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上
|
||||
这表明了在 Pod 内的容器都能够连接到本地的每个端口，集群中的所有 Pod 不需要通过 NAT 转换就能够互相看到。
|
||||
文档的剩余部分将详述如何在一个网络模型之上运行可靠的服务。
|
||||
|
||||
该指南使用一个简单的 Nginx server 来演示并证明谈到的概念。同样的原则也体现在一个更加完整的 [Jenkins CI 应用](http://blog.kubernetes.io/2015/07/strong-simple-ssl-for-kubernetes.html) 中。
|
||||
该指南使用一个简单的 Nginx server 来演示并证明谈到的概念。同样的原则也体现在一个更加完整的 [Jenkins CI 应用](http://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes.html) 中。
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ redirect_from:
|
||||
|
||||
|
||||
Kubernetes [`Pod`](/docs/user-guide/pods) 是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束。
|
||||
通过 [`ReplicationController`](/docs/user-guide/replication-controller) 能够动态地创建和销毁 `Pod`（例如，需要进行扩缩容，或者执行 [滚动升级](/docs/user-guide/kubectl/v1.7/#rolling-update)）。
|
||||
通过 [`ReplicaSets`](/docs/concepts/workloads/controllers/replicaset/) 能够动态地创建和销毁 `Pod`（例如，需要进行扩缩容，或者执行 [滚动升级](/docs/user-guide/kubectl/v1.7/#rolling-update)）。
|
||||
每个 `Pod` 都会获取它自己的 IP 地址，即使这些 IP 地址不总是稳定可依赖的。
|
||||
这会导致一个问题：在 Kubernetes 集群中，如果一组 `Pod`（称为 backend）为其它 `Pod` （称为 frontend）提供服务，那么那些 frontend 该如何发现，并连接到这组 `Pod` 中的哪些 backend 呢？
|
||||
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: "存储"
|
||||
weight: 90
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: "Storage"
|
||||
weight: 90
|
||||
weight: 70
|
||||
---
|
||||
-->
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: "工作负载"
|
||||
weight: 60
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: "Workloads"
|
||||
weight: 60
|
||||
weight: 50
|
||||
---
|
||||
-->
|
||||
|
||||
@@ -14,7 +14,7 @@ A _Deployment_ controller provides declarative updates for [Pods](/docs/concepts
|
||||
You describe a _desired state_ in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** You should not manage ReplicaSets owned by a Deployment. All the use cases should be covered by manipulating the Deployment object. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.
|
||||
You should not manage ReplicaSets owned by a Deployment. All the use cases should be covered by manipulating the Deployment object. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -103,7 +103,7 @@ nginx-deployment-2035384211-qqcnn 1/1 Running 0 18s app
|
||||
The created ReplicaSet ensures that there are three nginx Pods at all times.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** You must specify an appropriate selector and pod template labels in a Deployment (in this case,
|
||||
You must specify an appropriate selector and pod template labels in a Deployment (in this case,
|
||||
`app = nginx`). That is, don't overlap with other controllers (including other Deployments, ReplicaSets,
|
||||
StatefulSets, etc.). Kubernetes doesn't stop you from overlapping, and if multiple
|
||||
controllers have overlapping selectors, those controllers may fight with each other and won't behave
|
||||
@@ -113,7 +113,7 @@ correctly.
|
||||
### Pod-template-hash label
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Do not change this label.
|
||||
Do not change this label.
|
||||
{{< /note >}}
|
||||
|
||||
Note the pod-template-hash label in the example output in the pod labels above. This label is added by the
|
||||
@@ -125,7 +125,7 @@ and in any existing Pods that the ReplicaSet may have.
|
||||
## Updating a Deployment
|
||||
|
||||
{{< note >}}
|
||||
**Note:** A Deployment's rollout is triggered if and only if the Deployment's pod template (that is, `.spec.template`)
|
||||
A Deployment's rollout is triggered if and only if the Deployment's pod template (that is, `.spec.template`)
|
||||
is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -270,7 +270,7 @@ By default, all of the Deployment's rollout history is kept in the system so tha
|
||||
(you can change that by modifying revision history limit).
|
||||
|
||||
{{< note >}}
|
||||
**Note:** A Deployment's revision is created when a Deployment's rollout is triggered. This means that the
|
||||
A Deployment's revision is created when a Deployment's rollout is triggered. This means that the
|
||||
new revision is created if and only if the Deployment's pod template (`.spec.template`) is changed,
|
||||
for example if you update the labels or container images of the template. Other updates, such as scaling the Deployment,
|
||||
do not create a Deployment revision, so that we can facilitate simultaneous manual- or auto-scaling.
|
||||
@@ -318,7 +318,7 @@ nginx-deployment-3066724191-eocby 0/1 ImagePullBackOff 0 6s
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The Deployment controller will stop the bad rollout automatically, and will stop scaling up the new
|
||||
The Deployment controller will stop the bad rollout automatically, and will stop scaling up the new
|
||||
ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified.
|
||||
Kubernetes by default sets the value to 1 and spec.replicas to 1 so if you haven't cared about setting those
|
||||
parameters, your Deployment can have 100% unavailability by default! This will be fixed in Kubernetes in a future
|
||||
@@ -596,7 +596,7 @@ nginx-3926361531 3 3 3 28s
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** You cannot rollback a paused Deployment until you resume it.
|
||||
You cannot rollback a paused Deployment until you resume it.
|
||||
{{< /note >}}
|
||||
|
||||
## Deployment status
|
||||
@@ -669,13 +669,13 @@ attributes to the Deployment's `status.conditions`:
|
||||
See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/devel/api-conventions.md#typical-status-properties) for more information on status conditions.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Kubernetes will take no action on a stalled Deployment other than to report a status condition with
|
||||
Kubernetes will take no action on a stalled Deployment other than to report a status condition with
|
||||
`Reason=ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for
|
||||
example, rollback the Deployment to its previous version.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can
|
||||
If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can
|
||||
safely pause a Deployment in the middle of a rollout and resume without triggering the condition for exceeding the
|
||||
deadline.
|
||||
{{< /note >}}
|
||||
@@ -780,7 +780,7 @@ this Deployment you want to retain. The rest will be garbage-collected in the ba
|
||||
all revision history will be kept. In a future version, it will default to switch to 2.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment
|
||||
Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment
|
||||
thus that Deployment will not be able to roll back.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -831,7 +831,7 @@ from `.spec.template` or if the total number of such Pods exceeds `.spec.replica
|
||||
Pods with `.spec.template` if the number of Pods is less than the desired number.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** You should not create other pods whose labels match this selector, either directly, by creating
|
||||
You should not create other pods whose labels match this selector, either directly, by creating
|
||||
another Deployment, or by creating another controller such as a ReplicaSet or a ReplicationController. If you
|
||||
do so, the first Deployment thinks that it created these other pods. Kubernetes does not stop you from doing this.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -2,3 +2,10 @@
|
||||
title: "Pods"
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: "Pods"
|
||||
weight: 10
|
||||
---
|
||||
-->
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "裸金属"
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: "Bare Metal"
|
||||
weight: 60
|
||||
---
|
||||
-->
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: Kubernetes 文档
|
||||
layout: docsportal_home
|
||||
noedit: true
|
||||
cid: userJourneys
|
||||
css: /css/style_user_journeys.css
|
||||
js: /js/user-journeys/home.js, https://use.fontawesome.com/4bcc658a89.js
|
||||
display_browse_numbers: true
|
||||
linkTitle: "主页"
|
||||
main_menu: true
|
||||
weight: 10
|
||||
menu:
|
||||
main:
|
||||
title: "文档"
|
||||
weight: 20
|
||||
post: >
|
||||
<p>通过演练，示例和参考文档了解如何使用 Kubernetes。你甚至可以<a href="/editdocs/" data-auto-burger-exclude>帮助贡献文档</a>！</p>
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
approvers:
|
||||
- chenopis
|
||||
title: Kubernetes Documentation
|
||||
layout: docsportal_home
|
||||
noedit: true
|
||||
cid: userJourneys
|
||||
css: /css/style_user_journeys.css
|
||||
js: /js/user-journeys/home.js, https://use.fontawesome.com/4bcc658a89.js
|
||||
display_browse_numbers: true
|
||||
linkTitle: "Home"
|
||||
main_menu: true
|
||||
weight: 10
|
||||
hide_feedback: true
|
||||
menu:
|
||||
main:
|
||||
title: "Documentation"
|
||||
weight: 20
|
||||
post: >
|
||||
<p>Learn how to use Kubernetes with the use of walkthroughs, samples, and reference documentation. You can even <a href="/editdocs/" data-auto-burger-exclude>help contribute to the docs</a>!</p>
|
||||
---
|
||||
-->
|
||||
@@ -279,7 +279,7 @@ with different/greater permissions.
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
**Caution:** System administrators, use care when granting access to pod
|
||||
System administrators, use care when granting access to pod
|
||||
creation. A user granted permission to create pods (or controllers that create
|
||||
pods) in the namespace can: read all secrets in the namespace; read all config
|
||||
maps in the namespace; and impersonate any service account in the namespace and
|
||||
|
||||
@@ -9,7 +9,7 @@ content_template: templates/concept
|
||||
---
|
||||
reviewers:
|
||||
- janetkuo
|
||||
title: 工具
|
||||
title: 工具
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
@@ -17,7 +17,7 @@ content_template: templates/concept
|
||||
Kubernetes contains several built-in tools to help you work with the Kubernetes system.
|
||||
-->
|
||||
{{% capture overview %}}
|
||||
Kubernetes 包含一些内置工具，可以帮助用户更好的使用 Kubernetes 系统。
|
||||
Kubernetes 包含一些内置工具，可以帮助用户更好的使用 Kubernetes 系统。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
@@ -26,14 +26,14 @@ Kubernetes
|
||||
<!--
|
||||
[`kubectl`](/docs/tasks/tools/install-kubectl/) is the command line tool for Kubernetes. It controls the Kubernetes cluster manager.
|
||||
-->
|
||||
[`kubectl`](/docs/tasks/tools/install-kubectl/) 是 Kubernetes 命令行工具，可以用来操控 Kubernetes 集群。
|
||||
[`kubectl`](/docs/tasks/tools/install-kubectl/) 是 Kubernetes 命令行工具，可以用来操控 Kubernetes 集群。
|
||||
|
||||
## Kubeadm
|
||||
|
||||
<!--
|
||||
[`kubeadm`](/docs/tasks/tools/install-kubeadm/) is the command line tool for easily provisioning a secure Kubernetes cluster on top of physical or cloud servers or virtual machines (currently in alpha).
|
||||
-->
|
||||
[`kubeadm`](/docs/tasks/tools/install-kubeadm/) 是一个命令行工具，可以用来在物理机、云服务器或虚拟机（目前处于 alpha 阶段）上轻松部署一个安全可靠的 Kubernetes 集群。
|
||||
[`kubeadm`](/docs/tasks/tools/install-kubeadm/) 是一个命令行工具，可以用来在物理机、云服务器或虚拟机（目前处于 alpha 阶段）上轻松部署一个安全可靠的 Kubernetes 集群。
|
||||
|
||||
## Kubefed
|
||||
|
||||
@@ -41,7 +41,7 @@ Kubernetes
|
||||
[`kubefed`](/docs/tasks/federation/set-up-cluster-federation-kubefed/) is the command line tool
|
||||
to help you administrate your federated clusters.
|
||||
-->
|
||||
[`kubefed`](/docs/tasks/federation/set-up-cluster-federation-kubefed/) 是一个命令行工具，可以用来帮助用户管理联邦集群。
|
||||
[`kubefed`](/docs/tasks/federation/set-up-cluster-federation-kubefed/) 是一个命令行工具，可以用来帮助用户管理联邦集群。
|
||||
|
||||
|
||||
## Minikube
|
||||
@@ -51,7 +51,7 @@ to help you administrate your federated clusters.
|
||||
easy to run a single-node Kubernetes cluster locally on your workstation for
|
||||
development and testing purposes.
|
||||
-->
|
||||
[`minikube`](/docs/tasks/tools/install-minikube/) 是一个可以方便用户在其工作站点本地部署一个单节点 Kubernetes 集群的工具，用于开发和测试。
|
||||
[`minikube`](/docs/tasks/tools/install-minikube/) 是一个可以方便用户在其工作站点本地部署一个单节点 Kubernetes 集群的工具，用于开发和测试。
|
||||
|
||||
|
||||
## Dashboard
|
||||
@@ -60,7 +60,7 @@ development and testing purposes.
|
||||
[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), the web-based user interface of Kubernetes, allows you to deploy containerized applications
|
||||
to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself.
|
||||
-->
|
||||
[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), 是 Kubernetes 基于 Web 的用户管理界面，允许用户部署容器化应用到 Kubernetes 集群，进行故障排查以及管理集群和集群资源。
|
||||
[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), 是 Kubernetes 基于 Web 的用户管理界面，允许用户部署容器化应用到 Kubernetes 集群，进行故障排查以及管理集群和集群资源。
|
||||
|
||||
## Helm
|
||||
|
||||
@@ -68,7 +68,7 @@ to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resou
|
||||
[`Kubernetes Helm`](https://github.com/kubernetes/helm) is a tool for managing packages of pre-configured
|
||||
Kubernetes resources, aka Kubernetes charts.
|
||||
-->
|
||||
[`Kubernetes Helm`](https://github.com/kubernetes/helm) 是一个管理预先配置 Kubernetes 资源包的工具，这里的资源在 Helm 中也被称作 Kubernetes charts。
|
||||
[`Kubernetes Helm`](https://github.com/kubernetes/helm) 是一个管理预先配置 Kubernetes 资源包的工具，这里的资源在 Helm 中也被称作 Kubernetes charts。
|
||||
|
||||
<!--
|
||||
Use Helm to:
|
||||
@@ -79,20 +79,20 @@ Use Helm to:
|
||||
* Intelligently manage your Kubernetes manifest files
|
||||
* Manage releases of Helm packages
|
||||
-->
|
||||
使用 Helm：
|
||||
使用 Helm：
|
||||
|
||||
*查找并使用已经打包为 Kubernetes charts 的流行软件
|
||||
*分享您自己的应用作为 Kubernetes charts
|
||||
*为 Kubernetes 应用创建可重复执行的构建
|
||||
*为您的 Kubernetes 清单文件提供更智能化的管理
|
||||
*管理 Helm 软件包的发布
|
||||
* 查找并使用已经打包为 Kubernetes charts 的流行软件
|
||||
* 分享您自己的应用作为 Kubernetes charts
|
||||
* 为 Kubernetes 应用创建可重复执行的构建
|
||||
* 为您的 Kubernetes 清单文件提供更智能化的管理
|
||||
* 管理 Helm 软件包的发布
|
||||
|
||||
## Kompose
|
||||
|
||||
<!--
|
||||
[`Kompose`](https://github.com/kubernetes-incubator/kompose) is a tool to help Docker Compose users move to Kubernetes.
|
||||
-->
|
||||
[`Kompose`](https://github.com/kubernetes-incubator/kompose) 一个转换工具，用来帮助 Docker Compose 用户迁移至 Kubernetes。
|
||||
[`Kompose`](https://github.com/kubernetes-incubator/kompose) 一个转换工具，用来帮助 Docker Compose 用户迁移至 Kubernetes。
|
||||
|
||||
<!--
|
||||
Use Kompose to:
|
||||
@@ -101,9 +101,9 @@ Use Kompose to:
|
||||
* Go from local Docker development to managing your application via Kubernetes
|
||||
* Convert v1 or v2 Docker Compose `yaml` files or [Distributed Application Bundles](https://docs.docker.com/compose/bundles/)
|
||||
-->
|
||||
使用 Kompose:
|
||||
使用 Kompose:
|
||||
|
||||
* 将一个 Docker Compose 文件解释成 Kubernetes 对象
|
||||
* 将本地 Docker 开发 转变成通过 Kubernetes 来管理
|
||||
* 转换 v1 或 v2 Docker Compose `yaml` 文件 或 [分布式应用程序包](https://docs.docker.com/compose/bundles/)
|
||||
{{% /capture %}}
|
||||
* 将一个 Docker Compose 文件解释成 Kubernetes 对象
|
||||
* 将本地 Docker 开发 转变成通过 Kubernetes 来管理
|
||||
* 转换 v1 或 v2 Docker Compose `yaml` 文件 或 [分布式应用程序包](https://docs.docker.com/compose/bundles/)
|
||||
{{% /capture %}}
|
||||
|
||||
+1
-1
@@ -165,7 +165,7 @@ Pod 能有多个容器的主要原因是为了支持辅助应用（helper applic
|
||||
|
||||
|
||||
* 更多学习内容
|
||||
[混合容器的方式](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html)。
|
||||
[混合容器的方式](http://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns.html)。
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -152,7 +152,7 @@ IP 地址列在 `LoadBalancer Ingress` 旁边。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note**: If you are running your service on Minikube, you can find the assigned IP address and port with:
|
||||
If you are running your service on Minikube, you can find the assigned IP address and port with:
|
||||
-->
|
||||
**注意：** 如果您在 Minikube 上运行服务，您可以通过以下命令找到分配的 IP 地址和端口：
|
||||
{{< /note >}}
|
||||
|
||||
+1
-1
@@ -102,7 +102,7 @@ jsonpath 解释如下：
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note:** When fetching a single Pod by name, e.g. `kubectl get pod nginx`,
|
||||
When fetching a single Pod by name, e.g. `kubectl get pod nginx`,
|
||||
the `.items[*]` portion of the path should be omitted because a single
|
||||
Pod is returned instead of a list of items.
|
||||
-->
|
||||
|
||||
+2
-2
@@ -109,7 +109,7 @@ load-balanced access to an application running in a cluster.
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note:** If you are using Minikube, you don't get an external IP address. The
|
||||
If you are using Minikube, you don't get an external IP address. The
|
||||
external IP address remains in the pending state.
|
||||
-->
|
||||
**注意：** 如果您使用 Minikube，那么您将不会获得外部 IP 地址。外部 IP 地址将保持 pending 状态。
|
||||
@@ -139,7 +139,7 @@ load-balanced access to an application running in a cluster.
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note:** If you are using Minikube, enter these commands:
|
||||
If you are using Minikube, enter these commands:
|
||||
-->
|
||||
**注意：** 如果您使用 Minikube，输入以下命令：
|
||||
{{< /note >}}
|
||||
|
||||
+1
-1
@@ -200,7 +200,7 @@ local workstation to debug the database that is running in the pod.
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
**Warning**: Due to known limitations, port forward today only works for TCP protocol.
|
||||
Due to known limitations, port forward today only works for TCP protocol.
|
||||
The support to UDP protocol is being tracked in
|
||||
[issue 47862](https://github.com/kubernetes/kubernetes/issues/47862).
|
||||
-->
|
||||
|
||||
@@ -54,7 +54,7 @@ Before proceeding:
|
||||
{{< caution >}}
|
||||
<!--
|
||||
|
||||
**Caution:** All the containers will get restarted after the upgrade, due to container spec hash value gets changed.
|
||||
All the containers will get restarted after the upgrade, due to container spec hash value gets changed.
|
||||
|
||||
--->
|
||||
**注意:** 由于容器的具体哈希值改变了，所有的容器在升级之后会重新启动。
|
||||
@@ -98,7 +98,7 @@ chmod a+rx /usr/bin/kubeadm
|
||||
{{< caution >}}
|
||||
<!--
|
||||
|
||||
**Caution:** Upgrading the `kubeadm` package on your system prior to upgrading the control plane causes a failed upgrade.
|
||||
Upgrading the `kubeadm` package on your system prior to upgrading the control plane causes a failed upgrade.
|
||||
Even though `kubeadm` ships in the Kubernetes repositories, it's important to install `kubeadm` manually. The kubeadm
|
||||
team is working on fixing this limitation.
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 管理内存、CPU 和 API 资源
|
||||
title: 管理内存，CPU 和 API 资源
|
||||
weight: 20
|
||||
---
|
||||
|
||||
@@ -9,4 +9,3 @@ title: Manage Memory, CPU, and API Resources
|
||||
weight: 20
|
||||
---
|
||||
-->
|
||||
|
||||
|
||||
@@ -454,8 +454,3 @@ kubectl delete namespace constraints-cpu-example
|
||||
* [为Pod配置Service数量](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -313,4 +313,3 @@ it can be allowed to run in a namespace that is restricted by a quota.
|
||||
* [为Pod配置Service数量](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
-5
@@ -440,8 +440,3 @@ kubectl delete namespace constraints-mem-example
|
||||
* [为 Pod 配置 Service 数量](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
+1
-3
@@ -265,7 +265,7 @@ Here are two of the restrictions that a resource quota imposes on a namespace:
|
||||
-->
|
||||
|
||||
* 运行在命名空间中的每个容器必须有自己的内存限制。
|
||||
* 命名空间中所有容器的内存使用量之和不能超过声明的限制值。
|
||||
* 命名空间中所有容器的内存使用量之和不能超过声明的限制值。
|
||||
|
||||
<!--
|
||||
If a Container does not specify its own memory limit, it is given the default limit, and then
|
||||
@@ -331,5 +331,3 @@ it can be allowed to run in a namespace that is restricted by a quota.
|
||||
* [为 Pod 配置服务数量](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
-5
@@ -298,8 +298,3 @@ kubectl delete namespace quota-mem-cpu-example
|
||||
* [为 Pod 配置 Service 数量](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
<!--
|
||||
---
|
||||
title: Install a Network Policy Provider
|
||||
weight: 30
|
||||
---
|
||||
-->
|
||||
|
||||
---
|
||||
title: 安装网络规则驱动
|
||||
weight: 30
|
||||
---
|
||||
@@ -103,7 +103,7 @@ The following sysctls are supported in the _safe_ set:
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note**: The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
|
||||
The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
|
||||
--->
|
||||
**注意**: 示例中的 `net.ipv4.tcp_syncookies` 在Linux 内核 4.4 或更低的版本中是无命名空间的。
|
||||
{{< /note >}}
|
||||
@@ -226,7 +226,7 @@ spec:
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
**Warning**: Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
|
||||
Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
|
||||
is at-your-own-risk and can lead to severe problems like wrong behavior of
|
||||
containers, resource shortage or complete breakage of a node.
|
||||
--->
|
||||
@@ -299,7 +299,7 @@ given sysctl is both allowed and forbidden.
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
**Warning**: If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
|
||||
If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
|
||||
in a PodSecurityPolicy, any pod using such a sysctl will fail to start
|
||||
if the sysctl is not whitelisted via the `--allowed-unsafe-sysctls` kubelet
|
||||
flag as well on that node.
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
<!--
|
||||
---
|
||||
title: "Federation - Run an App on Multiple Clusters"
|
||||
weight: 160
|
||||
---
|
||||
-->
|
||||
|
||||
---
|
||||
title: "联邦：在多个集群上运行一个应用"
|
||||
weight: 160
|
||||
---
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
<!--
|
||||
---
|
||||
title: "Configure Pods and Containers"
|
||||
weight: 20
|
||||
---
|
||||
-->
|
||||
|
||||
---
|
||||
title: "配置 Pod 和 容器"
|
||||
weight: 20
|
||||
---
|
||||
|
||||
@@ -79,7 +79,7 @@ Each request can be recorded with an associated "stage". The known stages are:
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note** The audit logging feature increases the memory consumption of the API
|
||||
The audit logging feature increases the memory consumption of the API
|
||||
server because some context required for auditing is stored for each request.
|
||||
Additionally, memory consumption depends on the audit logging configuration.
|
||||
-->
|
||||
@@ -174,7 +174,7 @@ In both cases, audit events structure is defined by the API in the
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note:** In case of patches, request body is a JSON array with patch operations, not a JSON object
|
||||
In case of patches, request body is a JSON array with patch operations, not a JSON object
|
||||
with an appropriate Kubernetes API object. For example, the following request body is a valid patch
|
||||
request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
|
||||
-->
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "联邦 - 在多个集群上运行应用程序"
|
||||
title: "联邦 - 在多个集群上运行一个应用"
|
||||
weight: 120
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
<!--
|
||||
---
|
||||
title: "Inject Data Into Applications"
|
||||
weight: 30
|
||||
---
|
||||
-->
|
||||
|
||||
---
|
||||
title: "给应用注入数据"
|
||||
weight: 30
|
||||
---
|
||||
|
||||
|
||||
+1
-1
@@ -184,7 +184,7 @@ kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh
|
||||
* Pod的注释
|
||||
|
||||
{{< note >}}
|
||||
**Note:** 如果容器未指定CPU和memory limits，则Downward API默认为节点可分配值。
|
||||
如果容器未指定CPU和memory limits，则Downward API默认为节点可分配值。
|
||||
{{< /note >}}
|
||||
|
||||
## 投射密钥到指定路径并且指定文件权限
|
||||
|
||||
@@ -0,0 +1,362 @@
|
||||
<!--
|
||||
---
|
||||
title: Running Automated Tasks with a CronJob
|
||||
reviewers:
|
||||
- chenopis
|
||||
content_template: templates/task
|
||||
weight: 10
|
||||
---
|
||||
-->
|
||||
|
||||
---
|
||||
reviewers:
|
||||
- chenopis
|
||||
|
||||
title: 使用 CronJob 运行自动化任务
|
||||
content_template: templates/task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
You can use [CronJobs](/docs/concepts/workloads/controllers/cron-jobs) to run jobs on a time-based schedule.
|
||||
These automated jobs run like [Cron](https://en.wikipedia.org/wiki/Cron) tasks on a Linux or UNIX system.
|
||||
|
||||
Cron jobs are useful for creating periodic and recurring tasks, like running backups or sending emails.
|
||||
Cron jobs can also schedule individual tasks for a specific time, such as if you want to schedule a job for a low activity period.
|
||||
-->
|
||||
|
||||
你可以利用 [CronJobs](/docs/concepts/workloads/controllers/cron-jobs) 执行基于时间调度的任务。这些自动化任务和 Linux 或者 Unix 系统的 [Cron](https://en.wikipedia.org/wiki/Cron) 任务类似。
|
||||
|
||||
CronJobs 在创建周期性以及重复性的任务时很有帮助，例如执行备份操作或者发送邮件。CronJobs 也可以在特定时间调度单个任务，例如你想调度低活跃周期的任务。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
CronJob resource in `batch/v2alpha1` API group has been deprecated starting from cluster version 1.8.
|
||||
You should switch to using `batch/v1beta1`, instead, which is enabled by default in the API server.
|
||||
Examples in this document use `batch/v1beta1` in all examples.
|
||||
-->
|
||||
从集群版本1.8开始，`batch/v2alpha1` API 组中的 CronJob 资源已经被废弃。
|
||||
你应该切换到 API 服务器默认启用的 `batch/v1beta1` API 组。本文中的所有示例使用了`batch/v1beta1`。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Cron jobs have limitations and idiosyncrasies.
|
||||
For example, in certain circumstances, a single cron job can create multiple jobs.
|
||||
Therefore, jobs should be idempotent.
|
||||
For more limitations, see [CronJobs](/docs/concepts/workloads/controllers/cron-jobs).
|
||||
-->
|
||||
|
||||
CronJobs 有一些限制和特点。
|
||||
例如，在特定状况下，同一个 CronJob 可以创建多个任务。
|
||||
因此，任务应该是幂等的。
|
||||
查看更多限制，请参考 [CronJobs](/docs/concepts/workloads/controllers/cron-jobs)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
<!--
|
||||
* You need a working Kubernetes cluster at version >= 1.8 (for CronJob). For previous versions of cluster (< 1.8)
|
||||
you need to explicitly enable `batch/v2alpha1` API by passing `--runtime-config=batch/v2alpha1=true` to
|
||||
the API server (see [Turn on or off an API version for your cluster](/docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster)
|
||||
for more), and then restart both the API server and the controller manager
|
||||
component.
|
||||
-->
|
||||
|
||||
* 你需要一个版本 >=1.8 且工作正常的 Kubernetes 集群。对于更早的版本（ <1.8 ），你需要对 API 服务器设置 `--runtime-config=batch/v2alpha1=true` 来开启 `batch/v2alpha1` API，(更多信息请查看 [为你的集群开启或关闭 API 版本](/docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster)
|
||||
), 然后重启 API 服务器和控制管理器。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!--
|
||||
## Creating a Cron Job
|
||||
|
||||
Cron jobs require a config file.
|
||||
This example cron job config `.spec` file prints the current time and a hello message every minute:
|
||||
-->
|
||||
|
||||
## 创建 CronJob
|
||||
|
||||
CronJob 需要一个配置文件。
|
||||
本例中 CronJob 的`.spec` 配置文件每分钟打印出当前时间和一个问好信息：
|
||||
|
||||
{{< codenew file="application/job/cronjob.yaml" >}}
|
||||
|
||||
<!--
|
||||
Run the example cron job by downloading the example file and then running this command:
|
||||
-->
|
||||
|
||||
想要运行示例的 CronJob，可以下载示例文件并执行命令：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f ./cronjob.yaml
|
||||
cronjob "hello" created
|
||||
```
|
||||
|
||||
<!--
|
||||
Alternatively, you can use `kubectl run` to create a cron job without writing a full config:
|
||||
-->
|
||||
|
||||
或者你也可以使用 `kubectl run` 来创建一个 CronJob 而不需要编写完整的配置：
|
||||
|
||||
```shell
|
||||
$ kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"
|
||||
cronjob "hello" created
|
||||
```
|
||||
|
||||
<!--
|
||||
After creating the cron job, get its status using this command:
|
||||
-->
|
||||
|
||||
创建好 CronJob 后，使用下面的命令来获取其状态：
|
||||
|
||||
```shell
|
||||
$ kubectl get cronjob hello
|
||||
NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE
|
||||
hello */1 * * * * False 0 <none>
|
||||
```
|
||||
|
||||
<!--
|
||||
As you can see from the results of the command, the cron job has not scheduled or run any jobs yet.
|
||||
Watch for the job to be created in around one minute:
|
||||
-->
|
||||
|
||||
就像你从命令返回结果看到的那样，CronJob 还没有调度或执行任何任务。大约需要一分钟任务才能创建好。
|
||||
|
||||
```shell
|
||||
$ kubectl get jobs --watch
|
||||
NAME DESIRED SUCCESSFUL AGE
|
||||
hello-4111706356 1 1 2s
|
||||
```
|
||||
|
||||
<!--
|
||||
Now you've seen one running job scheduled by the "hello" cron job.
|
||||
You can stop watching the job and view the cron job again to see that it scheduled the job:
|
||||
-->
|
||||
|
||||
现在你已经看到了一个运行中的任务被 “hello” CronJob 调度。你可以停止监视这个任务，然后再次查看 CronJob 就能看到它调度任务：
|
||||
|
||||
```shell
|
||||
$ kubectl get cronjob hello
|
||||
NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE
|
||||
hello */1 * * * * False 0 Mon, 29 Aug 2016 14:34:00 -0700
|
||||
```
|
||||
|
||||
<!--
|
||||
You should see that the cron job "hello" successfully scheduled a job at the time specified in `LAST-SCHEDULE`.
|
||||
There are currently 0 active jobs, meaning that the job has completed or failed.
|
||||
|
||||
Now, find the pods that the last scheduled job created and view the standard output of one of the pods.
|
||||
Note that the job name and pod name are different.
|
||||
-->
|
||||
|
||||
你应该能看到 “hello” CronJob 在 `LAST-SCHEDULE` 声明的时间点成功的调度了一次任务。有0个活跃的任务意味着任务执行完毕或者执行失败。
|
||||
|
||||
现在，找到最后一次调度任务创建的 Pod 并查看一个 Pod 的标准输出。请注意任务名称和 Pod 名称是不同的。
|
||||
|
||||
|
||||
```shell
|
||||
# Replace "hello-4111706356" with the job name in your system
|
||||
$ pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items..metadata.name})
|
||||
|
||||
$ echo $pods
|
||||
hello-4111706356-o9qcm
|
||||
|
||||
$ kubectl logs $pods
|
||||
Mon Aug 29 21:34:09 UTC 2016
|
||||
Hello from the Kubernetes cluster
|
||||
```
|
||||
|
||||
<!--
|
||||
## Deleting a Cron Job
|
||||
|
||||
When you don't need a cron job any more, delete it with `kubectl delete cronjob`:
|
||||
-->
|
||||
|
||||
## 删除 CronJob
|
||||
|
||||
当你不再需要 CronJob 时，可以用 `kubectl delete cronjob` 删掉它：
|
||||
|
||||
```shell
|
||||
$ kubectl delete cronjob hello
|
||||
cronjob "hello" deleted
|
||||
```
|
||||
<!--
|
||||
Deleting the cron job removes all the jobs and pods it created and stops it from creating additional jobs.
|
||||
You can read more about removing jobs in [garbage collection](/docs/concepts/workloads/controllers/garbage-collection/).
|
||||
-->
|
||||
|
||||
删除 CronJob 会清除它创建的所有任务和 Pod，并阻止它创建额外的任务。你可以查阅 [垃圾收集](/docs/concepts/workloads/controllers/garbage-collection/)。
|
||||
|
||||
<!--
|
||||
## Writing a Cron Job Spec
|
||||
|
||||
As with all other Kubernetes configs, a cron job needs `apiVersion`, `kind`, and `metadata` fields. For general
|
||||
information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications),
|
||||
and [using kubectl to manage resources](/docs/user-guide/working-with-resources) documents.
|
||||
|
||||
A cron job config also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
|
||||
-->
|
||||
|
||||
## 编写 CronJob 声明信息
|
||||
|
||||
像 Kubernetes 的其他配置一样，CronJob 需要 `apiVersion`、 `kind`、 和 `metadata` 域。配置文件的一般信息，请参考 [部署应用](/docs/user-guide/deploying-applications) 和 [使用 kubectl 管理资源](/docs/user-guide/working-with-resources).
|
||||
|
||||
CronJob 配置也需要包括[`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
All modifications to a cron job, especially its `.spec`, are applied only to the following runs.
|
||||
-->
|
||||
对 CronJob 的所有改动，特别是它的 `.spec`，只会影响将来的运行实例。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Schedule
|
||||
|
||||
The `.spec.schedule` is a required field of the `.spec`.
|
||||
It takes a [Cron](https://en.wikipedia.org/wiki/Cron) format string, such as `0 * * * *` or `@hourly`, as schedule time of its jobs to be created and executed.
|
||||
-->
|
||||
|
||||
### 时间安排
|
||||
|
||||
`.spec.schedule` 是 `.spec` 需要的域。它使用了 [Cron](https://en.wikipedia.org/wiki/Cron) 格式串，例如 `0 * * * *` or `@hourly` ，做为它的任务被创建和执行的调度时间。
|
||||
|
||||
<!--
|
||||
The format also includes extended `vixie cron` step values. As explained in the [FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29):
|
||||
-->
|
||||
|
||||
该格式也包含了扩展的 `vixie cron` 步长值。[FreeBSD 手册](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)中解释如下:
|
||||
|
||||
<!--
|
||||
> Step values can be used in conjunction with ranges. Following a range
|
||||
> with ``/<number>'' specifies skips of the number's value through the
|
||||
> range. For example, ``0-23/2'' can be used in the hours field to specify
|
||||
> command execution every other hour (the alternative in the V7 standard is
|
||||
> ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps are also permitted after an
|
||||
> asterisk, so if you want to say ``every two hours'', just use ``*/2''.
|
||||
-->
|
||||
|
||||
> 步长可被用于范围组合。范围后面带有 ``/<数字>'' 可以声明范围内的步幅数值。
|
||||
> 例如，``0-23/2'' 可被用在小时域来声明命令在其他数值的小时数执行（ V7 标准中对应的方法是``0,2,4,6,8,10,12,14,16,18,20,22''）。
|
||||
> 步长也可以放在通配符后面，因此如果你想表达 ``每两小时''，就用 ``*/2'' 。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
A question mark (`?`) in the schedule has the same meaning as an asterisk `*`, that is, it stands for any of available value for a given field.
|
||||
-->
|
||||
调度中的问号 (`?`) 和星号 `*` 含义相同，表示给定域的任何可用值。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Job Template
|
||||
|
||||
The `.spec.jobTemplate` is the template for the job, and it is required.
|
||||
It has exactly the same schema as a [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/), except that it is nested and does not have an `apiVersion` or `kind`.
|
||||
For information about writing a job `.spec`, see [Writing a Job Spec](/docs/concepts/workloads/controllers/jobs-run-to-completion/#writing-a-job-spec).
|
||||
-->
|
||||
|
||||
### 任务模版
|
||||
|
||||
`.spec.jobTemplate`是任务的模版，它是必须的。它和 [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)的语法完全一样，除了它是嵌套的没有 `apiVersion` 和 `kind`。
|
||||
编写任务的 `.spec` ，请参考 [编写任务的Spec](/docs/concepts/workloads/controllers/jobs-run-to-completion/#writing-a-job-spec)。
|
||||
|
||||
<!--
|
||||
### Starting Deadline
|
||||
|
||||
The `.spec.startingDeadlineSeconds` field is optional.
|
||||
It stands for the deadline in seconds for starting the job if it misses its scheduled time for any reason.
|
||||
After the deadline, the cron job does not start the job.
|
||||
Jobs that do not meet their deadline in this way count as failed jobs.
|
||||
If this field is not specified, the jobs have no deadline.
|
||||
-->
|
||||
|
||||
### 开始的最后期限
|
||||
|
||||
`.spec.startingDeadlineSeconds` 域是可选的。
|
||||
它表示任务如果由于某种原因错过了调度时间，开始该任务的截止时间的秒数。过了截止时间，CronJob 就不会开始任务。
|
||||
不满足这种最后期限的任务会被统计为失败任务。如果该域没有声明，那任务就没有最后期限。
|
||||
|
||||
<!--
|
||||
The CronJob controller counts how many missed schedules happen for a cron job. If there are more than 100 missed
|
||||
schedules, the cron job is no longer scheduled. When `.spec.startingDeadlineSeconds` is not set, the CronJob
|
||||
controller counts missed schedules from `status.lastScheduleTime` until now. For example, one cron job is
|
||||
supposed to run every minute, the `status.lastScheduleTime` of the cronjob is 5:00am, but now it's 7:00am.
|
||||
That means 120 schedules were missed, so the cron job is no longer scheduled. If the `.spec.startingDeadlineSeconds`
|
||||
field is set (not null), the CronJob controller counts how many missed jobs occurred from the value of
|
||||
`.spec.startingDeadlineSeconds` until now. For example, if it is set to `200`, it counts how many missed
|
||||
schedules occurred in the last 200 seconds. In that case, if there were more than 100 missed schedules in the
|
||||
last 200 seconds, the cron job is no longer scheduled.
|
||||
-->
|
||||
|
||||
CronJob 控制器会统计错过了多少次调度。如果错过了100次以上的调度，CronJob 就不再调度了。当没有设置 `.spec.startingDeadlineSeconds` 时，CronJob 控制器统计从`status.lastScheduleTime`到当前的调度错过次数。
|
||||
例如一个 CronJob 期望每分钟执行一次，`status.lastScheduleTime`是 5:00am，但现在是 7:00am。那意味着120次调度被错过了，所以 CronJob 将不再被调度。
|
||||
如果设置了 `.spec.startingDeadlineSeconds` 域(非空)，CronJob 控制器统计从 `.spec.startingDeadlineSeconds` 到当前时间错过了多少次任务。
|
||||
例如设置了 `200`，它会统计过去200秒内错过了多少次调度。在那种情况下，如果过去200秒内错过了超过100次的调度，CronJob 就不再调度。
|
||||
|
||||
<!--
|
||||
### Concurrency Policy
|
||||
|
||||
The `.spec.concurrencyPolicy` field is also optional.
|
||||
It specifies how to treat concurrent executions of a job that is created by this cron job.
|
||||
the spec may specify only one of the following concurrency policies:
|
||||
|
||||
* `Allow` (default): The cron job allows concurrently running jobs
|
||||
* `Forbid`: The cron job does not allow concurrent runs; if it is time for a new job run and the previous job run hasn't finished yet, the cron job skips the new job run
|
||||
* `Replace`: If it is time for a new job run and the previous job run hasn't finished yet, the cron job replaces the currently running job run with a new job run
|
||||
|
||||
Note that concurrency policy only applies to the jobs created by the same cron job.
|
||||
If there are multiple cron jobs, their respective jobs are always allowed to run concurrently.
|
||||
-->
|
||||
|
||||
### 并发性规则
|
||||
|
||||
`.spec.concurrencyPolicy` 也是可选的。它声明了 CronJob 创建的任务执行时发生重叠如何处理。spec 仅能声明下列规则中的一种：
|
||||
|
||||
* `Allow` (默认)：CronJob 允许并发任务执行。
|
||||
* `Forbid`： CronJob 不允许并发任务执行；如果新任务的执行时间到了而老任务没有执行完，CronJob 会忽略新任务的执行。
|
||||
* `Replace`：如果新任务的执行时间到了而老任务没有执行完，CronJob 会用新任务替换当前正在运行的任务。
|
||||
|
||||
请注意，并发性规则仅适用于相同 CronJob 创建的任务。如果有多个 CronJob，它们相应的任务总是允许并发执行的。
|
||||
|
||||
<!--
|
||||
### Suspend
|
||||
|
||||
The `.spec.suspend` field is also optional.
|
||||
If it is set to `true`, all subsequent executions are suspended.
|
||||
This setting does not apply to already started executions.
|
||||
Defaults to false.
|
||||
-->
|
||||
|
||||
### 挂起
|
||||
|
||||
`.spec.suspend`域也是可选的。如果设置为 `true` ，后续发生的执行都会挂起。这个设置对已经开始的执行不起作用。默认是关闭的。
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
Executions that are suspended during their scheduled time count as missed jobs.
|
||||
When `.spec.suspend` changes from `true` to `false` on an existing cron job without a [starting deadline](#starting-deadline), the missed jobs are scheduled immediately.
|
||||
-->
|
||||
在调度时间内挂起的执行都会被统计为错过的任务。当 `.spec.suspend` 从 `true` 改为 `false` 时，且没有 [开始的最后期限](#starting-deadline)，错过的任务会被立即调度。
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
### Jobs History Limits
|
||||
|
||||
The `.spec.successfulJobsHistoryLimit` and `.spec.failedJobsHistoryLimit` fields are optional.
|
||||
These fields specify how many completed and failed jobs should be kept.
|
||||
By default, they are set to 3 and 1 respectively. Setting a limit to `0` corresponds to keeping none of the corresponding kind of jobs after they finish.
|
||||
-->
|
||||
|
||||
### 任务历史限制
|
||||
|
||||
`.spec.successfulJobsHistoryLimit` 和 `.spec.failedJobsHistoryLimit`是可选的。
|
||||
这两个域声明了有多少执行完成和失败的任务会被保留。
|
||||
默认设置为3和1。限制设置为0代表相应类型的任务完成后不会保留。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -5,7 +5,7 @@ title: 调度 GPU
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
<!--
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- vishh
|
||||
@@ -314,7 +314,7 @@ spec:
|
||||
accelerator: nvidia-tesla-p100 # or nvidia-tesla-k80 etc.
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
This will ensure that the pod will be scheduled to a node that has the GPU type
|
||||
you specified.
|
||||
-->
|
||||
|
||||
@@ -0,0 +1,133 @@
|
||||
---
|
||||
reviewers:
|
||||
- bprashanth
|
||||
- erictune
|
||||
- foxish
|
||||
- janetkuo
|
||||
- smarterclayton
|
||||
title: 删除 StatefulSet
|
||||
content_template: templates/task
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
This task shows you how to delete a StatefulSet.
|
||||
--->
|
||||
本文介绍如何删除 StatefulSet。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
<!--
|
||||
* This task assumes you have an application running on your cluster represented by a StatefulSet.
|
||||
--->
|
||||
* 本文假设在您的集群上已经运行了由 StatefulSet 创建的应用。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 删除 StatefulSet
|
||||
|
||||
<!--
|
||||
You can delete a StatefulSet in the same way you delete other resources in Kubernetes: use the `kubectl delete` command, and specify the StatefulSet either by file or by name.
|
||||
--->
|
||||
您可以像删除 Kubernetes 中的其他资源一样删除 StatefulSet：使用 `kubectl delete` 命令，并按文件或者名字指定 StatefulSet。
|
||||
|
||||
```shell
|
||||
kubectl delete -f <file.yaml>
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl delete statefulsets <statefulset-name>
|
||||
```
|
||||
|
||||
<!--
|
||||
You may need to delete the associated headless service separately after the StatefulSet itself is deleted.
|
||||
--->
|
||||
删除 StatefulSet 之后，您可能需要单独删除关联的无头服务。
|
||||
|
||||
```shell
|
||||
kubectl delete service <service-name>
|
||||
```
|
||||
|
||||
<!--
|
||||
Deleting a StatefulSet through kubectl will scale it down to 0, thereby deleting all pods that are a part of it.
|
||||
If you want to delete just the StatefulSet and not the pods, use `--cascade=false`.
|
||||
--->
|
||||
通过 kubectl 删除 StatefulSet 会将其缩容为0，因此删除属于它的所有pods。
|
||||
如果您只想删除 StatefulSet 而不删除 pods，使用 `--cascade=false`。
|
||||
|
||||
```shell
|
||||
kubectl delete -f <file.yaml> --cascade=false
|
||||
```
|
||||
|
||||
<!--
|
||||
By passing `--cascade=false` to `kubectl delete`, the Pods managed by the StatefulSet are left behind even after the StatefulSet object itself is deleted. If the pods have a label `app=myapp`, you can then delete them as follows:
|
||||
--->
|
||||
通过将 `--cascade=false` 传递给 `kubectl delete`，在删除 StatefulSet 对象之后，StatefulSet 管理的 pods 会被保留下来。如果 pods 有一个标签 `app=myapp`，则可以按照如下方式删除它们：
|
||||
|
||||
```shell
|
||||
kubectl delete pods -l app=myapp
|
||||
```
|
||||
|
||||
### Persistent Volumes
|
||||
|
||||
<!--
|
||||
Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have left the [terminating state](/docs/concepts/workloads/pods/pod/#termination-of-pods) might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
|
||||
--->
|
||||
删除 StatefulSet 管理的 pods 并不会删除关联的卷。这是为了确保您有机会在删除卷之前从卷中复制数据。在pods离开[终止状态](/docs/concepts/workloads/pods/pod/#termination-of-pods)后删除 PVC 可能会触发删除支持的 Persistent Volumes，具体取决于存储类和回收策略。声明删除后，您永远不应该假设能够访问卷。
|
||||
|
||||
<!--
|
||||
**Note: Use caution when deleting a PVC, as it may lead to data loss.**
|
||||
--->
|
||||
**注意：删除 PVC 时要谨慎，因为这可能会导致数据丢失。**
|
||||
|
||||
<!--
|
||||
### Complete deletion of a StatefulSet
|
||||
--->
|
||||
### 完全删除 StatefulSet
|
||||
|
||||
<!--
|
||||
To simply delete everything in a StatefulSet, including the associated pods, you can run a series of commands similar to the following:
|
||||
--->
|
||||
要简单地删除 StatefulSet 中的所有内容，包括关联的 pods，您可能需要运行一系列类似于以下内容的命令：
|
||||
|
||||
```shell
|
||||
grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}')
|
||||
kubectl delete statefulset -l app=myapp
|
||||
sleep $grace
|
||||
kubectl delete pvc -l app=myapp
|
||||
|
||||
```
|
||||
|
||||
<!--
|
||||
In the example above, the Pods have the label `app=myapp`; substitute your own label as appropriate.
|
||||
--->
|
||||
在上面的例子中，pods 的标签为 `app=myapp`；适当地替换您自己的标签。
|
||||
|
||||
<!--
|
||||
### Force deletion of StatefulSet pods
|
||||
--->
|
||||
### 强制删除 StatefulSet 类型的 pods
|
||||
|
||||
<!--
|
||||
If you find that some pods in your StatefulSet are stuck in the 'Terminating' or 'Unknown' states for an extended period of time, you may need to manually intervene to forcefully delete the pods from the apiserver. This is a potentially dangerous task. Refer to [Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/) for details.
|
||||
--->
|
||||
如果您发现 StatefulSet 中的某些 pods 长时间处于 'Terminating' 或者 'Unknown' 状态，则可能需要手动干预以强制从 apiserver 中删除 pods。这是一项潜在的危险任务。详细信息请阅读[删除 StatefulSet 类型的 Pods](/docs/tasks/manage-stateful-set/delete-pods/)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
Learn more about [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).
|
||||
--->
|
||||
了解更多有关[强制删除 StatefulSet 类型的 Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -6,9 +6,9 @@ approvers:
|
||||
---
|
||||
|
||||
|
||||
本示例描述了如何在 Kubeernetes 上持久化安装 [WordPress](https://wordpress.org/) 和
|
||||
[MySQL](https://www.mysql.com/) 。在这个安装里我们将使用官方的 [mysql](https://registry.hub.docker.com/_/mysql/) 和
|
||||
[wordpress](https://registry.hub.docker.com/_/wordpress/) 镜像（WordPress 镜像包含一个 Apache 服务）。
|
||||
本示例描述了如何在 Kubernetes 上持久化安装 [WordPress](https://wordpress.org/) 和
|
||||
[MySQL](https://www.mysql.com/) 。在这个安装里我们将使用官方的 [MySQL](https://registry.hub.docker.com/_/mysql/) 和
|
||||
[WordPress](https://registry.hub.docker.com/_/wordpress/) 镜像（WordPress 镜像包含一个 Apache 服务）。
|
||||
|
||||
|
||||
展示的 Kubernetes 概念：
|
||||
|
||||
@@ -52,7 +52,7 @@ kubectl run [-i] [--tty] --attach <name> --image=<image>
|
||||
与 `docker run ...` 不同的是，如果指定了 `--attach` ，我们将连接到 `stdin`，`stdout` 和 `stderr`，而不能控制具体连接到哪个输出流（`docker -a ...`）。
|
||||
|
||||
因为我们使用 Deployment 启动了容器，如果您终止了连接到的进程（例如 `ctrl-c`），容器将会重启，这跟 `docker run -it` 不同。
|
||||
如果想销毁该 Deployment（和它的 pod），您需要运行 `kubeclt delete deployment <name>`。
|
||||
如果想销毁该 Deployment（和它的 pod），您需要运行 `kubectl delete deployment <name>`。
|
||||
|
||||
#### docker ps
|
||||
|
||||
|
||||
Reference in New Issue
Block a user