云原生部署(十):健康检查与零停机部署
一个应用在容器里跑起来了,但“进程在跑”和“服务可用”是两回事。进程可能卡死在死循环里,可能连不上数据库,可能启动了半天还没加载完。K8s 的健康检查机制就是来区分这些状态的。而配合滚动更新策略,我们可以做到“用户无感知”的零停机发布——这一篇是云原生部署系列的收尾,把前面学的知识串起来,落地到生产实践。
一个开发出身的DevOps工程师
一个应用在容器里跑起来了,但“进程在跑”和“服务可用”是两回事。进程可能卡死在死循环里,可能连不上数据库,可能启动了半天还没加载完。K8s 的健康检查机制就是来区分这些状态的。而配合滚动更新策略,我们可以做到“用户无感知”的零停机发布——这一篇是云原生部署系列的收尾,把前面学的知识串起来,落地到生产实践。
如果你部署一个稍微复杂一点的应用(比如一个微服务 + MySQL + Redis + Nginx),YAML 文件会多到你怀疑人生。而且不同环境的配置(开发、测试、生产)各有不同,难道要维护三套 YAML?Helm 就是来解决这个痛苦——它被称为 “K8s 的 apt/yum”。
容器是“用完即扔”的,但数据不是。如果把 MySQL 直接跑在容器里,容器一删数据就没了,这显然不行。K8s 怎么管理存储?PV、PVC、StorageClass 这些都是什么关系?这篇文章把这些概念一次讲清楚。
网络是 K8s 中最复杂也最容易被忽视的部分。Pod 之间怎么通信?Service 的那个虚拟 IP 到底是怎么工作的?kube-proxy 在背后做了什么?这篇文章带你理清 K8s 网络的来龙去脉。
理解了 K8s 的架构,接下来该认识 K8s 中最核心的 API 对象了:Pod、Deployment、Service,以及管理配置与密钥的 ConfigMap 和 Secret。这五个是你日常和 K8s 打交道时使用频率最高的概念,搞明白了它们,K8s 就算入了门。
Kubernetes 被称为“容器编排之王”,但它的代码上了百万行、组件一堆,第一次接触的人很容易迷失。这篇文章带你从架构层面理解 K8s:它从哪里来,由哪些核心组件构成,以及这些组件之间是怎么协作的。
镜像构建出来了,放哪?直接推到 Docker Hub 上?如果你在公司做 DevOps,答案大概率是否定的。公司的代码、尤其是包含业务逻辑的镜像,不可能直接放到公共网络上。你需要一个私有镜像仓库。而这,就是 Harbor 的用武之地。
会写 Dockerfile 和写好 Dockerfile 是两回事。一个糟糕的 Dockerfile 可能让你的镜像从 100MB 变成 1GB,一个优秀的 Dockerfile 则能让你的构建快、镜像小、安全性还好。这篇我们深入 Dockerfile 的每条指令,并通过实际案例掌握多阶段构建。
Docker 是云原生部署的第一步。很多人会用 docker run,但未必清楚背后发生了什么。镜像和容器到底有什么区别?为什么 Docker 镜像那么省空间?“分层”是什么概念?这篇文章带你从原理层面理解 Docker 的核心机制。
你有没有想过,为什么十年前部署一个应用要折腾好几天,而现在几分钟就能上线?我们今天熟悉的容器、Kubernetes、云原生,其实不是凭空出现的,它们是一步步演化而来的。要理解云原生部署,得先知道它从哪里来、解决了什么问题。