[zh] sync access-api-from-pod.md
Michael
parent
cdef82baef
commit
079cb54c58
|
|
@ -1,5 +1,10 @@
|
|||
---
|
||||
title: "运行应用"
|
||||
weight: 40
|
||||
description: 运行和管理无状态和有状态的应用程序。
|
||||
weight: 80
|
||||
description: 运行和管理无状态和有状态的应用。
|
||||
---
|
||||
<!--
|
||||
title: "Run Applications"
|
||||
description: Run and manage both stateless and stateful applications.
|
||||
weight: 80
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ title: 从 Pod 中访问 Kubernetes API
|
|||
content_type: task
|
||||
weight: 120
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Accessing the Kubernetes API from a Pod
|
||||
content_type: task
|
||||
|
|
@ -31,8 +30,7 @@ to the API server are slightly different to the external client case.
|
|||
-->
|
||||
### 从 Pod 中访问 API {#accessing-the-api-from-within-a-pod}
|
||||
|
||||
从 Pod 内部访问 API 时，定位 API 服务器和向服务器认证身份的操作
|
||||
与外部客户端场景不同。
|
||||
从 Pod 内部访问 API 时，定位 API 服务器和向服务器认证身份的操作与外部客户端场景不同。
|
||||
|
||||
<!--
|
||||
The easiest way to use the Kubernetes API from a Pod is to use
|
||||
|
|
@ -47,7 +45,12 @@ libraries can automatically discover the API server and authenticate.
|
|||
### Using Official Client Libraries
|
||||
|
||||
From within a Pod, the recommended ways to connect to the Kubernetes API are:
|
||||
-->
|
||||
#### 使用官方客户端库 {#using-official-client-libraries}
|
||||
|
||||
从一个 Pod 内部连接到 Kubernetes API 的推荐方式为：
|
||||
|
||||
<!--
|
||||
- For a Go client, use the official
|
||||
[Go client library](https://github.com/kubernetes/client-go/).
|
||||
The `rest.InClusterConfig()` function handles API host discovery and authentication automatically.
|
||||
|
|
@ -60,14 +63,7 @@ From within a Pod, the recommended ways to connect to the Kubernetes API are:
|
|||
|
||||
- There are a number of other libraries available, please refer to the
|
||||
[Client Libraries](/docs/reference/using-api/client-libraries/) page.
|
||||
|
||||
In each case, the service account credentials of the Pod are used to communicate
|
||||
securely with the API server.
|
||||
-->
|
||||
#### 使用官方客户端库 {#using-official-client-libraries}
|
||||
|
||||
从一个 Pod 内部连接到 Kubernetes API 的推荐方式为：
|
||||
|
||||
- 对于 Go 语言客户端，使用官方的 [Go 客户端库](https://github.com/kubernetes/client-go/)。
|
||||
函数 `rest.InClusterConfig()` 自动处理 API 主机发现和身份认证。
|
||||
参见[这里的一个例子](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)。
|
||||
|
|
@ -78,6 +74,10 @@ securely with the API server.
|
|||
|
||||
- 还有一些其他可用的客户端库，请参阅[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)页面。
|
||||
|
||||
<!--
|
||||
In each case, the service account credentials of the Pod are used to communicate
|
||||
securely with the API server.
|
||||
-->
|
||||
在以上场景中，客户端库都使用 Pod 的服务账号凭据来与 API 服务器安全地通信。
|
||||
|
||||
<!--
|
||||
|
|
@ -118,15 +118,15 @@ at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
|
|||
-->
|
||||
向 API 服务器进行身份认证的推荐做法是使用
|
||||
[服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)凭据。
|
||||
默认情况下，每个 Pod 与一个服务账号关联，该服务账户的凭证（令牌）放置在此 Pod 中
|
||||
每个容器的文件系统树中的 `/var/run/secrets/kubernetes.io/serviceaccount/token` 处。
|
||||
默认情况下，每个 Pod 与一个服务账号关联，该服务账号的凭据（令牌）放置在此 Pod
|
||||
中每个容器的文件系统树中的 `/var/run/secrets/kubernetes.io/serviceaccount/token` 处。
|
||||
|
||||
<!--
|
||||
If available, a certificate bundle is placed into the filesystem tree of each
|
||||
container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be
|
||||
used to verify the serving certificate of the API server.
|
||||
-->
|
||||
如果证书包可用，则凭证包被放入每个容器的文件系统树中的
|
||||
如果证书包可用，则凭据包被放入每个容器的文件系统树中的
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` 处，
|
||||
且将被用于验证 API 服务器的服务证书。
|
||||
|
||||
|
|
@ -151,8 +151,8 @@ in the Pod can use it directly.
|
|||
如果你希望不使用官方客户端库就完成 API 查询，可以将 `kubectl proxy` 作为
|
||||
[command](/zh-cn/docs/tasks/inject-data-application/define-command-argument-container/)
|
||||
在 Pod 中启动一个边车（Sidecar）容器。这样，`kubectl proxy` 自动完成对 API
|
||||
的身份认证，并将其暴露到 Pod 的 `localhost` 接口，从而 Pod 中的其他容器可以
|
||||
直接使用 API。
|
||||
的身份认证，并将其暴露到 Pod 的 `localhost` 接口，从而 Pod
|
||||
中的其他容器可以直接使用 API。
|
||||
|
||||
<!--
|
||||
### Without using a proxy
|
||||
|
|
@ -163,8 +163,27 @@ directly to the API server. The internal certificate secures the connection.
|
|||
### 不使用代理 {#without-using-a-proxy}
|
||||
|
||||
通过将认证令牌直接发送到 API 服务器，也可以避免运行 kubectl proxy 命令。
|
||||
内部的证书机制能够为链接提供保护。
|
||||
内部的证书机制能够为连接提供保护。
|
||||
|
||||
<!--
|
||||
# Point to the internal API server hostname
|
||||
APISERVER=https://kubernetes.default.svc
|
||||
|
||||
# Path to ServiceAccount token
|
||||
SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
|
||||
|
||||
# Read this Pod's namespace
|
||||
NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
|
||||
|
||||
# Read the ServiceAccount bearer token
|
||||
TOKEN=$(cat ${SERVICEACCOUNT}/token)
|
||||
|
||||
# Reference the internal certificate authority (CA)
|
||||
CACERT=${SERVICEACCOUNT}/ca.crt
|
||||
|
||||
# Explore the API with TOKEN
|
||||
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
|
||||
-->
|
||||
```shell
|
||||
# 指向内部 API 服务器的主机名
|
||||
APISERVER=https://kubernetes.default.svc
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ title: 强制删除 StatefulSet 中的 Pod
|
|||
content_type: task
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!--
|
||||
reviewers:
|
||||
- bprashanth
|
||||
|
|
@ -16,23 +15,24 @@ weight: 70
|
|||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page shows how to delete Pods which are part of a
|
||||
{{< glossary_tooltip text="stateful set" term_id="StatefulSet" >}},
|
||||
and explains the considerations to keep in mind when doing so.
|
||||
-->
|
||||
本文介绍如何删除 {{< glossary_tooltip text="StatefulSet" term_id="StatefulSet" >}}
|
||||
管理的 Pod，并解释这样操作时需要记住的注意事项。
|
||||
管理的 Pod，并解释这样操作时需要记住的一些注意事项。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
<!--
|
||||
* This is a fairly advanced task and has the potential to violate some of the properties
|
||||
- This is a fairly advanced task and has the potential to violate some of the properties
|
||||
inherent to StatefulSet.
|
||||
* Before proceeding, make yourself familiar with the considerations enumerated below.
|
||||
- Before proceeding, make yourself familiar with the considerations enumerated below.
|
||||
-->
|
||||
* 这是一项相当高级的任务，并且可能会违反 StatefulSet 固有的某些属性。
|
||||
* 继续任务之前，请熟悉下面列举的注意事项。
|
||||
- 这是一项相当高级的任务，并且可能会违反 StatefulSet 固有的某些属性。
|
||||
- 请先熟悉下面列举的注意事项再开始操作。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -46,11 +46,11 @@ number of Pods from ordinal 0 through N-1 are alive and ready. StatefulSet ensur
|
|||
there is at most one Pod with a given identity running in a cluster. This is referred to as
|
||||
*at most one* semantics provided by a StatefulSet.
|
||||
-->
|
||||
## StatefulSet 注意事项
|
||||
## StatefulSet 注意事项 {#statefulset-considerations}
|
||||
|
||||
在 StatefulSet 的正常操作中，**永远不**需要强制删除 StatefulSet 管理的 Pod。
|
||||
在正常操作 StatefulSet 时，**永远不**需要强制删除 StatefulSet 管理的 Pod。
|
||||
[StatefulSet 控制器](/zh-cn/docs/concepts/workloads/controllers/statefulset/)负责创建、
|
||||
扩缩和删除 StatefulSet 管理的 Pod。它尝试确保指定数量的从序数 0 到 N-1 的 Pod
|
||||
扩缩和删除 StatefulSet 管理的 Pod。此控制器尽力确保指定数量的从序数 0 到 N-1 的 Pod
|
||||
处于活跃状态并准备就绪。StatefulSet 确保在任何时候，集群中最多只有一个具有给定标识的 Pod。
|
||||
这就是所谓的由 StatefulSet 提供的**最多一个（At Most One）** Pod 的语义。
|
||||
|
||||
|
|
@ -63,9 +63,9 @@ members with fixed identities. Having multiple members with the same identity ca
|
|||
and may lead to data loss (e.g. split brain scenario in quorum-based systems).
|
||||
-->
|
||||
应谨慎进行手动强制删除操作，因为它可能会违反 StatefulSet 固有的至多一个的语义。
|
||||
StatefulSets 可用于运行分布式和集群级的应用，这些应用需要稳定的网络标识和可靠的存储。
|
||||
StatefulSet 可用于运行分布式和集群级的应用，这些应用需要稳定的网络标识和可靠的存储。
|
||||
这些应用通常配置为具有固定标识固定数量的成员集合。
|
||||
具有相同身份的多个成员可能是灾难性的，并且可能导致数据丢失 (例如：票选系统中的脑裂场景)。
|
||||
具有相同身份的多个成员可能是灾难性的，并且可能导致数据丢失 (例如票选系统中的脑裂场景)。
|
||||
|
||||
<!--
|
||||
## Delete Pods
|
||||
|
|
@ -101,24 +101,23 @@ Pods may also enter these states when the user attempts graceful deletion of a P
|
|||
on an unreachable Node.
|
||||
The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
|
||||
-->
|
||||
当某个节点不可达时，不会引发自动删除 Pod。
|
||||
在无法访问的节点上运行的 Pod 在
|
||||
[超时](/zh-cn/docs/concepts/architecture/nodes/#condition)
|
||||
后会进入 “Terminating” 或者 “Unknown” 状态。
|
||||
当某个节点不可达时，不会引发自动删除 Pod。在无法访问的节点上运行的 Pod
|
||||
在[超时](/zh-cn/docs/concepts/architecture/nodes/#condition)后会进入
|
||||
“Terminating” 或者 “Unknown” 状态。
|
||||
当用户尝试体面地删除无法访问的节点上的 Pod 时 Pod 也可能会进入这些状态。
|
||||
从 API 服务器上删除处于这些状态 Pod 的仅有可行方法如下：
|
||||
|
||||
<!--
|
||||
* The Node object is deleted (either by you, or by the
|
||||
- The Node object is deleted (either by you, or by the
|
||||
[Node Controller](/docs/concepts/architecture/nodes/#node-controller)).
|
||||
* The kubelet on the unresponsive Node starts responding, kills the Pod and removes the entry
|
||||
- The kubelet on the unresponsive Node starts responding, kills the Pod and removes the entry
|
||||
from the apiserver.
|
||||
* Force deletion of the Pod by the user.
|
||||
- Force deletion of the Pod by the user.
|
||||
-->
|
||||
* 删除 Node 对象（要么你来删除, 要么[节点控制器](/zh-cn/docs/concepts/architecture/nodes/#node-controller)
|
||||
- 删除 Node 对象（要么你来删除, 要么[节点控制器](/zh-cn/docs/concepts/architecture/nodes/#node-controller)
|
||||
来删除）
|
||||
* 无响应节点上的 kubelet 开始响应，杀死 Pod 并从 API 服务器上移除 Pod 对象
|
||||
* 用户强制删除 pod
|
||||
- 无响应节点上的 kubelet 开始响应，杀死 Pod 并从 API 服务器上移除 Pod 对象
|
||||
- 用户强制删除 Pod
|
||||
|
||||
<!--
|
||||
The recommended best practice is to use the first or second approach. If a Node is confirmed
|
||||
|
|
@ -155,8 +154,8 @@ will violate the at most one semantics that StatefulSet is designed to guarantee
|
|||
强制删除**不会**等待来自 kubelet 对 Pod 已终止的确认消息。
|
||||
无论强制删除是否成功杀死了 Pod，它都会立即从 API 服务器中释放该名字。
|
||||
这将让 StatefulSet 控制器创建一个具有相同标识的替身 Pod；因而可能导致正在运行 Pod 的重复，
|
||||
并且如果所述 Pod 仍然可以与 StatefulSet 的成员通信，则将违反 StatefulSet 所要保证的
|
||||
最多一个的语义。
|
||||
并且如果所述 Pod 仍然可以与 StatefulSet 的成员通信，则将违反 StatefulSet
|
||||
所要保证的最多一个的语义。
|
||||
|
||||
<!--
|
||||
When you force delete a StatefulSet pod, you are asserting that the Pod in question will never
|
||||
|
|
@ -188,7 +187,7 @@ kubectl delete pods <pod> --grace-period=0
|
|||
If even after these commands the pod is stuck on `Unknown` state, use the following command to
|
||||
remove the pod from the cluster:
|
||||
-->
|
||||
如果在这些命令后 Pod 仍处于 `Unknown` 状态，请使用以下命令从集群中删除 Pod:
|
||||
如果在执行这些命令后 Pod 仍处于 `Unknown` 状态，请使用以下命令从集群中删除 Pod:
|
||||
|
||||
```shell
|
||||
kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'
|
||||
|
|
|
|||
Loading…
Reference in New Issue