日本做衣服的网站营销方案模板

背景

采用微服务架构部署的应用，部署方式都要用到容器化部署+k8s容器编排，最近我在公司负载的系统也是用的上述架构部署，但是随着系统的运行，用户提的需求就会越多，每次更新的话都要停机发布，最用户侧来说就不太方便了，传统的部署方式是使用nginx来做负载均衡，然后手动来做滚动发布，殊不知k8s也有自己的一套配置，来解决滚动发布的事情，并且系统发布时用户侧其实是无感知的；

配置文件代码

先上代码，再讲解各个参数的含义

apiVersion: apps/v1  
kind: Deployment  
metadata:  name: my-app-deployment  labels:  app: my-app  
spec:  replicas: 3  selector:  matchLabels:  app: my-app  strategy:  type: RollingUpdate  rollingUpdate:  maxSurge: 1  maxUnavailable: 1 template:  metadata:  labels:  app: my-app  spec:  containers:  - name: my-app-container  image: your-image-repository/my-app:latest  ports:  - containerPort: 8080  readinessProbe:  httpGet:  path: /system/health/readniess  port: 8080  initialDelaySeconds: 5  periodSeconds: 10  livenessProbe:  httpGet:  path: /system/health/readniess  port: 8080  initialDelaySeconds: 15  periodSeconds: 20minReadySeconds: 50

配置参数说明

这里的配置文件中主要用到了strategy，readinessProbe，livenessProbe等主要的参数，下面讲解一下这写参数的含义；
strategy
将现有 Pod 替换为新 Pod 时所用的部署策略。其下面有以下可用参数：
  type:部署的类型。取值可以是 “Recreate” 或 “RollingUpdate”。默认为 RollingUpdate;Recreate是重建式更新，在创建新 Pod 之前，所有现有的 Pod 会被杀死;RollingUpdate是滚动更新，简单定义 更新期间pod最多有几个等。可以指定maxUnavailable 和 maxSurge 来控制 rollingupdate 进程;Recreate会导致站点的停机,RollingUpdate则可以通过相关的配置,保证站点正常接收流量的情况下,部署新版本升级,不影响用户使用;
  rollingUpdate 当type=rollingUpdate时才需设置此参数，rollingUpdate下的参数有如下这些：

1. maxSurge ：超出预期的 Pod 数量之后可以调度的最大 Pod 数量。该值可以是一个绝对数（例如： 5）或一个预期 Pod 的百分比（例如：10%）。如果 MaxUnavailable 为 0，则此字段不能为 0。 通过向上取整计算得出一个百分比绝对数。默认为 25%。例如：当此值设为 30% 时， 如果滚动更新启动，则可以立即对 ReplicaSet 扩容，从而使得新旧 Pod 总数不超过预期 Pod 数量的 130%。 一旦旧 Pod 被杀死，则可以再次对新的 ReplicaSet 扩容， 确保更新期间任何时间运行的 Pod 总数最多为预期 Pod 数量的 130%
2. maxUnavailable ：更新期间可能不可用的最大 Pod 数量。该值可以是一个绝对数（例如： 5）或一个预期 Pod 的百分比（例如：10%）。通过向下取整计算得出一个百分比绝对数。 如果 MaxSurge 为 0，则此字段不能为 0。默认为 25%。 例如：当此字段设为 30%，则在滚动更新启动时 ReplicaSet 可以立即缩容为预期 Pod 数量的 70%。 一旦新的 Pod 就绪，ReplicaSet 可以再次缩容，接下来对新的 ReplicaSet 扩容， 确保更新期间任何时间可用的 Pod 总数至少是预期 Pod 数量的 70%

readinessProbe
就绪探针；指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针，则默认状态为 Success。
例如，应用在启动时可能需要加载大量的数据或配置文件，或是启动后要依赖等待外部服务。 在这种情况下，既不想杀死应用，也不想给它发送请求。 Kubernetes 提供了就绪探针来发现并缓解这些情况。 容器所在 Pod 上报还未就绪的信息，并且不接受通过 Kubernetes Service 的流量。
说明：就绪探针在容器的整个生命周期中保持运行状态。也就是说配置后就绪探针会一直运行，确服务是否就绪状态；
就绪探针可以使用使用 HTTP GET 请求、TCP 套接字、exec、 gRPC 健康检查协议来进行探测，我这里使用的是http请求后台服务的一个接口来判断应用是否已经启动好了，如果启动好了，那就对外部提供服务；
就绪探针下常用的参数配置：
  initialDelaySeconds：容器启动后要等待多少秒后才启动启动、存活和就绪探针。 如果定义了启动探针，则存活探针和就绪探针的延迟将在启动探针已成功之后才开始计算。 如果 periodSeconds 的值大于 initialDelaySeconds，则 initialDelaySeconds 将被忽略。默认是 0 秒，最小值是 0。
  periodSeconds：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
  failureThreshold：探针连续失败了 failureThreshold 次之后， Kubernetes 认为总体上检查已失败：容器状态未就绪、不健康、不活跃。 对于启动探针或存活探针而言，如果至少有 failureThreshold 个探针已失败， Kubernetes 会将容器视为不健康并为这个特定的容器触发重启操作。 kubelet 遵循该容器的 terminationGracePeriodSeconds 设置。 对于失败的就绪探针，kubelet 继续运行检查失败的容器，并继续运行更多探针； 因为检查失败，kubelet 将 Pod 的 Ready 状况设置为 false。
其他常用的配置可以查阅官网 k8s官网

livenessProbe
指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针，则默认状态为 Success。
存活探针来确定什么时候要重启容器。 例如，存活探针可以探测到应用死锁（应用在运行，但是无法继续执行后面的步骤）情况。 重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。
存活探针的常用参数和就绪探针完全一致，可以参考存活探针的使用方法；

最后我的配置文件内还使用了minReadySeconds参数，他的意思是：新建的 Pod 在没有任何容器崩溃的情况下就绪并被系统视为可用的最短秒数。 默认为 0（Pod 就绪后即被视为可用）。