|
1 | 1 | ---
|
2 | 2 | title: StatefulSets
|
3 | 3 | content_type: concept
|
4 |
| -weight: 40 |
| 4 | +weight: 30 |
5 | 5 | ---
|
6 | 6 |
|
7 | 7 | <!--
|
@@ -146,15 +146,25 @@ spec:
|
146 | 146 | ```
|
147 | 147 |
|
148 | 148 | <!--
|
| 149 | +In the above example: |
| 150 | +
|
149 | 151 | * A Headless Service, named `nginx`, is used to control the network domain.
|
150 | 152 | * The StatefulSet, named `web`, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods.
|
151 | 153 | * The `volumeClaimTemplates` will provide stable storage using [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume Provisioner.
|
| 154 | + |
| 155 | +The name of a StatefulSet object must be a valid |
| 156 | +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). |
| 157 | + |
152 | 158 | -->
|
| 159 | +上述例子中: |
| 160 | + |
153 | 161 | * 名为 `nginx` 的 Headless Service 用来控制网络域名。
|
154 | 162 | * 名为 `web` 的 StatefulSet 有一个 Spec,它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。
|
155 | 163 | * `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的
|
156 | 164 | [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
|
157 | 165 |
|
| 166 | +StatefulSet 的命名需要遵循[DNS 子域名](zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)规范。 |
| 167 | + |
158 | 168 | <!--
|
159 | 169 | ## Pod Selector
|
160 | 170 | -->
|
@@ -217,9 +227,48 @@ StatefulSet 可以使用 [无头服务](/zh/docs/concepts/services-networking/se
|
217 | 227 | 一旦每个 Pod 创建成功,就会得到一个匹配的 DNS 子域,格式为:
|
218 | 228 | `$(pod 名称).$(所属服务的 DNS 域名)`,其中所属服务由 StatefulSet 的 `serviceName` 域来设定。
|
219 | 229 |
|
| 230 | +<!-- |
| 231 | +Depending on how DNS is configured in your cluster, you may not be able to look up the DNS |
| 232 | +name for a newly-run Pod immediately. This behavior can occur when other clients in the |
| 233 | +cluster have already sent queries for the hostname of the Pod before it was created. |
| 234 | +Negative caching (normal in DNS) means that the results of previous failed lookups are |
| 235 | +remembered and reused, even after the Pod is running, for at least a few seconds. |
| 236 | + |
| 237 | +If you need to discover Pods promptly after they are created, you have a few options: |
| 238 | + |
| 239 | +- Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups. |
| 240 | +- Decrease the time of caching in your Kubernetes DNS provider (typically this means editing the config map for CoreDNS, which currently caches for 30 seconds). |
| 241 | + |
| 242 | + |
| 243 | +As mentioned in the [limitations](#limitations) section, you are responsible for |
| 244 | +creating the [Headless Service](/docs/concepts/services-networking/service/#headless-services) |
| 245 | +responsible for the network identity of the pods. |
| 246 | + |
| 247 | +--> |
| 248 | +取决于集群域内部 DNS 的配置,有可能无法查询一个刚刚启动的 Pod 的 DNS 命名。 |
| 249 | +当集群内其他客户端在 Pod 创建完成前发出 Pod 主机名查询时,就会发生这种情况。 |
| 250 | +负缓存 (在 DNS 中较为常见) 意味着之前失败的查询结果会被记录和重用至少若干秒钟, |
| 251 | +即使 Pod 已经正常运行了也是如此。 |
| 252 | + |
| 253 | +如果需要在 Pod 被创建之后及时发现它们,有以下选项: |
| 254 | + |
| 255 | +- 直接查询 Kubernetes API(比如,利用 watch 机制)而不是依赖于 DNS 查询 |
| 256 | +- 缩短 Kubernetes DNS 驱动的缓存时长(通常这意味着修改 CoreDNS 的 ConfigMap,目前缓存时长为 30 秒) |
| 257 | + |
| 258 | +正如[限制](#limitations)中所述,你需要负责创建[无头服务](/zh/docs/concepts/services-networking/service/#headless-services) |
| 259 | +以便为 Pod 提供网络标识。 |
| 260 | + |
220 | 261 | <!--
|
221 | 262 | Here are some examples of choices for Cluster Domain, Service name,
|
222 | 263 | StatefulSet name, and how that affects the DNS names for the StatefulSet's Pods.
|
| 264 | + |
| 265 | + |
| 266 | +Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain | Pod DNS | Pod Hostname | |
| 267 | +-------------- | ----------------- | ----------------- | -------------- | ------- | ------------ | |
| 268 | + cluster.local | default/nginx | default/web | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} | |
| 269 | + cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} | |
| 270 | + kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | |
| 271 | + |
223 | 272 | -->
|
224 | 273 | 下面给出一些选择集群域、服务名、StatefulSet 名、及其怎样影响 StatefulSet 的 Pod 上的 DNS 名称的示例:
|
225 | 274 |
|
@@ -350,12 +399,14 @@ described [above](#deployment-and-scaling-guarantees).
|
350 | 399 | `Parallel` pod management tells the StatefulSet controller to launch or
|
351 | 400 | terminate all Pods in parallel, and to not wait for Pods to become Running
|
352 | 401 | and Ready or completely terminated prior to launching or terminating another
|
353 |
| -Pod. |
| 402 | +Pod. This option only affects the behavior for scaling operations. Updates are not affected. |
| 403 | + |
354 | 404 | -->
|
355 | 405 | #### 并行 Pod 管理 {#parallel-pod-management}
|
356 | 406 |
|
357 | 407 | `Parallel` Pod 管理让 StatefulSet 控制器并行的启动或终止所有的 Pod,
|
358 | 408 | 启动或者终止其他 Pod 前,无需等待 Pod 进入 Running 和 ready 或者完全停止状态。
|
| 409 | +这个选项只会影响伸缩操作的行为,更新则不会被影响。 |
359 | 410 |
|
360 | 411 | <!--
|
361 | 412 | ## Update Strategies
|
@@ -476,4 +527,3 @@ StatefulSet 才会开始使用被还原的模板来重新创建 Pod。
|
476 | 527 | * 示例一:[部署有状态应用](/zh/docs/tutorials/stateful-application/basic-stateful-set/)。
|
477 | 528 | * 示例二:[使用 StatefulSet 部署 Cassandra](/zh/docs/tutorials/stateful-application/cassandra/)。
|
478 | 529 | * 示例三:[运行多副本的有状态应用程序](/zh/docs/tasks/run-application/run-replicated-stateful-application/)。
|
479 |
| - |
|
0 commit comments