diff --git a/GitOps/summary.md b/GitOps/summary.md index ff906b9c..6adb7658 100644 --- a/GitOps/summary.md +++ b/GitOps/summary.md @@ -1,5 +1,7 @@ # 第十章 GitOps 落地实践 +工欲善其事必先利其器，软件研发的管理是一件非常复杂的事情。业务系统有多么复杂，研发管理就有多么复杂 + 随着 DevOps 文化的盛行，人们也一直在寻找一种能更好解决云环境中持续部署的最佳实践。 GitOps 起源于 weaveworks 公司在 2017 年发表的一篇博客：​GitOps - Operations by Pull Request[^1]。在这篇文章中，作者 Alexis Richardson 介绍了一种以 Git 为唯一事实来源的软件部署方式。在这种方式下，我们需要将软件设施定义在 Git 仓库中进行管理，这里的软件设施不限于应用本身，也包括 IaaS、Kubernetes 这样的基础设置。每个工程师都可以通过提交 Pull Request 来修改软件设施，然后通过自动化程序（譬如 Flux CD、Argo CD）的方式在线上执行这些修改。 @@ -8,8 +10,6 @@ GitOps 起源于 weaveworks 公司在 2017 年发表的一篇博客：​GitOps - - [^1]: 参见 https://www.weave.works/blog/gitops-operations-by-pull-request diff --git a/container/k8s-deploy-etcd.md b/container/k8s-deploy-etcd.md index 52489473..dfe4f48d 100644 --- a/container/k8s-deploy-etcd.md +++ b/container/k8s-deploy-etcd.md @@ -1,14 +1,12 @@ # 高可用 etcd 集群 -笔者在分布式的章节用大量篇幅介绍共识算法和 raft，现在那些知识终于到了用武之地了。 +笔者在分布式的章节用大量篇幅介绍共识算法和 raft，这一节那些知识终于到了用武之地。 -etcd 是 Kubernetes 的核心存储，Kubernetes 所有的资源对象都保存在 etcd etcd 是否健壮将直接影响 Kubernetes 服务。 +笔者根据 raft 协议以及 etcd 本身实现的特性，解读部署中的部分策略，首先因 raft 选举或者可用性要求，一般部署节点的个数奇数且数量大于 3 个，注意，笔者用的是“一般”，实际上**raft 并不严格限定到底是奇数还是偶数，只要 (n-1)/2 以上的节点正常，集群就能正常工作**。譬如配置 4 个节点，其中 1 个节点宕机了，但还有 (n-1)/2 个节点正常，对 etcd 集群而言不论是选举还是可用性，都不会产生影响。 -etcd 使用 Raft 协议，因 raft 选举或者可用性要求，一般部署节点的个数奇数且数量大于 3 个，注意，笔者用的是“一般”，**raft 并不严格限定到底是奇数还是偶数，只要 (n-1)/2 以上的节点正常，集群就能正常工作**。譬如配置 4 个节点，其中 1 个节点宕机了，但还有 (n-1)/2 个节点正常，对 etcd 而言不论是选举还是可用性，都不会产生影响。 +etcd 集群的性能极限受两部分影响：单机性能的影响（有条件使用 SSD 存储）以及网络的开销。etcd 默认是线性一致性（最强一致性），每次操作所有的节点都要参与，节点越多性能越低，所以增加再多的节点意义不是很大。官方推荐 etcd 节点个数 3、5、7。 -etcd 的性能极限受两个部分影响：单机性能的影响以及网络的开销。etcd 默认是线性一致性（最强一致性），每次操作所有的节点都要参与，节点越多性能越低，所以增加再多的节点意义不是很大。官方推荐 etcd 节点个数 3、5、7。 - -笔者使用多个可用区的方式部署 etcd，假设的是云商**某个可用区产生重大故障，短时间内无法恢复**。注意这个并不是防止脑裂，官方给到的解释也是 etcd 没有脑裂。 +笔者使用多个可用区的方式部署 etcd，注意这个并不是防止脑裂，官方给到的解释也是 **etcd 没有脑裂**。可用区部署假设的是云商某个可用区产生重大故障，短时间内无法恢复。 :::tip etcd 没有脑裂 The majority side becomes the available cluster and the minority side is unavailable; there is no “split-brain” in etcd. diff --git a/container/runtime.md b/container/runtime.md index 292f824c..788ff5bc 100644 --- a/container/runtime.md +++ b/container/runtime.md @@ -1,8 +1,6 @@ # 7.4 容器运行时 -作为容器技术早期的项目 Docker，以一个“好点子”（镜像）引爆了一个时代，不过这个”好点子“也并不是特别复杂的技术，笔者相信就算没有 Docker 也会有 Cocker 或者 Eocker 的出现，而 Kubernetes 的成功不仅有 Google 深厚的技术功底作支撑，有领先时代的设计理念，更加关键的是 Kubernetes 的出现符合所有云计算大厂的切身利益，有着业界巨头不遗余力的广泛支持，它的成功便是一种必然。 - -Kubernetes 与 Docker 两者的关系十分微妙，把握住两者关系的变化过程，是理解 Kubernetes 架构演变与容器运行时 CRI、OCI 规范的良好线索。 +Docker 大概也没想到，在 2020 还能再次成为舆论的焦点，事件的起源是 Kubernetes 宣布开始进入废弃 dockershim 支持的倒计时，最后讹传讹被人误以为 Docker 不能再用了。虽说此次事件有众多标题党的推波助澜，但也侧面说明了 Kubernetes 与 Docker 两者的关系十分微妙，而把握住两者关系的变化过程，就成了我们理解 Kubernetes 架构演变与 CRI 以及 OCI容器运行时规范的绝佳线索。 ## OCI