上一部分我们分享到，Statefulset 部署应用，我们需要完成这些资源的创建：
- 制作应用程序和镜像
- 编写 Service
- 编写 Statefulset 指定 pod 模板及挂载
我们已经完成前面 2 部分，若还有疑问的可以看上上一部分的文章
[图片上传失败...(image-59c8ea-1691076102651)]
编写 Statefulset 清单
现在可以来专注的编写 Statefulset 资源了
编写 Statefulset 资源其实也比较简单，注意三大部分：
- Statefulset 自身的基本信息
- 指定好 serviceName 及 pod 的模板，且配置好挂载路径
- 指定好持久化卷声明的模板
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 的情况
[图片上传失败...(image-a5326d-1691076102651)]
我们可以查看到 sta-kubia-1 是在 sta-kubia-0 完全启动好，状态变成 Running 状态的时候才开始创建容器的
这是 statefulset 自身的机制，会去一个一个的创建 pod，创建 pod 后会准确的确认该 pod 运行 ok，才会进行创建下一个
这样也是保证安全性的一个设计
任意查看一个 pod 的详情
kubectl describe po sta-kubia-0
[图片上传失败...(image-3866c3-1691076102651)]
可以看到该 pod 会正确的对应上一个卷的声明，且索引和自己 pod 的索引一致
查看 持久化卷声明 pvc 和 查看 持久化卷 pv
kubectl get pvc
kubectl get pv
[图片上传失败...(image-88f542-1691076102651)]
我们可以看到 查看 持久化卷声明 pvc 和 查看 持久化卷 pv，总共分别有 2 个，且互相正确对应上的
如何与我们的 pod 进行通信
之前我们知道，我们是通过 Service 与 pod 进行通信，客户端只需要访问 节点的地址和 Service 的端口就可以了****（前提是我们暴露了 Service 的端口）
还有一种方式就是进入到其中一个 pod 的内部，去访问集群中 Service 的地址和端口
xdm 还记得其实我们还可以使用一种简单的方式，那就是访问通过 API 服务器的方式来访问我们的 pod 元数据，不记得细节的 xdm 可以看看我之前分享的文章 【k8s 系列】k8s 学习二十四，如何访问 pod 元数据
访问 k8s 的 API Server
- 直接运行代理
kubectl proxy
[图片上传失败...(image-7b695b-1691076102651)]
我们可以看到咱开启的代理是通过 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/
[图片上传失败...(image-9dad30-1691076102651)]
此处我们 POST 请求 sta-kubia-0 ，并带上数据 helloworld sta-kubia-0 字符串，请求成功，http 服务器会给我们返回写入成功的内容
GET 请求 pod
curl localhost:8001/api/v1/namespaces/default/pods/sta-kubia-0/proxy/
[图片上传失败...(image-45572f-1691076102651)]
GET 请求数据，会将指定文件中的内容打印出来
请千万记住结尾是 proxy/ 而不是 proxy ，否则你是会收到一个空白回应的， k8s 自身也是通过 url 拼接的方式来组装请求地址的
我们可以知道这个 url 是这样来组装的：
地址:端口/api版本/命名空间/pod名称/proxy
[图片上传失败...(image-cef78c-1691076102651)]
如上我们看到，GET 请求和 POST 请求都被正常处理了，那么我们来用图解的方式，看看我们的 curl 请求是怎样到达实际的 ApiServer 的
我们先来看看 ApiServer 的地址和我们访问的 pod 的地址：
ApiServer 的地址
[图片上传失败...(image-5a0cfd-1691076102651)]
sta-kubia-0 地址
[图片上传失败...(image-4f0cb9-1691076102651)]
从 curl 请求到 pod sta-kubia-0 的请求过程如下：
[图片上传失败...(image-9bb061-1691076102651)]
-
从最初发出 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 的相应结果了
今天就到这里，学习所得，若有偏差，还请斧正
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
[图片上传失败...(image-ff267-1691076102651)]
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是阿兵云原生，欢迎点赞关注收藏，下次见~
网友评论