committed by
Kubernetes Prow Robot
parent
0268ed0c18
commit
b05129acc3
@@ -3,11 +3,11 @@ title: 运行应用程序的多个实例
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!--
|
||||
<!--
|
||||
---
|
||||
title: Running Multiple Instances of Your App
|
||||
weight: 10
|
||||
---
|
||||
---
|
||||
-->
|
||||
|
||||
<!DOCTYPE html>
|
||||
|
||||
+1
-1
@@ -134,4 +134,4 @@ kubectl create --edit -f /tmp/srv.yaml
|
||||
- [Kubernetes 对象模式参考](/docs/resources-reference/v1.6/)
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -150,4 +150,4 @@ kubectl apply -R -f configs/
|
||||
{{< /comment >}}
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -164,7 +164,7 @@ client_address=10.240.0.3
|
||||
为了防止这种情况发生,Kubernetes 提供了一个特性来保留客户端的源 IP 地址[(点击此处查看可用特性)](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)。设置 `service.spec.externalTrafficPolicy` 的值为 `Local`,请求就只会被代理到本地 endpoints 而不会被转发到其它节点。这样就保留了最初的源 IP 地址。如果没有本地 endpoints,发送到这个节点的数据包将会被丢弃。这样在应用到数据包的任何包处理规则下,你都能依赖这个正确的 source-ip 使数据包通过并到达 endpoint。
|
||||
|
||||
|
||||
设置 `service.spec.externalTrafficPolicy` 字段如下:
|
||||
设置 `service.spec.externalTrafficPolicy` 字段如下:
|
||||
|
||||
```console
|
||||
$ kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
||||
|
||||
@@ -67,7 +67,7 @@ kubectl get pods -w -l app=nginx
|
||||
在另一个终端中,使用 [`kubectl create`](/docs/user-guide/kubectl/{{< param "version" >}}/#create) 来创建定义在 `web.yaml` 中的 Headless Service 和 StatefulSet。
|
||||
|
||||
```shell
|
||||
kubectl create -f web.yaml
|
||||
kubectl create -f web.yaml
|
||||
service "nginx" created
|
||||
statefulset "web" created
|
||||
```
|
||||
@@ -149,7 +149,7 @@ web-1
|
||||
使用 [`kubectl run`](/docs/user-guide/kubectl/{{< param "version" >}}/#run) 运行一个提供 `nslookup` 命令的容器,该命令来自于 `dnsutils` 包。通过对 Pod 的主机名执行 `nslookup`,你可以检查他们在集群内部的 DNS 地址。
|
||||
|
||||
```shell
|
||||
kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh
|
||||
kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh
|
||||
nslookup web-0.nginx
|
||||
Server: 10.0.0.10
|
||||
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
|
||||
@@ -206,7 +206,7 @@ for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
|
||||
web-0
|
||||
web-1
|
||||
|
||||
kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh
|
||||
kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh
|
||||
nslookup web-0.nginx
|
||||
Server: 10.0.0.10
|
||||
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
|
||||
@@ -433,7 +433,7 @@ Kubernetes 1.7 版本的 StatefulSet 控制器支持自动更新。更新策略
|
||||
`OnDelete` 更新策略实现了传统(1.7之前)行为,它也是默认的更新策略。当你选择这个更新策略并修改 StatefulSet 的 `.spec.template` 字段时, StatefulSet 控制器将不会自动的更新Pod。
|
||||
|
||||
|
||||
Patch `web` StatefulSet 的容器镜像。
|
||||
Patch `web` StatefulSet 的容器镜像。
|
||||
|
||||
```shell
|
||||
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]'
|
||||
@@ -479,7 +479,7 @@ web-2 k8s.gcr.io/nginx-slim:0.8
|
||||
```
|
||||
|
||||
<!--
|
||||
`web-0` has had its image updated, but `web-0` and `web-1` still have the original
|
||||
`web-0` has had its image updated, but `web-0` and `web-1` still have the original
|
||||
image. Complete the update by deleting the remaining Pods.
|
||||
-->
|
||||
`web-0` 已经更新了它的镜像,但是 `web-1` 和 `web-2` 仍保留了原始镜像。
|
||||
@@ -850,7 +850,7 @@ kubectl get pods -w -l app=nginx
|
||||
在另一个终端里重新创建 StatefulSet。请注意,除非你删除了 `nginx` Service (你不应该这样做),你将会看到一个错误,提示 Service 已经存在。
|
||||
|
||||
```shell
|
||||
kubectl create -f web.yaml
|
||||
kubectl create -f web.yaml
|
||||
statefulset "web" created
|
||||
Error from server (AlreadyExists): error when creating "web.yaml": services "nginx" already exists
|
||||
```
|
||||
@@ -943,7 +943,7 @@ service "nginx" deleted
|
||||
再一次重新创建 StatefulSet 和 Headless Service。
|
||||
|
||||
```shell
|
||||
kubectl create -f web.yaml
|
||||
kubectl create -f web.yaml
|
||||
service "nginx" created
|
||||
statefulset "web" created
|
||||
```
|
||||
@@ -1008,7 +1008,7 @@ kubectl get po -lapp=nginx -w
|
||||
在另一个终端窗口创建清单中的 StatefulSet 和 Service。
|
||||
|
||||
```shell
|
||||
kubectl create -f webp.yaml
|
||||
kubectl create -f webp.yaml
|
||||
service "nginx" created
|
||||
statefulset "web" created
|
||||
```
|
||||
@@ -1052,7 +1052,7 @@ web-3 1/1 Running 0 26s
|
||||
```
|
||||
|
||||
<!
|
||||
The StatefulSet controller launched two new Pods, and it did not wait for
|
||||
The StatefulSet controller launched two new Pods, and it did not wait for
|
||||
the first to become Running and Ready prior to launching the second.
|
||||
|
||||
Keep this terminal open, and in another terminal delete the `web` StatefulSet.
|
||||
|
||||
@@ -62,7 +62,7 @@ content_template: templates/tutorial
|
||||
ensemble 使用 Zab 协议选举一个 leader,在选举出 leader 前不能写入数据。一旦选举出了 leader,ensemble 使用 Zab 保证所有写入被复制到一个 quorum,然后这些写入操作才会被确认并对客户端可用。如果没有遵照加权 quorums,一个 quorum 表示包含当前 leader 的 ensemble 的多数成员。例如,如果 ensemble 有3个服务,一个包含 leader 的成员和另一个服务就组成了一个 quorum。如果 ensemble 不能达成一个 quorum,数据将不能被写入。
|
||||
|
||||
|
||||
ZooKeeper 在内存中保存它们的整个状态机,但是每个改变都被写入一个在存储介质上的持久 WAL(Write Ahead Log)。当一个服务故障时,它能够通过回放 WAL 恢复之前的状态。为了防止 WAL 无限制的增长,ZooKeeper 服务会定期的将内存状态快照保存到存储介质。这些快照能够直接加载到内存中,所有在这个快照之前的 WAL 条目都可以被安全的丢弃。
|
||||
ZooKeeper 在内存中保存它们的整个状态机,但是每个改变都被写入一个在存储介质上的持久 WAL(Write Ahead Log)。当一个服务故障时,它能够通过回放 WAL 恢复之前的状态。为了防止 WAL 无限制的增长,ZooKeeper 服务会定期的将内存状态快照保存到存储介质。这些快照能够直接加载到内存中,所有在这个快照之前的 WAL 条目都可以被安全的丢弃。
|
||||
|
||||
|
||||
## 创建一个 ZooKeeper Ensemble
|
||||
@@ -350,7 +350,7 @@ zk-0 0/1 Terminating 0 11m
|
||||
zk-0 0/1 Terminating 0 11m
|
||||
```
|
||||
|
||||
重新应用 `zookeeper.yaml` 中的代码清单。
|
||||
重新应用 `zookeeper.yaml` 中的代码清单。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/docs/tutorials/stateful-application/zookeeper.yaml
|
||||
@@ -897,7 +897,7 @@ ZooKeeper 需要一个服务的 quorum 来成功的提交数据变动。对于
|
||||
|
||||
```shell
|
||||
for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done
|
||||
```
|
||||
```
|
||||
|
||||
|
||||
`zk` StatefulSe 中所有的 Pods 都被部署在不同的节点。
|
||||
@@ -919,13 +919,13 @@ kubernetes-minion-group-2g2d
|
||||
matchExpressions:
|
||||
- key: "app"
|
||||
operator: In
|
||||
values:
|
||||
values:
|
||||
- zk-headless
|
||||
topologyKey: "kubernetes.io/hostname"
|
||||
```
|
||||
|
||||
|
||||
`requiredDuringSchedulingRequiredDuringExecution` 告诉 Kubernetes 调度器,在以 `topologyKey` 指定的域中,绝对不要把 `zk-headless` 的两个 Pods 调度到相同的节点。`topologyKey`
|
||||
`requiredDuringSchedulingRequiredDuringExecution` 告诉 Kubernetes 调度器,在以 `topologyKey` 指定的域中,绝对不要把 `zk-headless` 的两个 Pods 调度到相同的节点。`topologyKey`
|
||||
`kubernetes.io/hostname` 表示这个域是一个单独的节点。使用不同的 rules、labels 和 selectors,你能够通过这种技术把你的 ensemble 在物理、网络和电力故障域之间分布。
|
||||
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ spec:
|
||||
app: zk
|
||||
annotations:
|
||||
pod.alpha.kubernetes.io/initialized: "true"
|
||||
|
||||
|
||||
spec:
|
||||
affinity:
|
||||
podAntiAffinity:
|
||||
@@ -60,7 +60,7 @@ spec:
|
||||
matchExpressions:
|
||||
- key: "app"
|
||||
operator: In
|
||||
values:
|
||||
values:
|
||||
- zk-headless
|
||||
topologyKey: "kubernetes.io/hostname"
|
||||
containers:
|
||||
|
||||
Reference in New Issue
Block a user