k8s业务迁移与服务部署实践

崔亮的博客

已于 2023-08-09 10:44:30 修改

阅读量3k

点赞数 4

文章标签： kubernetes docker 运维

于 2023-03-11 11:24:40 首次发布

本文链接：https://blog.csdn.net/qq_33816243/article/details/129461040

版权

K8s运行业务的优势

部署上线业务流程

情景模拟：

业务部署上线是每个运维都需要面对的问题，接下来分别从传统运维和k8s运维角度，梳理操作流程：
传统运维：

安装操作系统
初始化系统配置(安全策略、时间同步、yum源……)
安装配置java环境
打jar包并部署服务
Systemctl添加自定义服务或supervisor进程守护

k8s运维：

安装操作系统
初始化系统配置(安全策略、时间同步、yum源……)
部署k8s集群（多台机器）
封装docker镜像
创建资源清单，完成项目部署

分析：
两者都需要安装操作系统，初始化系统。不同之处在于传统运维只需要单机配置环境部署服务即可。而k8s运维则需要部署搭建一个k8s集群，然后封装docker镜像，创建k8s的资源清单，才能完成项目的部署。相比较而言，k8s方式部署业务，前期从时间成本，资源使用考虑都是高于传统方式部署业务的。

故障处理转移流程

业务上线初期，通常访问量很小，大多数情况都是单节点运行业务，那么如果出现硬件故障，例如磁盘坏盘，导致系统死机，用户无法访问业务服务。那么我们应该如何处理呢？
传统运维：

安装操作系统
初始化系统配置
安装配置java环境
打jar包并部署服务
Systemctl添加自定义服务或supervisor进程守护
修改DNS解析，指向新的服务器地址

k8s运维：

K8s检测到节点故障后，自动进行故障转移，将故障机器上的服务自动迁移至其他正常机器上运行

分析：
如果是传统运维的话，服务器硬件故障可能一时半会不能修复，为了尽可能缩短业务中断时间，降低经济损失，只能快速再起一台服务器，再重复执行一遍业务上线的流程，最后修改DNS解析，或者修改公网ip，把流量引入新的机器中，恢复故障。
而如果是k8s运维的话，因为前期在部署上线时，已经搭建了k8s集群，当集群内有一个节点故障后，k8s发现节点宕机后，会将异常节点上的pod都变为unknow状态，并自动在其他机器上开启指定数量的副本pod。整个故障迁移过程中，运维人员不需要参与，用户也不会感知到服务异常，更不会对业务造成中断。

业务扩容流程

随着业务的不断发展，为了提高服务性能、避免单点故障，需要进行由单体服务向集群转变的操作。
传统运维：

安装操作系统
初始化系统配置
安装配置java环境
打jar包并部署服务
Systemctl添加自定义服务或supervisor进程守护
部署nginx、lvs或者haproxy等服务，实现负载均衡

k8s运维：

修改资源清单文件，将副本数从1改为N，由service自动进行负载均衡。

分析：
如果是传统运维，那就再执行几遍业务上线流程，如果机器过多，可以使用ansible等批量工具编写playbook执行，最后部署一个lvs 或者nginx 或者haproxy等反向代理软件，实现负载均衡，但过程中集群机器尽可能使用一样的操作系统和环境。
而如果是一个k8s运维，那么他需要做的操作，只是将副本数从1改为N即可，不需要关注如何实现负载均衡，因为k8s通过service已经实现了负载均衡。而且，面对一些瞬时暴增的流量，k8s可以通过HPA自动扩缩容，非常适合于一些流量波动大，机器资源吃紧，服务数量多的业务场景。

版本更新发布流程

传统运维：

拉取最新代码并打jar包
修改负载均衡配置，剔除将要更新的机器
停止服务，替换jar包文件
启动服务，访问测试
修改负载均衡配置，恢复更新完成的机器
重复上述步骤，直至全部机器完成

k8s运维：

拉取最新代码，封装docker镜像，推送至镜像仓库
修改资源清单文件的镜像配置，执行apply操作，完成滚动更新。

分析：
以java项目为例，当打完jar包后，传统运维的话，因为整个业务是集群方式运行，所以首先就从负载均衡服务中，剔除那个将要更新的机器，防止流量进入。然后逐个更新，期间不停修改负载均衡服务后端地址列表。
而如果是k8s运维的话，只需要将最新jar包打包成一个新版本的业务docker镜像，然后修改资源清单文件的镜像版本即可，使用deployment控制器会自动完成滚动更新，实现零停机发布。

运维成本分析对比

	传统运维	K8s运维
部署上线	配置环境，打包部署服务配置服务管理脚本	搭建集群、封装镜像、创建资源
健康检查	编写shell脚本或使用守护进程工具	k8s提供就绪、存活探针，支持exec执行命令、HTTP状态码、TCP端口探测
故障转移	新机器部署服务，修改DNS解析指向新机器	K8s内部自动实现故障转移
集群扩容	新机器部署服务，部署负载均衡服务，配置后端地址	修改k8spod资源副本数，service自动实现负载均衡
版本更新	修改负载均衡配置，逐个滚动停止服务，替换jar包，启动服务	更新docker镜像并上传，修改k8spod资源镜像信息，k8s自动实现滚动更新

以上五个运维场景相信也是大家在日常工作中会经常用到的，两种运维方式相比较而言，k8s只是在项目初期需要投入更多的时间和精力，但是当业务稳定运行后，k8s可以大大的简化运维的工作内容，是一种一劳永逸，更加优雅的运维方式。

应用迁移基本流程

将应用封装进容器

将应用迁移到k8s，首先第一步就是要编写dockerfile，将原本在Linux服务器上运行的服务打包到容器中运行。我们回想传统方式部署业务的整体流程，我们一般是从最底层开始选择合适版本的操作系统，配置一系列的初始化操作，配置安全策略等。然后再部署运行环境，配置环境变量，最后上传项目代码到服务器中，配置启动脚本或者守护进程。在整个过程中，我们所有的操作分为了三个层面，最底层的操作系统，中间层的运行环境，上层的应用服务。

而编写dockerfile时，base镜像的选择也是从这几个层面考虑，如果环境层的镜像无法满足需求，就从系统层开始编写dockerfile。基础镜像可以从以下几个网站获取到
https://hub.docker.com/
https://quay.io/
http://gcr.io
通过下面几个常见案例说明：
案例1：

我们也已经明确知道了这个项目运行的系统和环境，也就是前面提到的三层中的系统层和环境层是已经确定的，使用docker镜像仓库中提供的基础镜像就可以满足我们的要求，我们只需要在应用层上将自己的代码加入镜像即可。dockerfile基本内容参考文档：https://www.cuiliangblog.cn/detail/section/26458557

FROM openjdk:19-jdk-alpine3.16 # 使用alpine3.16操作系统，java19运行环境为基础镜像
ADD demo.jar /opt/app.jar      # 复制项目jar包文件到容器/opt/目录下
EXPOSE 8888                    # 声明容器暴露的端口
WORKDIR /opt                   # 指定容器工作目录
CMD ["java","-jar","app.jar"]  # 指定启动命令为java –jar /app.jar

案例2：

在这个场景中，我们需要两个环境，一个是编译打包环境需要nodejs，一个是运行环境需要nginx。此时我们就需要用到多阶段构建，将打包阶段中的文件拷贝到后边的运行阶段中，实现编译环境和运行环境分离，dockerfile多阶段构建镜像参考文档：https://www.cuiliangblog.cn/detail/section/31400933。我们的dockerfile就这样写

FROM node:16.15.0 AS build        # 使用node 16.15运行环境 用于打包项目,并将第一阶段命名为build
COPY . /vue                       # 复制项目代码到/vue目录下
WORKDIR /vue                      # 设置工作目录为/vue
RUN npm install && npm run build  # 安装项目依赖并打包项目

FROM nginx:1.20.1            							 # 使用nginx 1.20运行环境为基础镜像
COPY --from=build /vue/dist /opt/vue/dist  # 拷贝build阶段生成的打包文件dist到容器目录下
EXPOSE 80                                  # 声明容器暴露的端口
COPY vue.conf /etc/nginx/nginx.d/vue.conf  # 拷贝nginx配置文件到容器nginx配置文件目录下
CMD ["nginx", "-g","daemon off;"]          # 指定启动命令

案例3：

前两个案例中，我们都是使用默认的系统和环境，就可以实现我们的需求，我们只需要自定义应用层的东西即可。但如果碰到这样的需求，也就是说直接使用Python这个环境层的镜像无法满足要求了，因为他不支持yum命令安装sshd服务，直接拷贝ssh的二进制文件编译安装也非常麻烦，那我们就只能使用最基础的系统层镜像，然后自定义Python环境，完成镜像封装。

FROM centos:centos8 # 选取centos8为基础镜像
RUN dnf install openssh-server passwd python38 python38-devel -y # 安装相关软件包
RUN /bin/echo "123.com" | passwd --stdin root # 设置ssh密码
RUN /bin/sed -i 's/.session.required.pam_loginuid.so./session optional pam_loginuid.so/g' /etc/pam.d/sshd && /bin/sed -i 's/UsePAM yes/UsePAM no/g' /etc/ssh/sshd_config && /bin/sed -i "s/#UsePrivilegeSeparation.*/UsePrivilegeSeparation no/g" /etc/ssh/sshd_config # 修改sshd配置文件
RUN ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key && ssh-keygen -t rsa -f /etc/ssh/ssh_host_ecdsa_key && ssh-keygen -t rsa -f /etc/ssh/ssh_host_ed25519_key # 创建密钥
RUN echo -e "#! /bin/bash\n/usr/sbin/sshd -D" > /run.sh # 创建sshd服务启动脚本
ADD . /app # 拷贝代码到容器目录
RUN pip3.8 install -r /app/requirements.txt # 安装依赖
EXPOSE 22 # 声明容器暴露的端口
CMD ["/usr/sbin/sshd","-D"] # 指定启动命令

dockerfile构建镜像经验

减少镜像的层数，尽量把一些功能上面统一的命令合到一起来做；
注意清理镜像构建的中间产物，比如一些安装包在装完之后就把它删掉；
注意优化网络请求，使用yum源的时候，用一些网络比较好的源站点，可节约时间，减少失败率；
尽量去使用缓存构建，尽量把一些不变的东西或者变动比较少的东西放在前面。例如业务更新，打包新版本镜像时，只有代码发生变化，其他内容不变。此时可以把拷贝代码放最后，前面的构建阶段直接使用缓存即可。

将容器放入Pod中

当我们把应用封装成docker镜像后，接下来就是在kubernetes中启动镜像运行容器。因为Pod是Kubernetes管理的最小单元，Kubernetes不直接管理容器，而是管理Pod，Pod里面包含一个或多个容器。需要考虑是一个Pod中放置多个容器，还是一个Pod中放置一个容器。在一个pod中所有container共享，PID、Network、IPC

在有些业务场景中，例如一个web服务，对应的资源文件需要从远端实时监听更新，就需要使用边车 (sidercar)模式，一个pod中包含一个web容器一个file容器，通过共享存储方式实现。又比如一个用户的微服务包含：User API、User Control、User Data等三个模块，彼此之间紧耦合，对外只需要通过User API，这样类型的应用就可以放置在一个Pod中。
Pod资源清单建议

建议开发项目时，提供healthy健康检查接口，便于检测服务是否正常。
建议运维配置LivenessProbe存活检测探针，防止服务假死。
建议配置resources，避免程序出现异常，并占用大量的系统资源，从而会影响节点上其他的Pod。

使用Controller管理Pod

单一Pod如果出现故障，就会影响业务连续性，所以需要多副本，就像我们给一个Web应用做集群是一样的。Kubernetes提供了不同的Controller，需要根据应用的实际情况选择使用Deployment、DaemonSet、StatefulSet、Job、CronJob等，只需要在Pod的YAML模板上封装上对应的配置即可。

kubernetes提供的控制器如下：

Deployment：封装了Pod的副本管理、部署更新、回滚、扩容、缩容等。
DaemonSet：保证所有的Node上有且只有一个Pod在运行。
StatefulSet：有状态的应用，为Pod提供唯一的标识，它可以保证部署和scale的顺序。
Job：使用Kubernetes运行单一任务。
CronJob：使用Kubernetes运行定时任务。

使用Service访问Pod

由于每次pod重启都会随机生成新的ip，且使用控制器运行多副本pod时，该访问哪个具体的IP呢？

在传统的方式运行服务时，通常会提供一个VIP和service后端地址池。其中VIP负责对外暴露服务，监听请求。后端地址池复制监听后端服务的变化，随时更新地址池，并通过控制器实现轮循哈希等负载均衡方式。
在kubernetes中，service便是这样的存在，service只是一个抽象的概念，他的工作主要由endpoint controller和kube-proxy搭配完成。
endpoints controller 是负责生成和维护所有 endpoints 对象的控制器，监听 service 和对应 pod 的变化，更新对应 service 的 endpoints 对象。当用户创建 service 后 endpoints controller 会监听 pod 的状态，当 pod 处于 running 且准备就绪时，endpoints controller 会将 pod ip记录到 endpoints 对象中，因此，service 的容器发现是通过 endpoints 来实现的。
而 kube-proxy 会监听 service 和 endpoints 的更新并调用其代理模块在主机上刷新路由转发规则。实际的路由转发都是由 kube-proxy 组件来实现的。
目前Service的负载均衡支持多种实现方式：User Space、iptable和ipvs。如果使用ipvs，当你创建Service的时候，kube-proxy会获取Service对应的Endpoint，调用LVS帮我们实现负载均衡的功能。

k8s同样也为我们提供了多种service使用：
ClusterIP(集群IP)：集群内的服务间通信。例如，应用程序的前端(front-end)和后端(back-end)组件之间的通信。
NodePort(节点端口)：k8s集群内部服务暴露给外部时访问，可以通过k8s节点ip+端口方式访问服务。
LoadBalancer（负载均衡器）：使用云厂商来托管您的 Kubernetes 集群时。由它接入外部客户端的请求并调度至集群节点相应的NodePort之上
ExternalName（外部名称）：在 Kubernetes 内创建服务来表示映射外部服务名称，例如在 Kubernetes 中使用公有云数据库时，可以创建一个ExternalName资源，后续更换云数据库地址时，更新ExternalName配置即可

使用Ingress提供外部访问

虽然用户可以通过service提供的nodeport方式或者loadbalancer方式访问k8s集群内部的服务，但是随着服务的增多，让普通用户通过ip+端口方式访问服务是不现实的。此时就需要通过不同的域名对应访问不同的服务，而这种全局的、为了代理不同后端 Service 而设置的负载均衡服务，就是 Kubernetes 里的 Ingress 服务。

Ingress同样也只是一个概念，它的具体的实现依赖控制器，Ingress控制器并不直接运行为kube-controller-manager的一部分，它是Kubernetes集群的一个重要附件，类似于CoreDNS，需要在集群上单独部署。Ingress控制器可以由任何具有反向代理（HTTP/HTTPS）功能的服务程序实现，如Nginx、Envoy、HAProxy、Vulcand和Traefik等。

使用ConfigMap管理配置文件

在DevOps的部署流水线中，其中有一个核心的理念就是代码和配置的分离，这样更容易实现流水线的编排。我们只需要使用一套代码，配合不同的配置文件，就可以实现灵活发布到测试环境、预发布环境、生产环境等。

kubernetes同样也为我们提供了配置与文件管理方案：

ConfigMap配置文件：可以从文件、文件夹等途径创建ConfigMap。然后再Pod中挂载使用配置文件，例如nginx配置。
secret私密文件：使用base64加密的文件，例如存储第三方镜像仓库凭证配置TLS 类型secret 用于记录证书秘钥等信息。

使用共享存储持久化存储数据

容器中的存储都是临时的，因此Pod重启的时候，内部的数据会发生丢失。实际应用中，我们有些应用是无状态，有些应用则需要保持状态数据，确保Pod重启之后能够读取到之前的状态数据，有些应用则作为集群提供服务。这三种服务归纳为无状态服务、有状态服务以及有状态的集群服务，其中后面两个存在数据保存与共享的需求，因此就要采用容器外的存储方案。
kubernetes拥有众多类型的用于适配专用存储系统的网络存储卷。这类存储卷包括传统的NAS或SAN设备（如NFS、iSCSI、fc）、分布式存储（如GlusterFS、RBD）、云端存储（如gcePersistentDisk、azureDisk、cinder和awsElasticBlockStore）以及建构在各类存储系统之上的抽象管理层（如flocker、portworxVolume和vsphereVolume）等。

资源清单部署服务案例实践

环境准备

ip	主机名	角色
192.168.10.100	tiaoban	harbor私有仓库+nfs服务器+es服务+kibana
192.168.10.10	k8s-master	k8s master节点
192.168.10.11	k8s-work1	k8s work节点
192.168.10.12	k8s-work2	k8s work节点

nfs部署文档：https://www.cuiliangblog.cn/detail/section/116191364
traefik部署文档：https://www.cuiliangblog.cn/detail/section/94793162
harbor部署文档：https://www.cuiliangblog.cn/detail/section/15189547
es+kibana部署文档：https://www.cuiliangblog.cn/detail/section/117075458

案例1(springboot)

思路分析

开发提供jar包：基础镜像直接使用open-jdk即可
部署到k8s：多副本管理，滚动更新：需要使用Deployment控制器；Pod多副本负载均衡：需要使用ClusterIP服务资源
用户通过域名访问：使用Ingress创建域名路由，流量转发到Service

构建docker镜像
我们将打包好的jar文件和dockerfile放在同一级目录下，执行docker build指令，即可完成镜像构建

[root@tiaoban springboot]# ls
demo  demo-v1.jar  demo-v2.jar  Dockerfile
[root@tiaoban springboot]# cat Dockerfile 
FROM openjdk:19-jdk-alpine3.16
ADD demo-v1.jar /opt/app.jar
EXPOSE 8888
WORKDIR /opt
CMD ["java","-jar","app.jar"]
# 打包镜像
[root@tiaoban springboot]# docker build -t springboot:v1 .
# 启动容器，访问测试
[root@k8s-master springboot]# docker run -d -p 8888:8888 springboot:v1
74a8bc2446d7f30195099c8f6f905481b2fdc6b585436e4b810849f1df50185d
[root@k8s-master springboot]# curl 127.0.0.1:8888
Hello SpringBoot Version:v1[root@k8s-master springboot]# 
[root@k8s-master springboot]# curl 127.0.0.1:8888/healthy
ok[root@k8s-master springboot]#

推送至harbor私有镜像仓库
构建好镜像测试无误后，接下来就可以推送到harbor私有镜像仓库中

[root@k8s-master springboot]# docker tag springboot:v1 192.168.10.100/demo/springboot:v1
[root@k8s-master springboot]# docker push 192.168.10.100/demo/springboot:v1

创建pod资源调试
推送完成后，接下来我们开始编写pod的资源清单文件，镜像地址填写harbor仓库的镜像地址

[root@k8s-master springboot]# cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: springboot
  labels:
    name: springboot
spec:
  containers:
  - name: springboot
    image: 192.168.10.100/demo/springboot:v1
    resources:
      limits:  # 资源使用最大值
        memory: "1Gi"
        cpu: "1"
      requests:
        memory: "128Mi"
        cpu: "100m" 
    ports:
      - containerPort: 8888
        name: web
    livenessProbe:
      httpGet: # http存活检测，返回状态码为200表示正常
        port: web
        path: /healthy
      initialDelaySeconds: 20 # 容器启动后20秒开始检测
    readinessProbe:
      tcpSocket:  # tcp就绪检测，只有当8888端口开始监听，才会有流量引入
        port: web
[root@k8s-master springboot]# kubectl apply -f pod.yaml 
pod/springboot created
[root@k8s-master springboot]# kubectl get pod -o wide
NAME                                               READY   STATUS    RESTARTS      AGE   IP           NODE        NOMINATED NODE   READINESS GATES
nfs-subdir-external-provisioner-7c8776699f-mkpxg   1/1     Running   4 (56m ago)   97m   10.244.2.5   k8s-work2   <none>           <none>
springboot                                         1/1     Running   0             46s   10.244.2.7   k8s-work2   <none>           <none>
# pod启动后，可以通过pod的IP+端口方式访问服务，验证测试是否正常启动
[root@k8s-master springboot]# curl 10.244.2.7:8888
Hello SpringBoot Version:v1

创建deployment资源
pod资源创建完成测试无误，接下来就是使用deployment控制器管理pod，让它以多副本方式运行

[root@k8s-master springboot]# kubectl delete -f pod.yaml 
pod "springboot" deleted
[root@k8s-master springboot]# cat deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: springboot
spec:
  replicas: 2 # 副本数
  selector:
    matchLabels:
      app: springboot
  template:
    metadata:
      labels:
        app: springboot
    spec:
      containers:
      - name: springboot
        image: 192.168.10.100/demo/springboot:v1
        resources:
          limits:
            memory: "1Gi"
            cpu: "1"
          requests:
            memory: "128Mi"
            cpu: "100m" 
        ports:
          - containerPort: 8888
            name: web
        livenessProbe:
          httpGet:
            port: web
            path: /healthy
          timeoutSeconds: 2       # 表示容器必须在2s内做出相应反馈给probe，否则视为探测失败
          periodSeconds: 30       # 探测周期，每30s探测一次
        readinessProbe:
          tcpSocket:
            port: web
          initialDelaySeconds: 10 # 容器启动后10s开始探测
[root@k8s-master springboot]# kubectl apply -f deployment.yaml 
deployment.apps/springboot created
[root@k8s-master springboot]# kubectl get pod -o wide
NAME                                               READY   STATUS    RESTARTS      AGE    IP           NODE        NOMINATED NODE   READINESS GATES
nfs-subdir-external-provisioner-7c8776699f-mkpxg   1/1     Running   4 (61m ago)   102m   10.244.2.5   k8s-work2   <none>           <none>
springboot-55df548fdb-lr4v4                        1/1     Running   0             32s    10.244.2.8   k8s-work2   <none>           <none>
springboot-55df548fdb-pdpfh                        1/1     Running   0             32s    10.244.1.6   k8s-work1   <none>           <none>
# deployment控制器资源部署成功后，我们继续使用pod IP+端口方式访问测试
[root@k8s-master springboot]# curl 10.244.2.8:8888
Hello SpringBoot Version:v1
[root@k8s-master springboot]# curl 10.244.1.6:8888/healthy
ok

创建service资源
控制器资源创建无误后，接下来我们部署service资源，然后就可以通过clusterIP+端口方式访问服务

[root@k8s-master springboot]# cat service.yaml 
apiVersion: v1
kind: Service
metadata:
  name: springboot
spec:
  type: ClusterIP 
  selector:
    app: springboot 
  ports:
  - name: http
    port: 8888
    protocol: TCP 
    targetPort: 8888 
[root@k8s-master springboot]# kubectl apply -f service.yaml 
service/springboot created
[root@k8s-master springboot]# kubectl get svc 
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP    127m
springboot   ClusterIP   10.100.116.123   <none>        8888/TCP   6s
[root@k8s-master springboot]# curl 10.100.116.123:8888
Hello SpringBoot Version:v1

创建ingress资源
至此，资源创建基本完成，接下来我们配置一个ingress域名资源，客户端配置hosts地址后，就可以通过域名方式访问服务

[root@k8s-master springboot]# cat ingress.yaml 
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: springboot
spec:
  entryPoints:
  - web
  routes:
  - match: Host(`springboot.test.com`) # 域名
    kind: Rule
    services:
      - name: springboot  # 与svc的name一致
        port: 8888     # 与svc的port一致[root@k8s-master springboot]# 
[root@k8s-master springboot]# kubectl apply -f ingress.yaml 
ingressroute.traefik.containo.us/springboot created
[root@k8s-master springboot]# kubectl get ingressroute
NAME         AGE
springboot   18s

案例2(vue)

思路分析

VUE项目，只提供源码：构建镜像时，使用Nodejs和NGINX两个基础镜像多阶段构建
部署开发与生产环境：一套代码，两套环境，通过configmap创建两套不同配置。
使用两个域名访问两个环境：部署两套Controller 、Service、Ingress。
从远端定时拉取资源：需要使用sidecar模式，一个vue容器，一个img容器，共享存储路径，实现静态资源远端拉取更新。

构建docker镜像
在这个案例中，我们只有git仓库的地址。因此我们首先要克隆代码，然后再执行打包并测试。

[root@k8s-master vue]# git clone https://gitee.com/cuiliang0302/vue3_vite_element-plus.git
[root@k8s-master vue]# docker build -f Dockerfile-vue -t vue:v1 .
[root@k8s-master vue]# docker run -d -p 90:80 vue:v1
09b2ad25f1aa1f7d71f9977d965f82b17edfced266dc3f9287c143fef02dfd9c

vue镜像测试无误，接下来打包测试拉取图片的img镜像

[root@k8s-master vue]# docker build -f Dockerfile-img -t img:v1 .
[root@k8s-master vue]# docker run -d img:v1
c212f514f52dfa84f2b499c73a684ee2037c2ebf9654b4d37ee2d0bebde3b9a6
root@k8s-master vue]# docker exec -it c212f514f5 sh
/media # cd /media/
/media # ls -lh
total 332K   
-rw-r--r--    1 root     root      329.7K Mar  7 12:17 images.jpg

推送至harbor私有镜像仓库

[root@k8s-master vue]# docker tag vue:v1 192.168.10.100/demo/vue:v1
[root@k8s-master vue]# docker push 192.168.10.100/demo/img:v1
[root@k8s-master vue]# docker tag img:v1 192.168.10.100/demo/img:v1
[root@k8s-master vue]# docker push 192.168.10.100/demo/img:v1

创建configmap资源
我们分别创建两套nginx的配置文件，分别对应开发环境和生产环境。

[root@k8s-master vue]# cat configmap.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: vue-dev
data:
  default.conf: |-
    server {
      listen       80;
      server_name  vue-dev.test.com; # 开发环境域名
      location /img {                # 访问img路径下资源时，重定向到百度页面
          return 301 https://www.baidu.com;
      }
      location / {
          root  /opt/vue/dist;
          index  index.html index.htm;
          try_files $uri $uri/ /index.html;
          add_header Access-Control-Allow-Origin *;
      }
    } 
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: vue
data:
  default.conf: |-
    server {
      listen       80;
      server_name   vue.test.com; # 生产环境域名
      location /img {             # 访问img路径下资源时，从远端获取，保存到/media目录下
          alias /media/;
      }
      location / {
          root  /opt/vue/dist;
          index  index.html index.htm;
          try_files $uri $uri/ /index.html;
          add_header Access-Control-Allow-Origin *;
      }
    }
[root@k8s-master vue]# kubectl apply -f configmap.yaml 
configmap/vue-dev created
configmap/vue created

创建deployment资源
生产和开发环境对应两个不同的控制器，他俩的区别在于使用的configmap不同，在生产模式下，使用sidecar定期从远端获取资源，存放在/media共享路径下。

[root@k8s-master vue]# cat deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vue-dev
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vue-dev
  template:
    metadata:
      labels:
        app: vue-dev
    spec:
      containers:
      - name: vue
        image: 192.168.10.100/demo/vue:v1
        resources:
          limits:
            memory: "1Gi"
            cpu: "1"
          requests:
            memory: "128Mi"
            cpu: "100m" 
        ports:
          - containerPort: 80
            name: web
        livenessProbe:
          httpGet:
            port: web
            path: /
        readinessProbe:
          tcpSocket:
            port: web
        volumeMounts:
          - mountPath: /etc/nginx/conf.d/default.conf
            subPath: default.conf
            name: nginx-config
      volumes:  # 使用开发环境的nginx配置文件
        - name: nginx-config
          configMap:
            name:  vue-dev
            
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vue
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vue
  template:
    metadata:
      labels:
        app: vue
    spec:
      containers:
      - name: vue
        image: 192.168.10.100/demo/vue:v1
        resources:
          limits:
            memory: "1Gi"
            cpu: "1"
          requests:
            memory: "128Mi"
            cpu: "100m" 
        ports:
          - containerPort: 80
            name: web
        livenessProbe:
          httpGet:
            port: web
            path: /
        readinessProbe:
          tcpSocket:
            port: web
        volumeMounts:
          - mountPath: /etc/nginx/conf.d/default.conf
            subPath: default.conf
            name: nginx-config
          - mountPath: /media
            name: media
      - name: img
        image: 192.168.10.100/demo/img:v1
        resources:
          limits:
            memory: "128Mi"
            cpu: "100m" 
        volumeMounts:
          - mountPath: /media
            name: media
      volumes:
        - name:  nginx-config  # 使用生产模式nginx配置文件
          configMap:
            name:  vue
        - name: media          # 挂载空目录，用于存放远端资源
          emptyDir: {}
[root@k8s-master vue]# kubectl apply -f deployment.yaml 
deployment.apps/vue-dev created
deployment.apps/vue created

创建service资源
service资源同样也是两套，唯一不同的区别在于匹配不同的资源标签

[root@k8s-master vue]# cat service.yaml 
apiVersion: v1
kind: Service
metadata:
  name: vue-dev
spec:
  type: ClusterIP 
  selector:
    app: vue-dev 
  ports:
  - name: http
    port: 80
    protocol: TCP 
    targetPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: vue
spec:
  type: ClusterIP 
  selector:
    app: vue
  ports:
  - name: http
    port: 80
    protocol: TCP 
    targetPort: 80
[root@k8s-master vue]# kubectl apply -f service.yaml 
service/vue-dev created
service/vue created

创建ingress资源
ingress资源同样也是两套，对应不同的环境域名

[root@k8s-master vue]# cat ingress.yaml 
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: vue-dev
spec:
  entryPoints:
  - web
  routes:
  - match: Host(`vue-dev.test.com`) # 域名
    kind: Rule
    services:
      - name: vue-dev
        port: 80
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: vue
spec:
  entryPoints:
  - web
  routes:
  - match: Host(`vue.test.com`) # 域名
    kind: Rule
    services:
      - name: vue
        port: 80
[root@k8s-master vue]# kubectl apply -f ingress.yaml 
ingressroute.traefik.containo.us/vue-dev created
ingressroute.traefik.containo.us/vue created

访问验证
开发环境，当我们访问http://vue-dev.test.com/img/images.jpg时，会301重定向到百度页面。

生产环境，当我们访问http://vue.test.com/img/images.jpg时，会从远端服务器拉取资源文件并返回给客户端。

案例3(python)

思路分析

安装网络软件包：不能使用Python基础镜像，只能使用centos、ubuntu等系统镜像
定时运行项目：使用cronjob控制器
持久化存储数据：使用nfs、ceph共享存储服务
将日志采集并实时上传到ES：方案1：使用sidecar模式启动filebeat服务，同一pod包含两个container，共用日志目录。方案2：使用hostpath挂载宿主机目录，使用daemonset控制器启动filebeat服务，采集宿主机目录日志。但是此案例中，python程序仅需几秒便可执行完成，而filebeat需要持续运行，使用sidecar模式会导致filebeat还未开始采集日志，python程序已经运行完成，最终导致pod状态码异常，因此采用daemonset方案。

打包镜像并上传

[root@k8s-master python]# cat Dockerfile 
FROM rockylinux:8
RUN dnf -y install wget gcc gcc-c++ net-tools telnet iproute procps tcpdump python38 python38-devel
ADD project /project
RUN pip3.8 install -r /project/requirements.txt -i https://pypi.doubanio.com/simple
WORKDIR /project
CMD ["python3.8","main.py"]
[root@k8s-master python]# docker build -t python:v1 .
[root@k8s-master python]# docker run python:v1
2023-03-07 14:49:33.213 | INFO     | __main__:<module>:26 - 爬虫程序开始执行
2023-03-07 14:49:33.214 | INFO     | __main__:get_data:10 - 获取的数据ID:43
2023-03-07 14:49:40.958 | INFO     | __main__:get_data:14 - 获取的name值:oddish
2023-03-07 14:49:40.965 | INFO     | __main__:save_data:22 - 文件写入完成，文件名:oddish1678200580.txt
2023-03-07 14:49:40.966 | INFO     | __main__:<module>:29 - 爬虫程序执行完成
[root@k8s-master python]# docker tag python:v1 192.168.10.100/demo/python:v1
[root@k8s-master python]# docker push 192.168.10.100/demo/python:v1

创建pvc资源，用于持久化存储爬虫数据

[root@k8s-master python]# cat pvc.yaml 
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: python-pvc
spec:
  storageClassName: nfs-client
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
[root@k8s-master python]# kubectl apply -f pvc.yaml 
persistentvolumeclaim/python-pvc created

创建cronjob资源，定时执行爬虫程序

[root@k8s-master python]# cat cronjob.yaml 
apiVersion: batch/v1
kind: CronJob
metadata:
  name: python
spec:
  schedule: "* * * * *"
  jobTemplate:
    metadata:
      name: python
    spec:
      template:
        spec:
          containers:
          - name: python
            image: 192.168.10.100/demo/python:v1
            volumeMounts:
            - name: python-data
              mountPath: "/project/data"
            - name: python-log
              mountPath: "/project/log"
            env:
            - name: TZ
              value: Asia/Shanghai
          restartPolicy: Never
          volumes:
          - name: python-data
            persistentVolumeClaim:
              claimName: python-pvc
          - name: python-log
            hostPath:
              path: /data/python-log
              type: DirectoryOrCreate
[root@k8s-master python]# kubectl apply -f cronjob.yaml 
cronjob.batch/python created

导出es证书
因为es从8开始，安装后默认开启了base基础用户验证和TLS证书。filebeat想要连接ES需要指定SSL证书，否则会报X509证书异常错误。

[root@tiaoban ~]# docker cp elasticsearch:/usr/share/elasticsearch/config/certs .
Successfully copied 21.5kB to /root/.
[root@tiaoban ~]# ls
anaconda-ks.cfg  certs  elasticsearch.yml
[root@tiaoban ~]# cd certs/
[root@tiaoban certs]# ls
http_ca.crt  http.p12  transport.p12
[root@tiaoban certs]# scp http_ca.crt k8s-master:/root

创建secret资源
从docker容器中导出es证书后，创建secret资源，后续filebeat直接挂载证书资源即可。

[root@k8s-master ~]# kubectl create secret generic es --from-file=./http_ca.crt 
secret/es created
[root@k8s-master ~]# kubectl describe secrets es 
Name:         es
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
http_ca.crt:  1915 bytes

创建filebeat的configmap资源

[root@k8s-master python]# cat configmap.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: filebeat-config
data:
  filebeat.yml: |-
    filebeat.inputs:
    - type: log
      enabled: true
      paths:
      - /project/log/*.log
    setup.ilm.enabled:  false #新版本的Filebeat则默认的配置开启了ILM 导致索引的命名规则被ILM策略控制
    setup.template.name:  "python"
    setup.template.pattern:  "python-*"
    setup.template.overwrite:  false
    setup.template.settings:
      index.number_of_shards: 1 #索引分片数
      index.number_of_replicas: 0 #索引副本数
    output.elasticsearch:  #指定ES的配置
      hosts:  ["https://192.168.10.100:9200"]
      username: "elastic"
      password: "HufU-ybqd5aeEvh8xf6y"
      index: "python-%{+yyyy.MM.dd}"
      ssl.certificate_authorities: ["/secret/http_ca.crt"]
[root@k8s-master python]# kubectl apply -f configmap.yaml 
configmap/filebeat-config created

创建daemonset资源，每个节点启动一个filebeat

[root@k8s-master python]# cat daemonset.yaml 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: filebeat
  labels:
    app: filebeat
spec:
  selector:
    matchLabels:
      app: filebeat
  template:
    metadata:
      labels:
        app: filebeat
    spec:
      containers:
      - name: filebeat
        image: elastic/filebeat:8.6.2
        resources:
          limits:
            memory: "128Mi"
            cpu: "100m" 
          requests:
            memory: "10Mi"
            cpu: "10m" 
        args: ["-c","/etc/filebeat/filebeat.yml","-e"]
        volumeMounts:
        - name: filebeat-config
          mountPath: /etc/filebeat/filebeat.yml
          subPath: filebeat.yml
        - name: python-log
          mountPath: /project/log
        - name: es-cert
          mountPath: /secret
          readOnly: true
      volumes:
      - name: python-log
        hostPath:
          path: /data/python-log
          type: DirectoryOrCreate
      - name: filebeat-config
        configMap:
          name: filebeat-config
      - name: es-cert
        secret:
          secretName: es
[root@k8s-master python]# kubectl apply -f daemonset.yaml 
daemonset.apps/filebeat created

访问kibana查看日志是否成功上传

在index management页面查看index是否成功创建

建立kibana data views

discover查看index详细数据

查看nfs目录数据

[root@tiaoban default-python-pvc-pvc-b52722f6-1c82-41cb-9e79-fd7e991c78dd]# pwd
/data/nfs/default-python-pvc-pvc-b52722f6-1c82-41cb-9e79-fd7e991c78dd
[root@tiaoban default-python-pvc-pvc-b52722f6-1c82-41cb-9e79-fd7e991c78dd]# ls -lt
总用量 201
-rw-r--r-- 1 root root 183112 3月   8 23:03 pidgey1678287784.txt
-rw-r--r-- 1 root root 210376 3月   8 23:02 poliwag1678287723.txt
-rw-r--r-- 1 root root 193014 3月   8 23:01 cloyster1678287664.txt
-rw-r--r-- 1 root root  27881 3月   8 23:00 weedle1678287603.txt
-rw-r--r-- 1 root root 243530 3月   8 22:59 pikachu1678287544.txt
-rw-r--r-- 1 root root 278708 3月   8 22:58 drowzee1678287483.txt
-rw-r--r-- 1 root root 182849 3月   8 22:57 ninetales1678287423.txt
-rw-r--r-- 1 root root 234397 3月   8 22:56 vulpix1678287363.txt

Helm部署服务

为什么需要Helm

通过上面几个实践案例，大家肯定会思考这样的问题。部署一个服务，需要创建ConfigMap、PV、PVC、Deployment 、Service、Ingress这一堆资源。

能否统一管理、配置和更新这些分散的 k8s 资源文件，防止服务器到处都是散落的yaml文件，修改配置时先要查找yaml文件
能否分发和复用一套应用模板，每个springboot资源基本都是相同的资源，只是镜像版本和名称不一致
能否将应用的一系列资源当做一个软件包管理，像使用yum一样一键部署安装服务

kubernetes为了解决上述问题，推出了helm。

Helm是什么

Helm 是 Kubernetes 的包管理器。包管理器类似于我们在 Ubuntu 中使用的apt、Centos中使用的yum 或者Python中的 pip 一样，能快速查找、下载和安装软件包。能够将一组K8S资源打包统一管理, 是查找、共享和使用Kubernetes构建的软件的最佳方式。

Helm部署服务

类似于docker hub一样，helm也为我们提供了hub仓库，地址为https://artifacthub.io/。我们只需要浏览helm仓库，找到合适的helm安装包，添加仓库源，然后安装即可。以使用helm部署elk为例，参考文档https://www.cuiliangblog.cn/detail/section/15189467

自定义chart

除了浏览官方的helm仓库安装应用外，自定义服务部署也可以使用helm方式实现，开发者只需要按照 Helm Chart 的格式，将应用所需的资源文件包装起来，通过模版化 (Templating) 的方式将一些可变字段（比如我们之前提到的暴露哪个端口、使用多少副本）暴露给用户，最后将封装好的应用包，就完成了Helm Chart的制作，最后集中存放在统一的仓库中供其他用户浏览下载。参考文档https://www.cuiliangblog.cn/detail/section/15287438

operator部署服务

Operator 模型基于 Kubernetes 中的两个概念结合而成：自定义资源和自定义控制器。要想理解operator，首先就要知道自定义资源和自定义控制器

什么是CRD

CRD(Custom Resource Definitions)，也就是自定义K8S资源类型。
当内置的POD、Deployment、Configmap等资源类型不满足需求时，我们就需要扩展k8s，常用方式有三种：

使用CRD自定义资源类型
开发自定义的APIServer（例如HPA）
定制扩展Kubernetes源码（例如腾讯云TKE）

在 Kubernetes中，资源是 Kubernetes API中的一个端点，用于存储一堆特定类型的API对象。它允许我们通过向集群添加更多种类的对象来扩展Kubernetes。添加新种类的对象之后，我们可以像其他任何内置对象一样，使用 kubectl 来访问我们自定义的 API 对象，CRD无须修改Kubernetes源代码就能扩展它支持使用API资源类型。

什么是Controller

Kubernetes 的所有控制器，都有一个控制循环，负责监控集群中特定资源的更改，并确保特定资源在集群里的当前状态与控制器自身定义的期望状态保持一致。
Controller是需要CRD配套开发的程序，它通过Apiserver监听相应类型的资源对象事件，例如：创建、删除、更新等等，然后做出相应的动作，例如一个 Deployment 控制器管控值集群里的一组 Pod ，当你 Kill 掉一个 Pod 。控制器发现定义中期望的Pod数量与当前的数量不匹配，它就会马上创建一个 Pod 让当前状态与期望状态匹配。

什么是Operator

operator 是一种 kubernetes的扩展形式，利用自定义资源对象CRD来管理应用和组件，允许用户以 Kubernetes 的声明式 API 风格来管理应用及服务。operator 定义了一组在 Kubernetes 集群中打包和部署复杂业务应用的方法，operator主要是为解决特定应用或服务关于如何运行、部署及出现问题时如何处理提供的一种特定的自定义方式。

使用Operator方式部署有状态服务

例如MySQLOperator可以实现：

全生命周期设置和维护
使用 oracle 官方发布的 MGR 高可用架构
自动、按需备份
自动故障检测，故障切换和故障恢复

例如ESOperator（ECK）可以实现：

管理和监测集群
证书安全配置
轻松升级至新的版本
扩大或缩小集群容量
更改集群配置

例如KafkaOperator（Strimzi）可以实现：

快速部署集群和安全配置
自动化证书管理
快速集群扩容
快速灾难恢复
支持滚动更新，支持备份以及还原

总结

横向对比

	Helm	Operator
资源类型	标准对象，自定义对象	自定义对象
运维能力	手工，较弱	自动故障恢复及异常处理
设计理念	资源模板化，配置分离	复杂应用的自动化管理
实现方式	传统镜像	k8s控制器
实现难度	较低	偏高
灵活性	高度灵活修改YAML文件	依赖控制程序，不太灵活

适用场景

方式	场景	举例
手写YAML	部署业务项目、需要频繁需改配置或架构、需要高度灵活性	Prometheus、Traefik
Helm	部署无状态集群服务、快速部署实验测试环境	Redis、Consul、Grafana
Operator	部署有状态集群服务	MySQL、Kafka、Elasticsearch