Statefulset实战 2

上一部分我们分享到，Statefulset 部署应用，我们需要完成这些资源的创建：

• 制作应用程序和镜像
• 编写 Service
• 编写 Statefulset 指定 pod 模板及挂载

我们已经完成前面 2 部分，若还有疑问的可以看上上一部分的文章

编写 Statefulset 清单

现在可以来专注的编写 Statefulset 资源了

编写 Statefulset 资源其实也比较简单，注意三大部分：

1. Statefulset 自身的基本信息
2. 指定好 serviceName 及 pod 的模板，且配置好挂载路径
3. 指定好持久化卷声明的模板

statefulset.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: sta-kubia
spec:
  serviceName: sta-kubia
  replicas: 2
  selector:
    matchLabels:
      app: sta-kubia
  template:
    metadata:
      labels:
        app: sta-kubia
    spec:
      containers:
      - name: sta-kubia
        image: xiaomotong888/sta-kubia
        ports:
        - name: http
          containerPort: 8080
        volumeMounts:
        - name: data
          mountPath: /var/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      resources:
        requests:
          storage: 1Mi
      accessModes:
      - ReadWriteOnce

• 设置 statefulset 自身的名称为 sta-kubia，设置 2 个副本数，管理的 pod 标签为 sta-kubia
• 设置容器模板，镜像为 xiaomotong888/sta-kubia，容器端口为 8080 ，挂载路径为 /var/data
• 设置持久化卷声明模板，请求的资源内存为 1M，访问模式为 ReadWriteOnce

还是老规矩，通过 kubectl create -f statefulset.yaml 的方式部署 statefulset ，我们来分别查看一下 pod，持久化卷声明 pvc ，持久化卷 pv

查看 pod 状态

通过指令 kubectl get po 查看 pod 的情况

我们可以查看到 sta-kubia-1 是在 sta-kubia-0 完全启动好，状态变成 Running 状态的时候才开始创建容器的

这是 statefulset 自身的机制，会去一个一个的创建 pod，创建 pod 后会准确的确认该 pod 运行 ok，才会进行创建下一个

这样也是保证安全性的一个设计

任意查看一个 pod 的详情

kubectl describe po sta-kubia-0

可以看到该 pod 会正确的对应上一个卷的声明，且索引和自己 pod 的索引一致

查看 持久化卷声明 pvc 和 查看 持久化卷 pv

kubectl get pvc
kubectl get pv

我们可以看到 查看 持久化卷声明 pvc 和 查看 持久化卷 pv，总共分别有 2 个，且互相正确对应上的

如何与我们的 pod 进行通信

之前我们知道，我们是通过 Service 与 pod 进行通信，客户端只需要访问 节点的地址和 Service 的端口就可以了****（前提是我们暴露了 Service 的端口）

还有一种方式就是进入到其中一个 pod 的内部，去访问集群中 Service 的地址和端口

xdm 还记得其实我们还可以使用一种简单的方式，那就是访问通过 API 服务器的方式来访问我们的 pod 元数据，不记得细节的 xdm 可以看看我之前分享的文章 【k8s 系列】k8s 学习二十四，如何访问 pod 元数据

访问 k8s 的 API Server

• 直接运行代理

kubectl proxy

我们可以看到咱开启的代理是通过 8001 端口与 Api Server 进行交互的

• 访问具体的 pod 接口

这个时候，我们就可以通过访问这样的 url 通过代理来请求 ApiServer 了，这算是一个正向代理

还记得，我们镜像中写的应用吗，应用是一个 http 服务器，提供 GET 和 POST 请求？

• GET 是用来读取指定文件的内容
• POST 请求是用来将请求内容写入到指定文件中

由于 pod 创建出来，指定的文件还没有，我们可以先使用 POST 请求我们的 pod，然后再使用 GET 请求 pod

POST 请求 pod

curl  -X POST -d 'helloworld sta-kubia-0' localhost:8001/api/v1/namespaces/default/pods/sta-kubia-0/proxy/

此处我们 POST 请求 sta-kubia-0 ，并带上数据 helloworld sta-kubia-0 字符串，请求成功，http 服务器会给我们返回写入成功的内容

GET 请求 pod

curl localhost:8001/api/v1/namespaces/default/pods/sta-kubia-0/proxy/

GET 请求数据，会将指定文件中的内容打印出来

请千万记住结尾是 proxy/ 而不是 proxy ，否则你是会收到一个空白回应的， k8s 自身也是通过 url 拼接的方式来组装请求地址的

我们可以知道这个 url 是这样来组装的：

地址:端口/api版本/命名空间/pod名称/proxy

如上我们看到，GET 请求和 POST 请求都被正常处理了，那么我们来用图解的方式，看看我们的 curl 请求是怎样到达实际的 ApiServer 的

我们先来看看 ApiServer 的地址和我们访问的 pod 的地址：

ApiServer 的地址

sta-kubia-0 地址

image-20220213165754717

从 curl 请求到 pod sta-kubia-0 的请求过程如下：

• 从最初发出 curl 请求之后，会经过 kubectl proxy 进行代理，kubectl proxy 会去代理到 8001 端口继续向下访问
• kubectl 又会将请求代理到 ApiServer 上，此时请求的是 Apiserver 的地址:8443 端口，看到这里，整个请求实际上是经过了 2 个代理
• ApiServer 收到请求后，会去请求实际的 pod sta-kubia-0 地址（172.17.0.1）和端口（8080）
• 最终 pod 中的容器响应后，数据怎么来，请求就顺利请求路径一层一层的相应，最终，我们在界面上就看到了 pod sta-kubia 的相应结果了