做网站的劣势,遵义网站开发公司,驰够网官方网站,重庆市门户网站制作背景
采用微服务架构部署的应用#xff0c;部署方式都要用到容器化部署k8s容器编排#xff0c;最近我在公司负载的系统也是用的上述架构部署#xff0c;但是随着系统的运行#xff0c;用户提的需求就会越多#xff0c;每次更新的话都要停机发布#xff0c;最用户侧来说就…背景
采用微服务架构部署的应用部署方式都要用到容器化部署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配置参数说明
这里的配置文件中主要用到了strategyreadinessProbelivenessProbe等主要的参数下面讲解一下这写参数的含义 strategy 将现有 Pod 替换为新 Pod 时所用的部署策略。其下面有以下可用参数 type:部署的类型。取值可以是 “Recreate” 或 “RollingUpdate”。默认为 RollingUpdate;Recreate是重建式更新在创建新 Pod 之前所有现有的 Pod 会被杀死;RollingUpdate是滚动更新简单定义 更新期间pod最多有几个等。可以指定maxUnavailable 和 maxSurge 来控制 rollingupdate 进程;Recreate会导致站点的停机,RollingUpdate则可以通过相关的配置,保证站点正常接收流量的情况下,部署新版本升级,不影响用户使用; rollingUpdate 当typerollingUpdate时才需设置此参数rollingUpdate下的参数有如下这些
maxSurge 超出预期的 Pod 数量之后可以调度的最大 Pod 数量。该值可以是一个绝对数例如 5或一个预期 Pod 的百分比例如10%。如果 MaxUnavailable 为 0则此字段不能为 0。 通过向上取整计算得出一个百分比绝对数。默认为 25%。例如当此值设为 30% 时 如果滚动更新启动则可以立即对 ReplicaSet 扩容从而使得新旧 Pod 总数不超过预期 Pod 数量的 130%。 一旦旧 Pod 被杀死则可以再次对新的 ReplicaSet 扩容 确保更新期间任何时间运行的 Pod 总数最多为预期 Pod 数量的 130%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 在没有任何容器崩溃的情况下就绪并被系统视为可用的最短秒数。 默认为 0Pod 就绪后即被视为可用。
