标签：原来 tcp 转发 replicate 有关 机制 特定 cluster tor
该篇介绍 statefulset 的特点,我们通过实践部分验证 statefulset 的特点 .
实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，就被称为“有状态应用”（Stateful Application）,例如 : web 应用和数据库，比如我们可以用;相反,没有与外界有关系的应用,例如一个计算模块(输入一个值经过计算返回一个结果的模块应用)，比如一个推送模块 , StatefulSet 和 Deployment 可以说对应着有状态应用和无状态应用 ，也可以说 StatefulSet 是一种特殊的 Deployment。
k8s 这个工具是能够支持有状态应用的部署的, 得益于“控制器模式”的设计思想，Kubernetes 项目很早就在 Deployment 的基础上，扩展出了对“有状态应用”的初步支持。这个编排功能，就是：StatefulSet。 StatefulSet 的设计其实非常容易理解。它把真实世界里的应用状态，抽象为了两种情况：
拓扑状态。这种情况意味着，应用的多个实例之间不是完全对等的关系。这些应用实例，必须按照某些顺序启动，比如应用的主节点 A 要先于从节点 B 启动。而如果你把 A 和 B 两个 Pod 删除掉，它们再次被创建出来时也必须严格按照这个顺序才行。并且，新创建出来的 Pod，必须和原来 Pod 的网络标识一样，这样原先的访问者才能使用同样的方法，访问到这个新 Pod。(操作的时候有顺序)
存储状态。这种情况意味着，应用的多个实例分别绑定了不同的存储数据。对于这些应用实例来说，Pod A 第一次读取到的数据，和隔了十分钟之后再次读取到的数据，应该是同一份，哪怕在此期间 Pod A 被重新创建过。这种情况最典型的例子，就是一个数据库应用的多个存储实例。(依赖于某个特定的外部条件)
我们细读上面这两个特点，可不可以用两种场景来表述呢？
example.a.com , B的是 example.b.com , 当某些情况下，A 和 B 都异常退出后 ,k8s 会重新为 A B分配 node ,再次启动 pod , 那么此时我访问 example.a.com ，必须访问的还是 A , 访问 example.b.com 还是访问的 。所以，StatefulSet 的核心功能，就是通过某种方式记录这些状态，然后在 Pod 被重新创建时，能够为新 Pod 恢复这些状态。
以下描述来自课程,非原创
我在和你一起讨论 Kubernetes 架构的时候就曾介绍过，Service 是 Kubernetes 项目中用来将一组 Pod 暴露给外界访问的一种机制。比如，一个 Deployment 有 3 个 Pod，那么我就可以定义一个 Service。然后，用户只要能访问到这个 Service，它就能访问到某个具体的 Pod。
那么，这个 Service 又是如何被访问的呢？
第一种方式，是以 Service 的 VIP（Virtual IP，即：虚拟 IP）方式。比如：当我访问 10.0.23.1 这个 Service 的 IP 地址时，10.0.23.1 其实就是一个 VIP，它会把请求转发到该 Service 所代理的某一个 Pod 上。这里的具体原理，我会在后续的 Service 章节中进行详细介绍。
第二种方式，就是以 Service 的 DNS 方式。比如：这时候，只要我访问“my-svc.my-namespace.svc.cluster.local”这条 DNS 记录，就可以访问到名叫 my-svc 的 Service 所代理的某一个 Pod。
而在第二种 Service DNS 的方式下，具体还可以分为两种处理方法：
第一种处理方法，是 Normal Service。这种情况下，你访问“my-svc.my-namespace.svc.cluster.local”解析到的，正是 my-svc 这个 Service 的 VIP，后面的流程就跟 VIP 方式一致了。
第二种处理方法，正是 Headless Service。这种情况下，你访问“my-svc.my-namespace.svc.cluster.local”解析到的，直接就是 my-svc 代理的某一个 Pod 的 IP 地址。可以看到，这里的区别在于，Headless Service 不需要分配一个 VIP，而是可以直接以 DNS 记录的方式解析出被代理 Pod 的 IP 地址。
下面是一个标准的 Headless Service 对应的 YAML 文件：
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None ## 看这个
selector:
app: nginx
可以看到，所谓的 Headless Service，其实仍是一个标准 Service 的 YAML 文件。只不过，它的 clusterIP 字段的值是：None，即：这个 Service，没有一个 VIP 作为“头”。这也就是 Headless 的含义。所以，这个 Service 被创建后并不会被分配一个 VIP，而是会以 DNS 记录的方式暴露出它所代理的 Pod。 当你按照这样的方式创建了一个 Headless Service 之后，它所代理的所有 Pod 的 IP 地址，都会被绑定一个这样格式的 DNS 记录，如下所示：
<pod-name>.<svc-name>.<namespace>.svc.cluster.local
这个 DNS 记录，正是 Kubernetes 项目为 Pod 分配的唯一的“可解析身份”（Resolvable Identity）。有了这个“可解析身份”，只要你知道了一个 Pod 的名字，以及它对应的 Service 的名字，你就可以非常确定地通过这条 DNS 记录访问到 Pod 的 IP 地址。
Headless Service 的 yaml 文件
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
StatefulSet 的 yaml 文件
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx"
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.9.1
ports:
- containerPort: 80
name: web
然后我们通过命令运行这两个 yaml
$ kubectl create -f svc.yaml $ kubectl get service nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx ClusterIP None <none> 80/TCP 10s $ kubectl create -f statefulset.yaml $ kubectl get statefulset web NAME DESIRED CURRENT AGE web 2 1 19s [root@k8s-master ~]# kubectl get pod NAME READY STATUS RESTARTS AGE lifecycle-demo 1/1 Running 4 18d nginx-deployment-5d59d67564-bdn4d 1/1 Running 0 3h54m nginx-deployment-5d59d67564-cj9qh 1/1 Running 0 3h54m test-projected-volume 1/1 Running 3 17d web-0 1/1 Running 0 3h54m web-1 1/1 Running 0 3h54m
我们可以看到 web-0和web-1是 statefulset 生成的，可以看到默认生成的pod 命令上有编号，该编号就是启动顺序相关的。
$ kubectl exec web-0 -- sh -c ‘hostname‘ web-0 $ kubectl exec web-1 -- sh -c ‘hostname‘ web-1
上面的命令的可以查询到这两个pod的主机名。下面我们需要验证是否可以通过 DNS 找到对应的 pod .
我们通过创建一个新的 pod ，然后在 pod 里查询 web 的信息。
$ kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh
通过这条命令，我们启动了一个一次性的 Pod ，对应的镜像是 busybox:1.28.4，因为–rm 意味着 Pod 退出后就会被删除掉。然后，在这个 Pod 的容器里面，我们尝试用 nslookup 命令，解析一下 Pod 对应的 Headless Service：
$ nslookup web-0.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local Name: web-0.nginx Address 1: 10.244.1.7 $ nslookup web-1.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local Name: web-1.nginx Address 1: 10.244.2.7
然后我们在另外的会话中，我们先删除我们刚创建的pod,不出意外的话,新的 pod 将会创建 ,那么我们重新执行上面的步骤,在新的pod里查看 DNS 信息,假如依旧是保持原有的 DNS 信息,那么就成功验证了 statefulset 第二条的 "存储状态" 的特点.
$ kubectl delete pod -l app=nginx pod "web-0" deleted pod "web-1" deleted
如果手速够快,我们还可以看到 pod 的创建过程, web-0 总是优先于 web-1 ,删除的话则是相反的顺序 .
$ kubectl get pod -w -l app=nginx NAME READY STATUS RESTARTS AGE web-0 0/1 ContainerCreating 0 0s NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 2s web-1 0/1 Pending 0 0s web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 32s
StatefulSet 这个控制器的主要作用之一，就是使用 Pod 模板创建 Pod 的时候，对它们进行编号，并且按照编号顺序逐一完成创建工作。而当 StatefulSet 的“控制循环”发现 Pod 的“实际状态”与“期望状态”不一致，需要新建或者删除 Pod 进行“调谐”的时候，它会严格按照这些 Pod 编号的顺序，逐一完成这些操作。
深入剖析Kubernetes课程标签：原来 tcp 转发 replicate 有关 机制 特定 cluster tor
原文地址：https://www.cnblogs.com/Benjious/p/14852772.html
