部署环境从docker swarm迁移到k8s后kie-server的发布方式变化

书接swarm

https://cloud.tencent.com/developer/news/475316

swarm的集群部署非常简单,但领导说docker和 docker swarm都不想用

换k8s
ok
哦另外, k8s的CRI运行时 也不用docker 而是用containerd
完成.

但发现一个问题 ,k8s没有暂停pod的概念. 同时containerd没有暂停容器的概念, (docker有这个概念)

kubectl rollcout restart pod whoami-deployment-56bdd9544f-m28c8

这个命令并不被支持, 估计是docker做CRI时支持吧.

这样就问题大了, 因为我们用的是不是典型的容器开发方式.
而是利用容器,在容器上面做追加的发布.需要drain某个节点来发发布的请求.保证同时只有一个node接收请求.

在containerd里reboot 会直接容器消失再出现一个新的.
ok进行调研

先对现状分析,对于docker swarm环境, 有连着wb的ks. 把容器内整个wildfly文件夹copy出来.

https://blog.csdn.net/weixin_45843419/article/details/119978883

docker cp 2aa7d757d24d:/opt/jboss/wildfly/ /home/xxx/before/

然后发布一个简单的dmn项目, 之后再次把整个wildfly copy出来

docker cp 2aa7d757d24d:/opt/jboss/wildfly/ /home/xxx/after/

把文件夹从linux服务器下载到本地很麻烦, 先zip

http://c.biancheng.net/view/781.html

zip -r before.zip before
zip -r after.zip after

然后用对比工具 beyondcompare 对比,
发现前后只有一个文件有差别

http://www.hnwypx.com/zhishi/290464.html

这里是所有有效信息都是maven管理的jar的信息
故真正的文件应该再本地maven库里.
不知道在哪.
直接搜.m2文件夹 (这个是真方便, windows的话得安装everything) (我唯一愿意夸linux的地方)

http://c.biancheng.net/view/779.html

find / -name .m2

找到了.m2在哪里.

里面确实有ooonew的jar.
验证了假设,找到了结论, 即 kb发布的时候会ks会把jar放到自己的本地库, 并在kie-server-[hostname].xml里加一段话, 里面的containers即他每次重启后要发布的container,具体jar在本地库里找.

那么, 在k8s里发布一个没有wb的ks

apiVersion: v1
kind: Namespace
metadata:
  name: kie-server-alone

---

apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: kie-server-alone
  name: kie-server-alone
  namespace: kie-server-alone
spec:
  type: NodePort
  ports:
    - port: 8080
      targetPort: 8080
      nodePort: 30002
  selector:
    k8s-app: kie-server-alone

---

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: kie-server-alone
  name: kie-server-alone
  namespace: kie-server-alone
spec:
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: kie-server-alone
  template:
    metadata:
      labels:
        k8s-app: kie-server-alone
    spec:
      nodeName: ltwwapp01
       
      containers:
        - name: kie-server-alone
          image: quay.io/kiegroup/kie-server-showcase:latest
          imagePullPolicy: Always
          ports:
            - containerPort: 8080
              protocol: TCP
              

发现jar拉不下来,
给containerd加镜像源
配置containerd的镜像源 /etc/containerd/config.toml
原来:

之后

[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
 		[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
          endpoint = ["https://cekcu3pt.mirror.aliyuncs.com"]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."k8s.gcr.io"]
          endpoint = ["http://registry.aliyuncs.com/google_containers"]

然后重启containerd
systemctl restart containerd

https://it.cha138.com/android/show-57256.html

之后就拉成功了

crictl pull quay.io/kiegroup/kie-server-showcase:latest (绝大多数的docker命令都可以像这样在containerd里用)

pod已然建成, 现状就在k8s+containerd环境下验证上面的结论.
把.m2文件夹的zip放到服务器上, 然后copy到pod里

https://blog.csdn.net/weixin_45969972/article/details/121424601

kubectl cp ./repository.zip kie-server-alone/kie-server-alone-7898df8b45-c9lpt:/opt/jboss/.m2/

然后需要进到pod里unzip

http://c.biancheng.net/view/782.html

unzip repository.zip

然后修改pod里的那个xml文件

vi kie-server-kie-server-alone-7898df8b45-c9lpt.xml

ok关键来了. 我们知道reboot会销毁pod新建一个, 大概是k8s的pod守护进程发现pod出问题了然后就用image重新开一个pod. 集群都会有这个机制, swarm里重启也会新出来一个容器.
所以试下只是重启wildfly是否ok.

https://www.mastertheboss.com/jbossas/jboss-configuration/how-to-start-stop-and-restart-wildfly/

discnnect 是 quit
直接说结论, ok

至此,问题完全解决, 而且相比于之前的发布方式, 这个会更规范.
下一步是要把.m2文件夹做成一个只读的共享的volume, 然后xml也可以自动修改.
非常好