Bitnami：一个真实的Kubernetes案例

我们的解决方案

• dev：开发者做产品试验，或者运行alpha阶段的软件。
• int：内部服务，比如bugtracker和CI/CD。
• web：外部可访问的服务，比如网站

• 如何协调不同人员、不同时区的改动？
• 我们如何确保不同的服务能够使用相同的部署模式/规则
• 如何确保一个通用的服务能够被一致地部署在多个集群中

关于集群功能的简单介绍

宏图

配置：模板无处不在！

apiVersion: v1
kind: Service
metadata:
labels:
name: proxy
name: proxy
namespace: webcache
spec:
ports:
- port: 80
targetPort: proxy
selector:
name: proxy
type: ClusterIP
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
name: proxy
name: proxy
namespace: webcache
spec:
minReadySeconds: 30
replicas: 1
revisionHistoryLimit: 10
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
template:
metadata:
 labels:
  name: proxy
spec:
 containers:
 - name: squid
   # skipped, for clarity

• 声明式的，无副作用（side-effect-free）语言在复杂的情况系统中能够减少意外的发生。
• 能够原生地生成JSON，而不仅仅是一个特定领域专用的语言，只能够将几个特殊的字符片段拼接起来。
• 支持多个输入文件，并且拥有一个强大的合并功能，它使得我们能够构建通用模板的库。
• 当我们在Google工作时，也遇到类似的问题，那时我们使用了一个类似的语言。
• 缺点：小众，并且没有被预安装在主流的linux发行版中。

{
namespace: "webcache",

squid_service: kube.Service("proxy") {
metadata+: { namespace: $.namespace },
target_pod: $.squid.spec.template,
port: 80,
},

squid: kube.Deployment("proxy") {
metadata+: { namespace: $.namespace },
spec+: {
  template+: {
    spec+: {
      containers_+: {
        squid: kube.Container("squid") {
          // skipped, for clarity
        },
      },
    },
  },
},
},  // Kubernetes structures are deep :)
} 

表达相似性

• 运行在多个集群的通用模块
• 横跨多个模块的通用部署模式

• lib/ 基础库，主要负责通用部署模式
• common/ 基于基础库，描述的是软件栈中耦合更紧密的资源声明
• $cluster_name/ 每个命名空间对应一个文件，它们整合了common/中的栈，并且覆写集群特有的选项。

工具以及工作流

1. 开发者在他们最喜欢的编辑器中编辑jsonnet文件。在实际场景中，为了测试，总是会有一个“编辑、运行jsonnnet、推送到dev集群，查看结果”的循环过程。Kubecfg.sh脚本使得这个过程变得简单。我们关于dev集群的宗旨就是“善待开发者，任何改动都能够被重新恢复到git中的任一个阶段”
2. Jsonnet文件被扩展成正常的json文件，这个过程使用了一个简单的jsonnet-in-docker脚本，它会被Makefile触发。我们发现JSON文件能够让作者和评审者清楚的知道改动会影响什么内容，尤其是当你修改了基础模板时。
3. 不同的单元测试会对jsonnet和JSON文件进行测试。我们的jsonnet代码包含了许多的assert语句，这些都会在JSON生成的过程中被验证。我们还额外地检查了jsonnet代码风格的一致性，因此生成的JSON文件非常准确，符合Kubernetes的jsonschema，并且所有的资源都有一个显式的命名空间。重要的是，在任何时间这些检查都是安全的，因此我们可以在github pull请求的时候执行这些检查。
4. 团队成员能够通过常规的github代码评审来查看改动。他们知道多个自动化测试已经通过了，因此他们能够专注于高层次的内容正确性而不是语法正确性。当觉得改动能够接受时，只需要点击同意，就能够完成合并了。
5. 合并之后，jenkins自动对每个集群运行deplo.sh脚本来部署这些改动。已有的Deployment检查和首航（rollout）策略都能防止灾难性的改动被通过。此外，我们还有持续性的监控来报告任何错误的发生。重要的是，首航策略足够缓慢，因此监控系统能够给我们足够的时间来应对以及冻结这次崩溃的首航，这些可以通过常规的kubectl rollout pause和undo命令来完成。我们拥有过去的所有历史记录，因此我们能够通过回滚git中错误的改动来完成恢复。

教训以及未来的工作

杨润青，90后博士僧，研究方向是网络和信息安全。

原文发布时间为：2017-05-17

本文作者：杨润青

本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。

原文标题：Bitnami：一个真实的Kubernetes案例