伪架构师

在 Kubernetes 集群上部署 Gitlab Runner

Sun, 05 May 2019 00:00:00 +0100

Gitlab Runner 和 Gitlab 主程序一样，提供了 Helm chart 用于进行安装，同样可以用 helm fetch 下载 Chart 进行定制和渲染：

helm fetch --untar gitlab/gitlab-runner

根据官方文档介绍，Runner 的安装有两个必要参数：

gitlabUrl：Gitlab 的地址。
runnerRegistrationToken：注册用的 Token。

另外还有一个即将用到的重要参数：runners.image 这个参数可以用来指定 Runner 的基础镜像，以满足不同环节中对 Runner 的需求。

例如为了构建 Java 应用，我们创建一个 Maven 的 Runner。Gitlab 地址我们已经知道了，接下来获取一个 Token，用浏览器打开 /admin/runners，可以查看：

我们使用这个 Token，创建一个基于 maven:alpine 的 Runner：

$ helm template gitlab-runner \
--namespace gitlab \
--name java \
--set gitlabUrl="https://gitlab.microservice.rocks" \
--set runnerRegistrationToken="xgX4QEt8gklFGSOFu0FURTzfvticEQmqaa3cnosMmoxc1nacYSIMBniRmBgACn19" \
--set rbac.create=true \
--set runners.image="maven:alpine" \
--set runners.tags="java\,maven" \
--set runners.privileged=true | kubectl appy -f
secret/java-gitlab-runner created
configmap/java-gitlab-runner created
serviceaccount/java-gitlab-runner created
deployment.extensions/java-gitlab-runner created
role.rbac.authorization.k8s.io/java-gitlab-runner created
rolebinding.rbac.authorization.k8s.io/java-gitlab-runner created

创建成功之后，打开页面 /admin/runners，会看到其中列出了我们新建的 Runner：

点击 Runner ID，可以看到详细信息，也可以进行修改。

使用 Maven 运行单元测试

Sun, 05 May 2019 00:00:00 +0100

Runner 运行起来之后，我们可以尝试建立一个项目，使用 Runner 来针对每次提交，运行一次单元测试。

访问 projects/new 创建一个新项目，命名为 sample：

创建完成之后，进入项目的主页面：

这里点击 clone 按钮，会看到弹出的项目 git 地址，我们使用这个地址对项目进行初始化。

$ git clone git@gitlab.microservice.rocks:root/sample.git
正克隆到 'sample'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
接收对象中: 100% (3/3), 完成.

这里我们使用来自 Junit 5 Sample 中的 Maven 示例来尝试 CI。

$ cd sample
$ wget https://github.com/junit-team/junit5-samples/archive/master.zip
...
$ unzip master
$ mv junit5-samples-master/junit5-jupiter-starter-maven/* .
$ rm master.zip
$ rm -Rf junit5-samples-master

接下来创建如下内容的文件，命名为 .gitlab-ci.yaml

stages:
  - scan
  - build
job unit:
  stage: scan
  tags:
    - maven
  script:
    - mvn test

Git 添加并提交，返回浏览器，查看项目首页，会发现多出一行内容：

这表示项目的 CICD 正在运行。稍候片刻，浏览 root/sample/pipelines，会看到执行的 Pipeline 列表，我们最近的提交，Pipeline 结果已经显示为成功，点击后能够看到每个 Job 的执行记录：

如果我们修改一下测试案例 src/test/java/com/example/project/CalculatorTests.java，把其中的 34 行修改为 1011 或者其它的错误结果，就会看到测试失败的情况。

如果新建分支，并在分支中修复测试案例的话，会在 MR 中看到单元测试的结果，帮助管理员判断 Merge Request 的合并请求是否合理：

Gitlab 的部署

Sun, 05 May 2019 00:00:00 +0100

Gitlab 提供了多种部署方式，包括 Docker、Kubernetes 和裸金属上直接安装等。

Gitlab 的容器支持

Thu, 13 Jun 2019 00:00:00 +0100

身处容器时代，Gitlab 自然也提供了容器方面的支持，除了在 CI 中进行镜像构建之外，还提供了镜像库服务，此外也有 Kubernetes 插件用来在 Kubernetes 上进行部署。

使用 SonarQube 进行代码扫描

Thu, 06 Jun 2019 00:00:00 +0100

Gitlab 提供了基于 Code Climate 的代码质量评估功能，这一功能是通过 dind（Docker in Docker）方式运行的，在 Kubernetes 环境中、尤其是托管集群中，这种方式不太合适，还好还有一个替代方案：Sonarqube，通过在 .gitlab-ci.yml 中的设置，可以使用 Sonarqube 对代码进行扫描，接收到 Commit 之后，Sonarqube 会生成针对提交的代码质量提示，如图所示：

过程也并不复杂，简单的部署一个 SonarQube 服务，并在 Gitlab CI 中调用即可。

配置 Gitlab

这个步骤很简单，只要打开页面 profile/personal_access_tokens，新建 Token 备用即可。

启动 Sonarqube

在 Kubernetes 环境中启用一个简单的 Sonarqube 服务器是很方便的，具体说明可以参看官方 Docker 镜像的说明，这里有几个重点：

数据：该镜像内置 H2 存储，在生产环境中使用自然是不合适的，可以通过环境变量，使用外部的 MySQL 或者 PostgreSQL 服务器。
持久化：该镜像的数据目录为 /opt/sonarqube/，下面的 data、logs、conf 和 extensions，都是需要接入 PVC 进行持久化存储的。（就算只是测试，因为安装插件需要重启，因此也需要提供持久化支持）
权限：该镜像主进程是使用 999 的组 ID 运行的，因此需要进行配置。
后续内容所用插件目前还无法支持 SonarQube 7.7，因此此处使用的是 7.6 版本。

总结以上几点，列出代码中需要注意的内容：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: sonarqube
  labels:
    app: sonarqube
spec:
...  
  template:
    metadata:
...
    spec:
      securityContext:
        fsGroup: 999
      containers:
      - name: sonarqube
        image: "sonarqube:7.6-community"
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 9000
        volumeMounts:
        - name: sonar-ext
          mountPath: /opt/sonarqube/extensions
        - name: sonar-data
          mountPath: /opt/sonarqube/data
        - name: sonar-log
          mountPath: /opt/sonarqube/logs
        - name: sonar-conf
          mountPath: /opt/sonarqube/conf
...

配置 Sonarqube

SonarQube 启动之后，使用缺省用户名和密码（admin/admin）登录之后，首先安装 Java 语言插件：

在 /account/security/ 修改密码。
前往 /admin/marketplace 安装 SonarJava 插件。
打开路径 /admin/system，重启服务。

接下来是手工安装 Gitlab 插件：

使用 kubectl exec -it 进入 SonarQube 的 Pod 中。
进入 /opt/sonarqube/extensions/plugins 路径，下载插件
重启 Sonarqube。

插件安装完成之后，/projects/create 创建新项目，选择 java -> maven，最终会出现如下提示：

其中包含了后续步骤所需要的 Token。

配置 Gitlab 插件

打开 admin/settings?category=gitlab。
填写 GitLab url 以及 GitLab User Token。
保存。

配置项目 CI

这部分相当简单的一行 Maven 命令，例如

stages:
  - test
  - scan
...
Sonar:
  stage: scan
  tags:
    - maven
  script:
    - mvn --batch-mode verify sonar:sonar -Dsonar.host.url=https://sonar.microservice.xyz -Dsonar.login=cd387c80d1d40b24c1000b9982778ecef572795c -Dsonar.projectKey=sam -Dsonar.gitlab.project_id=$CI_PROJECT_ID -Dsonar.gitlab.commit_sha=$CI_COMMIT_SHA -Dsonar.gitlab.ref_name=$CI_COMMIT_REF_NAME

这里的关键参数：

sonar.host.url：Sonarqube 的地址。
sonar.login：Sonarqube 配置新项目时生成的 Token
sonar.projectKey：Sonarqube 新项目生成的 ID。

完成上述修改之后，就可以提交你的 Java 代码，看看 Sonarqube 在 Commit 下使用评论方式发表的代码分析结果。

附录

插件项目地址：https://github.com/gabrie-allaigre/sonar-gitlab-plugin/

在 Kubernetes 集群中安装 Gitlab

Sun, 05 May 2019 00:00:00 +0100

先决条件

在 Kubernetes 中的安装，自然需要一个可以运行和管理的 Kubernetes 集群，首先创建一个 Namespace 用于 Gitlab 的安装运行：

$ kubectl create ns gitlab
namespace/gitlab created
$ kubens gitlab
Context "mediumlab" modified.
Active namespace is "gitlab".

同时还要求该集群有如下能力：

外网 Loadbalancer 支持
镜像拉取
Helm 访问
StorageClass

Helm 仓库

Gitlab 官方提供了 Helm 仓库，添加地址之后就可以进行安装了：

$ helm repo add gitlab https://charts.gitlab.io/
"gitlab" has been added to your repositories

Helm 安装一般有两种方式：

helm install：需要集群端安装 Tiller，直接完成安装。
helm template：无需 Tiller 支持，用于生成最终的 YAML 安装文件。

这里为了使用方便，我们选择第二种，生成模板的方式。

TLS

为了提供 HTTPS 服务，不可避免的要使用 tls 的相关设置，Gitlab 给出了几个选项，本文使用两种：

自行提供泛域名证书

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...
...Successfully got an update from the "gitlab" chart repository
...Successfully got an update from the "stable" chart repository
$ helm fetch --untar gitlab/gitlab
$ helm template gitlab \
--namespace gitlab \
--name core \
--set global.edition=ce \
--set certmanager.install=false \
--set global.ingress.configureCertmanager=false \
--set global.ingress.tls.secretName=xyz \
--set global.hosts.domain=microservice.xyz \
--set gitlab-runner.install=false > gitlab-install.yaml

上面列出的几个开关，解释如下：

global.edition：Gitlab 分为 CE（社区版）和 EE（企业版）两个版本，这里仅涉及 CE 版本。
certmanager.install：使用固定证书，无需 certmanager。
global.ingress.tls.secretName：不用 certmanger 配置 Ingress。
global.hosts.domain：主机域名，这里给出的是一个根域名，后续会生成形如 gitlab.microservice.xyz、registiry.microservice.xyz 形式的子域名。
gitlab-runner.install=false：后续步骤中会单独安装 runner。
global.ingress.tls.secretName=xyz：用于保存我们的泛域名证书。

cert-manager + letsencrypt

$ helm template gitlab \
--namespace gitlab \
--name core \
--set global.edition=ce \
--set global.hosts.domain=microservice.rocks \
--set certmanager-issuer.email="xampal@gmail.com" \
--set gitlab-runner.install=false

这个参数很简单：

global.hosts.domain：根域名。
certmanager-issuer.email：签发者证书。

安装

用上述命令生成的安装清单，使用 kubectl 即可完成安装。

$ kubectl apply -f gitlab-le.yaml
...
poddisruptionbudget.policy/gitlab-gitaly created
poddisruptionbudget.policy/gitlab-gitlab-shell created
...

完成动作之后，可以通过 ingress、pods 的情况查看启动情况：

$ kubectl get ing -w
NAME            HOSTS                         ADDRESS   PORTS     AGE
core-minio      minio.microservice.rocks                80, 443   23s
core-registry   registry.microservice.rocks             80, 443   23s
core-unicorn    gitlab.microservice.rocks               80, 443   24s

启动完成应该有几个结果：

svc/Ingress 获得了地址。
Pod 运行。
PVC 全部绑定。

接下来就可以使用命令获取 root 密码：

$ kubectl get secret core-gitlab-initial-root-password -ojsonpath='{.data.password}' | base64 --decode ; echo
O3ewqaXE...NjCTYVktYghmkodF0j1c

初始化

输入 SSH 公钥

浏览器打开 /profile/keys，在其中输入公钥内容即可。

关闭 Auto DevOps

浏览器打开 /admin/application_settings/ci_cd，取消其中的 Default to Auto DevOps pipeline for all projects。

Gitlab 持续集成

Sun, 05 May 2019 00:00:00 +0100

Gitlab 除了基本的版本管理功能之外，还提供了很有用的持续集成能力，简单的在项目根目录中编写一段 .gitlab-ci.yml，就能够让 Gitlab 按照其中的指示完成持续集成的工作。

Gitlab CI/CD 是 Gitlab 的一个组件，它利用 Gitlab Runner 来执行具体的构建任务。

View Secret

Tue, 02 Jul 2019 13:01:00 +0800

简介

这个插件可以方便的查看 Kubernetes 中的 Secret 内容。

该插件中除了明确要求的 jq 依赖之外，还要求 bash 版本高于 4.0。

基本用法

$ kubectl view-secret default-token-2m68w
Multiple sub keys found. Specify another argument, one of:
-> ca.crt
-> namespace
-> token
$ kubectl view-secret default-token-2m68w namespace
default
$ kubectl view-secret default-token-2m68w token
eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4tMm02OHciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWN
...

参考链接

项目地址：https://github.com/ahmetb/kubectl-extras

Open Service

Tue, 02 Jul 2019 12:08:00 +0800

简介

这个插件的用途很是简单：在浏览器中打开指定 Service，和 kubectl 的端口转发功能类似，可以协助进行一些简易的调试。

基本用法

打开指定服务

$ kubectl open-svc httpbin
Starting to serve on 127.0.0.1:8001
Opening service/httpbin in the default browser...

浏览器会打开一个网址：http://127.0.0.1:8001/api/v1/namespaces/default/services/httpbin:http/proxy/。其中展示了 httpbin 服务的页面内容。

参考链接

项目地址：https://github.com/superbrothers/kubectl-open-svc-plugin/

Ingress Nginx

Fri, 28 Jun 2019 20:50:00 +0800

简介

这个组件由 Nginx Ingress Controller 项目官方提供，可以在控制台和 Nginx Ingress Controller 进行交互。

基本用法

安装 Nginx Ingress Controller

# 部署 Deployment
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
namespace/ingress-nginx configured
configmap/nginx-configuration created
...
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/cloud-generic.yaml
service/ingress-nginx created

查看 Ingress 后端服务

kubectl ingress-nginx backends

[
  {
    "name": "upstream-default-backend",
    "port": 0,
    "secureCACert": {
      "secret": "",
      "caFilename": "",
      "pemSha": ""
    },
    "sslPassthrough": false,
    "endpoints": [
      {
        "address": "127.0.0.1",
        "port": "8181"
      }
    ],
    "sessionAffinityConfig": {
      "name": "",
      "cookieSessionAffinity": {
        "name": ""
      }
    },
    "upstreamHashByConfig": {},
    "noServer": false,
    "trafficShapingPolicy": {
      "weight": 0,
      "header": "",
      "headerValue": "",
      "cookie": ""
    }
  }
]

列出当前的 Ingress 资源

这个功能和 kubectl get ing -o wide 类似：

$ kubectl ingress-nginx ingresses
INGRESS NAME   HOST+PATH                    ADDRESSES        TLS   SERVICE    SERVICE PORT   ENDPOINTS
flask          flask.whitehorse.com/      139.67.22.123      YES   flaskapp   80             2
flaskapp       flaskapp.whitehorse.com/   139.67.22.123      NO    flaskapp   80             2
$ kubectl get ingress -o wide
NAME       HOSTS                       ADDRESS          PORTS     AGE
flask      flask.whitehorse.com      139.67.22.123   80, 443   129m
flaskapp   flaskapp.whitehorse.com   139.67.22.123   80        152m

获取当前 Ingress Controller 的运行配置

$ kubectl ingress-nginx conf

# Configuration checksum: 17417893439548704315

# setup custom paths that do not require root access
pid /tmp/nginx.pid;

load_module /etc/nginx/modules/ngx_http_modsecurity_module.so;

daemon off;

worker_processes 2;
...

其它几个有用的命令

获取特定主机名所使用的 TLS 证书：kubectl ingress-nginx certs --host flask.whitehorse.com
读取 Ingress 日志：kubectl ingress-nginx logs
Ingress Controller 信息：kubectl ingress-nginx general kubectl ingress-nginx info

参考链接

Nginx Ingress Controller：https://kubernetes.github.io/ingress-nginx/deploy

Kubesec Scan

Fri, 28 Jun 2019 20:50:00 +0800

简介

使用 kubesec.io 提供的功能对集群进行扫描，得到安全相关的问题以及对应的建议。

基本用法

kubectl kubesec-scan [resource-type] [-n namespace] <resource-name>

例如：

$  kubectl kubesec-scan daemonset -n kube-system cilium
scanning daemonset cilium in namespace kube-system
kubesec.io score: -44
-----------------
Critical
1. containers[] .securityContext .privileged == true
Privileged containers can allow almost completely unrestricted host access
2. .spec .hostNetwork
Sharing the host's network namespace permits processes in the pod to communicate with processes bound to the host's loopback adapter
3. .spec .volumes[] .hostPath .path == "/var/run/docker.sock"
Mounting the docker.socket leaks information about other containers and can allow container breakout
-----------------
Advise1. containers[] .securityContext .runAsNonRoot == true
Force the running image to run as a non-root user to ensure least privilege
2. containers[] .securityContext .capabilities .drop
Reducing kernel capabilities available to a container limits its attack surface
3. containers[] .securityContext .readOnlyRootFilesystem == true
An immutable root filesystem can prevent malicious binaries being added to PATH and increase attack cost
4. containers[] .securityContext .runAsUser > 10000
Run as a high-UID user to avoid conflicts with the host's user table
5. containers[] .securityContext .capabilities .drop | index("ALL")
Drop all capabilities and add only those required to reduce syscall attack surface

参考链接

项目地址：https://kubesec.io/

Bulk Action

Fri, 28 Jun 2019 07:06:00 +0800

简介

顾名思义，Bulk Action 是一个用于进行批量操作的插件。它使用 kubectl bulk <resourceType> [<parameters>] [action] [<fields>] 形式的命令，对指定资源的字段进行批量操作。

这个插件是使用 Shell 脚本通过大量的 grep、sed 完成操作的，对完整资源并无认识，因此操作还是具有一定的危险性的，请慎重使用写操作。

基本用法

get

这个命令用于读取特定对象的指定字段值。

例如获取所有 Deployment 中的特定字段的内容：

$ kubectl bulk-action deploy get image
image fields are getting
image: dustise/flaskapp
image: dustise/flaskapp
- image: dustise/sleep
- image: dustise/sleep

上面的输出内容中，也能很清晰的分辨出 sh 的操作痕迹。推测 labels 这种字段就无法获取了：

$ kubectl bulk-action deploy get labels
labels fields are getting
labels:
labels:
...

list

这个命令是 bulk-action 的缺省操作，用 yaml 的形式列出所有指定类型的资源。

create

根据目前的资源，经过一定的替换之后生成新资源。

例如复制一个 Deployment：

$ kubectl bulk-action deploy create name sleep-v2 sleep-v3
creating new resource with changing name: sleep-v2 to name: sleep-v3 for all  deploy
deployment.extensions/sleep-v3 created
Error from server (AlreadyExists): deployments.extensions "flaskapp-v1" already exists
Error from server (AlreadyExists): deployments.extensions "flaskapp-v2" already exists
Error from server (AlreadyExists): deployments.extensions "sleep-v1" already exists

前面说过，这个工具的操作是通过 grep sed 等完成的，因此这里的情况就比较有趣：sleep-v2 被替换生成新的 Deployment，其它 Deployment 不包含这段文本，因此无效。

delete

选择指定资源执行删除操作，例如删除所有的 Service。

这个操作相当危险。这里有个 bug，可以 mv ~/.krew/bin/kubectl-bulk_action ~/.krew/bin/kubectl-bulk 来纠正。

update

和 Create 类似，不过这里调用的是 kubectl replace

结论

古怪的功能，危险的操作。非常不建议采用。

参考链接

项目地址：https://github.com/emreodabas/kubectl-plugins

Access Matrix

Sun, 23 Jun 2019 22:23:00 +0800

简介

Access Matrix 插件针对 RBAC 设计，用于查询和展示当前集群的 RBAC 设置。

基本用法

--as：查询指定用户身份的访问能力
--sa：查询指定 ServiceAccount 的访问能力
--namespace：把查询范围限定在特定命名空间
--verb：根据动词进行查询，可以指定多个，用逗号分隔，例如 get,watch,patch

参考链接

项目地址：https://github.com/corneliusweig/rakkess/blob/v0.4.0/doc/USAGE.md#usage

Gitlab 的开发流程支持

Sat, 22 Jun 2019 00:00:00 +0100

Gitlab 的管理范围不仅仅是源码，它还提供

构建 Docker 镜像

Sun, 16 Jun 2019 00:00:00 +0100

有了 Gitlab CI 的脚本能力，又有容器镜像仓库的支持，自然的一个想法就是，在 Gitlab 上构建容器镜像，并推送到镜像仓库之中。

常见的镜像生成流程

生成执行文件（JAR/PHP/PY 等等）
将执行文件和 Dockerfile 等支持文件加入到镜像目录
构建指定 Tag 的镜像
登录镜像库
推送镜像

相对于在单一服务器执行这些过程的情况，在 Gitlab 环境下主要有两个小麻烦：

在不同的 Runner 之间如何传递文件。
如何在以 Pod 形式运行的 Runner 中构建镜像并完成推送。

跨 Runner 的文件共享

Gitlab 提供了两种方式的文件共享方式，用于在不同 Runner 之间传递文件。

Cache：用于在构建过程中传递一些中间文件，无需长久保存，例如下载的依赖文件。
Artifact：构建过程生成的交付目标，需要保存一定时间，例如生成的 JAR、测试报告等交付文件。

这里我们准备使用 Artifact 的方式将 JAR 转发给 Docker 构建过程。在构建环节中简单加入这一字段即可，例如：

jar:
  stage: build
  tags: 
    - maven
  script:
    - mvn package
  artifacts:
    paths:
      - target/*.jar

这个环节执行后，会在脚本执行之后，搜集指定目录的文件，上传到 Gitlab 的共享空间，并 Pipeline 页面生成下载链接，如下图所示：

这里生成的 JAR 文件将在后续用来构建 Docker 镜像。

在 Pod 内构建 Docker 镜像

Docker 提供了一个 dind 镜像，意思就是“Docker in Docker”。但它使用的是使用 EntryPoint 启动守护进程的方式来完成对 Docker 的支持，而 Runner 启动时，会被替换入口函数，因此这里决定采用 IMG 工具来进行构建。

要使用 IMG，首先需要运行它的 Runner，这里偷懒使用 Alpine 镜像，后续在 CI 脚本中直接安装 IMG：

#!/bin/sh
helm template gitlab-runner \
--name img \
--set gitlabUrl="https://gitlab.microservice.xyz" \
--set runnerRegistrationToken="8xZSQH3PNqu3L2EgOT1PmjtKkep9yF3xjJfR0hxZ3nEvwMjeyuJxyb8zlqJMgEyx" \
--set rbac.create=true \
--set runners.image="alpine" \
--set runners.tags="img" \
--set runners.privileged=true

在启动 IMG Runner 之后，就可以更新我们的 .gitlab-ci.yml 了，加入如下内容进行构建：

docker:
  stage: image
  tags:
    # 仅使用带有 img 标签的 Runner
    - img
  script:
    # img 对 git 有依赖
    - apk add git
    # 安装 img，可以直接生成自己的镜像代替这个步骤
    - apk add img --repository=http://dl-cdn.alpinelinux.org/alpine/edge/testing
    # 准备构建 Docker 镜像
    - mkdir docker
    - cp target/*.jar docker
    - cp Dockerfile docker
    # 登录镜像库
    - img login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    # 构建镜像，变量列表和含义请参见附录
    - img build -t $CI_REGISTRY_IMAGE/sample:$CI_COMMIT_SHORT_SHA docker
    # 推送镜像
    - img push $CI_REGISTRY_IMAGE/sample:$CI_COMMIT_SHORT_SHA

修改完成后，提交更改到项目，触发 Pipeline，进入 /root/sample/pipelines 浏览构建过程列表，点击新启动的 Pipeline，可以查看各个环节的运行情况。

构建成功之后，进入项目的 container_registry 路径，可以看到该项目的镜像列表：

参考链接

Gitlab CI 变量列表：https://docs.gitlab.com/ce/ci/variables/
Cache vs Artifact：https://docs.gitlab.com/ee/ci/caching/#cache-vs-artifacts
IMG 项目：https://github.com/genuinetools/img

使用 Gitlab 的镜像仓库

Thu, 13 Jun 2019 16:00:00 +0100

Kubernetes 已经是事实标准，很多应用都会以容器镜像作为交付物。Gitlab 自然是不甘人后，也集成了容器镜像仓库的功能。

在使用 Helm 安装 Gitlab 时，设置 registry.enabled=true 即可启用镜像仓库功能。该功能启用之后，就可以用 Docker 客户端进行操作了。

我们使用项目 root/sample 作为示例：

# 登录
$ docker login registry.microservice.xyz

Username: root
Password:
Login Succeeded

$ docker tag alpine:latest registry.microservice.xyz/root/sample/alpine:latest

# 推送镜像
$ docker push registry.microservice.xyz/root/sample/alpine:latest
The push refers to repository [registry.microservice.xyz/root/sample/alpine]
7bff100f35cb: Pushed
latest: digest: sha256:3d2e482b82608d153a374df3357c0291589a61cc194ec4a9ca2381073a17f58e size: 528

镜像推送成功后，浏览项目的 registry 菜单，例如 https://gitlab.microservice.xyz/root/sample/container_registry，就会看到新推送的镜像：

关于镜像的路径，该页面上的说法是：允许存在三个层次，例如下列命名都是合法的：

registry.microservice.xyz/root/sample:tag
registry.microservice.xyz/root/sample/optional-image-name:tag
registry.microservice.xyz/root/sample/optional-name/optional-image-name:tag

其它路径的推送会被拒绝，例如：

$ docker tag alpine:latest registry.microservice.xyz/root/alpine:latest
$ docker push  registry.microservice.xyz/root/alpine:latest
The push refers to repository [registry.microservice.xyz/root/alpine]
7bff100f35cb: Preparing
denied: requested access to the resource is denied

MCP 是一座桥

Sat, 15 Mar 2025 10:55:23 +0800

前言

前两天刘老师吐了个槽，印象里是个问句：大家猜猜 KCD 为什么是 KCD？我觉得问得挺好的，所以作为 Kubernetes 老饼一张，我今天也来聊一点 AI 相关的事。

ChatGPT 横空出世之后，一直还是保持一点关注的，应该也交了几百刀的 AI 税了。除了聊天玩之外，也尝试使用流行的大模型解决一些实际问题，这一段时间以来，对于 AI 的有效使用大概归结成几种模式：

洗稿：当然不是抄袭的那种，我经常会将要发表的文字交给 GPT 类的东西，帮我查查错字，部分字句进行润色等。
翻译：传统翻译工具，包括 Deepl 在内，对于凌乱格式的文档（例如 PDF 中的胡乱换行、HTML 中的代码和标签等）都是力有不逮的，大模型对这种情况可以说是信手拈来。
辅助开发：函数级的代码、单元测试的编写，还有代码的阅读解释，甚至是一些配置参数的跟踪、特定功能的查找和调试，目前不管是 Windsurf 还是 Cursor 的效果都远超我的预期。
资料查询和整合：目前不管是 Search 还是 Research，都属于这个范畴。

除了这些工具类的东西，我有没有真的把大模型的能力融入到我的实际业务之中呢？你别说还真有。

运维老师傅

在运维现场，老师傅的最大价值之一就是：见多识广。然而在所有的主流大模型眼中，知名软件的日志信息毫无秘密可言。所以就随手写了个 Pipe2GPT 的小玩意，这东西现在一直在我的 Mac 和 Home Server 里呆着，随便遇到什么疑难 STDOUT/STDERR，Pipe 过去就行了。绝大多数情况下，能给出不弱于 StackOverflow 之类的结果，最重要的是说的的确是经过组织的人话，这点太重要了。

哄娃小工具

我有个工作流，效果是用广东话根据几个关键字生成童话故事，并使用方言 TTS 生成语音朗读给小朋友听——为保留粤语尽点绵薄之力？

调制和解调

其实跟翻译类似，让大模型的能力，对信息进行翻译和重整，使之生成新的信息模式，包括但不限于：

从自然语言的网页，例如公告、通知等信息中，提取规范化信息，交由其它系统进一步的处理。这种应用方式非常广泛，非常适合小打小闹的做一些趁手的搜集工作。
云 SDK 到 IaC：就拿虚拟机来说，同样的 4 核 8G，每个厂商都提供了多种机型可选，在 Terraform 的 Provider 之中，又有各种不同的表达。而有了大模型的辅助，反倒是可以轻松地在不同厂商 SDK 格式、不同的 IaC 代码之间进行转换。

…

然而这蹭热度的过程中，一直有些粗糙的感觉，应用侧和模型侧始终是泾渭分明、各自为战。训练练不起，对接呢，因为个人架构能力有限，每次都会因为需求的微小差异，进行大量的代码调整。尤其是和一些商业数据系统对接时，缺乏最佳实践的指导，由此产生草台班子的感觉会让人非常受挫。

MCP

前不久看到了 claude MCP，感觉这高冷的大模型开始有味道了。总算可以有办法，将“传统”服务和系统，跟各种大模型能够相对规矩的对接起来。

MCP 是 Model Context Protocol 的缩写。官方简介称：

模型上下文协议（MCP）是一种开放式协议，可实现 LLM 应用程序与外部数据源和工具之间的无缝集成。无论您是要构建人工智能驱动的集成开发环境、增强聊天界面，还是要创建自定义的人工智能工作流，MCP 都能提供一种标准化的方式，将 LLM 与它们所需的上下文连接起来。

目前已经提供了 TypeScript、Python、Java 和 Kotlin 的 SDK。

官方提供的架构图如下所示：

从核心上讲，MCP 遵循客户端-服务器架构，其中主机应用程序可以连接到多个服务器：

flowchart LR
    subgraph "Your Computer"
        Host["MCP 客户端(Claude, IDEs, Tools)"]
        S1["MCP Server A"]
        S2["MCP Server B"]
        S3["MCP Server C"]
        Host <-->|"MCP Protocol"| S1
        Host <-->|"MCP Protocol"| S2
        Host <-->|"MCP Protocol"| S3
        S1 <--> D1[("本地数据源 A")]
        S2 <--> D2[("本地数据源 B")]
    end
    subgraph "Internet"
        S3 <-->|"Web APIs"| D3[("远端服务 C")]
    end

MCP Hosts: 例如 Claude Desktop、集成开发环境 (IDEs) 或希望通过 MCP 访问数据的 AI 工具
MCP Clients: 与服务器建立一对一连接的协议客户端
MCP Servers: 轻量级程序，通过标准化的 Model Context Protocol 提供特定功能
本地数据源: 您计算机上的文件、数据库和服务，MCP 服务器可以安全访问它们
远程服务: 通过网络（如 API）可访问的外部系统，MCP 服务器能与之连接

从架构图中可以看到，MCP 定义了一种行为规范及其依赖的通信方式和对应的对象。LLM 客户端应用，作为 MCP Client，通过 MCP Server，和本地资源、外部服务连接起来，从而形成了完整的数据通路，让 MCP Server 所提供的数据和能力，直接在 LLM 客户端应用中得以使用。

MCP 中的核心概念包括用于描述原子能力的资源（Resource）和工具（Tool），用于复用提示词的（Prompt），以及能够控制文本生成的 Sampling 能力。除了这些能力之外，对于传输、安全、敏感信息等，也提出了相对完善的建议和最佳实践。因此虽然存在只能本地调用等短板，MCP 仍然不失为一个开拓 LLM 应用的一个非常有用的方向（不够好没关系，Who can who up 就是了）。

例子

官网文档里提供了一个天气预报的 Sample，这个例子很典型：从外部服务获取实时信息作为上下文在 LLM 中进行使用。这个例子分为三个部分：

服务端，提供了多种语言的开发方法，其中定义了 get_forcast 和 get_alert 两个 Tool
客户端：如何创建 Bot 并使用前面开发的 MCP 服务器
claude App 中如何使用 MCP Server。

例子中表达的主要“业务”就是在 LLM 中获取（美国）的天气信息，并结合 LLM 自有能力来响应用户需求。

提问时发生了什么？

客户端把问题发送给 Claude
Claude 分析可用的工具并决定使用哪一个
客户端通过 MCP 服务器执行所选工具
结果被发回给 Claude
Claude 根据响应内容回答问题

在 claude App 中启用 MCP

App 属性窗口中，Developer Tab 直接编辑 Settings，加入如下定义就可以得到：

{
    "mcpServers": {
        "weather": {
            "command": "uv",
            "args": [
                "--directory",
                "/ABSOLUTE/PATH/TO/PARENT/FOLDER/weather",
                "run",
                "weather.py"
            ]
        }
    }
}

启用 Server 之后，在 claude 聊天窗口输入框右下方会出现一个 🔨 图标，点击后就可以展示当前启用 MCP Server 所提供的 Tools 了。

生态

目前支持 MCP 的工具还是颇有一些的，官方列表：https://modelcontextprotocol.io/clients

官方列出的示例服务：https://modelcontextprotocol.io/examples

mcp.so 中列出了超过 2000 个 MCP Server。

展望

MCP 的整体实现是较为简洁的，这一方面方便参与，另一方面就是碎片化的前兆。目前来说仅能支持本地，很大程度上消减了可能的性能和安全性问题，但是对于自动化、实时性要求来说，MCP 目前体现的能力还是不很清晰的。

综上，跟社区的普遍思路不太一样，个人认为 MCP 作为一个便宜（便宜坊的便宜）途径，在独占大模型环境是颇有吸引力的一种解决方案。

在 Argo workflow 中使用 OBS 进行制品传递

Tue, 11 Feb 2025 21:56:17 +0800

在所有的通用工作流中，都会有文件传递的需求，Argo workflow 中，可以通过对接外部存储来支持这一需求。下面就以华为云为例，展示一下对接对象存储的过程。

OBS 侧配置

首先在 OBS 服务中创建一个存储桶，并在控制台的用户->我的凭证->访问密钥模块中，创建一个访问密钥，并下载凭据文件，凭据文件格式大致如下所示：

User Name,Access Key Id,Secret Access Key
"myusername",Y9C3WCABCDEFG,6bHX5eHIJKLMN

Argo workflow 配置

使用文件中的 Access Key 和 Secret Access Key ，在Workflow 所在的 Namespace 中创建 Kubernetes Secret。例如：

$ kubectl create secret generic s3-secret \
    --from-literal accessKey=Y9C3WCABCDEFG \
    --from-literal secretKey=6bHX5eHIJKLMN
...

接下来需要修改 Argo workflow 的配置文件，加入对制品的支持内容：

  artifactRepository: |
    archiveLogs: true
    s3:
      endpoint: obs.[Region ID].myhuaweicloud.com
      bucket: [Bucket Name]
      region: cn-north-4
      insecure: false
      keyFormat: "my-artifacts\
        /{{workflow.creationTimestamp.Y}}\
        /{{workflow.creationTimestamp.m}}\
        /{{workflow.creationTimestamp.d}}\
        /{{workflow.name}}\
        /{{pod.name}}"

      accessKeySecret:
        name: s3-secret
        key: accessKey
      secretKeySecret:
        name: s3-secret
        key: secretKey
      useSDKCreds: false

上面的配置大致解释一下：

在 OBS 中存储 Pod 日志
使用了华为云北京四 Region 的 OBS 端点。
需要引用前面创建的存储桶名称
使用加密方式进行访问
制品的存储路径模板为：my-artifacts/实例创建时间（年/月/日）/实例名称/步骤所在 Pod 名称/
Access Key 引用 Kubernetes Secret 中名为 s3-secret 的 accessKey 字段
Secret Key 引用 Kubernetes Secret 中名为 s3-secret 的 secretKey 字段

将上述内容加入 Argo workflow 所在命名空间的 workflow-controller-configmap。

启动工作流

尝试启动一个使用制品能力的工作流，清单内容来自https://argo-workflows.readthedocs.io/en/latest/walk-through/artifacts/。

这个流程模板中定义了两个工步：

生成制品

...
outputs:
  artifacts:
  # generate hello-art artifact from /tmp/hello_world.txt
  # artifacts can be directories as well as files
  - name: hello-art
    path: /tmp/hello_world.txt

上述代码中，将 /tmp/hello_world.txt 内容作为制品，并命名为 hello-art。

读取制品

inputs:
  artifacts:
  # unpack the message input artifact
  # and put it at /tmp/message
  - name: message
    path: /tmp/message

这段代码则是获取输入中名为 message 的制品，并解压到 /tmp/message 路径下。

执行时候，用 {{steps.generate-artifact.outputs.artifacts.hello-art}} 方式引用生成的制品。

执行

使用 Argo CLI 启动流程后，会看到类似如下的输出：

Name:                artifact-passing-mkn57
Namespace:           default
ServiceAccount:      argo-executor
Status:              Succeeded
...
STEP                       TEMPLATE                 PODNAME                                                    DURATION  MESSAGE
 ✔ artifact-passing-mkn57  artifact-example
 ├───✔ generate-artifact   hello-world-to-file      artifact-passing-mkn57-hello-world-to-file-551171166       8s
 └───✔ consume-artifact    print-message-from-file  artifact-passing-mkn57-print-message-from-file-1735545326  8s

这时如果返回 OBS 面板，会看到存储桶中，按照前面的路径规则存储了文件以及相关的日志（*.log）。

其他制品相关功能

覆盖仓库配置

前面我们在 Workflow Controller 配置文件中的配置，适用于单租户场景；多租户场景下，还可以通过 artifactRepositoryRef 方式，让每个流程可以使用自己的制品配置（https://argo-workflows.readthedocs.io/en/latest/artifact-repository-ref/）。

首先使用 Configmap 定义多个存储对接的参数，例如：

apiVersion: v1
kind: ConfigMap
metadata:
  # If you want to use this config map by default, name it "artifact-repositories". Otherwise, you can provide a reference to a
  # different config map in `artifactRepositoryRef.configMap`.
  name: my-artifact-repository
  annotations:
    # v3.0 and after - if you want to use a specific key, put that key into this annotation.
    workflows.argoproj.io/default-artifact-repository: default-v1-s3-artifact-repository
data:
  default-v1-s3-artifact-repository: |
    s3:
...
  v2-s3-artifact-repository: |
...

这段 YAML 中，提供了几个信息：

如果想要默认使用这个 Configmap 定义制品仓库，可以将其名称设置为 artifact-repositories。
如果不是默认，就需要在 artifactRepositoryRef.configMap 中显示定义 Configmap 名称。
v3.0 以后，可以用 workflows.argoproj.io/default-artifact-repository 注解定义这个 Configmap 中的默认仓库定义
data 字段定义了两个制品仓库。

然后可以在 Workflow 中引用：

spec:
  artifactRepositoryRef:
    configMap: my-artifact-repository
    key: v2-s3-artifact-repository

垃圾回收

在 Workflow 的 spec.artifactGC 中，可以定义 Garbage Collection 的策略。可选策略包括 OnWorkflowCompletion 和 OnWorkflowDeletion。

存储驱动能力列表

除了 S3 之外，目前 Argo Workflow 支持的存储驱动能力如下：

(https://argo-workflows.readthedocs.io/en/latest/configure-artifact-repository/)

Name	Inputs	Outputs	Garbage Collection	Usage (Feb 2020)
Artifactory	Yes	Yes	No	11%
Azure Blob	Yes	Yes	Yes	-
GCS	Yes	Yes	Yes	-
Git	Yes	No	No	-
HDFS	Yes	Yes	No	3%
HTTP	Yes	Yes	No	2%
OSS	Yes	Yes	No	-
Raw	Yes	No	No	5%
S3	Yes	Yes	Yes	86%

Argo Workflow 中的卸载和归档

Mon, 16 Dec 2024 23:38:57 +0800

卸载

Argo workflow 使用 CR 方式来保存工作流的运行状态，众所周知 ETCD 有一个请求大小的限制：1MB，也就是说，如果我们的 Workflow 对象 YAML 尺寸大于 1MB，超出了 ETCD 限制，就无法正常保存了。这种场景最常见于对大量目标进行循环的情况下，作为一个成熟的工作流系统，Argo workflow 自然是考虑到这方面的限制，提供了称为卸载（Offload）的方式，用于处置超大尺寸的工作流。

简单来说，在遇到超大工作流时，Argo Workflow 会对其 status.nodes 字段进行压缩，然后保存到 ETCD 中，当需要查询时，会先从 ETCD 中查询出压缩后的数据，再进行解压，从而避免了 ETCD 的限制。如果压缩仍然无法满足这一要求，Argo workflow 会将它保存到数据库中。

那么什么才是“超大”呢？Argo workflow 中，默认 1024*1024 为超大，但是我们可以通过修改 Workflow 控制器中的 MAX_WORKFLOW_SIZE 环境变量来改变这个值。为了测试方便，我们将环境变量修改为 10240，也就是 10KB。

为了测试方便，我们选用 Hello 插件来进行测试，使用之前首先要启用这个插件：

从 https://github.com/argoproj-labs/argo-workflows-hello-executor-plugin 获取代码
kubectl apply -f hello-executor-plugin-configmap.yaml 即可启用该插件。

接下来编写一个最小的 Workflow：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: little-
spec:
  entrypoint: main
  templates:
  - name: main
    steps:
    - - name: item
        template: atom
        withSequence:
          count: "5"
  - name: atom
    plugin:
      hello: { }

提交之后，看一下这个工作流的尺寸：

$ kubectl get wf little-xbg5g -o yaml | wc -c
    4549

只有 4K 多一点，不会触发压缩，如果查看这个 YAML，会看到里面的 Nodes 情况。那么我们将循环次数提高到 50 会发生什么？

...
  generateName: bigger-
spec:
...
    - - name: item
        template: atom
        withSequence:
          count: "50"
...

提交运行后，我们会发现，这个 WF 对象的 status.nodes 节点不见了，取而代之的是 status.compressedNodes，其中包含了一串编码内容，如果用 base64 -d | gunzip 处理后，就会看到 status.nodes 的内容了。

如果工作流再大一些呢？例如我们把循环次数放大到 500：

...
  generateName: huge-
spec:
...
    - - name: item
        template: atom
        withSequence:
          count: "50"
...

Argo workflow 提交直接会出错：workflow is longer than maximum allowed size. compressed size 18191 > maxSize 10240Tried to offload but encountered error: offload node status is not supported，也就是说，经过压缩之后，还是超出了最大限制，尝试卸载，结果失败了。那么如何启用卸载呢？

Wrokflow Controller 有一个可选的 Configmap，其中包含对持久化卸载的选项，例如我这样设置的：

apiVersion: v1
data:
  persistence: |
    connectionPool:
      maxIdleConns: 100
      maxOpenConns: 0
      connMaxLifetime: 0s
    nodeStatusOffLoad: true
    mysql:
      host: argo-mysql.default
      port: 3306
      database: argo
      tableName: argo_workflows
      userNameSecret:
        name: argo-mysql-cred
        key: user
      passwordSecret:
        name: argo-mysql-cred
        key: password
kind: ConfigMap
metadata:
  name: workflow-controller-configmap
  namespace: argo

提交之前首先要准备数据库：

在 argo 命名空间中创建一个 Secret 备用，其中包含两个字段，分别是 MySQL 的用户名和密码。
创建一个 MySQL Database，命名为 argo，并且让前面 Secret 中声明的凭据可以访问。
在配置中引用前面创建的 Secret。

提交 Configmap 之后，重启 Workflow Controller。再次提交上述的工作流，可以看到工作流已经可以运行了。

成功后，使用 argo watch 命令是无法获取详情的，但是可以在 Argo Server 的 Web 界面上查看。

如果进入数据库，可以看到 argo_workflows 的 nodes 字段已经保存了完整的 Node 信息。

归档

虽然我们可以使用垃圾搜集策略来适时删除 Pod，但是 WF 对象始终存在，除了 kubectl get wf > backup.yaml，Argo workflow 有没有提供更好的归档能力呢？

启用数据库之后，就可以进行归档了，用法很简单，仍然从 Configmap 配置入手：

archiveTTL: 180d
archiveLabelSelector:
  matchLabels:
    workflows.argoproj.io/archive-strategy: "always"

archiveTTL 表示归档寿命，默认为 0，也就是用不删除，archiveLabelSelector 则是标签选择器，用于指定哪些工作流需要被归档。例如下面的 metadata：

metadata:
  generateName: backup-
  labels:
    workflows.argoproj.io/archive-strategy: "always"

提交工作流，运行完成后，使用 kubectl get wf 可以看到他的标签发生了变化：

labels:
    workflows.argoproj.io/archive-strategy: always
    workflows.argoproj.io/completed: "true"
    workflows.argoproj.io/phase: Succeeded
    workflows.argoproj.io/workflow-archiving-status: Archived

此时查看数据库内容，可以看到 argo_archived_workflows 表中已经记录了这个工作流的信息。

Platform As A Runtime（PaaR）——超越平台工程

Thu, 12 Dec 2024 22:39:53 +0800

原文：Platform as a Runtime (PaaR) - Beyond Platform Engineering

作者：Aviran Mordo

我个人对平台工程非常有兴趣。Wix已经实施了十几年的平台工程——当然，在“平台工程”这个名词诞生之前就开始了。本文将介绍 Wix 工程团队在过去几年中部署和实施的一些项目，这些项目将平台工程提升到了一个新的水平。接下来我们将深入探讨一些新的平台项目，为我们的未来愿景提供一些见解。

提供一些背景信息，Wix 是一个领先的网站构建平台，拥有来自 190 个国家/地区的超过 2.4 亿注册用户（网站构建者）。我们的平台部署在全球 3 个地区的 20 个服务点。Wix 有 5,000 多名员工，其中约一半从事研发工作。因此，可以肯定地说，（软件）工程是我们工作的核心，也是我们业务价值的核心驱动力。

The need for speed

成功的软件企业，能够快速交付高质量代码。随着规模的不断扩大，挑战也接踵而来。随着公司的发展壮大，因为依赖性、存量代码和复杂性的增加，让软件的交付过程日趋缓慢。

计算机科学和（软件）工程诞生以来，就一直在涌现各种方法，用于对工作进行组织，从而实现更高的速度和质量。而持续交付、DevOps 和 Serverless 是目前的最新趋势。

随着方法论趋势的演进，我们的工具也随之变化。这些技术的目的，当然是为了让公司能够更快速地交付软件——初创科技公司的数量及其增长推动了这样的演进。为了支持这种增长，我们看到云托管/计算提供商的出现，它们可以快速访问庞大数据中心的服务器，成功地降低了运维开销。

随后出现了微服务理念，使公司能够更快地扩展规模并“更轻松”地维护其软件。最后，我们有了 Serverless，它消除了更多的开销和对服务器进行维护的需求。顾名思义，使用 Serverless，您就不再需要自行维护服务器。服务器扩容、服务机配置、Kubernetes 集群管理等问题不复存在，运维开销进一步被缩减。

微服务如何影响开发速度

如果从单体服务开始，那么事情相当简单。可以选用任何框架，利用任何工具。一切都能快速推进。

但是随着规模的扩张，服务数量开始膨胀，事情就开始变得复杂。系统和服务之间需要进行集成——RPC/REST、数据库、消息服务等开始出现在你的组件列表里。运维、测试和管理的工作越来越多。这时就需要框架了。

少量的微服务没什么问题。然而随着你的不断成长，微服务会越来越多。下图是 Wix 的微服务地图——每个矩形是一个微服务集群，这些连线代表了微服务之间的通信。

如你所见，越多的服务就需要越多的团队。微服务之间需要协调工作，因此需要考虑他们之间的共性——他们需要使用相同的“语言”，也就是使用相同的协议和接口。例如如何处理 Cookie 和安全性？怎么完成 RPC 调用？Http Header 和日志如何处理？

下图中的条目，列出了一个需要关注的问题的列表，这些内容重要，但不完整。

微服务架构的冰山一角

让我们看一个示例服务的分层。虚拟机是基础层。应用在容器内运行，其之上是微服务/应用程序框架——例如 JVM 世界中的 Spring、NodeJS 的 Express。然后，在此之上，构建可信环境框架，该层使所有底层服务能够以相同的方式进行通信。通过相同的协议，使用相同的 HTTP Header，使用相同的加密/解密算法，等等。这样，它们就可以被网络上的所有其他服务使用和信任。

软件工程师会在这些层的基础上工作。业务服务处于金字塔的顶端，这些服务代表的是公司实际销售给客户的业务价值。

对于我们工程师来说，这只是冰山一角。在我们处理业务逻辑代码之前，首先要处理它的整个底部部分。不幸的是，开销并没有到此为止。除了需要开发的实际产品功能之外，开发人员还需要考虑法规、业务和法律问题，例如 GDPR 合规性。这虽然不是实际销售的价值，但却是每个服务的必要内容。

这些介绍有些冗长，但它解释了开发大型系统的重要性。现在让我们喘口气，谈谈……

平台即运行时（PaaR）

通常会使用内部的框架或库来构建微服务，gRPC、Kafka 客户端、连接池、A/B 测试等内容都来自这些基础代码。但是，通过这种方法，最终得到的是一个分布式通用框架。在这种情况下，就需要频繁地更新所有微服务，以便让所有服务的版本保持兼容。

如何应对这种依赖开销呢？

一种方案是把构建时依赖修改为运行时依赖。但在 Wix，我们更进一步。除了我们之前提到的通信协议和合约之外，构建内部框架时还需要考虑其他问题。这些其他问题包括常见的业务流程、常见的法律问题（GDPR、PII 等）、常见的租户模型、权限、身份管理等。

因此，我们将所有这些业务问题和流程添加为运行时依赖项，最终得到平台即运行时 (PaaR).

添加到 PaaR 中的众多内容意味着什么？每个在 PaaR 中运行的微服务都会自动处理这些问题，而无需在每个服务中进行开发。例如在 GDPR 场景里，所有服务都会自动使用 GDPR 方式获取个人数据并在合适的时间“忘记”数据，从而节省每个服务宝贵的开发时间。

我们是怎样做到的？

首先从我们的 Serverless 平台开始。平台核心是 NodeJS，支持了整个应用程序框架。选择 Node.js 的原因——它轻量级，支持动态代码加载，并且简单易学。

第一步：我们将整个框架与 GRPC/REST/Kafka（包括发现服务）的集成层一起编码到 Node.js 服务器中，并使其成为“运行时服务器”。

这样一来，我们就拥有了一组具有相同功能的“运行时”服务器。

第二步：我们为数据服务添加了另一层，让开发人员可以轻松快速地连接数据库（运行时处理所有连接字符串、连接池、JDBC 等）。

我们最终得到的是一个“智能”容器，它可以处理入口流量，并将所有常见问题嵌入其中，但没有太多业务逻辑。

这两个步骤后，开发人员可以用运行时依赖的方式来构建业务逻辑，依赖项的代码不会和业务代码耦合在一起编译打包。

开发人员在本地完成开发之后，就可以准备进行部署了。在 Serverless 生态中，部署应用无需关注 Node.js 服务或者容器的细节，只需要部署 TypeScript 文件或包，平台将更新代码自动加载到平台的运行时。

运行时自带了注册发现能力，因此在进行服务间调用时，只需要声明调用目标，平台会自动提供匹配的客户端来完成对目标服务的调用。

这些交互都是通过运行时完成的，也就是说，真正的集成工作是在运行时完成的，因此集成测试的工作开销也减少了。

这种做法的好处是，只需部署业务代码，而不必将其与公共库和 Node.js 运行时捆绑在一起，这使得可部署的文件非常小（大小通常小于 100Kb）。

分离项目结构和部署拓扑

上文中描述的内容，和 Lambda 地行为是颇有些相似的。差异在于，Lambda 的框架和也是和可部署程序捆绑在一起的。但是如果我要加入新函数要怎么办呢？在 Lambda 中，需要新建一个实例，或者把新的函数添加到现有的实例中；而在我们的可信环境中，我们可以把多个函数运行在同一个进程里。简单说，我们可以用微服务或者函数的粒度进行开发，但是所有这些功能又可以用单体进程的方式来运行。当然，我们也可以把这些功能分离到平台中不同的主机上——像微服务一样。

不仅如此，我们还能用微服务或者单体的方式开发软件，并把软件的不同部分，部署到不同的平台主机上。

举个例子，假设我们有一个服务，它有两个服务端点：一个用来响应用户请求的 RPC 端点；还有一个用来监听 Kafka 主题。我们可以在同一个项目中开发这两个函数，沿着这个思路，开发者会认为这两个端点是是一体的，这些功能是同一个逻辑服务，但其实他们会被部署到不同主机上。

这样一来，这里的两个端点就有了不同的伸缩策略。在没有增加开发者心智负担和工作量的情况下，面向顾客的 RPC 函数和面向 Kafka 的两部分内容能够各自伸缩，却又完全无需进行重构和拆分。

在 Wix，函数的发布是轻松又高效的。开发者将函数推送到 Github 仓库后，新增代码只是一个小小的函数，只要个把分钟，新代码就能部署和启动运行了。

平台工程思维

那么我们收获了什么呢？

集成非常容易：开发人员能够简单的声明要调用的函数和微服务，就能够自动获得所需的客户端。
测试代码少：胶水代码无需进行集成测试
开发人员专注于业务逻辑的实现，开发和部署粒度非常小。
部署速度快：代码量小，无需框架公共库的打包工作
无需脚手架：集成工作都已经预先配置，并且开发人员用生命方式就可以引用。

未来愿景

接下来，我们应该如何利用现有资源并在此基础上进行构建呢？例如我们可以让不同的团队管理各自不同的运行时。只需要克隆环境就能完成这样的需求。这样一来，ecom 和 blog 团队都可以有各自不同的运行时集群，这种情况下，不同团队的代码就不会被推送到同一运行时。但是不同运行时之间的函数还是可以互相调用的。

在这种情况下会产生一个需求：根据运行时来优化函数之间的亲和性。假设我们有两个运行时，每个运行时都包含多个函数：

上图看到，函数 2 和 5 之间存在交互。他们在不同的运行时中运行，网络延迟会降低他们之间的通信效率。如果我们能让系统自动地把函数 5 部署到第一个运行时，函数 2 部署到第二个运行时，调用关系就会变成这样：

这样我们就跨过构建，直接在运行时完成函数的组织和优化，以此类推，我们能够形成一个跨网调用最少的高度优化的运行时环境。而现在我们只能把领域设计、开发环境跟运行时拓扑进行耦合（才能达成这样的效果）。

单一运行时才是未来

将运行时扩展到其他编程语言是个有吸引力的想法。依我看，要完成这一目的，不需要构建多语言系统，也不应该为特定技术堆栈多次构建相同的框架。我们需要的是能够支持任何语言的单一运行时

要实现这一目标，我们设想的方法是将整体框架一分为二：“Host”和“Guest”。Host 中包含运行时框架、服务集成和数据服务层；Guest 中包含的则是业务代码以及业务代码的集成能力。这样一来，只需要开发一次应用程序框架，而不是不断尝试在不同编程语言框架之中努力实现对等功能。这种方法的明显优势就是只要在 Host 上进行框架更新，无需跨语言的重复劳动。

缺点也是存在的——Guest 之间的调用是通过 Host 的跨进程通信来完成的。我们还在使用 GraalVM，试图在 Host 进程之间运行多个不同语言实现的 Guest。现在我们是通过两个不同的进程，简化了开发工作，得到了一个可用的系统。

当下进展

我们的开发人员很喜欢目前的工作，这标志着该方法的成功。方法的核心就是平台工程思维，在这种环境中，很多复杂问题变得简单。Wix 开发人员能在几小时内开发出从前需要开发几天甚至几个星期的东西。

从本质上来说，我们的平台工程超越了简单的开发人员门户，取而代之的是成熟的 PaaR，为开发运维工作降低了心智负担。

要了解更多信息，请观看：Beyond Serverless and DevOps。

在 Argo workflow 中使用插件减少并行 Pod 数量

Fri, 29 Nov 2024 21:41:22 +0800

在之前写过的使用 Argo workflow 调用公有云客户端软件实现运维过程的文章中，可以看到，使用 Argo workflow 的容器模板，简单的将既有运维能力容器化，就能使用 Argo workflow 对这些能力进行编排了。

不过近期一个测试中，遇到个小麻烦——在一个 With 循环里，我输入了 500 个任务，结果是 6 节点 CCE 集群爆满，流程卡住——集群规模的事情很简单，我直接将 Argo workflow 部署到 CCE Autopilot 集群中，随着流程启动，Auto pilot 集群非常给力，不到一分钟就扩容到了上百节点。然而新的问题出现了，Argo workflow 容器模板使用的镜像托管在 quay.io 上，我被限流了——无法拉取镜像，工作流自然也就无法执行了。

如果说必须要限流的话，Argo workflow 提供了多种机制，在不同粒度上对工作流的并发进行控制：

在模板中，使用 parallelism 参数，限制流程实例内的并发数。
在 Workflow Controller 的 Configmap（workflow-controller-configmap）中，使用 parallelism 或者 namespaceParallelism，在集群范围内，限制总体并发的流程数量。
模板中使用 synchronization，使用同样的共享锁的流程实例将会被有效限流。

不难看出，在有限集群的规模下，通过对并发的控制，以及垃圾回收策略的定义，都能有效的限制集群规模——毕竟上百节点是要花不少银子的。在这种情况下，还有一条路就是，使用执行插件。例如如下工作流：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: python-example-
spec:
  entrypoint: main
  arguments:
    parameters:
      - name: value
        value: "1"  
  templates:
    - name: main
      steps:
      - - name: evaluate
          template: evaluate
          arguments:
            parameters:
              - name: value
                value: "{{workflow.parameters.value}}"
          withSequence:
            count: "50"         
    - name: evaluate
      inputs:
        parameters:
          - name: value    
      plugin:
        python:
          expression: |
            {"sum": int(parameters["value"]) + 1}

这里使用 plugin.python 的方式引用了一个插件，执行时，循环了 50 次，提交后，我们会发现，这里只执行了一个 Pod：python-example-hlc5t-1340600742-agent，也就是说，这一个 Pod 承载了所有的 50 个任务。如何实现的呢？这里就要看看 Argo workflow 的插件机制了。

Argo workflow 默认是不启用插件的，要启用插件，需要给控制器加入环境变量：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: workflow-controller
spec:
  template:
    spec:
      containers:
        - name: workflow-controller
          env:
            - name: ARGO_EXECUTOR_PLUGINS
              value: "true"

重启后，就可以启用上面工作流引用的插件了，启用插件的方式很有意思，提交一个 Configmap 即可：

# This is an auto-generated file. DO NOT EDIT
apiVersion: v1
data:
  sidecar.container: |
    args:
....
kind: ConfigMap
metadata:
...
    workflows.argoproj.io/version: '>= v3.3'
  creationTimestamp: null
  labels:
    workflows.argoproj.io/configmap-type: ExecutorPlugin
  name: python-executor-plugin

这方式有点奇怪，Configmap 里面包含了一堆 Python 代码。以及似乎是 Sidecar 的容器定义。应用之后，就能够运行上述工作流了。

注意 Configmap 中的注释说明：这是一个自动生成的文件，哪里来的呢？

实际上，Argo workflow 插件是由 argo executor-plugin build 命令构建出来的，一个插件的原始文件主要包含三个部分：

插件清单（plugin.yaml）：这里实际上是对一个容器的定义，其中包含了容器镜像、资源使用等。
启动文件：一个命名为 server.* 的文本文件，可以是 Shell 或者 Python 脚本，他会在插件启动时被执行。
插件镜像：上述文本文件可能无法描述一些业务逻辑，因此，可以将二进制文件封装到镜像里，给启动文件调用。

例如前边用到的 Python 插件的 plugin.yaml：

kind: ExecutorPlugin
apiVersion: argoproj.io/v1alpha1
metadata:
  name: python
...
    workflows.argoproj.io/version: '>= v3.3'
spec:
  sidecar:
    container:
      command:
        - python
        - -c
      image: python:alpine
      name: python-executor-plugin
...

不难看出，这个定义和上边的 Configmap 是一致的。再看看 server.py：

import json
from http.server import BaseHTTPRequestHandler, HTTPServer


class Plugin(BaseHTTPRequestHandler):

    def args(self):
        return json.loads(self.rfile.read(int(self.headers.get('Content-Length'))))

    def reply(self, reply):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(json.dumps(reply).encode("UTF-8"))

    def unsupported(self):
        self.send_response(404)
        self.end_headers()

    def do_POST(self):
        if self.path == '/api/v1/template.execute':
            args = self.args()

            template = args['template']
            plugin = template.get('plugin', {})

            if 'python' in plugin:
                spec = plugin['python']

                # convert parameters into easy to use dict
                # artifacts are not supported
                parameters = {}
                for parameter in template.get('inputs', {}).get('parameters', []):
                    parameters[parameter['name']] = parameter['value']

                try:
                    code = compile(spec['expression'], "<string>", "eval")
...


if __name__ == '__main__':
    httpd = HTTPServer(('', 7984), Plugin)
    httpd.serve_forever()

上边的代码，不难看出，这里只是启动了一个简单的 Python HTTP Server，监听 /api/v1/template.execute 的 Post 请求，并对其进行处理。

上述的 YAML 和启动代码都编写完成之后，就可以使用 argo executor-plugin build 命令来构建 Configmap 了。

当然也可以使用自己定义的基础镜像。

Argo + KooCli 操作华为云资源

Tue, 15 Oct 2024 01:39:10 +0800

前面写过一篇使用 Argo Workflow 操作 AWS 资源的例子，今天要写的是类似的，在 Argo Workflow 中，使用 CLI 客户端操作华为云资源的办法。

华为云提供的 KooCLI 是一个命令行工具，其中提供了很多华为云的操作能力。要在 Argo Workflow 中使用 KooCLI，首先需要构建 KooCLI 的容器镜像，Dockerfile 如下：

FROM ubuntu:24.04
RUN apt-get update -y && apt-get install curl -y
RUN curl -sSL https://cn-north-4-hdn-koocli.obs.cn-north-4.myhuaweicloud.com/cli/latest/hcloud_install.sh -o ./hcloud_install.sh \
  && bash ./hcloud_install.sh -y \
  && yes | hcloud --help

WORKDIR hcloud

整个过程和官网的说明是类似的，这里我加了一行初始化操作：yes | hcloud --help，这是因为启动 hcloud 的时候，首先会弹出一个 License 界面，需要输入 yes 才继续。所以这里使用 yes 命令进行一个初始化。

容器镜像构造结束之后，就可以在 Argo Workflow 中使用 KooCLI 了。

这次测试使用的是 Argo Workflow 的 v3.5.11 版本。

简单粗暴上代码，在 https://gist.github.com/fleeto/7c70b58a6ee7bdb93494f94f77db7c20

上述代码有几个要点：

入参

在 spec.arguments.parameters 中，定义了 ak、sk 以及 region 三个参数，用于配置华为云的 AK、SK 以及区域。

  arguments:
    parameters:
    - name: ak
      value: "AKAKAK"
    - name: sk
      value: "SKSKSSK"
    - name: region
      value: "cn-north-4"

执行 KooCLI

在 list-ecs 步骤中，使用了前面构建的 KooCLI 镜像，用无配置方式，通过 hcloud ECS ListCloudServers 命令，获取到当前区域下的所有云服务器：

- name: list-ecs
  container:
    image: dustise/koocli:v0.0.2
    command:
    - hcloud
    args:
    - ECS
    - ListCloudServers
    - --cli-region={{workflow.parameters.region}}
    - --cli-access-key={{workflow.parameters.ak}}
    - --cli-secret-key={{workflow.parameters.sk}}

这一步骤中，我没有定义输出参数，这是因为在 Argo Workflow 中，可以使用 steps.[步骤名称].outputs.result 的方式，默认导出 STDOUT 内容，但是需要注意的是，这种方式最大支持 256kb 的内容。

还有一种方式就是把内容输出给文本文件，然后用如下形式声明：

outputs:
  parameters:
  - name: hello-param
    valueFrom:
      path: /tmp/hello_world.txt

KooCLI 输出的 JSON 中，可以使用 --cli-query 开关，使用 JMESPath 方式对结果进行整理，原始的输出格式大致如下：

{
  "servers": [
    {},]}

要想只输出 servers 数组，可以加入 --cli-query=servers 开关，就能输出只包含 servers 数组的内容了。

引用输出结果进行循环

这里使用了 withParam 语法，对 list-ecs 步骤的输出结果进行循环，每次循环，都会把当前循环的元素赋值给 item 变量，输出 item 变量的 id 属性。

循环变量里，我们使用了一个奇怪的表达式："{{=toJSON(jsonpath(steps.list.outputs.result, '$.servers'))}}"：

{{= 代表使用表达式进行运算。
使用 jsonpath 获得数组
toJSON 把对象编码为 JSON

注意，不同的 Argo workflow 版本，这一点不太一样，目前看到的官网讨论是：

3.4: {{=toJson(jsonpath(...))}}
3.5: {{=toJSON(jsonpath(...))}}
3.6: {{=jsonpath(...)}}

运行

argo submit 或者 kubectl create 执行之后，可以看到，KooCLI 用了一个容器进行查询，随后在循环中，每个示例都有一个对应的 Pod 执行 ECHO 任务。

用 Obsidian 有效应对日常工作

Wed, 02 Oct 2024 23:06:09 +0800

两三年前，因为信息安全方面的考虑，弃坑了 Notion 和 Craft，改为使用 Obsidian 进行日常工作的记录，随着工作内容的日渐散乱，原本围绕少量项目和单一知识体系构造的笔记方法，从记录效率、到检索能力都逐渐被破坏了。因此经过一段时间打磨之后，围绕着记录、浏览和检索三个功能特性，面向我的日常工作内容，借助一系列的插件，逐步调整了我的笔记方法。目前看来，这种用事件为核心的记录方法，在日常工作中表现出的效率，的确远远超过之前以天为单位的粗放方法。

场景

日常工作中，需要打开 Obsidian 进行记录的情况，主要有几个场景：

文件往来：这里说的文件，除了 Markdown 和 Office 三件套之外，还可能包括各种绘图、建模的存档，以及一些在线文档、代码仓、工单系统等。虽说在线文档是现在的主流，但是在面对的并行项目和工具都达到两位数，并且相互之间存在交叉的情况下，在线文档的各种网址本身也可能成为一种认知负担；更不要提“我早就发给过你”、“你从来就没发给过我”的常规战争了。
会议/沟通纪要：日常经常有些小会、小的讨论，其结论处在“有用、有意向，但是没有公示价值”的尴尬区间，可能需要进一步的深入讨论以及决策，这些鸡肋内容如果失去记录，可能就造成信息流的中断，对于其所属的更大的项目或者产品的决策过程，也会造成一定的损失。
即兴文档：一方面在工作范围之外，还是会有一些稍嫌杂乱的思索和摘抄；另一方面，在线交流过程中，会产生一些现场绘图、板书等也是需要记录的。

除了上述三种记录场景之外，更重要的是查询和展示，传统来说 Obsidian 通过文件夹、标签、搜索、（反向）链接和关系图谱对记录内容进行展示，这些方法的确可以显示出特定关注点的所有相关内容，但是通常会显得比较杂乱；除了这些之外，我们还希望有更丰富的查询和更规整的展示方式。

方法

综合上述场景化需求，我决定使用 Zettelkasten 的卡片记录法，结合 Dataview 查询来满足日常需求。

使用卡片快速记录

要使用卡片记录，首先要在配置->核心插件中，启用时间戳笔记生成器（Unique note creator）。功能启用之后，创建一个保存卡片的目录，例如 /Cards，然后打开这个选项，把这个目录设置为保存位置。如果有兴趣可以把时间戳格式设置成自己喜欢的样式。后续我们会针对模板进行更多工作，所以这里不会进行设置。

建立模板

在 Obsidian 中，模板用于设置常见的格式化内容。设置模版之后，只要用 插入模板 命令，就可以选择模版插入当前位置。

这里假设使用 /Templates 作为模板目录，可以在 配置->核心插件->模板 中设置目录。

在模板中，除了可以设置特定常用的文字、结构和内容之外，还可以使用 {{date}}、{{time}} 作为变量，在使用模板时自动写入当前日期和时间。

另外，为了便于 DataView 的检索，我们会使用 字段名:: 字段内容 的方式，为速记内容提供关系数据。

这里我根据上除的录入场景，为卡片设置了三种模板：

即兴写作

即兴写作其实不会有很多内容，我通常只会放置 标题::、关键字:: 和 内容 三个段落。另外为了在 Dataview 中方便检索，我会在模版第一行中使用 #卡片-即兴 的标签。

但是在 Obsidian 中，还有一个即兴写作的东西是 Excalidraw，他可不会管你什么 Tag 什么 Dataview，其实有两种方法在 Excalidraw 文件中进行标注：

在浏览窗格中，使用默认编辑器打开绘图，会看到绘图背后的 Markdown 文档，直接在前面的 --- 区间加入 Tag 或者 Dataview Field。
安装 MetaEdit 插件，直接在 Excalidraw 文件的右键菜单上就能看到加入 Tag 或者 Field 的选项。

沟通和会议

沟通和会议，主要关注的是时间、参与人、过程内容和关键结果，时间可以用前面提到的 {{date}}、{{time}} 自动填充，参与人我做成了字段。

涉及人的项目，我通常会用 [[人名]] 的方式，这样每个人都有自己的页面，一方面用反向链接查看每个人的所有相关项目，另一方面可以为这个人加入诸如联系方式、邮件、组织关系等的注释。注意：参与人:: 后面如果写入多个人名，Dataview 会认为这是一整个字符串，要形成数组方式，应该用 参与人:: [[张三]] 参与人::[[李四]] 的方式。

会议结论里通常会包含 TODO 项目，这里可以使用 Task 插件，形成待办列表。（后面的 Dataview 章节会介绍 Task 专属的视图）例如在 7 日之前联系张三：

- [ ] 会见 [[张三]] 修改诉讼方案 📅 2024-10-07

快速插入模版

因为前面没有给卡片设置缺省模版，所以新建卡片是空白的，这里选择模版再插入就有些麻烦了，因此我安装了 Hotkeys for templates，这个插件可以为每个模版设置快捷键，方便你夹着电话的时候快速构建内容。

文件往来

文件通常也是沟通的一种，不同的是要对文件进行处理，这里我主要借助的是 Custom Attachment Location 插件，在他的配置中，有一个 Location for New Attachments 的项目，可以设置把附件文件保存到当前笔记的相对目录下，例如我设置的是 ./assets_of_$filename，如果当前卡片是 202410011820，则黏贴进来附件会被保存到 assets_of_202410011820 目录里。

注意，需要开启 选项->文件与链接 中的 检测所有类型文件。

使用 Dataview 快速浏览

Dataview 使用一种特定的 DSL 来对 Obsidian 中的数据进行查询，前面一节创建的卡片会有些凌乱，因此我设计了几个视图，让工作变得清晰一些。

首页

使用 Home Page 插件实现，主要目的是跟踪 Task 列表，其中使用 Dataview 编写了两个简单的视图，分别显示未完成的任务和已完成的任务。Dataview 为 Task 插件定制的语法非常简单：

```tasks
not done
sort by due
```

展示未完成任务。

以及

```tasks
done
sort by done revferse
limit 10

展示最近十条已完成任务。

日记

可以使用在日记的模板里，使用变量和 Dataview 的语法，快速查询某一天的所有卡片。我的用法是，用三个不同的表格，展示每天的三种卡片。例如日记模板中，关于即兴记录：

```dataview
TABLE 标题,关键字
FROM (#卡片-即兴 and ("Cards")) or ("Excalidraw")
WHERE (file.day=date({{time:YYYY-MM-DD}}))
```

TABLE 这一行，表示会引用卡片中的 标题:: 和 关键字:: 字段。
FROM 子句，表示从 Cards 目录中带有 #卡片-即兴 标签的卡片中，或者从 Excalidraw 文件中，选择当天的卡片。
WHERE 中，要求文件日期等于 date({{time:YYYY-MM-DD}})。date 是 Dataview 的内置函数，负责把日期字符串转换成日期格式；而 {{time:YYYY-MM-DD}} 则是模板中的变量，会被替换成当前日期并进行格式化。

杂项

标签改名：日常记录中难免会忙中出错，记错标签；或者因为时间的推移，要求合并前面过度细分的标签，可以用 Tag Wrangler 插件实现这一功能。
隐藏附件文件：模板、或者附件文件夹，通常是无需暴露出来的，插件 Hidden Folder 可以使用正则表达式来隐藏这些文件夹。

IaC 杂感

Thu, 05 Sep 2024 02:24:13 +0800

IaC 的起源

IaC 是配置管理领域的一种技术，全称 Infrastructure as Code，字面意义：基础设施即代码，是一种使用可读文本发放和管理基础设施资源的方法。通常情况下，软件定义的基础设施管理平台，会为用户提供命令行、WebUI 的方式，让用户能够用手工或者工具化的方式进行资源发放和管理工作。随着“基础设施”这一概念的不断扩展，使用频度的不断提高，越来越多的基础设施平台会提供各自的 API 为自动化打开方便之门。为了更快、更多的发放更多种类的基础设施，用一致的代码对这些基础设施进行管控也是顺理成章。IaC 的发展史很清楚地证明了这种演进过程。

1993 年，Mark Burgess 在博士后期间，为了管理不同的 Unix 工作站，开发了 CFEngine。这个大概是 IaC 工具的鼻祖。据说他仅仅根据直觉和实践经验，为了简化在不同 Unix 下大量编写脚本的工作，而开发了这个软件，在这里他提出了面向最终状态进行收敛的思路。

2006 年，AWS 发布了 EC2，各种公有云、私有云随之兴起，企业面对的资源不再是少数的主机，取而代之的是数量更大、品种更多、生命周期更短的虚拟机和随之而来的、更复杂的 IT 环境。在这之后，Chef、Salt Stack、Ansible 等生态也先后浮出水面。

个人认为真正的变化，是接下来的 2021-2024 年，Cloudformation、Terraform 和 Kubernetes 陆续发布，使用声明式 API 进行 IaC 操作成了业界惯例。AWS Control API 和 Kubernetes 这样的基础设施，从底层保障了声明式 API 的实现能力。

IaC 是对物理资源的采样

IaC 真的能描述物理资源么？很显然答案是否定的，毕竟现实世界是连续的。例如下面的 EC2 Instance：

  MyEC2Instance: 
    Type: AWS::EC2::Instance
    Properties: 
      ImageId: "ami-79fd7eee"
      KeyName: "testkey"
      BlockDeviceMappings: 
      - DeviceName: "/dev/sdm"
        Ebs: 
          VolumeType: "io1"
          Iops: "200"
          DeleteOnTermination: "false"
          VolumeSize: "20"
      - DeviceName: "/dev/sdk"
        NoDevice: {}

很明显，这几行代码不可能描述一个完整的 EC2 实例，结合前面提到的 Control API 和 Kubernetes，实际上，对资源的抽象从资源 API 层面就已经开始了，表现在 IaC 层面的，也只是这种抽象的结果。正如对声音的采样，IaC 中表达的资源不会是“完整的全貌”，越频繁的采样，能够保留越多的细节，也会造成这一描述的复杂度大大提高——但是无论如何提高，IaC 的描述能力甚至都达不到监控的细节水平。换句话说，使用 IaC 的方式来描述资源，就必须承担抽象带来的损失。

除了静态的属性之外，对象的状态也是对实际情况的大幅度抽象，例如下面的 Pod 状态：

stateDiagram-v2
    [*] --> Pending
    Pending --> Running : PodScheduled
    Pending --> Failed : PodFailed
    Pending --> Succeeded : PodSucceeded
    Running --> Succeeded : ContainersCompleted
    Running --> Failed : ContainersFailed
    Running --> Terminating : PodTerminating
    Terminating --> Succeeded : ContainersCompleted
    Terminating --> Failed : ContainersFailed
    Terminating --> [*]
    Failed --> [*]
    Succeeded --> [*]

虽然看起来很细致，但实际上中间忽略了很多细节，一个明显的例子就是，在各个状态之间切换失败时，往往都需要进一步的识别问题根因才能解决。

在《Thinking in Promises》中，有这样一段话：

我们的文化，偏好于对整体图景进行理解，这种偏好催生了控制系统：这些大型、集中式、无所不知的系统，像大脑一样运作运作，它们根据可用性和一致性的假设做出精确决策，根据我们的微观管理思路，产生直接的指令性的动作。集中化在逻辑上是合理的，然而它导致了规模上的限制。具备庞大处理能力的集中控制在逻辑上是合理的，然而在大规模系统下，仍然可能无法快速决策和执行动作。行动的延迟所导致的不准确和不一致，通常会造成未知后果。

随着计算、存储、网络的飞速进步，我们能够越来越多地获得系统中各种资源的细节信息，这可能会造成一种“膨胀”的心态——我们希望能够更多地获取系统中发生的所有细节，知晓其所有过往，甚至预测其所有未来。但是问题也很明显，我们面对的世界的复杂度的加速度，远高于我们的采集和管理能力的提升。将连续的物理资源抽象为离散的资源对象，并且以可读代码的方式进行表达，能有效地降低基础设施对注意力的消耗。同时针对软件开发过程设计的版本管理、访问控制、单元测试、文本比对、规则引擎、安全扫描、代码评审等一系列的方法都可以在 IaC 世界中大展拳脚，借助这一技术，管理员能更透明、更快、更大范围地对基础设施进行发放和管理。

IaC、面向对象和微服务

在我使用 IaC 的这一段时间里，新鲜感过后，我遇到了和推广容器化同样的困境——大量的实际业务和管控需求无法满足。在云原生语境中，我通常会用 12 要素等微服务要求来解释为什么你的“微服务”不能容器化。例如其中对进程、状态、配置、快速启动和优雅终止等。但是在 IaC 的落地过程中，我感觉缺乏了这样的理论后盾，有些底气不足。手里有了锤子，自然希望一切都是钉子——这些基础设施不过就是微服务运行所依赖的环境吧？面向对象、微服务架构的各种原则在这里是否继续有效呢？Terraform Provider 开发最佳实践中有这么几条：

Providers should focus on a single API or problem domain
Resources should represent a single API object
Resource and attribute schema should closely match the underlying API

很明显，这里将 TF Provider 视作了 Restful API 的延伸，而众所周知，Restful API 本身的设计，关注的也是“资源”及其 CURD-L 操作。因此作为 IaC 基础的 Provider 们，本身应该就可以用 OO 的方式进行构建了。IaC 资源就是对物理资源的抽象，我们在软件设计过程中所遵循的设计原则，应该也是适用于 IaC 的实施过程之中的，并且 IaC 应该是整个软件的一部分，因此其复杂度也是小于软件的整体的，顺着这个思路，就可以理直气壮的做些事了。

拆分堆栈

在公有云上运行软件，往往会涉及品类繁多的云资源，每次更新都是按照堆栈进行组织的，然而到底围绕一个微服务的堆栈应该由哪些资源组成呢？例如 VPC 算么？容器集群算么？浮动 IP 算么？按照上面的说法，把这些基础设施资源按照拆分微服务的方法进行组织，就方便多了。针对每个资源，简单地回答几个问题，就可以确定其归属了，例如记在谁的账上？谁在使用他？谁负责它的运维？哪些资源是一起更新的？这样几个维度判断下来，围绕着微服务，就能够构建合理的资源堆栈了。

Module 的划分

通常会使用 Module 对资源进行组合，这种组合有很多好处，例如可复用、规范化、降低认知负载等等，然而什么资源和什么资源应该组合成一个 Module 呢？Module 类似于日常开发中的 Library，完全可以使用和共享代码一样的方式，确定其共享范围和功能边界。

流水线设计

在 AWS 的 Builder’s Library 中提到：

典型的微服务可能具有应用程序代码管道、基础设施管道、操作系统修补管道、配置/功能标记管道，以及运算符工具管道。同一个微服务拥有多个管道有助于我们更快速地将更改部署到生产环境。未通过集成测试且阻塞应用程序管道的应用程序代码更改不会影响其他管道。例如，它们不会阻止基础设施代码更改到达基础设施管道的生产阶段。同一微服务的所有管道看起来都十分相似。例如，功能标记管道使用的安全部署技术与应用程序代码管道相同，因为错误的功能标记配置更改就像错误的应用程序代码更改一样，可能会影响生产。

不难发现，上述不同的流水线，也采用了类似微服务的划分方法，多条流水线以独立运作、互不堵塞的方式，用不同的频率个自运行。

入乡应随俗

如你所知，不管是面向对象，还是微服务架构，还没有、也不可能一统天下，IaC 也是这样。在传统运维领域，我们更倾向于掌控变更的全部过程，面对 IaC/Provider 这样的黑盒子，这种追求可能就有些不合时宜了——尤其是对于自行实现的 Provider 来说。

要想穿透 IaC 资源的状态管理，实现基于流程的过程管控，通常可以有两种做法：

拆小堆栈：用尽可能小的颗粒度进行变更，这样就从宏观上提供了一个相对细致的管控能力。
暴露细节：将原本被状态迁移隐藏起来的过程，暴露给外部进行观测和限制。

小颗粒的堆栈，牺牲的是 IaC 变更的效率和完整性；而暴露内部细节的方式，则破坏了对象的封闭性——像是暴露了所有 Private 成员的类定义，客观上对于“不规矩”/“不完整”的 Provider 是一种鼓励。

正如对 Kubernetes 对象的操作一样，IaC 的管控应该是一个相对“肤浅”、“粗放”的过程，能够依赖的，只能是 Provider 主动开放出来的状态迁移过程。

无需重启，使用 Shell Operator 对 Pod 进行垂直扩缩容

Mon, 02 Sep 2024 22:16:09 +0800

通常情况下，要修改 Pod 的资源定义，是需要重启 Pod 的。在 Kubernetes 1.27 中，有一个 Alpha 状态的 InPlacePodVerticalScaling 开关，开启这一特性，就能在不重启 Pod 的情况下，修改 Pod 的资源定义。

要使用这个功能，需要在 kube-apiserver 的 featureGates 中显式地设置启用，启用这一特性之后，就可以进行测试了。

例如 Kind 集群，需要在配置中加入：

featureGates:
  "InPlacePodVerticalScaling": true

测试一下

假设下面的 Pod 定义：

apiVersion: v1
kind: Pod
metadata:
  name: stress
spec:
  containers:
  - name: stress
    image: colinianking/stress-ng:latest
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer    
    command: ["sleep", "3600"]
    resources:
      limits:
        cpu: 200m
        memory: 200M
      requests:
        cpu: 200m
        memory: 200M

可以看到，spec 中加入了 resizePolicy 字段，用来指定对 CPU 和内存的扩缩容策略。内容很直白：

CPU 的扩缩容策略是 NotRequired，即不重启 Pod；
内存的扩缩容策略是 RestartContainer，即重启 Pod。

将上述内容提交到 Kubernetes 中运行。启动之后，如果运行 kubectl get po stress -o yaml，会发现状态字段中加入了如下内容：

- allocatedResources:
    cpu: 200m
    memory: 200Mi

说明此时分配给容器的资源。如果这时候对 CPU 进行修改，例如修改为：

resources:
  limits:
    cpu: 800m
    memory: 200Mi
  requests:
    cpu: 100m
    memory: 100Mi

修改后查看 Pod 列表，会发现 Pod 没有重启：

$ kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
stress   1/1     Running   0          4m14s

重新获取 YAML，会看到状态字段的一些变化：

resize: InProgress：表示正在扩缩容；

当前分配的资源也发生了变化：

- allocatedResources:
  cpu: 100m
  memory: 100Mi

自动纵向扩缩容

到目前为止，VPA 还没有支持这一特性。我们可以简地使用 Prometheus 对 Pod 资源压力进行监控，然后使用 Shell Operator 来实现自动扩缩容。总体思路就是，定期读取 Prometheus，获取指定 Pod 的 CPU 和使用情况，如果 CPU 使用率超过 80%，则将其 CPU 上限扩容一倍。

Prometheus 监控指标

Awesome Prometheus alerts 提供了如下的告警定义，用于表达 CPU 用量和其 Limit 的关系：

  - alert: ContainerHighCpuUtilization
    expr: (sum(rate(container_cpu_usage_seconds_total{container!=""}[5m])) by (pod, container) / sum(container_spec_cpu_quota{container!=""}/container_spec_cpu_period{container!=""}) by (pod, container) * 100) > 80
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: Container High CPU utilization (instance {{ $labels.instance }})
      description: "Container CPU utilization is above 80%\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

我们把它写入 Python 代码：

CPU_USAGE_QUERY = '''(sum(rate(container_cpu_usage_seconds_total{{namespace="{0}", pod="{1}", container="{2}"}}[5m])) by (pod, container) 
/ sum(container_spec_cpu_quota{{namespace="{0}", pod="{1}",container="{2}"}}
/container_spec_cpu_period{{namespace="{0}", pod="{1}", container="{2}"}}) by (pod, container) * 100)'''

定期运行

要设置 Shell Operator 的定期运行，需要使用 Schedule 类型的配置，下面的 Configmap 设置每两分钟运行一次：

apiVersion: v1
data:
  config.yaml: |+
    configVersion: v1
    schedule:
    - crontab: "*/2 * * * *"
      allowFailure: true
kind: ConfigMap
metadata:
  creationTimestamp: null
  name: so-config

我们会将这个 Configmap 加载到 Pod 定义中，

...
volumeMounts:
- mountPath: /conf/
  name: operator-config
...
volumes:
- configMap:
  name: so-config
name: operator-config
...

在 Hook 代码执行参数中带有 --config 参数时，读取该配置进行返回：

if len(sys.argv) > 1 and sys.argv[1] == "--config":
    with open("/conf/config.yaml", "r") as f:
        print(f.read())
    exit(0)

RBAC

Shell Operator 需要对 Pod 资源进行扩容，所以需要如下授权：

- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch", "patch"]

构建 Docker 镜像

FROM flant/shell-operator
RUN apk update && \
    apk add --no-cache py3-requests
COPY main.py /hooks

测试

Workload 中，我们设置的资源是 100M 内存+100m CPU 的配置，使用 kubectl exec -it stress -- sh 进入 Pod 之后，执行 stress-ng --cpu 1 --fork 2 制造一点压力，触发 Shell Operator 中的脚本对 Pod 进行纵向扩容，在 Prometheus 会看到如下曲线：

随着每次运行和扩容，CPU 水位不断下降，直到稳定。打开 Pod 定义，会看到扩容的痕迹：

  containerStatuses:
  - allocatedResources:
      cpu: 6400m
      memory: 100M
    containerID: containerd://10c55739a6a63f3464184f5384a2f2b091a235b7b6689bcdb58526e3eb8bdb19
    image: docker.io/colinianking/stress-ng:latest
    imageID: docker.io/colinianking/stress-ng@sha256:1b10c09968ea3460196596398f7811c7a604489a8311b3dbf477f552ac5ea972
    lastState:
      terminated:
        containerID: containerd://e3f1fe628086e291830b47247c88403d3ce0f4fd5db38b18afcca444659011d3
        exitCode: 0
        finishedAt: "2024-09-08T08:07:49Z"
        reason: Completed
        startedAt: "2024-09-08T07:07:49Z"
    name: stress
    ready: true
    resources:
      limits:
        cpu: 6400m
        memory: 100M

结论

全部代码被上传到了 https://github.com/fleeto/vscale-by-shelloperator。内容当然还是非常简陋，例如缺乏缩容手段、没有对上限进行限制，防抖动措施也是缺乏的。另外该特性还处在 Alpha 阶段，因此不推荐在生产环境中使用。

使用 Shell Operator + CRD 恢复被暂停的 Argo Workflow

Wed, 24 Jul 2024 23:21:04 +0800

上一篇讲到，使用 Kyverno 通过对特定标签的识别，让每个步骤进入自动暂停的状态，实现逐步骤运行。留了个尾巴，怎样才能快速的恢复被暂停步骤的运行？

TL;DR;

随便搞个 CRD，用 Shell Operator 监听，自动执行 kubectl exec 恢复目标步骤的运行。

Shell Operator 简介

简单来说，Shell Operator 是一个让用户能够使用脚本语言快速建立 Operator 的框架，能够非常方便的完成定时运行、启动运行、监听并响应 Kubernetes 对象和 CRD 等能力。

这篇文章会使用这一框架，从 CR 资源获取用户恢复运行指定步骤的意图，并完成恢复运行的操作。整个操作分为如下步骤：

创建 CRD
编写 Shell Operator
运行测试

创建 CRD

要恢复一个被暂停的工作流步骤，其输入只需要工作流 ID 和被暂停步骤（Template）名称即可，制定如下 CRD：

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: resumes.argocontroller.io
spec:
  conversion:
    strategy: None
  group: argocontroller.io
  names:
    kind: Resume
    listKind: ResumeList
    plural: resumes
    singular: resume
  scope: Namespaced
  versions:
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        properties:
          apiVersion:
            type: string
          kind:
            type: string
          metadata:
            type: object
          spec:
            properties:
              TemplateName:
                type: string
              Workflow-ID:
                type: string
            type: object
        type: object
    served: true
    storage: true

命名有点草率。

这个 CRD 中使用了 Workflow-ID 和 TemplateName 两个字段，分别用来查找流程实例和被暂停的步骤。

编写 Shell Operator

一个 Shell Operator 通常分为几个部分：

配置文件，用来指定触发时机，例如定时执行、启动执行和被 Kubenetes 对象操作触发。
Hook 脚本：主体，用来执行指定功能。
Dockerfile：继承 Flant 的 Shell Operator，用来构建运行镜像。
Kubernetes YML：用来在 Kubernetes 中运行 Shell Operator。

配置文件

我们这里设置，监听前面的 CR argocontroller.io/resume 的创建动作，因此配置文件这样编写：

configVersion: v1
kubernetes:
- apiVersion: argocontroller.io/v1alpha1
  kind: Resume
  executeHookOnEvent: ["Added"]

使用命令 kubectl create configmap hook-conf --from-file=config.yml 创建 Configmap 供后续脚本加载。

脚本

符合触发条件的 CR 一旦创建，就会被 Shell Operator 捕获，并保存到对应 Pod 的文件系统中，临时文件名保存在环境变量 BINDING_CONTEXT_PATH 里。

这里我们使用 Shell 脚本，处理环临时文件内容，查找 CR 包含的流程实例和模板名称。查找到流程实例之后，在其 status 节点查找 Pod 名称，最后执行恢复操作。脚本内容如下：

#!/bin/bash
if [[ $1 == "--config" ]] ; then
  cat /conf/config.yml
else
    jq -c '.[]' "$BINDING_CONTEXT_PATH" | while read -r item; do
        type=$(echo "$item" | jq -r '.type')
        # 跳过无用元素
        if [ "$type" != "Event" ]; then
            continue
        fi
        # 查找流程 ID 和模板名称
        TEMPLATE_NAME=$(echo "$item" | jq -r '.object.spec.TemplateName')
        WORKFLOW_ID=$(echo "$item" | jq -r '.object.spec["Workflow-ID"]')
        echo "tmpl=${TEMPLATE_NAME}  wfid=${WORKFLOW_ID}"
        FILENAME=/tmp/wf.json
        # 获取工作流实例的 YAML
        kubectl get workflow ${WORKFLOW_ID} -o json > "${FILENAME}"
        # 查找 Pod 名称
        POD=$(jq -r ".status.nodes[] | select(.templateName == \"${TEMPLATE_NAME}\" and .type == "Pod") | .id" "${FILENAME}")
        echo "pod=${POD}"
        kubectl exec -it ${POD} -- touch /proc/1/root/var/run/argo/ctr/main/after
    done
fi

Dockerfile

Dockerfile 很简单，只要把脚本设置为可执行，并加入到 /hooks 文件夹即可：

FROM  ghcr.io/flant/shell-operator:latest
ADD wf-resume.sh /hooks

编写好之后，使用 Docker 构建镜像并推送：

docker buildx build --platform linux/amd64,linux/arm64 --push \
    -t [image-name:image-tag] .

YAML

这里我们用一个 Pod YAML 来运行 Shell Operator：

apiVersion: v1
kind: Pod
metadata:
  name: shell-operator-observe
spec:
  serviceAccountName: shell-operator
  containers:
    - name: shell-operator-observe
      image: [image-name:image-tag]
      volumeMounts:
        - name: config-volume
          mountPath: /conf
  volumes:
    - name: config-volume
      configMap:
        name: hook-conf

这里有两个需要注意的点：

监听或者修改 Kubernetes 对象是需要授权的，要针对 shell-operator 这个 Service Account 进行 RBAC 授权。
使用 Configmap 加载到镜像的 /conf 目录。

使用 kubectl 提交运行。

运行测试

运行前一片文章中使用的工作流，暂停之后，使用 kubectl get workflow，例如 pause-3141592654ft97，就可以创建如下 CR：

{
  "apiVersion": "argocontroller.io/v1alpha1",
  "kind": "Resume",
  "metadata": {
    "name": "example-resume",
    "namespace": "default"
  },
  "spec": {
    "Workflow-ID": "pause-3141592654ft97",
    "TemplateName": "whalesay"
  }
}

提交集群后，可以看到，暂停状态取消，流程变为 Succeeded 状态。

调试

Shell Operator 在工作过程中难免会出现问题，我主要依赖的三板斧：

使用 kubectl logs 查看 Pod 日志。
进入 Operator Pod，修改脚本，重复触发
脚本中加入 echo 语句，或者保存 BINDING_CONTEXT_PATH 文件。

用 Kyverno 让 Argo Workflow 单步执行

Thu, 18 Jul 2024 22:59:35 +0800

AWS 的 SSM Automation 中，有个有趣的特性就是单步执行，在编写自动化脚本的时候，这个功能对调试非常有帮助。Argo Workflow 也有个暂停特性，官网给出的例子是这样的：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: pause-after-
spec:
  entrypoint: whalesay
  templates:
    - name: whalesay
      container:
        image: argoproj/argosay:v2
        env:
          - name: ARGO_DEBUG_PAUSE_AFTER
            value: 'true'

把他提交到 Argo 会看到暂停的情况：

$ argo submit --watch debug.yml
Name:                pause-after-hpvg9                                                                                                                                          [0/1455]
Namespace:           default
ServiceAccount:      unset (will run with the default ServiceAccount)
Status:              Running
Conditions:
 PodRunning          True
Created:             Thu Jul 18 23:18:46 +0800 (18 seconds ago)
Started:             Thu Jul 18 23:18:46 +0800 (18 seconds ago)
Duration:            18 seconds
Progress:            0/1

STEP                  TEMPLATE  PODNAME            DURATION  MESSAGE
 ● pause-after-hpvg9  whalesay  pause-after-hpvg9  18s

你会发现，这个 Workflow 会一直冻结在这个状态，

$ argo list
NAME                STATUS      AGE   DURATION   PRIORITY   MESSAGE
pause-after-hpvg9   Running     11m   11m        0
...

这时候只要进入 Pod，执行一个命令，工作流就会完成：

$ kubectl exec -it pause-after-hpvg9 -- bash
root@pause-after-hpvg9:/# touch /proc/1/root/var/run/argo/ctr/main/after
root@pause-after-hpvg9:/# command terminated with exit code 137

可以看到 Argo 的 Watch 也发生了变化：

STEP                  TEMPLATE  PODNAME            DURATION  MESSAGE
 ✔ pause-after-hpvg9  whalesay  pause-after-hpvg9  21m

问题来了，正常的工作流不会只有一个步骤，要实现单步执行的效果，就需要给每个步骤加入环境变量，是不是有点麻烦？我想到一个办法——用 Kyverno 做个自动补丁。只要 Workflow 加上一个 debug 标签，就给所有步骤加入暂停标志。

废话不多说，上策略代码：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-argo-debug-env
spec:
  rules:
    - name: add-debug-env-var
      match:
        resources:
          kinds:
            - argoproj.io/v1alpha1/Workflow
          selector:
            matchLabels:
              debug: "true"
          operations:
          - CREATE
      mutate:
        foreach:
          - list: request.object.spec.templates[]
            patchesJson6902: |-
              - path: /spec/templates/{{elementIndex}}/container/env/-
                op: add
                value:
                  name: ARGO_DEBUG_PAUSE_AFTER
                  value: "true"

这段策略有几个要点：

selector 指定，只处理带有 Debug 标签，并且操作为 CREATE 的
使用 foreach 语法，处理工作流中出现的每一个步骤
用 patchesJson6902 方式，给每个步骤的容器加入 ARGO_DEBUG_PAUSE_AFTER 环境变量。

提交策略之后，用如下任务脚本测试一下：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: debug314159-
  labels:
    debug: "true"
spec:
  entrypoint: whalesay
  templates:
    - name: whalesay
      container:
        image: argoproj/argosay:v2
    - name: whalesayagain
      container:
        image: argoproj/argosay:v2

提交工作流：

$ argo submit debug.yml
Name:                debug314159-dvqmw
Namespace:           default
ServiceAccount:      unset (will run with the default ServiceAccount)
Status:              Pending
Created:             Fri Jul 19 00:11:15 +0800 (now)
Progress:

查看生成的工作流：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
...
  labels:
    debug: "true"
    workflows.argoproj.io/completed: "false"
    workflows.argoproj.io/phase: Running
  name: debug314159-dvqmw
  namespace: default
...
spec:
...
  - container:
      env:
      - name: ARGO_DEBUG_PAUSE_AFTER
        value: "true"
      image: argoproj/argosay:v2
...
  - container:
      env:
      - name: ARGO_DEBUG_PAUSE_AFTER
        value: "true"
      image: argoproj/argosay:v2
      name: ""
...

可以看到，Kyverno 给每个步骤都加入了环境变量，这样一来，就实现了单步执行的效果。

后记

这个办法还有个问题，就是恢复太麻烦了，我打算接下来用 Shell Operator 来解决。

不明白为什么 Argo Workflow 没有给这种步骤设置一个暂停状态。

介绍一个小工具：Terranetes

Sun, 07 Jul 2024 06:58:46 +0800

IaC 不只是 Terraform

虽然几年前的一次讨论中，我嘲讽过某同事说，Terraform 目前最靠谱的 Provider，也就只有 Kubernetes 一个而已，相对于顾头不顾尾的 Provider 来说，Kubernetes + Operator 才是正道；然而形势比人强，目前 Terraform 的确是能帮用户踏上 IaC 旅程的方便法门。

就像 Kubernetes 之于云原生，对于 IaC 来说，Terraform 也同样有着 Day2 的问题。并且由于面对更大范围、更大成本的调度能力，Terraform 的管控也面临更大的挑战。例如工作流、合规、安全、成本等方面的考虑，以及偏差检测、模块安全等特性的应用，都是摆在管理员面前的明显问题。围绕这一工具，想要构建一个稳健的自助平台，是个颇为复杂的困难过程。

Terranetes 简介

appvia.io 是一个位于伦敦的解决方案厂商，它的开源项目 Terranetes 就尝试解决 Terraform 的 Day2 问题。这个 golang 项目在 22 年开源，到现在为止，发布了一百多个 Release，Star 数量只有 135 个，上次代码更新是在两个月前，从运作成绩来看，似乎不太成功。然而从平台工程的角度来看，这个项目提供的众多特性，却是非常值得关注和致敬的。

Terranetes 首页有这样一张图，形象地描述了这一产品的 IaC 治理思路：

工作流

图里简单地描述了一个工作流，平台团队制定规则、开发团队申请资源，控制器接收申请、引用凭据、执行规范，按照流程中设定的审批、Lint 等环节，完成资源申请过程。

他把用户明确地区分为平台和开发两种角色：

平台团队

平台用户的主要职责是为开发者用户提供自助服务的基础支持：

接入资源供应商：用 CRD 的形式定义资源供应商，以此来支撑开发者使用指定供应商的资源。
凭据管理：管理接入资源供应商的身份凭据，开发者无需自行管理凭据，即可获得操作资源的权限。
策略管理：从成本、合规、安全等方面，提供策略支持，保障开发者对资源的有效使用。

开发团队

开发者的职责相对集中一些：引用平台团队维护的凭据、规则、模板等，按照既定工作流进行资源的申请和使用。

上手一试

官方提供了 Quick Start 文档，网络条件允许的话，几分钟就可以完成第一次资源分配。下面的例子我使用 AWS 作为资源供应商，本机的 OrbStack 提供给 Terranetes 作为控制器的 Kubernetes 运行平台。

先决条件

Kubernetes 集群
AWS 账号，有能够创建 S3 Bucket 的 AK/SK

部署

基于 Helm 的老套部署方式：

$ helm repo add appvia https://terranetes-controller.appvia.io
$ helm repo update
$ helm install -n terraform-system terranetes-controller appvia/terranetes-controller --create-namespace
...

运行后可以看到多出了 terraform-system 命名空间，其中运行了两个控制器 Pod。

CRD

看看多出了哪些 CRD：

$ kubectl api-resources | grep terraform
cloudresources                                 terraform.appvia.io/v1alpha1      true         CloudResource
configurations                                 terraform.appvia.io/v1alpha1      true         Configuration
contexts                                       terraform.appvia.io/v1alpha1      false        Context
plans                                          terraform.appvia.io/v1alpha1      false        Plan
policies                                       terraform.appvia.io/v1alpha1      false        Policy
providers                                      terraform.appvia.io/v1alpha1      false        Provider
revisions                                      terraform.appvia.io/v1alpha1      false        Revision

官网文档用下图来描述对象之间的关系：

CloudResources：这个对象用来描述 Terraform 中的云资源，CloudResources 会选择性的向用户公开属性，从而减少开发者的心智负担，并确保选项符合组织意图。

Revisions：Revision 是云资源的模板，在实际环境中，应该是经过策划和测试的版本化资产，其中会包含组织所需的默认设置，并只公开与上下文相关的功能：

Revision 指向 Terraform 模块。
包含平台希望模块默认设置的所有默认选项，并向消费者公开部分可见选项。
可以跟踪 Terraform 模块，也可独立演进。
所有 CloudResources 都会引用集群中的 Revision。
要升级 CloudResource 消费者，需要更新其指向的 Revision。

Configurations：另一种描述云资源的方法，相对于 CloudResource，它相对传统一些，采用了和 Module 进行一对一连接的方式。

Providers：用来连接云资源提供方的定义。

Plans：无需主动创建，随 Revision 对象的定义自然产生。

Policies：对策略的引用，其中包含了 Checkov 规则的引用方法、对 Module 的限制。

Contexts：上下文提供了一种在配置之间共享通用配置的方法。集群中任何组件都可以引用该资源。

配置凭据和 Provider

接下来配置用来连接 AWS：

$ kubectl -n terraform-system create secret generic aws \
--from-literal=AWS_ACCESS_KEY_ID=${AWS_AK} \
--from-literal=AWS_SECRET_ACCESS_KEY=${AWS_SK} \
--from-literal=AWS_REGION=${AWS_AGN}
secret/aws created
$ export PROVIDER="https://raw.githubusercontent.com/appvia/terranetes-controller/master/examples/provider.yaml"
$ kubectl apply -f $PROVIDER
provider.terraform.appvia.io/aws created
provider.terraform.appvia.io/aws-irsa created

可以看到 Provider 对象的 spec 内容：

  spec:
    preload:
      cluster: wayfinder-production
      context: default
      enabled: false
      region: eu-west-2
    provider: aws
    secretRef:
      name: aws
      namespace: terraform-system
    source: secret

其中指定了 AWS 作为资源供应商，并且使用前面的 Secret 作为连接凭据。

配置 Revision

$ export REV="https://raw.githubusercontent.com/appvia/terranetes-controller/master/examples/revision.yaml"
$ kubectl apply -f ${REV}
revision.terraform.appvia.io/bucket.v1 created

打开 Revision 文件，能够大致观察到其中包含的信息：

configuration：其中有 Module 的地址、Context 引用、Provider 引用以及默认值。
inputs：这里定义了用户可以控制的内容（此处只有 bucket 可写）。
plan：则定义了该对象所属的计划。

Revision 中定义的 Plan 也被自动创建了：

$ kubectl get plan bucket -o yaml
apiVersion: terraform.appvia.io/v1alpha1
kind: Plan
metadata:
  ...
spec:
  revisions:
  - name: bucket.v1
    revision: v0.0.1

使用 Plan->Revision 创建资源

上面两节完成了平台管理或者资源管理角色的任务，接下来要真正地申请资源了。这里需要创建如下的 CloudService 对象：

apiVersion: terraform.appvia.io/v1alpha1
kind: CloudResource
metadata:
  name: bucket
spec:
  plan:
    name: bucket
    revision: v0.0.1
  providerRef:
    name: aws
  writeConnectionSecretToRef:
    name: test
  variables:
    bucket: forever8384

执行之后，我们会看到，系统中有了一个运行成功的 Job 对象，以及一个 CloudResource 对象：

$ kubectl get jobs
NAME                  COMPLETIONS   DURATION   AGE
bucket-tgbrl-1-plan   1/1           28s        8m37s
$ kubectl get cloudresources.terraform.appvia.io
NAME     PLAN     REVISION   SECRET   CONFIGURATION   ESTIMATED     UPDATE   SYNCHRONIZED   AGE
bucket   bucket   v0.0.1     test     bucket-tgbrl    Not Enabled   None     OutOfSync      8m50s

任务已经完成，打开 AWS 控制台，也找不到我们要的 Bucket。看看 Job 对应的 Pod 日志：

kubectl logs -f bucket-tgbrl-1-plan-lj7hd
[info] Checking if required flags have been provided.
[info] Waiting 10 seconds for pod logs to be available (attempt 1/15)..
[info] waiting for the job to be scheduled
...
  # aws_s3_bucket_server_side_encryption_configuration.this[0] will be created
  + resource "aws_s3_bucket_server_side_encryption_configuration" "this" {
...
  # aws_s3_bucket_versioning.this[0] will be created
  + resource "aws_s3_bucket_versioning" "this" {
...
Plan: 6 to add, 0 to change, 0 to destroy.

搞 Terraform 的读者会看得出来，他似乎只做了 Plan，没有做实际的 Apply。

文档解释说，默认情况下，资源的创建是需要被批准的，除非是使用了注解：terraform.appvia.io/apply=true，所以我们现在加入这个：

$ kubectl annotate cloudresources bucket "terraform.appvia.io/apply"=true --overwrite
cloudresource.terraform.appvia.io/bucket annotated

接下来会看到一个新的 Job 在运行，类似 bucket-l6jkf-1-apply-xp45d 这样的名称。这个 Pod 运行成功之后，会看到 S3 桶已经创建。

客户端

Terranetes 还有个叫 tnctl 的命令行客户端软件，提供了任务跟踪、审批等能力，避免大量使用 kubectl 来完成这些任务。

其他

偏差检测

CloudResource 有个字段 spec.enableDriftDetection，设置为 True 就可以启动偏差检测。例如上面的 CloudResource，我们修改这个字段为 True 之后，删除对应的桶，一段时间之后，这个资源就会变成 OutOfSync 状态。

监控

Controller 自带了 Prometheus 的指标抓取端口，提供了请求数、延迟时间等简单的指标。

除了这些基本功能之外，Terranetes 还能对接 Infracost 进行成本数据采集和预测，不过这是个商业产品，就没有进一步尝试了。

总之，Terranetes 提供了一个相对全面的框架，其中展示的工作流、策略、分权等设计，都是很好的范本，很值得工具平台、IaC 相关方案的设计者们参考和学习。

使用 Argo Workflow 组织跨云运维的可能性

Thu, 02 May 2024 21:39:17 +0800

在微服务、容器化和 IaC 等概念普及之前，自动化通常是使用过程性操作进行的，例如摘流——升级——恢复的过程。为了运维方便，通常这些操作序列会由所谓的运维流程编排工具完成，例如 AWS 的 SSM Automation，或者阿里云的 OOS 等。随着运维自动化的要求逐步提高，这些工具的编排能力也逐步扩展，出现了插件扩展、循环、跳转等更复杂的行为，甚至还出现了人工审批等蜜汁操作。自动化的编排复杂度也不断延伸——AWS 公开的作业脚本中已经出现了超过 3000 行 50 个步骤的庞然大物。

古时候的自动化运维通常是围绕着虚拟机进行的——管你是谁家的机器，只要你开了 SSH，或者装了我家的 Agent，你就跟我姓了。但是随着公有云服务能力的不断扩展，虚拟机的运维操作占比就逐步降低了，围绕 API 进行的运维能力逐步超过了虚拟机，成为主流。

不管有用没用，多云已经成为部分架构师的口头禅了。再加上前面的两个情况—— SRE 平台需要有一个能跨云的、面向 API 的、具备复杂编排能力并且能用编程方式进行扩展的自动化工具了，另外随着面对资源规模的不同，必要的并发能力和横向扩展的能力也是必要的。经过一番比对，我觉得 Argo Workflow 可能是个合适的选择。

Argo 大概于 2017 年以 GitOps 工具的形态，由 Intuit 发布，2020 年进入 CNCF 孵化，2022 年毕业，现在已经成长为包含 Argo CD、Argo Workflows、Argo Events 以及 Argo Rollouts 的生态群，并在 2022 年开始有了 Argo Con 峰会。

架构

根据官方提供的组件图可以看出：

Argo Workflows 运行在 Kubernetes 集群里。
可以利用 Kubernetes API 对 Argo 进行控制。
用户可以通过 CLI、Kubectl 和 Web UI 三种方式和 Argo 进行交互。
可以对接外部 idP，让 Argo Workflows 具备单点登录能力
Workflow 也是以 Pod 的形式在集群中运行的。

下图则是对工作流的一个描述。

这里不难发现，Argo Workflow 除了支持工作流之外，还支持了 DAG，它的工作流节点是用多容器 Pod 的形式运行的——每个 Pod 中包含 Wait、Init 和 Main 三个容器。

功能

Argo Workflow 提供了非常丰富的自动化编排能力。流程方面，提供了循环、条件、递归、暂停、恢复等常见内容；容错方面提供了超时、重试、异常捕捉/跳转等能力；另外他还支持脚本执行、变量定义和处理、工件传递等用于应对复杂场景的功能。功能方面，个人评估是略强于 AWS 的 SSM Automation 的。

起步

下文均用目前的 v3.5.6 为例

Argo Workflows 的快速部署方式非常简单，下面两行命令即可：

$ kubectl create namespace argo
namespace/argo created
$ kubectl apply -n argo -f https://github.com/argoproj/argo-workflows/releases/download/v3.5.6/install.yaml
...
priorityclass.scheduling.k8s.io/workflow-controller created
deployment.apps/argo-server created
deployment.apps/workflow-controller created

当然，这只是一个测试环境的玩法，项目也用 Helm Chart 的方式提供了用于生产环境的部署途径。

服务启动后，可以看到两个 Pod：

$ kubectl get po -n argo
NAME                                   READY   STATUS    RESTARTS   AGE
workflow-controller-5bb8788d57-sxnv2   1/1     Running   0          29s
argo-server-67bcf4bb48-sq9jp           1/1     Running   0          29s

为了简化使用可以进行一点修改：

$ kubectl patch deployment \
  argo-server \
  --namespace argo \
  --type='json' \
  -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": [
  "server",
  "--auth-mode=server"
]}]'

默认的认证方式需要使用 Service Account，并且需要进行较多的 RBAC 配置，有些复杂，所以这里改成了服务侧自行认证。

然后把服务改成 NodePort：

$ kubectl patch svc argo-server -n argo -p '{"spec": {"type": "NodePort"}}'
service/argo-server patched

这样，就可以在获取端口后，直接浏览器直接访问 Argo UI 了（注意这里默认使用的是 https 协议）。

教程中提供了一个 Hello World 流程，内容如下：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: hello-world-
  labels:
    workflows.argoproj.io/archive-strategy: "false"
  annotations:
    workflows.argoproj.io/description: |
      This is a simple hello world example.
spec:
  entrypoint: whalesay
  templates:
  - name: whalesay
    container:
      image: docker/whalesay:latest
      command: [cowsay]
      args: ["hello world"]

这个简单的 YAML 可以看到 Argo 工作流定义中的基本元素：

这是一个 CRD，类型是 argoproj.io/v1alpha1 的 Workflow。
这一清单需要重复使用，因此 metadata 中没有给出 Name，而是给出了 generateName。
spec.templates 中保存的步骤的定义，并使用 spec.entrypoint 指定了入口环节。
仅有的一个步骤中，使用一个容器镜像，并指定了执行命令，输出一段文字。

使用 kubectl create 提交工作流，看看结果：

$ kubectl create -f install.yaml
workflow.argoproj.io/hello-world-fdddc created

用浏览器打开控制台，浏览 workflows 页面，可以看到，出错了：

错误原因也很 Kubernetes，就是 RBAC 权限不足：

Error (exit code 1): pods "hello-world-fdddc" is forbidden: User "system:serviceaccount:default:default" cannot patch resource "pods" in API group "" in the namespace "default"

看来这里用到的什么修改 Pod 的功能，看一下命名空间中的 hello-world，会看到它的内容和我们在模板中指定的简单几行完全不同，多出了 initContainer 和 Sidecar。主容器的命令也被加入了新的内容。

这里偷个懒，直接借用 Argo 明明空间里的 Argo SA，用法很简单，在 YAML 的 entrypoint 字段后加入同级元素 serviceAccountName: argo，并且在 Argo 命名空间里创建：

$ kubectl create -f hello-world.yaml -n argo
workflow.argoproj.io/hello-world-l4q2x created

浏览器控制台可以看到，这次成功运行，并且输出了结果：

用 argo CLI 也可以方便的查看：

$ argo list -A
NAMESPACE   NAME                STATUS      AGE   DURATION   PRIORITY   MESSAGE
argo        hello-world-l4q2x   Succeeded   7h    10s        0
default     hello-world-fdddc   Error       8h    10s        0          Error (exit c

场景

用户可以通过 Restful API、SDK、CLI 和 Web 控制台来访问 AWS 服务，自动化操作通常会使用 SDK 或者 CLI 的方式。这里我们设置一个场景：查询当前账户的 EC2 实例，并关机。

这里需要用到几个能力：

使用容器模板加载 AWS 凭据，并运行 AWS CLI 的能力
将 AWS CLI 结果输出为变量的能力
循环处理列表变量的能力

加载 Secret

假设我们的凭据文件保存在当前目录的 credentials 文件中，我们需要将它创建为 Secret，并在后续的容器模板中进行加载：kubectl create secret generic awskey --from-file=credentials。

工作流中想要加载 Secret，跟 Pod 是很相似的，例如我们将会这样编写列出 EC2 实例的环节：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: shutdown-ec2-
  labels:
    workflows.argoproj.io/archive-strategy: "false"
spec:
  serviceAccountName: argo
  entrypoint: list-instances
  volumes:
    - name: aws-secret
      secret:
        secretName: awskey
  templates:
    - name: list-instances
      container:
        image: amazon/aws-cli:2.15.43
        args:
          - "ec2"
          - "describe-instances"
          - "--output"
          - "json"
          - "--region" 
          - "ap-northeast-1"
          - "--query"
          - "Reservations[].Instances[].InstanceId"          
        volumeMounts:
          - name: aws-secret
            mountPath: /root/.aws

这个步骤写完之后，可以运行一下，看看结果：

$ argo submit -n argo --watch aws-list-ec2.yaml
...
STEP                   TEMPLATE        PODNAME             DURATION  MESSAGE
 ✔ shutdown-ec2-7ngl9  list-instances  shutdown-ec2-7ngl9  4s

查看日志会发现，成功返回了一个 JSON 数组，其中包含了我们需要的实例 ID 列表。

循环关闭

接下来把这个工作流改为多模板的模式，便于我们加入参数和循环能力。

实际上 AWS CLI 是直接支持用数组方式关闭多个 EC2 实例的

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: shutdown-ec2-
  labels:
    workflows.argoproj.io/archive-strategy: "false"
spec:
  serviceAccountName: argo
  entrypoint: shutdown-all-ec2
  volumes:
    - name: aws-secret
      secret:
        secretName: awskey
  templates:
    - name: shutdown-all-ec2
      steps:
        - - name: list
            template: list-instances
        - - name: shut
            template: shutdown-ec2
            arguments:
              parameters:
                - name: ec2id
                  value: "{{item.InstanceId}}"
            withParam: "{{steps.list.outputs.result}}"
    - name: list-instances
      container:
        image: amazon/aws-cli:2.15.43
        command: ["aws"]
        args:
          - --output
          - json
          - --region
          - ap-northeast-1
          - ec2
          - describe-instances
          - --query
          - "Reservations[].Instances[]"
        volumeMounts:
          - name: aws-secret
            mountPath: /root/.aws
    - name: shutdown-ec2
      inputs:
        parameters:
          - name: ec2id
      container:
        image: amazon/aws-cli:2.15.43
        command: ["aws"]
        args:
        - "ec2"
        - "stop-instances"
        - --region
        - ap-northeast-1        
        - "--instance-ids"
        - "{{inputs.parameters.ec2id}}"
        volumeMounts:
          - name: aws-secret
            mountPath: /root/.aws

上面的 YAML 的主要变化：

把原有的单步骤流程拓展成了多步骤
列表中加入了格式化内容，精简输出

将列表结果作为循环变量，传递给了用于关机的后续步骤

arguments:
parameters:
- name: ec2id
  value: "{{item}}"
withParam: "{{steps.list.outputs.result}}"

这一段将步骤 list 的控制台输出作为循环变量，传递给 shutdown-ec2 模板的 ec2id 参数，逐个关机。

注意这里的写法，使用 step 的方式对模板进行引用，形成多步骤流程。

运行后，可以看到 Argo 用并发的形式，进行了批量关机操作。

补充

首先是 AWS CLI 提供了丰富的功能，调用起来实在是比 SDK 方便太多，所以这里用这种形式来简化操作。

其次是这里对输出变量的做法，其实 Argo 提供了丰富的内置函数，可以对这些输出内容进行较为复杂的处理，当然，也可以用 Script 步骤进行更加细致的定制工作。

再次，过程中直接加载 AWS 凭据的方法非常不推荐，关于容器环境中的敏感信息管理，已经有很多陈述，这里就不节外生枝了。

最后，Argo 的文档真烂，真的烂。。

Kubernetes 的小秘密——从 Secret 到 Bank Vault

Thu, 04 Apr 2024 17:52:04 +0800

Kubernetes 提供了 Secret 对象用于承载少量的机密/敏感数据，在实际使用中，有几种常规或者非常规的方式能够获取到 Secret 的内容：

Pod 加载（自己的或者不是自己的）Secret 为环境变量或者文件
使用 Kubernetes API（或者 kubectl）获取 Secret 对象内容
连接 ETCD 读取其中保存的 Secret 明文
在 CICD 工具中截获含有明文的 Secret 对象 YAML
在加载了 Secret 的容器中直接读取环境变量或者机密文件

上述泄露途径有几个方式可以进行消减：

制定细粒度的 RBAC 策略，防止未授权的 Secret 访问以及 Exec 访问
API Server 使用加密参数（EncryptionConfiguration），在 ETCD 中存储密文
使用 Scratch 等超精简基础镜像，杜绝无用访问
使用策略引擎，防止不当的加载行为
- 只有特定的 Pod/容器可以加载特定的 Secret
- 禁止随意加载主机卷，防止 Kubernetes 组件的身份证书被冒用

除了上述的原生方案之外，还有一些补充手段也是有帮助的，例如：

Bitnami 的 Sealed Secret 工具，使用密钥对机密信息进行加密，只有在进入集群之后才会还原为目标 Secret，防止在供应链中泄露信息。
Vault 提供了一个 Sidecar，能把 Vault 中存储的机密信息，直接在 Pod 中生成相应的敏感信息文件
Secrets Store CSI Driver 项目，能从 Vault、Azure 等设施获取信息，注入 Pod 或者生成 Secret。

Bank Vault

Bank Vault 是个 Vault 周边项目，它大大的降低了 Vault 的落地难度，通过 Webhook 注入，Sidecar 等方式，为 Kubernetes 集群中的工作负载提供了方便的 Vault 接入手段。下图表示了它和原生 Vault 的相对优势：

部署

Bank Vault 提供了一个 Operator，能够非常方便的部署 Vault 服务极其相关的 Webhook。所以首先从 Helm 安装 Operator 开始。

$ helm upgrade --install --wait vault-operator \
oci://ghcr.io/bank-vaults/helm-charts/vault-operator

Release "vault-operator" does not exist. Installing it now.
Pulled: ghcr.io/bank-vaults/helm-charts/vault-operator:1.22.1
Digest: sha256:f9d976c39f96942ae52b26a3ab923f173109de64a87c3161fed2470f7bcfa86f
NAME: vault-operator
LAST DEPLOYED: Sat Apr  6 13:54:32 2024
...

接下来使用 Kustomize 生成 Vault 所需的 RBAC 对象：

$ kubectl kustomize https://github.com/bank-vaults/vault-operator/deploy/rbac | kubectl apply -f -
serviceaccount/vault created
role.rbac.authorization.k8s.io/vault created
role.rbac.authorization.k8s.io/leader-election-role created
rolebinding.rbac.authorization.k8s.io/leader-election-rolebinding created
rolebinding.rbac.authorization.k8s.io/vault created
clusterrolebinding.rbac.authorization.k8s.io/vault-auth-delegator created

最后创建 Vault 实例：

$ kubectl apply -f https://raw.githubusercontent.com/bank-vaults/vault-operator/v1.21.0/deploy/examples/cr-raft.yaml
vault.vault.banzaicloud.com/vault created

创建结束后，会出现几个 Pod，分别是 vault-operator、vault-configurer 以及三个有状态 vault 实例。

连接到 Vault

首先是新开一个终端窗口，使用端口转发方式暴露 Vault 服务：

$ kubectl port-forward vault-0 8200 &
...
Forwarding from 127.0.0.1:8200 -> 8200
Forwarding from [::1]:8200 -> 8200

然后是给 Vault 客户端准备接入端点和 CA：

# 端点就是 kubectl 转发的端口
$ export VAULT_ADDR=https://127.0.0.1:8200
# 导出证书，并记录到环境变量里
$ kubectl get secret vault-tls -o jsonpath="{.data.ca\.crt}" | base64 --decode > $PWD/vault-ca.crt
export VAULT_CACERT=$PWD/vault-ca.crt

检查一下 vault 的连接：

$ vault status
Key                     Value
---                     -----
Seal Type               shamir
Initialized             true
Sealed                  false
...

用环境变量保存凭据：

export VAULT_TOKEN=$(kubectl get secrets vault-unseal-keys -o jsonpath={.data.vault-root} | base64 --decode)

部署 Webhook

Vault 服务启动并连接之后，就可以开始着手部署功能部分了，前面提到过，Bank Vault 是用 Webhook 实现功能的，所以接下来部署的就是 Webhook 了：

$ kubectl create namespace vault-infra
$ kubectl label namespace vault-infra name=vault-infra

namespace/vault-infra created
namespace/vault-infra labeled
$ helm upgrade --install --wait vault-secrets-webhook \
  oci://ghcr.io/bank-vaults/helm-charts/vault-secrets-webhook \
  --namespace vault-infra
...
LAST DEPLOYED: Sat Apr  6 14:45:05 2024
NAMESPACE: vault-infra
STATUS: deployed

部署完成之后发现生成了两个 Webhook。查看代码，可以看到：

pods.vault-secrets-webhook
- 会被 Pod 的创建事件触发
- 跳过 kube-system 和刚创建的 vault-infra 两个命名空间
- 跳过 security.banzaicloud.io/mutate 标签为 skip 的 Pod
secrets.vault-secrets-webhook
- 会被 Secret 的创建和更新事件触发
- 跳过 kube-system 和刚创建的 vault-infra 两个命名空间
- 跳过 security.banzaicloud.io/mutate 标签为 skip 的 Secret

写入测试数据

向 Vault 写入一个密钥：

vault kv put secret/demosecret/aws AWS_SECRET_ACCESS_KEY=s3cr3t

======= Secret Path =======
secret/data/demosecret/aws

======= Metadata =======
Key                Value
---                -----
created_time       2024-04-06T07:12:27.042649134Z
...

用环境变量读取 Vault 内容

创建一个 Pod，看看 Webhook 会对他做什么。

apiVersion: v1
kind: Pod
metadata:
  name: vault-test-pod
  labels:
    app.kubernetes.io/name: vault
  annotations:
    vault.security.banzaicloud.io/vault-addr: "https://vault:8200"
    vault.security.banzaicloud.io/vault-role: "default"
    vault.security.banzaicloud.io/vault-skip-verify: "false"
    vault.security.banzaicloud.io/vault-tls-secret: "vault-tls"
    vault.security.banzaicloud.io/vault-agent: "false"
    vault.security.banzaicloud.io/vault-path: "kubernetes"
spec:
  serviceAccountName: default
  containers:
  - name: alpine
    image: alpine
    command: ["sh", "-c", "echo $AWS_SECRET_ACCESS_KEY && echo going to sleep... && sleep 10000"]
    env:
    - name: AWS_SECRET_ACCESS_KEY
      value: vault:secret/data/demosecret/aws#AWS_SECRET_ACCESS_KEY

创建成功之后，看看 Pod 的日志：

$ kubectl logs -f vault-test-pod
Defaulted container "alpine" out of: alpine, copy-vault-env (init)
...
s3cr3t
going to sleep...

这里输出了我们之前写入 Vault 的密钥值，然而回头看看，我们的 Pod 定义里，并没有引用 Secret，只是定义了一个值为 vault:secret/data/demosecret/aws#AWS_SECRET_ACCESS_KEY 的环境变量，command 节中的命令行直接输出这个环境变量，就能够输出保存在 Vault 中的内容了。但是进入 Pod 的 Shell，会发现环境变量没有变化：

$ kubectl exec -it vault-test-pod -- env | grep -i aws
Defaulted container "alpine" out of: alpine, copy-vault-env (init)
AWS_SECRET_ACCESS_KEY=vault:secret/data/demosecret/aws#AWS_SECRET_ACCESS_KEY

所以 Pod 中被注入了什么呢？

首先是注入了一个初始化容器，在临时卷里面复制了一个 vault-env 命令
用卷加载了 Configmap，其中包含了访问 Vault 所需的 CA
加载了
根据我们前面的注解，生成了一系列的 VAULT* 环境变量

最重要的，它劫持了原有的启动命令，在前面加入了一个 /vault/vault-env，启动命令就变成了：

  - args:
    - sh
    - -c
    - echo $AWS_SECRET_ACCESS_KEY && echo going to sleep... && sleep 10000
    command:
    - /vault/vault-env

所以可以推测——/vault/vault-env 充当了 sh 的父进程，在其中根据环境变量 AWS_SECRET_ACCESS_KEY 的值获取了保存在 Vault 中的机密内容。

用机密数据渲染配置文件

看看下面的 Configmap：

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/name: my-app
    my-app.kubernetes.io/name: my-app-vault-agent
    branches: "true"
  name: my-app-vault-agent
data:
  config.hcl: |
    vault {
      // This is needed until https://github.com/hashicorp/vault/issues/7889
      // gets fixed, otherwise it is automated by the webhook.
      ca_cert = "/vault/tls/ca.crt"
    }
    auto_auth {
      method "kubernetes" {
        mount_path = "auth/kubernetes"
        config = {
          role = "default"
        }
      }
      sink "file" {
        config = {
          path = "/vault/.vault-token"
        }
      }
    }
    template {
      contents = <<EOH
        {{- with secret "secret/data/demosecret/aws" }}
        token: {{ .Data.data.AWS_SECRET_ACCESS_KEY }}
        {{ end }}
      EOH
      destination = "/tmp/config"
      // command     = "/bin/sh -c \"kill -HUP $(pidof sleep) || true\""
    }

上面的配置文件指示了如何对接 Vault，从 secret/data/demosecret/aws 拉取 AWS_SECRET_ACCESS_KEY 中的值，渲染到 template 一节中的模板里面。只要在 Pod 的注解中加入 vault.security.banzaicloud.io/vault-agent-configmap: "my-app-vault-agent"。就可以在这个容器中加入 Sidecar，使用 Sidecar 在 destination 字段指定的配置文件里保存渲染结果。如果 command 有赋值，还可以发出命令，通知业务应用刷新配置。

加入该注解的 Pod 运行后，可以在这个 Pod 的指定文件中看到渲染结果，例如：

$ kubectl get pods | grep vault-agent-pod
vault-agent-pod                     2/2     Running   0              9m8s
$ kubectl exec -it vault-agent-pod -- cat /tmp/config
Defaulted container "vault-agent" out of: vault-agent, alpine

    token: s3cr3t

后记

Bank Valut 这个项目虽然已经有 2000 Star 了，不过文档还弱的很，甚至 Blog 全挂了也没人理。但是这个思路还是有点意思。虽说有点像屠龙技，不过被安全同学卡脖子的时候，这种使用父进程遮盖环境变量，或者用轮转方式刷新配置文件的玩法，都算是个可行的解法。

不用 API Server 也能运行 Pod？

Wed, 21 Feb 2024 23:37:11 +0800

遇到一个奇怪的需求：想复用 Pod 的 YAML，但是家境贫寒，不想搞个高可用 API Server；又惜字如金，不想上 Docker Compose。一顿 Google 猛如虎之后，得到了两个方案：静态 Pod 和 podman play kube。

静态 Pod

Kubernetes 有个功能，就是 static pod，官网介绍大致如下：

静态 Pod 由特定节点上的 kubelet 守护进程直接管理的，API 服务器并不关注静态 Pod。通常说来，Pod 是由 Deployments 之类的控制器管理的，而静态 Pod 则是在 Kubelet 的看护之下，并负责其重新启动的。

那么 Kubelet 是否可以脱离 API Server 直接运行呢？答案是肯定的，Kelsey Hightower 早在七年前就做了这样的尝试。

https://github.com/kelseyhightower/standalone-kubelet-tutorial

想法很简单，单独运行一个 Kubelet，使用 Kubelet 拉起磁盘上的 Pod 文件。

测试

以目前最新版本的 1.29 为例，在 Ubuntu 中按照默认方式使用 apt 部署 Containerd：

$ apt install containerd cri-tools
...

然后按照官网文档安装 kubelet：

$ apt-get install -y apt-transport-https ca-certificates curl gpg
$ curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
$ echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
$ sudo apt-get update
$ sudo apt-get install -y kubelet
...

编写如下 kubelet.yaml：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
enableServer: false
staticPodPath: /home/kubelet/pods
readOnlyPort: 10250
failSwapOn: false
podCIDR: 10.241.1.0/24
authentication:
  anonymous:
    enabled: true
  webhook:
    enabled: false
authorization:
  mode: AlwaysAllow

最后，我们启动 Kubelet：

$ kubelet --config=kubelet.yaml
I0302 11:39:14.006446    9890 server.go:487] "Kubelet version" kubeletVersion="v1.29.2"
I0302 11:39:14.006492    9890 server.go:489] "Golang settings" GOGC="" GOMAXPROCS="" GOTRACEBACK=""
I0302 11:39:14.006622    9890 server.go:650] "Standalone mode, no API client"
I0302 11:39:14.010584    9890 server.go:538] "No api server defined - no events will be sent to API server"
...

注意，如果使用其它配置方法的容器运行时，可能需要指定不同的 Endpoint。

这里会看到，日志中直接就表明这是一个独立运行模式的 Kubelet。

最后只要把一个 Pod 定义的文件拷贝到上文配置中的指定目录就能启动 Pod 了：

apiVersion: v1
kind: Pod
metadata:
  name: apache
spec:
  containers:
  - name: apache
    image: httpd
    ports:
    - name: http
      containerPort: 80
      hostPort: 45678
    volumeMounts:
    - name: local
      mountPath: /data
  volumes:
  - name: local
    hostPath:
      path: /home/volumes/data
      type: Directory

使用 crictl 查看运行中的 Pod：

$  sudo crictl ps
55a65b4642f47       50a1bd9b297f7       18 seconds ago      Running             apache              0                   c141f4e021cdf       apache-ubuntu
$ curl http://127.0.0.1:45678
<html><body><h1>It works!</h1></body></html>

Pod 已经启动。

限制

因为没有 API Server 的支持，所以静态 Pod 里面是无法引用 Configmap、Secret 之类的外部对象的。更不要提 Deployment 了。

Podman Play Kube

和独立模式的 Kubelet 不同，podman play kube 支持的 Kubernetes 对象除了 Pod 之外，还支持：

Deployment
PVC
Configmap

启动 Pod

Ubuntu 下可以直接使用 apt install podman 安装部署。安装结束后，可以复用刚才的 pod.yaml：

$ podman play kube pod.yaml
a container exists with the same name ("apache") as the pod in your YAML file; changing pod name to apache_pod
Pod:
...
Container:
...

$ podman pod ls
POD ID        NAME        STATUS      CREATED        INFRA ID      # OF CONTAINERS
99e235dfe7a3  apache_pod  Running     9 seconds ago  b54991e35f58  2

$ podman ps
CONTAINER ID  IMAGE                           COMMAND           CREATED         STATUS             PORTS                  NAMES
b54991e35f58  k8s.gcr.io/pause:3.5                              41 seconds ago  Up 38 seconds ago  0.0.0.0:45678->80/tcp  99e235dfe7a3-infra
aa4a4ba1af39  docker.io/library/httpd:latest  httpd-foreground  38 seconds ago  Up 38 seconds ago  0.0.0.0:45678->80/tcp  apache_pod-apache

看到这里有几个发现：

用 podman pod ls 和 podman ps 可以查看 Pod 和容器的情况
Podman 取了个巧，使用命名的方式来区分容器和 Pod
Podman 启动的 Pod 用到了 Infra 容器，所以一个 Pod 里面会有两个容器。

为了让后续动作顺利，可以把容器名称修改为 httpd，用于消除这种隐式变更。在应用新版本 YAML 之前，需要因为发生了改名情况，所以无法使用 podman play kube pod.yaml --down 的方式停止 Pod，这里用 podman pod kill apache_pod && podman pod rm apache_pod 删除 Pod，然后重新创建修改后的 Pod：

$podman play kube pod.yaml
Pod:
...
Container:
...

甚至可以启动一个 Deployment，例如：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx

用 play kube 运行一下：

$ podman play kube deploy.yaml
...
podman pod ls
POD ID        NAME         STATUS      CREATED         INFRA ID      # OF CONTAINERS
0a6e4dcda93c  nginx-pod-2  Running     15 seconds ago  319f12f3b6f2  2
266df25c4df1  nginx-pod-1  Running     19 seconds ago  a65f6b601160  2
e6966f42c5fd  nginx-pod-0  Running     22 seconds ago  953e3e830528  2
573597e627ec  apache       Running     9 minutes ago   3b4ff4625b46  2

可以看到，这里生成了 3 个 nginx-pod 为前缀的 Pod。

Configmap

修改一下刚才的 pod.yaml，其中加入 Configmap：

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-sample
data:
  key1: value1
---
apiVersion: v1
kind: Pod
metadata:
  name: apache
spec:
  containers:
  - name: httpd
    image: httpd
    ports:
    - name: http
      containerPort: 80
      hostPort: 45678
    envFrom:
    - configMapRef:
        name: cm-sample
        optional: false

这里加入了一个引用 Configmap 作为环境变量的选项，使用 --down 开关停止当前 Pod 并重建后（4.x 版本有了 --replace 开关），验证一下：

$ podman exec -it [your container id] env | grep key
key1=value1

可以看到已经成功引用了 Configmap。

结论

除了简单的运行功能之外，Podman Play 还提供了网络、命名空间等功能，甚至还有现场构建的能力，比孤零零的 kubelet 强大不少，但是如果 Kubelet 加入 crictl、nerdctl 之类的东西的话，勉强也算各擅胜场。

Thinking in Promises Ch01.with a License to Intend

Sat, 13 Jan 2024 23:36:30 +0800

【译】《Thinking in Promises》第一章承诺和强加

Thu, 11 Jan 2024 01:05:19 +0800

想象有这样一组原则，这些原则可以帮助你理解部分如何结合成为整体，以及每个部分如何从自己的角度看待整体。如果这些原则是有效的，那么用这些原则进行观察，会发现团队中的人类、鸟群中的鸟儿、数据中心中的计算机还是瑞士手表中的齿轮都是可以应用这一原则的。合作理论应该是相当普遍适用的，因此我们可以将其应用于技术和工作场所。

这些原则是承诺理论的主题。承诺理论不是从整体出发的，其目标是从部分之和中揭示整体的行为。换句话说，它是一种自下而上的建构主义世界观。你可以将其描述为一种自底向上记录系统行为的学科。

承诺工程

2004年，我正在寻找一种用来描述CFEngine的分布式计算模型，承诺模型的工程概念在此时产生了。当时“承诺”这个词正式我所需要的：一种用来表达意图的院子。然而这个想法打开了潘多拉魔盒，我发现承诺可以用于更普遍的实物之中。组件如何作为一个整体运行的？承诺理论是理解这一问题的有效方式，并且它还承诺了一种从前没有被认真对待的思路：用单一描述来统一人类和机器行为。

与商业和计算机科学等其他建模方法不同，承诺理论并非一份宣言，也不是政治声明或哲学议程。一套简单原则的应用，构成了承诺理论的魔力。它只不过是一种将系统分解为基本组成部分，并重新组合的分析和工程方法。在这个过程中，我们找到了一种表示和质疑预期结果可行性的方法。对于某些人来说，疑点就在于计算机编程的知识，围绕计算机编程已经有了许多哲学思想，如OO、SOA、UML等等。这其中，有些把哲学置于理解之上的方法已经都失败了。

本书的目的是探讨在人机系统、组织和技术中，通过对承诺的理解，可以获知合作的方法，以及如何将这种理解应用于协同工作面临的现实挑战。

从命令到承诺

至少在西方的文化中，会将预期结果编写为分步执行的命令来执行的。然后，我们将这种思路编程为方法，用里程碑和可交付成果的方式来强调我们的思路。这种思路的产生原因是，我们用故事的方式来思考，就像我们通过语言讲述故事一样。但是故事是很难被评估的。我们如何知道一个故事是否成功地表达了其意图？

在另一方面，我们是不是转换一下思路，我们不再关心中间步骤，而只去考虑目标、预期结果、评估方式和成功呢？

举个例子——用如下指令来清理洗手间：

洗地板、拖地
清洗马桶
把纸巾放到纸巾盒
补充皂液
每小时准时执行上述操作

如果我们把该任务转换成为承诺模式：

我承诺，每小时检查时，地板都是清洁和干燥的
我承诺，每小时检查时，马桶都是空的和干净的
我承诺，每小时检查时，纸巾盒里都有干净的纸巾
我承诺，每小时检查时，肥皂盒里都有充足的皂液

重点在哪里？这有什么意义呢？难道这世界不是由用力来推动变化的吗？这是牛顿时代以来一直被广泛接受的学说，但这种看法是一种过度简化，甚至在现代物理学中也不准确。

我们首先要注意的事情就是，必须有代理人（人或者机器人）做出承诺，这样我们就知道谁是活动代理；做出承诺后，代理就负担了承诺所代表的责任。接下来我们会发现，做出承诺是需要动力的。合作通常要包含对话和激励。这些承诺缺少的是一个需求，比如：如果马桶洗干净了，我保证付款给你。因此从承诺的角度来看，就需要解答一个问题：我们如何描述激励措施？

为什么承诺优于命令

为什么是承诺，而不是义务、命令或者需求？在承诺理论中，后面的几个词被认为是强制措施——在没有邀请的情况下把意图强加给别人。

相对于强制措施来说，承诺始终关注因果关系的要点：即作出承诺并负责履行的代理人。承诺会更直接地揭示与预期结果相关的信息

命令或者其他的强制措施有两个问题：

对行为做出要求，而不是直接提出我们的需要（重过程而轻结果）
甚至在不了解目标的情况下，就要按部就班地执行全套命令

所以为什么承诺比命令好？承诺表达的关于终点或最终结果的意图，而不是指示起点时应该做什么。命令是和发出命令时的的具体状况相关联的，所以命令是受限于上下文的。而对于最终状态的承诺则是独立于当前状态的：

![[images/20231226-1.png]] 图 1-1：在本书中，我们将多次讨论时间线的收敛或扩散。在左边，命令从确定的起点扩散到不可预测的结果，我们从一种确定状态转变为一种不确定状态。而在右边，承诺从不可预测的开始趋于一个确定的结果，带来了更高的确定性。

承诺是从最大化确定性的视角来阐述预期的。承诺适用于作出承诺的代理人。根据自治的定义，每个代理人都有权控制自己。强加或命令是适用于他人（非自己）的事物。根据定义，那就是您无法控制的内容。

承诺有时候是可以关联到出发点的：“我承诺现在就倒立”，“我承诺会在早上9点离开房间”。承诺代表持续存在的状态，而命令则不行。

自治带来的确定性

承诺是对预期结果的一个声明。承诺不关注动作，也不试图强迫。承诺是一种自愿的行为。随着内容的推进，我还会使用“自愿”一词，让意义将变得更加清晰，还有个同义词就是自治。

如果一个代理人能控制自己的目标，那么他就是自主的（后果是由自己的行为导致的，而不是其他人）。这是一个独立的代理人。把世界分拆为自主的部分，我们就可以在因果上取得先机。当发生变更时，我们会知道他在一个自主区域里发生；在没有对外部做出明确承诺的情况下，就不会自外向内的产生变化。

注意，一个行为，只要看起来是有意的，或者是有可能有意为之即可被视为有意行为，不一定需要显式地声明意图。

永远正确的观察者

当我们做出承诺时，需要和某角色进行通信，让它能对预期结果进行校验。通常一个承诺意味着一个尚未发生的结果（比如说“我承诺准时把你送到教堂参加婚礼”）。我们还能对已经发生但是尚未验证的事情进行承诺（例如会计部门说：“我承诺已经按时付款了”）；结局已经发生了，但是承诺还没有被验证。

验证为何如此重要？实际上，每个可能的观察者都应该是知晓相关信息，能够对承诺是否得到实现进行独立的判断的。承诺人可能是受承诺影响最大的人，但是不会是唯一一个能够发声的人。

例如，Alice承诺要付钱给Bob。如果Alice在Bob不在场的情况下进行转账，Bob必须要检查账号才能确定承诺是否达成。然而Carol作为旁观者，听到了这一承诺，Alice转账时她刚好在场。因此她可以验证承诺是否完成。Bob和Carol所接触到的信息是不同的，因此他们有不同的校验承诺后果的方法。

这样每个自治的代理人都有自己的独立视角，意味着代理人都有自己的独立的预期。因此代理人无需校验后果即可做出判断。这是将承诺与信任结合使用的方式。每一个可能的观察者，都能访问到部分信息，能够独立的做出判断，在不同的环境下，可能的处不同的结论。

这是很像一个商业上的陈词滥调——“顾客永远是对的”。每个观察者都有权利拥有自己的观点。承诺的一个有益的副产品，就是记录代理人做出决策时所处的条件，以备后续使用。

文化和心理学

承诺理论的优势，在文化或心理方面都是可以证实的。在洗手间示例的命令版本中，可以写一个算法来实现所需的最终状态。您的算法可能涉及一份清单，比如擦洗马桶、使用特殊清洁剂等等。写下这些步骤给人以教育意义，因为它告诉你如何做。这对于教导别人如何在未来遵守承诺可能是有益的，但它并没有明确说明最终结果应该是什么样子，或者是否存在多种实现目标的方式。因此，在没有承诺的情况下无法评估算法。通过承诺，我们可以明确所期望达到的最终状态，并讨论实现它的其他方法。”

“How”是设计师的任务。那么关于运行和维护过程如何保证承诺在各种困难环境上都能达成呢？在信息技术领域，设计被翻译为“开发”，而维护则被翻译为“运维”，二者通常被称为DevOps。

想象一本菜谱，通常来说，每一页刚开头都是一个关于预期结果的承诺（一张诱人的成品照），接下来就是一个建议的配方。菜谱里通常不会直接抛给你一个配方，强迫你信任配方，一步一步操作最终得到结果，菜谱中首先给你的，正是一个预期。而在编程和管理方面，通常都不是这样做事的。

承诺与服务的概念是自然契合的。任何在服务或支持角色中工作过的人都会知道，你所做的事情并不是理解的最佳指南：“别告诉我你在做什么，告诉我你想要实现什么！” 你实际上正在做的事情可能与你想要实现的目标毫无关系。

一个简单的意图表达就是所谓的承诺提议。当你真心实意地说出来时，它就变成了一种承诺。

义务的局限性

强制性活动，尤其是“义务”，存在一个重大问题，那就是它们并不能减少我们对情况的不确定性。实际上，它们可能会增加不确定性。由于义务涉及到我们在某个领域中肯定拥有不完整信息的世界，所以很快就会导致冲突。

想象一对父母和一个孩子。妈妈和爸爸以以下方式将他们的语言模式强加给他们无辜的后代。美国妈妈告诉孩子：“你说tomaetoe”，而英国爸爸则说：“我说tomahtoe”。除非他们真正承诺沟通并达成共识，否则妈妈和爸爸可能甚至没有意识到自己在告诉孩子不同的事情。因此存在利益冲突。

但是这情况的糟糕程度不止于此。因为意图的源头是孩子无法控制的，所以她对这个冲突完全无能为力；问题源自在于她无法控制的领域之外：在爸爸妈妈身上。义务实际上增加了这个孩子眼中的不确定性。

解决之道在于让所有的的代理人具备自治能力。孩子和父母都无需听从命令或者履行义务。他们有拒绝的自由，并选择其它方式做出自己的决定。实际上，一旦从这种视角出发，孩子就需要对父母承诺她试图说出的话。实际上，她现在掌握着信息和控制权，可以承诺对妈妈说一件事情，对爸爸说另一件事情而毫无冲突。

这是伪科学？

承诺或者意图是充满人类因素的东西，这种东西和客观可衡量的现实世界里的结果结合在一起，会让科学家（除了某些社会科学家）和工程师们感觉很不舒服。我们受到的教育要求我们在自然科学中消除人为因素的参照，以保持客观。这种情况的部分原因是我们忘记了让我们走到今天的科学哲学，所以我们相信自然科学在某种意义上是“客观”的

科学家（除了某些社会科学家可能例外）和工程师对将像承诺或意图这样的人类因素与似乎客观可衡量的现实世界结果混合在一起的想法感到不舒服。我们被教导要在自然科学中消除所有关于人性的参照，以使其尽可能客观。部分原因是我们已经忘记了让我们走到今天这一步的科学哲学，所以现在我们相信自然科学在某种意义上是“客观”的（不仅仅是中立）。

在我另一本书（《Search of Certainty》）中。描述了在自然科学领域中，科学是如何被最难的问题强迫面对观察者相对性问题（或者换个说法叫主观问题）的，这是一个意外的转折。作为一名物理学家，我花了好一段时间才接受了这一事实——人类问题的确需要体现在技术研究过程中。这一过程甚至无需触及情感、或者针对特权阶级的道德谴责等问题。

承诺必命令或义务更基础，这并不难理解。他可以类比到简单的物理学：承诺是局部的，而义务是分布的（非局部的）。

承诺理论的目标是将变化（动态）和意图（语义）结合起来，形成一种简单的工程方法论，以认识到在处理不完整信息时存在的限制。谁有权访问哪些信息？

在我们描述某些行为时，我们对它在时间和空间上的持续性有什么期望？这是爆炸一样的一次性的变化，还是和平条约一样的持续平衡呢？

语义和动态 动态是可以测量的系统方面，比如大小、速度、频率等。系统的动态可以客观地用数字（“数据”）来描述，并且这些数字独立于解释存在。在科学中，也使用了力学和运动学这些词汇，但对广大受众来说它们不太熟悉。语义是关于我们如何解释某个事物：它意味着什么，它有什么功能，我们给予它什么样的重要性？语义是主观的（即取决于观察者）；因此根据相同的动态数据评估一项承诺是否履行，不同的人可能得出不同的结果。

承诺理论真的是理论么

像任何科学方法一样，承诺理论并不是针对特定问题的解决方案；它是一种描述和讨论不同代理人或行为者之间合作行为的信息语言。如果您在其假设和习语框架内操作，它将帮助您构建假设并找到涉及分布式信息的问题的可能的解决方案。

承诺理论是一种对协作系统进行建模的方法，它帮助我们评估系统的可靠性和效率。要准确评估，参与协作的代理人必须能够承诺满足一些基本条件，以确保系统的有效运作。

承诺理论也是一种原子理论。它鼓励我们将问题分解成一个元素表（基本承诺），一旦关于自身的意图被公开，它就变成了一个承诺，意图之间的组合就像化学反应一样，可能产生各种实质性的结果。SOA定义了具有接口（API），并且由文档完善的的自治服务（代理人）组成，因此是以Web服务和API为基础的承诺模型的一个例子。

承诺理论背后的原则存在是为了遵从普遍性，并尽可能少地做出预测。承诺理论还容许每个参与者持有不完整的世界观（即存在不同观点），从而在所见所闻方面产生局限性。

和其他的科学模型相比，承诺理论的不同之处在于，他用客观的方式对意图进行建模，而不会去管这意图直接来自人类还是某种技术。将承诺理论与博弈论模型相结合，我们还可以看到如何用经济型来解释合作（有时被称为有限理性）。我为什么应该遵守我的承诺？我会得到什么好处呢？

主要概念

我们会时常引用几个关键概念：

意图（Intention）：这是某种可能结果的主体。它可以被解释为在特定背景下具有重要意义的事物。任何代理人（人、物体或机器）都可以怀有意图。一个意图可能是灯光“变红”，或者是运动员“赢得比赛”的目标。
承诺（Promise）：当一个意图（范围）宣布时，它就变成了承诺。因此，承诺是一种明确的意图。在本书中，我只会谈论所谓的第一类承诺，也就是关于自己的承诺。换句话说，我们制定了一个规则：任何代理人都不能代表他人作出承诺（见图1-2）。

![[images/20231228.png]] 图 1-2 承诺堪比丘比特之箭

强加：这是一种试图引导另一个代理合作的尝试（即植入意图）。它是对承诺概念的补充。强加程度包括暗示、建议、请求、命令等。 ![[images/20240105.png]] 图 1-3 强加像是一种攻击
义务：一种暗示：如果不遵守将会产生成本或惩罚的强制措施。它比简单的强制措施更具侵略性。
评估：对于一个承诺是否得到了履行的判断。每个代理人都会对其所知的承诺进行评估。通常，评估涉及观察其他代理人的行为。
其他：还有一些其它层次的代理人之间的互动。例如，可以强迫代理遵从要求，这可能被定义为一种攻击；然而，我们不会进一步讨论这个问题，从而避免引发道德争论。

承诺比强制更常见，因此成为主要关注的重点。强制通常在现有承诺的体系中起作用。此外，承诺通常可以被提出来以等效的自愿行为取代强制。

相对于强制来说，承诺是更为常见的情况，因此我们会主要关注承诺方面的问题。当然，在承诺系统中，强加的方式也是能够奏效的，不过可以用等效的自愿承诺，来取代强加方式。

你要多少确定性

承诺理论还是处在一个研究阶段，所以我们不应期待用这一理论解答一切问题。另外它也综合了图论、相对论等其它理论中的思想，所以它也不是一个全新的理论。这一理论从一组最小的假设出发，然后从总体角度的各个视角来描述独立承诺的联合效果，构建一张协作网络。如果你想更加深入的理解它，我鼓励你用正式的、数学的语言来研究它。

承诺是个常用词，很容易让人产生各种联想。在承诺理论中，它有着特定而明确的含义。其他人也将这个词用于技术用途：并发编程中讨论了未来和承诺。这同样是给普通词汇赋予了专门的含义。我们需要小心，不要将太多自己的想象投射到这些特定的含义中。

在阅读本书的过程中，你会发现承诺理论提出了很多似乎显而易见的观点。这是一件好事。毕竟，一个不能预测明显事物的理论不会是一个很好的理论。然后，还会有其他结论用不熟悉的方式延展你的思维；可能会让你透过文化偏见，更清晰地看到事物。你还可能觉得这个理论缺乏惊人启示，失望透顶；或者你可能会对之前从未意识到的事物感到惊讶。这一切取决于你的思考的起点。无论你的经验如何，我希望这本书能为你提供一些关于合作系统的构建和设计的见解。

快速用户指南

在深入细节之前，首先简要概述一下如何开始以承诺的方式思考。这里归结了几条经验法则：

识别关键参与者（意图代理人）

建模的第一步，是在您所解决的问题范围内，识别扮演角色的代理人。系统的任何部分都可能是代理人，代理人可以独立地直接或者间接的对某事发起意图或承诺。代理人可能是人，也可能是计算机、政策文件等等，无论其原始来源如何，只要能发起意图的任何东西都可以是代理人。

为了正确进行建模的这一步骤，我们需要小心不要把意图与行动或消息混淆起来。行动未必是实现意图所必需的。无动作可能也是必要的。

此外，简单的工具也可以发起承诺。简单如钟表零件，甚至是一个 HTTP 的请求，都可能作为代理人的身份出现。在更大的视野中，最终阶段发挥作用的并不一定是人。

要想独立，一个代理只需要有不同的思考方式或者不同的视角，能够接触到不同的信息等等。这关乎关注点的分离。如果我们希望能够以不同方式推理的代理共同工作，它们就需要承诺以互惠互利的方式行事。这些代理可以是人类（如在商业-IT桥梁中的情况），也可以是计算机（如在多层服务器队列中的情况）。

可以用不同的思考方式、不同的视角或者能够接触到的不同信息，将代理人独立出来。这是符合关注点分离原则的做法。各种不同的代理人要协同工作，就需要做出互惠互利的承诺。代理人可以是人类，也可以是计算机。

处理不确定性和障碍

代理能够履行承诺的可能性有多大？真实世界是没有绝对的确定性的，所以忘记这个不切实际的想法吧！科学正是用来应对不确定性的，所以只管卷起袖子，依据现有条件来设计你的承诺，使其达到最佳效果。这方面是有些技巧可以使用的。

关键在于，可能存在种种原因让承诺无法履行。承诺只是意图，而非不可抗力。

机器和人都可能出故障，无法履行承诺，因此我们需要对此进行建模。基于我们对每个承诺的未来行为的信任或信念，每个承诺都存在一定的可能性（甚至可能是正式的概率）。

然而，代理人只对自己的行为作出承诺。如果我们试图代表他人做出承诺，就很可能遭到拒绝而无法实施——甚至另一个代理根本对这一企图一无所知。因此，合理的模型是拉取或者使用其它代理的承诺，而不应该把承诺推动或强加于其它代理。它假设代理只有在他们愿意的情况下才会遵从于外部强制（也就是说武力无法推动控制）。这意味着我们面对的现实情况里，不存在军事指挥结构这样的东西。应该认为代理人实际上存在产生共识、自愿遵从命令的情况——但是这种机制是有失败几率的。

从要求到承诺（从自上而下到自下而上）

承诺理论关注主动代理的两个原因：首先，因为这些代理最了解自己履行承诺的能力。其次，因为主动代理是可以轻易加入到任何更大的合作行为中的基本构建块。要求是自上而下地被强加的。承诺则是自下而上地被遵守的。

这和原子理论有些相似——没有人能在元素周期表中强行创造一个新元素。假设设计飞机的过程中，需要一种强度是钢的两倍、但重量只有铝的一半的金属元素——在物理定律的妨碍下，恐怕你只能写信给圣诞老人求助了。我们可以当然可以梦想那些根本不可能的事物，但如果我们放弃不切实际的梦想，而真正去了解世界所做出的承诺，并尝试在此基础上进行构建，我们就会取得真正的进步。从基本元素的承诺出发，我们可以通过理解不同类型原子及其不同属性（即承诺的行为方式）的结合，构建出具有新材料属性的元素组合。

这是一种自下而上的策略。从上到下的视角不是分布式的。因为缺乏对信息定位的清晰思考，你可能会做出无权做出的假设；例如，你可能会想要代表你无法控制的代理出承诺。

自下而上的方式下，因为你需要提出明确的承诺来应对每种假设，所以你必须知道事情的具体运转。这样一来，承诺方法强制性地引入了一种纪律。

这不就是讨论种笨拙的讨论需求的方式吗？其实并非如此。这恰恰相反。需求是从高层次的泛化出发，对更专业的执行层面提出义务。在要求者和被要求者之间，存在显而易见的的信息差。关于可能结果的重要信息处于这个差距的错误一端。从承诺的角度出发，就被迫只能从执行的角度思考，并将自己置于履行承诺的角色中，面对所有出现的问题。从这个视角出发，就很难做出做出无端的假设。

用承诺的方式思考，应急计划就是个顺理成章的事情——如果你的第一个假设失败了怎么办？

承诺的立场是一个极端的立场，你可能会基于某些传统观念而反对它。正因为它是一个极端的立场，它才有用。如果做出了任何假设，都可以用承诺的方式进行承诺，并用承诺的形式来应对外部影响以及任何合规要。但是一旦我们打开了怀疑的大门，就无法回头。所以承诺理论是建立具有预测能力理论的唯一的合理选择。

承诺理论的目标是确保各个代理通过做出所有必要的承诺来协作并取得成功。假设有一个拥有所有信息的神奇旁观者，那么在他眼里，整个合作行动可以被视为一个单一有机体做出的单一承诺。怎样才能促使这些主体做出承诺，取决于它们是什么类型的主体。经济激励能让人类做出承诺；而可编程的主题，那么它们需要被编程来履行这些承诺。我们称这种行为是自愿合作。对于人类来说，经济因素包括社会、专业和经济方面。

这听起来疯狂吗？为什么不像机械钟那样强迫每个人遵守规则呢？因为这毫无意义。即使是计算机，也只是因为它被自愿构建为遵循指令而遵循指令。如果我们无法通过拔掉其输入线的方式来改变这个承诺。人类也不能被外部代理强制实施——除非通过攻击手段让代理失去独立性。

处理意图冲突

如果所有代理拥有相同的意图，那么就不太需要承诺。每个人都会和谐相处，为共同的目标而努力。然而，一个系统的初始状态拥有未知的意图和分散的信息，这意味着我们需要建立像协议这样的东西，在其中代理承诺以特定方式行事。这就是我们所说的协调。

但如果不同地点的承诺无意中影响到第三方会怎样呢？这种情况经常发生——在义务理论（要求、法律和分布式许可模型）中，冲突的可能性非常高。承诺理论在解决冲突方面相当有效，因为一个代理只能与自己发生冲突，因此解决冲突的所有信息都位于同一个地方。

尽管去做

在一些人眼里，承诺理论是颠倒是非的。他们想要用义务来思考。A应该做B，C必须做D，等等。但除了激怒人的尊严感之外，这种方法很快就会导致可证明的矛盾。问题在于，任何义务的来源（施加义务者）都是存在于主体之外。因此，如果代理不愿意或无法合作（可能是因为它根本没有收到信息），那么除非解决另一个分布式合作问题，弄清楚出了什么错的情况下，才能解决这个问题！如此这般，令人作呕。（人们开始看到信任中心化推送模型和独立监控系统的谬误。）

“承诺理论假设一个代理只能对其自身的行为做出承诺（因为它只能控制自己），这一点解决了信息分布所带来的问题，确保解决任何问题所需的信息和资源都是本地的且代理可以获取。通过这种方式，代理可以通过承担责任来自主地修复一个承诺。这就是代理的含义。

一个练习

尝试用承诺而不是欲望、要求、需求等来思考的能力。花一整天时间思考人们、地方、过程和事物所做的承诺：

承诺是向谁做出的？
承诺是以何种形式做出的？
它们是否依赖于其他事物来帮助它们履行承诺？
这些事物是如何尝试履行它们的承诺的？
如何评估承诺是否成功？

不要错过任何事情：从的睡床（它让你背疼了吗？），到晨练计划（它会减少脂肪吗？），你吃的食物（它新鲜、美味吗？），你合作的人们（他们的角色是什么？），你生活的城市，一直到你一天结束时使用的牙刷。

如果你看不到任何承诺，试着问自己：这些事物的预期功能是什么？我与这些事物的关系是什么？我在它们身上看到了什么价值？最后，你添加了哪些额外的解释，这些并不属于你周围的承诺？金钱对你意味着生活方式、娱乐和未雨绸缪？

在一天结束时，你将更好地理解我们所说的世界中的语义和意图性，并且准备好用这种思维应对各种情况。

试译：Thinking in Promises

Thu, 11 Jan 2024 01:00:42 +0800

前段时间在摸索配置管理问题时，偶然翻到了这本书，作者 Mark Burgess 是个会作曲会画画的理论物理学家，同时在管理一堆服务器的时候，编写了 CFEngine 这个鼻祖级的配置管理工具。这本书在我的程度来说，相当难读，但是又解决了我过去很多考虑不清甚至尚未觉察的底层问题，因此试着抽空把它翻译出来，也当做是自己的一个学习过程。

用 KEDA 根据工作负载进行快速扩容

Wed, 29 Nov 2023 15:21:04 +0800

太长不看版：用单一指标指导单一工作负载进行扩缩容实在是太低效了。

历史问题

众所周知，Kubernetes 有个亲生的 HPA 组件，在云原生早期，这个名义上的自动扩缩容的能力给 Kubernetes 赢得了不少掌声。当然现在回头看看，仅仅根据 CPU 和内存这样“贫瘠”的指标，不论是用于判断负载水平，还是用于计算扩容目标，都不是很够用的。这个阶段里，HPA 的扩缩容效率也是广受诟病的一个问题，在一个多级微服务调用的业务场景里，压力是逐级传递的，下图展示了一个常见情况：

如上图，用户流量进入集群之后：

首先在 Deploy A 造成负载，指标变化迫使 Deploy A 扩容
A 扩容之后，吞吐量变大，B 受到压力，再次采集到指标变化，扩容 Deploy B
B 吞吐变大，C ..

这个逐级传递的过程不仅缓慢，而且可以说是步步惊心——每一级的扩容都是直接被 CPU 或内存的飙高触发的，被“冲垮”的可能性是普遍存在的。这种被动、滞后的方式，很明显是有问题的。

推陈出新

造成 HPA 窘境的原因之一，就是“自扫门前雪”，每个 Pod 都只能根据自身负载情况来进行扩缩容决策。如果能够直接根据业务流量的变化进行决策，并且将流量流经的所有微服务进行扩缩容，看起来情况就会好很多了。 HPA 的自定义指标支持，给这个问题了一个可行的方案。该能力让 HPA 可以用其它的指标来作为扩缩容的触发器，例如我们可以用 Promethues 采集消息中间件的深度或者负载均衡器的队列长度，作为一个更能如实反映业务流量的指标，直接用来触发相关的多个微服务的扩缩容，如下图所示：

在上图中：

Prometheus 采集消息队列和负载均衡等更能反映业务流量的指标
使用 Prometheus Adapter 将 Promethues Metrics 转换为 Kubernetes 的 Aggregated API
HPA 使用自定义指标，同时对多个应用进行扩缩容。

这中间涉及到的 Prometheus Adapter，通过配置文件完成步骤 2 的转换：

- seriesQuery: '{__name__=~"^container_.*_total",container!="POD",namespace!="",pod!=""}'
  resources:
    overrides:
      namespace: {resource: "namespace"}
      pod: {resource: "pod"}
  seriesFilters:
  # since this is a superset of the query above, we introduce an additional filter here
  - isNot: "^container_.*_seconds_total$"
  name: {matches: "^container_(.*)_total$"}
  metricsQuery: "sum(rate(<<.Series>>{<<.LabelMatchers>>,container!="POD"}[2m])) by (<<.GroupBy>>)"

当然，完全可以自行实现 Aggregated API 来支持这种指标的采集和呈现工作。Prometheus 所提供的大量 Exporter 是吸引我们写这种古怪语法的最大动力。

那么如果是 KEDA 的话，这个问题又如何呢？KEDA 提供了几十个被称为 Scaler 的东西，其中除了 Promethues 之外，还包括 Kafka、Redis、PostgreSQL 等多种选择。所以在很多场景中，无需 Promethues，也能使用 Scaler 完成对输入指标的读取和判断。下面用 KEDA 为例，看看这种伸缩方法的具体实现。

KEDA

假设一个容器化应用由多个工作负载组成：

Ingress：负责接收业务流量
Backend 1、Backend 2：负责处理 Ingress 发来的任务
Database：数据库

我们希望达成的效果是 —— Ingress、Backend 1、Backend 2、Database，实例数量保持在 1:2:1.5:2 的关系，Keda 的大致流程如下图所示：

首先使用 Helm 安装 KEDA：

$ helm repo add kedacore https://kedacore.github.io/charts
$ helm install keda kedacore/keda --namespace default
NAME: keda
LAST DEPLOYED: Wed Nov 29 18:56:36 2023
NAMESPACE: default
STATUS: deployed
REVISION: 1
...

随便创建几个工作负载，冒充微服务：

$ kubectl create deploy ingress --image=nginx
deployment.apps/ingress created
$ kubectl create deploy backend1 --image=nginx
deployment.apps/backend1 created
$ kubectl create deploy backend2 --image=nginx
deployment.apps/backend2 created
$ kubectl create deploy database --image=nginx
deployment.apps/database created
$ kubectl get pods | cut -d - -f 1 | grep -v keda | sort
...
backend1
backend2
database
ingress

运行成功后，我们可以看到，四个微服务，每个微服务都有一个实例。

按照刚才瞎掰的比例，编写一个 ScaleObject：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: bk1
spec:
  scaleTargetRef:
    name: backend1
  triggers:
  - type: kubernetes-workload
    metadata: 
      podSelector: 'app=ingress'
      value: '0.5'
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: bk2
spec:
  scaleTargetRef:
    name: backend2
  triggers:
  - type: kubernetes-workload
    metadata: 
      podSelector: 'app=ingress'
      value: '0.67'      
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: db
spec:
  scaleTargetRef:
    name: database
  triggers:
  - type: kubernetes-workload
    metadata: 
      podSelector: 'app=ingress'
      value: '0.5'

上述代码引入了 kubernetes-workload 类型的触发器，他会监控 app=ingress 的容器，并对 scaleTargetRef 中提到的工作负载数量比例进行扩缩容。

提交到集群之后，会看到实例数量数量发生了变化：

$ kubectl get pods | cut -d - -f 1 | sort | uniq --count
...
   2 backend1
   2 backend2
   2 database
   1 ingress
   3 keda

我们把 Ingress 扩容到 2 实例，再次统计：

$ kubectl scale deployment ingress --replicas=2
deployment.apps/ingress scaled
$ kubectl get pods | cut -d - -f 1 | sort | uniq --count
...
   4 backend1
   3 backend2
   4 database
   2 ingress
   3 keda

可以看到，的确是按照我们设定的比例，同步产生了缩放。如果缩减 Ingress 服务实例数，几分钟之后，其它工作负载也会随之缩容。

$ kubectl scale deployment ingress --replicas=1
deployment.apps/ingress scaled
$ kubectl get pods | cut -d - -f 1 | sort | uniq --count                                                         \
...
   2 backend1
   2 backend2
   2 database
   1 ingress

结论

虽说云原生架构的复杂性问题越来越被强调，但是这一生态的宗旨应该还是没有变化——用简单的透明的手段解决复杂问题。

平台工程六大支柱

Sun, 12 Nov 2023 22:34:09 +0800

原文：Six pillars of platform engineering

作者：Michael Fonseca

平台工程和开发体验

平台工程是用来设计、构建工具链和工作流的方法，软件工程师团队在这些工具和流程的帮助下，获得自助服务的能力。这些工具和流程被称为内部开发平台，经常会被简称为平台。平台团队的目标是提高开发生产力、加快发布节奏、提高应用稳定性、降低安全及合规风险，以及降低成本。

HashiCorp 曾经协助很多组织通过平台团队来扩展其云运营模型，平台团队必须提供让开发者满意的体验才能达成目标。我们在这些经验中看到了两种提高开发者体验的方式：

对基础设施服务进行标准化，减少开发人员和运维团队之间的摩擦：小而集中的平台工程师团队能够使用合适的工具（例如 API、文档和推广等），来改善整个组织的开发者体验。目标是减少工具和流程碎片化，从而提高软件交付系统和环境的核心稳定性。
平台即产品：传统的 IT 项目通常有一个确定的开始和结束日期。但内部开发平台永远不会真正完成。包括 Backlog 管理、定期功能发布以及为利益相关者更新路线图等工作都是需要持续进行的。因此要以迭代和敏捷思维方式进行开发，而不是像瀑布式开发那样进行大规模的前期规划。

平台不是凭空产生的。只有在开发者想要使用平台的时候，平台才是有效的。构建和管理平台的过程中，需要持续的和开发者（平台用户）和利益相关人进行对话，并接纳其需求。本指南试图为平台团队提供一个对话的切入点，围绕软件交付过程中的六个技术元素（或者支柱）进行讨论，探讨每个要素的流程和一般需求，最终用这些要素进行产品组织。

平台工程的六大支柱

平台战略有哪些组成部分？在和业界大量客户协作的过程中，HashiCorp 认为，平台由六大基础元素组成。

安全
流水线（版本管理和 CI/CD）
基础设施发放
网络连通
编排
可观测性

接下来的章节会对这些要素的定义、流程、需求、依赖以及实现过程进行阐述。

支柱 1：安全

不管使用什么系统，开发者的第一个问题大概会是——“如何创建账号？怎么设置凭据？哪里能拿到 API Key？”虽说版本控制、持续集成以及基础设施发放才是平台工程的核心业务，然而默认安全是平台体验的基本要求。

历史上，很多组织都会构建基于网络边界的安全能力，形成一种“城堡+护城河”的防御方式。然而现在的基础设施变得越来越动态，边界也就越来越模糊，兼顾生产力和控制力，难度越来越高。

头部公司开始使用基于身份的安全、身份代理方案，以及凭据集中管理、加密方法论等现代方法来应对这一挑战。这些手段提高了审计过程的可见性和持续性，并且降低了碎片化方案带来的运营开销。

这些公司普遍采用了安全左移的策略：在软件开发的全生命周期中实现安全控制，尽早识别和修复潜在的攻击路径，并提高对审计以及合规的重视。这种方法不是临时措施，而应该是默认的用自动化的方式运行的。

DevSecOps 要求使用身份驱动的安全工具，并且用 As Code 的方式进行实现，而避免使用工单驱动的赋权过程。这种方式在传统和（例如基于特权的访问管理方式（PAM））和现代的安全方法论（例如 JIT 访问以及零信任）之间架设了桥梁。

身份代理

在云运营模型中，人类、应用和服务都有自己的身份，用权威的中性化机构对这些身份进行认证。可以使用身份供应者（idP）结合多租户机密管理和加密平台来作为组织的身份代理。

工作流：身份代理

在真实世界里，典型的身份代理工作流大概是这样的：

请求：人、应用或者服务发出请求，开始互动。
校验：一或多个 IDP 根据一或多个真相来源对这个身份进行验证。
响应：认证和鉴权结果会被反馈给发起者。

身份代理需求列表

身份代理有几个要素：

所有的人、应用和服务都有定义完善的身份
可以使用可信的 idP 进行认证
身份系统提供跨越多云、多运行时的互操作性
身份系统应该是中心化的，仅进行有限的分段，简化审计和多环境下的运营管理
为每个 idP 构建身份和访问管理（IAM）能力
客户端必须为认证和鉴权提供有效的身份
通过验证之后，就开始以默认拒绝的策略来进行访问，如果身份泄漏，这种策略能将最小化可能的不良后果
鉴权过程和审计一体化，如果能够做到即时（JIT）就更好了
- 定期对审计日志进行审核，以识别过于宽泛或未被利用的权限，并在威胁检测后进行追溯分析。
- 审计数据是不可抵赖的，并且用合规的方式进行存储。
通过支持异构运行时的灵活身份代理系统来防止碎片化：
- 平台（VMWare、Azure 虚拟机、Kubernetes/OpenShift 等）
- 客户端（开发人员、运维人员、应用、脚本等）
- 服务（MySQL、MSSQL、活动目录、LDAP、PKI 等）
包含确定 SLA 的 24/7/365 的企业级保障能力
自动化能力（IaC、Runbook 等）

访问管理：机密管理和加密

有了身份之后，客户会需要有办法操作机密数据，例如：

获取机密数据（凭据、密码、密钥等）
访问安全目标
管理安全数据（加密、解密、哈希、掩码等）

这些机制应该只需要极少的人工干预即可完成设置，更高的自动化水平更容易达成合规要求。这一能力还应该是可扩展的，确保后续能够有更多的工具加入系统。

工作流：机密管理和加密

典型的机密管理工作流应该包含五个关键步骤：

请求：客户（人、应用或服务）请求一个机密。
验证：idP 验证该请求
请求：如果机密由被请求的平台管理，那么这个请求会被平台处理，还有可能：
- 平台向第三方请求一个临时凭据
- 第三方系统为这个代理请求返回一个短生命周期的机密
代理响应：初始响应通过 IAM 加密屏障进行卸载或缓存。
客户端响应：最终响应返回给请求方

访问管理：安全的远程访问（人机交互）

传统上基于城堡-护城河模式的人机交互是不够的。传统过程需要用到多种身份，有认证和鉴权过程的介入，管理机密的生命周期，以及复杂的网络分区，这会造成非常大的开销。

过去十年中，尽管 PAM 解决方案已经发展出委托（如动态生成 SSH 密钥）能力，但这并不能满足更广泛的生态系统需求，包括多运行时审计或跨平台身份管理。引入云架构模式，如临时资源、异构云网络拓扑和即时身份管理进一步增加了传统解决方案的复杂性。

临时资源及其带来的复杂性问题，例如动态资源注册、身份、访问以及机密等问题，被一种现代方案解决了。这种现代的安全的远程访问方案不再依赖 VPN、CMDB、堡垒机、人工 SSH、机密数据签入签出等传统工作流。

企业级的安全访问工具可以使用零信任方案。这种方案里，用户和资源都有其身份，用户直接连接资源。通过动态资源注册表、控制器和密钥，作用域角色会自动注入到资源中，这样就消除了许多手动流程和安全风险，如频繁的网络打通和长期存在的密钥。

工作流：安全的远程访问（人机交互）

现代的远程基础设施访问工作流，通常有如下八个步骤：

请求：用户请求访问系统
验证（用户）：通过身份代理校验该用户的有效性
验证（到机器）：通过认证之后，进行鉴权，查看该用户对目标的权限。
请求：平台为目标系统申请一个凭据（静态的或者短期的）
注入凭据：平台把凭据注入到目标资源里
代理响应：平台向返回一个认证代理返回一个响应
客户端响应：平台授权给最终用户
访问机器/数据库：用户使用现代的安全远程访问协议访问目标资源

访问管理需求列表

机密管理系统应该包含：

中心化
传输和存储中的加密
用范围角色和访问策略进行限制
尽可能动态生成
时间相关（TTL）
全程可审计

机密管理应该有如下能力：

支持多运行时、多云以及混合云部署
提供弹性集成能力
有多样化的生态系统
拥抱零接触的自动化能力（API 驱动）
在范围边界里，通过开发者和委托实现决策。
具备各个领域的良好的文档
根据 SLA 提供 24/7/365 的企业级支持
支持自动化配置（IaC、Runbook）

另外，要实现远程访问，应该提供：

动态注册的服务目录
实现身份模型
提供面向多种认证源的认证能力
可以用代码的形式进行配置
提供 API 用于审核以及批准
能够将密钥注入资源
提供细颗粒的 RBAC
记录动作、命令、会话等用于审计
高可用，多平台，多云能力，支持分布式运营，并且具备应对事故的弹性

支柱 2：流水线（版本管理、CI/CD）

平台团队的第一步通常是和软件交付流水线进行集成，或者重构。在这之前首先要审视一下团队所在组织的版本管理系统和 CI/CD 流水线。

很多组织都会有多个成熟程度不一的版本管理系统和 CI/CD 流水线。这些平台还在演进之中，所以建议采用基于组件的 API 平台或目录模型，以支持未来的可扩展性，这样就可以避免在功能上进行妥协，或者反复重构了。

在云原生模型里，基础设施和配置都是用代码的方式被管理的，因此版本管理系统是这一功能的核心。版本控制系统在这里起到了以下作用：

持久化和标准化
敏捷和效率
规模和弹性
配置即文档
复用和共享
灾难恢复和可重现性
合规与安全

版本管理系统和 CI/CD 使得跨基础设施、跨平台的交互称为可能，因此需要对这两个元素进行详细的评估。

工作流：版本控制和 CI/CD

典型的版本控制和 CI/CD 工作流有五个步骤：

编码：开发人员把代码提交到 VCS，随后自动触发流水线
校验：CI/CD 平台向 idP 发起验证请求（认证和鉴权）
响应：如果校验成功，流水线开始执行任务（测试、构建和部署）
输出：输出和制品被分享给平台组建或者外部系统，用于后续处理
操作：可能会进行一些安全方面的后续处理，例如权限清理等。

VCS 和 CI/CD 需求列表

成功的 VCS 和 CI/CD 解决方案应该提供：

打造具备现代效率，并且满足团队需要的使用体验
易于上手
平缓的学习曲线，只需要少量支持培训（利用业界标准工具）
完整的易于访问的文档
流水线即代码
平台无关（API 驱动）
内置安全控制（RBAC、审计等）
和平台集成机密数据管理、认证和健全
鼓励和支持伙伴生态以及企业技术集成
扩展服务范围，运行人员可授权和隔离控制范围
企业级的 SLA（24/7/365）

VCS 和 CI/CD 系统可能有一些别的特别需求。

平台团队选择和演进他们的 VCS 和 CI/CD 解决方案，要考虑存量/传统的基础设施发放、安全以及合规要求的转型。团队应该假设新平台会影响到存量实践，应该识别、协作和协调随之而来的变化。

平台团队还要有前瞻性。VCS 和 CI/CD 平台会用更多的抽象来让研发人员远离 CI/CD 过程的复杂性。面对包含 Kubernetes 和 Serverless 在内的多种运行环境，HashiCorp 希望用 Waypoint 产品来提供对部署、管理和可观测性的支持。

流水线支柱：HashiCorp 和合作伙伴（VCS 以及 CI/CD）的方案 VCS：GitHub、GitLab、BitBucket CI/CD：Jenkins、CircleCI、GitHub Action 在目前，方案中的这些选择属于各个领域里面的最流行工具。这些工具已经流行超过十年，所以 HashiCorp 也就没有提供自己的 VCS 或者 CI/CD 方案。 HashiCorp 提供的是在各个平台之上的新的控制层，为平台工程师提供真正的一致的（Kubernetes、ECS 等）平台即服务（PaaS）工作流。HashiCorp Waypoint 承担了这一任务，让开发者能够用统一的工作流来跨平台的构建和发布应用。Waypoint 中，开发者用一个简单的 waypoint up 命令就能把应用运行起来。

参考

支柱 3：基础设施发放

前面提到的两个支柱，平台团队提供了自服务的 VCS 和 CI/CD 流水线，并且提供了安全能力作为防护。这是软件交付的先决步骤。那么要运行应用的时候，面临的问题就是——在哪里运行？

每个 IT 组织都需要为应用进行基础设施规划，而平台团队则应该把资源规划视为能力的基础。基于工单的工作流是无法适用于现代的动态 IT 环境的，因此平台工程的首要目标就是消灭这种工作流。平台团队一般会构建自助的基础设施供应服务，这种服务给开发者提供了工作流、模板和工具，这种服务是消灭工单流程的关键举措。当然，这一能力要和前面提到的安全和 VCS 等支柱结合起来。

通常会使用 IaC（Infrastructure as Code）技术构建有效的、现代的基础设施平台。基础设施的配置和自动化被变成代码了，那么不管多复杂的基础设施场景，也都能进行自动化了。基础设施代码能够非常方便地进行版本控制，从而进行审计、迭代和协作。市面上有不少的 IaC 工具，不过最常见的还是 HashiCorp Terraform，他的市占率远超同类其他产品。

大量组织采用 Terraform 的原因是它的庞大生态。这一生态让平台工程师能够满足基础设施能力的一个主要需求：扩展性。扩展能力强的社区让平台工程师能够在不开发新代码的情况下，快速采用新技术和服务。

基础设施发放：模块和镜像

要构建标准化的基础设施工作流，就要把基础设施重构为可复用的组件，理想情况下，这些组件还应该是不可变更的。不可变基础设施在现代 IT 世界里是一个普遍标准，这种概念能有效的降低复杂性，简化了排障过程，同时也提高了可靠性和安全性。

不可变意味着所有的变更都是对基础设施进行删除-重建的过程，这样就最小化了对服务器进行补丁和配置变更的要求，确保每次服务迭代都是用的是新建的、经过测试以及更新过的实例。不可变还实际促进了 Runbook 校验以及故障演练、金丝雀部署等能力的实际落地。很多组织会使用 Terraform 或者其他类似的工具来落地不可变原则——仅需修改配置代码，就能构建或者重构建大量基础设施资源。有些组织还构建了黄金镜像流水线，所谓黄金镜像，指的是经过测试的、符合安全以及合规需求的机器镜像，这种流水线专门用于黄金镜像的构建和部署。

除了机器镜像之外，现代 IT 组织还将基础设施代码组织成可复用的模块。软件开发的核心原则之一就是不要重新发明轮子，因此模块化对于基础设施代码化是非常重要的。模块化过程会根据架构原则，抽象出轻量级的模块，而避免直接使用孤立的对象。通常会对基础设施代码进行版本化管理，并和服务目录、测试框架等第三方系统进行交互。

高效 IT 团队会把黄金镜像流水线以及自己的模块仓库结合起来，来为应用程序构建基础设施。开发者无需知道太多的基础设施细节和内部机制，凭借黄金镜像流水线和基础设施模块，能够直接获得一个可重复、有弹性、可预测的工作流，其中甚至还包含了安全、合规以及最佳实践，

工作流：模块和镜像

典型的基础设施供应流程会有 6 个步骤：

编码：开发者提交代码，并向流水线提交任务
校验：CI/CD 平台向 idP 平台申请认证和鉴权
idP 响应：如果验证通过，流水线启动任务（例如测试、构建和部署）
请求：CI/CD 自动化工作流构建模块、制品、镜像以及其它基础设施组件
响应：（执行器）把响应结果（成功、失败，以及元数据）传递给 CI/CD 平台
输出：模块、制品以及镜像配置等基础设施组件被部署或者存储。

策略即代码

原本基础设施供应的重点被认为是运维问题，而敏捷开发实践已经将其转变为应用交付的需求。基础设施的发放现在已经变成了商业成功的基本要素。企业战略和顾客业务都和基础设施发放工作息息相关，这不仅仅关系到运维成本。

要实现转型，过程控制和工作流都是需要做出改变的。历史上，运维人员通过工单保障基础设施发放过程的合规。这些工单通常涉及鉴权、审批、安全性、成本等方面。整个过程都要进行合规性和控制实践的审计。

如今，开发人员和其它平台用户希望用自助方式来进行基础设施发放，这种流程必须改变。需要实现一系列的代码化安全控制以及护栏，满足合规和控制要求。

在云原生系统中，这些控制是通过策略即代码的方式来实现的。策略即代码是使用可编程的规则和条件，来完成应用和基础设施的部署，代码中包含了最佳实践、合规要求、安全规则以及成本控制。

有些工具和系统包含了自己的策略系统，也有高级策略引擎能够和多种系统进行集成。基本需求在于，在系统中能够使用代码的方式来管理策略，并且提供评估、控制、自动化以及反馈流程。

策略即代码造成了左移的效果，在基础设施发放过程中，能够更早的给用户提供反馈，并让用户能够更快更好地做出决策。策略是需要编写的。平台团队应该负责策略即代码的实践，协同安全、合规、审计以及基础设施团队，一起来保障策略的合理落地。

工作流：策略即代码

要在基础设施供应方面实现策略即代码，需要 5 个步骤：

编码：开发者提交代码，流水线发起任务
校验：CI/CD 平台向 idP 发起认证和鉴权请求
idP 响应：如果成功，流水线启动任务（例如测试、构建和部署）
请求：运行计划的基础设施交付任务之前，首先要通过策略引擎进行决策，确定放行还是拦截该资源计划
响应：包含元数据的响应内容经过 CI/CD 被发送给外部系统。

需求列表：基础设施发放

要用自助方式提供基础设施发放能力需要：

端到端自动化的控制和数据平面
自动化配置（IaC、Runbook）
预定义的、可配置的工作流
本地集成 VCS 和 CI/CD 工具
支持业务所需的多种容器和虚拟机镜像
为不同的角色和工作流提供不同的界面（GUI、API、CLI、SDK）
使用广为接受的 IaC 语言——强烈推荐声明式语言
和业界标准的测试、安全、加密以及机密管理系统保持兼容
能和通用的工作流组件（例如通知工具、Webhook）进行集成
支持代码化的门禁：
- 策略即代码：内置的能扩展的策略即代码引擎
- RBAC：以最小特权原则实现的细粒度访问控制
- 自动化流程中使用基于 Token 的访问凭据进行认证
- 组织级模块和批准模式，实现基础设施的分配工作的模板化
使用单点登录和 RBAC 可以集成到可信的鉴权 Provider
资源的元数据管理（状态、镜像、资源等）：
- 默认拒绝的控制
- 加密
- 为自然人和机器提供可编程的使用界面
- 用支持追溯的配置系统，对被管理对向进行隔离
可以支持大型分布式的团队
支持公开和私有模块
全面的审计和日志能力
用 FinOps 支持基于成本的政策和优化
明确定义的文档和开发者支持
基于 SLA（例如 24/7/365）的企业支持

基础设施支柱：HashiCorp 解决方案 HashiCorp Terraform：基础设施发放方面的业界标准。很多组织都已经采用了 Terraform Cloud 或者企业级 Terraform 作为基础设施发放工作流和护栏。 HashiCorp Packer：构建黄金镜像的事实标准。 HashiCorp Cloud Platform（HCP）Packer：提供了增强的镜像元数据管理能力，合规自动化以及全局镜像查询能力，HCP 是 HashiCorp 的托管云服务。

参考

支柱 4：网络连接

如今很多企业还在用传统的模式和硬件，平台工程的讨论中，很少会涉及到网络连接方面的话题。应用间的数据交换依赖网络，基础设施和应用程序的架构也都跟网络强相关，因此连接性问题也应该仔细斟酌。

创建 DNS 条目，打开防火墙端口，设置网络 ACL 或者更新流量路由规则等日常活动，传统上也是使用工单系统来驱动的。即使是基础设施管理流程已经完全自动化，这种玩法通常也会消耗整天甚至整个星期的时间。另外这些简单的更新通常是人工的、易错的，并且不利于在动态的云环境中执行。如果没有自动化的实现，在高速运转的公有云系统里，IP 地址和连接性这些事情都会琐碎、易变和难于管理。

为了适应现代动态环境，平台团队将网络功能、软件和设备引入其基础架构的代码配置中。这样可以将基础设施代码化带来的速度、可靠性和版本控制追溯性等优势带到网络领域。

组织采用了微服务架构之后，紧接着就会意识到软件驱动的服务发现和服务网格解决方案的价值。这些解决方案会基于集中策略自动发现服务和尝试连接服务，在零信任网络中，默认会拒绝服务与服务之间的连接，仅在得到授权的情况下才会进行连接。在这个模型中，有了基于服务的身份，才能确保对常见安全框架的遵从。

组织的中央共享注册表应该是多云、多区域和多运行时的，这意味着它可以连接各种集群类型，包括虚拟机、裸金属服务器、无服务器或 Kubernetes。团队需要尽量减少对传统网络入口或出口点的需求，以避免将他们的环境带回过时的基于网络边界的安全方法。

工作流：连接性

典型的网络连接工作流应该有八个步骤：

代码：开发者提交代码
- 注意：开发者应该在 RBAC 允许的情况下，能直接访问网络的控制平面。
校验：CI/CD 平台请求 idP 平台进行认证和鉴权
请求：执行请求内容，例如构建模块、拉取制品、使用内外部策略进行验证等，最终完成资源发放
发放：发放缺失的基础设施
配置：在连接性平台上进行配置
连接：目标系统基于根据既定策略进行更新
响应：用元数据的形式，把响应内容返回给 CI/CD 系统，并且通知外部系统执行其它操作，例如安全扫描或者集成测试。

连接性需求列表

成功的网络连接自动化需要：

中心化的共享仓库，用于发现、连接和加密跨地区、跨运行时和跨供应商的服务
支持多种角色和控制方式例如 API、GUI、CLI 和 SDK
健康检查
分段和管理模型
L4 和 L7 流量管理
实现注入深度防御、默认拒绝等安全方面的最佳实践
集成受信任的身份提供者，支持单点登录和 RBAC
支持审计
企业级 SLA 支持
支持自动配置（IaC、Runbook）

HashiCorp 的连接性解决方案 HashiCorp Consul 提供先进的基于服务的网络功能，支持常见用例，如服务发现和服务网格。Consul 解决了多平台应用连接性挑战，能够在异构环境（私有云和公共云）和运行时（主机、微服务、传统虚拟机或裸金属基础设施）之间桥接工作负载。

参考

支柱 5：编排

当开始部署应用工作负载的时候，如果要处理分布式应用、微服务或者希望在云基础设施上实现弹性，工作负载编排器会让事情变得简单。

相对于传统技术，Kubernetes 或者 HashiCorp Nomad 这样的工作负载编排器好处多多。不同的选择性投入，会得到不同的收益。例如将应用程序重构为容器化形态，进而采用 Kubernetes，其投入就远高于采用 HashiCorp Nomad 这样的编排器，这是因为 HashiCorp Nomad 的原始设计目的就是支持多种工作负载类型。不管如何选择，工作负载编排器应提供如下能力：

提高资源使用率
弹性扩缩容
多云以及混合云支持
开发者自助服务
服务发现和网络（内置插件）
高可用和故障隔离
高级调度能力
资源隔离和安全
成本优化

编排器提供了优化算法，来确定将工作负载分配到基础设施资源上的最佳方式（例如 bin-packing、分散、亲和、反亲和、自动伸缩、动态资源分配等），这会显著降低成本。这些调度算法能在无需开发者知悉细节的情况下，自动地完成算力分配和韧性设置。

和其它平台支柱一样，能够前瞻性地兼容未来的环境变化和多样性工作流世很有必要的。编排器还应当具备处理多租户以及跨云、跨数据中心的能力

记住，不是所有的系统（例如供应商提供的单体应用）都能被容器化，或者转换为现代编排器，所以团队应当帮助其它团队优化转型和自动化编排的流程。现代化编排器提供了很多原生能力。尽管具体的实现和功能在不同系统中有所差异，但存在一些共性的核心要求。

工作流：编排

典型的编排工作流应该包含八个步骤：

Code：开发者提交代码。
- 注意：开发者应该有在 RBAC 许可的情况下，直连网络控制平面的能力。
校验：CI/CD 平台申请 idP 进行认证和鉴权。
idP 响应：如果认证和鉴权成功，流水线启动普遍任务（测试、构建、部署）。
请求：平台执行任务，例如构建模块、下载制品或者使用内外部引擎进行校验等，完成资源发放
发放：发放和配置基础设施。
配置：对被编排资源进行配置
Job：编排器在目标基础设施上根据既定任务和策略运行 Job。
响应：将请求的完成情况反馈给 CI/CD 平台，以便进行后续处理或移交给外部系统执行后续动作，例如执行安全扫描或集成测试等。

编排器需求清单

成功的编排需要：

服务/批处理调度程序
灵活的任务驱动能力
可插拔设备接口
灵活的升级和发布策略
支持联邦部署
弹性、高可用的部署拓扑结构
自动扩缩容
访问控制系统（IAM JWT/OIDC 和 ACL）
支持多个界面以适应不同角色和工作流程（GUI、API、CLI、SDK）
与可信 idP 集成，支持单点登录和委派式 RBAC
对任务进行功能、逻辑或物理隔离
原生配额系统
审计系统
基于 SLA 提供企业支持（例如 24/7/365）
通过自动化进行配置（IaC，Runbook）

HashiCorp 解决方案

HashiCorp Nomad 是一个轻量级的、健壮的、适配多种运行环境的编排器。在官方网站你可以看到 Nomad 的架构、能力、界面以及为客户运维工作提供的帮助。

参考

支柱 6：可观察性

任何平台工作流程的最后一步就是对部署结果进行监控和维护。将可观察性实践和自动化构建到平台中，能够衡量软件、服务、平台和产品的质量和性能，了解系统行为。良好的系统可观察性可以加快并简化问题调查和诊断过程。

从根本上说，可观察性就是对数据进行记录、组织和可视化处理。仅有数据的可用性并不能提供企业级的可观察性。SRE、DevOps 或其他团队首先确定要生成、收集、聚合、总结和分析哪些数据，以获得有意义且可操作的见解。

可观测性解决方案使用指标、跟踪和日志数据来对系统进行理解和调试。企业需要在整个堆栈上实现统一的可观测性：云基础设施、运行时编排平台（如 Kubernetes 或 Nomad）、云托管服务（如 Azure 托管数据库）以及业务应用程序。这种统一有助于团队了解云服务和组件之间的相互依赖关系。

但是数据的统一仅是将可观察性融入平台工程的第一步。平台团队还需要使用模块和部署模板等自动化方式，来落地可观察性的最佳实践。就像平台工程帮助安全功能向左移动一样，通过将可观察性融入容器和镜像，也同样能把可观察性向左移动到基础设施编码和应用构建阶段。如此一来，团队从开始就能够构建并实施全面的遥测策略，并将其自动化到平台工作流程中。

将可观察性解决方案集成到基础架构代码中的好处很多：开发人员可以更好地了解其系统的运行方式和应用程序的可靠性。团队可以快速调试问题并追溯到根本原因。组织可以通过数据驱动的决策来改进系统、优化性能和提升用户体验。

工作流：可观测性

企业级可观测性工作流应该有如下 8 个步骤：

编码：开发人员提交代码
- 注意：开发人员应该在 RBAC 许可的情况下直接连接到网络控制平面
验证：CI/CD 平台请求 idP 进行认证和鉴权
idP 响应：如果成功，则流水线触发任务（例如测试、构建和部署）
请求：执行请求内容，例如构建模块、拉取制品、使用内外部策略进行验证等，最终完成资源发放
发放：发放缺失的基础设施
配置：配置可观测性资源
收集：根据配置读取指标和跟踪数据
响应：将提供者请求的完成情况提发放 CI/CD 平台，以便进行后续处理和/或移交给外部系统，进行安全扫描或集成测试等。

可观测性需求列表

企业级的可观测性需要：

实时的问题和异常检测
跨越多个控制平面和环境的自动发现和集成
精准的告警、跟踪、日志和监控
高阶分析
标记、标签和数据模型治理
可观测性即代码
多云和混合环境下的弹性和性能
安全、隐私以及 RBAC 保障下的自服务可视化、配置和报告

HashiCorp 合作伙伴的可观测性方案

HashiCorp observability partner: Datadog

HashiCorp observability partner: Splunk

HashiCorp observability partner: New Relic

HashiCorp observability partner: Honeycomb

下一步和技术选择的标准

平台建设永远不会完全完成。它不是一个事先计划好的项目，在每个人签署并开始使用后就结束了。它更像是一个迭代的敏捷开发项目，而不是传统的瀑布式开发项目。

平台工程可以从最小可行产品（MVP）开始，然后把平台推向组织市场。向团队展示该平台的常见模式和最佳实践如何能使团队从中受益，并适用于整个开发生命周期。与各个团队共同进行流程分析（当前状态对比未来状态），以便共同努力并理解采纳的好处可能会产生积极效果。最后，简化新员工上手过程是至关重要的。

选择上述，平台团队应该采取用户体验设计师的思维方式。调查各个团队的需求和期望之后，可能会发现，只有 80% 至 90% 的需求能被满足。有些工作流程太复杂或独特，无法纳入平台中。无法讨好每个人。工具链选择应该是一个跨职能过程，并且在一开始就需要高层支持来推动采用。

关键工具链的问题列表

实践者意见：您是否从询问开发人员对哪些技术感兴趣开始？这些技术能否快速支持业务？他们想学习什么，市场上是否普遍存在这种技能？
规模：该工具能否满足企业的期望，包括性能、安全/合规性和易于采用？您可以向同行机构学习，而不是冒险进入未知领域吗？
支持：所选解决方案是否得到组织的支持，以满足核心关键基础设施（24/7/365）的服务级别协议，并满足客户的可用性期望？
长期稳定性：这些解决方案供应商财务状况良好且有能力长期支持这些基本支柱和核心基础设施吗？
开发人员灵活性：这些解决方案提供灵活接口（GUI、CLI、API、SDK），以创建个性化用户体验吗？
文档资料：这些解决方案提供全面且最新的文档资料吗？
生态系统集成：是否有可扩展的生态系统集成来与其他工具（如安全或数据仓储解决方案）紧密连接？

构建企业 IDP 最小可行性产品的黄金路径

Sat, 04 Nov 2023 12:39:09 +0800

原文：Here’s One Golden Path to Build an MVP Enterprise IDP

作者：Charles Humble

借助 Humanitec 最近发布的开源参考架构实施方案，企业平台团队可以快速创建内部开发人员平台。

最近不管参加什么技术会议，八成会看到一张看起来无所不能的云原生全景图，这张大图说明，现代软件开发的复杂度，已经让人略有不适了。

当然这张大图也显示了 Kubernetes 的成功，以及云原生领域的创新，但是工具的无序扩张，受影响的可不只是应用程序开发团队。

平台工程公司 Syntasso 的联合创始人兼首席运营官 Paula Kennedy 告诉 The New Stack：“我认为，平台团队和应用团队一样，都很难弄清楚自己的工具集应该是什么。”“因为平台工程作为是一种对实践的定义，因此其确定性更差，构成也更不清晰，所以在这方面，平台工程的问题也更大。”

除此之外，至少根据我个人的经验，起初，平台可能会自发形成。一个开发人员为自己构建一个工具，因为事实证明这个工具很有用，就分享给团队中的其他人。这种方法在初期是很有效的。但随着开发人员数量的增加，这种方法就会出现问题，因为正如 Kennedy 所说，“如果没有系统化思维的思维和主动的架构设计，那么就只能野蛮生长”。

到了一定程度，企业可能会发现这种方式不再适合自己，于是可能会寻求分拆出一个集中式的平台团队，试图以更完善的方式，让开发人员能够更快地入职，更快地交付。但是，应该如何开始组件平台团队呢？

显然，你需要与应用程序开发人员沟通，了解他们的需求和痛点，然后构建一个能解决这些问题的解决方案——可是解决方案如何选择合适的工具和组件呢？

Kennedy 说：“在CNCF的环境下，无处不在的 Kubernetes 结构是让一切变得更容易的原因之一；CNCF 上的所有东西都是以云原生模式为基础构建的。而如果你所在的平台团队正在处理一些传统大型机，再加上一些云原生和其他一些东西，你的工具集可能是任何东西，并有一大堆不同的原则作为其核心。”

为了改善这种情况，Humanitec 发布了一系列白皮书和内部开发人员平台 (IDP) 参考架构的开源实现。这些内容结合在一起，为企业平台团队提供了一种方法，使其能够快速启动并运行新平台的最小可行产品（MVP）版本。参考架构本身基于麦肯锡的研究成果。

内部开发人员平台模式

在 6 月份的 PlatformCon 上，麦肯锡数字专家合伙人 Stephan Schneider 和该公司的高级 DevOps 工程师 Mike Gatto 发表了演讲，介绍了他们如何根据对多个组织的分析，确定了一套内部开发者平台的通用模式。

麦肯锡就是麦肯锡，该报告的重点是面向企业而不是小型组织。在平台的背景下，这是说得通的，因为对平台的一种定义就是在企业规模上使 DevOps 实践发挥作用的一种尝试。

如下图所示，麦肯锡建议的架构使用了许多现成的组件，包括开发人员门户构建工具 Backstage、GitHub、Terraform 和 Humanitec 的平台编排器，以及云提供商（本例中为 AWS）提供的组件。

麦肯锡的蓝图将开发者平台分为五个平面，每个平面都有一套相关的能力，如上图白色方框所示的可观察性和网络化。

开发人员控制平面：是开发人员发布代码并通过自己选择的界面访问平台的地方。它包括版本控制、集成开发人员环境、基础架构即代码和开发人员门户（如 Backstage）。除代码外，开发者还提供一个 Score 工作负载规范文件。这是一个 YAML 配置文件，指定了以与环境无关的方式运行应用程序所需的资源。
集成和交付平台获取应用程序代码，将其打包到一个或多个容器中，然后将其发布到亚马逊 ECR 等注册表中。一旦完成，CI 管道就会将注册表中的新工件通知平台协调器（麦肯锡使用 Humanitec 进行此操作），并启动构建。协调器会在部署前生成新的应用程序和基础架构配置文件和清单。
资源平面包括运行应用程序所需的资源。这可能包括计算（例如 Amazon EKS）；如果还没有 Kubernetes 集群，则构建 Kubernetes 集群；数据（例如 Amazon RDS、MySQL 等）；网络（例如 Amazon Route 53）；以及服务（例如 Amazon SQS）。
监控和日志记录交给云提供商，在我们的 AWS 示例中使用的是 Amazon Cloud Watch。
最后，安全管理机密和身份，以保护敏感信息（参考架构中使用了 HashiCorp Vault）。

由于平台编排器在蓝图中起着核心作用，因此值得对其进行更详细的了解。下图描述了其核心功能：

每一次 Git 推送，平台编排器就会解读工作负载运行所需的资源和配置，根据平台团队定义的规则创建应用程序和基础架构配置，并执行这些配置。Humanitec 用“读取、匹配、创建、部署”的执行模式来进行平台编排：

读取：解释工作负载规格（也就是 Score 文件和上下文）。
匹配：识别正确的配置基线以创建应用程序配置，并根据匹配的上下文识别需要解决或创建的资源。
创建：创建应用程序配置；必要时创建（基础架构）资源；并获取证书，将用 Secret 的形式注入给应用程序。
部署：将工作负载部署到与其依赖关系相连的目标环境中。

IDP 的开源蓝图

麦肯锡的参考架构在 PlatformCon 上引起了很大反响，因此，受其启发，Humanitec 编写了几份白皮书，为构建内部开发人员平台提供参考架构蓝图，不仅有 AWS 版本，还有 Google Cloud Platform 和 Microsoft Azure 的版本。

麦肯锡的参考架构引起了很大反响，因此，受其启发，Humanitec 发布了参考架构开源实施系列的第一个版本，由一组 Terraform 配置组成，能够在 AWS 和 GCP 上部署蓝图示例。AWS 版本包括 Backstage（如上图所示），并计划逐步增加 Azure 和多云实施的示例。

这为平台团队提供了一种方法，可以快速为内部开发人员平台开发出企业级最小可行产品（MVP），同时也为 Humanitec 平台编排器的试运行提供了便利。

Humanitec 产品经理 Luca Galante告诉 The New Stack：“社区对参考架构的反响令人难以置信。”我们在前几周就有了 1 万次下载，这充分说明了业界对清晰蓝图和设计模式的需求。

当然，您也可以随意更换组件，包括 Humanitec 本身。回想一下图中的平面和功能，“平面很重要，因为它们提供了方向并奠定了基础，而功能也很重要”Humanitec 的平台架构师 Clemens Jütte 告诉 The New Stack。“你肯定希望拥有图上的所有功能，我们从未见过没有这些功能的平台。但方框内的标识并不重要。你可以挑挑拣拣，开始迭代，建立你想要的 IDP。

黄金之路，不是黄金囚笼

企业面临的另一个挑战是，他们很可能已经有了一些不愿放弃的流程和工具，而且不同的团队有不同的需求。因此，灵活性也是很重要的

同样，强迫开发人员使用某个特定的平台也是不明智的–某个特定的团队或小组可能有充分的理由，在既定路线之外做事情。如果强制性的工具阻碍了开发人员完成他们的工作，也会出现影子 IT 实践。更好的做法是，尽可能让平台对应用程序开发人员具有吸引力，这样他们在任何情况下都会优先选择适合自己的平台。

加拿大金融公司 Nesto 的 DevOps 总监 Mathieu Frenette说，“我们谈论的是黄金路径，而不是黄金牢笼” 而 Kennedy 说：“我非常喜欢这种说法，因为这有助于我思考这样一个事实，即开发人员需要有一条简单的道路；他们需要有一个模板，帮助他们快速上手，但他们也还保有打破他的权利。”

“平台团队需要能够通过抽象提供简单性，同时在需要时提供灵活性。”

Galante 认为，“目前还没有一个平台能够保留我的 Terraform 设置，保留我的基础设施和 CI 管道，但我可以以一种更强大的方式将它们粘合在一起，从而获得内部开发者平台所承诺的所有好处。”

虽然各组织实施 IDP 的情况大不相同，但这一参考架构可以作为一个有用的起点。

我说的平台工程是什么

Sat, 21 Oct 2023 00:59:17 +0800

原文：What I Talk About When I Talk About Platforms

作者：Evan Bottcher

为什么一个有效的数字平台可以帮助您扩大交付规模，它应该包含哪些内容，以及如何开始建立一个数字平台。

如今，每个人都在建立一个“平台”，以加快数字产品的大规模交付。但什么样的平台才是有效的数字平台呢？一些组织试图在现有共享服务的基础上进行平台建设时，因为没有解决组织结构和运营模式的问题，最终陷入困境。

“平台”到底是什么？

“平台”是个含糊不清的词，但对于提高大规模交付速度和效率而言，它却极其重要。因此，本文的标题就是我最近一直在谈论的“平台”。

满世界都是各种软硬件平台的定义，一般都是描述一种运行环境，在此环境上可以执行应用程序，并提供文件系统和安全等可重复使用的功能。

放大到组织层面，“数字平台”也具有类似的特征——团队在可重复使用的功能支持下，建立一个操作环境，从而更快地向客户提供产品功能。

数字平台是自助式 API、工具、服务、知识和支持的基础，是一种引人注目的内部产品。凭借平台的支持，自主交付团队能用更少的协调成本，更快地交付产品功能。

在 Thoughtworks，我们开发了一个包含五大平台能力支柱的模型。这些能力包括基础设施交付、应用程序接口和架构修复、自助服务数据、实验基础设施和客户接触点技术。通过全球验证之后，我们认为这些是值得投资的重要共享能力，这些能力能够帮助构建数字化组织。

本文的重点是我们归类为交付基础架构的平台功能，包括云托管和 DevOps 工具，尽管这些定义特征同样适用于其他平台功能。

非平台

几年前，我受聘为澳大利亚一家大型金融服务机构提供咨询。我们称他们为 BigCo。到达现场后，我的第一个目标是了解应用基础架构、托管和运维领域的情况。为了真正了解挑战所在，我们决定通过工作系统跟踪一个真正的变更，看看这里的行为方式。

尽管 BigCo 在云计算和自动化方面进行了大量投资，但在基础设施和运维领域仍保留了传统的团队安排。团队按照技术能力划分。我们跟踪了几个典型的变更，每个变更都涉及多个团队。例如由“中间件”负责更改应用服务器配置。但是，中间件团队无法访问底层操作系统配置，这属于“中段”团队的职责。数据库变更必须由 DBA 团队进行。网络变更必须通过网络团队完成。托管服务提供商进行负载均衡的变更，而防火墙的变更则是另一家提供商的任务。此外，还有一个独立的自动化团队，他们拥有一些自动化能力–主要限于协调。当然，还有独立的企业监控、安全、变更和发布管理团队。

图 1：将高度专业化的基础设施团队和运维团队分开

BigCo 的每个团队都有自己的管理结构和工作方式。每个团队都在自己的技术领域实现高效管理、集中专业化、无差异外包能力、实施管理和降低成本。然而，在 BigCo 公司，为客户提供端到端功能的效率却无人负责。

涉及基础设施的小改动需要花费数周到数月不等的时间，这对客户响应速度造成了巨大影响。影响很大，但这还不是全部。我们注意到，当变革艰难而缓慢时，变革过程中的任何失败都会导致进一步的延误。因此工程师和管理人员会尽可能减少变更次数，只对应用程序和基础设施进行绝对必要的变更。

图 2：应用程序交付团队所需的更改需要数周或数月时间

很明显，这会导致应用程序和基础架构的内部质量逐渐下降——环境和配置设置中随处可见许多不一致的地方。团队已经停止了能够保持或提高质量和一致性的微小改进和重构。这种情况在实践中会自我强化：由于质量会影响可预测性，从而增加变更风险，因此团队会变得更加谨慎，改进工作也会变得更加困难。

因此，总而言之：在 BigCo，基础设施和托管事务的处理缓慢而又困难。

Backlog 耦合的后果

数字化渠道一直是敏捷软件交付的法宝，小型自主团队与业务领导者密切合作，确定客户需求并构建满足这些需求的功能。然而，数字产品团队的速度越快、反应越灵敏，所受到的外部限制就越大。

数字团队受到几个方面的限制：核心系统进化缓慢、无法获取高质量数据和分析结果，基础设施和运维难于共享。

我称其为 Backlog 耦合，Backlog 是敏捷交付团队经常使用的一种规划工具。

图 3：当变更与多个团队的工作队列存在依赖关系时，就会发生 Backlog 耦合的情况

这概念很简单，一个工作队列中的的大量项目需要另一个团队提出相应的 Backlog 项目，那么生产率和响应速度就会大打折扣。Backlog 项目会在整个组织内串联起来，每个项目都根据不同的系统确定优先级。在看板上给任务贴上大红“阻塞”标签，利益相关者生气，共享服务提供商会尽力根据反馈音量做出反应。

Backlog 耦合能糟糕到什么程度？在澳大利亚的一家电信公司，我的同事对通过交付中心的数百件工作或任务进行了研究。有些任务可以由一个团队完成，无需依赖其他团队，特别是无需安排其他团队成员的工作。而那些需要等待其他团队完成的任务，耗时则要慢 10-12 倍。因此，依赖性确实会产生重大影响。

这种情况对我们造成了多种伤害：它损害了纯粹的吞吐量和对客户需求的响应速度，促使我们进行更长期的规划，从而有效地管理依赖关系。它还会损害团队自身对结果的责任感，据我观察，这对许多团队来说都是动力杀手。团队趋向于推卸责任，不再寻求自身的持续改进。

在一个超负荷团队中，为众多吵闹的内部客户提供服务，也没有什么乐趣可言。

最近的“扩展敏捷（Scaling Agile）” 试图通过一种方式来解决这个问题-引入规划仪式，试图在多个团队之间协调优先事项。很显然这种方式能够提高一致性但是降低了整体的自主性、反应能力和应对变化的能力。这不可能是唯一的方法。

因此，能够减少 Backlog 耦合的平台是好的。平台提供的服务必须不需要工单和分配工作。自助服务是优秀平台的一个关键定义特征。

平台应该团队提供自助式访问。具体来说，用户能够自助在平台上自助完成供给、配置、管理和运维。

半吊子私有云

BigCo 意识到自助服务的必要性，但是这个大型基础架构和运维组织中，传统基础架构和思维方式根深蒂固，要实现这一目标谈何容易。公司已经在集中自动化工具方面进行了投资，因此首先要做的是为应用交付团队创建自助服务能力，以便自助配置基础设施。

BigCo 构建了一个自助工具，允许交付团队根据非常固定的模板申购计算实例。配置的虚拟机实例在配置上是固定的，并被安全锁定，以确保中端团队对机群的控制。要实例进行一些有用的操作，例如安装软件包、连接网络、附加存储、配置负载均衡、配置监控工具或其他任何操作，交付团队都需要发出工单。

图 4：BigCo 在不改变应用程序和基础架构运行方式的基础上，构建了一个基本的自助服务应用程序接口。结果并没有明显改变交付速度。

你可以将这种情况归咎于首次迭代，这的确是个问题，但是这中间也有明显的取向问题。BigCo 的基础设施和运维团队还没有准备好打破自己的组织孤岛，将重要责任（以及访问权）转移给交付团队。而且，即使意图是好的，但要逐步将应用程序接口构建到所需的丰富程度，这个过程需要的巨大工作量也是难于承受的。

我们将这种方法称为“肤浅的私有云”——将现有的虚拟化平台重新贴上标签，供交付团队以非常受限的方式使用，并没有减少集中控制的真正意图。

与此同时，BigCo 公司的交付团队也在努力，他们解锁了在生产系统中直接使用 AWS 的能力。一旦有了这样的先例，交付团队纷纷加入了 AWS 的用户行列。

对于交付团队的直接消费而言，AWS 是一个极具吸引力的平台：它完全是自助式的，而且责任分工明确。谁构建、谁运行变成了口头禅。AWS 建设和运营平台以及 API，并确保其高度可用；应用程序交付团队则构建、配置并运行平台上的应用程序。

故事到此为止？

自主加快上市速度，提高创新能力

我遇到的大多数组织都有一个“为复用而构建”的默认思维：在规避风险和降低成本的双重驱动下的中心化趋势。

图 5：大多数组织默认通过集中方式来提高成本效益

在过去的几年里，我有幸成为澳大利亚（和全球）一家大型技术公司的技术领导团队的一员，这家公司拥有庞大的在线业务，我们姑且称其为 WebBiz。该公司拥有数百名工程师，规模庞大，面临着许多与 BigCo 相同的挑战，在基础设施、应用程序和数据方面都有不小的遗留问题，但 WebBiz 又小到足以见证快速的变化和改进。

我在 WebBiz 工作期间，我们开始了一项长达数年的迁移工作，原本在租赁数据中心的虚拟化平台上部署的大多数应用程序，被迁移到 AWS 这个新的默认部署目标。我们还将应用程序和（大部分）基础设施的构建和运行责任转移给了产品团队，这是我所见过的从传统中央运维到开发运维的最彻底转变。我相信，以“谁构建谁运行”的思维模式来创建一个小型组织其实并不难，但实现转型需要勇气和持续的愿景。WebBiz 在这方面做得很好。

作为迁移的一部分，WebBiz 的产品团队能够完全自主地配置和运行堆栈的每个部分。这种方法被命名为“团队管理基础设施”–虽然在早期建立了一些默认设置，但每个团队都可以在几乎没有中央授权的情况下，自行决定堆栈的每个部分。

WebBiz 成功让组织更倾向于技术多样化和发明。这提高了员工的参与度，让工程师在技术堆栈中获得更深层次的经验，推动了发明创造，迅速确立了对部署内容（应用和业务）的响应水平，并消除了团队的大部分依赖关系。同时，这也吸引了那些对自己的工作负责、对自主性反应良好、对解决棘手的业务和技术问题感兴趣的工程师到 WebBiz 工作。

技术多样化增加阻力

然而，尽管好处多多，转向完全自主还是要付出一定代价的。通过采用 AWS 作为平台，WebBiz 消除了与集中式基础设施团队的 Backlog 耦合。然而，WebBiz 的每个团队现在都不得不围绕构建和运营基础设施的各个方面做出一系列决策。

图 6：云原生全景图

上图是最新版本的“全景图”：这里包含一些常见的开源产品和产品，并按构建云原生架构时所关注的领域进行分组。这是一张拥挤的地图，而且只是最成熟的产品。对于上述每个领域以及更多领域，团队都必须评估各种选项，选择适合其需求的产品，然后学习如何集成和操作该产品。

除了重复基础设施的维护费用外，每个团队还需要不断研究和评估其基础设施选择。

WebBiz 现在正开始建立一个定义更加清晰的交付基础架构平台–一套令人信服的默认设置，产品团队可以使用这些默认设置来减少阻力，提高工作效率。

但是，他们是否有可能失去自主权带来的好处？

平台即产品

在自主多样化和中心化管理之间找到适当的平衡点，是个难度颇高、且不易预测的工作。成功找到这种平衡的一个关键因素是，平台必须令人信服，不能仅仅依靠授权。现有的共享基础设施功能处于垄断地位，交付团队没有可行的替代方案。竞争是推动产品思维的必要因素，可确保每个平台功能都能增加价值，而不是造成限制和耦合。

成功找到这种平衡的关键因素是，平台的使用必须具有吸引力，怎样才有吸引力？

该平台可为绝大多数使用场景提供自助服务。
平台是可组合的，包含可独立使用的离散服务。
平台不会强迫交付团队采用不灵活的工作方式。
平台上手快速、成本低廉，易于上手（如快速入门指南、文档、代码示例等）
平台拥有丰富的内部用户社区，便于共享
平台是安全的，合规的
平台是最新的

最终，当使用平台能力比构建和维护自己的东西更容易时，交付基础架构平台就会引人注目。Netflix 将其集中式工具称为“铺装路”-团队有权不使用这些工具，但要负责维护自己的替代工具的所有成本。

平台也不应仅仅是软件和应用程序接口，它还包括文档、咨询、支持和宣传、模板和指南。

等等——这不是“DevOps 团队”吗？做得不好？可能是的。

（我还没准备好在 DevOps 上认输：所以，如果你不确定，如果你有一个团队叫’DevOps’，那么这个词的意思并不是你想的那样）。

您可以选择组建一个团队来构建和运营交付基础架构平台–我认为在大多数情况下，这将是最佳的入门方式。如果是这样，你就应该非常清楚平台团队与其客户（为了清晰起见，我称之为应用团队）的职责范围。

应用团队负责构建、部署、监控和调用他们在平台上提供和部署的应用组件和应用基础架构。平台团队负责构建、部署、监控平台组件和底层平台基础设施，并随时待命。

理想情况下，平台团队甚至不知道平台上运行着哪些应用程序，他们只负责平台服务本身的可用性。

这样，应用团队和平台团队都有责任构建和运行自己的产品。这当然还是“谁构建，谁运行”。

如何开始？

成功建立交付平台有一些先决条件。首先，你可能已经开始摆脱以“项目”作为技术交付的主要资金和人员机制。平台是一种产品，需要一个长期稳定的产品团队来负责构建和运行。

其次，必须愿意将应用程序的部分或全部运维责任转移到应用程序团队，而不是集中化的运维和支持。平台提供的工具和服务可以让应用团队对他们所构建的内容负责，但如果集中提供支持，就无法做到这一点。

第三，你必须在实施的严格一致性与交给自主应用团队的自由和责任之间进行权衡。

还有些问题。

平台不仅仅是可以安装的基础设施、工具和应用程序接口。要想取得成效，必须回答交付团队的问题：如何快速采用新功能？如何独立做出哪些选择而不是使用合理的默认设置？以及您将如何持续维护这些功能。这将需要一些内部咨询技能、培训和宣传。

您不知道自己需要什么样的平台功能，因此应根据真正的成熟需求从小规模开始。从应用团队中收集已经验证的解决方案，并尝试与将使用这些解决方案的团队合资创建和测试功能。

请务必小心，在有限的虚拟主机和锁定的集中管理工具上贴个平台标签，并不是平台。

Everything as General Purpose Code

Thu, 27 Jul 2023 09:11:00 +0800

大概是 2014 年，在老东家搞了一阵 DevOps 工具的设计开发，出了一个蛮有意思的设计：以 Pull/Merge Request 为模型枢纽，把需求、代码、构建、发布以及可观测性都关联起来，用一个 Dashboard 观测一个需求从提出到发布以及运行的的所有生命周期内容。那时候大概是 Jenkins 最后辉煌的年代，我第一次接触了 Infrastructrue as Code 的概念，从 Kubernetes 的状态机制、到 Jenkins 的 Pipeline as code，当然还有让我踏进 Kubernetes 门槛的 Ansible，以及可以直接合并到代码仓里面的 Grafana Template，都给刚脱离业务代码不久的我带来很大触动。（最近会上听说这个产品还活着，老怀大慰 :D），后面的日子里因为一直在跟各种 YAML 打交道，可以说 As Code 的概念已经成了我的思维习惯。

工作在 SRE 和云原生领域，不可避免的接触到各种 As Code 的东西，另外虽说今年以来阅读量锐减，但是大模型和平台工程这两个名词还是不时地跳到我的眼前，SRE 工作如何借助借助这两个新玩意走向未来，已经是一个无法回避的问题。随着不断地在各种公有私有 DSL 里面摸爬滚打，我发现单纯的 Infrastructrue As Code 甚至是 Everything As Code 都是不够的，更精确的描述应该是 Everything as General Purpose Code，翻译成人话大概就是——一切都是通用代码。

早在 2004 年出版的《Thinking in Promises》一书中，已经提出了很多这一理念的雏形:

提倡基于 Promise 理论来管理计算系统。
主张基于策略而不是手工操作来管理复杂环境。
强调通过计算机编码的方式来实现策略自动化。

这本书奠定了 Mark Burgess 后来进一步发展 CFEngine 自动化配置管理系统的理论基础。

随着 IT 行业的迅猛发展，数据中心规模的暴增，传统的手工配置服务器以及 Shell 脚本的自动化方式，越来越无法满足运维需求，在 CFEngine、Puppet 这样的先驱之后，涌现了各种 As Code 的工具，例如：Terraform、Ansible、Vagrant、Docker 等等，尤以 Kubernetes、Prometheus 为首的云原生体系出现之后，这种趋势就更加成为一种默认的选择。

目前，Everything as Code 成为 DevOps 流程的重要组成部分。GitOps 将 Git 作为基础设施部署和管理的单一源。Everything as Code 理念被进一步拓展到监控、日志、文档等更多领域。随着敏捷运维和 DevOps 的兴起而逐步发展成熟,已经成为现代软件工程自动化的重要范式。其核心思想也将持续引领软件工程的未来方向。

一艘大贼船

在实际工作中会发现，微服务、声明式 API、Everything as code、以及阿姆斯特丹 KubeCon 上大热的平台工程，形成了一张粘人的网：

多数情况下，微服务和容器可以说是绝配。
要编写 Kubernetes 风格的声明式 API，通常需要对业务进行面向状态而非面向过程的设计。
面向状态的设计中，基本的对象操作方法就是——设计对象的状态机，并让对象自行根据有效路径向目标状态迁移。
状态通常是离散的，因此并不是所有的业务都适合使用这种方法进行设计。
微服务提倡的智能终端、透明性、内聚性等架构风格，都可以用这种思路来设计实现
既然已经清晰的使用状态来描述对象的现状和目标，那么使用代码进行描述可以说是毫无难度的。
…

I can do this all day.

众多的开源工具、协议、规范等，交织在一起，对于初创企业来说可能是个好事，但是对于具备强大 IT 实现能力的大厂们来说，这个事情可能就不太美妙了——或多或少的 Not Invent Here 思路，开始被“外边的世界”来回撕扯，从任意一个角度踩到这张大网上，都会感到这张网的粘性和侵蚀能力。为了持续发展、或者说防止碎片化，开源社区尤其是云原生的相关社区，一方面推崇 Upstream first 的开源理念，一方面发展一致性认证等手段，形成一种“打不过就加入”的态势，诱使或者迫使企业以及个人用户和贡献者沿用同一标准和思路助力项目的发展。而企业中小团队自行研发的一些相对应的技术，则往往会因为开源世界的飞速发展，越来越多的面临疲于奔命的窘境。

在开发者看来，对于公开技术的学习和深入应用，能显著的降低学习成本，提高个人技术积累的有效性和可评估性，也会越来越倾向于对公开标准的迎合。

在最终用户眼中，以前经常的奚落话术：“不就是开源套个壳”，因为对于多云厂商的需求，以及对厂商绑定的反感，开始逐步转变为：“你为什么不用开源软件套个壳”这样的提问，当然这种情况还有另外一个原因——越来越多的乙方技术人员被输出成为了甲方。

种种形势的夹击之下，拥抱开放标准，用开放代码表达尽可能多的资源和策略，就成为一个新的重要方向。

这和平台工程有什么关系

既要新，又要快，还要稳。

目前平台工程还没有一个权威的被广泛接受的定义，这里尝试从职责的角度给他下一个定义：在组织范围内，为软件从开发到运维的完整生命周期，编制符合其 IT 治理要求以及最佳实践的可执行的内部规范，并开发用于实施这种规范的工具平台，这种工具平台是一个可拼接、可编排的松耦合框架，用工具和 API 的方式，为研发和运维人员提供自动化的安全、合规、研发能效等方面的支持，从而保障软件能够快速交付、平稳运行。

平台工程的开发并不会和普通业务系统的开发过程有什么本质区别。然而平台工程处于基础设施和开发之间，并且承载组织的 IT 治理职责，产品开发团队希望更聚焦于主航道业务，希望使用更便捷的方式来使用 IaaS/PaaS/SaaS 服务来快速地构建产品；炒作周期中的新技术则会对所有的技术人员产生巨大的吸引力；与此同时，IT 管理团队则以稳定可控为第一前提，希望不同年代的各种技术能够为我所用、为我所控，用一个相对稳定的治理体系进行维持。

综上所述，平台工程产品的建设，同时受到来自业务、技术以及管控三方的压力；在三方压力撕扯之下，平台工程还要在保持业务连续性的底线之上持续向前演进。因此平台工程是一个高度定制化、高度敏态的、永不完工的系统。这就要求平台工程团队要将大量不同来源的基础设施、规范、工具，用弹性的方式结合在一起，根据研发运维等技术性工作的需求，粘合成为具备一致性拓扑视图和管控能力的能力中台。

平台团队需要构建共享的工具和服务，帮助开发团队开发、部署和管理云基础设施。其服务范围跨越云基础设施、容器编排平台、数据库、网络、监控、代码仓库和部署流水线等一系列工具和能力。因此平台工程有两个基本组件——首先要为其服务范围内的各种资源建立一个统一的资源模型，并以 CMDB、API 或者命令行、图形界面等方式将其呈现给开发运维人员；其次就是在这个基础之上为应用提供一个涵盖基础设施以及应用程序部署能力的 CICD 工具（是的平台工程的终点也是 CICD，各位看官可以脑补掀头套的表情包）；根据组织分工的不同，其它职能例如可观测性、FinOps、安全、合规、隐私等，也可能以内置或者接入的方式出现在平台工程之中。

说这么多，跟所谓的公开的通用语言有什么关系呢？

平台工程的用户通常是开发、运维工作的相关的技术人员，因此工具所提供的命令行、图形界面以及 API，如果是用户所熟知的形式，将大大提高用户的使用意愿，这方面很优秀的一个例子就是近些年风靡大江南北的 xxctl 命令，容器相关的命令行大多都有这种 xxctl verb type obj parameter 的形式，大大的降低了技术人员接触这类工具的门槛，并且其中所透露出的操作以及对象结构，也让用户更加容易理解系统所提供的能力模型。API 也是同理，现在要逃出 Restful 的魔爪，哪怕是用流行程度稍差的 GraphQL，就要接受一些额外的的质疑。
平台工程对云基础设施的管控，目前多通过 GitOps、IaC 等技术作为基础来进行实现，这里同样面临 Not Invented Here 和 Proudly Found Elsewhere 的选择。从零到一对每个技术团队来说，都有极大的诱惑。然而一旦市面上出现了很可能会持续发展的同类技术，自建产品就面临尴尬境地——用户们会按照外部的“传说”，一方面会 Push 平台工程团队跟进外部特性，另一方面也会抱怨需要进行额外的学习才能掌握自研工具，内外部客户通常还会提出“兼容某某某”的“小需求”。而自研产品的团队也会面临两难境地——一方面，要用小团队跟进整个社区的进展是个吃力不讨好的事情；另一方面也因为不间断的外部噪音，而打乱产品原计划的发展路线。

工具方面，比较有趣的一个例子就是 Podman，它的绝大多数命令都是和 Docker 可以互换的，有人甚至给 Podman 做个 Docker 的 alias。

语言方面，我想很多人都有过从自定义脚本到 Ansible、CloudInit 等制式工具的美妙体验；号称简化 Kubernetes YAML 的工具非常多，然而除了 Helm，甚至包括 Kustomize 在内，可以说——都是弟弟。

为什么还能扯到 LLM

Q：大家都是用什么卡训练的？ A：信用卡

LLM 的情况比较简单，跟平台工程面临的情况是很类似的——大模型也是需要训练的。需要投入海量语料、天价算力以及庞大的人力，才能培养出来一个渊博的大模型。而私有的自研语言，在这方面有着天然的缺陷——大模型她不认识我。这就造成一个挠头的困境——自己凭实力弄出来的私有技术，还要花钱让大模型学会它。举个例子来说，很多开发者都有过用私有语法/语言自定义策略的经验，这种 DSL 其实不难实现，然而等到难用的 OPA 的用户可以用 ChatGPT 把策略聊出来的时候，你的用户可能就要刁难你了。

当然，可以通过迁移学习、联合训练等手段，降低私有语言进入大模型的门槛，然而这世界变化很快，类似的场景可能还包括：

Prometheus 告警表达式
Grafana Dashboard 的 JSON
Dockerfile
根据日志进行故障定位
根据审计记录进行态势感知
IPtables 策略编写和诊断
…

可以说，私产越多，花费越多。在这种情况下，具备广泛传播的语言、日志等，就具备更好的使用 LLM 的基础，形成新的人机界面。

结语

自有语言、协议的情况其实非常常见，尤其对研发能力溢出的大厂而言。但是对于眼下大模型+平台工程的趋势来说，拥抱主流标准，或者取而代之，搭上行业的顺风车，应该是个更好的选择。

From ChatGPT：作为 IT 作家，我对这个标题“Everything as General Purpose Code”有一些见解。首先，这个标题传达了一个强烈的观点，即将“一切”事物都作为“通用代码”来处理。这似乎暗示了一种理念，即无论是硬件、软件还是其他系统，都可以用通用代码来实现其功能。这种观点在某些方面是有吸引力的，因为它强调了代码的普适性和灵活性。从技术角度来看，将一切事物视为通用代码可能意味着在设计和实现过程中追求更高的抽象和通用性，从而实现更高效的系统和应用。这种方法可能会促进代码重用，减少开发工作量，并使系统更易于维护和扩展。然而，这样的理念也存在一些挑战和潜在问题。首先，将所有事物视为通用代码可能导致过度抽象化和泛化，从而牺牲了一些特定情况下的性能和效率。不同领域的应用可能需要特定的优化和定制，通用代码并不总是能够满足所有需求。其次，将一切事物视为通用代码还涉及到一些安全和隐私方面的考虑。通用代码可能增加了系统的复杂性，从而增加了潜在的安全漏洞。此外，某些领域的数据可能是敏感的，将其简单地视为通用代码可能导致数据泄露和隐私问题。最后，实现“一切事物都是通用代码”这样的理念需要强大的技术支持和开放的标准。这需要跨行业和跨领域的合作，以确保各种系统和设备都能够相互交互和协作。否则，这种理念可能难以实现，只能是一种理想主义的愿景。综上所述，标题“Everything as General Purpose Code”传达了一种令人着迷的观点，但也需要在现实中认真考虑其可行性和潜在的挑战。将一切事物视为通用代码是一个有趣的思考方向，但在实际应用中需要谨慎和明智的决策。

通用 I(E)ac 是通往 AIOps 的捷径

Sat, 22 Jul 2023 08:42:53 +0800

Transparency can be a big win.

[译] Prime Video 并没有重回单体架构

Fri, 30 Jun 2023 21:53:26 +0800

原文：Amazon Prime Video’s Microservices Move Doesn’t Lead to a Monolith after All

作者：Scott M. Fulton III

太长不看版

本文主体由 Deepl 翻译，局部经过 ChatGPT 润色，后大面积返工。

Prime Video 不是整个 Amazon，也不是 AWS。
身处 IT 企业，经常会误以为其他企业也有同等规模和素质的 IT 团队和投入
架构跟时尚一样，会存在周期性的反复，业务目标和组织结构始终是个决定性因素
和平年代和战争年代，对架构工作的前瞻性和时效性会有截然不同的选择。

正文

在任何组织结构中，一旦你把常规工作分解成过于琐碎的任务，并把它们委托给太多的人，他们的信息传递很快就会变得无法管理，组织也会停止发展。去年 3 月 22 日，亚马逊 Prime Video 的工程师在一篇几周内未被注意的博文中报告说，他们在微服务平台上创建的，为确定流媒体视频的服务质量（QoS）水平而构建的服务质量监控应用程序，在低于 10% 负载情况下也会失败。

更重要的是，他们已经应用了一种补救措施：他们的帖子描述的解决方案是“单体应用”。

Prime Video 是《权力的游戏》和《了不起的麦瑟尔夫人》等点播节目的发源地，击败传统广播机构获得 NFL 周四晚间足球赛的直播权之后五年，发生了这样的问题。

成为流媒体市场领导者之一之后，Prime Video 同时为 1660 万观众提供服务。为了跟上体育实况观众的网络需求，Prime Video 的发展需要加速。

可惜，在 2022 年 9 月的橄榄球赛季开幕时，Prime Video 发出了不少以 “很抱歉给您带来了不便”开头的推文。

工程师们在博客中报告说，Prime Video 的工程师们将原本分离在孤立的 AWS Step Functions 和 Lambda 函数中的 QoS 监控操作整合到一个统一的代码模块中，解决了这一问题。

正如最初报道的那样，这件事的发展，似乎最终证实了许多组织在过去十年中的猜测，即维持系统复杂性和信息传递开销所产生的成本，完全有可能抵消微服务架构所带来的收益。

可想而知，那篇博文稍作炒作，就会有专家来给为服务架构宣判死刑。Ruby on Rails 的创始人 David Heinemeier Hansson 写道：“很明显，在实践中，微服务可能会诱导你构建不必要的复杂系统”，而.NET MVP Milan Jovanović 在 Twitter 上问：“我们会看到雄伟的单体重新出现吗？”。

杰夫-德莱尼（Jeff Delaney）在 YouTube 频道 Fireship 上说到：“这一举措给 Amazon 省了不少钱，但这也是个可能失去重要收入来源的坏消息”。

然而有其他专家，包括 CodeOpinion.com 的 Derek Comartin，他们将 Prime 的架构图相互比较，并注意到这些图和他们的附带叙述之间存在一些明显的脱节。

在 TNS 访谈中，有业界知名专家提到（并且得到 Amazon 高级网络服务工程师的证实），Prime Video 的新解决方案，不仅不符合单体应用的特征，和原架构相比，新版本在扩展性等重要方面，都是一个进化了的微服务架构

传说中的完美

AWS 的前云架构战略副总裁，现在是 Nubank 的顾问 Adrian Cockcroft 在接受 The New Stack 采访时说到：“这绝对不是一个从微服务到单体的故事，而是一个 Step Function 到微服务的故事。”

许多 The New Stack 的读者都知道，Cockcroft 是微服务架构的发起人之一，当然也是其最直接的支持者。自从成为顾问以来，他没有直接参与 Prime Video 或 AWS 的工作，但他熟悉那里实际发生的事情，当 Prime 的流质量监测项目开始时，他是 AWS 的高管。他为我们描述了一种原型设计策略，即企业利用 AWS 的 Step Functions，加上 Serverless 编排，对业务流程进行可视化建模。

通过这种采用策略，架构师基本上可以随意重组数字流程，最终发现它们与业务流程的最佳匹配。他对这种方法非常熟悉，因为它是 AWS 最佳实践的一部分–他也是起草人之一。在与我们交谈时，Cockcroft 赞扬了 Prime Video 团队，认为该团队遵循了这一最佳实践。

根据 Cockcroft 的理解，Step Functions 的决策，并不是以 NFL 体育赛事直播的规模来设计的。这些流程的最终状态需要有更多算法、更有效、更巩固。因此，要使 Step Functions 模型不仅用于原型设计，其诀窍不仅仅是可扩展性，而且还要具有可迁移性。

Cockcroft 说：“如果你知道你最终的业务规模，你可能会采用完全不同的架构。所以真正的问题有两个：在什么规模上，用什么方式做事？这是两个不同的问题，如果你不知道问题的答案，或者如果你知道它是小规模的、复杂的，但却不知如何构建这一系统，那么你会需要快速建设一个原型。”

然而，他建议，如果一个组织从一开始打算建设广泛使用的大规模系统，就应该在前期加大投入来解决这些问题。而 Prime Video 团队却没有这样的条件。在这种情况下，Cockcroft说，该团队遵循的是最佳实践：建立他们能做的最好的系统，以完成他们当时所理解的业务目标。

Cockcroft 解释说：“很多企业内部的 IT 工作负载都是相对较小规模的事情，往往会发现，建设系统的花费超出了系统的运行费用，在这种情况下，你大概会想通过超级快速的构建过程来节省开发人员的时间。我认为第一个版本……就是这样思考的，它并不打算大规模运行。”

随着基于 Step Functions 的系统的完善，根据这些相同的最佳实践，其进化的下一个阶段将是迁移阶段。与流行的观念相反，这种蜕变的一部分可能涉及服务整合。不管 Prime Video 的博文怎么说，但整合的结果不是一个单体。它现在是一个完全成熟的微服务，能够提供工程师所吹嘘的 90% 的成本削减。

Cockcroft说：“这是整个 Prime Video 工作负载的一个可独立扩展的部分，如果他们现在不运行直播流，它就会缩容或关停–这也是一开始就用 Step Function 和 Lambda 来构建它的重要原因。而如果流服务在发展，它就会进行扩容。那是一个微服务。Prime Video 的其他部分也是独立扩展的。”

这篇文章发表后，AWS 发言人联系了 The New Stack，就如何在组织内使用 Step Functions 提供了进一步的建议。这位发言人告诉我们，许多 AWS 客户，包括 Liberty Mutual 和 Taco Bell，都从 Step Functions 开始他们的架构计划，并选择在其部署规模扩大时继续使用该服务。发言人称，Prime 视频流 QoS 服务是 Prime 博客原文的主题，是流媒体公司在 AWS 平台上利用的许多服务之一，其他许多服务可能在可预见的未来继续使用Step Functions。

The New Stack 采访了 AWS Lambda 及其管理的容器服务 App Runner 的总经理 Ajay Nair。Nair 完整地证实了 Cockcroft 的说法，即该项目最初是如何以 Step Functions 为框架开始构建，以及它最终如何成为一个可扩展的微服务。

Nair 为我们概述了一个典型的微服务开发模式。原始应用的业务流程经常会被过于僵硬地耦合在一起，难以进化和适应。所以要进行解耦和隔离。这种分解使开发者能够定义合同，阐明每个服务的预期输入和输出、要求和结果。业务团队第一次可以直接观察到交易活动，而在这之前，这些要素完全被其复杂性和意外的设计限制所掩盖。

Nair 接着说，软件工程师可以把孤立的 Serverless 函数编排为服务。在这样做的过程中，他们可能会进一步分解一些服务，例如 AWS 把 S3 拆分为 300 多个微服务类。服务合并也是可能的：观察它们的行为可能会发现，它们实际上并不需要被独立扩展。

Nair 说：“这是任何架构的自然演进，所构建的服务会被整合和重新分配，由此产生的能力仍然有一个完善的合同，[并且]有一个单一的团队管理和部署它。所以它在技术上符合微服务的定义。”

分解

Kubernetes 的 Co Founder，现任微软企业副总裁的 Brendan Burns 说：“我认为微服务的定义不一定很明确，我倾向于从功能、扩展和团队规模的角度来考虑它。一个微服务应该是一个或多个一致的功能–这就像良好的面向对象设计。如果你的微服务是 CatAndDog() 服务，你可能要考虑把它分成 Cat() 和 Dog() 服务。但如果你的微服务是 ThatOneCatOnMyBlock()，那可能就是拆的太碎了。”

F5 的 Lori MacVittie 在接受 The New Stack 采访时解释说，“微服务的粒度仍然受到物理定律、网络速度、你实际包裹的[代码]多少的限制。你能做到这一点吗？你能在一个容器化的环境中做所有的功能，并使其发挥作用吗？可以。它将会慢得要命。人们不会使用它。”

Adrian Cockcroft 建议，即使是对于一个非开发人员来说，每个服务的核心目的也是可解释的，这应该是微服务架构本身的一个原则。仅仅是这一事实就应该减轻对不良设计选择的影响。

“它应该简单到一个人就能理解它是如何工作的，” Cockcroft 提倡说。“有很多关于微服务的定义，但是一个基本共识就是把问题分割成多个独立可扩展的块。”

F5 的 MacVittie 说：“我们说的不过就是没有标准化的 SOA，你可以看一下框架、对象和层次结构，你会觉得——这和以前没什么不同。我们可以对此进行争论。谁赢了？这有关系吗？亚马逊大概会说——你是对的，这是一个大的微服务，谢谢你。这能改变什么吗？不，他们已经解决了他们的一个问题，通过改变他们的设计方式。如果他们碰巧偶然发现了他们一开始就应该做的事情，根据互联网上的专家的说法，很好。这对他们有用。他们省钱了，而且他们确实暴露了其中的一个问题，就是在没有足够能力的时候进行了过度的分解。”

她继续说：“我们有点被物理困住了，我们不太可能比现在的速度更快，所以我们必须绕过这个问题。”

也许你已经注意到了：企业的技术故事总在二元对立中茁壮成长。为了将任何软件架构作为有价值的东西介绍给读者，供应商和记者将新架构与其他架构对立起来。当一个同等的系统或方法还不存在时，新的架构可能最终被描绘成颠覆传统的革命的预兆。

其中一个原因可能是，网上的讨论要么是由供应商主导，要么是由倾向于首先与供应商对话的记者主导。

Platify Insights 的分析师 Donnie Berkholz 说：“软件公司的运作方式和世界其他地方的运作方式之间一直存在着这种脱节。在一家软件公司，你有十倍于其他许多公司的人均人员配置和软件工程。这让你有很多能力和人才来做其他人无法跟上的事情。”

大概巨大的 Amazon 品牌掩盖了一个事实：Prime Video 是 AWS 的客户。Prime 工程师的博文被放大了。某些技术作家可能非常专注于微服务架构的某些方面，以至于他们让读者认为该架构的替代方案必须是什么样子。如果根据定义，微服务是小的（一位记者特别强调了这一点），那么其邪恶的对应物一定是大的。在这种假设下，如果亚马逊的 Prime Video 拥抱了单体架构，那么所有的 Amazon 也必须拥抱。在第四节为单体架构打出一次反败为胜的触地得分，并演奏每周四的的橄榄球主题曲。

Berkholz 说，“多年以来，我们看到同样的事情不断发生，领先的软件公司、网络公司和初创公司因为规模原因，遇到的问题，会在几年之后才开始冲击大众。”

积累

服务导向二分法中最初的“邪恶轴心”是 1999 年的 Big Ball of Mud。这个概念首先由伊利诺伊大学厄巴纳-香槟分校的 Brian Foote 和Joseph Yoder 教授提出，它提出了对分布式系统的支持。但是泥巴球不能简单地和单体应用划上等号。

泥巴球并不是一座由僵硬、不灵活、紧密耦合的进程组成的令人生畏的高塔，而是将程序杂乱无章地堆积在其他程序上，通过将文件转储到软盘上，用纸板箱从办公室的楼梯上搬下来，在它们之间进行数据交换。在 20 世纪 90 年代和 21 世纪初的架构乱世中，如果一个系统脱离了泥巴球架构，那么可以说他已经相当优秀了。

Forrester 高级分析师 David Mooter 回忆说：“SOA 架构的理念和微服务是相同的，这个理念就是，服务与业务能能力和业务运营模式相一致。而大多数组织只是随意构建 Web Service，也就是用 SOAP 来构建业务。杂乱无章的 SOAP，就变成了杂乱无章的泥巴球。因为每个人都在用 SOAP 来实现最差的 SOA，SOAP 的骂名由此而来。”

Mooter 在一篇名为《The Death of Microservices?》的 Forrester 博文中分享了他的一些最新观点。在与我们的采访中，他指出：“我认为，通过对亚马逊博客的一些反应，你会发现当你采用了最糟糕的微服务实践，并将责任归咎于微服务而不是你糟糕的架构决策时，每个人都说微服务糟透了…抛开微服务不谈：任何时髦的技术趋势都无法弥补糟糕的架构决策。”

泥巴球“是一个模糊的、可塑的隐喻”，过去四分之一个世纪以来几乎所有失宠的方法论或架构都与之相关。当微服务在组织中取得进展时，单体架构就会被戴上荆棘的皇冠。最近，通过一些巧妙的措辞，微服务背上了耻辱的名号。

The New Stack 的老朋友、专业工程教练 Laura Tacho 表示：“我们的行业在创新、实验和增长（有时被称为和平时期）与紧缩和追求效率（战时）之间像钟摆一样摆动，当然，大多数公司在不同领域都面临这两种情况，但显然我们现在处于紧缩时期。在这种时期，微服务拆分造成的效率影响就不再是一个易于回避的问题了”

Berkholz 一直在观察同样的趋势：“行业内一直在摇摆，从单体到微服务，然后又回来。几年前，它是 SOA，然后再回来。”

为了抵御这种周期性的摇摆，微服务的捍卫者说，他们的架构并不适合每一种情况，甚至不适合每一个组织。但这是个大问题。如果同时存在两个或更多相等的、相互竞争的解决方案，那么这个市场就会被判断为碎片化市场——而企业通常会主动避免参与碎片化市场。

“分散意味着问题还没有为每个人很好地解决，”Berkholz告诉我们，”当有很多不同的解决方案，而没有人整合在一个单一的解决方案上，在大多数时候是有意义的。这是企业需要关注的问题。这是一个支离破碎的生态系统，很难做出选择？或者这是一个有明确和明显主宰的生态系统？” Lori MacVittie 告诉我们，F5 Networks 会对其客户进行调查，询问他们的应用组合中被描述为单体、微服务、移动应用和中间件注入的客户/服务器应用的相对百分比。她告诉我们，大多数组织都在以其中的某个百分比运作。如果只问只把应用程序分为“传统的”还是“现代的”，通常是 ⁶⁰⁄₄₀ 的比例。“他们用不同的风格做事，这是一种混乱吗？我不这么认为。特定模式的应用会有特定的用途。”

微软的 Brendan Burns 表示：“我有点觉得微服务对单体并不是一个很好的争论，这就像争论向量与链表，或垃圾收集与内存管理。这些设计都是工具，更重要的是要了解你从每一种设计中得到的价值，以及你何时可以利用这种价值。如果你坚持对所有的东西进行微服务，你肯定会对一些单体进行微服务，而这些单体可能是你应该单独留下的。但如果你说，’我们不做微服务’，你可能会把一些敏捷性、可靠性和效率留在桌上。”

大泥球的创造者引用了康威法则，作为软件架构变得臃肿和不方便的原因：“任何组织设计一个系统（广义的定义）都会产生一个设计，其结构是该组织的通信结构的副本。”多年来，微服务的倡导者们将这一概念向前推进了几步，建议业务结构甚至组织结构图都应该被刻意改造，以便与软件、系统和服务保持一致。

Tacho 指出，当 IT 架构潮流的钟摆开始回摆，玩家们也会重新考虑既有观念，也许这不仅仅是康威法则敲响了警钟，甚至还还有一种可能：市场条件是否允许我们暂时无视康威法则，以便在效率和创新之间进行权衡？沿用前面战争与和平的比喻，Tacho 继续说道：“一切都是一种权衡。过去因为微服务可能导致开发减缓、流程变得不那么高效的决策，在和平时期可能完全没问题，但在战时还要不断为这些低效性辩护，则是令人厌倦的。在战时，大多数公司不会针对庞大的代码库进行重构的投资。他们必须考虑业务回报率更高的其他优先事项，但像亚马逊这样的庞然大物会拥有更多的灵活性。”

Forrester 的 Mooter 建议说：“你首先应该看的是你的业务，什么是正确的架构？微服务不是目的，业务成果才是。你要实现的业务成果是什么？”，Forrester 称之为“结果驱动的架构”。“我们如何调整我们的 IT 系统和基础设施以及应用程序，以优化你的能力来实现这些？它将随着时间的推移而改变。”

微软的 Burns 说，“微服务设计的好处之一是，它拥有非常具体的 API，团队之间的合同很清晰，使小团队能够自主地行动。如果你的开发文化的其他部分阻止你的小团队自主运作，那么你就永远不会获得微服务的敏捷性好处。当然，微服务也有其他的好处，比如增加弹性，以及通过更优化的扩展来提高潜在的效率。这不是一个全有或全无的问题，但也是一个情况，即在实施微服务时，独立和自主的工程文化结构会做得更好。我不认为这与十年前与 DevOps 运动相关的文化变革有多大区别。”

Prime Video 在 NFL 橄榄球版权上进行了一场巨大的商业赌博，而随着时间的推移，这场赌博是否会得到回报，目前还没有定论。这一举措在 Prime Video 工程团队的某些敏感区域点燃了一把火。他们可能突然被要求提前提供原计划在三到五年后提供的能力。所以他们做了一个架构上的转变，这个转变可能是计划内的，也可能是被迫的。他们是否像他们的最佳实践建议的那样，在未来的道路上实现了业务灵活性？或者他们只是把 Prime Video 绑在一个服务合同上，他们的业务将被迫永远适应这个合同？从这个角度来看，人们很容易忘记哪个选项是单体，哪个是微服务。

这是我们向 AWS 的 Ajay Nair 提出的一个难题，他的回答值得密切关注，不仅仅是软件工程师：”建立一个可演化的架构软件系统是一种战略，而不是一种宗教。”

更新：自出版以来，这个故事已被更新，加入了 AWS 围绕 Step Function 提供的额外材料。

使用 OpenKruise 升级指定 Pod

Sat, 17 Jun 2023 00:17:21 +0800

最近在和同事讨论一个非典型的云原生应用更新场景。目标应用是一系列有状态的 Statefulset，其中的实例用类似投票的机制对外提供服务，这意味着始终有一部分实例是处于待命状态的。由此情况，这个应用在虚拟化时期，会提供一个仲裁服务，每次对实例进行更新时，首先要从这个仲裁服务查出可以更新的摸鱼实例，然后仅仅对这些空闲实例进行升级。

这种行为在虚拟化场景是行之有效的，到了 Kubernetes 环境就难搞了，Statefulset 的 Partition 能力官网说明如下：

RollingUpdate更新策略可以通过指定.spec.updateStrategy.rollingUpdate.partition来进行分区。如果指定了分区，当StatefulSet的.spec.template被更新时，所有序数大于或等于分区的Pod将被更新。所有序号小于分区的Pod将不会被更新，即使它们被删除，也会以以前的版本重新创建。如果一个 StatefulSet 的 .spec.updateStrategy.rollingUpdate.partition 大于其 .spec.replicas，对其 .spec.template 的更新将不会被传播到其 Pods。在大多数情况下，你不需要使用分区，但如果你想进行阶段性更新、推出金丝雀或执行分阶段推出，它们是有用的。

如此看来，分区更新能力会保护分区序号以内的连续的 Pod 保持原样，和需求中提到的随时分配情况还是颇有不同的。在我看来，更好的做法是效仿 KubeDB 系列的产品，自行控制更新行为——当然，对甲方提出这种非分要求是不合适的。既然这个需求如此的不云原生，那么先看看 Open Kruise 总不会错的。经过对其文档的阅读，有两个发现：

Partition：和 Statefulset 不同，它的 Partition 可以使用整数和百分比两种方式
可以使用标签的方式指定升级时候的优先级。

如果这两个方法能够同时生效，这个需求就有望完成了，设计要点如下：

从仲裁服务中，获得工作和空闲副本的情况
刷新 Statefulset 中的 Pod 标签，用于指示当前工作状态。
设置 Partition，将 Partition 数量设置为等于工作中的副本数量进行保护。

由此可以编写一个 Advanced Statefulset，示例如下：

apiVersion: apps.kruise.io/v1beta1
kind: StatefulSet
metadata:
  name: sample
spec:
  replicas: 5
  serviceName: fake-service
  selector:
    matchLabels:
      app: sample
  template:
    metadata:
      labels:
        app: sample
        working: "false"
    spec:
      readinessGates:
      - conditionType: InPlaceUpdateReady
      containers:
      - name: main
        image: alpine:3.18.2
        command: ['sleep', '3600']
  podManagementPolicy: Parallel
  updateStrategy:
    rollingUpdate:
      partition: 3
      unorderedUpdate:
        priorityStrategy:
          weightPriority:
          - weight: 30
            matchSelector:
              matchLabels:
                working: "true"
          - weight: 50
            matchSelector:
              matchLabels:
                working: "false"

这里的定义有几个需要关注的点：

Pod 模版中加入了 working 标签，用于指示每个 Pod 当前的工作状态。
unorderedUpdate.priorityStrategy.weightPriority：这里指定了非工作状态的 Pod 会有更高优先级。
partition 设置为 3：这里我们假设工作中的副本有 3 个。
这里镜像使用 alpine:3.18.2，作为我们的工作负载。

安装 Open Kruise

传统的 Helm 三部曲：

helm repo add openkruise https://openkruise.github.io/charts/
helm update
helm install kruise openkruise/kruise --version 1.4.0

部署应用

部署前面的 Advanced Statefulset：

$ kubectl apply -f statefulset.yaml
statefulset.apps.kruise.io/sample created

查看当前工作负载的镜像：

$  kubectl images
[Summary]: 1 namespaces, 5 pods, 5 containers and 1 different images
+----------+-----------+---------------+
|   Pod    | Container |     Image     |
+----------+-----------+---------------+
| sample-0 | main      | alpine:3.18.2 |
+----------+           +               +
| sample-1 |           |               |
+----------+           +               +
| sample-2 |           |               |
+----------+           +               +
| sample-3 |           |               |
+----------+           +               +
| sample-4 |           |               |
+----------+-----------+---------------+

可以看到五个副本用的都是 alpine:3.18.2。

标识工作负载

我们使用标签，把第 0、2、4 三个 Pod 的 working 标签设置为 true。

$ kubectl label pods sample-0 working=true --overwrite
pod/sample-0 labeled
$ kubectl label pods sample-2 working=true --overwrite
pod/sample-2 labeled
$ kubectl label pods sample-4 working=true --overwrite
pod/sample-4 labeled

更新镜像

替换镜像为 alpine:3.18.0，然后 apply：

$ kubectl apply -f statefulset.yaml
statefulset.apps.kruise.io/sample configured

验证结果

查看 Pod 状态：

$ kubectl get pods
NAME       READY   STATUS    RESTARTS   AGE
sample-0   1/1     Running   0          9m27s
sample-1   1/1     Running   0          5s
sample-2   1/1     Running   0          9m27s
sample-3   1/1     Running   0          39s
sample-4   1/1     Running   0          9m27s

可以看到，working 为 false 的 Pod 已经被更新。

查询一下所用的镜像：

$ 1 namespaces, 5 pods, 5 containers and 2 different images
+----------+-----------+---------------+
|   Pod    | Container |     Image     |
+----------+-----------+---------------+
| sample-0 | main      | alpine:3.18.2 |
+----------+           +---------------+
| sample-1 |           | alpine:3.18.0 |
+----------+           +---------------+
| sample-2 |           | alpine:3.18.2 |
+----------+           +---------------+
| sample-3 |           | alpine:3.18.0 |
+----------+           +---------------+
| sample-4 |           | alpine:3.18.2 |
+----------+-----------+---------------+

这里就看得出，工作状态的 Pod 保持原样，而非工作状态的 Pod 已经被更新。

继续推动

如果此时再次更新，应该让更新后的实例进入工作状态，把原有工作实例设为空闲，并减小 Partition 数量，所以把 1 号 Pod 设置为工作状态，同时把 4 号 Pod 设置为空闲状态，最后把分区数量缩减为 2，看看会发生什么：

$ kubectl images
[Summary]: 1 namespaces, 5 pods, 5 containers and 2 different images
+----------+-----------+---------------+
|   Pod    | Container |     Image     |
+----------+-----------+---------------+
| sample-0 | main      | alpine:3.18.2 |
+----------+           +---------------+
| sample-1 |           | alpine:3.18.0 |
+----------+           +---------------+
| sample-2 |           | alpine:3.18.2 |
+----------+           +---------------+
| sample-3 |           | alpine:3.18.0 |
+----------+           +               +
| sample-4 |           |               |
+----------+-----------+---------------+

这里看到，只有 sample-0 和 sample-2 还在使用 3.18.2 版本，其它副本都成功变更为 3.18.0 的镜像。

注

其实不难看出，要把上述功能实现到自动化流程里，还是需要编写一些控制逻辑的——以及引进一个三方软件的成本，活罪难逃不是？

这叫平台工程吗

Sat, 13 May 2023 16:04:14 +0800

本文主要内容来自于 2023 年大连 Kubernete Community Day 的演讲《集群多还是多集群？——云原生平台工程探索》

第一页——听说 DevOps 死了

2022 年底，InfoQ 发了一篇爆款文，《DevOps 已死，平台工程才是未来》，这里总结了一个太长不看版：

开发者并不想做运维，工程师不仅编写代码，还要运行他们编写的代码；
反模式：高级工程师现在要负责环境配置，并需要处理比较初级的同事的请求；
除了 CICD 之外，还有很多复杂的运维场景：配置管理、依赖管理、跨环境部署、统一的安全管控..
虽然对于像谷歌、亚马逊、Airbnb 这些比较先进的组织来说，上述方法很有效，但对于其他大多数团队而言，要在实践中复制真正的 DevOps 并不简单。

还提到 Gartner 的炒作周期图，将平台工程定义为正在上升期的技术，并且会在 2-5 年达到平台期。

其实这部分回答了我一直以来的一个小迷惑——所谓大一统的运维平台/工具，到底有没有存在的意义？是不是说假设 DevOps 团队成长起来了，就不需要这种集中产出的工具和规范了？

首先，我们来看看 DevOps，DevOps 是一种文化，而非一种角色。在 DevOps 文化中，开发和运维团队需要更紧密地协作，共同为业务提供更好的服务。但这并不意味着所有开发人员都需要成为运维专家，或者所有运维人员都需要成为开发专家。

在实践中，即使是 DevOps 团队，也需要有明确的职责划分和专业分工。大一统的运维平台/工具的存在意义就在于它可以提供一种标准化和自动化的方式，使得 DevOps 团队能更高效地进行日常工作，而不需要过度关注具体的运维细节。这并不是说 DevOps 团队成长起来就不需要这种工具了，相反，随着团队的成熟，这种工具的价值会更加明显。

再来看看高级工程师组成的 DevOps 梦之队。虽然有一些高级工程师在多个技术领域都有深厚的造诣，但是他们的存在并不能解决所有问题。专家本身的技术一定是有所侧重和偏爱的，而且在多个不同种类的工作之间进行频繁切换会严重影响效率。而且，聘用多个领域的专家组成全职能 DevOps 团队的成本非常高，这对于大多数公司来说是不切实际的。

最后，我们来看看平台工程。平台工程将复杂的运维任务抽象为平台服务，由专门的平台工程团队提供支持。这样，开发团队就可以将更多的精力投入到业务开发上，而不是被运维问题所困扰。平台工程团队一般由具有深厚运维经验和开发能力的高级工程师组成，他们可以为开发团队提供高质量的平台服务，从而提高整个组织的开发效率。因此，平台工程才是未来的趋势。

关于平台工程的文章中一般还会提到一本书：《Team Topologies》，这本书中，详细描述了通常被称为成本中心的平台团队的服务范围、交付模式、运营内容等做了一番阐述，建议 SRE 工具建设领域的朋友们阅读本书增强自信。根据本书描述，有四种基本的拓扑结构，团队应该围绕这些拓扑结构进行：

业务导向团队：与业务领域某个部分的工作流相匹配，处理核心业务逻辑。
赋能团队：帮助业务导向团队克服障碍并检测缺失的功能。
复杂子系统团队：在严重依赖数学/技术方面的专业知识时组建。
平台团队：提供一个令人信服的内部平台，提高业务导向团队的交付速度。

各自为政有什么问题

下面说点常见的场景。

第三方软件选型和采用

首先说的是云原生，很多人都领略过 Cloudscope Landscape 的宏伟壮观。选型时无从下手，尤其是面对同类项目（例如 ELK 栈和 Loki 栈，Docker 和 Podman 等）时，社交网络定选型是个常态。

然而大家心里应该都清楚，引入一个“看上去不错”开源软件进入企业系统，是有很多需要考虑的内容的，例如：

项目健康度如何？例如社区活跃程度、Issue 响应速度、社区多样性等。
是否有商业公司提供支持？
软件本身是否满足其 License 要求？软件的 License 是否能够满足企业内使用的场景需求？
软件及其依赖项合法合规吗？
除了功能之外，稳定性、可靠性、安全性等非功能特性是否满足企业需要？
运维特性，例如倒换、扩缩容、升级、备份恢复等是否完善方案，用于支撑长期运行？
…

软件选定之后还面临世界对接的问题，常见的问题包括认证、可观测性、存储等的对接，这些还是一些点状的功能，在云原生体系里，还有一个更严重的体系冲突问题。

我常用这张图来把“普通”开源软件和云原生软件的采用过程进行对比：

一个有一定规模的企业的 IT 体系，条条框框是相对固定的，软件规模不管大小，都可以服服帖帖、按部就班的落到代表体系规则的鱼骨图里，而以 Kubernetes 为代表的云原生生态则不同，其中自带了各种条条框框，不光是改了改你的部署运行方式，还对你的运维方式产生深远影响，甚至对你的应用架构指指点点。如果不照章办事，就可能和生态不兼容。因此云原生进入企业，通常会跟 IT 系统的现存规则交缠在一起，形成一种相互影响和制约的新体系。

用户又乱搞了

以我熟悉的 Kubernetes 为例，一些用户的操作，可能造成各种奇怪的不良后果，例如：

滥用节点反亲和导致无法调度
引入网络恶意镜像损失算力甚至被盗取机密
误用本地存储，Pod 漂移后数据损失
错误配置引发集群异常

Kubernetes 对象的易用性，随手可得的各种技巧，都给误操作和危险行为以可乘之机，然而实际情况是，如果是多个团队自行进行运维，可能就会产生五花八门的不同风格的集群，如下图所示：

很明显，不同团队因为各自的业务目标、技能水平等，会产生各种不同风格的集群，自然而然，不同的集群，有机会进行不同的“乱搞”，也会出现不同的问题。

我说平台工程

根据流行定义：平台工程是一门设计和构建工具链和工作流的学科，在云原生时代为软件工程组织提供自助服务能力。平台工程师提供一个集成的产品，通常被称为 “内部开发者平台”，涵盖了应用程序整个生命周期的操作需要。

以我所见，平台工程面在三个方面为组织提供支持基础设施、规范和工具：

基础设施

现代软件运行需要大量的基础设施，除了传统的网络、计算、存储之外，还包括大量的服务化的中间件等能力，OpenStack、Kubernetes 等资源编排工具也属于是传统管控难题。平台团队可以综合基础设施自有的管控运维能力，使用 Terraform、Kubernetes CRD、等资源抽象和自动化手段，为开发团队及其产品，规划、搭建、自动化和优化可靠、安全、高性能的基础设施，以支持业务的运行和发展。

规范

企业 IT 环境通常会有一系列的规范，例如设施命名、账号管理、IP 分配等等；另外操作系统、容器集群等具有极大灵活性的基础设施，也通常是需要有一定的规范化管理的，这里提到的规范至少包括：

安全规范：平台团队负责制定和实施安全规范，以确保平台和应用程序的安全性。这可能包括访问控制、身份验证、数据加密、漏洞管理等方面的规范。
部署和发布规范：平台团队可以制定规范，定义部署和发布流程，并确保它们得到正确执行。这些规范可以包括环境分离、版本控制、持续集成和持续交付等。
最佳实践：各种最佳实践可以通过规范的形式进行推行和实施。将最佳实践转化为规范的形式可以确保团队成员共享相同的理解，并提供具体的指导和标准，以便在组织中广泛应用，例如访问控制规范、文档发布规范、接口管理规范等等。
资源规范：例如资源申请和分配、生命周期管理、成本控制、审计和监控等的规范，有助于组织资源的有效利用、成本控制和性能优化。

工具

平台工程的主要产出就是一个被称为 idp（内部开发平台）的工具，以此工具为开发团队提供支持，在实际工作中，工具部分的工作内容至少包括：

外部（开源/商业）软件的导入：除了前面提到的采用开源软件的层层关卡之外，平台工程团队还应负责补齐第三方软件的运维能力、外部软件和内部平台的配套对接、开发并实施明确、有效并且成本合理的生命周期管理过程。
基础设施的供给、隔离：在基础设施自身服务接口和运维能力基础之上，为各个开发组织以及产品，规划并供给基础设施资源，尽可能让产品团队关注资源本身，并提供成本监测、优化等技术支持能力，用隔离手段防止租户和租户、租户和管理之间的不必要的资源访问。
Dev(Sec)Ops：包含供应链安全、代码质量、环境管理等的复杂 CI/CD 生命周期相关能力。
规范实施：平台或者工具，除了是业务的加速器，同时也是管理意志的执行者。纯文本的规范举步维艰，只有靠策略保障、工具辅助等方式，才能保障规范背后的管理意图的达成。

机场杂谈：挥霍 API 和 AIGC

Sun, 30 Apr 2023 10:18:39 +0800

最近总在写一些小玩意，有了 Copilot 和 ChatGPT，我得了一种奢侈的选择困难症——每次写代码之前都会犹豫一下：这次用啥语言呢？

几个小玩具

我给自己做了个播客

生娃和进厂之后，个人独处时间越发金贵，随之而来的问题就是阅读量难于保障了。过去我的阅读流程是浏览邮件列表、固定的播客、推特等信息源头，根据喜好情况搜集到 Pocket 之类的 Read it later 工具里面。但是现在因为缺乏连续时间，待读列表越来越长。想了下也就是跑步和开车的时候耳朵是比较清闲的——灵机一动：“给自己做个播客吧”。

个人使用，当然能省则省，大致定下了这样几个分工和工具：

运行平台：Google Function，免费额度足够每日使用，负责抓取网文并
存储：使用 Google 对象存储，同样免费额度
交互：Github Issue/Comment + Webhook，构成交互界面
翻译和整理：ChatGPT/DeepL，将互联网上抓取的内容进行翻译和排版
TTS：Azure TTS 服务免费额度
Buzzsprout：支持 API 的播客托管平台，能自动对接 Apple 和 Google 的播客服务目录

选定平台之后，使用 Github Issue 交互，通过 Webhook 调用 Google Function，借助各个服务，完成抓取、翻译、朗读以及发布的环节，最终形成了我自己的播客节目，怎么说呢——聊胜于无吧。

我给自己翻译了一本书

想把一本书翻译成中文，在线等，挺急的。

最近一直在看《Team Topologies》这本书，奈何我的英语水平比我的时间还有限，突然想起 @yihong0618 的项目 bilingual_book_maker，于是用了起来，使用 GPT 3.5 API，大概三个多小时，epub 就变成了一本中英同屏的读物了。如下图：

老实说翻译效果麻麻地，能看，好在是留着英文对照，倒也不会太影响阅读，推测是因为逐段翻译缺乏上下文支持造成的。

给自己请个运维专家

这是之前公众号文章中提到的 Pipe2GPT 项目，一个没头没脑的 Prompt：作为一个 IT 领域的专家，对于这段输出你有什么看法？我应该采取什么措施？，不管在控制台看到什么输出、或者日志，都用管道发给 ChatGPT，目前看来，知名软件的输出内容都能够得到具备一定可操作性的结果。

所以我想说啥

本领域知识依旧不可或缺

不论是翻译、出图、编程还是辅助创作等等，应该说都惊喜有余，可信不足的。例如

多次在利用 ChatGPT 生成代码时，出现错误的 API 地址、错误的数据结构等。AI 写代码，开发工作变成调试工作，效率不见得一定会提升。
整书翻译过程中，因为上下文长度限制，会有较多的错误结果。
出图跟编码差不多，修修补补的能力也还是要有的。

综上，毫无疑问地，ChatGPT、Midjourney 等的确能够快速出活，然而要达到交付要求，还是需要有碳基人坐镇本领域，才能达成生产级别的目标。

技术又解放了

其实最近给自己写着玩的东西远不止这些，尤其是结合 LangChain 之后，很多以前看似需要“思考”的东西，现在都可以通过一些零碎代码和零钱来解决了。如果有一点 Python 入门的开发和调试能力，结合 Copilot 或者 ChatGPT 这样的工具，就能够完成很多可用的东西了。正如我前一阵朋友圈吐槽说的——对“知其所以然”的需求，再一次被降低了。就像前面几个例子，虽然被朋友耻笑说这种不算个东西，上不得台面，但是的确解决了自己的问题，像生物信息等严重依赖编程的非 CS 专业来说，有了这些新东西的帮助，应该能大大降低工作难度，提高工作效率。

一大波新思路正在接近

用前面提到的 bilingual_book_maker 项目来说，究其本质，其实跟 ChatGPT 并没有很多关系，它只是将 ChatGPT 作为一个跟 Deepl API 等价的可选插件而已，当然这里并没有贬低这个项目的意思，相反地，这个项目给我的思考是——AIGC 的热潮，促使我们对很多传统 IT 领域进行新的审视，简单说又可以翻大饼了。这似乎是第一次，人工智能用这样触手可及的方式深入到各个领域，大概是堪比个人电脑进入家庭一样一股浪潮，除了对各种 IT 非 IT 领域的直接促进之外，应该也会促使对更多问题的深入思考——例如 HR 大概在思考的：

程序员应该裁掉多少？
实习律师留三成还是五成？
Prompt 技能要写到 JD 里面吗？怎么考核呢？
….

每个人/组织都需要自己的垂类 AI 支持

众所周知，ChatGPT 一直在嚷嚷他的数据来源仅限于 2021 年之前，以及 Token 数量的限制等（ps，很奇怪，我只申请到了 ChatGPT，一直没机会使用其它几个大模型），导致面对一些垂类或者一些非公开上下文的时候束手无策，因此不论是私有模型还是其它手段，总要有某种方法来支撑这些更加贴近业务目标的需求。

安全隐私要出大问题

ChatGPT 在很多非结构化内容的处理上都有令人有点满意的效果，例如用来审视合同、润色文字作品、撰写周报、评估简历等等。其实很难抵抗把自家材料提交给 ChatGPT 的冲动，最终面对安全隐私部门的惩处，对吧？

更有意思的是，市面上有非常多的 ChatGPT 以及其他 AIGC 平台的代理，甚至已经有了分销和盈利的运作模式，放胆设想一下，一个野生 AIGC 代理，能拿到多少不为人知的大小秘密？

编不下去了

一次喝酒时，曹老板还在笑我：这个 AI 怀疑论者买了 Copilot（甚至 Copilot 怎么读都不知道）。现在我倒是经常在琢磨如何做好一个 AIGC 带路党的事情，可惜脑容量有限，一直没头苍蝇一样四处乱撞。接着航班大延误的机会，随便把这些零碎思考记录下来吧。

ChatGPT 和我写了个小工具：Pipe2GPT

Sat, 25 Mar 2023 01:57:17 +0800

开通了尊贵的 ChatGPT Plus 之后，在平时做些控制台操作的时候，就多了个习惯——把各种控制台内容投喂给 ChatGPT，看他如何反馈。结果还是不错的，经过适当的 Prompt 设计，ChatGPT 不但能够读懂这些输出内容，更可以提供进一步排查或者解决问题的建议。

懒惰是进步的动力——我连拷贝黏贴都懒了，还是想 ChatGPT 帮我写个小工具吧。按照官方客户端情况来说，Python 才是一等公民，然而为了方便分发，而且不是自己动手，我选择了高大上的 Golang。

实现思路

其实起初我是想模仿 kubectl，用 krew 插件的形式写个 gpt-diag 子命令，例如 kubectl gpt-diag pod xxxx，直接将 Describe Pod 内容输出，结合一个关于诊断 Kubernetes Pod 信息的 Prompt 来对某种对象，于是我让 ChatGPT 使用 Cobra 给我生成一个这样的框架。有趣的是，生成途中，它根据我提供的这些对象名称，自动给这个程序加了个简介——一个 Kubernetes 检查工具。

命令行代码生成之后，要求它用接口、类的方式来定义各种检测行为，这里包含了 Pod、Node、Event、API Server、ETCD 等在 kubectl 命令中能够拿到输出的内容，每个类都有自己的 Prompt，利用 Kubernetes 获取信息，OpenAI Client 进行解答。

在这之后，我意识到一个问题：这玩法太传统了，我压根不需要替 ChatGPT 做这种前期工作，于是我删掉了这套代码，另起炉灶。

所以以下的工作步骤就四班顺滑了：

要求 ChatGPT 输出 Shell 脚本，用来初始化一个 Golang CLI 应用的目录结构。然后用 Goland 打开。
ChatGPT 生成代码，读取环境变量中的 OpenAI API Key
加入一个配置文件，要求 ChatGPT 判断命令行参数，根据 JSON 格式，生成代码
继续生成代码，从管道读取输入，加入 Prompt，调用 OpenAI。

说起来还是比较辛苦的，实际上这些功能在 ChatGPT 4.0 中一个 Prompt 就差不多搞定了：

用 golang 编写一个 CLI 应用，它带有一个配置文件，格式如下： { “data”:{“k8s”: “简明扼要地用 Kubernetes 专家的身份判断一下这段输出有什> 么问题，要整齐列出问题对象和可能原因以及操作建议：”} } 这个命令行接受 –type 参数，参数值就是配置文件中的 data.[key]。另外这个命令还要从环境变量中读取 OPENAI_APIKEY 运行时，这个工具从管道接收其它应用输出的内容，根据从配置文件中取得的值作为 > Prompt，调用 OpenAI 的 API，获得反馈内容。

我这里测试的时候，只有模型选择不太合适，其它都可以直接进行调试。

生成代码之后，Debug 一下下，基本就 OK 了。

接下来又让他生成了双语版本的 README.md。以及一个用于 golang 交叉构建的 GitHub Action。

最后，这个非人产生的项目保存在了 https://github.com/fleeto/pipe2gpt。

运行效果大致如下：

接下来我可能会在项目 README.md 里面写一句：本 REPO 仅接受 AI 生成代码，人工勿入，面斥不雅

持续监控集群中的镜像漏洞——Trivy Operator 简介

Sun, 19 Mar 2023 20:03:17 +0800

在本文中，我们将介绍 Trivy Operator，一款用于持续监控 Kubernetes 集群中的容器镜像漏洞的工具。我们将从 Trivy Operator 的简介开始，接着介绍如何安装和配置，最后探讨漏洞扫描与呈现，以及其他补充功能。

引言

当下，容器技术已成为企业构建和部署应用的关键组成部分。然而，容器镜像可能会携带软件漏洞，这些漏洞可能导致应用和数据面临安全风险。为了确保 Kubernetes 集群在运行时的持续安全，就需要自动对运行中的容器镜像进行扫描的工具。

很早以前曾经使用 Shell Operator 结合 Trivy 编写了一个小工具，对运行中的镜像进行扫描，然后把扫描结果用 Prometheus 的方式进行输出。

接下来将要介绍的 Trivy-Operator，是一个来自 Aqua 的开源工具，可以自动扫描容器镜像中已知的漏洞，并用最佳实践对 Kubernetes 资源进行验证，从而提高 Kubernetes 集群的运行时安全性。它易于安装，可以顺利地集成到监控系统中；更借助Kubernetes Operator 技术响应集群上的工作负载和其他更改，自动更新安全报告资源。Trivy-Operator 能够显著加强 Kubernetes 集群的安全性，保护其中的应用程序免受潜在威胁。

简介

在深入了解 Trivy-Operator 的使用方法之前，先简单交代一下它的大致功能：

漏洞扫描：Trivy-Operator 基于 Trivy 扫描器，对容器镜像进行全面扫描，识别其中的已知漏洞。这有助于及时发现并修复潜在的安全隐患，保护您的应用程序免受攻击。
Kubernetes 资源验证：通过与 Kubernetes API 的集成，Trivy-Operator 可以自动验证 Kubernetes 资源的配置，确保遵循安全性最佳实践。这样可以避免因配置错误导致的安全风险。
持续监控与报告：Trivy-Operator 自动更新安全报告资源，以响应 Kubernetes 集群上的工作负载和其他更改。这意味着它可以在创建新 Pod 时启动漏洞扫描和配置审核，然后更新扫描报告。这有助于实时了解集群安全状况，及时采取相应措施。
Prometheus 集成：Trivy-Operator 提供 Prometheus 指标端点，使其可以与现有的监控基础设施集成。通过Prometheus，用户可以收集和分析 Trivy-Operator 的指标数据，实现对集群安全的实时监控。通过 Prometheus 之后，还可以和 Grafana、Alert-manager 等联动，进一步提高集群的透明度和可运维性。

安装

可以通过三种方式安装和部署 Trivy Operator，YAML、Helm 和 OLM。

YAML

$ kubectl apply -f \
https://raw.githubusercontent.com/aquasecurity/trivy-operator/v0.12.1/deploy/static/trivy-operator.yaml

customresourcedefinition.apiextensions.k8s.io/clustercompliancereports.aquasecurity.github.io created
...

可以看到，这里创建了几个 CRD，都是以 reports 结尾的，看来都是各种报告，大概几个字面意思：

infraassessmentreports，clusterinfraassessmentreports：基础设施评估报告，包括 Kubernetes 核心组件的配置内容
vulnerabilityreports：漏洞报告
configauditreports、clusterconfigauditreports：配置审计报告
exposedsecretreports：Secret 报告
clusterrbacassessmentreports/rbacassessmentreports：RBAC 评估报告
clusterrbacassessmentreports：集群 RBAC 评估报告

另外还生成了一个叫做 trivy-operator 的 ServiceAccount，可以查看一下它的权限：

$ kubectl rolesum trivy-operator
ServiceAccount: trivy-system/trivy-operator
...
Policies:
...
• [CRB] */trivy-operator ⟶  [CR] */trivy-operator
  Resource                                                Name  Exclude  Verbs  G L W C U P D DC
  clustercompliancedetailreports.aquasecurity.github.io   [*]     [-]     [-]   ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖
  clustercompliancereports.aquasecurity.github.io         [*]     [-]     [-]   ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖

这里用到了 kubectl 的 rolesum 插件

可以看到，它从 trivy-operator 这个 ClusterRole 继承了大量权限，除了前面提到的 CR 之外，还包括了对 Pod、Configmap 等的读取权限，据此可以判断他的工作范围。

Helm

这个安装也比较简单，首先加入 Aqua 的仓库：

$ helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo add aqua https://aquasecurity.github.io/helm-charts
"aqua" has been added to your repositories
$ helm repo update
...
$ helm install trivy-operator aqua/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --set="trivy.ignoreUnfixed=true" \
  --version 0.12.1
...

可以用 helm show values aqua/trivy-operator 看看其中包含的丰富配置。后面也会进行一点讲解。

Operator Lifecycle Manager

OLM这是一种专门用于维护 Operator 生命周期的方式。这里暂时不做更多介绍。具体安装方式可以参照官方文档

配置

Operator Pod（trivy-operator-）支持很多环境变量用于其行为配置，下面列出一些关键内容：

OPERATOR_EXCLUDE_NAMESPACES：排除命名空间
OPERATOR_VULNERABILITY_SCANNER_ENABLED：启用漏洞扫描
OPERATOR_CONFIG_AUDIT_SCANNER_ENABLED：启用配置审计
OPERATOR_RBAC_ASSESSMENT_SCANNER_ENABLED：启用 RBAC 扫描
OPERATOR_CONFIG_AUDIT_SCANNER_BUILTIN：启用内置的配置扫描引擎
OPERATOR_WEBHOOK_BROADCAST_URL：Webhook 地址，置空则禁用该功能

另外，同一个命名空间内还有一个 Configmap，内容：

apiVersion: v1
data:
  trivy.additionalVulnerabilityReportFields: ""
  trivy.command: image
  trivy.dbRepository: ghcr.io/aquasecurity/trivy-db
  trivy.dbRepositoryInsecure: "false"
  trivy.mode: Standalone
  trivy.repository: ghcr.io/aquasecurity/trivy
  trivy.resources.limits.cpu: 500m
  trivy.resources.limits.memory: 500M
  trivy.resources.requests.cpu: 100m
  trivy.resources.requests.memory: 100M
  trivy.severity: UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL
  trivy.slow: "true"
  trivy.supportedConfigAuditKinds: Workload,Service,Role,ClusterRole,NetworkPolicy,Ingress,LimitRange,ResourceQuota
  trivy.tag: 0.38.2
  trivy.timeout: 5m0s
  trivy.useBuiltinRegoPolicies: "true"
kind: ConfigMap
metadata:
  annotations:
    ...
  name: trivy-operator-trivy-config
  namespace: trivy-system

其中的内容，熟悉 Trivy 扫描器的读者应该很容易看得出来——这里基本定义了最常用的几个 Trivy 开关。另外根据官网看来，还可以使用 trivy-operator-trivy-config Secret 的 data.trivy.githubToken 来设置用于抓取 Trivy 特征库的 Github Token。

漏洞扫描和呈现

事实上，Trivy Operator 部署之后直接就会启动扫描，生成漏洞报告（vulnerabilityreports）以及 RBAC 报告（rbacassessment），可以使用 kubectl get xx yy-o wide，或者 kubectl descrbe xx yy 来查看具体内容。例如漏洞报告显示各级别问题都是 0。

新建一个工作负载，例如 kubectl create deployment nginx --image nginx:1.16，创建之后，会发现马上出现一个 scan-vulnerabilityreport-* 的 Pod 启动了，在它完成任务消失之后，我们会看到 vulns 多了一条针对 nginx:1.16 镜像的记录，其中包含高中低各种级别的漏洞若干。

另外还新出现了一个名为 replicaset-nginx-XXX 的 ConfigAuditReport 对象，其中包含了对这个 RS 的审计内容，例如：

  - category: Kubernetes Security Check
    checkID: KSV015
    description: When containers have resource requests specified, the scheduler can
      make better decisions about which nodes to place pods on, and how to deal with
      resource contention.
    messages:
    - Container 'nginx' of ReplicaSet 'nginx-54f8f9f495' should set 'resources.requests.cpu'
    severity: LOW
    success: false
    title: CPU requests not specified

这些基本内容都可以通过 Prometheus 监控栈进行监控，并可通过 Grafana Dashboard 进行可视化呈现；或者用 Alert Manager 以及 Webhook 进行告警。

补充

其实除了 YAML 和镜像漏洞的检查之外，这个 Operator 还定义了多种合规性、安全基线方面的内容，并可以通过 REGO 语言进行自定义的基线检查。虽然多数功能还处于非正式版本，但这是一个合理的方向———对集群安全，要进行可视化的、持续的审视，而不是。。我不说了。

用 ChatGPT 评审 PR

Wed, 15 Mar 2023 11:33:55 +0800

前些天写了个脚本，用 ChatGPT 给 FloMesh 的 Pipy 项目做了个代码评审，生成的结果还挺有意思的，例如下面这段结果：

评价：

1. 代码没有明确的介绍具体的功能和作用，缺乏注释和文档说明。
2. 使用了一些不必要的注释，如版权声明和许可条款，应该将这些内容放入独立的文档中。
3. 引用了一些外部库文件，在没有说明的情况下建议在头文件中添加相关介绍。
4. 没有遵循统一的命名规范，建议遵循某种命名规范，如 Google C++ Style Guide。
5. 代码风格和排版统一，清晰易读。

改进意见：


#ifndef THREAD_HPP
#define THREAD_HPP

#include "pjs/pjs.hpp"
#include "worker-thread.hpp"

namespace pipy {

// 在代码开头添加注释，介绍文件的作用和功能
// ...

// 添加版本信息或其他相关说明
// ...

// 可以将所有依赖的外部库文件进行汇总说明
// ...

// 建议统一的命名规范，如使用 Google C++ Style Guide。
class Thread : public pjs::ObjectTemplate<Thread> {
public:
  // 在函数上添加注释，说明函数的功能和参数含义
  auto index() const -> int { return m_worker_thread->index(); }

private:
  // 在变量上添加注释，说明变量的作用和类型
  Thread(WorkerThread *worker_thread) : m_worker_thread(worker_thread) {}

  WorkerThread* m_worker_thread;

  friend class pjs::ObjectTemplate<Thread>;
};

} // namespace pipy

// 添加结尾注释
// ...

// 推荐加上 #endif 前的空格
#endif // THREAD_HPP

自然而然就产生了个想法——如果项目每个 PR 都能这样自动 Review 一下岂不妙哉？结果——好点子总会有人比你先想到，已经有人编写了一个 Github Action 了，于是试用了一下，记录一下这个试用过程。

首先在目标项目的设置中加入 OpenAI 的 API_KEY，也就是在项目的 Settings->Security->Secrets and variables->Actions 菜单中，加入 Repository Secret，Key 设置为 OPENAI_API_KEY。

接下来，在 Github Action 中加入如下代码：

name: Code Review

permissions:
  contents: read
  pull-requests: write

on:
  pull_request:
    types: [opened, reopened]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: anc95/ChatGPT-CodeReview@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          LANGUAGE: Chinese

上面代码尝试在创建 PR 时候对变更内容进行评审动作。

我们尝试给项目新建一个 PR，其中包含一段新的输出代码，并删除了一行注释，结果收到了如下的评审记录：

从结果看来，ChatGPT 对 PR 的目的进行了识别，并给出了讲解和建议。不过前面 Action 定义的语言并没有生效，应该后续还会有提升空间——或者用这个思路再做一个也是不错的想法。

另外，受到 Token 上限的影响，代码文件只能接受 4K 以下的文件，传说新的 GPT 4.0 API 能够支持更大的 Token 上限，也许就能支持更大的代码文件了。

用 ChatGPT 写了一点代码

Sun, 19 Feb 2023 21:14:35 +0800

ChatGPT 发布之后，一直在半真半假的用着：有时候写一些代码片段，例如让他用 Python、Rust 分别帮我写一点方法级别的代码；有时候会跟他“探讨”一些问题——是的你没看错，真的是探讨一些问题，例如刚刚我跟他探讨了一下 SRE、DevOps 和平台工程的区别、联系和发展情况。总的说来，如果不求输出成品，那效果还是相当不错的，至少触发灵感是没问题的。

前些天跟蔡书夸下海口，用 ChatGPT 也能给 PP 写个 Ingress 控制器来，奈何俗务缠身，一直也没能完成，今天抽出两个小时，总算完成了一个 Ingress 监听的原型代码。大体过程讲解一下。

我的第一个 Prompt：

我想用循序渐进的方式逐步用 Golang 开发一个 Ingress 控制器，我想到的步骤包括：

1. 创建目录布局 
2. 编写第一个可执行的控制台应用的圆形，并完成构建和测试运行 
3. 在这个原型基础上，加入连接 Kubernetes 集群的能力，同样完成构建和运行 
4. 加入 Watch Ingress 对象的能力。并在 Ingress 发生变化的时候输出提示信息。
首先我们完成第一个步骤，使用 shell 命令创建对应的目录结构。

是的，你没看错，我连目录结构都让他给我创建。ChatGPT 的回复很不错——必须很不错，这个太简单了：

mkdir -p my-ingress-controller/cmd/my-ingress-controller
mkdir -p my-ingress-controller/pkg/ingress
mkdir -p my-ingress-controller/pkg/kube
touch my-ingress-controller/cmd/my-ingress-controller/main.go
touch my-ingress-controller/pkg/ingress/ingress.go
touch my-ingress-controller/pkg/kube/kube.go

并且给出了解释：

这将创建一个名为 my-ingress-controller 的目录，并在其中创建 cmd 和 pkg 目录，分别用于存放主应用程序和包。此外，我们在 cmd/my-ingress-controller 目录中创建了 main.go 文件，用于编写第一个可执行的控制台应用程序的圆形；在 pkg/ingress 和 pkg/kube 目录中，分别创建了 ingress.go 和 kube.go 文件，用于存放后续的代码。

我照章办事执行之后，当然生成了对应的目录和文件，接下来我给出第二个 Prompt：

然后完成第二步骤，完成一个可执行的控制台应用的圆形。

ChatGPT 给出了经典的 Hello World 代码，填充了 my-ingress-controller/cmd/my-ingress-controller/main.go：

package main

import (
    "fmt"
)

func main() {
    fmt.Println("Hello, Ingress!")
}

接着他解释了代码的作用，提示使用 go build -o my-ingress-controller ./cmd/my-ingress-controller 命令进行构建。

对此我的回复是

go build 执行失败了，返回信息“go: go.mod file not found in current directory or any parent directory; see 'go help modules'”

ChatGPT 回应大意是：

这是因为 Go 1.11 版本后引入了模块（module）的概念，用于解决依赖管理的问题。如果我们的项目使用了 Go 模块，则需要在项目根目录中创建一个 go.mod 文件来记录项目的依赖关系。

go mod init my-ingress-controller

如果你使用的是 Go 1.16 及以上的版本，也可以使用以下命令自动初始化 Go 模块：go mod init

照章办事之后，果然构建通过了。

运行成功后，我们开始连接 Kubernetes，对此我给出的 Prompt 是：

这一步运行成功之后，我们完成第三个步骤，加入连接 Kubernetes 集群的代码。并再次进行构建和试运行。

ChatGPT 并未含糊，给出了 kube.go 和 main.go 的代码：

// kube.go 两种方法进行连接
package kube

import (
    "k8s.io/client-go/kubernetes"
    "k8s.io/client-go/tools/clientcmd"
    "k8s.io/client-go/rest"
)

func NewClient() (*kubernetes.Clientset, error) {
    config, err := clientcmd.BuildConfigFromFlags("", clientcmd.RecommendedHomeFile)
    if err != nil {
        return nil, err
    }
    clientset, err := kubernetes.NewForConfig(config)
    if err != nil {
        return nil, err
    }
    return clientset, nil
}

func InClusterConfig() (*rest.Config, error) {
    return rest.InClusterConfig()
}

//main.go：列出 Namespace

package main

import (
    "fmt"
    "my-ingress-controller/pkg/kube"
)

func main() {
    client, err := kube.NewClient()
    if err != nil {
        fmt.Println(err)
        return
    }
    namespaces, err := client.CoreV1().Namespaces().List(context.Background(), metav1.ListOptions{})
    if err != nil {
        fmt.Println(err)
        return
    }
    for _, ns := range namespaces.Items {
        fmt.Println(ns.Name)
    }
}

在这个步骤之后，ChatGPT 开始不太灵了，主要出现的问题包括：

Client-Go 和 Kubernetes 之间存在对应关系，他对于这方面并没有一个稳定的假设，导致 API 的兼容频频出错
偶尔会在 Import 方面出现疏漏

Import 问题基本上来说，贴出构建错误就能解决；而版本问题则需要反复调试和提示才得以解决。

最后的一个坑是，他给我生成的 Informer 语句如下：

informerFactory := informers.NewSharedInformerFactoryWithOptions(
    client, 
    0,
    informers.WithNamespace("default"),
    informers.WithTweakListOptions(func(options *metav1.ListOptions) {
        options.LabelSelector = "app=my-ingress-controller"
    }),
)

这里暗含了对命名空间和标签的要求，导致测试无法通过。在我发现问题发出疑问时，这位很淡定的回答：

是的，如果要测试 Ingress 资源的监控，可以在创建 Ingress 资源的时候添加一个 app=my-ingress-controller 的标签，这样就会触发事件并输出日志信息。

也算总结吧

所以以后学编程，是不是可以不用费劲加那么多啥微信群了？

在 SPIRE 中用 SSH 证实节点身份

Sat, 17 Dec 2022 20:16:36 +0800

前面关于 SPIRE 的内容中，介绍了使用 JOIN Token 证实节点身份的方法。这种方法比较简易，但是完全依赖 SPIRE Server/Agent 的“内循环”，并不利于外部管理，同时每次节点更新，都要照本宣科的重来一遍。对于动态集群来说，这种方式并不理想，SPIRE 包含了面向 OpenStack、几大公有云以及 TPM 等的花钱证实节点身份的方案；除了这些之外，还有个经济型的证实方法——使用 SSH。

我们一般使用的免密登录 SSH 方案通常是点对点的，总结来说就是服务器和客户端各自有各自的公私钥，互相进行信任操作：

SSHD 会自动生成服务器端的公私钥
客户端通常使用 ssh-keygen 命令生成自己的公私钥
客户端将服务器端的证书脚印加到自己的 know_hosts 文件里面，代表信任该地址和证书的组合
服务器将客户端的公钥加到服务侧特定用户的 authorized_keys 文件之中，代表认可以该密钥作为特定用户的身份证明。

不难看出，这个过程实际上是跟前面的 JOIN Token 方式是对等的，并不会提升节点证实过程的可管理性。因此 SPIRE 的 SSH 插件要求使用基于 CA 的 SSH 方法。

用 CA 进行 SSH 认证

这种方式比上面的点对点认证方式稍微复杂一些。主要区别在于：

主机身份和用户身份都用 CA 进行签署
同样地，主机和用户身份的互信，也是通过对 CA 的信任完成

大概要完成几个工作：

创建节点 CA 证书，SSH 客户端信任该 CA 证书
用节点 CA 签发主机证书，并将服务端证书记录在 SSHD 的配置文件中。
创建客户端 CA 证书，SSH 服务端信任该 CA 证书
使用客户端 CA 签发用户证书，以此作为登录凭据。

例如 ChatGPT 告诉我的步骤是这样的：

几个关键的命令：

生成并配置 HostKey

下面的命令可以用于 SSHD 初始化，利用 CA 生成 HostKey：

ssh-keygen -s /etc/ssh/ca \
     -I "$(hostname --fqdn) host key" \
     -n "$(hostname),$(hostname --fqdn),$(hostname -I|tr ' ' ',')" \
     -V -5m:+3650d \
     -h \
     /etc/ssh/ssh_host_rsa_key.pub \
     /etc/ssh/ssh_host_dsa_key.pub \
     /etc/ssh/ssh_host_ecdsa_key.pub

查看一下生成的证书内容：

$ ssh-keygen -L -f ssh_host_rsa_key-cert.pub
ssh_host_rsa_key-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com host certificate
        Public key: RSA-CERT SHA256:[...]
        Signing CA: RSA SHA256:[...] (using rsa-sha2-512)
        Key ID: "ssh"
        Serial: 0
        Valid: from 2022-12-16T08:12:02 to 2032-12-13T08:17:02
        Principals:
                ssh
                ssh
                10.211.55.9
                fdb2:2c26:f4e4:0:21c:42ff:fe2a:18c4
        Critical Options: (none)
        Extensions: (none)

配置 HostKey

生成主机凭据之后，将证书和密钥信息加入 /etc/ssh/sshd_config：

HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

让客户端信任主机 CA

和前面提到的 FingerPrint 方式类似，把 CA 证书公钥加入到客户端的 ~/.ssh/know_hosts 之中，例如：

@cert-authority * ssh-rsa ...AAAAB3NzaC1yc2EAAAADAQABAAABgQCb... someone@ssh

生成客户端证书

和前面生成主机身份证书的情况类似，这次去掉了 -h 参数：

ssh-keygen -s /etc/ssh/ca \
    -I "$(whoami)@$(hostname --fqdn) user key" \
    -n "$(whoami)" \
    -V -5m:+3650d \
    ~/.ssh/id_rsa.pub

服务端信任客户端证书 CA

同样在 /etc/ssh/sshd_config 配置中加入 TrustedUserCAKeys，具体取值为用户 CA 的公钥文件名。

完成这些内容之后，如果使用新的身份证书登录成功，则代表前置任务完成。否则可以参考以下材料：

SPIRE 配置

前面的 SSH 配置只是个铺垫。SPIRE 使用 SSHPOP 实现了 Server 和 Agent 侧的节点证实插件，两个插件需要协同工作，官网的说明非常简明扼要：

稍稍延展说明一下需要注意的要点：

SPIRE Agent 所在的节点实际上是作为 SSH 的服务端
SPIRE Agent 联系 SPIRE Server 之后，SPIRE Server 要通过 SSH 来访问 SSH 服务端来确认身份。

因此上面语焉不详的配置就比较清楚了：

SPIRE Server 的 cert_authorities 需要的是客户端证书内容，例如 ["ssh-rsa XXXX46IvQ+bDEXYvf8pM= someone@ssh"]
SPIRE Server 的 cert_authorities_path 指向节点 CA 公钥，例如 XXXX/ca.pub
SPIRE Agent 的 host_cert_path 指向主机证书文件，例如 XXXX_key-cert.pub
SPIRE Agent 的 host_key_path 指向密钥文件，例如 XXXX_key

配置完成之后，启动 SPIRE Server，获取并把 Trust Bundle 传递给 SPIRE Agent，启动 SPIRE Agent，可以看到生成了形如 "spiffe://spiffe.dom/spire/agent/sshpop/XXXX 的 SVID，说明这个证实过程已经成功完成。

后记

本以为这是个顺便完成的东西，结果从来没想过 SSH 还有个 CA 这样的玩意，卡了好些时间，轻敌了。

另，值此辞旧迎新之际，祝大家身体健康、事业稳定、学习进步、物资充足——最重要运气爆棚吧：）

用 SPIRE 为 Pod 提供身份

Thu, 24 Nov 2022 21:55:45 +0800

开始之前

SPIFFE 是一个认证框架，能为多种节点和工作负载类型提供证实能力，解决“我是我”的问题，前面文章演示过用 SPIRE 给类 Unix 进程提供身份的方法，今天这篇就试试给 Pod 提供身份。

这次实验会在前面的基础之上，在 Kubernetes 集群之外运行独立的 SPIRE Server，在集群中用 Pod 的形式运行 SPIRE Agent 作为节点，最后在其它 Pod 中访问 SPIRE Agent，获取 SVID。本文所涉及的对象关系如下图所示：

开始之前，需要做一些准备：

有一个 Kubernetes 集群，Kind 或者 Minikube 也都是可以完成测试的。
SPIRE 1.5.x 的二进制文件，可以从 https://spiffe.io/downloads/ 下载
构建镜像所需的基础镜像和 Podman/Docker 等工具。

Kubernetes 相关插件

这里要用到 SPIRE 的三个插件：

Kubernetes Node Attestor：用于证实 Node 身份，需要分别在 Server 和 Agent 两侧进行配置。目前可以选择 k8s_sat 或者 k8s_psat 两种插件，两侧的插件选择应保持一致，分别用于 ServiceAccount Token 和新版本 Kubernetes 中新增的 Projected ServiceAccount Token，本文选择的是 k8s_sat。

Projected Token 具有更好的安全性，延伸阅读：https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/）

Kubernetes Bundle：Trust Bundle 是数字证书的集合，在 Kubernetes 中往往需要使用 Configmap 来存储和共享，所以一个直接的想法就是通过 spire-server bundle show 命令来获取证书集合，并生成 Configmap。但是这个插件可以方便地通过 Kubernetes API 来自动维护证书集合到 Configmap 的转换过程，并自动完成轮转工作。

Kubernetes Workload Attestor：用于证实 Workload 身份，只需要在 Agent 中配置即可。

配置和启动 SPIRE Server

简单粗暴上配置：

server {
...
    }
}

plugins {
    DataStore "sql" {
...
    }

KeyManager "disk" {
...
}

    Notifier "k8sbundle" {
        plugin_data {
            kube_config_file_path = "/home/dustise/.kube/config"
        }
    }

    NodeAttestor "k8s_sat" {
        plugin_data {
            clusters = {
                "kindcluster" = {
                    service_account_allow_list = ["spire:spire-agent"]
                    use_token_review_api_validation = true

上面的 SPIRE Server 配置中，省略了通用部分，具体内容可以参考前面一篇文章，重点看一下两节 Kubernetes 相关配置。

k8sbundle 的作用就是把 Trust Bundle 内容保存到 Configmap 里面，因此是需要和 API Server 打交道的，这里给他直接配置了一个 KubeConfig 文件，访问方式还有其他的配置内容，可以参考官方文档。要注意的是，这里使用的 KubeConfig 文件所包含的账号是 Cluster Admin 权限，如果使用其他的账号，需要具备对 Configmap 进行 create 和 patch 操作的授权。

k8s_sat 一节中，clusters 字段是一个 Map，其中可以对接多个 Kubernetes 集群，这里我们填充了三个字段：

service_account_allow_list：允许 Agent 注册时使用的 Service Account。
use_token_review_api_validation：使用 TokenReview API 对 Serivce Account Token 进行验证，除此之外，还可以使用证书进行认证。
kube_config_file：和 API Server 进行沟通的凭据。

和 Bundle 类似，这里同样需要具备一定的权限来完成 SPIRE Server 的工作，

Configmap 的 patch、get、list
tokenreviews 的 create

创建好配置文件之后，可以先在目标集群中创建 spire 命名空间。使用 spire-server -config=[config file path] 命令启动服务器。稍后会在集群中看到新建的 Configmap。

更多配置信息可以参考官方文档

Server 启动成功后，可以提前为工作负载创建 Node 和 Entry：

spire-server entry create -socketPath=socks/spire-server.sock \
    -spiffeID spiffe://spiffe.dom/clusters/kindcluster \
    -selector k8s_sat:cluster:kindcluster -node

spire-server entry create -socketPath=socks/spire-server.sock \
    -spiffeID spiffe://spiffe.dom/ns/default/sa/default \
    -parentID spiffe://spiffe.dom/ns/spire/sa/spire-agent \
    -selector k8s:ns:default \
    -selector k8s🈂️default

首先用 k8s_sat:cluster:kindcluster 创建了一个在 spiffe.dom 中的 Node 条目，它的 SPIFFE ID 是 spiffe://spiffe.dom/clusters/kindcluster；

接下来以 Node 条目为上级，使用 k8s:ns:default + k8s🈂️default 的 Selector，创建一个 SPIFFE ID spiffe://spiffe.dom/ns/default/sa/default，代表在 default 命名空间中用 default Service Account 身份运行的 Pod。

创建 Agent

在运行 Agent 之前，首先要制作一个镜像，这里偷懒的使用现成二进制进行构建：

FROM busybox:1.35.0-glibc
RUN mkdir -p /spire/bin
COPY spire-agent /spire/bin
CMD ["/spire/bin/spire-agent", "-config=/spire/conf/k8s-agent.conf"]

这里要创建一个 Agent 的工作负载，为了让 Agent 能够通过进程号查询工作负载的 Pod 信息，并对工作负载提供 Workload API，需要满足几个条件：

Agent 需要有授权访问 Kubernetes 的特定资源
共享 Socket 文件，让 Workload 可以访问 Agent 提供的 Workload API
能够识别调用 Workload API 的进程的 Pod 信息，从而生成 Selector

综合以上考虑，我们需要设计这样的 Workload：

用主机卷的方式在每个节点上暴露 Socket
能够访问 Trust Bundle 所在的 Configmap
Agent 和 Workload 共享 IPC 空间，便于通过进程号识别身份
Agent 所使用的 Service Account 需要具备和 API Server/Kubelet 通信查询信息的能力。

因此产生如下的 YAML 片段：

    spec:
      hostPID: true
      hostNetwork: true
      serviceAccountName: spire-agent
...
      containers:
        - name: spire-agent
          image: gcr.io/spiffe-io/spire-agent:1.5.0
          args: ["-config", "/run/spire/config/agent.conf"]
          volumeMounts:
            - name: spire-config
              mountPath: /run/spire/config
              readOnly: true
            - name: spire-bundle
              mountPath: /run/spire/bundle
            - name: spire-agent-socket
              mountPath: /run/spire/sockets
              readOnly: false        
      volumes:
        - name: spire-config
          configMap:
            name: spire-agent
        - name: spire-bundle
          configMap:
            name: spire-bundle
        - name: spire-agent-socket
          hostPath:
            path: /run/spire/sockets
            type: DirectoryOrCreate
...

这段 YAML 有几个要点：

使用了符合 SPIRE Server 配置中要求的 ServiceAccount
HostPID 共享主机 PID 空间
HostNetwork 共享主机网络空间
加载 Trust Bundle 所在的 Configmap
加载一个主机卷用于输出 Socket 文件
用一个 Configmap 保存配置文件并加载

Agent 的配置文件如下：

agent {
  data_dir = "/run/spire"
  log_level = "DEBUG"
  server_address = "10.211.55.5"
  server_port = "8081"
  socket_path = "/run/spire/sockets/agent.sock"
  trust_bundle_path = "/run/spire/bundle/bundle.crt"
  trust_domain = "spiffe.dom"
}

plugins {
  NodeAttestor "k8s_sat" {
    plugin_data {
      cluster = "kindcluster"
    }
  }

  KeyManager "memory" {
...
  }

  WorkloadAttestor "k8s" {
    plugin_data {
      skip_kubelet_verification = true
    }
  }
}

Agent 配置相对来说稍显复杂：

server_address 和 server_pod，用于访问前面启动的 SPIRE SERVER
trust_bundle_path 引用 Configmap 的加载路径即可
trust_domain 需要保持和 SPIRE Server 定义一致
k8s_sat 的 cluster 字段中，集群名称需要和 SPIRE Server 的 Map 中的定义匹配
skip_kubelet_verification：跳过对 Kubelet 证书的检查

Agent 使用的 Service Account 也需要进行 RBAC 授权，需要能够对 pod、node 以及 node/proxy 进行 get 操作。

先后把配置 Configmap、RBAC 以及 Daemonset 等资源提交之后，会看到 Agent Pod 启动。

启动客户端

任意启动一个客户端程序，为模仿接入 Workload API 的实现，其中还是需要使用 SPIRE Agent 的二进制。客户端应该使用 Agent 的 Socket 访问 Wokrload API，同时为了表明身份，同样需要用 HostPID 供 Agent 识别，因此运行如下工作负载：

...
      hostPID: true
      hostNetwork: true
...
      containers:
        - name: client
          image: gcr.io/spiffe-io/spire-agent:1.2.3
          command: ["sleep"]
          args: ["1000000000"]
          volumeMounts:
            - name: spire-agent-socket
              mountPath: /run/spire/sockets
              readOnly: true
      volumes:
        - name: spire-agent-socket
          hostPath:
            path: /run/spire/sockets
            type: Directory

Pod 在 default 命名空间启动之后，进入 Shell 使用 spire-agent api fetch 命令，就能成功的获取 SVID 了：

$ bin/spire-agent api  fetch -socketPath=/run/spire/sockets/agent.sock
Received 1 svid after 83.772792ms

SPIFFE ID:              spiffe://spiffe.dom/shutup
SVID Valid After:       2022-11-24 17:02:03 +0000 UTC
SVID Valid Until:       2022-11-24 17:04:13 +0000 UTC
CA #1 Valid After:      2022-11-23 14:57:51 +0000 UTC

To be continued

现在我们就用一个非常笨拙的方法，把 Kubernetes 的工作负载识别能力接入到了 SPIRE Server 里面了。事实上接入 Kubernetes 还有别的部署和使用方式，例如使用 CRD、在集群内运行 SPIRE Server、使用 Envoy 等接入 Workload API 等。官网文档中对这些案例都有较为详细的指导。

结合前面对于 Ghostunel 等的介绍，不难看出，打通虚拟机和 Kubernetes 工作负载身份是可行的，而根据联邦一文的描述，这个体系还可以和 OIDC 等进行互通，进一步扩大 SPIFFE SVID 的版图。

Scaling Spire.md

Thu, 24 Nov 2022 21:41:44 +0800

原文：Scaling SPIRE

SPIRE 的容量是有限的，随着工作负载强度的不同，需要有不同的规模。一套 SPIRE 中的 Server 部分，可能由一或多个共享数据存储的 SPIRE Server 组成；还可以是同一信任域的多个 SPIRE Server；至少有一个 SPIRE Agent，当然，多数时候是多个 Agent。

部署规模和负载规模相关。单个 SPIRE Server 能够承载一定数量的 Agent 和注册项。SPIRE Server 负责管理和签发注册项的身份，因此它的内存和 CPU 消耗是随着负载注册条目的数量线性增长的。单一的 SPIRE Server 部署还可能导致单点失败。

SPIRE Server 可以用水平扩展的方式支持大量的 Agent 和工作负载。多个 Server 的情况下，运算任务会分布到多个 SPIRE Server 实例之中。除了算力增加，多实例部署也避免了单点失败的风险。

高可用模式的 SPIRE Server

要用水平扩展的方式来实现高可用和分布式计算，只需要让所有服务器共享同一个信任域和数据存储就可以了。

SPIRE Server 会把注册项和身份映射策略等动态配置信息进行持久化，缺省情况下会使用内置的 SQLite，同时可以使用多种 SQL 数据库进行存储，还可以通过插件将数据保存在 Kubernetes 的 CRD 之中。所以要对 SPIRE Server 进行水平扩展之前，就要选择满足需求的数据存储方式。这方面的内容可以参考数据存储插件文档。

高可用模式里，每个服务器都管理着自己的 CA，这个 CA 可能是自签发，也可能是一个共享的上游根 CA 所签发的中间证书。

选择 SPIRE 部署拓扑

SPIRE 有三种部署拓扑：

单信任域
嵌套 SPIRE
SPIRE 联邦

管理域边界、工作负载数量、高可用需求、供应商数量以及认证需求都是部署方案的决策输入项。

单信任域

单信任域拓扑适用于独立环境或者一个管理域内的多个环境共享。单信任域的最大好处就是从单一 CA 中签发身份证书，能有效降低 SPIRE Server 的部署管理的复杂度。

然而要跨越 Region、平台或者供应商的话，单信任域就面临容灾、分布等需求的挑战了。这种情况下，嵌套部署就比较有优势了。

嵌套 SPIRE

SPIRE 的嵌套部署呈现了一种链式结构，虽然是多个 Server，但是签发的是同一个信任域的身份，这样所有工作负载的身份都处在同一个信任域里，能够用该信任域的根密钥进行校验。

嵌套拓扑中，下游 SPIRE Server 和上游的 SPIRE Agent 共同部署。下游 SPIRE Server 通过使用 Workload API 获取凭据，这些凭据会用于和上游 SPIRE Server 进行通信获取中间 CA。

一种便于理解嵌套拓扑的思路：上游 SPIRE 服务器是一个（或者是一组高可用部署的）全局服务器，下游 Server 是 Region 或者集群级的。

在这种情况下，顶层 SPIRE Server 掌管着根证书/密钥，下游服务器会向上层请求中间证书，用于下游 CA。这样即使是顶层服务宕机，中间服务器还能继续运作，一定程度上提高了可用性。

嵌套逻辑也能用于多云环境。对 Node Attestor 进行匹配之后，下游服务器能够为不同的云供应商环境中的工作负载和 Agent 提供证明。

水平扩展 SPIRE Server，达到高可用和负载均衡的目的，作为互补，嵌套拓扑可以作为一种遏制策略来对故障域进行分割。

SPIRE 联邦

有时会需要多个信任根共存：有的组织会有不同的分隔和不同的管理，或者多个环境之间偶尔进行通信。

还有一种用例就是在组织之间（例如云供应商和客户之间）进行 SPIFFE 的互操作。

这种多信任域和互操作需要良好定义的互操作方法，让一个信任域的工作负载能够认证另一个信任域的工作负载。互信的技术细节可以参考 https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Trust_Domain_and_Bundle.md#5-spiffe-bundle-endpoint，具体操作可以阅读 https://github.com/spiffe/spire-tutorials/tree/main/docker-compose/federation

和外部系统的互动

SPIFFE 兼容系统

SPIFFE 身份能够和其它提供了 SPIFFE 联邦接口的系统对接，在联邦中进行安全的认证和通信。和 SPIRE 联邦类似，可以在 SPIFFE 兼容的系统之间（例如 Istio 和 SPIRE，或者两个 Istio 之间）建立联邦。

例如目前的 Istio 中所有的应用都在同一个信任域里，或者说是共享一个信任根。可能存在多个服务网格，或者服务网格中的应用需要和外部的服务进行受保护的通信。联邦 SPIFFE 就可以用来够完成网格之间或者网格内外的互信关系。

OIDC-Provider

针对公有云之类的 OIDC 兼容的提供商，SPIRE 能够代表通过认证的工作负载和远端系统进行可编程的认证。例如在 AWS 上，SPIRE 认证的工作负载能够和 AWS S3、RDS 或者 AWS CodePipeline 进行通信。

SPIR OIDC Discovery Provider 用 ACME 协议获取 Web PKI 证书，这个证书用于一个端点的安全，这个端点会提供 OIDC 兼容的 JWKS 包以及标准的 OIDC 发现文档。远程 OIDC 认证服务进行配置之后，能够定位到这一端点，并对 WebPKI 服务进行验证。配置生效后，远端系统的 IAM 策略和角色可以和 SPIFFE ID 进行映射。工作负载可以使用 JWT-SVID 访问 OIDC 认证的系统。被访问系统从预定义的 OIDC 发现服务 URI 中获取 JWKS，如果 JWT-SVID 中包含的 SPIFEE ID 是被允许访问该资源的，就放行。这样一来，工作负载就能访问外部远程服务，无需额外处理认证问题了。

OIDC 发现服务配置：https://github.com/spiffe/spire/tree/main/support/oidc-discovery-provider

AWS OIDC 联邦指南：https://spiffe.io/spire/try/oidc-federation-aws/

部署规模评估

在评估 SPIRE 部署规模时，需要考虑如下因素：

SVID 和根证书的 TTL

每节点的工作负载数量

JWT-SVID 的用量（JWT 必须按需签署，不像 x509 是预生成的）

注册项的变更频率

SPIRE 服务所在节点上的其它进程

底层基础设施环境的形态和容量

数据存储的设计规划非常重要。上表没有提到数据存储问题，但它会对 SPIRE 性能造成潜在限制。每次 Agent（每 5 秒钟）的认证同步，都是一个昂贵的操作，数据存储可能成为性能瓶颈。嵌套拓扑中每个 SPIRE 服务器都存储自己的数据，因此可以降低这种成本。

下表尝试呈现一个 SPIRE 的规格指导。数据来自于一个测试环境，所以无法对任何用户的实际环境提供保障，只能在数量级上给出一个参考。网络带宽和数据性能没有包含在内。另外工作负载和 Agent 数量也不代表 SPIRE 规模的理论上限。

Number of Workloads	10 Agents	100 Agents	1000 Agents	5000 Agents
10 Workloads	2 Server Units with 1 CPU core, 1GB RAM	2 Server Units with 2 CPU cores, 2GB RAM	2 Server Units with 4 CPU cores, 4GB RAM	2 Server Units with 8 CPU cores, 8 GB RAM
100 Workloads	2 Server Units with 2 CPU cores, 2GB RAM	2 Server Units with 2 CPU cores, 2GB RAM	2 Server Units with 8 CPU cores, 8 GB RAM	2 Server Units with 16 CPU cores, 16 GB RAM
1,000 Workloads	2 Server units with 16 CPU Cores, and 8GB RAM	2 Server units with 16 CPU Cores, and 8GB RAM	2 Server units with 16 CPU Cores, and 8GB RAM	4 Server units with 16 CPU Cores, and 8GB RAM
10,000 Workloads	4 Server units with 16 CPU Cores each, and 16 GB RAM	4 Server units with 16 CPU Cores each, and 16 GB RAM	4 Server units with 16 CPU Cores each, and 16 GB RAM	8 Server units with 16 CPU Cores each, and 16 GB RAM

用 Ghostunnel 和 SPIRE 为 NGINX 提供 SPIFFE 认证

Sat, 22 Oct 2022 21:55:16 +0800

之前对 SPIFFE 和 SPIRE 进行了一个相对全面/啰嗦的介绍，这一篇就反过来，用一个简单的例子来展示 SPIRE 的基本用法，本文中会以 NGINX 作为服务生产方，使用 Ghostunnel 当做 NGINX 的反向代理，把原有的 HTTP 通信升级为支持定期正顺轮转的双向 TLS 认证协议，并且用 CURL 使用客户端证书来通过 Ghostunnel 安全地访问背后的 NGINX。这里为 CURL 和 NGINX 提供证书以及轮转的，就是 SPIRE 的 Server 和 Agent。

Ghostunnel 是一个简单的 TLS 代理，能为非 TLS 的后端提供双向认证能力。Ghostunnel 能够以服务端（反向代理）或者客户端（代理）的模式进行工作，类似 stunnel。不同的是，他还支持访问控制、证书轮转、ACME 以及最近总在唠叨的 SPIFFE。

本文中会演示的过程实际上是 Ghostunnel 的 SPIFFE DEMO 的一个精简版，会略细致讲述每个步骤涉及的内容。整个过程分为如下一些环节：

环境准备：准备运行环境，包括 SPIRE Agent/Server 的构建、NGINX 的安装、以及 Ghostunnel 的构建等
编写 SPIRE Server 配置，并启动
生成 Ghostunnel 以及 CURL 的 Agent Token，并编写配置文件启动对应的 SPIRE Agent
启动 Ghostunnel
获取 CURL 客户端证书并测试连接

环境准备

这里使用的是基于 ARM 的一个 Ubuntu 系统，使用 APT 安装并启动 NGINX。另外后续步骤还需要 GIT 工具以及连接 GITHUB，并使用 GOLANG 构建 SPIRE 以及 Ghostunnel。

GIT 获取 SPIRE 版本，并进行构建：

$ git clone --single-branch --branch v1.4.0 https://github.com/spiffe/spire.git
Cloning into 'spire'...
...
$ cd spire
$ make bin/spire-agent
Installing go1.18.4...
Building bin/spire-agent...
$ make bin/spire-server
Building bin/spire-server...

接下来获取 Ghostunnel 并进行构建：

$ git clone https://github.com/ghostunnel/ghostunnel.git
Cloning into 'ghostunnel'...
...
$ make ghostunnel
go build -ldflags '-X main.version=v1.6.1-25-g8ae18ea' -o ghostunnel .
...

构建成功后，把三个新生成的可执行文件拷贝到可见目录备用。

spire-101
- certs
- conf
- data
- logs
- socks

编写 SPIRE Server 配置并启动服务

server {
    bind_address = "0.0.0.0"
    bind_port = "8081"
    socket_path = "socks/spire-server.sock"
    trust_domain = "spiffe.dom"
    data_dir = "data/spire-server"
    log_level = "DEBUG"
    ca_ttl = "30m"
    default_svid_ttl = "2m"
    ca_subject = {
        country = ["CN"],
        organization = ["FUNNY"],
        common_name = "",
    }
}

plugins {
    DataStore "sql" {
        plugin_data {
            database_type = "sqlite3"
            connection_string = "data/spire-server/datastore.sqlite3"
        }
    }

    NodeAttestor "join_token" {
        plugin_data {
        }
    }

    KeyManager "disk" {
        plugin_data {
            keys_path = "data/spire-server/keys.json"
        }
    }
}

此处配置文件的几个要点：

TCP 监听 0.0.0.0:8081
监听 Socket 路径为 socks/spire-server.sock
使用 spiffe.dom 作为信任域
SVID 的默认寿命为 2 分钟
使用 SQLite3 作为数据存储引擎，数据库文件保存在 data/spire-server/datastore.sqlite3
在本地存储 Key，路径为 data/spire-server/keys.json。

然后用这个配置文件启动 SPIRE Server：spire-server run -config conf/spire-server.conf > logs/spire-server.log 2>&1 &

启动 Agent

这个小实验需要用到两个 Agent，分别负责服务端和客户端的身份。在运行 Agent 之前，首先要获取 SPIRE Server 的 Trust Bundle：

$ spire-server bundle show \
  -socketPath socks/spire-server.sock > conf/bundle.crt

上述命令将 Trunst Bundle 保存到文件 conf/bundle.crt。

服务端 Agent 配置文件如下：

agent {
    data_dir = "data/server-side-agent"
    log_level = "DEBUG"
    server_address = "127.0.0.1"
    server_port = "8081"
    socket_path ="socks/server-side-agent.sock"
    trust_bundle_path = "conf/bundle.crt"
    trust_domain = "spiffe.dom"
}

plugins {
    NodeAttestor "join_token" {
        plugin_data {
        }
    }
    KeyManager "disk" {
        plugin_data {
            directory = "data/server-side-agent"
        }
   }
   WorkloadAttestor "unix" {
        plugin_data {
             discover_workload_path = true
        }
    }
}

这个配置的要点是：

使用 127.0.0.1:8081 作为 SPIRE Server
监听 socks/spire-server.sock
信任 conf/bundle.crt
Unix Workload Attestor 中开放了选项 discover_workload_path，从而可以通过二进制文件位置或者哈希识别调用 Agent 的应用的身份

为这个 Agent 创建一个 Token，用于标识 Agent 的身份：

$ spire-server token generate \
    -socketPath socks/spire-server.sock \
    -spiffeID spiffe://spiffe.dom/server-node
Token: [Token Hash]

上面命令生成了一个 Token，其 SPIFFE ID 为 spiffe://spiffe.dom/server-node。然后启动服务侧 Agent：

$ spire-agent run \
    -config conf/client-side-agent.conf \
    -joinToken [Token Hash] > logs/client-side-agent.log 2>&1 &

接下来启动客户侧的 Agent，配置文件如下：

agent {
    data_dir = "data/client-side-agent"
    log_level = "DEBUG"
    server_address = "127.0.0.1"
    server_port = "8081"
    socket_path ="socks/client-side-agent.sock"
    trust_bundle_path = "conf/bundle.crt"
    trust_domain = "spiffe.dom"
}

plugins {
    NodeAttestor "join_token" {
        plugin_data {
        }
    }
    KeyManager "disk" {
        plugin_data {
            directory = "data/client-side-agent"
        }
   }
   WorkloadAttestor "unix" {
        plugin_data {
        }
    }
}

跟上面的类似，我们也需要创建 Token 之后才能启动 Agent：

$ spire-server token generate \
    -socketPath socks/spire-server.sock \
    -spiffeID spiffe://spiffe.dom/client-node
Token: [Token Hash]

使用上述 Token 和配置文件启动 Agent：

$ spire-agent run \
    -config conf/client-side-agent.conf \
    -joinToken "$TOKEN" > logs/client-side-agent.log 2>&1 &

启动 Ghostunnel

首先要给 Ghostunnel 一个身份，也就是 Entry：

$ spire-server entry create \
    -selector unix:path:/usr/local/bin/ghostunnel \
    -socketPath socks/spire-server.sock \
    -spiffeID spiffe://spiffe.dom/ghost \
    -parentID spiffe://spiffe.dom/server-node
Entry ID         : fe4b1fd5-9e0a-440b-b08e-5c2c886b6a6e
SPIFFE ID        : spiffe://spiffe.dom/ghost
Parent ID        : spiffe://spiffe.dom/server-node
Revision         : 0
TTL              : default
Selector         : unix:path:/usr/local/bin/ghostunnel

上面的命令参数解释如下：

selector：类似 Kubernetes 中的 Label Selector，用 Workload 属性来界定身份，这里使用的是二进制路径：unix:path:/usr/local/bin/ghostunnel，此文件启动之后，可以使用 Workload API 向 Agent 请求 SVID
socketPath：指定 SPIRE Server 的监听 Socket
spiffeID：Workload 的 SPIFFE ID
parentID：Node 的 SPIFFE ID

创建这个 Entry 之后，SPIRE Server 会据此创建 SVID 下发给 Agent，Agent 只要根据 Selector 判断 Workload 身份，如果符合就可以发放 SVID 了。

接下来启动 Ghostunnel：

$ ghostunnel server \
    --use-workload-api-addr unix:///$(pwd)/socks/server-side-agent.sock \
    --listen=0.0.0.0:9099 \
    --target=localhost:80 \
    --allow-uri=spiffe://spiffe.dom/curl

这里使用了一个参数 --use-workload-api-addr，要求使用 SPIFFE Workload API，对应 Agent Socket 为前面生成的 socks/server-side-agent.sock。--listen 和 --target 分别代表了监听端口和被代理端口（也就是 NGINX）。而 --allow-uri 参数则是一种访问控制手段，此处是允许 spiffe://spiffe.dom/curl 的 SPIFFE ID 访问本服务。除了这种死板的方式之外，Ghostunnel 还能对接 OPA 实现更加复杂的符合生产要求的策略管控能力。

如果此时用浏览器或者 CURL 访问该节点的 9099 端口，就会出现客户端证书不匹配的错误。

获取 CURL 客户端证书并测试连接

类似的，我们给 CURL 创建一个 SVID：

$ spire-server entry create \
    -selector unix:uid:1000 \
    -socketPath socks/spire-server.sock \
    -spiffeID spiffe://spiffe.dom/curl \
    -ttl 600 \
    -parentID spiffe://spiffe.dom/client-node
Entry ID         : 50911ef7-f191-4917-adde-1bf4e6192002
SPIFFE ID        : spiffe://spiffe.dom/curl
Parent ID        : spiffe://spiffe.dom/client-node
Revision         : 0
TTL              : 600
Selector         : unix:uid:1000

因为我们用的是 CURL，并不具备直接访问 Workload API 的能力，所以这里用了比较特别的参数：

Selector 设置为当前用户的 ID，也就是说该用户执行的进程是可以匹配到这个 Entry 从而获取 SVID 的
设置了 10 分钟的 TTL，满足我们后续手动操作的需要

然后用 spire-agent api fetch 的方式获取证书：

$ spire-agent api fetch \
    --socketPath socks/client-side-agent.sock \
    -write certs

命令执行后，会在 certs 发现导出的证书文件，CURL 加上这个证书就能成功访问到 NGINX 了。

$ curl -kv https://127.0.0.1:9099 \
    --cert certs/svid.0.pem --key certs/svid.0.key
*   Trying 127.0.0.1:9099...
* Connected to 127.0.0.1 (127.0.0.1) port 9099 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
...
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
...

然后

如果观察 logs 目录中的日志，会看到在两个 Agent 的目录中会频频出现 Node 和 Workload 的 SVID 轮转的信息。那么如果 Server 挂了呢？这里就会发现，SPIRE Server 是系统中的一个单点，各个 Node 会因为 SVID 无法更新而异常退出，例如：

level=error msg="Agent crashed" error="current SVID has already expired and rotation failed: failed to dial dns:///127.0.0.1:8081: connection error: desc = \"transport: error while dialing: dial tcp 127.0.0.1:8081: connect: connection refused\""

因此需要对 SPIRE Server 进行高可用部署。另外这个手工过程中我们也会看到，手工创建 Entry、传播 Bundle 以及获取证书、参数授权等，是不可能适应快速变更的云服务环境的，因此自动注册机制、策略执行机制以及相应的防篡改机制都是 SPIFFE 体系落地的必要条件。

后续还会根据这些问题进行进一步的尝试。

eBPF、Sidecar 和服务网格的未来

Thu, 06 Oct 2022 16:57:57 +0800

原文：eBPF, sidecars, and the future of the service mesh

作者：William Morgan

eBPF 给云原生世界带来了很多变化。感谢 Cilium 之类的新技术，eBPF 已经成为了 Kubernetes CNI 的一个流行选择。Linkerd 这样的服务网格产品也经常会和 Cilium 或类似的 CNI 产品协同工作，从而同时在 7 层和 ³⁄₄ 层分别得到 Linkderd 和 Cilium 的强大处理能力。但是 eBPF 的网络技术到底多强大？会强大到——例如替换 Linkerd 的 Sidecar Proxy，从而能在内核里完成所有操作吗？

本文中我会尽量进行评估，尤其会重点关注会对用户产生影响的部分。我会讲述 eBPF 是什么，能做什么不能做什么。我还会针对 Sidecar 和其它模型在运维和安全方面的能力进行深入对比。最后我会摆出我的结论——关于我们 Linkerd 团队，对 eBPF 参与下的服务网格的未来。

我是谁

大家好我是 William Morgan，Linkerd 的创建者之一。Linkerd 是第一个服务网格产品，也是服务网格这个词的定义者。我还是 Buoyant 的 CEO，该公司的使命就是在世界范围内推动 Linkerd 的采用。你可能会阅读过我的一些文字，例如 The Service Mesh: What every software engineer needs to know about the world’s most over-hyped technology 或者 A Kubernetes engineer’s guide to mTLS: Mutual authentication for fun and profit。

在 Linkerd 身上我投入了很多精力，这是我的偏爱。我同时也乐于实际参与该产品的实现过程。Linkerd 的最终目标是为用户简化服务网格技术，Linkerd 的实现细节就是为此服务的。例如 Linerd 1.x 时代使用的是主机级别的代理，而出于安全和运维方面的考虑，我们换用了 Sidecar 模型。我注意到，eBPF 可能让我们进一步的简化 Linkerd（尤其是在运维领域）。

什么是 eBPF

在扎到服务网格的细节之前，可以先从 eBPF 开始。这个铺天盖地的新技术到底是什么？

eBPF 是 Linux 内核的一个功能，应用借助 eBPF 可以自助地在内核中执行一些任务。eBPF 大放异彩的重要原因就是，它发迹于网络，但是其能力并不限于网络，eBPF 解放了一大类的网络可观测能力，因为性能影响，在过去这根本不可能实现。

假设要做一个能够处理网络数据包的应用。主机的网络 Buffer 是由内核管理和保护的，例如内核要保障一个进程无法读取 Buffer 中另一个进程的数据包。应用无法直接访问 Buffer，但是有一种被称之为 syscall 的机制，给应用一种调用内核功能的能力：应用调用 syscall，内核检查一下应用是否对目标数据包进行操作的权限，如果有，则完成调用。

Syscall 是可移植的（你的代码甚至可以在非 Linux 的机器上运行），不过比较慢。在现代网络环境之中，一个主机每秒钟都可能要处理海量的数据包，用基于 syscall 的代码来处理每个数据包是不现实的。

Syscall 代码需要在内核空间和用户空间之间进行数据传递，而 eBPF 会把代码直接交给内核执行。没有 syscall，应用能够全速运行——然而下面会提到，没这么简单：）

eBPF 是最近的内核功能之一，和 Linkerd 大量使用的 io_uring 一样，改变了应用程序和内核的互动方式。ScyllaDB 的 Glauber Costa 就此写了一篇 io_uring 和 eBPF 如何改变 Linux 编程，推荐阅读。这些功能的工作方式差别很大：io_uring 使用一种特殊的数据结构，让应用和内核能够安全地共享内存；eBPF 则是让应用能够提交代码到内核。两种方式的目标都是获得超越 syscall 方式的性能。

eBPF 进步巨大，但也并非魔法。并不是任意代码都可以用 eBPF 的方式运行的。实际上出于种种考虑，eBPF 的能力是受到严格限制的。

多租户的难处

eBPF 的局限源自于内核，为什么存在 syscall 这样的东西呢？为什么程序不可以直接访问网络、内存或者磁盘呢？

内核所面对的是一个充满竞争的多租户世界。多租户中的租户可能是人、账号或者其他什么 Actor，多个租户分享同一个主机，各自运行各自的程序。不同租户不应该访问它人的数据，或者说互不干涉。内核既要保障程序的运行，又要维持秩序，换句话说，内核要对租户进行隔离。

这意味着内核不会完全信任任何程序。某个租户的程序，在任何时间点都可能尝试去破坏其它租户的程序或者数据。内核要确保未授权程序，不能停止或者打断其他程序、或者拒绝其资源使用、又或直接访问其它程序的网络、磁盘或者内存等。

这是一个致命需求。几乎所有软件相关的安全保证，最终都依赖于内核的这种能力。不经授权读取其他程序的内存或者网络流量，意味着被渗透或者更糟糕的情况；无授权的情况下写入其它程序的内存或者网络流量则意味着仿冒或者更大的麻烦。允许程序破坏规则的内核漏洞是一个非常严重的问题。要打破这种规则的最好方法就是获取对内核状态的访问——如果能够读写内核的内存，就能绕过这种规则。

隔离失败的后果难以承受，这就是应用和内核之间的交互被严格控制的原因。内核开发者们倾注了巨量精力。

这也是容器的力量之源——它们继承了同样的隔离保障，并将其应用到任意的应用程序和依赖包，得益于现代内核技术，我们能够用相互隔离的方式来运行程序，用完整的内核能力来处理多租户竞争场景。用虚拟机也能达成这种隔离，但是更慢、更昂贵。容器技术给了我们（几乎）一致的保证，并且成本大幅降低。

云原生中各个方面几乎都依赖于这种隔离能力。

eBPF 的局限

回到 eBPF。就像前面讨论的，eBPF 让我们能够提交代码到内核并运行。从内核安全的角度来说，这是个非常恐怖的事情——这会穿越应用和内核之间的界限，直接面对安全威胁。

要提高安全性内核对这种代码提出了相当苛刻的限制。所有 eBPF 代码运行之前，都必须通过 verifier 这一关，它会对代码进行检查，识别其中的不当行为。内核只会运行通过检查的代码。

自动校验程序是个高难度的事情，所以 Verifier 会有宁杀错莫放过的倾向。因此 eBPF 代码受限颇多，例如不能阻塞、不能无限循环、不能超过预定义的尺寸；其复杂度也是受限的——Verifier 会对所有可能的执行路径进行评估，如果不能在某些限制下完成评估、或者不能证明每个循环都有退出条件，程序就无法通过校验。

有很多完美的安全程序无法满足这种限制。如果想要用 eBPF 的方式运行这些程序，就需要用 Verifier 的方式重写程序（或者提交 Patch 给 Verifier…）。如果你是 eBPF 粉丝，还是有好消息的，每次内核发布，Verifier 都会变得更具智能，这些限制也随之逐步放松。另外也有些创新的方法来应对这些限制。

即使如此，eBPF 的受限情况，也导致 eBPF 程序的应用场景非常有限。在 eBPF 程序中，就算是跨数据包缓冲数据也并非易事。更严重的情况，例如处理 HTTP/2 流量所需的全部代码就远远超出了纯 eBPF 的范围，终止 TLS 也是绝不可能。

最好的情况下，eBPF 能够分担其中一小部分工作，过于复杂的逻辑还是需要用户空间的程序来处理的。

eBPF vs 服务网格

eBPF 说完了，再来说说服务网格。

服务网格负责处理现代化的云原生网络的复杂性。例如 Linkerd 的几个重要功能：初始化并终结 TLS；跨越连接重试请求；透明地将连接从 HTTP/1.x 升级成 HTTP/2 从而提高性能；根据工作负载的身份进行访问控制；跨越 Kubernetes 集群发送流量，以及很多其他功能。

Linkerd 和多数服务网格一样，会在每个应用 Pod 间插入代理，这些代理会处理进出 Pod 的流量，从而完成网格能力。这些代理在自己的容器里运行，代理容器和应用容器伴行——这种模型被称为 Sidecar。Linkerd 的代理是基于 Rust 实现的，轻量、快速，但是 Sidecar 并非全部。

十年前，要在集群里部署成百上千个代理服务器，并和每个应用的每个实例配对，绝对是个运维噩梦。但是感谢 Kubernetes，让这种想法得以实现。Linkerd 还让这些代理成为可管理的：Linkerd 的微代理不需要调谐，并且也实现了资源消耗的最小化。

在这个上下文中，eBPF 和服务网格融洽地相处了几年。Kubernetes 的贡献在于提供了一个可编排的、层次清晰的平台；eBPF 和服务网格非常适用于这种模型：CNI 负责 3、4 层流量，服务网格负责 7 层。

服务网格对平台所有者来说非常有帮助。它提供了 mTLS、请求重试、金指标等，这样开发者就无需自行实现这些能力了。但这也要付出大量部署运行代理的成本。

所以回到老问题：我们能做的更好吗？我们能够使用 eBPF 服务网格来代替代理服务器么？

eBPF 服务网格还是需要代理服务器

根据前面对 eBPF 的铺垫，我们可以进行一些更深入的探讨。

不幸的是，触底非常快速：eBPF 的限制意味着，服务网格的完整能力（例如根据 Header 进行 HTTP/2 流量管理，初始化或者终结 mTLS 等）远远超出了纯 eBPF 方法的实现能力。

就算是在限制之内，用 eBPF 来实现也不见得就好。eBPF 编写困难、调试更难；这些网格功能的实现已经很难了，在一个有限的编程模型中实现就是难上加难。

所以不管在技术限制和软件工程实践来说，纯 eBPF 服务网格不可能实现。

但是 eBPF 结合用户空间代码的方式就能更好的应对复杂问题—— eBPF 负责一些专门问题，用户控件的代理服务器负责其他任务。

节点级代理对比 Sidecar

所以 eBPF 服务网格还是需要代理。但是是不是一定要 Sidecar 模型呢？如果我们用节点级代理——是不是能够有一个无 Sidecar、有 eBPF 的服务网格呢？

是的——不过这不是个好主意。我们在 Linkerd 1.x 中已经吃过这个苦头（对不起了，我们的早期用户）。相对于 Sidecar 来说，节点级代理对运维、管理和安全都是很不友好的。

Sidecar 模型中，所有进入应用实例的流量都会通过 Sidecar 代理。这种情况下，Sidecar 成为了应用的一部分：

代理的资源消耗是随应用负载变化的。进入实例的流量增长时，Sidecar 跟应用一样消耗更多的资源。如果应用流量很小，Sidecar 也不需要消耗太多资源（Linkerd 的代理的资源消耗最小仅有 2-3MB）。Kubernetes 的资源管理手段在这种场景下都有作用。
代理的爆炸半径被限制在 Pod 范围内。代理故障和应用故障一样，也可以被 Kubernetes 的 Pod 管理手段进行处理。
代理服务器的维护，例如版本升级同样可以用 Kubernetes 的滚动升级等机制来完成。
安全边界清晰，同样限制在 Pod 范围。Sidecar 跟应用实例共享同样的安全上下文。他们是同一 Pod 的组成部分，IP 共享。它对进出 Pod 的流量进行策略控制和 mTLS 发起和终结，并且只需要用到 Pod 的密钥物料。

在节点模型里，这些优势就不存在了。被 Kubernetes 调度到同一主机上的所有应用实例，流量都由这个节点级代理来处理。代理和应用完全解耦，产生了一些或大或小的问题：

代理服务器的资源消耗弹性巨大：资源水平取决于 Kubernetes 调度到本节点上的 Pod 数量。对特定代理来说，资源的消耗难于预测，也难于分析；这样一旦出了问题，服务网格团队将会因此受到指责。
应用易于受到“嘈杂邻居”的流量影响。节点上所有的流量都从同一个代理服务器经过，一个高流量 Pod 会耗尽代理服务器的所有资源，代理服务器必须确保资源的合理分配，否则应用将面临风险。
代理的爆炸半径变大，并且易变。代理服务器的故障和升级会影响到不同应用的不同实例，这意味着维护任务可能面临着难于预料的后果。
安全问题更加复杂。用 TLS 为例，节点级代理必须包含节点上所有应用的密钥物料，这就成了一种新的攻击目标，代理的 CVE 和漏洞都会造成大量的密钥泄漏。

简而言之，Sidecar 模式保留了容器化所承诺的隔离能力——内核能在容器一级完成安全和多租户隔离的工作。节点级模型破坏了这个边界，重新把多租户问题摆上了台面。

当然，节点级代理是有些优势的。例如 Sidecar 模型里，一次访问要穿过两个代理服务器，而节点级模型则只需要一次，很明显会降低延迟。可以用少量、高配置的代理服务器来应对高负载场景（Linkerd 1.x 就是一个好例子——大规模场景下表现突出，小规模下则不尽如人意）。你的网络架构图上可以少画不少盒子，显得简单很多。

但是这种优势比起安全和运维要面临的问题来说，就有些得不偿失了。为了弥补代理造成的性能损失，必须要把 Sidecar 做的又小又快。

只改进代理就可以了吗

节点级代理遇到的一些问题是伴随着多租户场景发生的。Sidecar 模式下，我们借用内核和容器的呢能力来应对这些问题。节点级代理模式下，没有这种能力可以依赖，那么——我们能不能对代理服务器进行改进，使之能够处理多租户竞争的场景呢。

答案是否定的。其实也不是不可以——理论上是可行的，实际上要投入大量的工作，并且也不是一个通用的能力。推上有个话题 Some of what would have to be done，进行了大量的这方面的讨论。需要完成大量的棘手任务，并且要不断地受到 Sidecar 模型的诱惑，持续地进行评估。

就算是完成了——还是要面对爆炸半径和安全性方面的问题。

服务网格的未来

综上所述——不论有没有 eBPF，在可预见的未来里，服务网格会是构建在用户空间中运行的 Sidecar 代理之上的。

Sidecar 当然不是完美的，但是目前条件下，要同时应对云原生网络的复杂性，以及容器的隔离性，最好的选择就是 Sidecar。eBPF 能卸载网格的一部分工作，它最合适的合作方是 Sidecar 而非节点级代理——让 Sidecar 变快的同时还能保持容器化的可管理性和安全性。eBPF 的目的不会是“用干掉 Sidecar 的方式来降低服务网格的复杂性并提高服务网格的性能”。

eBPF 的能力最终会进化到去掉代理直接处理服务网格的 7 层流量吗？有可能，但是基于上述原因，即使如此，也不可能放弃用户空间的代理服务器。内核会用一些机制来吸收服务网格的能力？可能——但是似乎没人想要一个网格内核，也看不到这种方向的前景。

所以在可预见的未来，Linkerd 会持续把精力投放到 Sidecar Proxy 的可维护、轻量化以及高性能方面，其中一个努力的方向就是在可能的情况下，向 eBPF 卸载部分工作。我们的本分就是为用户的 Linkerd 操作体验负责，从这个起点出发，来对每个设计和工程思维进行权衡。

SPIFFE/SPIRE 从入门到入门

Tue, 27 Sep 2022 21:10:08 +0800

前言

大概很多人和我一样，是从 Istio 那里听说 SPIFFE（读音 Spiffy [ˈspɪfi]）的，Istio 中用 SPIFFE 方式为微服务提供身份。SPIFFE 全称为 Secure Production Identity Framework For Every one，顾名思义，这是一个解决身份问题的框架；而 SPIRE 则是 SPIFFE 的一个实现，全称为 SPIFFE Runtime Environment。

一个“我是谁”的问题，真的需要大动干戈？甚至能养活两个项目：SPIFFE 和 Spire 这对双子星项目，2018 年以 Sandbox 项目身份加入 CNCF，2020 年进入孵化状态，2022 年毕业——是的不但养活了，甚至还毕业了。

官方出了一本小册子，叫做《Solving The Bottom Turtle —— a SPIFFE Way to Establish Trust in Your Infrastructure via Universal Identity》，内容如副标题所说——用 SPIFFE 的方式在基础设施中，利用统一身份构建信任关系。

这里提到的最下面的乌龟，大意是说，身份问题是一个值得深入挖掘的基石技术，相关的传说可以查看一下机壳的文章：《世界巨龟神话原型：如果世界是一只乌龟》。

业务和组织之间的关系，往往就代表着人与应用之间、应用与应用之间的交互。大量的微服务架构应用，用水平伸缩、快速迭代的方式在复杂多变的容器、公有云等基础设施上运行，而安全以及合规的要求则日益提高。这种情况下，访问控制的必要性就逐步凸显出来。访问控制的实现，就是乌龟叠叠乐的效果：

访问控制要解决的问题就是谁能访问什么的问题
这里的“谁”就是认证的问题，对于这个身份，需要进行证明和保护
通常的保护方式是把凭据作为敏感数据进行加密
那么解密所需的密钥也是敏感数据
敏感数据需要安全地进行保存
但是，要访问被保护的敏感数据，还是需要有访问控制
…

要打破死循环，需要一种短生命周期的（易于轮转且不易攻破）、自动化的解决方案。方案中需要有一个可信的根，在这个基础之上来构建软件的身份，而这个身份则成为认证和授权能力的基石。为了防止无穷无尽的下钻过程，工作负载应该能够不借助任何凭据来获得这个身份凭据。

很多厂商在这个方向上做了各种尝试，例如 Google 的 Application Layer Transplort Security（ALTS）、Netflix 的 Marathon 等。

Kubernetes 创始工程师 Joe Beda 在 2016 GlueCon 上发表了题为 Who’s Calling? Production Identity in a Microservices World 的演讲，其中展示了方案的三个要点：

无需凭据，通过内核调用来生成 0 号机密
使用大多数软件都支持的 x.509
解耦网络位置和认证

专家们在 Netflix 进行了 SPIFFE 草案的研讨。很多成员都已经实现并持续改进工作负载认证的方案，他们发现各自的解决方案都有或多或少的相似性，因此具备形成通用方案的可能性。

解决工作负载身份问题的最初目标是建立一个开放的规范和相应的生产实现。该框架需要在不同的实现和现成的软件之间提供互操作性，其核心是在一个不信任的环境中建立信任的根基，驱除隐性信任。最后，摆脱以网络为中心的身份，以实现灵活性和更好的扩展特性。

SPIFF 的基本概念

SPIFFE 由五个部分组成，分别是 SPIFFE ID、Workload API、SVID、SPIFFE Trust Bundle 以及 SPIFFE Federation。

SPIFFE ID

软件名称或身份的表达方式，一般使用信任域、服务标识组成的一个 URL，例如 Istio 中的 spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>

SVID

全称是 Software Verifiable Identify Document，一种加密的可验证的档案，用于证明工作负载的身份。用 CA 签署 SPIFFE 就产生了 SVID，SVID 有两种载体：

X509：用 SAN 字段来保存 SPIFFE ID。是推荐的保存方式。
JWT：这种方式下，在应用层用 bearer token 的方式来证明身份。考虑到适用范围和安全性问题，不建议使用 JWT 承载 SVID

Workload API

一种简单的本地 API，服务可以无需认证直接调用 API 来获得自己的身份、Trust Bundle 以及相关信息。

Trust Bundle

SPIFFE 的公钥组合

SPIFFE 联邦

一种简单的用于共享 SPIFFE Trust Bundle 的机制

SPIFFE/SPIRE 和其它安全技术的关系

SPIFFE/SPIRE 的能力并不新鲜，毕竟每个分布式系统都有认证的需求，Web PKI、Kerberos/Active Directory、OAuth、敏感信息存储以及服务网格等都和这一领域有着交集。

但现存的这些形式对于组织内部的服务认证并不合适。Web PKI 实现要求比较多，并且在典型的内部部署环境下也不够安全；Kerberos 需要一个一直在线的 Ticket 管理服务，并且缺乏证明能力；服务网格、机密管理器和叠加网络解决的都是服务身份问题中的一部分。SPIFFE 和 SPIRE 是目前唯一完整的服务身份方案。

Web Public Key Infrastructure

Web PKI 广泛应用在从浏览器连接到安全网站的场景里。这种技术用 X.509 证书来向用户证明网站的身份。读者自然会想问——直接用这种技术进行服务认证不就行了吗？

传统的 Web PKI 场景下，证书的签发和更新是手工的，难以适应现代的动态伸缩环境。虽然近年来发展出了自动化的签发和刷新流程（Domain Validation/DV），然而 DV 非常依赖于 IP 和域名规划，而且客户端证书也无法使用 DV 的自动化流程。另外，DV 流程里用于响应 Token 请求的服务是独立的，有可能通过 2 层网络进行仿冒。

AD 和 Kerberos

Kerberos 中的核心凭据被称为 ticket，Ticket 是一个客户端访问一个资源的凭据，客户端通过调用 Ticket Granting Service（TGS）来获取 Ticket。每个客户端在访问资源需要新的 Ticket 的时候都需要访问 TGS，因此需要 TGS 一直在线。所有服务都要信任 TGS。服务注册到 TGS 的时候，需要把密钥物料（例如公钥或者对称密钥）托管到 TGS，TGS 用来为服务创建 Ticket。要对物料进行轮转，需要在服务和 TGS 之间进行协调。服务自己必须接受前任物料签发的过期 Ticket。

而在 SPIRE 里，客户端和资源都要访问 SPIRE 服务器一次，获取 SVID，然后在信任域范围内就可以凭借这些 SVID 进行互信了，无需再次调用 SPIRE Server。SPIRE 的设计避免了大量对 SPIRE Server 进行访问的成本。SPIRE 这样的依赖 PKI 的认证机制，密钥物料已经解耦，所以轮转过程也大为简化。

另外 Kerberos 协议的签署过程和主机名紧密相关，多服务共享主机或集群时，这个情况就会非常复杂；SPIRE 则可以轻松地为工作负载和集群支持多个 SVID。同一个 SVID 也能够授予给多个工作负载。

OAuth 和 OpenID

OAuth 是一种用于委托的访问方式，而不一定需要自己完成认证过程。OIDC 的第一目标就是让自然人使用一个第三方网站作为自己的身份，来访问目标网站。这个第三方网站必须实现自己的认证方法，从而以本地的认证关系为用户向其他网站提供证明。

OAuth 是为人机交互设计的，登录过程中需要进行浏览器的交互；2.0 中加入了对非人实体的支持，通常是用 Service Account 的形式实现。工作负载要拿到 OAuth 凭据来访问远程系统，必须向 OAuth 提供密码或者 Token 等来进行认证。工作负载需要自行维护各自的凭据，从而获得粗粒度的授权能力，这一过程要求每个工作负载都注册到 OAuth 供应侧，因此起管理难度和负载会迅速增加。

OIDC 并没有解决身份的基本问题，实际上是依赖于预制的身份的。相对来说，SPIRE 不需要长寿的初始凭据，以 SPIRE 作为 OIDC 的身份供应者能够有效地提高安全性——应用无需自行准备身份凭据，只需要用 SPIFFE ID 按需认证即可。

敏感信息管理

这类工具通常要负责对敏感信息进行控制、审计和保管，起操作方包括了管理员和一些应用。有些工具还会提供加解密等功能。其加密存储功能通常被称为 vault。应用必须进行认证之后才能访问 Vault 中的数据。这种系统面临的最大挑战通常就是自身的访问控制，通常称为零号凭据。使用 SPIFFE 作为认证机制能更好的解决这一问题。

服务网格

所有的主流服务网格产品都提供了服务认证功能。SPIFFE 的身份提供能力正适用于这种场景，Istio 和 Consule 都可以使用 SPIFFE 提供身份解决方案。

Istio 使用 SPIFFE 用于识别节点，但是他的身份模型耦合在 Kubernetes 上，IBM 认为 Istio 的机制是不足的，因此提供了 SPIRE 和 Istio 的集成方案

叠加网络

叠加网络跨越多个平台模拟了一个统一网络。与服务网格不同的是，叠加网络使用 IP 地址和路由表这样的标准网络概念，来连接服务。最新的覆盖网络开始提供认证能力。在服务连接之前仍然无法验明正身。通常情况下，这种机制都依赖于一个预存证书。因此 SPIFFE 也很适合为叠加网络节点提供证书。

SPIRE 简介

综合前面对 SPIFFE 的讲述，可以知道，这东西的核心能力：

工作负载（业务应用）可以通过一种本地的、无需认证的方式获取到一个 SPIFFE ID
SPIFFE ID 可以签署成为 SVID，SVID 用 X.509 或者 JWT 的形式进行表达
不同的工作负载之间，共享 Trust Bundle
利用 Trust Bundle 可以鉴别 SVID 的真伪，从而识别出 SPIFFE ID

利用可信的 SVID 所代表的 SPIFFE ID，就可以进行后续的访问控制了。

SPIRE 是如何解决上述问题的？看看官方网站的架构图：

SPIRE 由服务器和 Agent 两部分组成：

服务器负责签发 SVID 并通过 Agent 传递给工作负载；另外他还要维护一个工作负载身份的注册表
Agent 部署在每个节点上，向工作负载公开 Workload API。

这说起来还是非常抽象，为了实现 SPIFFE 规范，SPIRE 引入了一系列自己的概念。

Attestation

SPIRE 中的 Attestation（证实）过程，就是求证工作负载身份的过程。SPIRE 的证实工作氛围两个步骤：

先验证节点：保障工作负载所在的节点的身份的有效性
再验证工作负载：保证节点上的工作负载是有效的

Node Attestation

节点的证实过程是在 Agent 启动过程中完成的，SPIRE 要求 Agent 在第一次连接到服务器的时候能够验明正身。在节点证实过程中，Agent 和服务器协作对 Agent 所在的节点进行校验。这个过程是通过 SPIRE 中被称为 Node Attestor 的插件完成的，这种插件的基本做法就是对节点以及所在环境进行查询和比对，来验证节点身份的有效性。

节点证实成功之后，Agent 就收到了一个 SPIFFE ID，Agent 会把这个 ID 作为父 ID，发放给运行在这个节点上的工作负载。

几种常见的节点身份的证据：

云平台分发给节点的身份文档（例如 AWS 的 Instance Identity Document）
节点上 HSM 或者 TPM 硬件的私钥
安装 Agent 时候的手工验证过程
多节点系统中提供的身份凭据，例如 Kubernetes 的 SA Token

节点证实过程会返回一组属性（Selector）给服务器，这些属性能够标识出特定的节点，另外还会有 Node Resolver 来获取节点的其他属性，这些属性一起，构成了 SPIFFE ID 的附加属性。

例如 AWS 节点的证实过程：

Agent 上的 AWS Node Attestor 向 AWS 查询节点的身份，发送给 Agent
Agent 把身份的证据发送给服务器，服务器把信息发送给 AWS Node Attestor（的服务侧）
AWS Node Attestor 的服务端独立或者调用 AWS API 对前一个步骤获取到的信息进行验证。Node Attestor 还会为 Agent 创建一个 SPIFFE ID，并把 SPIFFE ID 和 Selecor 传给服务器进程
Server 返回一个 Agent 节点的 SVID

SPIRE 支持多种环境的 Node Attestor，例如：

AWS 的 EC2 实例（EC2 Instance Identity Document）
Azure 虚拟机（Azure Managed Service Identities）
GCE Instance（GCE Instance Identity Token）
Kuhbernetes 节点（Kubernetes Service Account Token）

对于无法直接认证节点的平台，SPIRE 提供了如下措施：

服务器和 Agent 之间可以生成一个预共享密钥作为加入的 Token，Agent 启动时进行验证，使用后立即过期
使用现存 X.509 证书

Workload Attestation

工作负载的证实过程要回答的问题是：这个进程是谁？Agent 和 Server 都参与到了节点证实过程里；而工作负载的证实过程是由 Agent 完成的。

下图展示了工作负载证明的过程：

工作负载调用 Workload API 申请 SVID。在 Unix 系统中，这个 API 表现为一个 Unix Domain Socket
Agent 调用节点的内核来认证调用者的进程 ID。然后回调用工作负载的证实插件，把进程号提供给他们
利用进程 ID 查询工作负载的额外信息，可能会和 Kubelet 等同节点服务进行交互
Attestor 把进程信息返回给 Agent
Agent 把属性和注册信息进行比对，返回合适的 SVID 给工作负载。

工作负载的证实机制目前支持 Unix、Kubernetes 和 Docker。

SVID 的生命周期

这一节内容讲述了 SPIRE 签发工作负载身份的过程。这个过程从 Agent 在节点上启动开始，持续到工作负载收到有效的 X.509 SVID 为止（注意，JWT 和 X.509 的处理方式是不同的）。下面以 AWS EC2 为例。

SPIRE Server 启动
除非用户配置了上游 CA 插件，Server 会生成一个自签名证书；Server 会使用这个证书来给信任域内所有的工作负载签发 SVID
如果这是首次启动，Server 会自动生成 Trust Bundle，这些内容会被存储在 SQL 数据库中
Server 开启注册 API，允许注册工作负载
SPIRE Agent 在运行了工作负载的节点上启动
Agent 执行节点证实工作，向 Server 证明节点的身份。例如在 AWS EC2 实例上，通常会把 AWS Instance Identity Document 提交给服务器
Agent 把身份的证据用 TLS 提交给 Server。TLS 的认证通过 Agent 的 Bootstrap Bundle 来完成
Server 调用 AWS API 对这些证据进行校验
AWS 确认文档的有效性
Server 对节点进行解析，验证 Agent 节点的附加属性，并更新注册数据。例如节点使用的是 Azure Managed Service Identity（MSI）。Resolver 会根据 SPIFFE ID 解析 Tenat ID 以及 Principal ID，并用多种 Azure Service 获取额外信息
Server 给 Agent 签发一个 SVID，证实 Agent 的身份
Agent 用它的 SVID 以及他的 TLS 客户端证书联系 Server，获得它被授权的注册内容
Server 用 Agent 的 SVID 验证 Agent 的身份。Agent 接下来会完成 mTLS 握手，使用 Bootstarap Bundle 完成认证。
Server 从数据库中抓取所有（该 Agent 下的）认证的注册条目，发送给 Agent
Agent 发送工作负载的 CSR 给 Server，Server 会签署和返回 Workload SVID 给客户端，客户端进行缓存
启动过程完成，Agent 开始监听 Workload API 的 Socket
Workload 调用调用 Workload API，申请 SVID
Agent 通过调用 Workload Attestor 来初始化 Workload 的证实过程，证实过程的输入以工作负载的进程 ID 启动
Attestor 使用内核和用户空间的调用，发现工作负载的附加信息
Attestor 把发现的信息返回给 Agent
Agent 通过比对缓存中的注册信息和 Workload 上报的信息，来决定是否把缓存中的 SVID 返回给工作负载。

SPIRE Quick Start

是的完全来自官网

Release 页面没有提供 ARM 架构的发布包，差评，只好自己构建：

$ git clone --single-branch --branch v1.4.0 https://github.com/spiffe/spire.git
$ cd spire
$ go build ./cmd/spire-server 
$ go build ./cmd/spire-agent
...

然后用源码包里面的默认配置启动服务器：

$ bin/spire-server run -config conf/server/server.conf &
...
INFO[0000] Starting TCP server   address="127.0.0.1:8081" subsystem_name=endpoints
INFO[0000] Starting UDS server   address=/tmp/spire-registration.sock subsystem_name=endpoints

做一下健康检查：

$ bin/spire-server healthcheck                                         
Server is healthy.

前面提过用 Bootstrap Token 证实节点身份的方法，这里生成一个 Token：

$ bin/spire-server token generate -spiffeID spiffe://example.org/myagent
Token: ff19d99e-e3f2-446f-86eb-cb37fcbd6574

下面启动一个 Agent，并进行健康检查：

$ bin/spire-agent run -config conf/agent/agent.conf -joinToken <token>
$ bin/spire-agent healthcheck
Agent is healthy.

为了让 SPIRE 能识别工作负载，必须把工作负载用注册项的方式注册到 SPIRE 服务器上。注册过程告知 SPIRE 认证工作负载的方法，以及工作负载的 SPIFFE ID。

下面的命令用当前用户的 UID 创建了一个注册项：

$ bin/spire-server entry create \
    -parentID spiffe://example.org/myagent \
    -spiffeID spiffe://example.org/myservice \
    -selector unix:uid:$(id -u)
Entry ID         : 2c0325c5-e5b4-433a-a675-059cbf19f8aa
SPIFFE ID        : spiffe://example.org/myservice
Parent ID        : spiffe://example.org/myagent
Revision         : 0
TTL              : default
Selector         : unix:uid:501

此时可以在服务侧列出当前的注册条目：

$ bin/spire-server entry show
Found 2 entries
Entry ID         : 521fd101-031a-42bf-8190-696bd315e2d3
SPIFFE ID        : spiffe://example.org/myagent
Parent ID        : spiffe://example.org/spire/agent/join_token/ff19d99e-e3f2-446f-86eb-cb37fcbd6574
Revision         : 0
TTL              : default
Selector         : spiffe_id:spiffe://example.org/spire/agent/join_token/ff19d99e-e3f2-446f-86eb-cb37fcbd6574

Entry ID         : 2c0325c5-e5b4-433a-a675-059cbf19f8aa
SPIFFE ID        : spiffe://example.org/myservice
Parent ID        : spiffe://example.org/myagent
Revision         : 0
TTL              : default
Selector         : unix:uid:501

这个注册条目的 Selector 字段表示用 uid 501 这个条件可以给出 spiffe://example.org/myservice 这个 SPIFFE ID。

这里使用的是 unix Workload Attestor，SPIRE 通过插件的方式支持多种 Node Attestor 和 Workload Attestor，例如 SSH、Kubernetes、AWS、Docker 等等。上面的例子中使用了 unix Attestor 除了这个 uid 之外，还能够支持执行路径、二进制哈希等的 Selector

接下来模仿进程，从 Agent 获取一个 x509-SVID。x509-SVID 可以用于不同工作负载之间的访问控制，下面的命令把 SVID 写入 /tmp：

$ bin/spire-agent api fetch x509 -write /tmp/
Received 1 svid after 253.934417ms

SPIFFE ID:              spiffe://example.org/myservice
SVID Valid After:       2022-10-05 14:45:30 +0000 UTC
SVID Valid Until:       2022-10-05 15:45:40 +0000 UTC
Intermediate #1 Valid After:    2022-10-05 09:01:24 +0000 UTC
Intermediate #1 Valid Until:    2022-10-06 09:01:34 +0000 UTC
CA #1 Valid After:      2018-05-13 19:33:47 +0000 UTC
CA #1 Valid Until:      2023-05-12 19:33:47 +0000 UTC

Writing SVID #0 to file /tmp/svid.0.pem.
Writing key #0 to file /tmp/svid.0.key.
Writing bundle #0 to file /tmp/bundle.0.pem.

看到生成了几个 .pem、.key 文件，查看几个文件的内容，会发现：

bundle.0.pem 中是一个自签发的根证书：

...
X509v3 Basic Constraints: critical
    CA:TRUE
X509v3 Key Usage: critical
    Certificate Sign, CRL Sign
X509v3 Subject Alternative Name:
    URI:spiffe://local
...

svid.0.pem 中包含了两个证书，其中一个是中间 CA，另一个是可用于服务侧和客户侧的身份证书

检查签发关系会发现是 bundle.0.pem 签发了 svid.0.pem 中的中间证书，中间证书签发了身份证书。

根据上面的过程大致可以推断出，Server 启动成功之后，Agent 首先自己通过某种方式获得了自己的“合法身份”（例如例子中使用的 Token）。Server 侧预制了若干策略（例如前面注册的 uid=501），Agent 拿到这些策略之后，根据其“本地”的工作负载情况，符合 Selector 要求的内容，就直接发放 SVID。

小结

零敲碎打的阅读了官网文档以及这篇 PDF 之后，对其中种种的严密思考深感折服，同时也感觉，对于缺乏零信任基础设施的组织来说，SPIFFE/SPIRE 是个不可多得的致敬目标，其中对于 Server、Agent、插件的职责划分和流程保障都非常值得借鉴（抄袭）。

然而仅凭这一个技术和产品要达成安全目标也是不现实的，就拿前面提到的 Node Attestor、Workload Attestor，很明显需要根据企业 IT 实际环境，进行插件的选择甚至开发；各种 Selector 的选用和具体实施过程，策略如何保障权威性和最小权限原则，CI/CD、不可变基础设施、配置漂移等问题，都有可能对 SPIFFE 证实过程的干扰甚至破坏；策略的制定过程似乎也是个充满挑战的过程。还好文档中对于联邦的设计、高可用部署、各种典型的集成方式都有相当细致的介绍，非常值得深入学习。

CIS 软件供应链安全指南

Wed, 17 Aug 2022 09:59:13 +0800

概述

Argon（现在是 Aqua Security 的一部分）曾经联系 CIS（Center for Internete Security），建议为软件供应链安全开发一种 CIS 基线。多年以来，CIS 开发并发布了很多安全配置指南，但是软件供应链安全方面还是一个空白。现代软件开发过程中会涉及大量的平台和技术，软件供应链安全的工作范围应该有多大？如何保证基线能够在多种平台中保持一致？

很明显，要直接定义特定的基线是不现实的，更实际的做法是定义一个通用的指南，然后以此为基础来进一步定义更精准的内容。因此 CIS 软件供应链安全指南诞生了。这篇指南的目的在于引出全球社区的反馈，从而帮助制定未来的更准确、更针对特定平台的指南。

本指南面向下图所示的软件供应链过程，涵盖了从代码到交付的生命周期。

本指南目前包含了一百多条建议，按照以下维度进行组织：

源码：关于正确管理源码的的安全建议

这是软件供应链的第一环节，源码是这一过程的真相之源，因此供应链安全的管理要从源码开始，管理内容包括脆弱性、错误配置以及敏感数据等。
构建管线：对构建组件的管理和安全建议。

构建组件包含了构建管线——获取原始代码文件、运行一组任务，最后输出物料。这部分包含构建管线的环境、管理和运行方面的建议。这是软件供应链的第二个环节，针对这一环节的攻击（例如 Codecov 或 SlolarWinds）越来越频繁。
依赖：构建和发布过程中会引入多种依赖内容，这些内容会变成软件的一部分。本节建议针对依赖内容提出。

依赖可能进入代码，还可能被构建管线使用，因此是软件供应链中的一个主要组成部分。被依赖内容经常是由第三方开发者提供的，可能受到特定攻击（例如 log4j）。
制品：对构建管道产生的制品，以及应用程序在构建过程中使用的制品进行管理的安全建议。

制品是软件的打包版本。可以用软件包仓库（或工件管理器）保存制品。制品的创建、复制、直至被部署到相关的环境中，都需要具备保障能力。
部署：针对应用部署过程、配置和相关文件的安全建议。

软件供应链的最后一环。在这之后，应用将在生产环境中运行，供给客户使用。如何将物料安全地交付给客户，至关重要。

本指南和 CIS 基准的愿景，是支持关键的新兴标准，如软件产品的供应链级别（SLSA）和更新框架（TUF），为基准支持的平台上的配置设置和审计工作奠定基础。

通过制定 CIS 软件供应链指南，CIS 和 Aqua 希望建设一个活跃的社区，来支持开发未来的针对平台的软件供应链基线。呼吁开发这些平台或与这些平台合作的专家（Subject Matter Experts）以 CIS 的协作和共识方式帮助创建这一指南。

迄今为止，来自 Aqua Security、CIS、Microsoft、PayPal、Red Hat、CyberArk、Axonius 等组织的 SME 们已经对本指南进行了评审。CIS 和 Aqua Security 希望开放目前工作成果的方式，吸引有更多的 SME 为这个项目做出贡献，使所有人受益。

要贡献给 CIS 基线项目，请联系 CIS 基线开发团队：benchmarkinfo@cisecurity.org。

预期读者

本指南适用于计划通过 DevOps 管道的自动化手段构建和部署软件更新的开发、部署、评估或保护解决方案的 DevOps 和应用安全管理员、安全专家、审计师、Help Desk 和平台部署人员。

1. 源码

1.1 代码变更

1.1.1 使用版本控制平台来跟踪代码变更

1.1.2 确保能够从变更代码回溯到对应的任务

1.1.3 保证由两个强认证用户对代码变更进行评审和放行

1.1.4 如果代码变更的内容发生了更新，那么之前批准的变更申请应该作废

1.1.5 对于撤销变更评审结果的权限应该严加管控

1.1.6 为敏感代码或配置设置明确的所有者

1.1.7 代码属主的代码发生变更时，必须由属主进行审批

1.1.8 周期性地对不活跃分支进行评审和删除

1.1.9 合并新代码之前，必须通过所有检查

1.1.10 进行代码合并之前，确保 Git 分支是最新的

1.1.11 进行代码合并之前，确保所有开放注解都已经解决

1.1.12 合并之前需要对提交内容进行签署

1.1.13 留存 Linear History（仅能合并 Squash 或 Rebase 内容）

1.1.14 制定分支的管理规则

1.1.15 确保由特定的个人或者团队来完成代码合并过程

1.1.16 拒绝向保护分支强行推送代码

1.1.17 只有推送权限的用户不能删除分支

1.1.18 所有的合并操作都需要进行风险扫描

1.1.19 分支保护规则的变更需要进行审计

1.2 仓库管理

1.2.1 所有公开仓库都应该包含 `SECURITY.md` 文件

1.2.2 只有特定人/角色能够创建仓库

1.2.3 只有特定人/角色能够删除仓库

1.2.4 只有特定人/角色能够删除 Issue

1.2.5 确保跟踪所有代码的副本（分叉）

1.2.6 确保跟踪项目代码的可见性（可访问性）变化

1.2.7 周期性的评审不活跃代码仓并进行归档

1.3 访问代码库

这一节包含了在管理应用代码访问过程中的推荐安全措施。这其中包含了对内部和外部访问、账号管理、授权、认证方式等方面的内容。对于访问的安全限制是阻止攻击的重要手段，因此这一节内容是软件安全的重要组成部分。

本节对管理员账户和普通账户分而治之。因为管理员的权限过大，因此管理员账户只应用于管理工作，而非日常任务。

1.3.1 周期性评审不活跃用户并进行删除

1.3.2 确保只有特定用户才能创建团队

1.3.3 严格限制管理员数量

1.3.4 组织外贡献者需要进行多因素认证

1.3.5 组织成员需要进行多因素认证

1.3.6 组织中的现有用户可以邀请新用户加入，新成员只能使用公司认证的邮箱接收邀请

1.3.7 每个代码仓都需要有两个管理员

1.3.8 为代码仓设置严格的基础（缺省）权限

1.3.9 明确标识认证的组织，防止被仿冒

1.3.10 确保仅向认证的域发送源码管理系统的通知邮件

1.3.11 组织应提供 SSH 认证方法

1.3.12 根据 IP 地址限制 Git 访问

1.3.13 跟踪反常的代码访问行为

1.4.1 安装自动化插件/工具需要由管理员批准

1.4.2 周期性地检查过期插件/工具，并删除

1.4.3 应限制自动化工具/插件的最小权限

1.5 代码风险

本节包含代码安全扫描方面的建议。例如硬编码的敏感信息、常见的导致易受攻击的配置错误或者严格的授权等。因为应用代码有很多组件，因此需要逐一检查。

1.5.1 确保使用扫描器鉴别并阻止代码中出现敏感数据

1.5.2 CI 管线中应该有扫描器

1.5.3 IaC 指令必须通过扫描器的检查

1.5.4 用扫描器扫描漏洞

1.5.5 确保使用扫描器扫描引用的开源包中的漏洞

1.5.6 确保使用扫描器扫描引用的开源包的授权

2. 构建管线

本节针对组织开发的构建管线，提出安全建议。

构建管线是一组基础设施，会读取原始的代码问价，运行一组任务，最终输出制品。制品是软件最近版本的最终输出物，这些输出物会被打包以便于后续的存储、使用和部署。

2.1 构建环境

本节针对构建管线的环境提出安全建议。构建环境包含所有制品构建过程所需的基础设施——编排器、管线执行、构建器所在的环境等。绝大多数构建环境的安全建议是针对自建构建平台的——例如自建的 Circle CI。

2.1.1 每个管线都有单一职责，确保最小化权限

2.1.2 每个管线的基础设施和配置都是不可变的

2.1.3 需要保存构建环境的日志

2.1.4 能够自动创建构建环境

2.1.5 对构建环境进行访问控制

2.1.6 仅有认证用户能够访问构建环境

2.2 构建 Worker/Runner

2.2.1 每种构建 Worker 只有单一用途

2.2.2 构建 Worker 的运行环境和命令应该是从外部推送给 Worker，而不是由 Worker 主动拉取

2.2.3 不同 Worker 的职责应该分离

2.2.4 尽可能缩减 Worker 的网络连接能力

2.2.5 Worker 需要进行加固保障运行时安全

2.2.6 要对 Worker 进行漏洞扫描

2.2.7 Worker 的部署配置应该保存在版本控制系统里

2.2.8 监控 Worker 的资源消耗

2.3 管线指令

管线中使用指令来获取源代码的原始文件，并进行一系列处理最终输出制品。多数时候，这些指令是由第三方开发者编写的，受攻击的几率可能较高，因此需要谨慎对待。

2.3.1 确保所有构建步骤都以代码定义

将管道指令作为代码存储在版本控制系统中，提高了构建步骤的自动化程度，并减少人为错误导致的安全漏洞。此外，这种做法也具备了恢复管道配置版本的能力，在发生恶意事件时，更容易准确的定位受影响的变化。

2.3.2 清晰声明构建步骤的输入和输出内容

2.3.3 确保输出内容写入到独立的、安全的存储仓

2.3.4 管线文件需要进行跟踪和评审

2.3.5 确保构建过程的触发有严格权限控制

2.3.6 使用自动扫描的方式保障管线配置正确性

2.3.7 使用自动扫描的方式避免管线漏洞

2.3.8 使用自动扫描的方式避免管线中出现敏感数据

2.4 管线完整性

确保管线、管线的依赖项以及相关制品都是真实的。管道的完整性能保障管道运行过程中的每一个变化和进程都是有保障的。一个办法就是将每个依赖关系锁定在某个安全版本上。

2.4.1 为所有版本的所有制品进行签名

2.4.2 锁定所有构建过程中的外部依赖

2.4.3 在引入依赖之前要进行验证

2.4.4 构建管线的制品生成应该具有复现能力

2.4.5 管线步骤应该能生成 SBOM（软件物料单）

2.4.6 管线应对生成的 SBOM 进行签名

3. 依赖

3.1 三方包

3.1.1 要对第三方制品和开源库进行校验

3.1.2 所有第三方供应商都应该提供 SBOM

3.1.3 构建过程生成的（历史）元数据应该被签名和校验

3.1.4 确保开源组件的依赖关系也得到监控

3.1.5 定义并优先使用受信任的包管理器及其包仓库

3.1.6 为代码的 SBOM 进行签名（太啰嗦了）

3.1.7 依赖应该锁定到一个特定的、验证过的版本

3.1.8 使用的所有包都发布于至少 60 天以前

3.2 包校验

3.2.1 要在组织范围内实施依赖使用策略

3.2.2 要能够自动扫描已知漏洞

3.2.3 要能够自动扫描许可问题

3.2.4 能够自动扫描包的属主变化

4 制品

制品是软件的打包成果，保存在包仓库中或者制品库中，从产生到拷贝、更新以及部署的整个过程都需要关注安全问题。

4.1 校验

制品被推送到仓库之后，可能发生各种攻击：例如使用同名恶意制品进行覆盖、盗取制品文件等。

4.1.1 所有制品都需要通过构建管线进行签名

4.1.2 分发之前对制品进行加密

4.1.3 只有认证平台才能对制品进行解密

4.2 访问制品

4.2.1 对制品进行认证，并且限制特定平台对特定的制品进行认证

4.2.2 尽可能少地授权用户上传制品

4.2.3 能够上传制品的用户需要使用 MFA 认证

4.2.4 制品库不应该使用本地的用户管理

4.2.5 禁止匿名访问制品库

4.3 包仓库

4.3.1 包仓库要对制品签名进行验证

4.3.2 所有制品的所有版本的签名都需进行验证

4.3.3 包仓库的配置变更需要进行审计

4.3.4 包仓库使用的 Webhook 需要用加密协议进行通信

4.4 可追溯

4.4.1 制品需要通过 SBOM、元数据文件等方式提供源头信息

4.4.2 禁止从外部仓库拉取私有制品

5. 部署

部署是供应链的最后一段，本节提供关于发布、部署和配置等方面的安全建议。

5.1 部署配置

5.1.1 确保部署配置文件和源码进行分离

5.1.2 部署配置的变更必须进行跟踪

5.1.3 用扫描器保障识别和阻止配置文件中出现敏感数据

5.1.4 只有特定用户才能访问部署配置

5.1.5 对 IaC 指令进行扫描，防止指令错误

5.1.6 确保对部署配置进行校验

5.1.7 部署配置应该绑定到特定的可信的版本

5.2 部署环境

5.2.1 用自动化的方式进行部署

5.2.2 可复制的部署环境

5.2.3 对部署环境进行访问限制

5.2.4 禁止使用缺省密码

在 Istio 中合并监控指标

Sat, 06 Aug 2022 21:53:29 +0800

前些天阅读 Istio 文档的时候发现个语焉不详的东西：Metrics Merging，原文如下：

This option is enabled by default but can be disabled by passing –set meshConfig.enablePrometheusMerge=false during installation. When enabled, appropriate prometheus.io annotations will be added to all data plane pods to set up scraping. If these annotations already exist, they will be overwritten. With this option, the Envoy sidecar will merge Istio’s metrics with the application metrics. The merged metrics will be scraped from /stats/prometheus:15020.

大致翻译一下：这是一个缺省开放的功能，可以在安装时用 --set meshConfig.enablePrometheusMerge=false 参数停用这个功能。这个功能启用后，相对应的 prometheus.io 注解就会被加入到所有数据面 Pod 上，以启用 Prometheus 的指标抓取能力。如果这些注解已经存在，那么就会被覆盖。有了这样的功能，Envoy Sidecar 就会把应用指标和 Istio 指标进行合并，Prometheus 可以从 :15020/stats/prometheus 拉取合并后的指标。

看完之后，一头雾水。翻翻代码看到另一番说辞：

applyPrometheusMerge configures prometheus scraping annotations for the “metrics merge” feature. This moves the current prometheus.io annotations into an environment variable and replaces them pointing to the agent.

这段代码实现了指标合并功能。它会把当前的 prometheus.io 注解保存到环境变量之中，并且将原有注解替换为指向 Agent 的内容。

再结合相关代码，大概可以推断其功能大致如下：

网格化微服务在网格化之前使用 prometheus.io 注解标注的抓取方法，会被保存到 Sidecar 的环境变量之中；
合并指标功能，能够将被网格劫持的微服务输出的 Promethues 指标和 Sidecar 自身指标进行合并，输出到 :15020/stats/prometheus 端点，供 Prometheus 拉取。

我们用 Python 的 Prometheus Exporter SDK 中的测试代码做一个示例应用，并使用如下 Dockerfile 进行打包：

FROM python:3.9.13-slim-buster
RUN pip install prometheus-client && mkdir app
COPY server.py /app/server.py
WORKDIR /app
EXPOSE 8000
CMD [ "python3", "server.py" ]

使用 Docker 运行一下，可以看到他输出的简单指标：

$ docker run -p 8000:8000 dustise/promclient:v0.1
Unable to find image 'dustise/promclient:v0.1' locally
v0.1: Pulling from dustise/promclient
...
Status: Downloaded newer image for dustise/promclient:v0.1
$ curl http://127.0.0.1:8000
...
# HELP request_processing_seconds_created Time spent processing request
# TYPE request_processing_seconds_created gauge
request_processing_seconds_created 1.6597804647800276e+09
...

会看到指标中是一些请求相关和 Python 特定的内容，这正像我们一个提供了监控指标的微服务，那么如何将这些“业务”指标和 Sidecar 合并输出呢？根据上文，需要加上 Prometheus 的注解，因此我们准备这样一个 YAML：

apiVersion: apps/v1
kind: Deployment
...
  template:
    metadata:
...
      annotations:
        prometheus.io/path: /
        prometheus.io/port: 8000
        prometheus.io/scrape: true
    spec:
...
---
apiVersion: v1
kind: Service
...

注入 Sidecar 并提交到集群：istioctl kube-inject -f promclient.yaml | kubectl apply -f -。

成功后，可以看看新 Pod 是不是发生了像文档所说的变化：

$ kubectl describe po promclient-6c74596f4f-r5z29 | grep prometheus.io
              prometheus.io/path: /stats/prometheus
              prometheus.io/port: 15020
              prometheus.io/scrape: true

看到我们原有的注解的确被替换为缺省内容，那原有内容是不是出现在环境变量之中？

$ kubectl exec -it [pod] -c istio-proxy -- env |  | grep ANNO
ISTIO_PROMETHEUS_ANNOTATIONS={"scrape":"true","path":"/","port":"8000"}

果然出现在这里了。那么指标是否完成合并了？采集一下 Pod 的 15020 端口：

$ http 10.52.1.11:15020/stats/prometheus | grep python | more
# HELP python_gc_objects_collected_total Objects collected during gc
# TYPE python_gc_objects_collected_total counter
python_gc_objects_collected_total{generation="0"} 101.0
python_gc_objects_collected_total{generation="1"} 273.0
...

可以看到，指标已经被合并到了 Sidecar 指标中之中。

方法固然简单，还是存在一些不适用的场景，例如：

用 mTLS 抓取指标
应用指标和 Sidecar 指标重名
Prometheus 未配置按照标准注解进行抓取

遇到上述问题，可能就需要关掉合并功能，采用自定义抓取的方式了。

Prometheus 和 Pod 标签

Fri, 22 Jul 2022 09:48:06 +0800

原文：Use Prometheus Vector Matching to get Kubernetes Utilization across any Pod Label

作者：Johannes Ziemke

注：这里实际上涉及到两种标签，一个是 Pod 的，一个是 Metrics 的，非常容易混淆，所以会分别写成 Pod 标签和指标标签。

Prometheus 是为 Kubernetes 这样的动态环境而生的。它的服务发现能力和查询语言非常强大，Kubernetes 运维过程中，用户可以借 Prometheus 解决监控问题。

相对其它竞品来说，这种弹性直接提高了 Prometheus 的使用门槛，向量匹配就是众多拦路虎中的一个。

Prometheus 文档中在这个主题上做了非常精彩的阐述，所以本文中不会做过多的细节阐述，而是会围绕资源使用率这个主题进行一些场景化的尝试。

用标签聚合内存用量

Kubernetes 提供了一个 container_memory_usage_bytes 指标，用于表达 Pod 的内存用量：

...
container_memory_usage_bytes{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_fluentd_ds_ready="true",beta_kubernetes_io_instance_type="g1-small",beta_kubernetes_io_os="linux",cloud_google_com_gke_nodepool="small-preemptible",cloud_google_com_gke_preemptible="true",container_name="POD",failure_domain_beta_kubernetes_io_region="us-east1",failure_domain_beta_kubernetes_io_zone="us-east1-c",id="/kubepods/burstable/pod13d4221c-c484-11e7-bff5-42010af0018b/67e5bb069ab9881ff8a55b8628ef4935b0d1ace09c18df20db059522bdfd5b7d",image="gcr.io/google_containers/pause-amd64:3.0",instance="gke-latency-at-small-preemptible-0c981b61-9489",job="kubernetes-cadvisor",kubernetes_io_hostname="gke-latency-at-small-preemptible-0c981b61-9489",name="k8s_POD_latency-api-971504058-jzs5h_default_13d4221c-c484-11e7-bff5-42010af0018b_0",namespace="default",pod_name="latency-api-971504058-jzs5h"}	389120
container_memory_usage_bytes{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_fluentd_ds_ready="true",beta_kubernetes_io_instance_type="g1-small",beta_kubernetes_io_os="linux",cloud_google_com_gke_nodepool="small-preemptible",cloud_google_com_gke_preemptible="true",container_name="POD",failure_domain_beta_kubernetes_io_region="us-east1",failure_domain_beta_kubernetes_io_zone="us-east1-c",id="/kubepods/burstable/pod81d0f651-c500-11e7-bff5-42010af0018b/309e05b118e618122c70ccf88538d13ca41c3b5a770d5d67882426854391c23c",image="gcr.io/google_containers/pause-amd64:3.0",instance="gke-latency-at-small-preemptible-0c981b61-9489",job="kubernetes-cadvisor",kubernetes_io_hostname="gke-latency-at-small-preemptible-0c981b61-9489",name="k8s_POD_latency-api-971504058-gszpw_default_81d0f651-c500-11e7-bff5-42010af0018b_0",namespace="default",pod_name="latency-api-971504058-gszpw"}	372736
container_memory_usage_bytes{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_fluentd_ds_ready="true",beta_kubernetes_io_instance_type="g1-small",beta_kubernetes_io_os="linux",cloud_google_com_gke_nodepool="small-preemptible",cloud_google_com_gke_preemptible="true",container_name="latency-api",failure_domain_beta_kubernetes_io_region="us-east1",failure_domain_beta_kubernetes_io_zone="us-east1-c",id="/kubepods/burstable/pod13d4221c-c484-11e7-bff5-42010af0018b/497e6fdf2217771cb3f52e6fef93734d023f0e7f23f92c58d22139fc18dc5f13",image="registry.gitlab.com/latency.at/latencyat@sha256:8ea057e064b64cc9c8459a68ef3f6d0fc26169b4f57aef193831779e1fe713d4",instance="gke-latency-at-small-preemptible-0c981b61-9489",job="kubernetes-cadvisor",kubernetes_io_hostname="gke-latency-at-small-preemptible-0c981b61-9489",name="k8s_latency-api_latency-api-971504058-jzs5h_default_13d4221c-c484-11e7-bff5-42010af0018b_1",namespace="default",pod_name="latency-api-971504058-jzs5h"}	11014144
container_memory_usage_bytes{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_fluentd_ds_ready="true",beta_kubernetes_io_instance_type="g1-small",beta_kubernetes_io_os="linux",cloud_google_com_gke_nodepool="small-preemptible",cloud_google_com_gke_preemptible="true",container_name="latency-api",failure_domain_beta_kubernetes_io_region="us-east1",failure_domain_beta_kubernetes_io_zone="us-east1-c",id="/kubepods/burstable/pod81d0f651-c500-11e7-bff5-42010af0018b/7b438a8e9df0cf1ab29d067fd36c97099f9f5e7e9257f6187c5be6bff846a62c",image="registry.gitlab.com/latency.at/latencyat@sha256:8ea057e064b64cc9c8459a68ef3f6d0fc26169b4f57aef193831779e1fe713d4",instance="gke-latency-at-small-preemptible-0c981b61-9489",job="kubernetes-cadvisor",kubernetes_io_hostname="gke-latency-at-small-preemptible-0c981b61-9489",name="k8s_latency-api_latency-api-971504058-gszpw_default_81d0f651-c500-11e7-bff5-42010af0018b_0",namespace="default",pod_name="latency-api-971504058-gszpw"}	11448320
...

但是很不幸，这其中并不包含 Pod 标签。还好，kube-state-metrics 提供了一个 kube_pod_labels 指标，这个指标包含一个静态时序，其中表达了 Pod 标签和 Pod 名称的关系：

可以用 (pod_name="latency-api-971504058-jzs5h") 来查询 Pod 的标签：

kube_pod_labels{instance="10.116.0.12:8080",job="kubernetes-service-endpoints",k8s_app="kube-state-metrics",kubernetes_name="kube-state-metrics",kubernetes_namespace="kube-system",label_app="latency-api",label_pod_template_hash="971504058",namespace="default",pod="latency-api-971504058-jzs5h"} 1
kube_pod_labels{instance="10.116.1.26:8080",job="kubernetes-service-endpoints",k8s_app="kube-state-metrics",kubernetes_name="kube-state-metrics",kubernetes_namespace="kube-system",label_app="latency-api",label_pod_template_hash="971504058",namespace="default",pod="latency-api-971504058-jzs5h"} 1

因为有两个 kube-state-metrics 实例在运行，所以出现了两条结果。这两个指标可以用向量匹配的方式进行合并。他们的值是一致的，所以用 min/max 都可以。后面的内容会用 label_app 进行聚合，所以需要保留这个指标标签。另外 pod 标签也是需要保留的，用于进行连接。因为在 kube_pod_labels 中，Pod 的指标标签是 pod，而在 containers_memory_usage_bytes 中则变成了 pod_name。因此需要用一个 label_replace 进行重命名：

max by (pod_name,label_app) (
  label_replace(kube_pod_labels{label_app!=""},"pod_name","$1","pod","(.*)")
)

返回内容大致如下：

{label_app="latency-api",pod_name="latency-api-971504058-n8k6d"}  1
{label_app="latency-api",pod_name="latency-api-971504058-jzs5h"}  1

接下来就可以用向量匹配的方式来把 container_memory_usage_bytes 和前面的表达式进行合并了。这里用到了 *，他把内存用量乘以 kube_pod_labels 里面的匹配值，然而这个值总是 1，所以其实没什么作用。

每个 Pod 会有多个容器，也就是说可能有多个 container_memory_usage_bytes，因此需要用到 group_left。因为要保留 label_app 这一指标标签，所以用它作为 group_left 的参数。

container_memory_usage_bytes * on (pod_name) group_left(label_app)
max by (pod_name,label_app) (
label_replace(kube_pod_labels{label_app!=""},"pod_name","$1","pod","(.*)")
)

用下面的表达式，可以聚合所有 Pod 的内存用量指标：

sum by (label_app,namespace) (
  container_memory_usage_bytes * on (pod_name) group_left(label_app)
  max by (pod_name,label_app) (
    label_replace(kube_pod_labels{label_app!=""},"pod_name","$1","pod","(.*)")
  )
)

用 Pod 标签对 CPU 和 IO 指标进行聚合

既然已经能把 kube_pod_labels 和 cadvisor 连接起来，那么这个能力范围就不仅限于内存了。

CPU

sum by (label_app,namespace) (
  rate(container_cpu_usage_seconds_total[2m]) * on (pod_name) group_left(label_app)
  max by (pod_name,label_app) (
    label_replace(kube_pod_labels{label_app!=""},"pod_name","$1","pod","(.*)")
  )
)

磁盘 IO

我曾经想要展示一些磁盘 IO 统计，很不幸，这个功能又出问题了。

网络

sum by (label_app,namespace) (
  rate(container_network_transmit_bytes_total[2m]) * on (pod_name) group_left(label_app)
  max by (pod_name,label_app) (
    label_replace(kube_pod_labels{label_app!=""},"pod_name","$1","pod","(.*)")
  )
)

Kubernetes 中的用户和工作负载身份

Mon, 04 Jul 2022 21:53:52 +0800

原文：User and workload identities in Kubernetes

作者：Arthur Chiao

本文中我们会试着解释，在 Kubernetes API Server 上如何对用户和工作负载进行认证的问题。

Kubernetes API Server 开放了 HTTP API 接口，让最终用户、集群组件以及外部组件可以进行通信。

绝大多数操作都可以用 kubectl 来完成，而且也可以使用 REST 调用的方式直接访问 API。

但是如何只允许认证用户访问 API 呢？

使用 `curl` 访问 Kubernetes API

让我们从调用 Kubernetes API 开始。

要列出集群中的所有命名空间，可以执行下列命令：

$ export API_SERVER_URL=https://10.5.5.5:6443

$ curl $API_SERVER_URL/api/v1/namespaces
curl: (60) Peer Certificate issuer is not recognized.
# truncated output
If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.

输出内容表明，API Server 的接口用一个未识别的证书（例如自签发）提供了 https 服务，所以 curl 中断了这个请求。

接下来我们用 -k 参数跳过证书验证过程，并观察产生的响应：

# curl -k $API_SERVER_URL/api/v1/namespaces
{
  "kind": "Status",
  "apiVersion": "v1",
  "status": "Failure",
  "message": "namespaces is forbidden: User \"system:anonymous\" cannot list resource \"namespaces\" ...",
  "reason": "Forbidden",
  "details": { "kind": "namespaces" },
  "code": 403
}

现在我们拿到了响应，但是：

对 API 端点的访问被禁止了（返回码 403）
用户身份被识别为 system:anonymous，这个用户无权列出命名空间

上面的操作揭示了 kube-apiserver 的部分工作机制：

首先识别请求用户的身份
然后决策这个用户是否有权完成操作

正式一点的说法分别叫认证（也叫 AuthN）和鉴权（也叫 AuthZ）：

发起 curl 请求时，流量触达 Kubernetes API Server
在 API Server 里，认证模块会首先收到请求。如果认证失败，请求就会被标识为 anonymous
认证之后就进入鉴权环节、匿名访问没有权限，所以鉴权组件拒绝请求，并返回 403

再次检视刚才的 curl 请求：

因为没有提供用户凭据，Kubernetes 认证模块会给请求标记为匿名请求
根据 Kubernetes API Server 配置，可能会收到一个 401 Unauthorized 代码
Kubernetes 鉴权模块会检查 system:anonymous 是否具有列出命名空间的权限，如果没有，就返回 403 Forbidden 错误信息

例如 Kubelet 需要连接到 Kubernetes API 来报告状态：

调用请求可能使用 Token、证书或者外部管理的认证来提供身份。认证模块是整个系统的第一个门槛。

Kubernetes 的认证模块提供的几个重点能力：

同时支持人和非人用户
同时支持内部用户（Kubernetes 负责创建和管理的账号）和外部用户（例如集群外部署的应用）
支持标准的认证策略，例如静态 Token、Bearer Token、X509 认证、OIDC 等
同时支持多种认证策略
可以加入或者移除认证策略
还可以授权匿名用户访问 API

下面我们会走进观察认证模块的工作过程。

本文聚焦于认证领域。要了解更多鉴权内容，可以阅读 Limiting access to Kubernetes resources with RBAC 一文。

Kubernetes API 的内外部用户区别

Kubernetes API 支持两种 API 用户：内部和外部。

这两个东西有什么不同呢？

如果用户是集群的内部用户，我们需要给它定义一个规范（例如数据模型）；而外部用户的规范是已经存在的。所以我们将用户分成下面几类：

Kubernetes 管理的用户：Kubernetes 创建，并由集群内应用使用的用户账号。
非 Kubernetes 管理用户：在 Kubernetes 集群外的用户，例如：
- 集群管理员发放的静态 Token 或证书
- 使用 Keystone、Google Account 以及 LDAP 等进行认证的用户

授权外部用户访问集群

假设有如下场景：使用 Bearer token 访问 Kubernetes。

curl --cacert ${CACERT} \
  --header "Authorization: Bearer <my token>" \
  -X GET ${APISERVER}/api

Kubernetes API Server 是如何将 Token 识别为身份的？

Kubernetes 并不管理外部用户，所以应该有一种机制来从外部资源中获取信息（例如用户名和用户组）。

换句话说，Kubernetes API 接到了带有 Token 的请求后，就应该能够提取信息并进行后续的决策了。

下面用例子来解释一下这个场景。

创建一个 CSV 文件，其中包含了用户、Token 和用户组：

token1,arthur,1,"admin,dev,qa"
token2,daniele,2,dev
token3,errge,3,qa

文件格式为 token, user, uid, groups。

用 --token-auth-file 参数启动一个 minikube 集群：

$ mkdir -p ~/.minikube/files/etc/ca-certificates
$ cd ~/.minikube/files/etc/ca-certificates
$ cat << | tokens.csv
token1,arthur,1,"admin,dev,qa"
token2,daniele,2,dev
token3,errge,3,qa
EOF
$ minikube start \
  --extra-config=apiserver.token-auth-file=/etc/ca-certificates/tokens.csv

为了发送请求给 Kubernetes API，需要集群的 IP 地址以及证书：

kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority: /Users/learnk8s/.minikube/ca.crt
    extensions:
    - extension:
        last-update: Fri, 10 Jun 2022 12:21:45 +08
        provider: minikube.sigs.k8s.io
        version: v1.25.2
      name: cluster_info
    server: https://127.0.0.1:57761
  name: minikube
# truncated output

接下来向集群发送一个请求：

$ export APISERVER=https://127.0.0.1:57761
$ export CACERT=/Users/learnk8s/.minikube/ca.crt
$ curl --cacert ${CACERT} -X GET ${APISERVER}/api
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {},
  "code": 403
}

响应信息表明，我们用匿名身份访问了 API，并且没有任何权限。

接下来用 token1（来自于 tokens.csv 文件中的用户 arthur）发起请求：

$ export APISERVER=https://127.0.0.1:57761
$ export CACERT=/Users/learnk8s/.minikube/ca.crt
$ curl --cacert ${CACERT} --header "Authorization: Bearer token1" -X GET ${APISERVER}/api
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "forbidden: User \"arthur\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {},
  "code": 403
}

如上所见，Kubernetes 能够识别出请求来自于 Arthur。发生了什么呢？tokens.csv 和 --token-auth-file 参数起了什么作用？Kubernetes 有多种认证插件，现在我们使用的是静态 Token 文件。

重放一下刚才的过程：

API Server 启动后，读取 CSV 文件，把用户数据保存在内存里
用 Token 向 API Server 发起请求
API Server 用 Token 找到匹配的用户，并解出剩余的用户信息（例如用户、用户组等）
这些详细信息会被包含在请求中，传递给鉴权模块
当前的鉴权模块（例如 RBAC）找不到 Arthur 的权限，拒绝请求。

创建一个 ClusterRoleBinding 就能快速修复这个问题：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin
subjects:
- kind: User
  name: arthur
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

用下面的命令把对象提交给集群：

$ kubectl apply -f admin-binding.yaml
clusterrolebinding.rbac.authorization.k8s.io/admin created

再次执行命令就会成功了：

curl --cacert ${CACERT} \
  --header "Authorization: Bearer token1" \
  -X GET ${APISERVER}/api
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "192.168.49.2:8443"
    }
  ]
}

上面向 kube-apiserver 发送了一个 HTTP 请求，认证模块会尝试将如下属性附加到请求之中：

Username：字符串，例如 kube-admin、jane@example.com
UID：字符串，相对用户名来说，UID 是一个更稳定的属性
Groups：例如 system:masters、devops-team
附加字段：可能对认证过程有帮助的一些其他字段

请求上下文中加入这些信息之后，后续的 Kubernetes API 组件都能读取这些信息，这些信息对认证插件来说是透明的。

可以使用 Token 向集群发起一个认证请求
Kubernetes 把请求 Token 进行匹配。这是一个外部用户，因此需要依赖一个外部的用户管理系统（这里指的就是那个 CSV 文件）
拿到用户名、ID、用户组等信息之后，这些信息会被传递给鉴权模块进行校验

前面的例子中为用户名创建了一个 ClusterRoleBinding。其实 CSV 中为 Arthur 设置了三个用户组（admin、dev、qa），因此也可以写成：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin
subjects:
- kind: Group
  name: admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

静态 Token 是一种简易的认证机制，集群管理员可以随意生成 Token 并指派给用户。但是这种方式有一定弊端：

必须知道所有的用户
编辑 tokens.csv 文件需要重启 API Server
Token 不会过期

Kubernetes 还提供了其它几种外部认证机制：

X.509 客户端证书
OpenID
认证代理
Webhook

每种方式都有各自的利弊，但是所有的工作流都跟静态 Token 类似：

身份被保存在集群之外
用户使用 Token 向 API Server 发起请求
Kubernetes 向外部认证源（例如 CSV 文件、认证服务、LDAP 等）请求检查 Token 的有效性
如果认证有效，Kubernetes 会拿到用户名和其他元数据
鉴权策略会使用这些数据来判断用户是否具备访问该资源的权限

那么如何选择认证插件呢？实际上可以同时启用多个认证插件，Kubernetes 会逐个调用每个插件，直到成功为止。

如果所有插件都没能成功，则请求会被标记为未认证或者是匿名访问。

认证不只是一个组件，而是由多个组件协同完成的
收到请求之后，插件会顺序执行，如果所有插件都失败了，请求就会被拒绝
如果成功，请求会被传递给鉴权模块

现在已经了解了外部用户的问题，接下来看看 Kubernetes 如何管理内部用户。

用 ServiceAccount 管理 Kubernetes 内部认证

在 Kubernetes 中，内部用户使用 Service Account 的概念来表达。

这些身份通过 kube-apiserver 创建，并分配给应用。

Service Account 会有相关联的 Token，应用向 kube-apiserver 发起请求时，会共享这个 Token 用于认证。

观察一下 Service Account 的定义：

$ kubectl create serviceaccount test
serviceaccount/test created

这个资源的具体内容：

$ kubectl get serviceaccount test -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: test
secrets:
- name: test-token-6tmx7

如果集群版本高于 1.24，输出会有不同：

$ kubectl get serviceaccount test -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: test

差距很明显，只有老版本集群中会有 secrets 字段。

这个 Secret 包含了必要的 Token，API Server 可以用 Token 对请求进行认证：

$ kubectl get secret test-token-6tmx7
apiVersion: v1
kind: Secret
metadata:
  name: test-token-6tmx7
type: kubernetes.io/service-account-token
data:
  ca.crt: LS0tLS1CR…
  namespace: ZGVmYXVs…
  token: ZXlKaGJHY2…

下面的 YAML 代码把这个身份分配给 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  serviceAccount: test
  containers:
  - image: nginx
    name: nginx

提交到集群，创建 Pod 并进入他的 Bash：

$ kubectl apply -f nginx.yaml
pod/nginx created
$ kubectl exec -ti nginx -- bash

发起请求：

$ export APISERVER=https://kubernetes.default.svc
$ export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
$ export CACERT=${SERVICEACCOUNT}/ca.crt
$ export TOKEN="token here"
$ curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "192.168.49.2:8443"
    }
  ]
}

调用成功了。

Kubernetes 1.24 以后的版本不再创建 Secret，那怎么获取 Token 呢？

为 Service Account 生成临时认证

新版本的 Kubernetes 中，Kubelet 负责从 API Server 申请临时 Token。

Token 格式类似 Secret 对象中的 Token，但是有个很大的不同是——他会过期。

这个 Token 不会被注入到 Secret 里面，而是使用 Projected Volume。

在 Kubernetes 1.24 中重复一下刚才的测试。

$ kubectl create serviceaccount test
serviceaccount/test created

创建一个 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  serviceAccount: test
  containers:
  - name: nginx
    image: nginx

把 Pod 提交到集群上：

$ kubectl apply -f nginx.yaml
pod/nginx created

首先确认一下，集群里没有 Secret：

$ kubectl get secrets
No resources found in default namespace.

然后进入 Pod Shell：

$ kubectl exec -ti nginx -- bash

检查一下 Token 的加载情况：

$ export APISERVER=https://kubernetes.default.svc
$ export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
$ export CACERT=${SERVICEACCOUNT}/ca.crt
$  export TOKEN=$(cat ${SERVICEACCOUNT}/token)
$ curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "192.168.49.2:8443"
    }
  ]
}

还是能成功，这个 Token 是怎么加载的？我们来看一下 Pod 的定义：

$ kubectl get pod nginx -o yaml
apiVersion: v1
kind: Pod
  name: nginx
spec:
  containers:
  - image: nginx
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-69mqr
      readOnly: true
  serviceAccount: test
  volumes:
  - name: kube-api-access-69mqr
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace

内容有点多，解析一下。

这里声明了一个 kube-api-access-69mqr 卷
这个卷用只读的方式加载到了 /var/run/secrets/kubernetes.io/serviceaccount。

这个卷用的是 projected 类型。

Projected 卷能把多个卷聚合在一起。但并不是所有类型的卷都能够绑定到 Projected 卷里面，目前仅限于 downwardAPI、configMap 以及 serviceAccountToken。

在这个例子里，Projected 卷的组成成分包括：

serviceAccountToken 卷被加载到 token 路径
configMap 卷
downwardAPI 卷被加载到 namespace 路径

这些卷都是干嘛的？

serviceAccountToken 是一种特别的卷，从当前的 Service Account 中加载 Secret，并填充到 /var/run/secrets/kubernetes.io/serviceaccount/token 文件中。

ConfigMap 卷会把 ConfigMap 中的每个 Key 加载成目录里面的文件。

这个文件的的内容就是对应 Key 的 Value（如果键值对的内容是 replicas:1，就会表达为一个命名为 replicas 的文件，其内容是 1）。

本例中，ConfigMap 卷中加载了调用 API 所必须的 ca.crt 证书。

downwardAPI 卷是一种特殊类型，使用 downwardAPI，将 Pod 信息开放给容器。

在这个例子里，用这种方法将当前命名空间用文件的方式暴露给容器。

可以在 Pod 里验证一下这个能力：

$ export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
$ export NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
$ echo $NAMESPACE
default

知道了 Token 的加载方式之后，那为什么 Kubernetes 要放弃 Secret 改用这种方式呢？

主要原因是：

Secret 中的 Token 永不过期
创建 Service Account 的时候，会异步创建一个带令牌的 Secret

但是如果你只需要 Token，却不需要 Pod 呢？是否可以不加载 Projected Volume 就拿到 Token 数据呢？kubectl 有个新命令：

$ kubectl create token test
eyJhbGciOiJSUzI1NiIsImtpZCI6ImctMHJNO…

这个 Token 是临时的，和 Kubelet 加载到 Pod 里面的 Token 是一样的。

重复执行命令会看到不同的结果，那么这个 Token 只是个长字符串吗？

Projected Servivce Account Token 是个签了名的 JWT Token

可以把这个字符串复制到 jwt.io 网站上，处理之后的输出内容结构如下：

Header 描述了 Token 的签名方式
Payload 就是 Token 中的真实数据
Signature 用于校验 Token 是否被修改

观察一下这个 Token：

{
  "aud": [
    "https://kubernetes.default.svc.cluster.local"
  ],
  "exp": 1655083796,
  "iat": 1655080196,
  "iss": "https://kubernetes.default.svc.cluster.local",
  "kubernetes.io": {
    "namespace": "default",
    "serviceaccount": {
      "name": "test",
      "uid": "6af2abe9-d8d8-4b8a-9bb5-3cc96442b322"
    }
  },
  "nbf": 1655080196,
  "sub": "system:serviceaccount:default:test"
}

上面的字段值得讨论：

sub：主体。本例中的主体是存在于缺省命名空间中的名为 test 的 Service Account。
aud：受众。这个 Token 对当前 Kubernetes 集群生效。
iss：签发者。因为这个 Token 是当前 Kubernetes 签发的，所以取值为当前集群的域名。
kubernetes.io：自定义字段，用于描述 Kubernetes 的细节。

从 Nginx Pod 中读取 Token：

{
  "aud": [
    "https://kubernetes.default.svc.cluster.local"
  ],
  "exp": 1686617744,
  "iat": 1655081744,
  "iss": "https://kubernetes.default.svc.cluster.local",
  "kubernetes.io": {
    "namespace": "default",
    "pod": {
      "name": "nginx",
      "uid": "a11defcb-f510-4d49-9c4f-2e8e8da1c33c"
    },
    "serviceaccount": {
      "name": "test",
      "uid": "6af2abe9-d8d8-4b8a-9bb5-3cc96442b322"
    },
    "warnafter": 1655085351
  },
  "nbf": 1655081744,
  "sub": "system:serviceaccount:default:test"
}

Payload 中包含了 Pod 的名字和 UUID。但是这些信息是谁在消费呢？

不仅能够检查 Token 的完整性和有效性，甚至还可以区分出同一个 Deployment 中的两个 Pod 的区别。

这个功能很有用，原因是：

授权粒度精细到特定 Pod
特定身份被攻破，也只会影响单一单元
从一个 API 调用就能够知道其中包含的命名空间和 Pod

AWS 如何将 IaM 集成到 Kubernetes

设想一个场景，在 AWS 中运行 Kubernetes 集群之中，并希望从集群中上传文件到 S3 的场景。

注意在 Azure 和 GCP 也存在同等能力。

通常来说，需要用一个角色来完成这一任务，但是 AWS 的 IAM 角色只能赋予给计算实例、而非 Pod，换句话说，AWS 对 Pod 并无认知。

2019 年底，AWS 提供了一种原生的 Kubernetes 集成 IAM 的机制，被称为 IAM Roles for Service Accounts (IRSA)，IRSA 在身份和 Projected Service Account Token 之间建立了联系。

创建一个 IAM 策略，其中包含了允许访问的资源
创建一个角色，其中包含了上一步中的策略，记录其 ARN
创建一个 Projected Service Account Token，并用文件的方式进行加载

把 Role ARN 和 Projected Service Account Token 呈现在 Pod 的环境变量之中：

apiVersion: apps/v1
kind: Pod
metadata:
  name: myapp
spec:
  serviceAccountName: my-serviceaccount
  containers:
  - name: myapp
    image: myapp:1.2
    env:
    - name: AWS_ROLE_ARN
      value: arn:aws:iam::111122223333:policy/my-role
    - name: AWS_WEB_IDENTITY_TOKEN_FILE
      value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
    volumeMounts:
    - mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
      name: aws-iam-token
      readOnly: true
  volumes:
  - name: aws-iam-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: sts.amazonaws.com
          expirationSeconds: 86400
          path: token

有了这一配置，就能向 S3 上传文件了。

应用会使用这两个环境变量作为连接到 S3 所需要的 Token，但是如何实现的呢？

是 Kubernetes 而非 AWS 生成了 Token，那么 AWS 如何知道 Token 的有效性呢——是的 AWS 不知道。

AWS SDK 使用角色 ARN 以及 Projected Service Account Token 来交换标准的 AWS 访问凭据。

如果不用 AWS SDK 又怎么办呢？应用程序向 AWS IAM 发起请求，为当前身份（Service Account）换取一个角色。

IAM 收到这个 Token 后，会进行解压并检查 iss 字段，来判断 JWT Token 的合法性。

这个字段通常会被配置为用于创建该 Token 的公钥。

前面说过，这个 URL 指向 Kubernetes 集群：

{
  "aud": [
    "https://kubernetes.default.svc.cluster.local"
  ],
  "exp": 1686617744,
  "iat": 1655081744,
  "iss": "https://kubernetes.default.svc.cluster.local",

注意，需要把这个 URL 改成一个完全限定名（FQDN），否则 AWS IAM 无法触达。可以用 --service-account-issuer 参数来指定

这个 URL 是一个标准的 OIDC Provider，AWS IAM 会查看两个路径：

{Issuer URL}/.well-known/openid-configuration：又被称为 OIDC 发现文档。其中包含了签发者的配置元数据
{Issuer URL}/openid/v1/jwks：其中包含了签名公钥，用于验证 Service Account Token 的真实性

要注意，缺省情况下，这两个端点是不会暴露的，需要集群管理员进行设计。

首先看看 JWKS 端点：

curl {Issuer URL}/openid/v1/jwks
  "keys": [
    {
      "use": "sig",
      "kty": "RSA",
      "kid": "ZO4TUgVjBzMWKVP8mmBwKLvsuyn8z-gfqUp27q9lO4w",
      "alg": "RS256",
      "n": "34a81xuMe…",
      "e": "AQAB"
    }
  ]
}

AWS IAM 会收到公钥，并校验 Token。下面的代码用于校验：

var jwt = require('jsonwebtoken')
var jwkToPem = require('jwk-to-pem')
var pem = jwkToPem(jwk /* "kid" value from the jkws file */)
jwt.verify(token /* this is the token to verify */, pem, { algorithms: ['RS256'] }, function(err, decodedToken) {
  // rest of the code
})

如果 Token 有效，就生成一个具备指定权限的 Access Token：

{
    "Credentials": {
        "AccessKeyId": "ASIAWY4CVPOBS4OIBWNL",
        "SecretAccessKey": "02n52u8Smc76…",
        "SessionToken": "IQoJb3JpZ…",
        "Expiration": "2022-06-13T10:50:25+00:00"
    },
    "SubjectFromWebIdentityToken": "system:serviceaccount:default:test",
    "AssumedRoleUser": {
        "AssumedRoleId": "AROAWY4CVPOBXUSBA5C2B:test",
        "Arn": "arn:aws:sts::[aws account id]:assumed-role/oidc/test"
    },
    "Provider": "arn:aws:iam::[aws account id]:oidc-provider/[bucket name].s3.amazonaws.com",
    "Audience": "test"
}

拿到新凭据后，就可以用来访问 S3 存储桶了。

Projected Serivce Account Token 代表一个集群内有效的身份它可以用来交换到一个其他场景下有效的 Token
AWS IaM 服务收到这个 Token，并读取其 iss 字段的内容，用于验证 Token
如果身份有效，就签发自己的 Token
可以使用新的 Token 访问 AWS 的服务

另外还有一篇文章，完整的描述了手工进行集成的过程。

这种方式可以用于访问外部资源，然而访问内部服务时，是否也需要这样操作呢?

使用 Token Review API 校验 Projected Service Account

可以用 Token Review API 来对集群创建的 Token 进行校验。

首先为 Service Account 创建一个 Token：

$ kubectl create token test
eyJhbG…

创建 YAML 资源，并在其中包含 Token：

kind: TokenReview
apiVersion: authentication.k8s.io/v1
metadata:
  name: test
spec:
  token: eyJhbG… # <- token

提交资源，注意 -o yaml 输出的内容：

$ kubectl apply -o yaml -f token.yaml
apiVersion: authentication.k8s.io/v1
kind: TokenReview
metadata:
  name: test
spec:
  token: eyJhbG…
status:
  audiences:
    - https://kubernetes.default.svc.cluster.local
  authenticated: true
  user:
    groups:
      - system:serviceaccounts
      - system:serviceaccounts:default
      - system:authenticated
    uid: eccac137-25e2-4e84-9d83-18b2f9c5e5af
    username: system:serviceaccount:default:test

Token Review API 的工作内容和 AWS IAM 集成类似：校验身份，并从 Token 中获取细节。当然，单一的 API 调用比 OIDC 流程要简单直接得多。

还可以使用定制 Audience 的方式来限制访问范围。

用 Kubernetes 1.24 或者更高版本生成 Service Account 的 Secret

从 1.24 开始，Kubernetes 不再为 ServiceAccount 自动生成 Secret。然而你还是可以使用传统的方式来创建 Service Account 并用注解的方式来附加给一个 Secret。

例如当前的 Service Account test 中没有 secret 对象。但是可以创建用这种方式创建 Secret （和 token）：

apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: test
  annotations:
    kubernetes.io/service-account.name: "test"

提交给集群之后，进行观察：

$ kubectl describe secret test

Name:         test
Namespace:    default

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1111 bytes
namespace:  7 bytes
token:      eyJhbG…

还可以用 Token Review API 来校验这个 Token：

kind: TokenReview
apiVersion: authentication.k8s.io/v1
metadata:
  name: test
spec:
  token: eyJhbG…

提交对象，并加入 -o yaml 开关：

$ kubectl apply -o yaml -f token.yaml

apiVersion: authentication.k8s.io/v1
kind: TokenReview
metadata:
  name: test
spec:
  token: eyJhbG…
status:
  audiences:
  - https://kubernetes.default.svc.cluster.local
  authenticated: true
  user:
    groups:
    - system:serviceaccounts
    - system:serviceaccounts:default
    - system:authenticated
    uid: eccac137-25e2-4e84-9d83-18b2f9c5e5af
    username: system:serviceaccount:default:test

如果把 Token 内容提交给 jwt.io，会发现 Token 没有过期时间：


{
  "iss": "kubernetes/serviceaccount",
  "kubernetes.io/serviceaccount/namespace": "default",
  "kubernetes.io/serviceaccount/secret.name": "test",
  "kubernetes.io/serviceaccount/service-account.name": "test",
  "kubernetes.io/serviceaccount/service-account.uid": "eccac137-25e2-4e84-9d83-18b2f9c5e5af",
  "sub": "system:serviceaccount:default:test"
}

这种情况和 Kubernetes 的传统行为是一致的。

认证插件的选择

Kubernetes 提供了以下的认证插件：

静态 Token 文件
X.509 证书
Open ID Connect
Authentication proxy
Webhook

如何选择呢？

在前面一节里，我们讨论了静态 Token 文件的限制：

需要知道用户名
修改 CSV 文件需要重启 API Server 才能生效
Token 不会过期

因此静态 Token 文件不是生产环境中的最佳选择。

X.509 客户端证书方案会略微好一些。

使用 X.509 客户端证书认证：

kube-apiserver 使用 --client-ca-file=FILE 参数来指定 CA
管理员为外部用户签发客户端证书。这些 X.509 客户端证书是自包含的，其中包含了用户名和用户组
用户使用这个证书，用 TLS 方式发起对 API Server 的访问
kube-apiserver 用 CA 证书对客户端证书进行认证，如果有效，则解析其中包含的用户名和用户组。

工作流和静态 Token 类似，但还是有些区别：

证书可以设置有效期
创建新的客户端证书，无需修改 API Server 参数
没有 CSV 文件，证书用 CRD 定义的方式来管理

然而，X.509 客户端证书也并不是一个值得推荐的方案。

X.509 客户端证书通常是很长寿（以年计）
CA 基础设施提供了作废证书的途径，但是 Kubernetes 不支持过期证书的检查
客户端证书是自包含的，因此用 RBAC 进行分组非常难
为了对客户进行认证，必须点对点的连接 API Server，不能使用反向代理或者 WAF 防火墙。

（临时）没有其它机制可用的应急场景下，正适合使用 X.509 认证方法。

Kubeadm 和 OpenShift 缺省会设置 API Server 的证书认证能力，这样本地的 Kubectl 就可以使用了。

除了上面的特例之外，可能最好的方式就是 OIDC 认证了。如果已经有了用于管理用户的 OpenID Connect 的基础设施，那就尤其合适了。这种情况下，可以用管理普通用户的方式来管理 Kubernetes 中的用户。

OpenID Connect Provider 能够签发 JSON Web Token（JWT），这意味着 Token 能够自动认证，无需连接到 Token 的签发方，并且会过期。

最后两种认证插件是：

认证代理
Webhook

认证代理插件能够通过外部的认证代理进行透明的认证。

当用户向 Kubernetes 集群发起请求时，请求首先会被认证代理进行处理。这种认证插件可以编写自己的认证逻辑，因此用来实现其它插件不支持的认证方式是很合适的。

最后 Webhook Token 认证插件让用户能够用 HTTP Bearer Token 的方式，对 Kubernetes 请求进行自定义认证逻辑。

Webhook Token 认证插件也同样适用于没有其它机制可用的场景。

总结

本文中阐述了 Kubernetes API Server 认证用户的能力。内容大致包括

外部用户和内部用户的区别
Kubernetes API Server 如何实现不同的用户认证方法，例如静态 Token、Bearer Token、X.509 证书、OIDC 等
Kubernetes 如何使用 Service Account 为内部用户授予身份
使用 Secret 创建的 Token，和 Kubelet 创建的 Token 有什么区别
Projected Volume 把多个卷聚合到一起的方法
如何用 JWT 工具查看 Service Account Token
和 OIDC 联邦，并且和 AWS 之类的云供应商进行集成的方式
如何使用 API Review API 来校验 Service Account Token 的有效性。

认证通过后，就进入鉴权环节了。然后可以阅读 Authentication between microservices using Kubernetes identities 来里了解相关内容。

介绍一个小工具：Inspektor Gadget

Sun, 26 Jun 2022 14:51:18 +0800

各位好，今天 6 月 26 号，吃了么您呐。

例行查看 krew index 的时候，发现有个新插件 gadgit，翻翻来历，居然是 Kinvolk 的作品，公司不太出名，印象里最早做服务网格 Benchmark 的就是他。插件功能介绍很简单：Collection of gadgets for Kubernetes developers，但是用法就很了不得了，非常有字数越小事越大的感觉：

Available Commands:
  advise      Recommend system configurations based on collected information
  audit       Audit a subsystem
  completion  generate the autocompletion script for the specified shell
  deploy      Deploy Inspektor Gadget on the cluster
  help        Help about any command
  profile     Profile different subsystems
  snapshot    Take a snapshot of a subsystem and print it
  top         Gather, sort and periodically report events according to a given criteria
  trace       Trace and print system events
  traceloop   Get strace-like logs of a pod from the past
  undeploy    Undeploy Inspektor Gadget from cluster
  version     Show version

过滤掉辅助功能，可以看到几个主要内容：

advise：根据搜集信息，推荐系统配置内容
audit：对子系统进行审计
profile：对不同子系统进行侧写
snapshot：给子系统进行快照并打印
top：根据制定规则，搜集、排序和周期性地报告事件
trace：跟踪和打印系统事件
traceloop：获取类似 strace 格式的历史日志

其实说了跟没说一样是不是？不如一条条看过去了。

部署

首先使用 krew 安装这个插件：

$ kubectl krew install gadget
Updated the local copy of plugin index.
Installing plugin: gadget
...
 | Use this plugin:
 |      kubectl gadget
...
 |  | $ kubectl gadget deploy | kubectl apply -f -
...
WARNING: You installed plugin "gadget" from the krew-index plugin repository.
...

上文可以看到，使用插件之前要安装到及群里 kubectl gadget deploy | kubectl apply -f -，可以看到，除了 RBAC 内容之外，还有 Daemonset 和 CRD 这两个东西。为了跟踪 Pod 行为，Inspektor Gadget 把 BPF 程序附加到内核函数上，当函数被执行时，内核也会运行这些被注入的程序。因此，BPF 程序需要检测触发该函数的系统调用，是否来自 Inspektor Gadget 的追踪目标。为了做到这一点，程序在包含要追踪的 Pod 列表的 BPF Map 中查找当前的 cgroup id，如果没有找到，程序会提前退出。最后，BPF程序收集要追踪的信息，例如，系统调用参数，并将它们 Ring Buffer 或 BPF Map。Inspektor Gadget 的用户空间工具在 Ring Buffer 或 BPF 地图上监听或读取，并获取新的事件。追踪结束后，BPF 程序将会被删除。

Network Policy Advise

这个功能由 Monitor 和 Report 两个部分构成，分别是启动特定命名空间内工作负载的网络监听，生成跟踪记录；以及根据跟踪记录生成网络策略两部分，例如：

$ kubectl gadget advise network-policy monitor  --output /tmp/result.txt
Node "gke-gcp-vlab-k8s-default-pool-d3fe3442-pw6v" ready.
Node "gke-gcp-vlab-k8s-default-pool-d3fe3442-9hsc" ready.
Node "gke-gcp-vlab-k8s-default-pool-d3fe3442-nj0k" ready.
^C
Stopping...

$ more /tmp/result.txt
{"type":"ready"}
{"type":"ready"}
{"type":"ready"}
{"type":"connect","remote_kind":"pod","port":2021,"local_pod_namespace":"gadget","local_pod_name":"gadget-dzb7g","local_pod_labels":{"controller-revision-hash":"8f55cc94f","k8s-app":"gadget","pod-template-generation":"1"},"remote_pod_namespace":"kube-system","remote_pod_name":"pdcsi-node-lpqln","remote_pod_labels":{"controller-revision-hash":"69cdc7c487","k8s-app":"gcp-compute-persistent-disk-csi-driver","pod-template-generation":"1"},"debug":"4649087588182 cpu#1 connect 3293 otelsvc 10.138.15.229:33032 10.138.15.229:2021 4026531992\n"}
...

执行一段时间后使用 Ctrl+C 终止命令，可以看到指定的输出文件中包含了一堆类似 JSON 的记录内容，可以用这个文件生成网络策略：

$ kubectl gadget advise network-policy report --input=/tmp/result.txt
...
      podSelector:
        matchLabels:
          k8s-app: konnectivity-agent
    ports:
    - port: 10250
      protocol: TCP
  podSelector:
    matchLabels:
      k8s-app: gadget
  policyTypes:
  - Ingress
  - Egress

可以看到，网络策略已经生成。

Seccomp Profile Advise

这一功能是用 advise seccomp-profile 模块完成的，这个模块有三个子命令，分别是 start、list 和 stop，例如要跟踪一个 Calico Pod：

$ kubectl gadget advise seccomp-profile start --podname=calico-node-t6hwg
HAmaTrPcxTLDNfSo
$ kubectl gadget advise seccomp-profile list
NAMESPACE      NODE(S)                                                                                                                         POD                  CONTAINER    TRACEID
kube-system    gke-gcp-vlab-k8s-default-pool-d3fe3442-9hsc,gke-gcp-vlab-k8s-default-pool-d3fe3442-nj0k,gke-gcp-vlab-k8s-default-pool-d3fe3442-pw6v    calico-node-t6hwg                 HAmaTrPcxTLDNfSo

上面 start 命令执行后出现的 HAmaTrPcxTLDNfSo 就是跟踪 ID，开始一段时间之后，可以调用 stop 命令结束跟踪，跟踪结束后会显示这个 Pod 的 Seccomp：

kubectl gadget advise seccomp-profile stop HAmaTrPcxTLDNfSo
{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": [
    "SCMP_ARCH_X86_64",
    "SCMP_ARCH_X86",
    "SCMP_ARCH_X32"
  ],
  "syscalls": [
    {
      "names": [
        "accept4",
        "access",
        "arch_prctl",
...
 ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Profile

这个模块包括 block-io 和 cpu 两个指令，例如监控某个节点的 block-io：

 kubectl gadget profile block-io --node=gke-gcp-vlab-k8s-default-pool-d3fe3442-9hsc
Tracing block device I/O... Hit Ctrl-C to end.^C

     usecs               : count     distribution
         0 -> 1          : 0        |                                        |
         2 -> 3          : 0        |                                        |
         4 -> 7          : 0        |                                        |
         8 -> 15         : 0        |                                        |
        16 -> 31         : 0        |                                        |
        32 -> 63         : 0        |                                        |
        64 -> 127        : 1        |                                        |
       128 -> 255        : 1        |                                        |
       256 -> 511        : 0        |                                        |
       512 -> 1023       : 2        |                                        |
      1024 -> 2047       : 54       |****************                        |
      2048 -> 4095       : 44       |*************                           |
      4096 -> 8191       : 49       |***************                         |
      8192 -> 16383      : 128      |****************************************|
     16384 -> 32767      : 118      |************************************    |
     32768 -> 65535      : 11       |***                                     |
     65536 -> 131071     : 5        |*                                       |

可以看到以微秒为单位的统计记录和分布情况。cpu 子命令的用法如下，其中 -K 开关意思是只关注内核空间的内容：

kubectl gadget profile cpu -p calico-node-t6hwg -K
Capturing stack traces... Hit Ctrl-C to end.^C

calico-node;entry_SYSCALL_64_after_hwframe;do_syscall_64;ksys_write;vfs_write;pipe_write;__wake_up_sync_key;_raw_spin_unlock_irqrestore;_raw_spin_unlock_irqrestore 1
calico-node;entry_SYSCALL_64_after_hwframe;do_syscall_64;ksys_read;vfs_read;pipe_read;anon_pipe_buf_release;anon_pipe_buf_release 1
ip 1
calico-node;entry_SYSCALL_64_after_hwframe;do_syscall_64;__se_sys_nanosleep;get_timespec64;_copy_from_user;copy_user_generic_unrolled;copy_user_generic_unrolled 1
calico-node 9

Snapshot

Snapshot 模块分为 process 和 socket 两个子命令，分别用于记录进程和网络。（v0.5.1 版本的 process 子命令好像无法工作）。

$ kubectl gadget snapshot socket \  
    --node=gke-gcp-vlab-k8s-default-pool-d3fe3442-pw6v \
    -o custom-columns=namespace,pod,protocol,status
NAMESPACE       POD             PROTOCOL STATUS
kube-system     calico-node-zjpl5 TCP      ESTABLISHED
kube-system     calico-node-zjpl5 TCP      ESTABLISHED
kube-system     calico-node-zjpl5 TCP      ESTABLISHED
kube-system     calico-node-zjpl5 TCP      ESTABLISHED
kube-system     calico-node-zjpl5 TCP      ESTABLISHED
kube-system     calico-node-zjpl5 TCP      ESTABLISHED
kube-system     calico-node-zjpl5 TCP      ESTABLISHED

Top

这个模块有三个子命令，block-io、tcp 和 file，跟 Linux 系统的 top 命令类似，例如下面的命令列出的 top file:

$ kubectl gadget top file \
    -o custom-columns=container,pid,comm,reads
CONTAINER        PID     COMM             READS
fluentbit        3737    flb-pipeline     1
fluentbit        3737    flb-pipeline     1
fluentbit        3737    flb-pipeline     2
gke-metrics-agent 56606   otelsvc          2
fluentbit        3737    flb-pipeline     1
fluentbit        3737    flb-pipeline     1
fluentbit        3737    flb-pipeline     2
gke-metrics-agent 56606   otelsvc          2
fluentbit        3737    flb-pipeline     1
fluentbit        3737    flb-pipeline     2

Trace

这个模块针对系统事件进行跟踪，目前支持包括：

bind：Scoket 绑定
capabilities：Capability 检查
dns：DNS 请求
exec：新进程
fsslower：open、read、write 和 fsync 操作时长超过阈值
mount：mount 和 umount 操作
oomkill：OOM Killer 被触发
open：open 系统调用
signal：跟踪进程收到的信号
sni: TLS 请求中的 SNI
tcp：TCP 的 connect、accept 和 close
tcpconnect：connect 调用

例如对 open 的跟踪：

$ kubectl gadget trace open -o custom-columns=container,path

CONTAINER        PATH
fluentbit        /var/log/containers
fluentbit        /var/log/pods
fluentbit        /var/log/containers
fluentbit        /var/log/pods
fluentbit        /var/run/google-fluentbit/pos-files
...
csi-driver-registrar /usr/bin/runc
csi-driver-registrar /sys/kernel/mm/hugepages
...

然后

以后没 eBPF 支持连 Ops 都不好做了？

Crossplane vs Terraform

Wed, 04 May 2022 15:12:39 +0800

原文：Crossplane vs Terraform

作者：Nic Cope

Crossplane 经常被拿来和 HashiCorp 的 Terraform 作比较。企业平台团队往往会在淘汰 Terraform 寻求替代品的过程中发现 Crossplane。这两个项目还是有些相似的：

这两个产品都支持工程师用声明式的配置来对基础设施进行建模
它们都可以用 Provider 的形式支持多种多样的基础设施
这两个产品都是具有强大社区的开源工具

二者的最大区别在于，Crossplane 是一个控制平面，而 Terraform 是一个命令行工具——或者说是一个控制平面的界面。本文会谈到企业在规模化应用 Terraform 的时候遇到的诸多痛点，并阐明 Crossplane 的解决之道。

协作

通常情况下，Terraform 是由运维团队引入企业的。对于较小的工程师团队来说，Terraform 是一个很好的基础设施治理方案。用声明式配置的方法来表达基础设施，运维团队就可以采用软件工程的最佳实践进行工作——用版本控制的方式对配置进行管理，并对变更进行评审，而且还能在必要的时候进行回滚。

在较多工程师协作管理组织的基础设施的情况下，Terraform 就显得有些凌乱了。Terraform 依赖一个单体式的状态文件，以此在基础设施的目标状态和实际状态之间进行映射。在应用配置时，必须锁定状态文件，所以 Terraform 的配置应用过程可能会产生一个数分钟的阻塞。在这个阻塞时间内，配置被独占，其他工程师或者实体都无法进行变更。类似地，Terraform 使用了一个单体式的 apply 进程——并没有什么最佳实践来完成在配置中只修改一部分基础设施的操作。如果缓存和数据库在同一个配置里，就只能同时更新，而无法仅仅更新缓存。

Terraform 推荐把单体式的配置分离为小粒度的配置。运维团队可能从一个 production 配置开始，然后被鼓励分为 production billing、production auth 等小配置。这很难一蹴而就，所以随着时间的推移，需要进行大量的重构，并可能产生网状依赖的 Terraform 配置，其输入和输出也可能产生耦合。

Crossplane 的资源模型被称为 XRM（Crossplane Resource Model），这个模型具备松耦合以及最终一致性的特征，因此提高了规模化协作的能力。在 Crossplane 中，基础设施中的每一块都是一个支持增删改查的 API 端点。Crossplane 的变更不需要依赖关系图，所以用单个数据库也能够管理整个生产环境。

自助服务

现代化组织的基础设施管理模式，正在从中心化向自助化演进。运维团队（也称为平台团队）对基础设施进行抽象，研发团队可以根据需求进行消费。Terraform 通过 Module 这样类似软件库的形式来支持这种进化，Terraform 和 Crossplane 一样，其资源都是外部 API 资源的忠实再现。模块对资源的配置基础上进行了简化的抽象，例如 RDS 模块用八个（现在是九个了） Terraform 资源来表达 RDS 实例的概念。

把应用团队当做 Terraform 配置的消费者意味着他们就是 Terraform 协作的主体。应用开发者被邀请参与组织基础设施的协作，像运维团队一样。平台团队邀请应用开发团队参与他们的工作流，而不仅是给他们提供服务。也就是说，应用团队必须学习新的、特定目标的工具集和语言——Terraform and the HashiCorp Configuration Language（HCL）。对于应用开发者来说，配置的抽象程度提高了，但是访问控制的抽象并没有随之提高。平台团队可以发布一个模块，让应用团队可以管理 RDS 实例，访问控制还是存在于云供应商的 API 级别，围绕着 database subnet groups 和 database parameter groups 进行。

和 Terraform 模块等价的 Crossplane 概念是一个符合对象-XR。每个 XR 都是一个 API 端点。平台团队需要给每个 XR 定义 OpenAPI 结构并输出文档，并在 API 级别实现 RBAC。这样平台团队如果供应给应用开发团队数据库实例，开发团队就有权进行增删改查，而无需关注底层的 RDS 实例和 Subnet 等概念了。Crossplane 构建在 Kubernetes RBAC 基础之上，平台团队能够用轻松地同一个控制平面支持多个应用团队。每个团队都只具备自己需要的权限——有的可能只需要管理存储桶、其他的可能有权使用缓存和数据库。

不仅如此，Crossplane 的 XR 能提供多种服务，Crossplane 用 Kubernetes 对象 spec 和 status 的方式，把 XR 的输入输出和它的实现进行解耦。如果应用程序团队被授权创建 PostgreSQL，他们可以轻松地从平台团队已经兼容的数据库中进行选择。这些服务类别可以表达生产、预发布和开发；AWS、Azure 以及 GCP；快或慢；以及各种条件的组合。

集成和自动化

Terraform 的背后是很多 API，但其自身并没有 API。所以很多团队的自动化方式就是：向版本管理系统（例如 GIT）提交 Terraform 配置的办法融入到 CI/CD 管线之中。这种方式自然要优于从自己的笔记本上运行 Terraform。但这种做法在规模扩张的时候会出现问题。Terraform 是一个命令行工具，而不是一个控制平面，他是短寿的、一次性的进程；所以他只能在调用期间，对基础设施进行面向期待状态的调谐。不管从 CI/CD 还是笔记本上运行，Terraform 一般都是在工程师需要对基础设施进行更新时被执行的。

Terraform 保守的按需执行的方式，可能会导致一个死锁。如前所述，应用 Terraform 配置的过程是全有或者全无的——如果在同一个配置中对缓存和数据库进行描述，那么无论更新哪个对象，都需要同时更新这两个配置。这样一来，如果有人绕开了 Terraform（直接变更基础设施），那么接下来运行 Terraform 计划的人会发现，Terraform 要试图撤销前面的变更。想象一下，一个工程师在半夜被叫醒，处理一个现场问题，他通过 AWS 控制台对生产环境的缓存配置进行了修改，并忘记通知给 Terraform。因此就有一种可能：基础设施的变化越频繁，应用 Terraform 配置的风险就越大。

而在 Crossplane 来说，他构建的是一系列的长期运行的、一直在线的控制循环。他会持续地对基础设施进行观察和矫正，以使环境符合预期。这样就一定程度上阻止了绕过 Crossplane 的企图。当 Crossplane 接管资源之后，所有在 Crossplane 之外修改资源的尝试都会被自动地、持续地修正回预期状态。

不提供 API 是企业应用 Terraform 的一大痛点。和 Terraform 进行集成是一个挑战——他的操作语言是面向特定领域的 HCL 语言，而且使用命令行工具进行调用。Crossplane 开放了 REST API，这无疑是对自动化更加友好。不管是用 Shell 脚本、Python、或者 Erlang，都有途径和 REST API 进行集成——也就是说和 Crossplane 进行集成。

Crossplane 不会暴露旧的 REST API。在 Kubernetes API 的基础上进行构建的 Crossplane API，让团队可以用 kubectl 的方式对所有云或非云的基础设施进行编排，这样就和编排容器化应用的方式保持了一致。Crossplane 还能用 Kubernetes Secret 的方式来表达应用连接基础设施的凭据，简化集成过程。它可以和 ArgoCD、Gatekeeper 或者 Velero 进行协作，来进行 GitOps、策略支持以及备份等工作。构建 Kubernetes Operator，和 Crossplane 集成，有利于建设可靠的自动化过程。

鱼与熊掌

Crossplane 和 Terraform 都能够编排基础设施。二者有一定的相似之处，但具体的编排方式却迥然不同。Terraform 用命令行界面来管理底层控制平面的 API；而 Crossplane 自己就是一个控制平面，能够在其他控制平面上建设抽象的编排能力。因为 Crossplane 让平台团队能够提供自己的控制平面，从而避免了 Terraform 面临的很多问题。

读者可能会注意到，这两个项目是互补的——Terraform 是控制平面的界面，并且它的 Kubernetes Provider 能够对 Kubernetes 控制平面进行管理。这也就产生了 Terraform 和 Crossplane 进行协作的可能性。假设你的组织偏爱 HCL 而非 YAML，那么就可以使用 Terraform 来对 XR 及其组合进行定义，而应用团队则可以使用 Terraform 来对 Crossplane 对象的期待状态进行编排。

我们认为 Crossplane 方案让平台团队为应用开发者赋能，使得开发者能够自助管理基础设施。如果有兴趣开始尝试 Crossplane，或者有问题或者反馈，可以通过 Slack 联系我们。

介绍一个小工具：Security Profiles Operator

Sun, 20 Mar 2022 20:20:50 +0800

在云原生安全方面，Kubernetes 在不同维度提供了很多的不同内容，例如 RBAC、Networkpolicy、SecurityContext 等等，种种措施中，像我这样基础不牢的 YAML 工程师最头大的可能就要数 SecurityContext 里面的 SELinux、Seccomp 和 AppArmor 三大块了。Security Profiles Operator 项目为此而来，希望能够降低在 Kubernetes 集群中使用这些安全技术的难度。在项目网页上转了转，发现他所说的简化，除了定义几个 CRD 封装这样的 Operator 传统技能之外；还有一个使用 CRD 在节点间传输 Security Profile 的能力；最后也是最重要的，提供了很方便的录制功能，这倒是真的戳中了痛点——手写 Profile 固然酷炫，录制生成才是生产力啊。目前支持的功能矩阵如下：

功能	Seccomp	SELinux	AppArmor
Profile CRD	Yes	Yes	Yes
ProfileBinding	Yes	No	No
Deploy profiles into nodes	Yes	Yes	WIP
Remove profiles no longer in use	Yes	Yes	WIP
Profile Auto-generation (logs)	Yes	WIP	No
Profile Auto-generation (ebpf)	Yes	No	No
Audit log enrichment	Yes	WIP	Yes

部署

如果目标环境不是 Openshift，首先需要安装 Cert Manager：

$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.yaml

customresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io created
...

接下来安装 SPO：

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/security-profiles-operator/master/deploy/operator.yaml
customresourcedefinition.apiextensions.k8s.io/profilebindings.security-profiles-operator.x-k8s.io created
customresourcedefinition.apiextensions.k8s.io/profilerecordings.security-profiles-operator.x-k8s.io created
customresourcedefinition.apiextensions.k8s.io/seccompprofiles.security-profiles-operator.x-k8s.io created

查看生成的 CRD，大致功能如下

全名	缩写	命名空间级	功能
AppArmorProfile	aa	true	用于保存 AppArmor Profile
ProfileBinding	N/A	true	把 Profile 绑定到 Pod 上
ProfileRecording	N/A	true	用录制的方式生成 Profile
RawSelinuxProfile	N/A	true
SeccompProfile	sp	true	用于保存 Seccomp Profile
SecurityProfileNodeStatus	spns	true
SecurityProfilesOperatorDaemon	spod	true
SelinuxProfile	N/A	true	用于保存 Selinux Profile

最后创建一个命名空间 spo，并以此作为缺省命名空间，进行后续的试用过程。

借助 SPO 传递 Seccomp

创建一个 Seccomp Profile，其中加入了对系统调用的审计日志：

apiVersion: security-profiles-operator.x-k8s.io/v1beta1
kind: SeccompProfile
metadata:
  namespace: spo
  name: seccomp-profile-sample
spec:
  defaultAction: SCMP_ACT_LOG

Apply 之后 kubectl get sp seccomp-profile-sample -o yaml ，会发现状态如下：

metadata:
...
  finalizers:
  - gke-gcp-vlab-k8s-default-pool-7c61250b-x3h1-delete
  - gke-gcp-vlab-k8s-default-pool-7c61250b-n9l3-delete
  - gke-gcp-vlab-k8s-default-pool-7c61250b-86wz-delete
...
status:
...
  localhostProfile: operator/spo/seccomp-profile-sample.json
  status: Installed

表明 Profile 已经部署到三个节点，状态为 Installed。

这样一来就可以创建一个 Pod，引用这个 Profile：

apiVersion: v1
kind: Pod
metadata:
  name: sleep-pod
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: operator/spo/seccomp-profile-sample.json
  containers:
    - name: sleep
      image: dustise/sleep:v0.9.6
      volumeMounts:
      - name: kubelet
        mountPath: /data/kubelet
  volumes:
  - name: kubelet
    hostPath:
        path: /var/lib/kubelet/seccomp/operator/spo
        type: Directory

Pod 创建之后，进入 Pod Shell，可以看到我们生成的 Profile：

$ kubectl exec -it sleep-pod -- bash
bash-5.0# cd /data/kubelet
bash-5.0# ls
seccomp-profile-sample.json
bash-5.0# cat seccomp-profile-sample.json
{"defaultAction":"SCMP_ACT_LOG"}

接下来执行一下 CURL 点什么，登录节点看看日志

$ sudo journalctl -xe  | grep -i seccomp | grep curl
Mar 21 10:12:44 gke-gcp-vlab-k8s-default-pool-d97cb436-mdgb audit[180209]: SECCOMP auid=4294967295 uid=0 gid=0 ses=4294967295 subj==docker-default (enforce) pi
d=180209 comm="curl" exe="/usr/bin/curl" sig=0 arch=c000003e syscall=231 compat=0 ip=0x7f6d3b8d76f9 code=0x7ffc0000

删掉 Pod。便于进行后续步骤

如果我不想修改 Pod，可以用 ProfileBinding 把 Seccomp Profile 和镜像绑定到一起，如下配置：

apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
kind: ProfileBinding
metadata:
  name: sample-binding
spec:
  profileRef:
    kind: SeccompProfile
    name: seccomp-profile-sample
  image: dustise/sleep:v0.9.6

看看重建一个没有 securityPod 的 Pod 会有什么变化：

apiVersion: v1
kind: Pod
metadata:
  name: sleep-pod
spec:
  containers:
    - name: sleep
      image: dustise/sleep:v0.9.6
      volumeMounts:
      - name: kubelet
        mountPath: /data/kubelet
  volumes:
  - name: kubelet
    hostPath:
        path: /var/lib/kubelet/seccomp/operator/spo
        type: Directory

创建之后，我们看看线上的 YAML：

$ kubectl get po sleep-pod -o yaml
apiVersion: v1
kind: Pod
...
    securityContext:
      seccompProfile:
        localhostProfile: operator/spo/seccomp-profile-sample.json
        type: Localhost

果然这里被修改了。有兴趣还可以查查，这里用到的 Mutating Webhook。

录制 Profile

SPO 支持三种录制模式，分别是 hook、log 或 eBPF。

hook 指的是 OCI hooks，但是目前 containerd 还不支持。

log 则是使用基于日志的录制方式。

eBPF 自然就是最新的基于 eBPF 的录制了。

缺省情况下 spod 没有开启 eBPF 录制功能，需要把开关 spec.enableBpfRecorder 设置为 true：

$ kubectl patch spod spod -n security-profiles-operator  --type=merge -p '{"spec":{"enableBpfRecorder":true}}'
securityprofilesoperatordaemon.security-profiles-operator.x-k8s.io/spod patched

接下来创建一个录制对象：

apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
kind: ProfileRecording
metadata:
  name: sample-recording
spec:
  kind: SeccompProfile
  recorder: bpf
  podSelector:
    matchLabels:
      app: sleep

提交之后，我们给上一个 Pod 加上标签 app=sleep，创建出来，然后随便执行点什么：

$ kubectl apply -f recording.yaml
profilerecording.security-profiles-operator.x-k8s.io/sample-recording created
$ kubectl apply -f plain-pod.yaml
pod/sleep-pod created
$ kubectl exec -it sleep-pod -- curl http://jd.com
...
$ kubectl exec -it sleep-pod -- mkdir 123
...
$ kubectl exec -it sleep-pod -- ping baidu.com
...

删除 Pod，查看 SeccompProfile：

$ kubectl delete -f plain-pod.yaml
pod "sleep-pod" deleted
$ kubectl get sp
NAME                     STATUS      AGE
sample-recording-sleep   Installed   9s

$ kubectl get sp sample-recording-sleep -o yaml

kind: SeccompProfile
metadata:
  creationTimestamp: "2022-03-21T14:07:23Z"
  finalizers:
  - gke-gcp-vlab-k8s-default-pool-d97cb436-5tct-delete
  - gke-gcp-vlab-k8s-default-pool-d97cb436-mdgb-delete
  - gke-gcp-vlab-k8s-default-pool-d97cb436-d8d1-delete
  generation: 1
  labels:
    spo.x-k8s.io/profile-id: SeccompProfile-sample-recording-sleep
...
spec:
  architectures:
  - SCMP_ARCH_X86_64
  defaultAction: SCMP_ACT_ERRNO
  syscalls:
  - action: SCMP_ACT_ALLOW
    names:
    - arch_prctl
    - bind
...

这里看到，删除 Pod 之后，录制过程自动生成了新的 SeccompProfile，其中包含了 Pod 工作过程中使用的配置，并且已经被安装到了各个节点之上。

牢骚

Kubernetes 普及之后，新方向层出不穷，正如杨蒙恩说的——“遍地是大王，短暂又辉煌”，不过安全可能是目前确定性最高的一块内容，决不短暂。所谓安全无小事，没有网格、没有 Serverless 甚至没有多集群、经济性、混布都可以，没有安全可能就全盘皆输了；也不要总想着新瓶装旧酒，挑挑节点、固定一下 IP 就完事了，BMW 装上马鞍之后，丢的不只是风阻和车顶，至少车友群是不太容易混了。

Kubernetes 策略管理

Sat, 29 Jan 2022 14:31:37 +0800

原文：Kubernetes Policy Management Whitepaper

本文试图清晰地阐述 Kubernetes 策略管理的必要性以及在工作负载安全和自动化方面的作用。另外还会讲述 Kubernetes 策略的适用场景以及实现原理。

简介

策略是一组规则，组织能用策略来帮助达成预期目标。策略可以应用在成本、安全以及生产力等各类行为之中。例如一个公司的开支策略定义了财务团队对员工采购进行审计的指导方针。

在信息技术方面，策略是系统配置和行为的规则，可能应用在安全、弹性、韧性以及最佳实践等不同领域之中。策略中定义的系统控制规则可以用声明式的方法来表达这些建议行为。Kubernetes 为代表的云原生系统通常是可扩展的，所以可以将策略管理能力集成到系统配置之中。为系统的执行或者审计行为建立报告就能对策略的遵从情况进行衡量。

在 Kubernetes 中，策略可以理解为应用属主、集群管理员以及安全管理员之间签订的数字契约。Kubernetes 管理员根据安全与合规需求，制定策略并部署到集群之中。策略会针对特定配置或行为做出放行、禁止或者审计的响应。一般来说策略是由运维和信息安全团队协作编写的。管理策略的最佳方式就是用代码表达策略，并且进行可审计的源码管理。

Kubernetes 的原生 API 中就带有策略的内容（例如网络策略），还可以通过动态准入控制器的方式把外部的策略引擎运行在 Kubernetes 控制面之中。本文会同时涉及这两种策略实施方式。

作者

Anca Salier, IBM
Ardhna Chetal, TIAA
Jayashree Ramanathan, Red Hat
Jim Bugwadia, Nirmata
Robert Ficcaglia, Sunstone Secure

鸣谢

作者团队在此感谢下列各位对本文的评审和反馈：

Raj Krishnamurthy, ContiNube
Itay Shakury, Aqua Security
Vishwas Manral, McAfee Enterprise (NanoSec)
Rory McCune, Aqua Security
Andres Vega, VMware
Sayantani Saha, IEM-Kolkata
Jack Kelly
Ash Narkar, Styra
Kapil Bareja, Deloitte
Karim Benzidane, IBM
Maor Kuriel, WhiteSource
Herbert Mühlburger, IT-Ziviltechniker
Maarten Hoogendoorn, Container Solutions
Pushkar Joglekar, VMware
Alok Raj
Dan Papandrea, Sysdig
Abdelrahman Essam
Rahul Jadhav, Accuknox

同时还需要感谢 CNCF 安全 TAG 以及 Kubernetes 安全 SIG 的合作和支持。

目标读者

本文适用于 Kubernetes 管理员、SRE 工程师以及其他希望在安全、韧性以及最佳实践方面符合组织标准以及监管要求的情况下创建集群并运行工作负载的从业者。

首席安全官（CSO）、首席信息安全官（CISO）、首席技术官（CTO）、安全以及合规从业人员，以及使用 Kubernetes 的审计人员也能从本文中受益。其它对 Kubernetes 安全、合规以及治理有兴趣的人也可以参考本文内容。

包括什么

Kubernetes 文档定义了云原生安全的 4C 模型，其中包含了代码、容器、集群和云四个维度：

Kubernetes 中的策略聚焦于中间的两层——容器和集群；而代码和云则不在本文范围之内，另外两层则属于总体安全策略的范畴。也就是说除了确保容器和集群的安全之外：

云和其它基础设施的安全也必须进行加固和管理
运行在容器中的应用代码和第三方依赖也必须确保安全

在 4C 模型中，Code 代表着运行在容器中的应用程序代码。Kubernetes 配置是由一系列对资源理想状态的声明构成的，这些声明通常用一组以 YAML 编写的资源清单构成。管理 Kubernetes 资源清单的最佳实践就是 As Code（例如版本控制、评审以及测试的措施），这些资源清单用于描述容器化应用在 Kubernetes 集群中的运行方式，因此在 4C 模型中被映射为容器层。

不包括什么

根据上面的讨论，不包括在本文中的层次是：

云：容器平台所在的基础设施
代码：应用代码和第三方依赖的安全

策略引擎和工具

本文内容围绕策略管理概念展开，而不会对策略管理工具进行陈述或比较。云原生全景图中的安全与合规类目中包含了工具方面的内容。

策略架构

来自 OASIS（Organization for the Advancement of Structured Information Standards 结构化信息标准促进组织）的 XACML（eXtensible Access Control Markup Language 可扩展访问控制标记语言）标准，定义了策略的语言、架构和过程模型。要定义 Kubernetes 的策略管理架构，XACML 架构是一个合适的起点。

在 XACML 架构中，PAP（Policy Administration Point 策略管理点）会为 PDP（Policy Desision Point 策略决策点）创建策略或者策略组。PEP（Policy Enforcement Point 策略执行点）会对用户请求进行处理，处理过程中会和 PDP 进行通信，得到最终决策。PDP 会从 PIP（Policy Information Point 策略信息点）获取属性值，以此充实策略数据。PDP 接下来就会指示 PEP 如何处理请求——例如放行或者拒绝。

下图展示了 XACML 组件和组件之间的互动。OASIS 的 XACML 3.0 规范中描述了这方面的详细内容。

接下来看看 XACML 架构在 Kubernetes 策略管理中的应用。

PAP

在 Kubernetes 中实施 XACML 架构时，通常会用一个中央管理系统来在多个集群中进行策略的定义和分发，以此实现 PAP 的职责。PAP 能集成版本控制系统或者兼容 OCI 的仓库来存储策略定义。版本控制和预发布测试及验证等软件开发方面的最佳实践都可以应用到策略的定义行为之中，也就是策略即代码（Polic as Code，PAC）。随着策略数量的增长，策略管理员会试着依据服务、领域或者控制焦点等维度对策略进行组织，用多个小的代码段来表达策略，让应用或服务查询特定策略；或者通过构造等设计模式进行策略的动态查找。例如根据控制类型或者特定的合规标准以及安全领域对策略进行分析组织。

PAP 为多个集群提供策略支持，并提供接口进行策略的配置。PAP 根据绑定关系将策略部署到受管理的集群上。一种弹性的实施方法就是用标签标识集群，根据对标签的查询来选择在特定集群上部署特定的策略。

PAP 用于编写、部署策略，并管理策略的变更。然而现实世界中的策略管理系统还会提供合规映射、策略结果管理、自动化工作流、团队协作以及和其它企业系统（例如认证管理、版本控制、告警等）进行集成的能力。除了管理和分发策略之外，PAP 的典型功能有：

用图形化的方式组织多个集群的策略执行结果和违规记录，结合上下文数据，促成不同分工团队（例如开发、SRE 以及 SecOps）的协作；
用策略报告的方式导出多个集群的详细违规记录，和其它 IT 工具进行集成，受管理的多个集群就无需各自完成和这些 IT 工具进行对接了；
为合规工作提供长期的概要报告。特定策略的详细违规记录保存在各种 PEP 之中。PAP 保存策略结果的时长一般是可以配置的，也可以将长期结果卸载到外部存储；
提供安全和合规评估报告以及态势细节；
和 SOC（Security Operations Center 安全运维中心）、事件管理以及 GRC（Governance Risk and Compliance）等企业工具进行对接。和 SOC 以及 GRC 结合可以将 PDP 的结果映射到特定的合规条例（例如 PCI）、法规（例如 HIPAA）或者标准（例如 NIST 800-53）及其控制；
将原生的策略报告格式转译为 NIST 开放安全评估控制语言（OSCAL—Open Security Controls Assessment Language）或者为审计过程提供模板。

PEP

PEP 用于执行策略，确保 Kubernetes 的工作负载和集群本身符合策略要求。还可以帮助对配置进行审计，并且在 API 资源发生违规操作时候进行告警。

Kubernetes 会使用以下方式执行策略：

内置策略对象
用准入控制器来扩展 Kubernetes
策略引擎

这些选项并非互斥关系，全面的安全解决方案会使用多种方式协作完成任务。

Kubernetes 策略对象

Kubernetes 内置了多种策略以及可以作为策略基础的资源对象。这些资源由 Kubernetes 控制器来实现。

Namespaces：Kubernetes 命名空间提供了 API 级别的资源分片，让不同工作负载和团队共享一个集群。即使是一个应用或者团队独占的集群，也应该使用命名空间作为安全边界，以此限制集群级别的访问；
RBAC：Kubernetes 可以定义集群级或命名空间级的角色，其中包含了授权信息，并可以将角色绑定到用户或 Service Account 上；
Pod Security admission：Pod 是 Kubernetes 中的基本执行单元，每个 Pod 都有一个安全上下文，其中定义了 Pod 的特权情况以及其它安全需求。Pod Security Standards 中定义了三个级别的安全策略，Pod 安全准入控制器提供了一个实现，用于在命名空间级别应用策略；
Quota：这个对象为工作负载和命名空间指定了 request 和 limit，确保工作负载不会影响到同一集群中其它工作负载的性能。
网络策略：网络策略控制了工作负载的 Ingress 和 Egress 流量。网络策略是 Kubernetes API 的一部分，其具体实现是来自 CNI 插件的，因此必须安装支持网络策略的 CNI 插件才能使用网络策略。

准入控制器

Kubernetes 中所有的配置变更活动，不论来自于管理员、终端用户、内置控制器、扩展或者外部管理系统，都是用声明式 API 进行的。所有 API 请求都是经由 Kubernetes API 服务器完成的，这样 API Server 就可以作为一个可扩展的执行点来进行工作了：

每个 Kubernetes API 请求在持久化到数据层（通常是 ETCD）之前，都会经过三个检查点：

认证：请求的发出方可能是用户或者应用，认证环节会验证凭据来鉴别用户的身份。Kubernetes 支持多种认证方法。例如基于 OpenID Connect（OIDC）的认证过程会使用中央认证的方式对 Token 进行认证，可以用于用户和 Service Account 的认证过程。策略管理需要确保部署了合适的认证方式，并遵循最佳实践进行配置。
鉴权：调用方经过认证之后，需要由鉴权环节来判别是否允许当前调用对指定资源进行读取或修改。Kubernetes 支持多种鉴权模式。RBAC 模式下，使用 Role 和 RoleBinding 对象控制命名空间中的资源；对于集群级的资源则会使用 ClusterRole 和 ClusterRoleBinding。 Kubernetes 中可以注册 Webhook 形式的鉴权插件。然而要使用这种模式，就需要对 API Server 的配置参数进行修改，托管 Kubernetes 通常不支持这种修改，因此很少使用这种模式。策略管理要求 Kubernetes 使用 RBAC 之类的鉴权模式。
准入控制：调用过程通过了认证和鉴权之后，Kubernetes 会调用准入控制器，对 API 请求的处理过程进行额外的控制。Kubernetes 内置了很多的准入控制器，可以使用 API Server 参数进行启用或者禁用。准入控制器可以对数据进行校验甚至修改。例如内置的 LimitRanger 会对确保特定命名空间中的资源约束和预订配额没有冲突；DefaultIngressClass 会修改新建的 Ingress 控制器，设置一个缺省的 Ingress Class。除了内置的准入控制器之外，Kubernetes 还可以用加密的方式注册以及调用外部控制器的 Webhook（Webhook 是一个软件组件，能够接收和响应 HTTP 请求），对请求数据进行校验和变更。这样外部策略引擎就能够对所有的 Kubernetes 请求进行校验或者修改。策略引擎可以作为一种深度防御机制，弥补常见的故障-放行控制。策略管理应该确保结合各种准入控制器和策略引擎来部署和实时策略。

在处理请求之前，可以用准入控制器实施策略，针对请求进行各种校验和修改，例如：

检查是否使用了可信的镜像仓库
检查镜像签名
把镜像标签转换为不可变的哈希值
执行供应链检查
强制使用 Kubernetes 策略对象，例如 Pod Security Admission、RBAC、命名空间、Limit 和 Quota 以及网络策略
使用合适的 SecComp 和 SELINUX 方案
禁止不安全的配置用法，例如不合理的特权 Pod
（借助 Mutating Webhook）自动消减不安全配置
根据最佳实践进行审计和策略实施，例如设置健康检查和资源配额
生成缺省资源，例如缺省的网络策略

运行时策略实施

对于一些不安全配置或者不当行为，例如访问被保护的文件系统，可以新增一个安全层进行检测。

在一些场景下，例如在现存的重要工作负载上引用新策略时，对于违规问题应该进行报告而不是阻断业务。PEP 应该提供这种细粒度的弹性控制。

容器运行时有两种不同的威胁：

攻击者获得了控制权，可以创建新容器
运行中的容器中产生的威胁

针对第一条威胁，可以使用 Kubernetes 认证、鉴权以及准入控制器来检查所有的 API 请求，这方面的策略在前面的章节已经有所涉及。接下来我们要关注的是第二个场景，要消减这方面的需求，需要对容器运行时参数进行合理的配置，并且要用策略来限制运行时做出非预期的行为。

Kubernetes 运行时策略引擎可以对运行中的容器进行观察，察觉或制止恶意的系统调用或进程，例如可以通过 LSM 直接拒绝危险的系统调用，阻止违规行为。实施最小特权原则可以保障容器只能在合法范围内进行活动，例如禁止或者限制或者审计对 debugfs 的使用，对其它进程的注入、写入可执行内存区、动态载入代码、载入内核模块以及进程钩子。可以定义策略限制或者审计到主机服务、Kubernetes API Server、云基础设施元数据服务（例如 AWS EC2 元数据服务），或者数据渗透、下载二进制文件等行为。

运行时策略能够根据访问 Token 中定义的的上下文和范围，限制 Kubernetes API 对资源的访问，或者对请求速率进行限制，避免队列积压或者控制器发生拒绝服务。例如阻止容器访问不应访问的命名空间内的资源，或者从 CoreDNS 中拉取服务信息，或者尝试通过 DoS 攻击准入控制器来绕过策略引擎。

运行时策略中可以依据 CIS Benchmark for Kubernetes 这样的容器安全标准进行周期性的检查。合规人员可以实现自动化的 CIS 基线检查，进行加固或者简单地进行监控和输出报告。

安全团队可以将策略报告输出到 Kubernetes API 审计流中，从而保持对编排活动的掌控。

在这些机制之外，云原生世界中出现了越来越多的安全左移的案例，例如在 GitOps 流程中可以在 CI 环节甚至开发者的工作站中执行策略，这样开发者就可以尽早得到策略评估的反馈情况。在“开发”一节中，会包含更多这方面的内容。

PDP

策略引擎的角色就是策略决策点（PDP）。策略引擎可以在 Kubernetes 准入控制器中运行，或者也可以用特权工作负载的方式运行在集群里。PDP 可以做出安全、韧性、软件工程等方面的策略决策。

当策略设置为通知或者审计模式的时候，PDP 会根据策略中的要求进行检测，不匹配的截获会报送给 PEP。

策略引擎可以有自己的语言，用于策略的定义和管理。策略语言可以是 DSL，也可以是通用语言，或者声明式配置。不论如何定义，策略都是可以被 Kubernetes 集群进行访问的，最佳实践就是将其表达为 Kubernetes CRD。

Kubernetes 策略工作组编写了一种弹性的可复用的策略结果报告定义。策略报告 CRD 是一种 Kubernetes API 对象，任何的 PDP 都可以用这种资源来报告策略执行结果；而 PAP 可以借此读取、保存以及报告当前以及实时的策略数据。PAP 还可以使用 Policy Report 对象对多个集群违反策略的细节情况进行外化，从而可以集成到外部的运维工具，用于事件管理、安全运维以及治理、风险、合规，以及进一步的映射到法规和标准控制。

补救措施包括根据策略要求进行修复，以符合策略中指定的最佳实践。当策略设置为 enforce 模式时，PEP 会在违反策略的时候进行补救。当策略设置为 inform 模式的时候，PEP 会将违反策略的情况汇报给 PAP，PAP 则会触发补救措施，或者将信息转换为告警发送给事件管理系统或者安全运维中心，从而启动补救措施。

PIP

策略决策过程还需要其他的元数据和配置数据的支持。例如有的规则需要针对命名空间标签进行过滤，这样就需要对命名空间的标签进行查询；另外还可能需要从 API Server 进行查询，获取资源限制以及其它相关属性。

Kubernetes 策略引擎通常需要调用 Kubernetes API 来查询额外信息，以此作为策略决策的驱动数据。有的策略引擎还允许调用外部系统的信息。当然对外部系统的调用需要具备合适的性能以及安全性。

生命周期

前文介绍了 Kubernetes 的策略，并提供了一个引用架构。本节则会讨论 Kubernetes 策略在生命周期中的映射。

CNCF 安全 TAG 出品的云原生安全白皮书定义了如下的生命周期：开发、分发、部署和运行。

Kubernetes 的策略可以应用到每个阶段之中，这里有两个需要聚焦的对象：

镜像：容器镜像通常由 CI/CD 构建而成，并且在容器化工作负载部署之后开始运行。
配置：Kubernetes 资源定义中使用声明式方法描述了容器化工作负载的运行方式。

PaC（策略即代码，Policy as Code）已经v成为云原生世界的共识，策略管理机制借此进入软件分发管线之中。Kubernetes 策略可以以自定义资源或者 ConfigMap 的方式存在，和应用资源清单协同工作。

本节中，我们会讨论 Kubernetes 策略在四个声明周期阶段中的使用方式，以及 Kubernetes 策略的开发、分发以及管理。

开发

在软件开发生命周期的早期引入安全内容，能更轻松地发现和解决问题，降低总体风险，提高安全性。因此云原生实践的重点方法就是采用左移的思路，以便尽可能在产品周期的早期发现安全问题。

针对应用的 Kubernetes 策略应该和应用代码一起进行开发和管理。前面提到的网络策略、RBAC 和其它 Kubernetes 资源都属于这个类型。

开发阶段还包含了 IaC 以及 PaC 物料的创建和校验，如此一来团队就可以通过声明资源，并以版本控制的方式管理这些物料，从而轻松地管理 Kubernetes 资源。

在关键性的软件之中，实现全面的测试和分发策略是非常必要的。策略和代码一样，策略中的 Bug 或者非预期行为也能会导致严重的不易检测的问题。策略语言和引擎应该支持预览，并能模仿用户行为，使用多种输入进行测试。

分发

软件供应链链中包含很多步骤，例如构建、测试、打包和分发，会包含不同工具进行持续构建和持续交付。

Kubernetes 策略可以用于镜像和配置的校验，通过使用准入控制校验数字签名，确保其可信任，并且在分发过程没有遭到篡改。

这一过程的最佳实践，可以把包括软件物料清单（Software Bill of Materials，SBOM）、透明日志以及证明在分发阶段发布到仓库的元数据里，并在工作负载部署进入集群执行之前使用 Kubernetes 策略进行校验。

Kubernetes 准入控制和策略引擎还可以通过应用 Pod 和工作负载策略来满足组织合规要求。不合规的资源清单会被拒绝部署，同时策略引擎还可以用弹性的方式，在遭遇非关键问题时进行报告。

策略报告可以把违规情况和策略结果汇报给集群管理员和工作负载属主。Kubernetes 策略工作组发布了一个可复用的报告格式，可以在任何策略引擎中发布结果。这个报告是一个 Kubernetes 的自定义资源，可以使用 Kubernetes API 进行查询和管理。

另外 Kubernetes 策略引擎的设计目标中包含了策略执行的透明性，这里的透明性用指标来表达，其中包含了规则数量、结果以及策略执行的延迟等。

运行

已部署的镜像中，一旦发现新的脆弱性，应该能被检出。所以 Kubernetes 策略应该是持续更新的，才能在运行中的脆弱镜像中指出违反策略的问题。

类似地，Kubernetes 安全策略和最佳实践也应该是随时进化的，需要周期性的对运行中的应用进行检测，从而发现最新的策略违反情况。

安全映射

策略是运维和其他安全领域之间的桥梁。本节会讨论 Kubernetes 策略映射到其他安全功能的方式。

安全保障

安全保障需要一种整体能力，跨越构建、基础设施和运行时，解决平台和应用设计生命周期中的安全需求。作为安全开发生命周期的一部分，第一步就是为平台和工作负载开发一个威胁模型。

威胁模型

在企业中，可以通过在不同层次中定义控制和策略进行深度防御，从而对威胁进行消解。策略是最佳实践的表达，通过策略实施的治理，就是让控制项进入符合最佳实践的状态。Kubernetes 工作负载以跟用户运行并且还具备主机访问能力，这种案例就可以判别为违反策略要求。在这种情况下，威胁模型是在实际状态和配置基础之上的，

用基于策略的方式来管理 Kubernetes 集群和工作负载，能够简化云原生安全模型中容器和集群的漏洞和威胁的管理工作。工作负载的隔离和分段策略，对于控制漏洞影响、制定防御措施来说非常重要。所有集群和容器的威胁模型，以及容器镜像和工作负载配置的安全影响分析是 Kubernetes 策略管理模型的基础。要进行安全影响分析，就需要了解工作负载、节点和集群的使用模式。可以使用标签或者注解的方式标识这些信息，方便策略的管理。例如 DevOps 工程师可以将管理持卡人数据的工作负载标记为高风险关键资产。

交付管线中的安全保障

IaC 和 PaC 扩大了交付管道的适用范围。在软件声明周期中尽早加入安全内容，是确保云原生应用和服务安全的关键。在 CI 中整合安全工具的方式被称为左移。

错误配置会导致特权逃逸、脆弱镜像、来自非信任仓库的镜像、用 Root 身份运行的容器、内核篡改和数据丢失。

攻击者会开发各种新方法，尝试用恶意软件渗透到软件供应链之中进行攻击，从而避开传统的应用安全控制。有一些关键策略可以用于保护软件供应链。这些策略可以在 CI/CD 中执行，例如可以使用数字签名、代码完整性、镜像软件物料单等来方法来验证软件供应商的身份。还可以在将软件引入企业存储库之前，在沙箱环境中进行扫描。安全 TAG 发布的《软件供应链最佳实践》中包含了更多软件供应链安全方面的内容。

企业使用的软件，不管是自行构建还是来自第三方，安全保障都是必须的。从整体的安全角度保证看来，策略实施和违规检测都是关键行为。

运行时安全保障

对策略的执行情况应该是可观测的，在违反策略的情况下需要进行告警。跟踪执行趋势、记录违规历史也是必要的。这种记录必须具备一定的粒度，避免在可视性方面产生断层。违规行为需要被审查，以改进政策并提高安全态势。

理想状况下，应该能使用自动化的方式补救违规行为。可以用隔离违规容器或者恢复配置的方式进行弥补，防止违规情况引发进一步的攻击。当然只有相当成熟的应用程序团队和平台团队，凭借成熟的流程和应用设计才能达成自动化目标。

Kubernetes 运行时安全策略的一些例子：

监控认证和访问控制日志
容器完整性监控，例如确保没有流氓进程在运行，没有更新主机文件。
观测网络流量、和网络安全
检测提权或新增 Capability
限制以 Root 身份运行容器
定期扫描 CIS 的合规性
检测并报告容器的攻陷情况
进行漏洞检测，确定是否有恶意软件通过交互式访问或通过网络接口注入
容器遥测，为检测和响应提供信息
检测在容器内运行的恶意脚本，如挖矿软件或端口扫描工具

事件响应

事件响应主要是人工过程，因此本节主要讨论 Kubernetes 策略管理对该活动的影响。Kubernetes 事件响应应该和 DevSecOps 流程对齐，强调可声明状态、工作负载瞬态和自动化控制。

Kubernetes 和云原生技术为事件响应计划引入了新的挑战。需要对大量的遥测数据进行有效的识别，在容器的短暂生命周期中克服持久化资源的缺失，检测到其中的攻击行为。要自动地对遥测和审计数据进行采集和处理，自动化工作流从原始遥测数据中提取可操作的事件，应对基础设施的运行状态变化。现有的 SIEM 和 SOAR 平台如果聚焦于人工操作，可能难于应对这样的挑战。

Kubernetes 中正在引入更多的混沌工程实践，用于事件响应计划和模拟，有利于发现新的威胁，设计更好的监控和遥测过程。基于机器学习的遥测分析能够帮助识别反常行为和边缘案例。自愈的重要性日益增长，借助策略及代码技术，训练 ML 模型，让这些工具随着攻击者的发展而适应。Kubernetes 策略报告中可以提供额外的数据，可以在 PAP 中搜集和保存长期数据。

合规

Kubernetes 策略有助于自动化合规。目前已有一系列的监管标准或者行业惯例，例如 PCI、NIST 800-30、NIST 800-53，NIST 800-190、HIPAA 等。策略映射关系在集群和应用负载配置中，建立了合规目标和技术控制的连接。

策略映射让集群管理员和应用属主用代码的形式定义控制的实现方式。例如 NIST 800-53 的控制项 PROTECTION OF INFORMATION AT REST（用户信息和系统信息的机密性和完整性）可以映射到 Kubernetes 控制项：

确定容器磁盘被加密
保障启用 ETCD 加密
用加密方式保存 Secret 对象

可以使用策略语言在 Kubernetes 中编写这些控制。另外为了便于复用，可以为策略定义参数，在保障基本功能和缺省能力的情况下，提供一种可变能力，能够应对不同的风险。

策略映射完成之后，根据客户现状结合相应的参数，就可以进行部署并对 Kubernetes 配置和容器进行校验了。

Kubernetes 集群中的策略不仅对安全运维团队有帮助，对合规部门也是有好处的。集群管理员需要根据合规基线对安全配置和容器以及集群进行校验；合规人员也希望通过他们的监管视角来对集群和容器的监管合规性进行评估和分享。

运营和合规角色之间成功联动的关键是认识到两者之间专业知识和期望值的差异：运营管理员更喜欢不合规资产或资源的报告，而合规官员更喜欢控制实施的缺陷或缺失以及系统和数据的相应风险的报告。

像之前讨论过的一个标准化的评估结果格式，如之前讨论的政策报告CRD，解决了这种观点和目标的两分法。如果使用一种模式，其格式旨在并支持不同资产和系统的标准化，这就可以实现端到端的自动化。OSCAL就是这样一种标准模式，有许多层次（见下文）。

OSCAL 评估结果模型定义了结构化的、机器可读的 JSON 和 YAML，以表示评估报告中包含的信息。任何对系统进行评估或持续监控活动的人都可以使用这个模型，以确定该系统符合一个或多个框架的程度。如果想要提高补救的自动化程度，这一点尤其有帮助。

从本质上讲，合规的集群是使用 Kubernetes 策略管理的。基于策略的方法提高了自动化程度，减少了整体的合规性负担，使企业能够专注于制作他们的应用程序和开发流程。政策和合规状态验证的正式方法仍在制定过程之中，但在云原生社区正在出现。

结论

云原生组织正在采用 Kubernetes 来提高敏捷性，并使其运营和管理实践标准化。然而，安全和自动化仍然是一个挑战。在最近的一项云原生安全调查中，超过 80% 的受访者表示，他们正在寻找带有开源软件的现代安全系统，主要痛点是缺乏专业知识、与现有工具不匹配以及管理的复杂性。

基于策略的 Kubernetes 运营有助于解决这些挑战，它提供了跨开发、运营和安全角色的关注点分离。各方向专家将各种配置控制的推荐做法和指南作为策略，使用云原生最佳实践在集群中部署。

一个全面的 Kubernetes 策略管理战略遵循三个准则。

使用 Kubernetes 策略对象，如 Pod Security、Limit Range、配额，以及其他与安全相关的资源，如命名空间、角色和角色绑定，以及网络策略。
使用准入控制来对 Kubernetes 政策和安全资源的正确使用进行审计和执行，并在整个集群范围和工作负载配置中应用额外的策略，以实现安全和自动化。作为一个最佳实践，同样的政策集也作为持续交付管道的一部分被应用，以向熟悉系统的工作负载所有者报告违规情况。
使用运行时检测和执行工具来发现、报告和阻止不安全的运行时行为，这些行为没有被配置策略阻止、或者由于配置错误而被绕过。定期的配置扫描对于管理现有工作负载的策略变化也是必要的。

来自各执行点的政策报告和违规行为被传送到政策管理点（PAP），然后与事件响应系统和 SOC 整合，以便快速解决问题。

CNCF 云原生互动全景图中安全与合规类别提供了相关项目和工具的清单。

云原生组织可以利用 Kubernetes 策略来定义操作控制和其他安全领域之间的映射，目的是实现治理和合规流程的自动化。通过采用基于策略的操作，企业可以实现他们的目标，即在不影响开发人员的灵活性和自助服务的情况下更加安全和合规。

Kyverno 和 Gatekeeper 的简单对比

Tue, 04 Jan 2022 14:03:44 +0800

引言

在生产环境中应用 Kubernetes 时，出于安全、合规等管控目的，经常需要对工作负载进行审计、校验以及变更，例如下列场景：

为了便于在监控和日志中识别特定应用，我们希望业务应用的 Pod 具备合适的标签结构，标识本 Pod 的业务角色。
根据职责分离的设计原则，只允许 admin 用户在形如 xxx-system 的命名空间创建工作负载。
为了防范供应链攻击，限制仅有来自特定仓库的容器镜像才能运行，并且镜像拉取策略必须设置为 Always。
恶意用户或者应用可以通过加载主机目录窃取消息或者实施破坏，因此应该限制这种加载行为。
…

Kubernetes 提供的 Validating 和 Mutation Webhook 能够完成这些任务，如图所示：

策略引擎们更进一步，使用 DSL 来编写 Webhook 的逻辑，目前使用最为广泛的策略引擎大概是 Kyverno 和 Gatekeeper 两个产品了，因为都是面向 Kubernetes 工作的，通过 CRD 和 Webhook 技术达成目的，因此两个产品的功能和思路颇有一些相似之处，本文将对这两个产品进行一个对比，便于读者们根据实际需求进行采用。

实际上在本文之前，就已经翻译过一篇两个产品的对比，因为版本更迭，其中部分结果已经发生变化。

项目简介

Kyverno 从 2019 年 5 月 24 日在 Github 发布第一个 Release 之后，于 2020 年 11 月 19 日进入 CNCF 版图成为沙箱项目。一年半的时间里，发布了 98 个 Release，收获 1.7k Star，先后有 88 个贡献者参与了该项目的建设之中。目前其策略库中包含了 100 条策略，Kyverno 官方的架构图如下：

从上图可以看到，Kyverno 的 Webhook 组件通过 Mutating 和 Validating 两个接口和 Kubernetes 进行交互，用于处理 Kubernetes API Server 的 AdmissionReview 请求。Policy 控制器负责检视集群中的策略对象；而 GenerateControl 实现了 Kyverno 的一个亮点功能，根据策略针对部分事件生成特定资源。

Gatekeeper 的情况比较复杂，它是在 OPA 项目基础上的一个实现，所以我们经常会看到 OPA/GateKeeper 这样的说法。OPA 的全称是 Open Policy Agent 是一个开源的通用策略引擎，在 2018 年进入 CNCF 沙箱，2021 年 1 月毕业。目前 OPA 的版本为 v0.36.0，它的架构图如下：

这里不难看出，OPA 的工作流程是也是很贴近 Kubernetes 的 AdmissionReview 流程的。Gatekeeper 在 OPA 的基础之上，根据 Kubernetes 生态的习惯做法，定制了多种 CRD，并融入到 Admission Controller 的体系之中。Gatekeeper V3 的架构体现了这一思路：

上图中 Gatekeeper 将 OPA 封装起来，通过 CRD 和 Admission Controller 的交互，实现了策略的自动化管理。Gatekeeper 的策略库中也包含了几十条实用策略。

相似的架构和工作原理，决定了两者的功能也是有颇多的相似之处的，下面将从作用范围选择、策略编写、审计和可见、独特功能几个方向分别对两者进行介绍。

作用范围

Kyverno 提供了 match 和 exclude 两个关键字，用于指定策略的作用范围。两者结合能够相对精确地对 API Server 的请求进行过滤，确定是否启用策略。Kyverno 的选择条件包括四个分类，分别是：

resources: 通过标签、命名空间、名称、注解、API 类型等进行选择；
subjects: 通过发起动作的用户、用户组和 ServiceAccount 进行选择；
roles 和 clusterroles：发起动作的用户角色以及集群角色。

多个条件同时作用时候，可以使用 any 和 all 关键字，分别用于指定 OR 或 AND 的逻辑关系。例如下面的规则：

spec:
  validationFailureAction: enforce
  background: false
  rules:
    - name: match-criticals-except-given-users
      match:
        all:
        - resources:
            kinds:
            - Pod
            selector:
              matchLabels:
                app: critical
      exclude:
        any:
        - subjects:
          - kind: User
            name: susan
          - kind: User
            name: dave

这个选择器匹配 app=critical 的 Pod，但是排除了 susan 和 dave 的用户。

再看 Gatekeeper 中对目标对象的选择，它的 spec.match 字段支持以下几种选择：

kinds：一个数组型字段，元素为 apiGroup 和 kind 的组合；
scope：用于定义作用范围，可以是 Namespaced, Cluster 或 *；
namespaces：一个数组型字段，元素为命名空间名称；可以支持尾部通配符，例如 kube-*；
excludedNamespaces：数组字段，需要排除的命名空间，同样支持尾部通配符；
labelSelector：其中包含 matchLabels 和 matchExpressions 两个字段，分别用于指定标签选择器和表达式选择器；
namespaceSelector：标签选择器，用于选择命名空间；
name：支持尾部通配符，用于过滤对象名称。

对比看来，Gatekeeper 的字段类型更丰富一些，但是 Kyverno 的优势是加入了针对特定动作发起者直接进行限制，Gatekeeper 也不是没有这种能力，它需要在策略中直接实现针对这些内容的过滤，所以二者的能力类似，但侧重点、便利程度是有所不同的。

策略编写

Kyverno 和 Gatekeeper 的策略编写方式是迥然不同的，例如一个简单的标签验证策略，在 Kyverno 中的实现：

  pattern:
    spec:
      containers:
      - name: "*"
        resources:
          limits:
            memory: "?*"
            cpu: "?*"
          requests:
            memory: "?*"
            cpu: "?*"

而在 Gatekeeper 中就相当不同了：

package limit
resources_defined(x) {
  x.resources; x.resources.limits; x.resources.requests
}
violation[{"msg": msg}] {
  ctr_list = input.review.object.spec.template.spec.containers
  some i
  ctr = ctr_list[i]
  not resources_defined(ctr)
  msg = sprintf("%v containers without 'resource' fields", [ctr.name])
}

Rego 语言给 OPA/Gatekeeper 带来强大能力的同时，也带来一定的学习成本，而 Kyverno 的最复杂语法（YAML）元素大概是：

Anchors：用于表述 if-then-else 语义，“如果存在 hostPath，则其内容不能是 /var/lib”：
```
=(hostPath):
    path: “!/var/lib”
```
foreach：用于对一个列表中的多个元素定义多种策略，例如 Pod 中的 Containers 数组。

虽然简单，但是用主要用于描述结构内容的 YAML 来表达逻辑，还是颇有些古怪的；Rego 加持的 OPA/Gatekeeper 就不会有这种烦恼了——它的一个困扰是，每种 Constraint 都是一种 CRD，当然，这种 CRD 非常灵活，能够很好地表达 Contraint 的参数化能力。

再说 Mutation，Kyverno 是使用 RFC 6902 JSONPatch 和 Strategic Merge Patch 两种方式来进行变更的，例如对 Configmap 对象的变更：

patchesJson6902: |-
  - path: "/data"
    op: add
    value: {"ship.properties": "{\"type\": \"starship\", \"owner\": \"utany.corp\"}"}

这只是个最简单的例子，Keyverno 的 Mutation 相关语法难度远大于验证语法。

而 OPA/Gatekeeper 的这个功能就让我有些意外了，它特别定义了三种 CRD，分别是：

AssignMetadata：用于对资源元数据进行变更
Assign：对元数据之外的内容进行变更
ModifySet：从列表中加入或者移除内容

例如要加入一个注解：

apiVersion: mutations.gatekeeper.sh/v1beta1
kind: AssignMetadata
metadata:
  name: demo-annotation-owner
spec:
  match:
    scope: Namespaced
  location: "metadata.annotations.owner"
  parameters:
    assign:
      value: "admin"

两个产品都提供了对策略进行测试的能力，不过 Kyverno 很遗憾地没有提供对 arm64 的支持。

审计和可观测性

Kyverno 提供了一个单独的可观测性服务，可以用 Prometheus 抓取如下内容：

策略和规则的数量
策略和规则的执行结果
策略执行的延迟
请求数量
策略变更数量

另外 Kyverno 还提供了两个用于生成报告的 CRD：PolicyReport 和 ClusterPolicyReport，例如：

$ kubectl get polr -A
NAMESPACE     NAME                  PASS   FAIL   WARN   ERROR   SKIP   AGE
default       polr-ns-default       338    2      0      0       0      28h
flux-system   polr-ns-flux-system   135    5      0      0       0      28h
$ kubectl describe polr polr-ns-default | grep "Result: \+fail" -B10
  Message:        validation error: Running as root is not allowed. The fields spec.securityContext.runAsNonRoot, spec.containers[*].securityContext.runAsNonRoot, and spec.initContainers[*].securityContext.runAsNonRoot must be `true`. Rule check-containers[0] failed at path /spec/securityContext/runAsNonRoot/. Rule check-containers[1] failed at path /spec/containers/0/securityContext/.
  Policy:         require-run-as-non-root
  Resources:
    API Version:  v1
    Kind:         Pod
    Name:         add-capabilities-init-containers
    Namespace:    default
    UID:          1caec743-faed-4d5a-90f7-5f4630febd58
  Rule:           check-containers
  Scored:         true
  Result:         fail
--
  Message:        validation error: Running as root is...

Gatekeeper 提供的指标包括：

Constraint：Constraints 的数量
Constraint Template：包括这一类对象的数量、处理延迟
Webhook：请求数量、响应时间、Mutation 请求数量、Mutation 响应时间
Audit：触发次数、审计延迟、审计运行时间戳
同步：缓存对象数量、同步延迟、最后同步时间戳
Watch：Watch 的对象种类数量

Kyverno 策略中提供了 validationFailureAction 字段，用于定义策略失败后的动作，可选动作包括 audit 和 enforce。

Gatekeeper 策略中包含 DryRun、Warn 和 Deny 三种应对措施。

独特功能

Kyverno 在功能方面有两个有趣的东西：

创建对象：可以根据策略，在特定条件下触发对象的创建，例如随 Service 创建 Ingress 之类；
校验镜像签名：可以使用 cosign 对镜像签名进行校验，保障供应链安全。

太长不看

OPA 是 CNCF 的老牌项目，Kyverno 属于后起之秀，在策略编写方面，Kyverno 的表达方式更合乎 YAML 工程师们的做事风格；而 Rego 语言虽然语法还是很奇怪，然而一旦习惯了这种设定，强大的实现能力还是要优于 YAML 语法糖的。

Mutation 方面，Gatekeeper 支持的比较晚，也非常生硬。Kyverno 的高可用和监控能力则是比较晚才出现。

酒话：Copilot 和运维代码

Sun, 12 Dec 2021 16:37:27 +0800

这个话题是前些天和一位同学在饭桌上喝着啤酒闲聊产生的内容，叙事极其杂乱，错过本文不会有任何损失。

背景

前些天跟同事讲，Learnk8s 的 A visual guide on troubleshooting Kubernetes deployments 是个很明显可以转换成工具运用到实际运维工作当中的东西，一套组合拳下来，基本问题搞清楚，是个挺方便的事儿，要不我周末把它搓出来给你看看。听者无意说者有心，我试了试，还真是个挺无聊的事情，设计各种场景，根据条件，捕获各种 K8s 输出，最终汇总成报表。不小心发散了一下，前一阵得到试用资格的 Github copilot 好像就很适合这种工作，周末趁娃补觉，用 Copilot + PyCharm 就真的实现了个差不多。

Copilot

首先介绍下 Copilot，这东西是使用 AI 技术凭借 Github 上的海量代码，用编辑器/ide 插件的形式提供辅助编程能力的一个产品，和 Tab Nine 这样的“传统”插件最大区别是，可以用“面向注释开发”的方式来使用 Copilot，例如输入 # Import Kubernetes 的注释，他就会推荐出 from kubernetes import client, config 这样的语句，按 Tab 接受之后，因为还没有在 venv 中安装相应的库，PyCharm 会做出提示，安装包即可。

整段脚本大概一百行，其中有一半是注释除了前面简单的 Import 之外，比较复杂的遍历、判断，还有使用 API 时候最头秃的对象结构的拆解，都是 Copilot 完成的，例如：

# Import kubernetes
from kubernetes import client, config
# Connect to kubernetes
config.load_kube_config()
# List all pods
v1 = client.CoreV1Api()
print("Listing pods with their IPs:")
ret = v1.list_pod_for_all_namespaces(watch=False)
for i in ret.items:
    print("%s\t%s\t%s" % (i.status.pod_ip, i.metadata.namespace, i.metadata.name))

这其中只有三行注释是手工输入的，对列表的遍历和 print 语句都是自动生成的，非常类似我们在试探阶段编写代码的方法。Copilot 的自动推荐方面还会根据本地代码有所变更，例如：

# define a list to store event messages
pending_event_list = []
...
# save namespace, pod name and message in to an object
pending_event_list.append({'namespace': event.involved_object.namespace, 'pod': event.involved_object.name,
        'message': event.message})
...
# if length of event_list is greater than 0, then print items into a table
if len(pending_event_list) > 0:
    print('Pending Pods:\n')
    print('{:<20}{:<30}{:<20}'.format('Namespace', 'Pod', 'Message'))
    print('{:<20}{:<30}{:<20}'.format('---------', '----', '-------'))
    for item in pending_event_list:
        print('{:<20}{:<30}{:<20}'.format(item['namespace'], item['pod'], item['message']))
    print('\n')

在定义了这个列表之后，仅凭一行注释，她就机智地把这三个字段形成的对象直接塞进了前面定义的列表之中（中间的 Pending Pods:\n 是我的手工输入），后面更是直接输出了表头和间隔线。更有意思的是，Pod 名称一栏的宽度原本是设置为 20 的，我手工改成了 30，后续输出第二个表格时，他就自动将 Pod 字段的宽度修改成了 30。

情况当然不总是一帆风顺的，例如我在输入 # get all events for pod 时，它就推荐了一行错误代码，调用了不存在的成员函数，使用 PyCharm 的自动完成纠正一下也就可以了；在判断容器重启次数时，他也会直接给出 pod.status.container_statuses[0].restart_count > 5 这样的粗暴判断。

总之两个小时下来，我主要的工作就在于几个点：

设计故障场景
琢磨英文注释
纠正错误代码
运行、调试、更正再运行

用我弱弱的英文输出能力，不停调试注释，让 Copilot 输出合适的代码，并进行微调，最终完成功能。

运维怎么开始写代码

那这么个破事怎么就联系到运维代码上了呢？其实像这种无聊尝试意义是不大的，但是运维代码的开发特点非常适合使用这个东西进行辅助：

需求描述非常技术化，容易转换为 Copilot 的注释输入
具体相关内容在网络上会有非常多的代码碎片，适合被 Copilot 抓取提炼和使用
甚至连注释都会有很多自动完成的机会
场景相对固定，代码量一般不大，方便进行调试

很多运维同学都在面临类似的焦虑——觉得自己手上的工作价值不大，编程基础不太好，又希望能像《Google SRE 解密》中提到的，从手工、脚本、软件直到 Borg 的过程中飞速进化。但是机会不总是存在的，将日常经验有效地变成代码从而得以积累和传播，对组织和个人都是非常具备实际意义的。在个人长期的运维相关工作过程中的经验来看，不管是哪个阶段，不管这个工作应该算是运维、DevOps、SRE 还是别的什么，现场工作一方面是工具的工作场景，另一方面也是工具的需求源头，同时也是工具实现方法的重要参考。

那么如何在现场开始写代码呢？我总结了一个 3X2 原则：如果在你的手工操作中，遇到如下场景：连续三个命令的序列，重复执行了第二次，那么就建议你将它写成一个 Shell 脚本——通常来说，会执行第二次，就会有第三次第四次，随着不断地使用，身兼作者和用户，会有各种非常具体的需求会加入到这个简陋的脚本之中，诱导你在其中逐步加入原本不太熟悉的判断、循环、管道、启动参数等的处理能力——毕竟每次只加一点点，例如我自己的经验：

起初是为了节约公有云测试开支，根据 gcloud 命令行文档，写了在 GKE 上一次性创建和删除 Kubernetes 集群的两个脚本
后来发现，删除集群时，相应的挂载卷也需要进行遍历删除
为了测试一些兼容性问题，需要创建集群时选择不同的 Kubernetes 版本
我拿到了一个每月 300 美金的 Azure 测试账号，我需要将脚本改造成可以选择 Azure 还是 Google Cloud 的版本
..

这一组脚本已经伴随我走了四五年，经过多年的“随手”改造的积累，已经成为几百行的小怪兽，能够在 GCP、AWS、Azure 创建各种不同规格、不同版本的 Kubernetes 集群，完成工作后能不留后患（账单）的进行彻底清理，帮助我完成了很多的测试，输出了很多的云原生相关的记录内容。

在团队中应该把小工具们组织起来，这里非常要提醒大家的一点就是，在文档中保存的代码段，相当于让代码脱离了生存环境，是很容易死掉的，所以具有相同或相似工作内容的组织内，用版本管理的方式将这些小工具们进行归拢。同行之间互相 Review，取长补短、协同进步会让代码段逐步变得成熟和广普。一致的工具集，紧贴现场需求，有助于形成“一个萝卜一个坑”的一致的问题应对方式，代码本身就成为团队的知识积累和沉淀，新兵加入后，可能就不那么需要从 Linux/Docker/Kubernetes 开始了——对于初出茅庐的新手来说，哪怕是一键提取日志，也是快速进入战场的有效途径。

小工具们成长壮大之后，就进入了抽象和复用的阶段了，这一方面，Kubernetes 生态中充满了绝佳范例：重度依赖调度能力、避免直接和节点/服务器之类的具体环境发生联系、专心解决自己的问题、对外提供稳定的声明式接口（声明式接口同时还意味着可重入、最终一致性等等）。例如我屡屡提到超过 300 行算我输的 Shell Operator，用极其简陋的方式，为运维人提供了用少量代码完成 Validating/Mutating Webhook、Prometheus Server、任务队列等复杂任务的能力。

抽象和复用程度代表了一个小工具在时间和场景上的适应能力，也代表了其需求和功能的稳定性，此时就完全可以考虑将其纳入具体的产品，甚至其自身就具备成为产品的潜在能力了——例如我偶尔一写的“介绍一个小工具”。

最后，运维人们，Happy Coding..

Release 自动更新 Krew Index

Fri, 26 Nov 2021 16:36:44 +0800

前面介绍过创建 Krew 插件的方法，其中生成插件描述文件的部分，可以说是又直接又麻烦，而且每次发布的时候，都要重新生成并刷新 Krew Index，于是我写了个脚本，可以根据既有信息和已经发布的二进制文件生成 YAML 文件。这个脚本的功能，简单说就是写一个 YAML 模板，然后下载二进制文件，计算哈希，生成最终的插件描述文件，把描述文件覆盖旧版本，然后发布 PR 即可。有了脚本之后其实还是挺麻烦的，不过在浏览 Krew 文档时发现有一节 Automating plugin updates ，其中提到了可以使用 Krew Release Bot 来自动地完成这个过程，官方强烈推荐使用这个 Bot 进行更新，理由是该 Bot 生成清单文件后自动提交的 PR，如果其中包含的变更内容只是简单的版本升级，能够被 Krew Index 的 Bot 自动处理，免除人工环节之后，整个更新过程可以在几分钟之内完成，避免了新版本二进制无法及时更新的尴尬。下面就介绍一下这个 Bot 的用法。

这个 Bot 是一个 Github Action 的插件，其工作原理和之前的脚本类似，在前文用 Github Action 自动发布二进制包中，在 Karmada 项目里使用 Github Action 进行了二进制文件的构建和发布，接下来继续使用这个基础，根据新发布的二进制来更新 Krew Index。

要在项目里使用 Krew Release Bot，首先要求项目插件已经成功发布到 Krew Index 中；接下来，需要生成一个文件 .krew.yaml，作为 Bot 的模板，这个模板和 Krew Index 的 YAML 是基本一致的，不过其中的二进制 URL 和 Hash 部分被替换为模板的占位符，例如 {{addURIAndSha "https://github.com/karmada-io/karmada/releases/download/{{ .TagName }}/kubectl-karmada-darwin-arm64.tgz" .TagName }}，甚至连这一步简单操作，Bot 作者也帮你解决了——他做了一个 Krew Release Bot Helper，在输入框输入已发布的 Karmada 插件名称，就可以自动生成 YAML 模板，放到项目里就可以了。

接下来，在 Release Action 里面加入如下语句：

- name: Update new version in krew-index
  uses: rajatjindal/krew-release-bot@v0.0.40

提交代码之后，创建一个新的 Release，会发现 Action 失败了，错误信息大概如下：

原因在于前面使用的 Matrix，我们的 PR 应该在生成并上传所有的二进制文件之后才能发起，所以改成这样：

  update-krew-index:
    needs: release-assests
    name: Update krew-index
    runs-on: ubuntu-18.04
    steps:
    - uses: actions/checkout@master
    - name: Update new version in krew-index
      uses: rajatjindal/krew-release-bot@v0.0.40

这里用了一个新的 job，使用 needs 关键字明确指出，需要等待 release-assests 任务完成。

再次提交，并创建 Tag，创建 Release。Action 运行示意图如下：

这里生成的 URL 所指向的二进制文件是无法访问的，因此还是无法成功，但如果是官方自行发布的话，就可以了，而且如上文所说，这样生成的 PR 会在几分钟之内得到 Approve。

读到这里会产生一个问题，会不会有人冒充发表呢？应该是不会的：Krew index 项目的 PR 机器人会对新 PR 的差异进行判定，如果不是典型的版本更新，会转入人工通道，因此新发的 PR 必须是和上一个版本具备这样的差异关系，而且必须是基于官方的二进制发布，才能够得到自动审批，因此完全可以放心使用。

Promethues 的 Agent 模式：高效转发云原生指标

Mon, 22 Nov 2021 20:16:53 +0800

原文：Introducing Prometheus Agent Mode, an Efficient and Cloud-Native Way for Metric Forwarding

作者：Bartlomiej Plotka

Bartek Plotka 是红帽的首席软件工程师，从 2019 年开始担任 Prometheus 项目的维护者，也是 CNCF Thanos 项目的共同作者之一，同时还担任 CNCF 大使以及 CNCF 可观察性 TAG 的技术领导者。他在业余和 O’Reilly 出版了《Efficient Go》一书。

Promethues 对于目标的极度专注是我喜欢并加入这个项目的原因。Prometheus 用务实、可靠、经济的方式，推出了无价的指标监控系统。Prometheus 提供了极其稳定和健壮的 API、查询语言和用于进行集成的协议（例如远端写入和 OpenMetrics），这一稳固的基础，让云原生的监控生态欣欣向荣：

社区提供了包罗万象的 Exporter，例如容器、eBPF、我的世界甚至还有针对园艺的健康监测；
现在多数 CNCF 项目都会提供基于 HTTP/HTTPS 的 /metrics 端点，让 Prometheus 可以读取指标数据。这原本是 Google 内部秘而不宣的一个概念，Prometheus 项目将其公诸于世；
可观察性的范式发生了变化。从一开始 SRE 和开发者就非常依赖指标数据，对软件的韧性、排障能力以及数据驱动的决策过程产生了很好的推动作用

最后，我们极少会看到没有运行 Prometheus 的 Kubernetes。

备受瞩目的 Prometheus 社区让其它项目也同步成长，让 Prometheus 脱离了单节点部署的局限性（例如 Context、Thanos 等等），更有采用 Promethues API 和数据模型的云供应商（例如亚马逊和谷歌的托管 Promethues、Grafana 云等）。如果 Prometheus 只有一个原因，那么这个原因只能是——把监控社区的焦点聚集在重要的事情上面。

本文中将会介绍 Prometheus 的新特性：“Agent”。这一特性内置于 Prometheus 之中。Agent 模式禁用了 Prometheus 的一些特性，优化了指标抓取和远程写入的能力。这一特性使得一种新的应用模式成为可能。本文中我会陈述该功能让 CNCF 生态中游戏规则发生的变化——是的他让我非常兴奋。

转发模式的历史

Prometheus 的核心设计从未变更。这是一个向 Google Borgmon 监控系统致敬的产品，要监控一个应用，就随应用部署一个 Prometheus 服务，告知 Promethues 如何联系到这个服务，允许 Prometheus 定期抓取当前的指标数据。这种工作方式通常被称为拉取模型，这种模型保障 Promethues 的轻量和韧性。另外它还极大简化了应用监控和 Exporter——只需要提供一个简单易读的 HTTP 端点，在其中提供 OpenMetrics 格式的当前指标值即可。这其中没有用到复杂的推送机制，也没有客户端库。一个简单的 Prometheus 监控部署如下图所示：

这种方式工作良好，过去几年中我们看到了上百万的部署案例，其中或长或短的留存了大量的监控数据。其中的指标数据可以进行查询、告警，并记录管理员和开发者都关注的数据指标。

然而云原生世界一直在发展和进化。随着托管 Kubernetes 方案的成长，几秒钟就能随需创建 Kubernetes 集群，我们已经能够把集群当做牲畜而非宠物（换句话说，我们不再关注特定的实例）。在 kcp 和 Fargate 中这样的产品中甚至没有了集群的概念。

另一个有意思的概念就是经常被用在电信、汽车和 IoT 领域的边缘集群和网络。我们会看到越来越多资源有限的小集群。规模限制导致他们无法在本地进行保存，包含监控数据在内的大量数据都需要被传送到远端的更大的节点上。

这意味着必须对必须对监控数据进行聚合，向用户进行呈现，甚至需要有全局级别的存储。这通常被称为全局视角。

要实现全局视角，最直接的办法就是在全局层次部署 Prometheus，通过远程网络抓去指标，或者从远端应用直接写入监控数据。我认为两种办法都烂透了，原因如下：

跨越网络边界的抓取行为会在监控管线中引入不确定因素。本地的拉取模型让 Prometheus 能够清晰获知待抓取目标的问题，例如宕机或者配置错误、重启、抓取缓慢（CPU 耗尽）、无法进行服务发现、缺乏访问凭据、DNS 故障，网络甚至整个集群失灵。外置抓取端引发的不稳定性可能让我们丢失信息。如果网络中断，可能会丧失可见性，相信我，不要这样做。

应用从远端直接向中心推送数据也不是什么好办法——尤其是在监控目标数量巨大时。得到指标之前，无法得到任何远端应用的信息，这个应用活着吗？是我的管线故障了吗？也许应用认证失败了？和前面的办法一样，跨网络的传输总面临着更大的风险。

Serverless 应用以及类似的短寿命容器经常会让我们将远端推送方式当做救命稻草。这种情况下我们希望把细碎的事件和指标能够聚合到一个较长存活期的时间序列里。我们对这一主题也进行了讨论，欢迎加入，一起完善这个方案。

Prometheus 用三种方式来支持全局视图，每种都有不同的优缺点。注意下图橘色部分：

联邦：这是第一种用于聚合目的的方案。这种方案里，全局级的 Prometheus 服务器或从基层 Prometheus 中抓取指标的子集。这种级联方式里，联邦节点暴露的指标中包含了原始采样的时间戳，因此降低了跨网络抓取的风险，但是如果网络间的时延达到分钟级，可能就无法在不损失数据的情况下完成数据联合了。
Prometheus 远程读取：从远端 Prometheus 服务器的数据库中绕过 PromQL，直接提取原始数据。可以在全局一级部署 Prometheus 或者 Thanos 方案，用抓取自多个站点的远程数据来执行 PromQL 查询。这种方式很强大——数据存储在“本地”，还可以按需访问。不幸的是，这种方式也有缺点，如果没有 Query Pushdown，一个简单的查询可能就要拉取上 GB 的压缩数据。类似地，如果网络失联，服务就不可用了，另外有些集群只允许 Egress，禁止 Ingress
最后一种就是远程写入：这似乎是目前最流行的选择。Agent 模式也是聚焦于远程写入的，因此我们要详细描述一下这个模式

远程写入

Prometheus 远程写入协议让用户可以把部分或者全部指标数据写入到远端，可以对 Prometheus 进行配置，将一些指标（其中甚至可以代入所有的元数据和范例）转发给一个或多个远端的写入 API。实际上 Prometheus 是同时支持远端接收和写入的，所以可以部署全局级的 Prometheus 来接收跨集群的聚合数据。

Prometheus 远程写入 API 规范还在评审阶段，但整个生态接受了远端写入协议作为缺省指标导出协议。例如 Cortext、Thanos、OpenTelemetry 以及 Amazon、Google、Grafana、Logz.io 等云厂商，都支持这一协议的写入。

Prometheus 官方提供了官方的 API 兼容性测试，能通过远程写入合规性测试的方案，就可以提供远程写入的客户端能力。对于自行实现的工具来说这个功能非常有帮助，能帮助自实现工具确认协议实现的正确性。

抓取得到的流数据进行中心化存储之后，就有了全局视图的实现基础。这样也实现了关注点的分离。应用程序不受可观察性团队的管理的情况下，这种方式很有优势。这种方式让服务商们能够将这种工作从客户侧剥离开来，因此得以广泛采用。

但是 Bartek 你刚刚说过，从应用推送指标不是个好主意！

没错，不过有意思的是，远程写入的情况下，Prometheus 还是使用拉取模式从应用端获得指标数据的，然后对取样和序列进行批处理，把数据进行导出，推送到远程写入端点，有效地降低了中心点在应用失联时面临的风险。

远程写入的可靠性和效率，是一个亟待解决的难题。普罗米修斯社区花了大约三年的时间完成了稳定和可扩展的实现。WAL（写前日志）经过多次重构后，增加了内部队列、分片、智能备份等等。所有这些对用户来说都是隐藏的，用户可以在集中存储的场景下得到良好的流性能和数据量支持。

Katacoda 教程：远程写入

在 Prometheus 中这些都不新鲜，很多用户都在使用这种抓取应用信息后向远端进行写入的方式。

要体验这种远端写入能力，推荐使用 Katacoda 提供的 Prometheus 远程写入 Thanos 教程，其中解释了 Prometheus 远程转发的所有步骤。这个课程是免费的，注册账号尝试一下就好。

这里用接收模式的 Thanos 作为远程存储。现在还可以使用大量与远程写入 API 兼容的其它项目。

远程写入这么好，为什么还要给 Prometheus 加入 Agent 模式？

Prometheus 的 Agent 模式

Prometheus v2.32.0 开始，用户可以使用测试版参数 --enable-feature=agent 来启动启动 Prometheus。

Agent 模式优化了远程写入的用例。它禁止了查询、告警和本地存储，取而代之的是一个自定义的 TSDB WAL。其它部分原封不动：抓取逻辑、服务发现和相关的配置。如果只是想把数据转发到远端的 Prometheus 服务器或其它兼容的项目，这种方式非常值得一试。工作方式如下图所示：

如果你不想在本地进行查询和告警，只是把指标输出到外部，使用 Agent 有什么好处呢？

第一个就是效率。Agent 中使用的 TSDB WAL 在转发成功后会立刻删除数据。如果远程端点无法连接，就会将数据保存起来，等待端点恢复。这种行为很像非 Agent 模式的 Prometheus，目前的缓冲有效期是两个小时，未来可能打破这个限制。这样一来我们就无需分配大块内存，也不用为查询准备完全索引。代理模式的资源消耗比标准服务实例低得多。

在边缘或者类似的环境中，CPU 和内存资源可能会很有限，效率是个非常重要的问题。另外目前使用指标进行监控的模式已经非常成熟。这意味着同样成本之下，能获得越多的监控指标，就越有性价比。

Agent 模式是针对特定使用场景的，标准模式的 Promethues Server 更稳定、更易维护，仍是缺省建议；Agent 模式的远端存储引入了更高的复杂性，还需谨慎使用。

另外，Agent 模式便于搭建纵向伸缩的数据接收架构。

指标接收端的弹性伸缩

数据抓取侧的自动伸缩方案需要根据抓取目标和指标数量进行判断。抓取的数据越多，就要自动部署更多实例。如果目标和指标数量下降了，就应该进行缩容，移除部分实例。自动伸缩能够降低 Promethues 规模调整造成的手工操作负担，并防止低谷期间浪费系统资源。

Server 模式的 Prometheus 是有状态的，很难应对这种需求。这种模式下搜集的数据保存在本地，缩容过程需要在中止实例之前将数据进行备份。接下来还要面对指标重叠、误导性的过期标记等问题。

这种场景下，我们需要能够聚合所有实例所有数据的全局视图（例如 Thanos Query 或者 Promxy）来进行查询。普通模式下的 Prometheus 的职责不仅限于指标采集，还包含了告警、录制、查询、压缩、远程写入等，这些任务都会消耗资源。

Agent 模式将服务发现、指标抓取和远程写入放到一个单独的服务中，如此就将工作焦点集中到了指标搜集上面。Agent 模式的 Prometheus 变得更加的“无状态”。是的为了防止数据丢失，我们需要部署一对 HA 实例，并挂接持久存储。但是技术上来说，我们有几千个目标（容器），我们可以部署多个 Prometheus Agent，安全地把抓取目标分配给特定实例。这么做的根本原因就是这些数据都会被推送给同一个中央存储。

总的说来，Agent 模式的 Prometheus 让自动的水平伸缩成为可能，从而有了针对监控指标规模变更进行应对的能力。我们将会和 Prometheus Kubernetes Operator 社区一起在这个方向努力。

那么 Agent 模式的 Prometheus 是否真的可用呢？

Agent 模式得到了大规模验证

Prometheus 会把 Agent 模式作为实验性功能加入下一个版本。参数、API 以及 WAL 的格式会发生变更。但是这种实现的性能已经在 Grafana Lab 的帮助下得到了实际验证。

Agent 的自定义 WAL 最初的实现是受到了 Robert Fratto 在 2019 年为 TSDB 实现的 WAL 的启发，期间得到了 Prometheus Maintainer Tom Wilkie 的指导。这个格式后来被用于 Grafana Agent 项目，得到了很多 Grafana 云的用户的采用。这一方案的成熟后，捐献给了 Promethues，希望得到集成和更多的发展和采用。Grafana 实验室的 Robert 在 Redhat 的 Srikrishna 以及社区帮助下，把这些代码移植到了 Prometheus，然后只用了半个月就合并进入到 main 分支。

有些 Prometheus Maintainer 也曾经为 Grafana Agent 项目贡献过代码，Grafana 的新 WAL 格式也是受到了 Prometheus WAL 格式的启发，捐献的过程非常平滑，并且目前的 Prometheus TSDB Maintainer 也能够方便的进行管理。并且 Robot 已经加入 Prometheus 团队，成为 TSDB 的 Maintainer。

接下来讲讲如何使用。

如何使用 Agent 模式

Prometheus 的帮助（--help 参数）内容中会看到类似内容：

usage: prometheus [<flags>]

The Prometheus monitoring server

Flags:
  -h, --help                     Show context-sensitive help (also try --help-long and --help-man).
      (... other flags)
      --storage.tsdb.path="data/"
                                 Base path for metrics storage. Use with server mode only.
      --storage.agent.path="data-agent/"
                                 Base path for metrics storage. Use with agent mode only.
      (... other flags)
      --enable-feature= ...      Comma separated feature names to enable. Valid options: agent, exemplar-storage, expand-external-labels, memory-snapshot-on-shutdown, promql-at-modifier, promql-negative-offset, remote-write-receiver,
                                 extra-scrape-metrics, new-service-discovery-manager. See https://prometheus.io/docs/prometheus/latest/feature_flags/ for more details.

Agent 模式是需要用 --enable-feature=agent 参数的启用的。这种模式下能够使用同样的指标抓取配置以及远程写入能力。Agent 模式下，Web UI 的查询功能是被禁用的，只能用于展示构建信息、配置内容、抓取指标和服务发现信息。

在 Katacoda 上尝试 Prometheus Agent

可以在 Katacoda 上尝试 Promtheus Agent，真切体会其中的易用性。

用 Karmada 和 Pipy 搭建野生多集群

Sat, 30 Oct 2021 07:56:56 +0800

最近加入 CNCF 成为沙箱项目的 Karmada 项目是一个开放的多 Kubernetes 管理工具，从 Kubernetes Federation ¹⁄₂ 继承的大量经验，让这个项目有成为多集群管理首选产品的潜力。Karmada 具有开箱即用的跨集群调度能力，简单的使用 PropagationPolicy 就能将 Deployment、Service 这样的原生 Kubernetes 对象在多个集群之间进行灵活的调度。

工作负载的分配结束之后，还有个重要的问题就是流量分配了——多集群管理加上流量分配，会有很多有意思的事情可以完成，例如蓝绿灰度金丝雀，集群维护升级等等。实际包括各种网格、API 网关方案在内的很多产品，都有提供跨集群流量管理方案可用。这个例子里我选择了 Pipy 来搭档完成任务，Flomesh 出品的这个东西可塑性很强，除了轻量、快速之外，更重要的是能够用高级语言对流量进行编程，最新版本还为插件模型加入了图形交互界面。

整个原型大致架构如下：

创建 Karmada 管理集群，并部署 Karmada。
纳管两个集群，分别命名为 member1 和 member2
部署 Deployment，并分布到两个集群
部署 Service，用 NodePort 方式开放服务，分发到集群
将暴露的服务端口同步给 Pipy，完成流量分发

部署 Karmada 集群

Karmada 的远程部署需要有一个运行的 Kubernetes 集群，然后克隆代码库，运行其中的 hack/remote-up-karmada.sh 脚本即可，命令行 ./remote-up-karmada.sh ~/.kube/config admin@v19 表示在 ~/.kube/config 配置文件中 admin@v19 上下文所指代的集群中部署 Karmada 控制平面。

部署之前，有两个需要注意的点：

如果要在 arm64 平台上运行，可以将脚本中的镜像改为 dustise/****:v0.0009-29-gc2030ca6
如果像我一样偏偏使用 NodePort 方式暴露 Karmada API Server，在 deploy-karmada.sh 的 203 行 installCRDs 语句之前加入一个 read -p "Review your kubeconfig, then press [Enter] key to continue.."，脚本运行至此会暂停工作，修改 kubeconfig 文件中新出现的 karmada-apiserver 上下文中的服务器即可，例如：
```
- cluster:
  insecure-skip-tls-verify: true
  server: https://10.211.55.58:32016
name: karmada-apiserver
```

安装器会在集群中生成 kamada-system 命名空间，在其中运行一个自己的 API Server，用于提供集群管理服务，并拉取认证信息到指定 Kubeconfig。

纳管集群

完成部署之后，可以在 Karmada 项目的 Release 页面上下载 karmada 用客户端 karmadactl 来加入集群了，例如：

$  kubectl karmada join member2 \
--cluster-kubeconfig=./total.yaml \
--cluster-context=admin@karmada2

为了方便使用，上面的命令把 karmada 客户端设置成为了 krew 插件，实际上直接解压使用二进制也是等效的。

和部署控制平面的命令类似，Karmada CLI 也是使用指定 kubeconfig 和上下文的方式，获取集群操作权限，把集群加入 Karmada。

Karmada 加入新集群之后，会在它的管理面 API Server 中注册一个 Cluster 对象，下面是加入了两个集群之后的样子：

$ kubectl get clusters
NAME      VERSION    MODE   READY   AGE
member1   v1.19.15   Push   True    13h
member2   v1.19.15   Push   True    13h

操作成员集群

既然是对象，就可以看看他葫芦里卖的是什么 YAML 了：

apiVersion: cluster.karmada.io/v1alpha1
kind: Cluster
metadata:
  creationTimestamp: "2021-10-14T11:51:54Z"
  finalizers:
  - karmada.io/cluster-controller
  generation: 1
  name: member1
...
spec:
  apiEndpoint: https://10.211.55.61:6443
  secretRef:
    name: member1
    namespace: karmada-cluster
  syncMode: Push
status:
  apiEnablements:
  - groupVersion: v1
    resources:
    - kind: Binding
      name: bindings
    - kind: ComponentStatus
      name: componentstatuses
    - kind: ConfigMap
      name: configmaps
    - kind: Endpoints
      name: endpoints
    ...
  conditions:
  - lastTransitionTime: "2021-10-14T13:52:31Z"
    message: cluster is reachable and health endpoint responded with ok
    reason: ClusterReady
    status: "True"
    type: Ready
  kubernetesVersion: v1.19.15
  nodeSummary:
    readyNum: 1
    totalNum: 1
  resourceSummary:
    allocatable:
      cpu: "2"
      ephemeral-storage: "59200992363"
      hugepages-1Gi: "0"
      hugepages-2Mi: "0"
      hugepages-32Mi: "0"
      hugepages-64Ki: "0"
      memory: 1927288Ki
      pods: "110"
    allocated:
      cpu: "1"
      ephemeral-storage: "0"
      memory: 140Mi
      pods: "10"
    allocating:
      cpu: "0"
      ephemeral-storage: "0"
      memory: "0"
      pods: "0"

会发现这里对集群的描述很像节点，状态字段中包含了：

资源情况
可接受的对象类型
运行状况

而 spec字段中的内容则包含了集群的访问端点和一个对 Secret 对象的引用，查看一下其中的内容：

$  kubectl view-secret -n karmada-cluster member1
Multiple sub keys found. Specify another argument, one of:
-> caBundle
-> token
$ kubectl view-secret -n karmada-cluster member1 caBundle
-----BEGIN CERTIFICATE-----
MIIC5zCCAc+gAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwprdWJl
...
-----END CERTIFICATE-----
$ kubectl view-secret -n karmada-cluster member1 token
eyJhbGciOiJSUzI1NiIsImtpZCI6ImRqZTY2OGVua0ltSHA2UGJ3LUZHQ0V
...

看起来这是个访问 Kubernetes 使用的凭据，我们可以导出 caBundle 测试一下：

$ kubectl --certificate-authority=member1/caBundle.pem \
  --server=https://10.211.55.61:6443 --token=eyJhb...\
  get nodes
NAME       STATUS   ROLES    AGE   VERSION
karmada1   Ready    master   37h   v1.19.15

果然返回了集群信息。

Karmada v0.9.0 中的 Cluster 对象属于 cluster.karmada.io/v1alpha1，因此可以用如下代码获取集群信息：

crd = client.CustomObjectsApi(karmada_config)
member_list = crd.list_cluster_custom_object(group="cluster.karmada.io",
                                             version="v1alpha1", plural="clusters")

而根据前面的尝试，用这个结果连接集群也是很方便的：

secret_name = member_obj["spec"]["secretRef"]["name"]
secret_ns = member_obj["spec"]["secretRef"]["namespace"]
secret_client = client.CoreV1Api(karmada_config)
secret_obj = secret_client.read_namespaced_secret(secret_name, secret_ns)
server_token = secret_obj.data["token"]
server = member_obj["spec"]["apiEndpoint"]
cfg = config.kube_config.Configuration()
cfg.host = server
cfg.api_key = {'authorization': 'Bearer ' + base64.b64decode(server_token.encode("ascii")).decode("ascii")}
cfg.verify_ssl = False
api_client = client.api_client.ApiClient(cfg)

部署应用

创建一个 Deployment：

$ kubectl create deploy flask --image=dustise/flaskapp:v0.2.7
...
deployment.apps/flask scaled
$ kubectl get deploy
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
flask   0/4     0            0           13h

这里我们创建一个 Deployment，并设置为四副本运行，在控制面看来，这个 Deployment 无法运行，也没有生成 Replicaset，接下来我们为它设置一个传播策略：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: flask
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: flask
  placement:
    clusterAffinity:
      clusterNames:
        - member1
        - member2
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        staticWeightList:
          - targetCluster:
              clusterNames:
                - member1
            weight: 1
          - targetCluster:
              clusterNames:
                - member2
            weight: 1

提交之后，可以看到成员集群按照我们设置的权重来创建 Pod：

$ k1 get po ; k2 get po
NAME                     READY   STATUS    RESTARTS   AGE
flask-6d75654674-54c7p   1/1     Running   0          34s
flask-6d75654674-qgbjg   1/1     Running   0          34s
NAME                     READY   STATUS    RESTARTS   AGE
flask-6d75654674-7d5vl   1/1     Running   0          3s
flask-6d75654674-9ns6n   1/1     Running   0          112s
~~~

缩容到 2 实例：

k1 get po ; k2 get po
NAME                     READY   STATUS        RESTARTS   AGE
flask-6d75654674-54c7p   0/1     Terminating   0          2m14s
flask-6d75654674-qgbjg   1/1     Running       0          2m14s
NAME                     READY   STATUS    RESTARTS   AGE
flask-6d75654674-9ns6n   1/1     Running   0          3m32s

Pod 运行起来之后，我们来部署一个 Service：

apiVersion: v1
kind: Service
metadata:
  labels:
    app: flask
  name: flask
spec:
  ports:
  - name: http
    port: 80
  selector:
    app: flask
  type: NodePort

创建之后，会发现 Karmada 为新服务分配了端口，Endpoint 是没有的：

$ kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
flask        NodePort    10.110.144.229   <none>        80:31193/TCP   13h
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        41h
$ kubectl get ep
NAME         ENDPOINTS           AGE
kubernetes   10.211.55.58:5443   41h

同样创建一个 pp，把 Service 分配给集群。完成分发后就可以访问各个集群的服务了。

有时候有人跟你说 PP 其实不是耍流氓，是在讨论 Karmada。

用 Pipy 做负载均衡

Pipy 的部署很方便，在 Release 页面下载二进制即可。源码中的 tutorial/08-load-balancing-improved 就是一个负载均衡的例子，这里我们对其配置做个简化：

这个例子中的 router 对象和 Kong Gateway 的概念类似，我们修改一下 config/router.json，仅包含一个对 /env/* 路径的转发：

{
  "routes": {
    "/env/*": "flask"
  }
}

而 config/balancer.js 中则包含了对负载均衡池的定义，原文内容：

{
  "services": {
    "service-hi"      : ["127.0.0.1:8080", "127.0.0.1:8082"],
    "service-echo"    : ["127.0.0.1:8081"],
    "service-tell-ip" : ["127.0.0.1:8082"]
  }
}

清理一下，只留下：

{
  "services": {
    "flask"      : [<每个集群每个节点的 Flask 服务 NodePort>] 
  }
}

启动 Pipy：pipy --admin-port=8889 proxy.js，在 8889 启用了控制台端口，浏览器打开会看到类似界面：

现在就可以在 config/proxy.json 中定义的代理端口中上访问我们部署在 Kubernetes 中的服务了。整个流程都非常清楚，这个服务发生任何变化，把新的开放端口写入配置，刷新 Pipy 即可，大致代码如下：

# 列出 Karmada 集群
for cluster in members["items"]:
    member_name = cluster["metadata"]["name"]
    logging.info("Services in cluster {}".format(member_name))
    cluster_client = karmada.get_member_client(cluster)
    # 查找服务
    services = karmada.list_service(cluster_client, "default", {"app": "flask"})
    # 每个集群的节点
    nodes = karmada.list_nodes(cluster_client)
    address_list = []
    port_list = []
    for node in nodes.items:
        addresses = node.status.addresses
        for address in addresses:
            if address.type == "InternalIP":
                logging.info("Found a node in {} with IP {}".format(member_name, address.address))
                address_list.append(address.address)
                break
    for service in services.items:
        port_list.append(service.spec.ports[0].node_port)
        logging.info("Found service named {} in cluster {}".format(service.metadata.name, member_name))
    # 组装 URL
    for address in address_list:
        for port in port_list:
            lb_config["services"]["flask"].append("{}:{}".format(address, port))

最终结果写入 Pipy 配置，管理页面重载配置就完成了刷新。此时访问 Pipy 在 proxy.js 中定义的端口，就能看到负载均衡的效果了。

其实没这么简单

首先，我知道该用 watch ：）；

其次，在管理界面刷新配置是个挺傻的事情，Pipy 提供了 Repo 功能，可以进行热加载。这个组件也是 Pipy 高可用和控制平面、GitOps 的命门所在。

另外，在节点比较多的集群中，往往不会把所有节点用于暴露 NodePort，这时可以考虑使用节点标签来限制负载均衡池的生成情况。

最后直接生成 balancer.js 是个非常粗糙的行为，这种做法里，Pipy 必须独占，否则一次刷新可能就覆盖了其它服务的定义，因此这里最好能够使用 Annotation 或者 CRD 等方式，给集群、服务、节点做出标识，从而精确完成刷新过程。

Pod 对象也能被淘汰么

Sun, 24 Oct 2021 22:33:16 +0800

原文：Could Kubernetes Pods Ever Become Deprecated?

作者：Martin Heinz

随着时间的推移，所有的软件项目都会加入新的功能和 API，与此相对地，也会有功能和 API 被移除。Kubernetes 这样的大型项目也并无不同，但是核心 API 的废弃和删除，始终有些含混，Kubernetes 中的核心对象或者说是 API，例如 Pod、Deployment 和 Service，是不是可以删除呢？如果答案是肯定的，那么该如何进行呢？

长话短说

GA 状态的核心 API，例如 v1 API 中的对象也是可能淘汰的。Kubernetes 中的的淘汰话题需要分为 API、CLI 以及 FeatureGate 这三个方面，每方面又会有自己的成熟阶段，例如 Alpha、Beta 或者 GA，这些成熟度的定义，就代表了在什么时间、什么条件下进行淘汰操作—— Pod 这样的东西也不能例外。因此本文尝试对这一问题进行进一步的探讨，看看过往的例子和一些未来的假设。

分而治之

不同的对象或功能有不同的规则，所以在讨论淘汰规则之前，首先对这些淘汰目标进行分类：

REST 对象：这是绝大多数人最多打交道的东西，因此也是最引人关注的方向，这里包括了 Pod 或者 Deployment 这样的顶层对象，也包含了它们的成员字段，例如 containers、volumes 或者 env；另外还有一些常量，例如 imagePullPolicy 使用的 Always、IfNotPresent 等。
CLI 和命令行参数：这一部分内容是针对客户端的。最容易想到的可能就是 kubectl，其实还包含了 kubelet、kube-apiserver 或者 kube-scheduler 及其子命令和选项等。
功能和行为：各种不同成熟度的试验特性是无法用 API 或者 CLI 来表达的，但是它们也应该有自己的淘汰过程和节奏。
指标：最后 Kubernetes 的各个组件还在 /metrics 端点中提供了大量指标。这些指标可能会在监控等系统中使用，因此也不能直接删除，而需要有一定的淘汰规则。

REST 对象

REST API 需要遵守一个普遍规则——官宣淘汰之时，API 版本至少要支持：

GA：12 个月或者 3 次发版（取最长时间）
Beta：9 个月或者 3 次发版（取最长时间）
Alpha：0 次发版

看起来好像非常清晰，其实里面包含了很多其它（可能很难理解）的规则，所以我们先进入示例环节来进行澄清。假设有一个叫做 Task 的 API 对象（有趣的事实：这是 Pod 的原名，请参见 First Commit of Kubernetes）。这个对象处于 GA 状态，其 API 版本为 v1，淘汰需要经过什么过程呢？

Kubernetes 版本	API 版本	推荐	行为
X	`v1`	`v1`	此时 `Task` 对象处于 GA 状态，并没有进入淘汰周期
X+1	`v2alpha1`, `v1`	`v1`	引入 `v2alpha1`，宣布 `Task` 开始淘汰，此时 `v2alpha1` 中并不包含 `Task`
X+2	`v2alpha2`，`v1`	`v1`	用 `v2alpha2` 替代 `v2alpha1`
X+3	`v2beta1`, `v1`	`v1`	`v2alpha2` 被 `v2beta1` 替换
X+4	`v2beta2`、~~`v2beta1`~~、`v1`	`v1`	引入 `v2beta2`，`v2beta1` 依旧存在，但是开始淘汰
X+5	`v2`、~~`v2beta2`~~、~~`v2beta1`~~、~~`v1`~~	`v1`	引入 `v2`，包括首选使用的 `v1` 在内的所有其他版本进入淘汰周期
X+6	`v2`、~~`v2beta2`~~、~~`v2beta1`~~、~~`v1`~~	`v2`	没有移除任何 API，但是 `v2` 已经成为首选版本
X+7	`v2`、~~`v2beta2`~~、~~`v1`~~	`v2`	移除 `v2beta1`
X+8	`v2`、~~`v1`~~	`v2`	移除 `v2beta2`
X+9	`v2`、~~`v1`~~	`v2`	没有什么变化，按照规则，`v1` 必须继续存活一个版本
X+10	`v2`	`v2`	最终删除了 `v1`，其中的 `Task` 对象也宣告终结

从上表来看，如果在 v2alpha1 开始淘汰 Task 对象，就需要 9 个版本才能最终完成。读者需要注意的是，根据当下的发布节奏，每年发版三次，整个淘汰流程可能需要三年多。

有些对象虽然没进入 GA，但是用户已经将其视为 GA 并进行使用。例如 1.19 中才进入 GA 的 Ingress，或者 1.21 的 CronJob。这种 beta 甚至是 alpha 的版本，淘汰节奏就不会这么宽松了。要检查资源所属的分类，可以运行 kubectl api-resources | grep beta，读取所有集群中的所有 beta API 对象类型。

REST 对象字段成员、常量以及对象结构，淘汰规则跟对象是一致的。也就是说，imagePullPolicy 中使用的 Always、IfNotPresent 和 Never 不会随机变化也不会从一节挪到另一节。

例如 PodSecurityPolicy 可能是近期的一个最大变化。这个 API 对象会从 v1beta1 转向 EOL，在 v1.21 中开始淘汰，在 v1.25 中被移除。详情可参见 KEP_2579。

另一个进行中的重要淘汰就是 selfLink 字段，这是 KEP-1164 中的一部分，这一变更的过程记录在 Github Issue 之中。

如果你有兴趣了解其它的淘汰过程，希望了解其中的逻辑关系以及整个流程，可以在 kubernetes/enhancements repository 搜索包含 deprecate 关键字的 KEP。

客户端和参数

和 REST 对象类似，kubectl 和 kubelet 的子命令及其参数也是有自己的淘汰策略的。

这部分的规则比前面的案例要简单，对于 kubectl 这样的面对客户的组件来说：

GA：12 个月或者两次发版（取最长时间）
Beta：3 个月或者 1 次发版（取最长时间）
Alpha：0 次发版

对于 kubelet、kube-apiserver 或者 kube-scheduler 这样的面向管理员的组件：

GA：12 个月或者两次发版（取最长时间）
Beta：3 个月或者 1 次发版（取最长时间）
Alpha：0 次发版

近期这方面的最知名案例应该算是 kubelet 中的 dockershim 了。在 KEP-2221 中讲到，在 v1.20 中设置淘汰，在 v1.24 中进行删除。

这方面的另一个显著目标就是 seccomp Profile 即将 GA，这一过程在 KEP-135 中进行跟进。这个特性并不会真正地对参数和 CLI 产生影响，但是它的 GA 过程会要求淘汰 kubelet 的 --seccomp-profile-root，详情请参见 SIG Node 文档。

所以这一节的淘汰过程是比较较宽松的，但是如果你正在自动化过程中使用 kubectl alpha，最好在升级集群和 CLI 之前检查一下它的淘汰情况。

Feature Gate

Kubernetes 每个版本中都会包含很多的实验性功能。这些功能被称为 Feature Gate，它们使用 Key/Value 形式的开关进行控制。

这些特性既然是用于试验的，其淘汰策略自然和其它的 Kubernetes 对象有所不同。随着特性的逐步成熟，它的 Feature Gate 也会发生变化。Alpha 阶段的功能，其 Feature Gate 会被缺省关闭；而 Beta 阶段的功能则会缺省打开；如果该功能进入 GA，对应的 Feature Gate 就不再需要了，会被淘汰，无法操作。

Alpha 功能可能随时消失；Beta 功能可能会在 1 次发版以后删除；进入 GA 的功能则会在两次发版后删除。

这方面的最好例子就是官方的 Feature Gate 列表。以其中包含的 AffinityInAnnotations 为例，它就是从 Alpha 淘汰的；而 BlockVolume、DryRun 或者 EndpointSlice 则已经进入了 GA。我还没有看到过有从 Beta 被淘汰的 Feature Gate。

如果打开了某些 Feature Gate，在集群升级之前一定要检查一下，防止一些特性因升级被删除。

指标

最后一个需要关注的就是监控指标，可能会有监控工具对指标进行聚合和消费，因此其淘汰过程也是需要多加小心的。和前面章节中的内容不同，指标只分成两类——稳定和 Alpha，声明淘汰之后，稳定指标可以在 3 次发版之后移除，Alpha 可以随时移除。

例如 rest_client_request_latency_seconds 就是一个值得观察的指标淘汰案例，这个过程在 v1.17 的版本说明里体现。

如果想要了解更多监控指标生命周期的问题，可以查看一下系统指标的相关文档。

结论

现今很多项目会采用“有破坏性的快速演进”方法来进行淘汰工作，其中往往会包含繁杂的手工操作，所以 Kubernetes 这样的大项目提出了如此深思熟虑的启用过程，让用户有时间来进行有计划的迁移，这是让人非常愉快的。

那么这篇文章的要点在哪里：

所有东西都可能淘汰？是的？
需要担心吗？显然不用。

看看淘汰的时间线长度，就知道无需担心突然袭击了。但是为长远计，应该检查版本说明，注意其中是否有你正在使用的 Alpha 功能。还应该阅读淘汰 API 指南，其中会列出所有未来将要移除的 API 对象。最后要说明的是，外部供应商的 CRD 的生命周期是自行负责的，可能和官方策略并不一致。

Kubernetes Semaphore：模块化、无侵入的跨集群通信框架

Thu, 07 Oct 2021 16:58:34 +0800

原文：Kubernetes Semaphore: A modular and nonintrusive framework for cross cluster communication

作者：UW Labs

问题

我们有一个环境，其中包含分属三个不同供应商（AWS、GCP 和私有云）的三个集群，我们希望不同集群中运行的应用能够互相通信，以及：

跨集群的 Pod 网络和加密能力；
访问远端 Kubernetes Service 的能力；
用策略来放行远端集群特定应用，使之能够访问本地端点。

我们有一个跨集群的三层网络，这样三个集群的节点就能互相访问了。每个集群都是在各个供应商子网中申请的节点：

AWS：10.66.21.0/24
GCP：10.22.20.0/24
私有云：10.88.0.0/24

三个集群的 Pod 网络分配如下：

AWS：10.2.0.0/16
GCP：10.4.0.0/16
私有云：10.6.0.0/16

依赖项

Calico CNI：在所有集群中使用 Calico CNI，方案中对 Calico 具有一定依赖；
CoreDNS：Semaphore-Service-Mirror 对此有依赖；
跨集群的三层网络。

现有方案

我们对 Istio、Linkerd、Consul 进行了评估，还直接编写了自己的 Envoy Proxy 配置工具。这些方案都能提供上述大部分甚至全部的功能。但是我们认为他们的性价比并不完全适合我们的环境。不同集群之中运行的不同应用构成的网格结构并不总是让人有兴趣的，其中提供的大量功能也无法让所有人受益。我们希望避免使用 Sidecar Proxy，也回避随之而来的额外开销，并确保我们的程序保持尽可能的独立，不受跨集群通信解决方案的影响。

设计

上面既然提到要避开 Sidecar 代理，我们希望用一种对运维人员和用户都较为简单的方式来解决问题。

理想情况下，每个目标都应该以相互隔离的方法来达成——假设用户只是需要对 Pod 通信进行加密，那么只要进行单独的部署即可。对于新用户来说，只需要少量的配置就可以对方案进行试用，并且可以轻松回退。

方案

Kube-Semaphore 是一个轻量级框架，为不同 Kubernetes 集群之间的应用，提供了简单安全的通信能力，并且无需对应用和清单进行修改。

这不是一个服务网格方案，而是要为远端集群提供服务端点和防火墙规则。

方案由三个独立的工具组成

Semaphore-Wireguard：负责 Kubernetes 集群之间的流量加密；
Semaphore-Service-Mirror：负责在无需外部负载均衡器参与的情况下，将一个集群中的服务暴露到另一个集群之中；
Semaphore-Policy：负载在跨集群的 Pod 间通信里创建防火墙规则。

为了小型、轻量和尽可能的安全，这个组件是用 Go 编写的，并使用了 Kubernetes 和 Calico 的客户端。远端集群上的部署内容很小，本地控制器仅需要一系列的 Service Account，满足 Watch 资源的权限需求即可。

路由和加密

Semaphore-Wireguard 负责在不同集群的节点之间进行加密通信，并在本地主机上加入访问远端 Pod 子网的路由。每个集群的每个节点上都会运行一个 WireGuard 管理器，负责节点之间的点到点通信。它负责生成本地密钥并发现所有远端密钥和端点，并配置与所有远程节点的对等关系。此外，它还负责更新本地路由表，以便通过主机的 WireGuard 接口将所有流量导向远程 Pod 子网。因此，Pod 可以利用所有集群中的节点之间创建的 WireGuard 网状结构，触达远程集群上的 Pod。

WireGuard 和 Calico 的集群内通信管理协作，形成了所有集群所有节点之间的网状结构，WireGuard 网络承担了节点之间的通信。

Semaphore WireGuard 部署样例

下图表达了 WireGuard 形成的主机网格，其中的 merit 就是我们的私有集群：

Service

Semaphore-Service-Mirror 是一个控制器，负责在不同 Kubernetes 集群之间复制服务。此处的镜像服务代表的是一个本地服务，其端点处于远端集群。

镜像控制器会在本地集群创建服务，并用远程集群中 Pod 的地址来更新端点列表，最终形成一个 ClusterIP 类型的 Service。

控制器部署样例

例如 AWS 集群上有一个 Service 对象：

$ kubectl --context=aws --namespace=sys-log get service fluentd
NAME      TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)             AGE
fluentd   ClusterIP   10.3.88.18   <none>        8888/TCP,8889/TCP   164d

它包含的端点：

$ kubectl --context=aws --namespace=sys-log get endpoints fluentd
NAME      ENDPOINTS                                                  AGE
fluentd   10.2.3.19:8889,10.2.4.19:8889,10.2.7.18:8889 + 3 more...   164d

镜像控制器会在 semaphore-service-mirror 所在的命名空间 sys-semaphore 中创建对应的 Service 和 Endpoint：

$ kubectl --context=gcp --namespace=sys-semaphore get service | grep fluentd
aws-sys-log-73736d-fluentd   ClusterIP   10.5.184.192   <none>        8888/TCP,8889/TCP   25d

$ kubectl --context=gcp --namespace=sys-semaphore get endpoints | grep fluentd
aws-sys-log-73736d-fluentd   10.2.3.19:8889,10.2.4.19:8889,10.2.7.18:8889 + 3 more...   17d

我们会发现，这个 Service 指向是远程集群：

$ kubectl --context=gcp --namespace=sys-semaphore describe service aws-sys-log-73736d-fluentd | grep Endpoints
Endpoints:         10.2.3.19:8888,10.2.4.19:8888,10.2.7.18:8888
Endpoints:         10.2.3.19:8889,10.2.4.19:8889,10.2.7.18:8889

控制器会监控远端资源，并根据事件进行更新，这样镜像服务就会及时地指向可用的端点。

最后对 CoreDNS 进行配置，就能够更好地进行解析了：

$ drill fluentd.sys-log.svc.cluster.aws
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 51067
;; flags: qr aa rd ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; fluentd.sys-log.svc.cluster.aws.     IN      A

;; ANSWER SECTION:
fluentd.sys-log.svc.cluster.aws.        5       IN      A       10.5.184.192

这样我们的 Pod 在无需关注镜像细节的情况下使用友好的服务名称了。

Policy

Semaphore-Policy 是一个用于创建防火墙策略的组件，用于限制来自远端集群的访问。这个组件会创建用于 Calico 网络策略的 IP 组，来定义允许发起的流量。控制器的唯一任务就是根据标签选择器来监控远端集群的 Pod，然后根据监控结果在本地创建 NetworkSets。接下来，可以使用简单的标签来描述 Calico Network Policy，方便地实现跨集群防火墙规则。

策略控制器部署样例

假设 GCP 集群中存在如下部署：

$ kubectl --context=gcp --namespace=sys-log get po -o wide -l policy.semaphore.uw.io/name=forwarder
NAME              READY   STATUS    RESTARTS   AGE     IP          NODE                                      NOMINATED NODE   READINESS GATES
forwarder-4jdm6   1/1     Running   0          3d20h   10.4.1.3    worker-k8s-exp-1-4l87.c.uw-dev.internal   <none>           <none>
forwarder-6ztl4   1/1     Running   0          3d20h   10.4.0.13   worker-k8s-exp-1-2868.c.uw-dev.internal   <none>           <none>
forwarder-klxdc   1/1     Running   0          4h27m   10.4.4.2    master-k8s-exp-1-j5f8.c.uw-dev.internal   <none>           <none>
forwarder-m9k27   1/1     Running   0          4h27m   10.4.5.2    master-k8s-exp-1-fc0b.c.uw-dev.internal   <none>           <none>
forwarder-n6nsn   1/1     Running   0          4h27m   10.4.3.3    master-k8s-exp-1-31rv.c.uw-dev.internal   <none>           <none>
forwarder-n8vnj   1/1     Running   0          3d20h   10.4.2.4    worker-k8s-exp-1-mdd7.c.uw-dev.internal   <none>           <none>

这是一个 sys-log 命名空间里名为 forwarder 的 DaemonSet。为了让控制器在远程集群中创建所需资源，需要给这个 Daemonset 中的 Pod 加入标签 policy.semaphore.uw.io/name=forwarder。加入标签之后，AWS 集群中的控制器就会创建对应的 GlobalNetworkSet：

$ kubectl --context=aws describe GlobalNetworkSet gcp-sys-log-forwarder
Name:         gcp-sys-log-forwarder
Namespace:
Labels:       managed-by=semaphore-policy
              policy.semaphore.uw.io/cluster=gcp
              policy.semaphore.uw.io/name=forwarder
              policy.semaphore.uw.io/namespace=sys-log
Annotations:  projectcalico.org/metadata: {"uid":"c7569765-a47d-424c-9533-80e4a7c201d6","creationTimestamp":"2021-04-09T15:04:43Z"}
API Version:  crd.projectcalico.org/v1
Kind:         GlobalNetworkSet
Spec:
  Nets:
    10.4.5.2/32
    10.4.4.2/32
    10.4.1.3/32
    10.4.0.13/32
    10.4.3.3/32
    10.4.2.4/32
Events:  <none>

这个组合包含了远端对象的 IP 地址，可以用于 Calico 的网络策略，定义允许进入的流量：

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-to-fluentd
spec:
  selector: app.kubernetes.io/name == 'fluentd'
  types:
    - Ingress
  ingress:
    - action: Allow
      protocol: TCP
      source:
        selector: >-
          policy.semaphore.uw.io/name == 'forwarder' &&
          policy.semaphore.uw.io/namespace == 'sys-log' &&
          policy.semaphore.uw.io/cluster == 'gcp'
        namespaceSelector: global()
      destination:
        ports:
          - 8889

上边的规则允许来自远端 forwarder 到本地 fluentd 的访问。

后记

这套东西对我们来说很有用，但是它的局限性也是显而易见的——如果恰巧适用于读者的环境和需求，那自然很好；如果不是，也希望读者在本文中得到一点启发。

没有 Calico 和 WireGuard，这个方案可能就难于落地了，方案的复杂部分主要是由这两个项目完成的，也正因为此，我们对我们的方案充满信心，这里对他们致以崇高敬意。

用 Github Action 自动发布二进制包

Fri, 17 Sep 2021 19:36:23 +0800

Github Actions 是 Github 提供的一个自动化流程工具，编写一段 YAML，随代码一起发布，根据脚本中定义的触发事件，能够完成 Lint、Build、Push Image 等等操作，在 Actions Market 中包含数千个功能各异的项目，能够给软件作者很大的帮助。

在发布 Github 项目版本时，Golang 之类的项目往往都需要执行构建、打包等动作，除了自己动手之外，也可以用 Github Action（也不排除使用 Travis CI 等自动化服务）来完成任务。

定义触发条件

Github Action 是使用 Github 事件来触发的，我们现在的需求是在生成 Release 的时候完成任务，因此可以如此定义触发事件：

on:
  release:
    types:
    - created

Release 相关事件除了 created 之外，还包括 published、unpublished、edited、deleted, 以及 prereleased。对象详情请参看附录 Reference 链接。

交叉构建

确定触发条件之后，下一个任务就是构建了，golang 项目通常需要进行多平台的交叉编译，在 Github Action 中可以用 Matrix 特性做个循环：

    strategy:
      matrix:
        include:
          - goarch: amd64
            goos: linux
          - goarch: amd64
            goos: darwin
          - goarch: arm64
            goos: linux
          - goarch: arm64
            goos: darwin
    steps:
    - uses: actions/checkout@master
    - name: Set up Go
      uses: actions/setup-go@v2
      with: 
        go-version: 1.16
    - name: Making kubectl-karmada
      run: make kubectl-karmada
      env:
        GOOS: ${{ matrix.goos }}
        GOARCH: ${{ matrix.goarch }}

这里针对 arm64、amd64 和 Linux、Darwin 的组合进行了交叉编译：

使用 checkout@master 获取代码
setup-go@v2 设置 golang 环境，并在 with 字句中指定了 1.16 版本
make 这里使用了 Matrix 定义的变量，循环构建每个组合；

打包上传

完成构建之后，对生成的文件进行打包，并进行上传：

    - name: Packaging...
      run: tar czf kubectl-karmada-${{ matrix.goos }}-${{ matrix.goarch }}.tgz kubectl-karmada LICENSE
    - name: Uploading assets...
      if: ${{ !env.ACT }}
      id: upload-release-asset 
      uses: actions/upload-release-asset@v1
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        upload_url: ${{ github.event.release.upload_url }}
        asset_path: ./kubectl-karmada-${{ matrix.goos }}-${{ matrix.goarch }}.tgz
        asset_name: kubectl-karmada-${{ matrix.goos }}-${{ matrix.goarch }}.tgz
        asset_content_type: application/gzip

上传这里用 actions/upload-release-asset@v1 镜像来完成任务。其中用到的事件变量为 github.event.release.upload_url，代表触发事件的 Release 的上传地址。

本地调试

上面的构建过程中有个执行条件 if: ${{ !env.ACT }}，环境变量中不存在 ACT 的时候才执行这个步骤，这个定义是用来做什么的？

Action 比较复杂的时候，调试就成了难题。要做线上操作，才能生成 Github 事件，才能触发 Action，这个过程的效率明显是很难提高的。nektos/act 就能部分地解决这个问题。Act 使用 Docker 环境模拟 Github 的运行环境，能够方便地在本地进行调试，能够减少很多对 Github 远程环境的操作。下面简单地试用一下。

在 Mac 下面可以用 brew install act 进行安装；Linux 下，则可以在命令行中输入 curl https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash。注意前面说到，Act 是依赖 Docker 的，使用之前必须安装 Docker。

输入 act --help 能看到命令的帮助内容，其中有几个重要的选项：

-n：Dry run，用于校验语法，查看基本运行逻辑；
-j：直接指定触发 Job；
g：图形化的方式来展示 Action 的流程；

-e：可以编写一个 JSON 文件来描述 Github 事件，例如一个 PR：

{
  "pull_request": {
    "head": {
      "ref": "sample-head-ref"
    },
    "base": {
      "ref": "sample-base-ref"
    }
  }
}

综上，假设我们的任务命名为 release，就可以用 act -j release-assests 进行测试了：

$ act -j release-assests
[Build Release/release linux/amd64-3] 🧪  Matrix: map[goarch:arm64 goos:linux]
[Build Release/release linux/amd64-2] 🧪  Matrix: map[goarch:amd64 goos:darwin]
[Build Release/release linux/amd64-2] 🚀  Start image=catthehacker/ubuntu:act-latest
...
[Build Release/release linux/amd64-4] ⭐  Run Packaging...
[Build Release/release linux/amd64-4]   🐳  docker exec cmd=[bash --noprofile --norc -e -o pipefail /Users/dustise/Dropbox/Synced/lab/karmada/source/workflow/3] user=
[Build Release/release linux/amd64-1]   ✅  Success - Packaging...
[Build Release/release linux/amd64-4]   ✅  Success - Packaging...

本地运行通过后，可以 Push 代码，创建 Release 来测试上传结果。

附录

Github Action Reference：https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions

用 Volcano 填补私有集群的空闲时间

Tue, 07 Sep 2021 18:41:55 +0800

引子

在私有 Kubernetes 场景下，因为硬件规模是一定的，不太会随着业务高峰低谷进行裁撤，因此缩减下来的服务资源并不能带来成本上的优势，如果在闲时~~~挖挖矿~~~跑跑 AI 大数据什么的是不是可以贴补一下家用呢？Volcano 值得一试。

Volcano（https://volcano.sh/zh/）是“一个用于高性能工作负载场景下基于Kubernetes 的容器批量调度引擎”，项目主页上罗列了为数众多的应用案例和适配的 AI、大数据平台。

它提供了Kubernetes目前缺少的一套机制，这些机制通常是许多高性能工作负载所必需的，包括：

机器学习/深度学习

生物学计算/基因计算

大数据应用这些类型的应用程序通常运行在像 Tensorflow、Spark、PyTorch、 MPI 等通用领域框架上，Volcano 无缝对接这些框架。

场景

假设这样一种场景，忙时会占用集群 60% 的 CPU 资源，而闲时则只需要一半，我们需要这样一个能力：

闲时自动启动任务
多个任务排队完成
如果主业务启动，则自行停止队列任务

使用 Volcano，简单的几个 YAML 就能完成任务。

部署

可以用 YAML 直接部署 Volcano，K8s 版本要求在 1.13-1.21 之间（1.22 因为 CRD 资源组升级为 v1，需要进行一些修改才能部署），部署文件如下：

x86_64：https://raw.githubusercontent.com/volcano-sh/volcano/master/installer/volcano-development.yaml
arm64：https://raw.githubusercontent.com/volcano-sh/volcano/master/installer/volcano-development-arm64.yaml

部署之后，会生成若干 CRD，以及一个 volcano-system 命名空间，其中包含 Volcano 的工作负载。

启动工作负载

我用了一个单节点 Kubernetes 集群，剩余可用资源刚好 1 CPU：

$ kubectl describe node single | grep -E "^\s+cpu\s+"
  cpu                1 (50%)     0 (0%)

创建一个 Deployment，为方便控制，我们使用两个占用 300m CPU 的实例（源码见附录 workload.yaml）：

$ kubectl apply -f workload.yaml
deployment.apps/sleep created
$ kubectl describe node single | grep -E "^\s+cpu\s+"
  cpu                1600m (80%)  600m (30%)

可以看到，CPU Request 已经上升至 80%。

创建 Volcano 队列

源码见附录 queue.yaml，创建之后查看其状态：

$ kubectl apply -f queue.yaml
queue.scheduling.volcano.sh/q800 created
$ kubectl describe queue q800
...
Spec:
  Capability:
    Cpu:        800m
  Reclaimable:  false
  Weight:       1
Status:
  State:  Open

上面结果表明，创建了一个 CPU 容量为 800m 且状态开放的队列。

创建 Valcano 任务

在创建任务之前，我们首先要给 Volcano 和工作负载分别创建一个 PriorityClass：

apiVersion: scheduling.k8s.io/v1
description: Used for volcano jobs
kind: PriorityClass
metadata:
  name: volcano-task
preemptionPolicy: PreemptLowerPriority
value: -1
---
apiVersion: scheduling.k8s.io/v1
description: Used for workloads
kind: PriorityClass
metadata:
  name: workload-task
preemptionPolicy: PreemptLowerPriority
value: 1

没有标明 PriorityClass 的 Pod ，其缺省优先级为 0，所以使用 -1 优先级的 Pod 就属于人见人踩的小角色了。而 workload-task 声明的 PreemptLowerPriority 策略，会在调度过程中抢占低优先级任务的资源。

接下来定义一个 Volcano 任务，源码见 job1.yaml，定义其优先级为刚刚创建的 volcano-task。这个 Job 配置最小可用副本为 2，和 Deployment 的定义类似，必须有两个 Pod 全部启动。

$ kubectl apply -f job.yaml
job.batch.volcano.sh/jobb created

查看各种对象：

$ vcctl job list
Name   Creation       Phase       JobType     Replicas    Min   Pending   Running   Succeeded   Failed    Unknown     RetryCount
jobb   2021-09-09     Pending     Batch       2           2     2         0         0           0         0           0
$ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
jobb-sleep-0             0/1     Pending   0          7s
jobb-sleep-1             0/1     Pending   0          7s
sleep-6458fc8f96-qr6s6   1/1     Running   0          14m
sleep-6458fc8f96-tmf9k   1/1     Running   0          14m

看到任务和 Pod 都处于 Pending 状态，查看 Pod 的状态，会发现 Pending 原因是：

$ kubectl describe po jobb-sleep-0
...
Warning  FailedScheduling  8m22s  volcano  all nodes are unavailable: 1 node(s) resource fit failed.

因为资源不足，导致任务被挂起，这是我们期待的效果。

工作负载扩缩容

假设闲时工作负载资源需求降低 50%，看看会发生什么：

$ kubectl scale deployment sleep --replicas=1
deployment.apps/sleep scaled
$ vcctl job list
Name   Creation       Phase       JobType     Replicas    Min   Pending   Running   Succeeded   Failed    Unknown     RetryCount
jobb   2021-09-09     Running     Batch       2           2     0         2         0           0         0           0

此时看到队列中的 Job 已经启动运行。

如果工作负载开始增加，优先级就会发生作用了：

dustise:mine/ $ kubectl scale deployment sleep --replicas=2                                                               [15:15:25]
deployment.apps/sleep scaled
dustise:mine/ $ kubectl get pods                                                                                          [15:15:29]
NAME                     READY   STATUS        RESTARTS   AGE
jobb-sleep-0             0/1     Pending   0          4m17s
jobb-sleep-1             0/1     Pending   0          4m17s
sleep-7f67d6c47c-5cp7s   1/1     Running   0          5m12s
sleep-7f67d6c47c-jrsqh   1/1     Running   0          4m29s

可以看到 jobb 已经退回 Pending 状态，任务回到排队状态。

$ vcctl queue list
Name                     Weight  State   Inqueue Pending Running
...
q800                     1       Open    1       0       0       0

后记

也不知道 Volcano 啥时候弄个挖矿调度器。。

源码

workload.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: sleep
  name: sleep
spec:
  replicas: 2
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      containers:
      - image: dustise/sleep:v0.9.8
        name: sleep
        resources:
          requests:
            cpu: 300m
          limits:
            cpu: 300m

job1.yaml

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: jobb
spec:
  minAvailable: 2
  schedulerName: volcano
  queue: q800
  priorityClassName: volcano-task
  policies:
    - event: PodEvicted
      action: RestartJob
  tasks:
    - replicas: 2
      name: sleep
      policies:
      - event: TaskCompleted
        action: CompleteJob
      template:
        spec:
          containers:
          - image: dustise/sleep:v0.9.8
            name: sleep
            resources:
              requests:
                cpu: 300m
              limits:
                cpu: 300m
            restartPolicy: Never

queue.yaml

apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: q800
spec:
  weight: 1
  reclaimable: false
  capability:
    cpu: 800m

（空想场景）使用 Prometheus 监控特定日志行数

Wed, 11 Aug 2021 20:06:06 +0800

感谢 @云原生小白提供线索

在系统的监控过程中，有时我们只是想要知道一些特定内容的出现数量或者频度，并不关心他的具体内容，而且也不想特意部署一个 Loki 或者 Elasticsearch，这时就可以使用 Fluentd 花里胡哨的插件功能来完成任务了。

Fluentd 有一个 Prometheus 插件，能够提供 Prometheus 接口提供采集数据，插件需要用 fluent-gem 进行安装，如果在 Docker 中的话，可以使用下列 Dockerfile：

FROM fluentd:v1.9.1-1.0
USER root
RUN fluent-gem install fluent-plugin-prometheus
USER fluent

这个插件的基本配置方式是，提供一个 promethues 的类型，包含一个 <metric> 元素用于对指标结构进行定义。例如文档中使用的：

  @type prometheus
  <metric>
    name fluentd_input_status_num_records_total
    type counter
    desc The total number of incoming records
    <labels>
      tag ${tag}
      hostname ${hostname}
    </labels>
  </metric>

这种指标放在 <filter> 用于指示输入数量，而放在 <match> 中则可以监控输出数量。

这里定义了一个名为 fluentd_input_status_num_records_total 的指标，其类型为 counter。

定义指标之后，还要将其暴露给 Prometheus：

<source>
  @type prometheus
  bind 0.0.0.0
  port 24231
  metrics_path /metrics
</source>

这段配置定义了一个监听 24231 端口的 Prometheus 端点，路径为 /metrics。

举个栗子

接下来用一个完整场景来展示这个例子，假设我们要监控 /logs/input.txt 中的 warning 数量，会采用文末的完整配置，分段解释如下：

<source> 段定义采集文件名称
第一个 <filter> 中使用 @type promethues 来监控输入数量，生成指标 fluentd_input_status_num_records_total，类型为 counter
第二个 <filter> 用 @type grep 的正则表达式插件对输入进行过滤
<match> 节中使用 @type copy 对输出进行分流
第一个 <store> 输出 fluentd_output_status_num_records_total 的 Promethues 指标，对过滤出来的文本进行计数
第二个 <store> 将输出内容展示在 stdout

配置结束之后启动采集过程，可以使用类似如下脚本：

#!/bin/sh
docker run -it --rm \
        -v $(pwd)/etc:/etc/fluentd \
        -v $(pwd)/log:/data \
        -p 12345:12345 \
        fluentd:prom \
        fluentd -c /etc/fluentd/fluentd.conf

启动之后，我们向日志中输出内容，例如 echo "warn" >> input.txt，会看到 fluentd 日志输出了类似 2021-08-14 07:06:55.688191458 +0000 custom.log: {"message":"warn"} 的内容，如果使用 curl 访问开放出来的 :12345/metrics，会看到输出中的如下内容：

fluentd_input_status_num_records_total{tag="custom.log",hostname="757214c8a91a"} 2.0      │➜  log  vim fluentd.conf
fluentd_output_status_num_records_total{tag="custom.log",hostname="757214c8a91a"} 1.0

这是很常见的指标格式，如果在 Kubernetes 中，对 Pod 进行注解，纳入采集范围，就可以像其它监控指标一样使用了。

fluentd.conf

<source>
  @type tail
  path /data/input.txt
  pos_file /data/input.pos
  tag custom.log
  <parse>
    @type none
  </parse>
</source>
<filter custom.**>
  @type prometheus
  <metric>
    name fluentd_input_status_num_records_total
    type counter
    desc The total number of incoming records
    <labels>
      tag ${tag}
      hostname ${hostname}
    </labels>
  </metric>
</filter>
<filter custom.**>
  @type grep
  <regexp>
    key message
    pattern /warn/
  </regexp>
</filter>
<match custom.**>
  @type copy
  <store>
    @type prometheus
    <metric>
      name fluentd_output_status_num_records_total
      type counter
      desc The total number of outgoing records
      <labels>
        tag ${tag}
        hostname ${hostname}
      </labels>
    </metric>
  </store>
  <store>
    @type stdout
</match>

<source>
  @type prometheus
  bind 0.0.0.0
  port 12345
  metrics_path /metrics
</source>

<source>
  @type prometheus_output_monitor
  interval 10
  <labels>
    hostname ${hostname}
  </labels>
</source>

关于账号的一点闲话

Sun, 08 Aug 2021 20:15:03 +0800

“你想想，我们厂是造火箭的，造个电动车还不是…”，试驾时，销售小哥如是说，虽说并不认同，不过我既不会造车、也不会造火箭，并不具备一击制敌的能力，所以也没把嘴边的一句“隔行如隔山”喷出来。

交了定金、登记资料之后，销售小哥告诉我可以用账号登录 App，绑定微信公众号来查看交付过程了，问题来了。

早前曾经好奇注册过一个英文版火箭厂的账号（下简称 A），前些天预约试驾尝试登录的时候就发现，在中文版登录时，网站会显示“登录失败无法使用您提供的信息登录。请重试。”，登录 App 的时候也有一个莫名其妙的异常码，我当时并未在意——毕竟账号是给车主服务的嘛，非车主别给人添乱吧。然而签约后我发现情况有点尴尬了。订单已经连到了 A 账号的邮箱，但是 A 账号可能因为属地原因，无法绑定到微信号上。当时我很聪明地想到了一个对策——修改 A 账号的邮箱到我的 QQ 邮箱，释放主力邮箱之后，再用主邮箱注册国内账号，不就结了吗？让人懊恼的是——国内网站还是提示 A 邮箱已经被注册。被逼无奈，只好启用了一个域名邮箱重新注册，方才在国内注册成功了（下文简称为 B）。

然而前面提到，订单已经关联到了 A 邮箱，所以现在的情况就很有意思了，用 A 账号打开 App，会看到订单信息，但是 A 账号无法关联公众号，并不知道在国内还会遭遇什么奇怪的情况；用 B 账号呢，就需要把已有订单重新关联到新的邮箱上。

这个体验是非常古怪和不方便的，我想没人会愿意把新鲜热辣的订单绑到一个无法使用的账号上，那么问题出在哪里呢？

首先邮箱信息是很关键的，它在全球范围内保障了账户的唯一性，然而极其流畅签约过程中，对这个重要数据的可用性并没有进行确认。整个购买过程中并没有对这个重要数据进行确认，目前为止我的邮箱里仅收到过密码复位以及满意度调查。

可能有的读者会问，买其他车也不需要验证这些玩意，是不是苛责太过了？我也反思了这个问题，追究这个问题的原因是，账号在这个厂牌的服务和驾驶体系里有非常重要的作用，不掰扯清楚是很难放心用车的。

其次是异常反馈的问题，前面提到，在切换站点过程中，实际上已经出现了异常信息，然而这些机器码对客户完全没有价值，推测在其业务日志中也没得到反馈，因此这个残缺的数据一直能够残缺地存在，一直到签约一刻才原形毕露。

再次有个小问题，全局被锁定的邮箱，在更改邮箱之后还没有被释放，所以无法复用。

最后的问题就复杂了，账号全球一致，无法分区登录，但是订单又变成全球绑定。所以让人产生一种疑惑，这数据到底是全国还是全球？

感觉此处应该插入一个 DDD 培训的广告，虽然它可能解决不了问题，但是至少能让你讲出更神奇的故事。

所以说，隔行如隔山，对大厂和技术偶像的崇拜应该点到为止，谁都没办法吞食天地。

实名反对 PodSecurity Admission

Fri, 06 Aug 2021 14:53:47 +0800

Kubernetes 1.22 中加入了一个新的功能叫 PodSecurity admission，据称是一个 PSP 的替代方案，于是我就“抱着试一试的态度”，第一时间体验了一下。

这个新功能的思路很直白，把 Pod/Container SecurityContext 的限制分为了三组，分别命名为 Privileged、Baseline 以及 Restricted，顾名思义，这三个级别代表着特权、普通以及严格管理三种对策。用法还是很简单的，只要给要控制的命名空间或者 Pod 打上标签即可。可用的标签列表如下：

pod-security.kubernetes.io/enforce: <policy level>
pod-security.kubernetes.io/enforce-version: <policy version>
pod-security.kubernetes.io/audit: <policy level>
pod-security.kubernetes.io/audit-version: <policy version>
pod-security.kubernetes.io/warn: <policy level>
pod-security.kubernetes.io/warn-version: <policy version>

其中的规定动作包括：

enforce ：仅允许创建符合该策略的 Pod 被创建，不合乎要求的 Pod 会被拒绝；
audit ：可以创建违规 Pod，但是会出现在审计日志中；
warn：可以创建违规 Pod，但是会在客户端返回警告信息。

而版本是跟随 Kubernetes 的，例如 1.22 或者 latest。

需要注意的是，多数情况下 Pod 都是用模板创建的，为了尽早发现问题，audit 和 warn 都是可以针对 Deployment 之类的控制器生效的，而 enforce 仅对 Pod 有效。

举个栗子

首先用 Kind 部署一个测试集群，使用如下的配置文件：

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
featureGates:
  "PodSecurity": true
nodes:
- role: control-plane
  image: kindest/node:v1.22.0
- role: control-plane
  image: kindest/node:v1.22.0
- role: control-plane
  image: kindest/node:v1.22.0
- role: worker
  image: kindest/node:v1.22.0

这里使用 "PodSecurity": true 启用该功能。创建集群并载入镜像：

$ kind create cluster --config 122.yaml
 ✓ Ensuring node image (kindest/node:v1.22.0) 🖼
 ✓ Preparing nodes 📦 📦 📦 📦
 ✓ Configuring the external load balancer ⚖️
 ✓ Writing configuration 📜
...
$ kind load docker-image dustise/sleep:v0.9.7
Image: "dustise/sleep:v0.9.7" with ID "sha256:cd6cdf0ece4664dcbc10cb98273799a0e4a0e0c2145bf36bb7031915c0ab04df" not yet present on node "kind-control-plane2", loading...

集群生成完毕之后，新建几个命名空间用来测试：

$ kubectl create ns dev
namespace/dev created
$ kubectl create ns stage
namespace/stage created
$ kubectl create ns prod
namespace/prod created

给三个命名空间分别打上标签：

$ kubectl label ns dev pod-security.kubernetes.io/warn=restricted
namespace/dev labeled
$ kubectl label ns stage pod-security.kubernetes.io/audit=restricted
namespace/stage labeled
$ kubectl label ns prod pod-security.kubernetes.io/enforce=restricted
namespace/prod labeled

接下来在每个命名空间创建 Deployment，看看会发生什么：

$ kubectl create deployment sleep --image=dustise/sleep:v0.9.7 -n prod
deployment.apps/sleep created

$ kubectl get pods -n prod
No resources found in prod namespace.

$ kubectl get events -n prod
...
Error creating: allowPrivilegeEscalation != false (container "sleep" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "sleep" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "sleep" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "sleep" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
...

可以看到，Deployment 成功创建，然而却没有 Pod 出现，查看事件会看到其创建过程被拒绝。

再去 Dev 命名空间看一下：

kubectl create deployment sleep --image=dustise/sleep:v0.9.7 -n dev
Warning: would violate "latest" version of "restricted" PodSecurity profile: allowPrivilegeEscalation != false (container "sleep" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "sleep" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "sleep" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "sleep" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
deployment.apps/sleep created

会看到直接返回告警信息，但是 Pod 还是建立起来了。

后记

这个新功能在我看来有些尴尬，每个类别的策略都是隐藏在预配置之中的，要想创建符合其要求的 Pod 可能会费点力气，用 CI 或者 Kyverno 辅助创建可能会更好。

数据包在 Kubernetes 中的一生（4）

Tue, 22 Jun 2021 12:43:08 +0800

原文：Life of a Packet in Kubernetes — Part 4

作者：Dinesh Kumar Ramasamy

本篇内容会跟进 Kubernetes 的 Ingress 和 Ingress 控制器。Ingress 控制器会关注 API Server 中 Ingress 对象的更新，并据此配置 Ingress 的负载均衡。

Nginx 控制器和负载均衡/代理服务器

Ingress 控制器一般会是一个以 Pod 形式运行在 Kubernetes 集群中的应用，它会根据集群中的 Ingress 对象的变化对负载均衡器进行配置。这里说的负载均衡器可以是一个集群内运行的软件，也可以是一个硬件，还可以是集群外部运行在云基础设施中。不同的负载均衡器需要不同的 Ingress 控制器。

Ingress 的基本目标是提供一个相对高级的流量（尤其是 http(s)）管理能力。使用 Ingress 可以在无需创建多个负载均衡或者对外开放多个 Service 的条件下，为服务流量进行路由。可以给服务配置外部 URL、进行负载均衡、终结 SSL 以及根据主机名或者内容进行路由等。

配置选项

在把 Ingress 对象转换为负载均衡配置之前，Kubernetes Ingress 控制器会用 Ingress Class 对 Kubernetes 的 Ingress 对象进行过滤。这样就允许多个 Ingress 控制器共存，各司其职。

基于前缀

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: prefix-based
  annotations:
    kubernetes.io/ingress.class: "nginx-ingress-inst-1"
spec:
  rules:
  - http:
      paths:
      - path: /video
        pathType: Prefix
        backend:
          service:
            name: video
            port:
              number: 80
      - path: /store
        pathType: Prefix
        backend:
          service:
            name: store
            port:
              number: 80

基于主机

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: host-based
  annotations:
    kubernetes.io/ingress.class: "nginx-ingress-inst-1"
spec:
  rules:
  - host: "video.example.com"
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: video
            port:
              number: 80
  - host: "store.example.com"
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: store
            port:
              number: 80

主机加前缀

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: host-prefix-based
  annotations:
    kubernetes.io/ingress.class: "nginx-ingress-inst-1"
spec:
  rules:
  - host: foo.com
    http:
      paths:
      - backend:
          serviceName: foovideo
          servicePort: 80
        path: /video
      - backend:
          serviceName: foostore
          servicePort: 80
        path: /store
  - host: bar.com
    http:
      paths:
      - backend:
          serviceName: barvideo
          servicePort: 80
        path: /video
      - backend:
          serviceName: barstore
          servicePort: 80
        path: /store

Ingress 是一个内置 API 对象，但是 Kubernetes 并没有内置任何 Ingress 控制器，需要另行安装控制器才能真正地使用 Ingress。Ingress 功能是由 API 对象和控制器协同完成的。Ingress 对象负责描述集群中 Service 对象的开放需求。而控制器则负责真正的实现 Ingress API，根据 Ingress 对象的定义内容来完成实际工作。市面上有很多不同的 Ingress 控制器，需要根据实际用例谨慎地进行选择使用。

同一集群里可以有多个 Ingress 控制器，并为每个 Ingress 直接指派具体的控制器，在同一个集群中可以根据不同需要为不同服务配置不同的 Ingress。例如某服务用于一个 Ingress 处理来自集群外的 SSL 流量，另外一个用于处理集群内的明文通信。

部署选项

Contour + Envoy

Contour Ingress 控制器由两部分组成：

Envoy 提供了高性能的反向代理服务；
Contour 负责对 Envoy 进行管理，为其下发配置。

这些容器是各自部署的，Contour 是一个 Deployment，而 Envoy 则是一个 Daemonset，当然也可以用其他模式进行部署。Contour 是 Kubernetes API 的客户端，会跟踪 Ingress、HTTPProxy、Secret、Service 以及 Endpoint 对象，并承担管理 Envoy 的职责，它会把它的对象缓存转换为 Envoy 的 JSON 报文，Service 转换为 CDS、Ingress 转为 RDS、Endpoint 转换为 EDS 等。

下面的例子展示了启用 Host Network 的 EnvoyProxy：

Nginx

Nginx Ingress 控制器的主要能力之一就是生成配置文件（nginx.conf）。这个实现还有个需要就是在配置发生变化之后重载 Nginx。在只有 upstream 发生变化时（例如部署调整时产生的 Endpoint 变化）不会进行重载，而是通过 lua-nginx-module 完成任务。

每次 Endpoint 发生变动，控制器会从所有服务中拉取 Endpoint，生成对应的后端对象。这些对象会被发送给 Nginx 中运行的 Lua 处理器。Lua 代码会把这些对象保存到共享内存区域。每次 balancer_by_lua 都会检查一下 upstream 中的有效节点，以此为目标按照预配置的算法进行负载均衡。如果在一个较大的集群中有比较频繁的发布行为，这种避免重载的方式能够大幅减少重载次数，从而更好地保障了响应的延迟时间，达成较高的负载均衡水平。

Nginx+ Keepalived —— 高可用部署

Keepalived 守护进程可以监控服务或者系统，如果发现问题，能够进行自动的切换。配置一个能在节点之间转移的浮动 IP。如果节点宕机，浮动 IP 会自动漂移到其它节点，Nginx 可以绑定到新的 IP 地址。

MetalLB —— 面向具备少量公有 IP 池的私有集群的负载均衡服务

部署到 Kubernetes 中的 MetalLB 为集群提供了一个负载均衡的实现。简单说来，MetalLB 能够在非公有云 Kubernetes 环境中对 LoadBalancer 类型的 Service 提供支持。在托管 Kubernetes 环境中，申请一个负载均衡之后，云平台会给这个新的负载均衡分配 IP；MetalLB 可以负责这个分配过程。MetalLB 给 Service 分配外部 IP 之后，需要声明该 IP 属于本集群，它使用标准路由协议来完成这一任务：ARP、NDP 或 BGP。

在 2 层模式中，集群的一个节点获取这个 Service 的所有权，然后使用标准的地址发现协议（IPv4 使用 ARP、IPv6 使用 NDP）在本地网中让次 IP 可达。从局域网的角度来看，这个节点只是多了一个 IP 地址。

在 BGP 模式中，集群中的所有节点都会对附近的路由器发起 BGP 对等会话，告知路由器如何将流量转发给这些服务。BGP 的策略机制有细粒度的流量控制能力，能真正地在多个节点之间进行负载均衡。

MetalLB 的 Pod：

Controller（Deployment）是集群级的 MetalLB 控制器，负责 IP 分配。
Speaker（Daemonset）在每个节点上运行，使用多种发布策略公告服务和外部 IP 的对应关系。

MetalLB 能够用在集群里的任何 LoadBalancer 类型的 Service 中，但是 MetalLB 为大型 IP 地址池工作就不太现实了。

数据包在 Kubernetes 中的一生（3）

Sun, 20 Jun 2021 10:06:21 +0800

原文：Life of a Packet in Kubernetes — Part 3

作者：Dinesh Kumar Ramasamy

本章我们会讨论一下 Kubernetes 的 kube-proxy 是如何使用 iptables 控制流量的。注意，kube-proxy + iptables 的组合并非完成该任务的唯一选择。

我们会从 Kubernetes 的多种通信模型和实现开始，如果读者已经了解了 Service、ClusterIP 以及 NodePort 的概念，可以直接跳到 kube-proxy/iptables 一节。

Pod 到 Pod

CNI 会配置节点和 Pod 的路由，kube-proxy 不会介入 Pod 到 Pod 之间的通信过程。所有的容器都无需 NAT 就能互相通信；节点和容器之间的通信也是无需 NAT 的。

Pod 的 IP 地址是不固定的（也有办法做成静态 IP，但是缺省配置是不提供这种保障的）。在 Pod 重启时 CNI 会给他分配新的 IP 地址，CNI 不负责维护 IP 地址和 Pod 的映射。Pod 名称在 Deployment 之中也是不固定的。

Deployment 中的 Pod 是无状态的，一个应用可能会有多个 Pod 副本，因此需要一个负载均衡之类的东西来负责对外开放服务，Kubernetes 中的 Service 对象负责完成这个任务。

Pod 到外部

Kubernetes 会使用 SNAT 完成从 Pod 向外发出的访问。SNAT 会将 Pod 的内部 IP:Port 替换为主机的 IP:Port。返回数据包到达节点时，IP:Port 又会换回 Pod。这个过程对于原始 Pod 是透明无感知的。

Pod 到 Service

Cluster IP

Kubernetes 有一个叫做 Service 的对象，是一个通向 Pod 的 4 层负载均衡。Service 对象有很多类型，最基本的类型叫做 ClusterIP，这种类型的 Service 有一个唯一的 VIP 地址，其路由范围仅在集群内部有效。

Kubernetes 集群中，Pod 可能发生移动、重启、升级或者扩缩容，因此向应用 Pod 发送流量是有困难的，另外应用通常有多个副本，我们需要一些方法来进行负载均衡。

Kubernetes 使用 Service 对象来解决这个问题。Service 是一个 API 对象，它用一个虚拟 IP 映射到一组 Pod。另外 Kubernetes 为每个 Service 的名称及其虚拟 IP 建立了 DNS 记录，因此可以轻松地根据名称进行寻址。

虚拟 IP 到 Pod IP 的转换是通过每个节点上的 kube-proxy 完成的。在 Pod 向外发起通信时，这个进程会通过 iptables 或者 IPVS 自动把 VIP 转为 Pod IP，每个连接都有跟踪，所以数据包返回时候，地址还能够被正确地转回原样。IPVS 和 iptables 在 VIP 和 Pod IP 之间承担着负载均衡的角色，IPVS 能够提供更多的负载均衡算法。虚拟 IP 并不存在于网络接口上，而是在 iptable 中：

FrontEnd Deployment：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
  labels:
    app: webapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

Backend Deployment：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth
  labels:
    app: auth
spec:
  replicas: 2
  selector:
    matchLabels:
      app: auth
  template:
    metadata:
      labels:
        app: auth
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

Service：

---
apiVersion: v1
kind: Service
metadata:
  name: frontend
  labels:
    app: frontend
spec:
  ports:
  - port: 80
    protocol: TCP
  type: ClusterIP
  selector:
    app: webapp
---
apiVersion: v1
kind: Service
metadata:
  name: backend
  labels:
    app: backend
spec:
  ports:
  - port: 80
    protocol: TCP
  type: ClusterIP
  selector:
    app: auth
...

现在 FrontEnd Pod 能够通过 ClusterIP 或者 DNS 名称来访问 Backend 了。CoreDNS 这样的 DNS 服务器具备 Kubernetes 集群感知的能力，他们会对 Kubernetes API 进行监控，一旦新建了 Service，就会新建对应的 DNS 记录。如果集群中启用的 DNS，所有 Pod 都能够自动的根据 DNS 名称来解析到 Service。

NodePort（外部到 Pod）

在集群内部可以用 DNS 访问 Service。然而 Service 的 IP 是私有的和虚拟的，所以集群外是无法访问的。

试试看从外部访问 frontEnd 的 Pod（此时还没有给 frontEnd 创建 Service）：

Pod IP 是私有的，无法路由。

接下来创建一个 NodePort 类型的 Service 把 FrontEnd 服务开放给外部世界。如果把 type 字段设置为 NodePort，Kubernetes 控制面使用 --service-node-port-range 参数为 NodePort 服务分配了一个端口范围。每个节点都会会把这个端口映射给特定的服务。Service 使用 .spec.ports[*].nodePort 字段来指定该端口：

---
apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  type: NodePort
  selector:
    app: webapp
  ports:
      # By default and for convenience, the `targetPort` is set to the same value as the `port` field.
    - port: 80
      targetPort: 80
      # Optional field
      # By default and for convenience, the Kubernetes control plane will allocate a port from a range (default: 30000-32767)
      nodePort: 31380
...

这样就可以在集群外使用任意节点的 nodePort 来访问服务了。还可以给 nodePort 赋值以指定特定开放端口。这种情况下，为了防止端口冲突，需要自行管理端口，并且指定端口也必须在参数中声明的端口范围之内。

ExternalTrafficPolicy

ExternalTrafficPolicy 字段表明所属 Service 对象会把来自外部的流量路由给本节点还是集群范围内的端点。如果赋值为 Local，会保留客户端源 IP 同时避免 NodePort 类型服务的多余一跳，但是有流量分配不均匀的隐患；如果设置为 Cluster，会抹掉客户端的源 IP，并导致到其它节点的一跳，但会获得相对较好的均衡效果。

Cluster

这是 Kubernetes Service 的缺省 ExternalTrafficPolicy。这个选项会把流量平均分配给该 Service 的所有 Pod 上。

这种策略的一个弱点是会存在不必要的节点间网络跳转。例如在一个节点的 NodePort 上接收到流量时，即使本节点上存在可用 Pod，流量还是可能会随机地把流量路由到另外一个节点上的 Pod，造成不必要的跳转。

在 Cluster 策略下，数据包的流向：

客户端把数据包发送给 node2:31380；
node2 替换源 IP 地址（SNAT）为自己的 IP 地址；
node2 将目标地址替换为 Pod IP；
数据包被路由到 node1 或者 node3，然后到达 Pod；
Pod 的响应返回到 node2；
Pod 的响应返回到客户端。

Local

这种策略中，kube-proxy 只会在存在目标 Pod 的节点上加入 NodePort 的代理规则。API Server 要求只有使用 LoadBalancer 或者 NodePort 类型的 Service 才能够使用这种策略。这是因为 Local 策略只跟外部访问相关。

如果使用了 Local 策略，kube-proxy 只会代理到本地 endpoint 的流量，不会向其它节点转发。如果本地没有相应端点，发送到该节点的流量就会被丢弃，所以数据包中会保留正确的源 IP，可以放心的在数据包处理规则中使用。

---
apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  type: NodePort
  externalTrafficPolicy: Local
  selector:
    app: webapp
  ports:
      # By default and for convenience, the `targetPort` is set to the same value as the `port` field.
    - port: 80
      targetPort: 80
      # Optional field
      # By default and for convenience, the Kubernetes control plane will allocate a port from a range (default: 30000-32767)
      nodePort: 31380
...

Local 策略下的数据包：

客户端发送数据包到 node1:31380，这个端点上存在目标 Pod；
node1 把数据包路由到端点，其中带有正确的源 IP；
因为策略限制，node1 不会把数据包发给 node3；
客户端发送数据包给 node2:31380，该节点上不存在目标 Pod；
数据包被丢弃。

LoadBalancer Service 类型中的 Local 策略

如果在 Google GKE 上使用 Local 策略，由于健康检查的原因，会把不运行对应 Pod 的节点从负载均衡池中剔除，所以不会发生丢弃流量的问题。这种模型对于需要处理大量外部入栈流量，需要避免跨节点跳转从而降低延迟的应用非常有帮助。另外因为不需要进行 SNAT，从而让源 IP 得以保存。然而官方文档声明，这种策略存在不够均衡的短板。

Kube-Proxy（iptable）

Kubernetes 中负责 Service 对象的组件就是 kube-proxy。它在每个节点上运行，为 Pod 和 Service 生成复杂的 iptables 规则，完成所有的过滤和 NAT 工作。如果登录到 Kubernetes 节点上，运行 iptables-save，会看到 Kubernetes 或者其它组件生成的规则。最重要的是 KUBE-SERVICE、KUBE-SVC-* 以及 KUBE-SEP-*：

KUBE-SERVICE 是 Service 包的入口。它负责匹配 IP:Port，并把数据包发给对应的 KUBE-SVC-*。
KUBE-SVC-* 担任负载均衡的角色，会平均分配数据包到 KUBE-SEP-*。每个 KUBE-SVC-* 都有和 Endpoint 同样数量的 KUBE-SEP-*。
KUBE-SEP-* 代表的是 Service 的 EndPoint，它负责的是 DNAT，会把 Service 的 IP:Port 替换为 Pod 的 IP:Port。

Conntrack 会介入 DNAT 过程，使用状态机来跟踪连接状态。为了记住目标地址的变更，并在回包时候进行恢复，这些状态是必须保存的。iptables 还可以根据 conntrack 状态（ctstate）来决定数据包的目标。下面四个 conntrack 状态尤其重要：

NEW：conntrack 对该数据包一无所知，该状态出现在收到 SYN 的时候。
ESTABLISHED：conntrack 知道该数据包属于一个已发布连接，该状态出现于握手完成之后。
RELATED：这个数据包不属于任何连接，但是他是隶属于其它连接的，在 FTP 之类的协议里常用。
INVALID：有问题的数据包，conntrack 不知道如何处理。这种状态是 Kubernetes 问题的常客。

Service 和 Pod 之间的 TCP 连接过程如下：

左侧的客户端 Pod 发送数据包到一个 Service：2.2.2.10:80；
数据包经过客户端节点的 iptables 规则，目标改为 1.1.1.20:80；
服务端 Pod 处理数据包，发送一个响应包到 1.1.1.10；
数据包回到客户端节点，conntrack 认出这个数据包，把源地址改回 2.2.2.10:80；
客户端 Pod 收到响应包。

iptables

在 Linux 操作系统中使用 netfilter 处理防火墙工作。这是一个内核模块，决定是否放行数据包。iptables 是 netfilter 的前端。二者经常被混为一谈。

链

每条链负责一种特定任务。

PREROUTING：决定数据包刚刚进入网络端口时的对策。有几种不同的选择，例如修改数据包（NAT），丢弃数据包或者什么都不做使其通过；
INPUT：其中经常包含一些用于防止恶意行为的严格规则，防止系统遭到入侵。开放或者屏蔽端口的行为就是在这里进行的；
FORWARD：顾名思义，负责数据包的转发。在将服务器作为路由器的时候，就需要在这里完成任务。
OUTPUT：这里负责所有的网络浏览的行为。这里可以限制所有数据包的发送。
POSTROUTING：发生在数据包离开服务器之前，数据包最后的可跟踪位置。

FORWARD 仅在 ip_forward 启用时才有效。所以下面的命令在 Kubernetes 中很重要：

$ sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
$ cat /proc/sys/net/ipv4/ip_forward
1

上面的变更是暂时性的，要持久化这个变更，需要在 /etc/sysctl.conf 中写入 net.ipv4.ip_forward = 1。

表

接下来会讨论 NAT 表，除此之外还有几个：

Filter：缺省表，这里决定是否允许数据包出入本机，因此可以在这里进行屏蔽等操作；
Nat：是网络地址转换的缩写。下面会有例子说明；
Mangle：仅对特定包有用。它的功能是在包出入之前修改包中的内容；
RAW：用于处理原始数据包，主要用在跟踪连接状态，下面有一个放行 SSH 连接的例子。
Security：负责在 Filter 之后保障安全。

Kubernetes 中的 iptables 配置

部署一个 2 副本 Nginx 应用，导出 iptables 规则。

服务类型 NodePort

$ kubectl get svc webapp
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
webapp NodePort 10.103.46.104 <none> 80:31380/TCP 3d13h
$ kubectl get ep webapp 
NAME ENDPOINTS AGE
webapp 10.244.120.102:80,10.244.120.103:80 3d13h

ClusterIP 是一个存在于 iptables 中的虚拟 IP，Kubernetes 会把这个地址存在 CoreDNS 中。

$ kubectl exec -i -t dnsutils -- nslookup webapp.default
Server:  10.96.0.10
Address: 10.96.0.10#53
Name: webapp.default.svc.cluster.local
Address: 10.103.46.104

为了能够进行包过滤和 NAT，Kubernetes 会创建一个 KUBE-SERVICES 链，把所有 PREROUTING 和 OUTPUT 流量转发给 KUBE-SERVICES：

sudo iptables -t nat -L PREROUTING | column -t
Chain            PREROUTING  (policy  ACCEPT)                                                                    
target           prot        opt      source    destination                                                      
cali-PREROUTING  all         --       anywhere  anywhere     /*        cali:6gwbT8clXdHdC1b1  */                 
KUBE-SERVICES    all         --       anywhere  anywhere     /*        kubernetes             service   portals  */
DOCKER           all         --       anywhere  anywhere     ADDRTYPE  match                  dst-type  LOCAL

使用 KUBE-SERVICES 介入包过滤和 NAT 之后，Kubernetes 会监控通向 Service 的流量，并进行 SNAT/DNAT 的处理。在 KUBE-SERVICES 链尾部，会写入另一个链 KUBE-SERVICES，用于处理 NodePort 类型的 Service。

KUBE-SVC-2IRACUALRELARSND 链会处理针对 ClusterIP 的流量，否则的话就会进入 KUBE-NODEPORTS：

$ sudo iptables -t nat -L KUBE-SERVICES | column -t
Chain                      KUBE-SERVICES  (2   references)                                                                                                                                                                             
target                     prot           opt  source          destination                                                                                                                                                             
KUBE-MARK-MASQ             tcp            --   !10.244.0.0/16  10.103.46.104   /*  default/webapp                   cluster  IP          */     tcp   dpt:www                                                                          
KUBE-SVC-2IRACUALRELARSND  tcp            --   anywhere        10.103.46.104   /*  default/webapp                   cluster  IP          */     tcp   dpt:www                                                                                                                                             
KUBE-NODEPORTS             all            --   anywhere        anywhere        /*  kubernetes                       service  nodeports;  NOTE:  this  must        be  the  last  rule  in  this  chain  */  ADDRTYPE  match  dst-type  LOCAL

看看 KUBE-NODEPORTS 的内容：

$ sudo iptables -t nat -L KUBE-NODEPORTS | column -t
Chain                      KUBE-NODEPORTS  (1   references)                                            
target                     prot            opt  source       destination                               
KUBE-MARK-MASQ             tcp             --   anywhere     anywhere     /*  default/webapp  */  tcp  dpt:31380
KUBE-SVC-2IRACUALRELARSND  tcp             --   anywhere     anywhere     /*  default/webapp  */  tcp  dpt:31380

看起来 ClusterIP 和 NodePort 处理过程是一样的，那么看看下面的处理流程：

# statistic  mode  random -> Random load-balancing between endpoints.
$ sudo iptables -t nat -L KUBE-SVC-2IRACUALRELARSND | column -t
Chain                      KUBE-SVC-2IRACUALRELARSND  (2   references)                                                                             
target                     prot                       opt  source       destination                                                                
KUBE-SEP-AO6KYGU752IZFEZ4  all                        --   anywhere     anywhere     /*  default/webapp  */  statistic  mode  random  probability  0.50000000000
KUBE-SEP-PJFBSHHDX4VZAOXM  all                        --   anywhere     anywhere     /*  default/webapp  */

$ sudo iptables -t nat -L KUBE-SEP-AO6KYGU752IZFEZ4 | column -t
Chain           KUBE-SEP-AO6KYGU752IZFEZ4  (1   references)                                               
target          prot                       opt  source          destination                               
KUBE-MARK-MASQ  all                        --   10.244.120.102  anywhere     /*  default/webapp  */       
DNAT            tcp                        --   anywhere        anywhere     /*  default/webapp  */  tcp  to:10.244.120.102:80

$ sudo iptables -t nat -L KUBE-SEP-PJFBSHHDX4VZAOXM | column -t
Chain           KUBE-SEP-PJFBSHHDX4VZAOXM  (1   references)                                               
target          prot                       opt  source          destination                               
KUBE-MARK-MASQ  all                        --   10.244.120.103  anywhere     /*  default/webapp  */       
DNAT            tcp                        --   anywhere        anywhere     /*  default/webapp  */  tcp  to:10.244.120.103:80

$ sudo iptables -t nat -L KUBE-MARK-MASQ | column -t
Chain   KUBE-MARK-MASQ  (24  references)                         
target  prot            opt  source       destination            
MARK    all             --   anywhere     anywhere     MARK  or  0x4000

注意：输出内容已经被精简。

ClusterIP：KUBE-SERVICES → KUBE-SVC-XXX → KUBE-SEP-XXX
NodePort：KUBE-SERVICES → KUBE-NODEPORTS → KUBE-SVC-XXX → KUBE-SEP-XXX

NodePort 服务会有一个 ClusterIP 用于处理内外部通信。

上述规则的可视化表达：

ExtrenalTrafficPolicy: Local

如前文所述，使用 ExtrenalTrafficPolicy: Local 会保留源 IP，并在到达节点上没有 Endpoint 的时候丢弃流量。没有本地 Endpoint 的节点上，iptables 的规则会怎样？

使用 ExtrenalTrafficPolicy: Local 部署 Nginx 服务：

$ kubectl get svc webapp -o wide -o jsonpath={.spec.externalTrafficPolicy}
Local

$ kubectl get svc webapp -o wide
NAME     TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE   SELECTOR
webapp   NodePort   10.111.243.62   <none>        80:30080/TCP   29m   app=webserver

检查一下没有本地 Endpoint 的节点上的 iptables 规则：

$ sudo iptables -t nat -L KUBE-NODEPORTS
Chain KUBE-NODEPORTS (1 references)
target prot opt source destination
KUBE-MARK-MASQ tcp — 127.0.0.0/8 anywhere /* default/webapp */ tcp dpt:30080
KUBE-XLB-2IRACUALRELARSND tcp — anywhere anywhere /* default/webapp */ tcp dpt:30080

再看一下 KUBE-XLB-2IRACUALRELARSND：

$ iptables -t nat -L KUBE-XLB-2IRACUALRELARSND
Chain KUBE-XLB-2IRACUALRELARSND (1 references)
target prot opt source destination
KUBE-SVC-2IRACUALRELARSND all — 10.244.0.0/16 anywhere /* Redirect pods trying to reach external loadbalancer VIP to clusterIP */
KUBE-MARK-MASQ all — anywhere anywhere /* masquerade LOCAL traffic for default/webapp LB IP */ ADDRTYPE match src-type LOCAL
KUBE-SVC-2IRACUALRELARSND all — anywhere anywhere /* route LOCAL traffic for default/webapp LB IP to service chain */ ADDRTYPE match src-type LOCAL
KUBE-MARK-DROP all — anywhere anywhere /* default/webapp has no local endpoints */

这里就会看到，集群级别的流量没什么问题，但是 NodePort 流量会被丢弃。

Headless Service

有的应用并不需要负载均衡和服务 IP。在这种情况下就可以使用 headless Service，只要设置 .spec.clusterIP 为 None 即可。

可以借助这种服务类型和其他服务发现机制协作，无需和 Kubernetes 绑定。kube-proxy 不对这种没有 IP 的服务提供支持，也就没有什么负载均衡和代理之类的能力了。DNS 的配置要根据 Selector 来确定。

有 Selector

定义了 Selector 的 Headless Service，Endpoint 控制器会创建 Endpoint 记录，并修改 DNS 记录来直接返回 Service 后端的 Pod 地址。

$ kubectl get svc webapp-hs
NAME        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
webapp-hs   ClusterIP   None         <none>        80/TCP    24s
$ kubectl get ep webapp-hs
NAME        ENDPOINTS                             AGE
webapp-hs   10.244.120.109:80,10.244.120.110:80   31s

无 Selector

没有定义 Selector 的 Headless Service，也就没有 Endpoint 记录。然而 DNS 系统会尝试配置：

ExternalName 类型的服务，会产生 CNAME 记录；
其他类型则是所有 Endpoint 共享服务名称。

如果外部 IP 被路由到集群节点上，Kubernetes Service 可以用 externalIPs 开放出来。通过 externalIP 进入集群的流量，会被路由到 Service Endpoint 上。externalIPs 不是 Kubernetes 管理的，需要集群管理员自行维护。

网络策略

阅读至此，Kubernetes 网络策略的实现方法已经呼之欲出了——是的，就是 iptables。目前是 CNI 而非 kube-proxy 负责实现网络策略。这部分内容本来应该写在第二篇 Calico 的内容里，然而我认为这里写出来可能更合适。

我们创建三个服务：frontend、backend 和 db。

缺省情况下，Pod 没有任何隔离，会接受任何来源的通信。

想要制定规则，禁止 frontend 访问 db：

这里推荐阅读 Guide to Kubernetes Ingress Network Policies 了解网络策略配置方面的更多内容。本节内容关注的是 Kubernetes 中策略的实现方式，而非配置知识。

创建一个策略把 db 和 frontend 隔离开，这样一来 frontend 和 db 之间的流量就会被阻断。

上图中为了简单起见，写的是 Service 而非 Pod，安全策略的控制对象实际上是 Pod。

策略实施之后会产生如下效果，frontend 的 Pod 能访问 backend 但是无法访问 db。backend 的 Pod 可以访问 db。

$ kubectl exec -it frontend-8b474f47-zdqdv -- /bin/sh
$ curl backend
backend-867fd6dff-mjf92
$ curl db
curl: (7) Failed to connect to db port 80: Connection timed out

$ kubectl exec -it backend-867fd6dff-mjf92 -- /bin/sh
$ curl db
db-8d66ff5f7-bp6kf

看看这里用到的网络策略：只允许 ‘allow-db-access 标签设置为 true 的 Pod 访问 db。

Calico 会把 Kubernetes 网络策略翻译成 Calico 格式：

$ calicoctl get networkPolicy --output yaml
apiVersion: projectcalico.org/v3
items:
- apiVersion: projectcalico.org/v3
  kind: NetworkPolicy
  metadata:
    creationTimestamp: "2020-11-05T05:26:27Z"
    name: knp.default.allow-db-access
    namespace: default
    resourceVersion: /53872
    uid: 1b3eb093-b1a8-4429-a77d-a9a054a6ae90
  spec:
    ingress:
    - action: Allow
      destination: {}
      source:
        selector: projectcalico.org/orchestrator == 'k8s' && networking/allow-db-access
          == 'true'
    order: 1000
    selector: projectcalico.org/orchestrator == 'k8s' && app == 'db'
    types:
    - Ingress
kind: NetworkPolicyList
metadata:
  resourceVersion: 56821/56821

iptables 的 filter 表在网络策略的实现中起了很重要的作用。Calico 中用到了 ipsec 等高级概念，难于进行反向工程。在这个规则中可以看到，只有来自 backend 的流量才被允许发给 db。

使用 calicoctl 获取 endpoint 详情：

$ calicoctl get workloadEndpoint
WORKLOAD                         NODE       NETWORKS        INTERFACE         
backend-867fd6dff-mjf92          minikube   10.88.0.27/32   cali2b1490aa46a   
db-8d66ff5f7-bp6kf               minikube   10.88.0.26/32   cali95aa86cbb2a   
frontend-8b474f47-zdqdv          minikube   10.88.0.24/32   cali505cfbeac50

cali95aa86cbb2a 就是 db Pod veth 的主机侧。

看看跟这个网络接口有关的 iptables 规则：

$ sudo iptables-save | grep cali95aa86cbb2a
:cali-fw-cali95aa86cbb2a - [0:0]
:cali-tw-cali95aa86cbb2a - [0:0]
...
-A cali-tw-cali95aa86cbb2a -m comment --comment "cali:pm-LK-c1ra31tRwz" -m mark --mark 0x0/0x20000 -j cali-pi-_tTE-E7yY40ogArNVgKt
-A cali-tw-cali95aa86cbb2a -m comment --comment "cali:q_zG8dAujKUIBe0Q" -m comment --comment "Return if policy accepted" -m mark --mark 0x10000/0x10000 -j RETURN
-A cali-tw-cali95aa86cbb2a -m comment --comment "cali:FUDVBYh1Yr6tVRgq" -m comment --comment "Drop if no policies passed packet" -m mark --mark 0x0/0x20000 -j DROP
-A cali-tw-cali95aa86cbb2a -m comment --comment "cali:X19Z-Pa0qidaNsMH" -j cali-pri-kns.default
-A cali-tw-cali95aa86cbb2a -m comment --comment "cali:Ljj0xNidsduxDGUb" -m comment --comment "Return if profile accepted" -m mark --mark 0x10000/0x10000 -j RETURN
-A cali-tw-cali95aa86cbb2a -m comment --comment "cali:0z9RRvvZI9Gud0Wv" -j cali-pri-ksa.default.default
-A cali-tw-cali95aa86cbb2a -m comment --comment "cali:pNCpK-SOYelSULC1" -m comment --comment "Return if profile accepted" -m mark --mark 0x10000/0x10000 -j RETURN
-A cali-tw-cali95aa86cbb2a -m comment --comment "cali:sMkvrxvxj13WlTMK" -m comment --comment "Drop if no profiles matched" -j DROP
$ sudo iptables-save -t filter | grep cali-pi-_tTE-E7yY40ogArNVgKt
:cali-pi-_tTE-E7yY40ogArNVgKt - [0:0]
-A cali-pi-_tTE-E7yY40ogArNVgKt -m comment --comment "cali:M4Und37HGrw6jUk8" -m set --match-set cali40s:LrVD8vMIGQDyv8Y7sPFB1Ge src -j MARK --set-xmark 0x10000/0x10000
-A cali-pi-_tTE-E7yY40ogArNVgKt -m comment --comment "cali:sEnlfZagUFRSPRoe" -m mark --mark 0x10000/0x10000 -j RETURN

检查一下 ipset，会看到只有来自 backend pod 的 10.88.0.27 才能访问 db。

数据包在 Kubernetes 中的一生（2）

Thu, 17 Jun 2021 07:10:41 +0800

原文：Life of a Packet in Kubernetes — Part 2

作者：Dinesh Kumar Ramasamy

如前文所述，CNI 插件是 Kubernetes 网络的重要组件。目前有很多第三方 CNI 插件，Calico 就是其中之一，因为它的易用性和网络能力，得到很多工程师的青睐。它支持很多不同的平台，例如 Kubernetes、OpenShift、Docker EE、OpenStack 以及裸金属服务。Calico Node 组件以 Docker 容器的形式运行在 Kubernetes 的所有 Master 和 Node 节点上。Calico-CNI 插件会直接集成到 Kubernetes 每个节点的 Kubelet 进程中，一旦发现了新建的 Pod，就会将其加入 Calico 网络。

下面的内容会涉及安装、Calico 模块（Felix、BIRD 以及 Confd）和路由模式，但是不会包含网络策略方面的内容。

CNI 的任务

创建 veth 对，并移入容器
鉴别正确的 POD CIDR
创建 CNI 配置文件
IP 地址的分配和管理
在容器中加入缺省路由
把路由广播给所有 Peer 节点（不适用于 VxLan）
在主机上加入路由
实施网络策略

其实还有很多别的需求，但是上面几个点是最基础的。看看 Master 和 Worker 节点上的路由表。每个节点都有一个容器，容器有一个 IP 地址和缺省的容器路由。

上面的路由表说明，Pod 能够通过 3 层网络进行互通。什么模块负责添加路由，如何获取远端路由呢？为什么这里缺省网关是 169.254.1.1 呢？我们接下来会讨论这些问题。

Calico 的核心包括 Bird、Felix、ConfD、ETCD 以及 Kubernetes API Server。Calico 需要保存一些配置信息，例如 IP 池、端点信息、网络策略等，数据存储位置是可以配置的，本例中我们使用 Kubernetes 进行存储。

BIRD（BGP）

Bird 是一个 BGP 守护进程，运行在每个节点上，负责相互交换路由信息。通常的拓扑关系是节点之间构成的网格：

然而集群规模较大的时候，就会很麻烦了。可以使用 Route Reflector（部分 BGP 节点能够配置为 Route Reflector）来完成路由的传播工作，从而降低 BGP 连接数量。路由广播会发送给 Route Reflector，再由 Route Reflector 进行传播，更多信息可以参考 RFC4456。

BIRD 实例负责向其它 BIRD 实例传递路由信息。缺省配置方式就是 BGP Mesh，适用于小规模部署。在大规模集群中，建议使用 Route Reflector 来克服这个缺点。可以使用多个 RR 来达成高可用目的，另外还可以使用外部 RR 来替代 BIRD。

ConfD

ConfD 是一个简单的配置管理工具，运行在 Calico Node 容器中。它会从 ETCD 中读取数据（Calico 的 BIRD 配置），并写入磁盘文件。它会循环读取网络和子网，并应用配置数据（CIDR 键），组装为 BIRD 能够使用的配置。这样不管网络如何变化，BIRD 都能够得到通知并在节点之间广播路由。

Felix

Calico Felix 守护进程在 Calico Node 容器中运行，完成如下功能：

从 Kubernetes ETCD 中读取信息
构建路由表
配置 iptables 或者 IPVS

看看集群中所有的 Calico 模块：

是不是有点不同？veth 的一端是“悬空”的，没有连接。

数据包如何被路由到 Peer 节点的？

Master 上的 Pod 尝试 Ping 10.0.2.11
Pod 向网关发送一个 ARP 请求
从 ARP 响应中得到 MAC 地址
但是谁响应的 ARP 请求？

容器是怎样路由到一个不存在的 IP 的？容器的缺省路由指向了 169.254.1.1。容器的 eth0 需要访问这个地址，因此在使用缺省路由的时候会对这个 IP 进行 ARP 查询。

如果能捕获 ARP 响应信息，会发现 veth 另外一侧的（cali123） MAC 地址。所以到底是怎样响应一个没有 IP 接口的 ARP 请求的呢？答案是 proxy-arp，如果我们检查一下主机侧的 veth 接口，会看到启用了 proxy-arp：

$ cat /proc/sys/net/ipv4/conf/cali123/proxy_arp
1

Proxy ARP 技术能用特定网络上的代理设备来响应针对本网络不存在的 IP 地址的 ARP 查询。这个代理知道流量的目标，会以自己的 MAC 地址进行响应。如此一来，流量就转给 Proxy，通常会被 Proxy 使用其它网络接口或者隧道路由到原定目标。这种以自己 MAC 地址响应其他 IP 地址的 ARP 请求，完成代理任务的行为有时也被称为发布。

仔细看看 Worker 节点：

数据包进入内核之后，会根据路由表进行路由。

入栈流量：首先进入Worker 节点内核。内核把数据包发给 cali123。

路由模式

Calico 支持三种路由模式，本节中会对几种模式的优劣和适用场景进行讨论。

IP-in-IP：缺省，有封装行为；
Direct/NoEncapMode：无封包（推荐）；
VxLan：有封包（无 BGP）

IP-in-IP

这是一种简单的对 IP 包进行再封包的方式。传输中的数据包带有一个外层头部，其中描述了源主机和目的 IP，还有一个内层头部，包含源 Pod 和目标 IP。

目前 Azure 还不支持 IP-IP，因此这种环境中无法使用该模式，建议关掉 IP-IP 以提高性能。

NoEncapMode

这种模式下数据包是用 Pod 发出时的原始格式发出来的。因为没有封包和解包的开销，这种模式比较有性能优势。

AWS 中要使用这种模式需要关闭源 IP 校验。

VXLAN

Calico 3.7 以后的版本才支持 VXLAN 路由。

VXLAN 是 Virtual Extensible LAN 的缩写。VXLAN 是一种封包技术，二层数据帧被封装为 UDP 数据包。VXLAN 是一种网络虚拟化技术。当设备在软件定义的数据中心里进行通信时，会在这些设备之间建立 VXLAN 隧道。这些隧道能建立在屋里或虚拟交换机之上。这些交换端口被称为 VXLAN Tunnel Endpoints（VTEPs），负责 VXLAN 的封包和解包工作。不支持 VXLAN 的设备可以连接到 VTEP，由 VTEP 提供 VXLAN 的出入转换工作。

VXLAN 对于不支持 IP-in-IP 的网络非常有用，例如 Azure 或者其它不支持 BGP 的数据中心。

演示—— IPIP 和 UnEncapMode

在没安装 Calico 之前检查一下集群：

$ kubectl get nodes
NAME           STATUS     ROLES    AGE   VERSION
controlplane   NotReady   master   40s   v1.18.0
node01         NotReady   <none>   9s    v1.18.0

$ kubectl get pods --all-namespaces
NAMESPACE     NAME                                   READY   STATUS    RESTARTS   AGE
kube-system   coredns-66bff467f8-52tkd               0/1     Pending   0          32s
kube-system   coredns-66bff467f8-g5gjb               0/1     Pending   0          32s
kube-system   etcd-controlplane                      1/1     Running   0          34s
kube-system   kube-apiserver-controlplane            1/1     Running   0          34s
kube-system   kube-controller-manager-controlplane   1/1     Running   0          34s
kube-system   kube-proxy-b2j4x                       1/1     Running   0          13s
kube-system   kube-proxy-s46lv                       1/1     Running   0          32s
kube-system   kube-scheduler-controlplane            1/1     Running   0          33s

检查 CNI 的二进制文件和目录。其中没有任何配置文件或者 Calico 二进制，Calico 安装过程会用加载卷来填充其中的内容：

$ cd /etc/cni
-bash: cd: /etc/cni: No such file or directory
$ cd /opt/cni/bin
$ ls
bridge  dhcp  flannel  host-device  host-local  ipvlan  loopback  macvlan  portmap  ptp  sample  tuning  vlan

在 Master/Worker 节点上检查 ip route：

$ ip route
default via 172.17.0.1 dev ens3
172.17.0.0/16 dev ens3 proto kernel scope link src 172.17.0.32
172.18.0.0/24 dev docker0 proto kernel scope link src 172.18.0.1 linkdown

在集群环境中下载并提交 calico.yaml：

$ curl https://docs.projectcalico.org/manifests/calico.yaml -O
$ kubectl apply -f calico.yaml

看看其中的配置参数：

cni_network_config: |-
    {
      "name": "k8s-pod-network",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "calico", >>> Calico's CNI plugin
          "log_level": "info",
          "log_file_path": "/var/log/calico/cni/cni.log",
          "datastore_type": "kubernetes",
          "nodename": "__KUBERNETES_NODE_NAME__",
          "mtu": __CNI_MTU__,
          "ipam": {
              "type": "calico-ipam" >>> Calico's IPAM instaed of default IPAM
          },
          "policy": {
              "type": "k8s"
          },
          "kubernetes": {
              "kubeconfig": "__KUBECONFIG_FILEPATH__"
          }
        },
        {
          "type": "portmap",
          "snat": true,
          "capabilities": {"portMappings": true}
        },
        {
          "type": "bandwidth",
          "capabilities": {"bandwidth": true}
        }
      ]
    }
# Enable IPIP
- name: CALICO_IPV4POOL_IPIP
    value: "Always" >> Set this to 'Never' to disable IP-IP
# Enable or Disable VXLAN on the default IP pool.
- name: CALICO_IPV4POOL_VXLAN
    value: "Never"

安装完毕之后，检查 Pod 和节点状态。

$ kubectl get pods --all-namespaces
NAMESPACE     NAME                                       READY   STATUS              RESTARTS   AGE
kube-system   calico-kube-controllers-799fb94867-6qj77   0/1     ContainerCreating   0          21s
kube-system   calico-node-bzttq                          0/1     PodInitializing     0          21s
kube-system   calico-node-r6bwj                          0/1     PodInitializing     0          21s
kube-system   coredns-66bff467f8-52tkd                   0/1     Pending             0          7m5s
kube-system   coredns-66bff467f8-g5gjb                   0/1     ContainerCreating   0          7m5s
kube-system   etcd-controlplane                          1/1     Running             0          7m7s
kube-system   kube-apiserver-controlplane                1/1     Running             0          7m7s
kube-system   kube-controller-manager-controlplane       1/1     Running             0          7m7s
kube-system   kube-proxy-b2j4x                           1/1     Running             0          6m46s
kube-system   kube-proxy-s46lv                           1/1     Running             0          7m5s
kube-system   kube-scheduler-controlplane                1/1     Running             0          7m6s
$ kubectl get nodes
NAME           STATUS   ROLES    AGE     VERSION
controlplane   Ready    master   7m30s   v1.18.0
node01         Ready    <none>   6m59s   v1.18.0

Kubelet 需要 CNI 的配置文件来设置网络：

$ cd /etc/cni/net.d/
$ ls
10-calico.conflist  calico-kubeconfig
$
$
$ cat 10-calico.conflist
{
  "name": "k8s-pod-network",
  "cniVersion": "0.3.1",
  "plugins": [
    {
      "type": "calico",
      "log_level": "info",
      "log_file_path": "/var/log/calico/cni/cni.log",
      "datastore_type": "kubernetes",
      "nodename": "controlplane",
      "mtu": 1440,
      "ipam": {
          "type": "calico-ipam"
      },
      "policy": {
          "type": "k8s"
      },
      "kubernetes": {
          "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
      }
    },
    {
      "type": "portmap",
      "snat": true,
      "capabilities": {"portMappings": true}
    },
    {
      "type": "bandwidth",
      "capabilities": {"bandwidth": true}
    }
  ]
}

检查 CNI 的二进制文件：

$ ls
bandwidth  bridge  calico  calico-ipam dhcp  flannel  host-device  host-local  install  ipvlan  loopback  macvlan  portmap  ptp  sample  tuning  vlan

安装 calicoctl 来获取 Calico 的更多信息并能修改 Calico 配置：

$ cd /usr/local/bin/
$ curl -O -L  https://github.com/projectcalico/calicoctl/releases/download/v3.16.3/calicoctl
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   633  100   633    0     0   3087      0 --:--:-- --:--:-- --:--:--  3087
100 38.4M  100 38.4M    0     0  5072k      0  0:00:07  0:00:07 --:--:-- 4325k
$ chmod +x calicoctl
$ export DATASTORE_TYPE=kubernetes
$ export KUBECONFIG=~/.kube/config
# Check endpoints - it will be empty as we have't deployed any POD
$ calicoctl get workloadendpoints
WORKLOAD   NODE   NETWORKS   INTERFACE

检查 BGP Peer 的状态，会看到 Worker 节点是一个 Peer。

$ calicoctl node status
Calico process is running.
IPv4 BGP status
+--------------+-------------------+-------+----------+-------------+
| PEER ADDRESS |     PEER TYPE     | STATE |  SINCE   |    INFO     |
+--------------+-------------------+-------+----------+-------------+
| 172.17.0.40  | node-to-node mesh | up    | 00:24:04 | Established |
+--------------+-------------------+-------+----------+-------------+

创建一个两副本 Pod，并设置 tolerations，使之可以运行在 Master 节点：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox-deployment
spec:
  selector:
    matchLabels:
      app: busybox
  replicas: 2
  template:
    metadata:
      labels:
        app: busybox
    spec:
      tolerations:
      - key: "node-role.kubernetes.io/master"
        operator: "Exists"
        effect: "NoSchedule"
      containers:
      - name: busybox
        image: busybox
        command: ["sleep"]
        args: ["10000"]

获取 Pod 和端点状态：

$ kubectl get pods -o wide
NAME                                 READY   STATUS    RESTARTS   AGE   IP                NODE           NOMINATED NODE   READINESS GATES
busybox-deployment-8c7dc8548-btnkv   1/1     Running   0          6s    192.168.196.131   node01         <none>           <none>
busybox-deployment-8c7dc8548-x6ljh   1/1     Running   0          6s    192.168.49.66     controlplane   <none>           <none>
$ calicoctl get workloadendpoints
WORKLOAD                             NODE           NETWORKS             INTERFACE
busybox-deployment-8c7dc8548-btnkv   node01         192.168.196.131/32   calib673e730d42
busybox-deployment-8c7dc8548-x6ljh   controlplane   192.168.49.66/32     cali9861acf9f07

获取 Pod 所在主机上的 VETH 信息：

$ ifconfig cali9861acf9f07
cali9861acf9f07: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1440
        inet6 fe80::ecee:eeff:feee:eeee  prefixlen 64  scopeid 0x20<link>
        ether ee:ee:ee:ee:ee:ee  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5  bytes 446 (446.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

获取 Pod 网络界面的信息：

$ kubectl exec busybox-deployment-8c7dc8548-x6ljh -- ifconfig
eth0      Link encap:Ethernet  HWaddr 92:7E:C4:15:B9:82
          inet addr:192.168.49.66  Bcast:192.168.49.66  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1440  Metric:1
          RX packets:5 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:446 (446.0 B)  TX bytes:0 (0.0 B)
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
$ kubectl exec busybox-deployment-8c7dc8548-x6ljh -- ip route
default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0 scope link
$ kubectl exec busybox-deployment-8c7dc8548-x6ljh -- arp

获取主节点路由：

$ ip route
default via 172.17.0.1 dev ens3
172.17.0.0/16 dev ens3 proto kernel scope link src 172.17.0.32
172.18.0.0/24 dev docker0 proto kernel scope link src 172.18.0.1 linkdown
blackhole 192.168.49.64/26 proto bird
192.168.49.65 dev calic22dbe57533 scope link
192.168.49.66 dev cali9861acf9f07 scope link
192.168.196.128/26 via 172.17.0.40 dev tunl0 proto bird onlink

尝试 Ping Worker 节点来触发 ARP：

$ kubectl exec busybox-deployment-8c7dc8548-x6ljh -- ping 192.168.196.131 -c 1
PING 192.168.196.131 (192.168.196.131): 56 data bytes
64 bytes from 192.168.196.131: seq=0 ttl=62 time=0.823 ms
$ kubectl exec busybox-deployment-8c7dc8548-x6ljh -- arp
? (169.254.1.1) at ee:ee:ee:ee:ee:ee [ether]  on eth0

注意上面的 MAC 地址。发出流量时，内核根据 IP 路由将数据包写入 tunl0，Proxy ARP 的配置：

$ cat /proc/sys/net/ipv4/conf/cali9861acf9f07/proxy_arp
1

目标节点如何处理数据包

node01 $ ip route
default via 172.17.0.1 dev ens3
172.17.0.0/16 dev ens3 proto kernel scope link src 172.17.0.40
172.18.0.0/24 dev docker0 proto kernel scope link src 172.18.0.1 linkdown
192.168.49.64/26 via 172.17.0.32 dev tunl0 proto bird onlink
blackhole 192.168.196.128/26 proto bird
192.168.196.129 dev calid4f00d97cb5 scope link
192.168.196.130 dev cali257578b48b6 scope link
192.168.196.131 dev calib673e730d42 scope link

接收到数据包之后，内核会根据路由表将数据包发给对应的 veth。

如果抓包的话会看出 IP-IP 协议。据我所知，Azure 不支持 IP-IP，也就是说我们无法在这种环境里使用 IP-IP。关闭 IP-IP 能获得更高性能，下面一节尝试一下。

禁用 IP-IP

更新 ippool.yaml 设置 IPIP 为 Never，然后用 calicoctl 应用配置：

$ calicoctl get ippool default-ipv4-ippool -o yaml > ippool.yaml
$ vi ippool.yaml
...
$ calicoctl apply -f ippool.yaml
Successfully applied 1 'IPPool' resource(s)

再次检查 ip route：

$ ip route
default via 172.17.0.1 dev ens3
172.17.0.0/16 dev ens3 proto kernel scope link src 172.17.0.32
172.18.0.0/24 dev docker0 proto kernel scope link src 172.18.0.1 linkdown
blackhole 192.168.49.64/26 proto bird
192.168.49.65 dev calic22dbe57533 scope link
192.168.49.66 dev cali9861acf9f07 scope link
192.168.196.128/26 via 172.17.0.40 dev ens3 proto bird

设备不再是 tunl0，而是变成 Master 节点的管理界面（ens3）。

Ping 一下 Worker 节点，验证工作情况，此时不再使用 IPIP 协议：

$ kubectl exec busybox-deployment-8c7dc8548-x6ljh -- ping 192.168.196.131 -c 1
PING 192.168.196.131 (192.168.196.131): 56 data bytes
64 bytes from 192.168.196.131: seq=0 ttl=62 time=0.653 ms
--- 192.168.196.131 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.653/0.653/0.653 ms

注意在 AWS 环境中使用这种模式需要禁用源 IP 检查。

演示 VXLAN

重新进行集群初始化，并下载 calico.yaml 文件，进行如下变更：

从 livenessProbe 和 readinessProbe 中删除 bird：

livenessProbe:
            exec:
              command:
              - /bin/calico-node
              - -felix-live
              - -bird-live >> Remove this
            periodSeconds: 10
            initialDelaySeconds: 10
            failureThreshold: 6
          readinessProbe:
            exec:
              command:
              - /bin/calico-node
              - -felix-ready
              - -bird-ready >> Remove this

把 calico_backend 修改为 vxlan，不再需要 BGP：

kind: ConfigMap
apiVersion: v1
metadata:
  name: calico-config
  namespace: kube-system
data:
  # Typha is disabled.
  typha_service_name: "none"
  # Configure the backend to use.
  calico_backend: "vxlan"

禁用 IPIP：

# Enable IPIP
- name: CALICO_IPV4POOL_IPIP
    value: "Never" >> Set this to 'Never' to disable IP-IP
# Enable or Disable VXLAN on the default IP pool.
- name: CALICO_IPV4POOL_VXLAN
    value: "Never"

应用这个 YAML：

$ ip route
default via 172.17.0.1 dev ens3
172.17.0.0/16 dev ens3 proto kernel scope link src 172.17.0.15
172.18.0.0/24 dev docker0 proto kernel scope link src 172.18.0.1 linkdown
192.168.49.65 dev calif5cc38277c7 scope link
192.168.49.66 dev cali840c047460a scope link
192.168.196.128/26 via 192.168.196.128 dev vxlan.calico onlink
vxlan.calico: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1440
        inet 192.168.196.128  netmask 255.255.255.255  broadcast 192.168.196.128
        inet6 fe80::64aa:99ff:fe2f:dc24  prefixlen 64  scopeid 0x20<link>
        ether 66:aa:99:2f:dc:24  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 11 overruns 0  carrier 0  collisions 0

获取 Pod 状态：

$ kubectl get pods -o wide
NAME                                 READY   STATUS    RESTARTS   AGE   IP                NODE           NOMINATED NODE   READINESS GATES
busybox-deployment-8c7dc8548-8bxnw   1/1     Running   0          11s   192.168.49.67     controlplane   <none>           <none>
busybox-deployment-8c7dc8548-kmxst   1/1     Running   0          11s   192.168.196.130   node01         <none>           <none>

查看 ip route：

$ kubectl exec busybox-deployment-8c7dc8548-8bxnw -- ip route
default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0 scope link

执行 Ping，触发 ARP 查询：

$ kubectl exec busybox-deployment-8c7dc8548-8bxnw -- arp
master $ kubectl exec busybox-deployment-8c7dc8548-8bxnw -- ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=116 time=3.786 ms
^C
$ kubectl exec busybox-deployment-8c7dc8548-8bxnw -- arp
? (169.254.1.1) at ee:ee:ee:ee:ee:ee [ether]  on eth0

概念和前一种模式相似，区别在于数据包抵达 vxland 的时候，会把节点 IP 以及 MAC 地址封装并发送。另外 vxland 的 UDP 端口是 4789。这里会从 etcd 获取可用节点以及节点支持的 IP 范围，从而让 vxlan-calico 据此构建数据包。

VxLan 模式需要更多系统开销

声明

本文未提供任何技术建议和推荐，文中所述皆为个人观点，不代表我所供职的企业。

数据包在 Kubernetes 中的一生（1）

Tue, 15 Jun 2021 22:49:04 +0800

原文：Life of a Packet in Kubernetes — Part 1

作者：Dinesh Kumar Ramasamy

即使是对于具备一定虚拟网络和路由知识的人来说，Kubernetes 集群的网络也是个颇为麻烦的事情。本文尝试帮助读者理解 Kubernetes 网络的基础知识。初期目标是根据一个发往 Kubernetes 集群 Service 的 HTTP 请求的路线，来理解 Kubernetes 网络的复杂性。这中间会涉及到命名空间、CNI 以及 Calico。第一篇会从 Linux 网络开始，后续章节会涉及到其他主题。

Linux 命名空间

Linux 命名空间包含了现代容器中的一些基础技术。从高层来看，这一技术允许把系统资源在进程之间进行隔离。例如 PID 命名空间会会把进程 ID 空间进行隔离，这样同一个主机之中的两个进程就能隔离了。

这个级别的隔离对容器世界来说是很重要的。没有命名空间的话，A 容器中的进程可能会卸载 B 容器中的文件系统，或者修改 C 容器的主机名，又或删除 D 容器的网卡。将这些资源纳入命名空间进行管理，A 容器甚至无法感知 B、C、D 容器的存在。

Mount：隔离文件系统加载点；
UTS：隔离主机名和域名；
IPC：隔离跨进程通信（IPC）资源；
PID：隔离 PID 空间；
网络：隔离网络接口；
用户：隔离 UID/GID 空间；
Cgroup：隔离 cgroup 根目录。

绝大多数容器会使用上述命名空间在容器进程之间进行隔离。要注意 cgroup 命名空间出现较晚，相对其它命名空间来说，用的比较少。

容器网络（网络命名空间）

在进入 CNI 和 Docker 之前，首先看看容器网络的核心技术。Linux 内核有不少多租户方面的功能。命名空间对不同种类的资源进行了隔离，网络命名空间隔离的自然就是网络。

在主流 Linux 操作系统中都可以简单地用 ip 命令创建网络命名空间。接下来创建两个分别用于服务器和客户端的网络命名空间。

$ ip netns add client
$ ip netns add server
$ ip netns list
server
client

创建一对 veth 将命名空间进行连接，可以把 veth 想象为连接两端的网线。

$ ip link add veth-client type veth peer name veth-server
$ ip link list | grep veth
4: veth-server@veth-client: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
5: veth-client@veth-server: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000

这一对 veth 是存在于主机的网络命名空间的，接下来我们把两端分别置入各自的命名空间：

$ ip link set veth-client netns client
$ ip link set veth-server netns server
$ ip link list | grep veth # doesn’t exist on the host network namespace now

从 client 命名空间检查一下命名空间中的 veth 状况：

$ ip netns exec client ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
5: veth-client@if4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether ca:e8:30:2e:f9:d2 brd ff:ff:ff:ff:ff:ff link-netnsid 1

然后是 server 命名空间：

$ ip netns exec server ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
4: veth-server@if5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 42:96:f0:ae:f0:c5 brd ff:ff:ff:ff:ff:ff link-netnsid 0

接下来给这些网络接口分配 IP 地址并启用：

$ ip netns exec client ip address add 10.0.0.11/24 dev veth-client
$ ip netns exec client ip link set veth-client up
$ ip netns exec server ip address add 10.0.0.12/24 dev veth-server
$ ip netns exec server ip link set veth-server up
$
$ ip netns exec client ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
5: veth-client@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ca:e8:30:2e:f9:d2 brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet 10.0.0.11/24 scope global veth-client
       valid_lft forever preferred_lft forever
    inet6 fe80::c8e8:30ff:fe2e:f9d2/64 scope link
       valid_lft forever preferred_lft forever
$
$ ip netns exec server ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
4: veth-server@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 42:96:f0:ae:f0:c5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.0.0.12/24 scope global veth-server
       valid_lft forever preferred_lft forever
    inet6 fe80::4096:f0ff:feae:f0c5/64 scope link
       valid_lft forever preferred_lft forever

在 client 命名空间中使用 ping 命令检查一下两个网络命名空间的连接状况：

$ ip netns exec client ping 10.0.0.12
PING 10.0.0.12 (10.0.0.12) 56(84) bytes of data.
64 bytes from 10.0.0.12: icmp_seq=1 ttl=64 time=0.101 ms
64 bytes from 10.0.0.12: icmp_seq=2 ttl=64 time=0.072 ms
64 bytes from 10.0.0.12: icmp_seq=3 ttl=64 time=0.084 ms
64 bytes from 10.0.0.12: icmp_seq=4 ttl=64 time=0.077 ms
64 bytes from 10.0.0.12: icmp_seq=5 ttl=64 time=0.079 ms

如果要创建更网络命名空间并互相连接，用 veth 对将这些网络命名空间进行两两连接就很麻烦了。可以创建创建一个 Linux 网桥来连接这些网络命名空间。Docker 就是这样为同一主机内的容器进行连接的。

下面就创建网络命名空间并用网桥连接起来：

# All in one
BR=bridge1
HOST_IP=172.17.0.33
ip link add client1-veth type veth peer name client1-veth-br
ip link add server1-veth type veth peer name server1-veth-br
ip link add $BR type bridge
ip netns add client1
ip netns add server1
ip link set client1-veth netns client1
ip link set server1-veth netns server1
ip link set client1-veth-br master $BR
ip link set server1-veth-br master $BR
ip link set $BR up
ip link set client1-veth-br up
ip link set server1-veth-br up
ip netns exec client1 ip link set client1-veth up
ip netns exec server1 ip link set server1-veth up
ip netns exec client1 ip addr add 172.30.0.11/24 dev client1-veth
ip netns exec server1 ip addr add 172.30.0.12/24 dev server1-veth
ip netns exec client1 ping 172.30.0.12 -c 5
ip addr add 172.30.0.1/24 dev $BR
ip netns exec client1 ping 172.30.0.12 -c 5
ip netns exec client1 ping 172.30.0.1 -c 5

还是用 ping 命令检查两个网络命名空间的连接性：

$ ip netns exec client1 ping 172.30.0.12 -c 5
PING 172.30.0.12 (172.30.0.12) 56(84) bytes of data.
64 bytes from 172.30.0.12: icmp_seq=1 ttl=64 time=0.138 ms
64 bytes from 172.30.0.12: icmp_seq=2 ttl=64 time=0.091 ms
64 bytes from 172.30.0.12: icmp_seq=3 ttl=64 time=0.073 ms
64 bytes from 172.30.0.12: icmp_seq=4 ttl=64 time=0.070 ms
64 bytes from 172.30.0.12: icmp_seq=5 ttl=64 time=0.107 ms

从命名空间中 ping 一下主机 IP：

$ ip netns exec client1 ping $HOST_IP -c 2
connect: Network is unreachable

Network is unreachable 的原因是路由不通，加入一条缺省路由：

$ ip netns exec client1 ip route add default via 172.30.0.1
$ ip netns exec server1 ip route add default via 172.30.0.1
$ ip netns exec client1 ping $HOST_IP -c 5
PING 172.17.0.23 (172.17.0.23) 56(84) bytes of data.
64 bytes from 172.17.0.23: icmp_seq=1 ttl=64 time=0.053 ms
64 bytes from 172.17.0.23: icmp_seq=2 ttl=64 time=0.121 ms
64 bytes from 172.17.0.23: icmp_seq=3 ttl=64 time=0.078 ms
64 bytes from 172.17.0.23: icmp_seq=4 ttl=64 time=0.129 ms
64 bytes from 172.17.0.23: icmp_seq=5 ttl=64 time=0.119 ms
--- 172.17.0.23 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.053/0.100/0.129/0.029 ms

default 路由打通了网桥的通信，这样这个命名空间就能和外部网络进行通信了：

$ ping 8.8.8.8 -c 2
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=3.40 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=3.81 ms
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 3.403/3.610/3.817/0.207 ms

从外部服务器连接内网

如你所见，这里演示用的机器已经安装了 Docker，也就是说已经创建了 docker0 网桥。测试场景需要所有网络命名空间的协同，进行 Web Server 的测试有些复杂，因此这里就借用一下 docker0：

docker0   Link encap:Ethernet  HWaddr 02:42:e2:44:07:39
          inet addr:172.18.0.1  Bcast:172.18.0.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

运行一个 nginx 容器并进行观察：

$ docker run -d --name web --rm nginx
efff2d2c98f94671f69cddc5cc88bb7a0a5a2ea15dc3c98d911e39bf2764a556
$ WEB_IP=`docker inspect -f "{{ .NetworkSettings.IPAddress }}" web`
$ docker inspect web --format '{{ .NetworkSettings.SandboxKey }}'
/var/run/docker/netns/c009f2a4be71

Docker 创建的 netns 没有保存在缺省位置，所以 ip netns list 是看不到这个网络命名空间的。我们可以在缺省位置创建一个符号链接：

$ container_id=web
$ container_netns=$(docker inspect ${container_id} --format '{{ .NetworkSettings.SandboxKey }}')
$ mkdir -p /var/run/netns
$ rm -f /var/run/netns/${container_id}
$ ln -sv ${container_netns} /var/run/netns/${container_id}
'/var/run/netns/web' -> '/var/run/docker/netns/c009f2a4be71'
$ ip netns list
web (id: 3)
server1 (id: 1)
client1 (id: 0)

看看 web 命名空间的 IP 地址：

$ ip netns exec web ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:12:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.18.0.3/24 brd 172.18.0.255 scope global eth0
       valid_lft forever preferred_lft forever

然后看看容器里的 IP 地址：

$ WEB_IP=`docker inspect -f "{{ .NetworkSettings.IPAddress }}" web`
$ echo $WEB_IP
172.18.0.3

从主机访问一下 web 命名空间的服务：

$ curl $WEB_IP
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

加入端口转发规则，其它主机就能访问这个 nginx 了：

$ iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination $WEB_IP:80
$ echo $HOST_IP
172.17.0.23

使用主机 IP 访问 Nginx：

$ curl 172.17.0.23
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

CNI 插件会执行上面的过程（不完全相同，但是类似）来设置 loopback、eth0，并给容器分配 IP。容器运行时调用 CNI 设置 Pod 网络，接下来讨论一下 CNI。

CNI 是什么

CNI 插件负责在容器网络命名空间中插入一个网络接口（也就是 veth 对中的一端）并在主机侧进行必要的变更（把 veth 对中的另一侧接入网桥）。然后给网络接口分配 IP，并调用 IPAM 插件来设置相应的路由。

看起来很眼熟吧？是的，我们在前面的容器网络部分已经说了这些内容。

CNI 是一个 CNCF 项目，其中包含了在 Linux 容器进行网络配置的规范和库。CNI 的主要工作就是容器网络的连接能力，并在容器销毁时移除相应的已分配资源。这种专注性使得 CNI 易于实现，因此被广泛接受。

此处所说的运行时可能是 Kubernetes、Podman 等等。

CNI 规范

https://github.com/containernetworking/cni/blob/master/SPEC.md

在我首次阅读时，注意到了一些点：

因为 Docker 等运行时会为每个容器新建一个网络命名空间，所以规范把容器定义为 Linux 网络命名空间；
CNI 的网络定义用 JSON 格式存储；
网络定义通过 STDIN 发送给插件；换句话说主机上并没有网络配置文件；
其他参数通过环境变量进行传递；
CNI 插件是可执行文件；
CNI 插件负责容器的网络；换句话说，它需要完成所有容器接入网络所需的工作。在 Docker 中会包含把容器网络命名空间连回主机的工作；
CNI 插件负责 IPAM 工作，其中包括 IP 地址分配和路由设置。

接下来尝试脱离 Kubernetes 模拟创建 Pod，并使用 CNI 插件而非 CLI 命令进行 IP 分配。完成 Demo 就会更好地理解 Kubernetes 中 Pod 的本质。

第一步：下载 CNI 插件：

$ mkdir cni
$ cd cni
$ curl -O -L https://github.com/containernetworking/cni/releases/download/v0.4.0/cni-amd64-v0.4.0.tgz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   644  100   644    0     0   1934      0 --:--:-- --:--:-- --:--:--  1933
100 15.3M  100 15.3M    0     0   233k      0  0:01:07  0:01:07 --:--:--  104k
$ tar -xvf cni-amd64-v0.4.0.tgz
./
./macvlan
./dhcp
./loopback
./ptp
./ipvlan
./bridge
./tuning
./noop
./host-local
./cnitool
./flannel

第二步，创建一个 JSON 格式的 CNI 配置（00-demo.conf）：

{
    "cniVersion": "0.2.0",
    "name": "demo_br",
    "type": "bridge",
    "bridge": "cni_net0",
    "isGateway": true,
    "ipMasq": true,
    "ipam": {
        "type": "host-local",
        "subnet": "10.0.10.0/24",
        "routes": [
            { "dst": "0.0.0.0/0" },
            { "dst": "1.1.1.1/32", "gw":"10.0.10.1"}
        ]
    }
}

CNI 配置参数：

-:CNI generic parameters:-
cniVersion: The version of the CNI spec in which the definition works with
name: The network name
type: The name of the plugin you wish to use.  In this case, the actual name of the plugin executable
args: Optional additional parameters
ipMasq: Configure outbound masquerade (source NAT) for this network
ipam:
    type: The name of the IPAM plugin executable
    subnet: The subnet to allocate out of (this is actually part of the IPAM plugin)
    routes:
        dst: The subnet you wish to reach
        gw: The IP address of the next hop to reach the dst.  If not specified the default gateway for the subnet is assumed
dns:
    nameservers: A list of nameservers you wish to use with this network
    domain: The search domain to use for DNS requests
    search: A list of search domains
    options: A list of options to be passed to the receiver

第三步：创建一个网络为 none 的容器，这个容器没有网络地址。可以用任意的镜像创建该容器，这里我用 pause 来模拟 Kubernetes：

$ docker run --name pause_demo -d --rm --network none kubernetes/pause
Unable to find image 'kubernetes/pause:latest' locally
latest: Pulling from kubernetes/pause
4f4fb700ef54: Pull complete
b9c8ec465f6b: Pull complete
Digest: sha256:b31bfb4d0213f254d361e0079deaaebefa4f82ba7aa76ef82e90b4935ad5b105
Status: Downloaded newer image for kubernetes/pause:latest
763d3ef7d3e943907a1f01f01e13c7cb6c389b1a16857141e7eac0ac10a6fe82
$ container_id=pause_demo
$ container_netns=$(docker inspect ${container_id} --format '{{ .NetworkSettings.SandboxKey }}')
$ mkdir -p /var/run/netns
$ rm -f /var/run/netns/${container_id}
$ ln -sv ${container_netns} /var/run/netns/${container_id}
'/var/run/netns/pause_demo' -> '/var/run/docker/netns/0297681f79b5'
$ ip netns list
pause_demo
$ ip netns exec $container_id ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

第四步：用前面的配置来调用 CNI 插件：

$ CNI_CONTAINERID=$container_id CNI_IFNAME=eth10 CNI_COMMAND=ADD CNI_NETNS=/var/run/netns/$container_id CNI_PATH=`pwd` ./bridge </tmp/00-demo.conf
2020/10/17 17:32:37 Error retriving last reserved ip: Failed to retrieve last reserved ip: open /var/lib/cni/networks/demo_br/last_reserved_ip: no such file or directory
{
    "ip4": {
        "ip": "10.0.10.2/24",
        "gateway": "10.0.10.1",
        "routes": [
            {
                "dst": "0.0.0.0/0"
            },
            {
                "dst": "1.1.1.1/32",
                "gw": "10.0.10.1"
            }
        ]
    },
    "dns": {}

CNI_COMMAND=ADD：动作，可选范围包括 ADD、DEL 和 CHECK；
CNI_CONTAINER=pause_demo：通知 CNI 对 pause_demo 网络命名空间进行操作；
CNI_NETNS=/var/run/netns/pause_demo：命名空间所在路径；
CNI_IFNAME=eth10：在容器端创建的网络接口名称；
CNI_PATH=`pwd`：CNI 插件的可执行文件的位置，在本例中我们的当前目录已经是 cni 目录，因此这个环境变量设置为 `pwd` 即可.

强烈建议阅读 CNI 规范以获知更多 CNI 插件及其功能的信息。在同一个 JSON 文件中可以使用多个插件形成调用链，可以用于建立防火墙规则等类似操作。

第五步，运行上面的命令会返回一些内容。

首先是因为 IPAM 驱动在本地找不到保存 IP 信息的文件而报错。但是因为第一次运行插件时会创建这个文件，所以在其他命名空间再次运行这个命令就不会出现这个问题了。

其次是得到一个说明插件已经完成相应 IP 配置的 JSON 信息。在本例中，网桥的 IP 地址应该是 10.0.10.1/24，命名空间网络接口的地址则是 10.0.10.2/24。另外还会根据我们的 JSON 配置文件，加入缺省路由以及 1.1.1.1/32 路由。检查一下：

$ ip netns exec pause_demo ifconfig
eth10     Link encap:Ethernet  HWaddr 0a:58:0a:00:0a:02
          inet addr:10.0.10.2  Bcast:0.0.0.0  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1476 (1.4 KB)  TX bytes:0 (0.0 B)
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
$ ip netns exec pause_demo ip route
default via 10.0.10.1 dev eth10
1.1.1.1 via 10.0.10.1 dev eth10
10.0.10.0/24 dev eth10  proto kernel  scope link  src 10.0.10.2

CNI 创建了网桥并根据 JSON 信息进行了相应配置：

$ ifconfig
cni_net0  Link encap:Ethernet  HWaddr 0a:58:0a:00:0a:01
          inet addr:10.0.10.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::c4a4:2dff:fe4b:aa1b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1174 (1.1 KB)  TX bytes:1545 (1.5 KB)

第六步，启动 Web Server 并共享 pause 容器命名空间：

$ docker run --name web_demo -d --rm --network container:$container_id nginx
8fadcf2925b779de6781b4215534b32231685b8515f998b2a66a3c7e38333e30

第七步，使用 pause 容器的 IP 地址访问 Web Server：

$ curl `cat /var/lib/cni/networks/demo_br/last_reserved_ip`
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
...

接下来看看 Pod 的定义。

Pod 网络命名空间

接触 Kubernetes 最应该知道的一个问题就是，Pod 不等于容器，而是一组容器。这一组容器会共享同一个网络栈。每个 Pod 都会包含有 pause 容器，Kubernetes 通过这个容器来管理 Pod 的网络。所有其他容器都会附着在 pause 容器的网络命名空间中，而 pause 除了网络之外，再无其他作用。因此同一个 Pod 中的不同容器，可以通过 localhost 进行互访：

Kubernetes 单点登录详解

Thu, 27 May 2021 15:52:57 +0800

原文：Kubernetes Single Sign On - A detailed guide

作者：Ben Dixon

本文中我们将会为 Kuebernetes 构建一个完备的单点登录系统，这个系统会为 kubectl、Web 应用的 Ingress，以及 Docker 镜像仓库和 Gitea 提供服务，本文中会涉及多数单点登录模型，对于 Gitlab、Kibana、Grafana 等其它应用，应该也是适用的。

整个方案中使用了以 OpenLDAP 为后端的 KeyCloak 服务。OpenLDAP 能满足 Gitea 的需求，但基于 OIDC 的 kubectl 单点登录之类的功能是不需要它的。

本文中的一些亮点：

通过浏览器完成 kubectl 的单点登录；
用同样简单、但更安全的注解来替换 Ingress 的 Basic 认证注解；
使用完整的 ACL（访问控制列表）来进行 Docker 容器镜像的推送和拉取。

前提条件

我们假设你能够使用 Kubectl 访问 Kubernetes 集群（集群中包含 CSI 支持），在其中创建一个名为 identity 的命名空间。能够使用 Helm 3。最后假设你使用 Nginx Ingress 控制器，并包含 Cert Manager 组件，并用 Cert Manager 为集群提供一个称为 letsencrypt-production 的 SSL 证书签发者。

如果你的配置不满足上述要求，一些主要步骤应该还是一致的，Ingress 注解可能会有一些不同。本文中涉及的源码位于 https://github.com/TalkingQuickly/kubernetes-sso-guide.git，可以 Clone 到本地：

git clone https://github.com/TalkingQuickly/kubernetes-sso-guide.git

后续所有命令都认为你的当前目录是上述源码的根目录。

部署 OpenLDAP

因为 stable Chart 仓库已经淘汰，OpenLDAP 的 Chart 也受到波及。因为还没有更新，本文会使用最近的版本。

openldap/values-openldap.yml 中包含了 values 样例，我们可以做一些因地制宜的修改。

# Default configuration for openldap as environment variables. These get injected directly in the container.
# Use the env variables from https://github.com/osixia/docker-openldap#beginner-guide
env:
  LDAP_ORGANISATION: "Talking Quickly Demo"
  LDAP_DOMAIN: "ssotest.staging.talkingquickly.co.uk"
  LDAP_BACKEND: "hdb"
  LDAP_TLS: "true"
  LDAP_TLS_ENFORCE: "false"
  LDAP_REMOVE_CONFIG_AFTER_SETUP: "true"
  LDAP_READONLY_USER: "true"
  LDAP_READONLY_USER_USERNAME: readonly
  LDAP_READONLY_USER_MASSWORD: password

# Default Passwords to use, stored as a secret. If unset, passwords are auto-generated.
# You can override these at install time with
# helm install openldap --set openldap.adminPassword=<passwd>,openldap.configPassword=<passwd>
adminPassword: admin
configPassword: 9h8sdfg9sdgfjsdfg8sdgsdfjgklsdfg8sdgfhj

customLdifFiles:
  initial-ous.ldif: |-
    dn: ou=People,dc=ssotest,dc=staging,dc=talkingquickly,dc=co,dc=uk
    objectClass: organizationalUnit
    ou: People

    dn: ou=Group,dc=ssotest,dc=staging,dc=talkingquickly,dc=co,dc=uk
    objectClass: organizationalUnit
    ou: Group

上一节配置中，我使用 dc=ssotest,dc=staging,dc=talkingquickly,dc=co,dc=uk 作为 Kubernetes 集群的基础域。我们的 LDAP 服务仅对内提供服务，因此不需要映射到 DNS。

customLdifFiles 的内容是用于对 LDAP 数据库进行初始化的。这里提供了两个 organizationalUnit，类型为 People 的项目会用于保存个人信息，另外一个类型为 Group 的则会用于保存群组信息。OU 可以近似的看做是传统文件系统中的文件夹。OpenLDAP OUs 一文中详细解释了这方面的内容。

现在就可以用下面的命令来安装 OpenLDAP 了：

helm upgrade --install openldap ./charts/openldap --values openldap/values-openldap.yml

安装过程中会输出一些成功信息，以及访问该服务的示例。

注意下面几个用于获取配置和密码的命令：

kubectl get secret --namespace identity openldap -o jsonpath="{.data.LDAP_ADMIN_PASSWORD}" | base64 --decode; echo
kubectl get secret --namespace identity openldap -o jsonpath="{.data.LDAP_CONFIG_PASSWORD}" | base64 --decode; echo

使用 OpenLDAP 客户端

我们最后会使用 KeyCloak 来管理 LDAP 目录，在那之前可以熟悉一下 OpenLDAP 客户端。Splunk 有文章介绍了这个客户端。

首先用 kubectl proxy 来开放 LDAP 服务：

kubectl port-forward --namespace identity \
      $(kubectl get pods -n identity --selector='release=openldap' -o jsonpath='{.items[0].metadata.name}') \
      3890:389

在另一个终端里，执行下面的命令（包括 OSX 在内的多数 Unix 系统都安装了 ldapsearch，如果没有的话，就需要进行安装，例如 Debian 发行版就需要安装 ldap-utils）：

ldapsearch -x -H ldap://localhost:3890 \
    -b dc=ssotest,dc=staging,dc=talkingquickly,dc=co,dc=uk \
    -D "cn=admin,dc=ssotest,dc=staging,dc=talkingquickly,dc=co,dc=uk" \
    -w password

命令会返回如下信息：

objectClass: organization
o: Talking Quickly's Demo
dc: k4stest4

# admin, k4stest4.talkingquickly.co.uk
dn: cn=admin,dc=k4stest4,dc=talkingquickly,dc=co,dc=uk
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9YjM1a0hLYXVwcDlvcGU5R1N2UE5qcFBLd3FxdUorWFk=

# People, k4stest4.talkingquickly.co.uk
dn: ou=People,dc=k4stest4,dc=talkingquickly,dc=co,dc=uk
objectClass: organizationalUnit
ou: People

# Group, k4stest4.talkingquickly.co.uk
dn: ou=Group,dc=k4stest4,dc=talkingquickly,dc=co,dc=uk
objectClass: organizationalUnit
ou: Group

# search result
search: 2
result: 0 Success

# numResponses: 6
# numEntries: 4

Stack Overflow 上有一篇帖子描述了 dn、dc 这些名词的详情。

注意我的测试域 ssotest.staging.talkingquickly.co.uk 的结果是一个 dn，其中包含了一组逗号分隔的 dc 列表：dc=ssotest,dc=staging,dc=talkingquickly,dc=co,dc=uk。这里看到我们 customLdiffFiles 定义的 ou 已经建立了。

现在我们已经有了 LDAP 服务器，通过简单的测试，检查了我们保存在服务之中的数据。接下来就可以安装 KeyCloak 了。

安装 KyeCloak

Helm 3 提倡使用去中心化的仓库替代原有的仓库，所以在安装 Keycloak 之前要首先加入新的仓库：

helm repo add codecentric https://codecentric.github.io/helm-charts

有兴趣的话还可以看看这个 Chart 的详细信息。

为了进行一些基础配置，我们需要配置 Ingress，并启用 Postgres 存储数据。

这里假设你的集群中包含了 Ingress 和存储支持。我用域名通配符 *.ssotest.staging.talkingquickly.co.uk 指向测试集群。所以我们的 keycloak/values-keycloak 看起来是这样的：

extraEnv: |
  - name: KEYCLOAK_LOGLEVEL
    value: DEBUG
  - name: KEYCLOAK_USER
    value: admin
  - name: KEYCLOAK_PASSWORD
    value: as897gsdfs766dfsgjhsdf
  - name: PROXY_ADDRESS_FORWARDING
    value: "true"

ingress:
  enabled: true
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-production
  rules:
    - host: sso.ssotest.staging.talkingquickly.co.uk
      paths:
        - /
args:
  - -Dkeycloak.profile.feature.docker=enabled

  tls:
  - hosts:
    - sso.ssotest.staging.talkingquickly.co.uk
    secretName: keycloak-tld-secret

postgresql:
  enabled: true
  postgresqlPassword: asdfaso97sadfjylfasdsf78

用如下命令执行安装：

helm upgrade --install keycloak codecentric/keycloak --values keycloak/values-keycloak.yml

在 values-keycloak.yml 中使用环境变量 KEYCLOAK_USER 以及 KEYCLOAK_PASSWORD 设置了 keycloak 的用户名和密码，我们将会用这个信息来访问 Keycloak 的控制台。

我们根据前面的 Ingress 设置来浏览控制台页面（例如 https://sso.ssotest.staging.talkingquickly.co.uk），然后输入用户名密码完成登录。这里可以创建用户和即将使用 Keycloak 进行单点登录的应用程序。

注意登录管理控制台和服务用户登录是各自独立的。

在 Keycloak 中我们可以创建多个 realms，代表不同的认证服务。例如我们可能要给内部系统创建一个 realm，另外给客户创建独立的 realm。缺省 realm 命名为 master，根据前面的 Ingress 定义，用户可以访问 https://sso.ssotest.staging.talkingquickly.co.uk/auth/realms/master/account 进行登录。访问 https://sso.ssotest.staging.talkingquickly.co.uk/auth/realms/master 能够获取该 realm 的有用信息。

这里有一个容易混淆的环节就是使用管理员凭据而非在特定 realm 中创建的普通用户的凭据进行登录。

Kubernetes 中的 Keycloak 和 OpenLDAP

完成了 Keycloak 和 OpenLDAP 的部署之后，可以进行进一步的配置，把两个系统连接起来，让 Keycloak 使用 OpenLDAP 存储用户数据。

在 Keycloak 中配置 OpenLDAP

用管理用户登录到 Keycloak 控制台，进入 User Federation 从 Add Provider 下拉列表中选择 ldap。按照如下数值填写关键字段：

Edit Mode: Writable
Sync Registrations: On
Vendor: Other
Connection URL: ldap://openldap.identity.svc.cluster.local; you’ll need to change identity to match the namespace you’re working in)
Users DN: ou=People,dc=ssotest,dc=staging,dc=talkingquickly,dc=co,dc=uk; you’ll need to change the dc entries to match your base dn. Note that here we’re telling Keycloak that users are stored in our People ou, created from the customLdiffFiles.
Authentication Type: simple
Bind DN: cn=admin,dc=ssotest,dc=staging,dc=talkingquickly,dc=co,dc=uk again, updating the dc entries to match your base dn
Bind Credentials: Set this to the admin password we used for ldapsearch earlier

填写完成后保存数据。这个配置数据和缺省数据稍有不同，需要确认 memberOf 属性是否正常工作。在这方面，Github 上有一个很长的 Issue。有些应用需要这个功能来根据分组来进行访问控制。

可以用 ldapsearch 验证 memberOf 是否正常工作，我们需要使用搜索操作符来进行搜索：

ldapsearch -x -H ldap://localhost:3890 -b dc=ssotest,dc=staging,dc=talkingquickly,dc=co,dc=uk -D "cn=admin,dc=ssotest,dc=staging,dc=talkingquickly,dc=co,dc=uk" "+" -w password

要在本地运行这个命令，需要在本地进行流量转发：

kubectl port-forward --namespace identity \
      $(kubectl get pods -n identity --selector='release=openldap' -o jsonpath='{.items[0].metadata.name}') \
      3890:389

用户管理和测试

点击 Keycloak 管理门户左侧的 Users，选择 Add User。填写并保存用户数据之后，就可以用 ldapsearch 来检查用户是否已经成功创建。可以用端口转发的方式来进行验证：

kubectl port-forward --namespace identity \
      $(kubectl get pods -n identity --selector='release=openldap' -o jsonpath='{.items[0].metadata.name}') \
      3890:389

然后进行搜索：

ldapsearch -x -H ldap://localhost:3890 -b dc=ssotest,dc=staging,dc=talkingquickly,dc=co,dc=uk -D "cn=admin,dc=ssotest,dc=staging,dc=talkingquickly,dc=co,dc=uk" "+" -w password

这里应该用真实密码代替此处的 password。

输出内容中应该能看到如下内容：

# talkingquickly, People, ssotest.staging.talkingquickly.co.uk
dn: uid=talkingquickly1,ou=People,dc=ssotest,dc=staging,dc=talkingquickly,dc=co,dc=uk
uid: talkingquickly1
objectClass: inetOrgPerson
objectClass: organizationalPerson
mail: ben+1@hillsbede.co.uk
sn: Dixon
cn: Ben

这表明用户已经成功建立。接下来配置一下用户组。我们浏览 Groups 页面，加入一个 Administrator 组，重新运行 ldapsearch 命令，我们不会看到任何变化，群组没有出现。

返回 Users 页，选择或者新建一个用户，并进入 Groups 页面把用户加入群组。回到 Users，会看到一个空列表，必须选择 View all users 才能看到用户信息。

完成这些动作之后，重新运行 ldapsearch，会看到类似下面的内容：

# Administrators, Group, k4stest4.talkingquickly.co.uk
dn: cn=Administrators,ou=Group,dc=k4stest4,dc=talkingquickly,dc=co,dc=uk
objectClass: groupOfNames
cn: Administrators
member: cn=empty-membership-placeholder
member: uid=talkingquickly,ou=People,dc=k4stest4,dc=talkingquickly,dc=co,dc=uk

这些输出表示我们的群组已经建立，并且已经有用户成为群组的成员。

如果我们查看一下我们的用户条目，点击 +，会看到包含一行内容：

memberOf: cn=Administrators,ou=Group,dc=ssotest,dc=staging,dc=talkingquickly,dc=co,dc=uk

说明 memberOf 功能正常。

本文不会涉及更多 ldapsearch 的内容，ldapsearch Examples 中包含了很多的详细用例。

用 OIDC 登录 Kubernetes

使用 Kubernetes 集群的团队要面临的一个常见痛点就是管理连接集群的配置文件。一般的解决办法，要么是使用 KUBECONFIG 环境变量指定配置文件，其中包含了硬编码的凭据；要么就是使用自定义脚本来包装 AWS 或者 GCP 的客户端。

本节中我们会把 Kubernetes 和 Keycloak 集成起来，这样在我们执行 kubectl 或者 helm 命令的时候，如果用户没能完成认证，就会打开浏览器窗口进行登录，这样就无需使用 KUBECONFIG 变量了。

我们也会配置基于群组的访问控制，所以我们可以创建一个 KubernetesAdminstrators 组，从而让组中所有用户具备 cluster-admin 权限。

如果我们在 Keycloak 中移除用户（或者从特定组中移除用户），对应用户就会失去权限。

我们会使用 OpenID Connect。官网文档中介绍了这一特性的原理。

缺省情况下，要给 Kubernetes 加入 OIDC 认证配置，需要修改 API Server 的参数。只有一些托管 Kubernetes 产品（例如 AWS 和 GCP）提供了这种手段，用于连接它们各自的 IAM 系统。

我们将使用来自 JetStack 的 kube-oidc-proxy 来解决这个问题。这个工具提供一个代理服务器来管理 OIDC 认证，用户连接到这个代理服务器时，服务会给通过认证的用户提供所需的权限。这种方法是通用的，也就是说我们可以用同样的方法来管理所有的托管和非托管集群。

设置 Keycloak

首先我们要在 Keycloak 中创建一个新客户端，其 ID 为 kube-oidc-proxy，协议为 openid-connect，并且设置该客户端的参数：

Access Type：confidential，这需要生成一个应用 Secret。
Valid Redirect URLs：http://localhost:8000 和 http://localhost:18000。kubelogin 会使用这些网址作为回调，在 kubectl 进行登录时，就会打开浏览器窗口进行 Keycloak 进行认证。

保存新应用，就会出现一个新的 Credentials 标签，需要在这个标签里生成客户端 Secret，这个 Secret 将会在后续步骤中和 Client ID 一起使用。

设置 Kube OIDC Proxy

客户端创建之后，就要配置 Kube OIDC Proxy 了。在 kube-oidc-proxy/values-kube-oidc.yml 包含一个样本：

oidc:
  clientId: kube-oidc-proxy
  issuerUrl: https://sso.ssotest.staging.talkingquickly.co.uk/auth/realms/master
  usernameClaim: sub

extraArgs:
  v: 10

ingress:
  enabled: true
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-production
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
  hosts:
    - host: kube.ssotest.staging.talkingquickly.co.uk
      paths:
        - /
  tls:
    - secretName: oidc-proxy-tls
      hosts:
        - kube.ssotest.staging.talkingquickly.co.uk

有几个需要进行定制的点：

issuerUrl：Keycloak 的实例地址，其中包含了 realm 信息（这里我们使用的是缺省的 master realm）。
Ingress 定义的主机名。这个 URL 会用来替代 Kubernetes API 的 URL，我们的 SSO 登录设置完毕之后，Kubeconfig 文件会指向这个地址而非原有的 Kubernetes API。

extraArgs 中设置的 v: 10 要求 Kube OIDC Proxy 输出详细日志，便于排查问题。在生产环境中可以删除这一行。

接下来用 Helm 安装 Kube OIDC Proxy：

helm upgrade --install kube-oidc-proxy ./charts/kube-oidc-proxy --values kube-oidc-proxy/values-kube-oidc.yml

Kube OIDC Proxy 启动之后，就可以配置 kubectl 了。最简单的方式就是使用 kubelogin。它是一个 kubectl 的插件，安装插件之后，如果执行 kubectl，就会打开一个浏览器窗口，让用户在其中登录 Keycloak。登录之后它会负责刷新 Token，并负责会话过期之后的重新认证。

项目主页提供了该插件的安装方法，homebrew 用户可以用 brew install int128/kubelogin/kubelogin 轻松完成，否则的话，推荐用 krew 管理 kubectl 插件，这样就可以用 kubectl krew install oidc-login 进行安装了。

接下来就是创建一个 kubeconfig.yml 文件，内容（kubelogin/kuebconfig.yml）如下：

apiVersion: v1
clusters:
- cluster:
    server: https://kube.ssotest.staging.talkingquickly.co.uk
  name: default
contexts:
- context:
    cluster: default
    namespace: identity
    user: oidc
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: oidc
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - oidc-login
      - get-token
      # - -v1
      - --oidc-issuer-url=https://sso.ssotest.staging.talkingquickly.co.uk/auth/realms/master
      - --oidc-client-id=kube-oidc-proxy
      - --oidc-client-secret=a32807bc-4b5d-40b7-8391-91bb2b80fd30
      - --oidc-extra-scope=email
      - --grant-type=authcode
      command: kubectl
      env: null
      provideClusterInfo: false

需要修改的内容：

server：Kube OIDC Proxy 的 Ingress URL；
oidc-issuer-url：和 Kube OIDC Proxy 中配置的 Keycloak URL；
oidc-client-secret：Keycloak 客户端应用的 Secret；
-v1：可选项，用于输出更多日志信息。

接下来执行：

export KUBECONFIG=./kubelogin/kubeconfig.yml
kubectl get pods

本文不会涉及 kubeconfig 文件的管理方法，而如果你还没有这方面的管理经验，强烈推荐使用 direnv 和 kubectx 的组合。我的 Debian 远程开发环境和 OSX 配置里面都提供了开箱可用的这两个工具。

export KUBECONFIG=./kubelogin/kubeconfig.yml 这个用法仅在同一个终端会话中生效，所以如果切换到新的终端，或者关闭重新打开你的终端，这个配置就会退回到 Shell 缺省的 KUBECONFIG 环境变量。

当我们执行上面命令的时候，会打开一个浏览器，用户需要在浏览器里登录 Keycloak。

然而我们会看到错误信息：

Error from server (Forbidden): pods is forbidden: User "oidcuser:7d7c2183-3d96-496a-9516-dda7538854c9" cannot list resource "pods" in API group "" in the namespace "identity"

Kubernetes 知道当前用户是 oidcuser:7d7c2183-3d96-496a-9516-dda7538854c9，说明我们的用户已经通过认证，但是这个用户当前却又无权进行任何操作。

我们可以创建一个 Cluster Role Binding，并把 cluster-admin 角色绑定上去。

我们需要另开一个终端，也就是我们还没有修改 KUBECONFIG 的终端会话，这样我们就会使用一个 cluster-admin 权限来操作集群了。

kubectl create clusterrolebinding oidc-cluster-admin --clusterrole=cluster-admin --user='oidcuser:OUR_USER_ID'

把 OURUSERID 替换为登录用户的 Keycloak ID（可以参看上面的消息）。

oidcuser: 前缀是 Kueb OIDC Proxy 配置中的 usernamePrefix: 和 oidcuser:。这一措施能够防止不同的用户系统之间造成冲突。

使用 Keycloak 群组登录到 Kubernetes

前面的步骤让我们的 kubectl 用 Keycloak 用户登录集群。然而为每个用户创建一个 Cluster Role Binding 是个很麻烦的事情。

要解决这个问题就要靠群组，我们会对 OIDC 实现进行配置，使其感知到 Keycloak 的群组。我们可以在 Keycloak 创建一个 KubernetesAdmin 组，组中所有用户都使用同一个 Cluster Role Binding 被授予 cluster-admin 权限。

首先在 Keycloak 上创建一个 KubernetesAdmin 群组，然后在群组中创建一个新用户。

接下来要更新我们的 Keycloak 客户端，把用户所属群组的信息包含在 JWT 中。

要完成这个任务要回到 Keycloak 客户端 kube-oidc-client 条目中，并选择 Mapper 分页，点击 Create。

输入如下内容：

Name：Groups；
Mapper Type：Group Membership；
Full Group Path：Off；

然后保存。

如果在 kubelogin/kubeconfig.yml 文件中取消 # - -v1 中的注释符，并删除 ~/.kube/cache/oidc-login/ 的内容然后执行 kubectl get pods，会再次进行登录，我们会看到 JWT 信息中包含了我们的群组信息：

{
  ...                                         
  "groups": [                                                       
    "DockerRegistry",                                             
    "Administrators",
    "KubernetesAdmins"
  ],             
  ...
}

我们可以创建一个 Cluster Role Binding，让每个 KubernetesAdmin 中的每个成员都有 cluster-admin 的访问能力：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: oidc-admin-group
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: oidcgroup:KubernetesAdmins

在我们的 Kube OIDC Proxy 配置中，使用 groupsPrefix: "oidcgroup:" 的配置为群组名称加上了 oidcgroup 前缀，防止和 Kubernetes 中的其他分组造成冲突。

把这个 YAML 提交给集群：

kubectl apply -f ./group-auth/cluster-role-binding.yml

然后就可以删除前面单独创建的 Cluster Role Binding：

kubectl delete clusterrolebinding oidc-cluster-admin

上述动作完成之后，就能用 kubectl get po 之类的简单命令来验证工作成果了。

上述授权只是用于测试的，实际工作中应该创建更加严格的授权，例如一些只能在特定命名空间中工作的用户。

使用 Ingress 注解为 Web 应用提供认证

本章节完成后，只需要给 Ingress 加入注解，就能用 Keycloak 为其他应用提供认证功能。这就给我们一种方便易用的替换 Basic Auth 的方法。

一部分运行在 Kubernetes 中的第三方应用都支持 OIDC 或者 LDAP 的登录。在部署自研应用时，可以使用 Keycloak 来管理登录，而无需额外开发 OIDC 或者 LDAP 的集成代码。

下面将使用 OAuth2 Proxy 给一个简单的 Nginx 容器加入认证功能。之后观察一下如何访问应用，如何解码 Keycloak JWT 并使用群组鉴权等特性。

可以用这种建议的方式对内部应用进行保护。在更复杂的环境中，还可以在 Keycloak 中创建一个 customers realm，把认证和鉴权工作都交给 Keycloak。

Keycloak Gatekeeper/Louketo 在 2020 年 8 月进入 EOL，因此我们使用 OAuth2 Proxy 来完成这一任务。

为 Nginx 服务器设置 Keycloak 认证

首先要对 OAuth2 Proxy 进行配置，使之对接到 Keycloak，并使用 Helm 进行部署。

接下来会用 Helm 部署官方的 Nginx 容器镜像，用它作为测试应用，然后我们会使用 Keycloak 结合 Ingress 注解来对其进行访问控制。

最后我们还要看看示例应用如何获得登录用的信息，从而有能力进行更细粒度的访问控制。

工作原理

Nginx 支持基于子请求结果的认证：当受保护页面接到请求时，Nginx 可以向一个额外的 URL 发送一个子请求，如果该 URL 返回了 2xx 的响应码，就允许接收这个请求，如果返回了 401 或 403，就会拒绝请求。

实际上我们无需深入理解上面的内容，因为 OAuth2 Proxy 连接到了 Keycloak 进行实际的认证，并给 Nginx 提供了适用的端点，来检查用户是否登录。

所以我们只要配置 OAuth2 Proxy 并给特定服务的 Ingress 加入合适的注解。

配置 OAuth2 Proxy

首先我们要在 Keycloak 创建一个客户端应用，创建一个新的 OpenID 连接应用，并作出如下设置：

Client ID：oauth2-proxy
Access Type：confidential
Valid Redirect URLs：https://oauth.ssotest.staging.talkingquickly.co.uk/oauth2/callback，注意替换其中的域名。

保存新建项目，并打开新出现的 Credentials 页面，注意其中的 Secret 内容。

最后进入 Mappers 页面，选择 Create：

Name：Groups
Mapper Type：Group Membership
Token Claim Name：groups
其它选项都设置为 On

保存数据。这一配置的含义是，属于本组的用户会返回给 OAuth2 Proxy 并随后返回给应用。

OAuth2 Proxy 有一个 Keycloak Provider，但是这里我们会使用通用的 OIDC Provider。这是一个更通用的解决方案，并提供了自动刷新 Cookie 等 Keycloak Provider 所没有的一些功能。目前 OAuth2 Proxy 团队还在讨论修改 Keycloak Provider 为 OIDC Provider。

下一步可以创建 OAuth2 Proxy 配置，在 oauth2-proxy/values-oauth2-proxy.yml 中包含一个样本：

# Oauth client configuration specifics
config:
  clientID: "oauth2-proxy"
  clientSecret: "YOUR_SECRET"
  # Create a new secret with the following command
  # openssl rand -base64 32 | head -c 32 | base64
  cookieSecret: "YOUR_COOKIE_SECRET"
  configFile: |-
    provider = "oidc"
    provider_display_name = "Keycloak"
    oidc_issuer_url = "YOUR_ISSUER"
    email_domains = [ "*" ]
    scope = "openid profile email"
    cookie_domain = ".ssotest.staging.talkingquickly.co.uk"
    whitelist_domains = ".ssotest.staging.talkingquickly.co.uk"
    pass_authorization_header = true
    pass_access_token = true
    pass_user_headers = true
    set_authorization_header = true
    set_xauthrequest = true
    cookie_refresh = "1m"
    cookie_expire = "30m"

ingress:
  enabled: true
  path: /
  hosts:
    - oauth.ssotest.staging.talkingquickly.co.uk
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-production
    nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"
  tls:
    - secretName: oauth-proxy-tls
      hosts:
        - oauth.ssotest.staging.talkingquickly.co.uk

这里有一些需要自行配置的关键字段：

clientSecret：Keycloak 凭据页面里保存的 Secret；
cookieSecret：可以用 openssl rand -base64 32 | head -c 32 | base64 命令随机生成；
loginurl、redeemurl、validate_url：应该根据实际的 URL 和 Realm 进行配置；
cookiedomain、whitelistdomain：需要根据实际的域名进行配置，例如这里使用的 .ssotest.staging.talkingquickly.co.uk；
ingress hosts：设置为部署 OAuth2 Proxy 的 Ingress 主机名。

cookie_domain 和 whitelist_domain 都很重要，缺省情况下，OAuth2 Proxy 只对自己的主机名生效。所以 Cookie 只能指定到该主机名，重定向也只能对这个子域名生效。

缺省情况下，OAuth2 Proxy 会请求一个 api scope，这在 Keycloak 是不存在的，会返回 403 Invalid Scopes 的错误，因此要设置 scope = "openid profile email"。

set_authorization_header 确保 JWT 被回传给 Nginx Ingress，这样就能确保 Header 被回传给应用，应用可以借此获取登录用户的信息。

最后，OAuth 报文中经常会传递较多的 Header 信息，因此这里设置 nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"，避免出现 Cookie "oauth2proxy not present" 或者 upstream sent too big header while reading response header from upstream 这样的错误。

安装 OAuth2 Proxy

同样地，因为 Stable 仓库即将淘汰，OAuth2 Proxy Chart 还没迁移到新的仓库，所以我们在样例中保留了最近的版本，可以用如下命令进行安装：

helm upgrade --install oauth2-proxy ./charts/oauth2-proxy --values oauth2-proxy/values-oauth2-proxy.yml

安装结束，就可以浏览 Ingress 域名，会看到出现了 Sign in with Keycloak 的选项。

如果我们不小心使用管理员而非在 OAuth2 Proxy 登录会看到 403 之类的错误。

如果我们成功地登录到了 Kyecloak，会被重定向到一个 404 页面，这是因为目前还没定义待认证页面。我们不应该直接访问这个 URL，正常情况下，认证流程应该在浏览受保护页面时被自动触发。所以前面的登录动作只是为了验证功能而已。

为应用加入认证

现在我们已经完成了 OAuth2 Proxy 的配置，接下来就可以安装一个示例应用，并在 Ingress 定义中加入注解，将应用置于认证保护之后。

在这个例子中会安装一个简单的 Nginx，它只会提供一个 Welcome to nginx 的静态页面，不同的是这个页面会要求登录认证。读者要注意不要把这个 Nginx 和 Nginx Ingress 混为一谈。

这里用了 Bitnami 的 Nginx Helm Chart：

helm repo add bitnami https://charts.bitnami.com/bitnami

用如下代码配置我们的应用：

serverBlock: |
  log_format    withauthheaders '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status  $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for" "$http_x_auth_request_access_token"';

    add_header    x-auth-request-access-token "$http_x_auth_request_access_token";

  # HTTP Server
  server {
      # Port to listen on, can also be set in IP:PORT format
      listen  8080;

      include  "/opt/bitnami/nginx/conf/bitnami/*.conf";

      location /status {
          stub_status on;
          access_log   off;
          allow 127.0.0.1;
          deny all;
      }

      access_log /dev/stdout withauthheaders;
  }

ingress:
  enabled: true
  hostname: nginx-demo-app2.ssotest.staging.talkingquickly.co.uk
  tls: true
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-staging
    nginx.ingress.kubernetes.io/auth-url: "https://oauth.ssotest.staging.talkingquickly.co.uk/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-signin: "https://oauth.ssotest.staging.talkingquickly.co.uk/oauth2/start?rd=$scheme://$best_http_host$request_uri"
    nginx.ingress.kubernetes.io/auth-response-headers: "x-auth-request-user, x-auth-request-email, x-auth-request-access-token"
    acme.cert-manager.io/http01-edit-in-place: "true"
    nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"

service:
  type: ClusterIP

这里定义的 serverBlock 和实际的认证流程无关。下面两条认证措施，都是把 Nginx 作为演示应用的：

修改日志行为，在日志输出中加入 x-auth-request-access-token Header，这样我们就可以查看日志中的 Token，进行分析和测试。
自动为入站请求和响应加入 x-auth-request-access-token Header，便于在浏览器进行查看。

把 Token 输出到日志是非常危险的操作，决不应该用在生产环境之中。

跟认证有关的行如下所示：

ingress:
  annotations:
    nginx.ingress.kubernetes.io/auth-url: "https://oauth.ssotest.staging.talkingquickly.co.uk/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-signin: "https://oauth.ssotest.staging.talkingquickly.co.uk/oauth2/start?rd=$scheme://$best_http_host$request_uri"
    nginx.ingress.kubernetes.io/auth-response-headers: "x-auth-request-user, x-auth-request-email, x-auth-request-access-token"
    acme.cert-manager.io/http01-edit-in-place: "true"
    nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"

这里用 acme.cert-manager.io/http01-edit-in-place: "true" 注解来调用 Cert Manager 并设置响应 Header。nginx.ingress.kubernetes.io/proxy-buffer-size: "16k" 则是增加缓存用于存储 OAuth 2 Proxy Header。

nginx.ingress.kubernetes.io/auth-url 是第一处核心注解，指定了检查当前用户认证的 URL。当请求进入时，Nginx 会发送请求到这个网址，注意它发送的只是 Header 以及请求相关的 Cookie，而不包括 Body。URL 所对应的 Service（本例中就是 OAuth2 Proxy）负责根据 Cookie 和 Header 来验证用户的登录状态。如果用户已经过认证，服务会返回 2xx 状态码，然后这个请求就会传递给应用。如果未登录，请求就会转发给 nginx.ingress.kubernetes.io/auth-signin 中的 URL，启动认证流程。要给所有子域提供认证，就需要把 OAuth2 Proxy 的 Cookie 域设置为上级域名。

因为设置了 set_authorization_header = true，当请求认证通过后，OAuth2 Proxy 就会在返回给 Nginx 的 2xx 响应中加入 x-auth-request-access-token Header，其中包含了认证 Token，本例中这个 Token 是包含用户和会话的 JWT 信息。

缺省情况下，被认证应用是不能访问这个 Token 的，要获取认证用户的信息，或者该用户所属的群组，要获取这些信息，需要设置 nginx.ingress.kubernetes.io/auth-response-headers: "x-auth-request-user, x-auth-request-email, x-auth-request-access-token"，它会通知 Nginx Ingress，从返回的 2xx 响应中获取这几个 Header，并传递给后端应用。这样后端应用就能够获取 Header，并解码 JWT 来获取用户的相关信息。

在这个简单的例子里，会把这些信息输出到日志里（不安全），并把信息响应给用户。如果访问示例应用的 Ingress URL，在本例中就是 https://nginx-demo-app2.ssotest.staging.talkingquickly.co.uk，就会要求登录，然后重定向到 Welcome to nginx! 页面。

可以用浏览器的网络页来观察请求内容，会看到响应中的 x-auth-request-access-token。

如果我们把 Header 内容拷贝出来进行解码（例如 https://jwt.io）就会看到类似内容：

{
...
  "scope": "openid email profile",
  "email_verified": false,
  "name": "Ben Dixon",
  "groups": [
    "/DockerRegistry",
    "/KubernetesAdmins",
    "/Administrators"
  ],
  "preferred_username": "talkingquickly",
  "given_name": "Ben",
  "family_name": "Dixon",
  "email": "ben@talkingquickly.co.uk"
}

在更复杂的系统中，后端系统会用这里的信息进行判断，根据用户和群组信息来展示不同内容。

Token 过期

我们已经完成了两阶段认证。当请求认证通过之后，OAuth2 Proxy 会跟 Keycloak 进行通信，并取得 Access Token。只要 OAuth2 Proxy 的 Cookie 存在并且有效，相应的请求就不会需要重新使用 Keycloak 进行认证。

使用 JWT 时，很可能会遭遇一个问题就是过期（缺省情况下，Keycloak 的 Access Key 寿命只有一分钟）。这个问题会导致一个麻烦，用户通过了 OAuth2 Proxy 的验证，但是传递给 x-auth-request-access-token 的 JWT 已经过期了。如果我们在应用中对 JWT 进行验证，会抛出 Token 无效的异常。

下面的配置可以解决这个问题：

cookie_refresh = "1m"
cookie_expire = "30m"

cookie_refresh 告诉 OAuth2 Proxy 如果 OAuth2 Proxy Cookie 超过一分钟还没刷新，则刷新 Access Token。这就和 Keycloak 的行为一致了，不会再次把过期 Token 加入请求数据之中。

使用 OIDC Provider 而非 Keycloak Provider 的原因是，目前 Keycloak Provider 还不支持 Token 刷新。

cookie_expire 设置 OAuth2 Proxy 的 Cookie 生命周期为 30 分钟，超时之后用户会被转向 KeyCloak 重新进行验证。这就和 KeyCloak 的会话过期保持了同步。

限制特定群组的访问

在 OAuth2 Proxy 配置中加入一行 allowed_groups = ["/DemoAdmin"]，就能够仅允许属于 DemoAdin 群组的用户进行登录。这种情况下，组外用户在登录失败的时候会看到一个 500 的返回码，而不是一个说明实际原因的页面。用户登录时，如果没有在许可组中找到记录，OAuth2 Proxy 就会返回 400，如果我们看看 Nginx 的日志，会看到 auth request unexpected status: 400 while sending to client 这样的信息。

所以这种方法虽然适用于简单的内部应用，但是在应用中处理群组鉴权会有更好的用户体验。

和 Token 打交道

jwt-ruby-example/main.rb 是一个简单的 Ruby 程序，其中包含了处理 Token 的技术。下面的代码很直白：

require 'jwt'

public_key_string = """
PUBLIC_KEY_GOES_HERE
"""

public_key = OpenSSL::PKey::RSA.new(public_key_string)

token = "TOKEN_GOES_HERE"

decoded_token = JWT.decode token, public_key, true, { algorithm: 'RS256' }

puts decoded_token

PUBLIC_KEY_GOES_HERE 需要用公钥来替换，可以在 Keycloak 的 Realm Settings -> Keys -> RS256 -> Public Key 中找到。

而 TOKEN_GOES_HERE 需要从我们的应用日志或者是 Headers 中获取并使用 ruby main.rb（在运行 bundle install 之后）解码获得。

注意 Keycloak Token 的缺省过期时间是 1 分钟，所以拷贝黏贴动作最好快一点。

输出内容会被解压为 Ruby Map。所以在完整的 Web 应用中（例如 Rails 或者 Sinatra），可以需要根据用户所属群组或者用户登录 Email 进行相应的判断。

Gitea 单点登录

Gitea 是一个开源的轻量级 Git 服务。顺便说一句，Gitea（尤其是和 Drone CI 协同）是我最喜欢的开源软件。

Gitea 的轻量和易用特性，非常适用于 Git Push 发布以及持续集成。

这里我们要配置 OpenLDAP 来进行中心化的用户管理并提供单点登录。我们也会配置 OpenID Connect，但是可能会有一些问题。

安装 Gitea

本文我们主要会聚焦于配置 Gitea 使用 LDAP 进行认证的过程，因此我们这里只会包括 Web 界面的设置。

可能需要根据集群现状编辑 gitea/values-gitea.yml 中的 Ingress 主机名以及 HTTPS 的相关配置：

itea:
  domain: gitea-keycloak.ssotest.staging.talkingquickly.co.uk 
  protocol: http
  installLock: "false"

ingress:
  enabled: true
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-staging
  hosts:
    - host: gitea-keycloak.ssotest.staging.talkingquickly.co.uk
      paths: ['/']
  tls:
   - secretName: gitea-keycloak-https-secret
     hosts:
       - gitea-keycloak.ssotest.staging.talkingquickly.co.uk

编辑结束之后，用 Gitea 安装：

helm3 upgrade --install gitea-keycloak ./charts/gitea --values ./gitea/values-gitea.yml

安装结束之后，我们在 Gitea Pod 里用客户端创建一个初始用户 administrator，注意修改其中的 YOUR_PASSWORD 和 YOUR_EMAIL 字段：

kubectl exec -it --namespace identity \
      $(kubectl get pods -n identity --selector='app.kubernetes.io/instance=gitea' -o jsonpath='{.items[0].metadata.name}') \
      -- gitea admin user create --username YOUR_EMAIL --password YOUR_PASSWORD --email YOUR_EMAIL --admin --access-token --must-change-password=false

这样我们就能登录 Gitea 实例了。

Gitea 的 LDAP 配置

Gitea 支持的 ODIC 登录仅适用于现存用户，不利于中心化的用户管理，所以我们选用 LDAP。

Github 上的 Gitea 仓库有个 Issue 解释了 OIDC 和 LDAP 的差异。

用 administrator 身份登录 Gitea，并进入 Site Administrator -> Authentication Sources，在 Add Authentication Source 选择 LDAP (via BindDN) 作为认证源。进行如下配置：

Authentication Name：OpenLDAP；
Security Protocol：Unencrypted；
Host：openldap.identity.svc.cluster.local；
Port：389；
Bind DN：cn=readonly,dc=k4stest4,dc=talkingquickly,dc=co,dc=uk；
Bind Password：这个应该是在 values-openldap.yml 文件中设置的只读用户密码；
User Search Base：ou=People,dc=k4stest4,dc=talkingquickly,dc=co,dc=uk 注意根据实际情况替换 dc。
User Filter：(&(objectClass=inetOrgPerson)(uid=%s)) 的配置允许所有用户登录 Gitea，当然可以创建更复杂的过滤器，只允许特定群组（例如 Engineers）成员登录，How to write ldap search filters 一文讲解了过滤器编写方面的知识。uid=%s 让用户可以使用用户名登录，可以修改过滤器同时匹配邮件和用户名；
Username Attribute：uid；
First Name Attribute：cn；
Surname attribute：sn；
Email Attribute：mail。

Gitea LDAP 文档中介绍了更多的细节内容。

注意如果我们要用配置管理工具管理 Gitea，可以使用前面创建管理账号的方法。要用 CLI 创建 LDAP 配置可以参考 Gitea 的命令文档。

如果回到 Gitea 的登录页面，我们会发现可以直接用 Keycloak 中创建的用户凭据登录。注意要使用 master realm 中的用户而非管理用户。

这个过程没有重定向，密码认证会在后台执行。如果我们进入该用户的 security settings 页面，因为用户是外部托管的，无法在 Gitea 中修改密码，只能在 Keycloak 做管理。

配置 Gitea 使用 OpenID

OpenID Connect 无法在 Gitea 中使用完整的 SSO。（Gitea 的）底层用户必须已经存在，对于已经登录的用户是可以配置的，要配置 Keycloak 的 OIDC，从而用户可以通过 Keycloak 流程进行登录，而不用直接在 Gitea 中输入他们的 Keycloak 用户名和密码。

这种方式的唯一好处就是，扩展使用 Keycloak 让用户能够更方便的登录，少输入用户名和密码。所以这个选项不像其它方法一样完整。

在 Keycloak 管理界面中，进入侧面菜单的 Clients 页面，并选择 Create。给 Gitea 输入 Client ID 并设置 Client Protocol 为 openid-connect，设置如下内容：

Name：Gitea；
Access Type：confidential 要生成客户端 Secret，就需要这样填写；
Valid Redirect URI’s：https://GITEA_INGRESS_URL/（例如 https://gitea-keycloak.k4stest4.talkingquickly.co.uk/*）

保存之后，就可以在 Credentials 页面中找到客户端的 Secret。

在 Gitea 中进入 Site Administration 并选择 Authentication Sources，然后选择 Add Authentication Source，填写下列内容：

Authentication Type：OAuth2；
Authentication Name：Keycloak；
OAuth2 Provider：OpenID Connect；
Client ID：gitea（创建客户端应用时输入的值）；
Client Secret：YOUR_SECRET（在 Keycloak 客户端页面的 Credentials 卡片上为 Gitea 客户端创建的 Secret）；
OpenID Connect Auto Discovery URL：https://YOUR_KEYCLOAK_INGRESS_URL/auth/realms/master/.well-known/openid-configuration 用 Keycloak 的 Ingress 主机名替换 YOUR_KEYCLOAK_INGRESS_URL。

需要着重关注的是，Gitea 会在创建 Provider 的时候进行证书认证，所以如果 SSL 证书无效的时候是无法完成的。

在尝试登录之前，我们需要给在 Keycloak 中创建的用户设置一个密码。可以通过进入 Keycloak 用户页面，选择 Credentials 卡片并设置一个密码，如果设置 Temporary 为 1，则用户登录时，会被要求设置新密码。

这样我们就可以进入 Gitea 的登录页面，点击 Sign in with OpenID Connect 选项（如果已经登录，就需要登出当前用户）。这样会重定向到 Keycloak 登录页面，在这页面中我们可以用前面创建的 Keycloak 用户名进行登录。

使用 Keycloak 的用户名和密码进行登录之后，就会重定向回到 Gitea。

简易的 Docker 镜像库

本节我们会讲解如何使用 Keycloak 作为 Docker 镜像库的认证层。这样用户必须使用 Keycloak 中的有效凭据完成 docker login 才能够进行 push 和 pull。注意这里没有什么访问控制，所有 Keycloak 用户都能够对任何镜像执行任何动作。要进行细粒度的控制，还是需要使用 Harbor。

配置 Keycloak

Keycloak 的 Helm values 文件中需要加入如下内容：

args:
  - -Dkeycloak.profile.feature.docker=enabled

这样就能启用 Docker 镜像库的支持了。

Keycloak 中的 Docker registry 配置

在 Keycloak 中创建新的客户应用，命名为 simple-docker-registry，协议选择 docker-v2。在后续界面中进入 install 卡片，选择 Docker Compose YAML，然后点击 Download。我们并不是要使用 Docker Compose，这个过程是为了便捷地获取证书，用于创建 Kubernetes Secret。

创建 Secret

从 Keycloak 中得到 Docker Compose YAML 压缩包之后，解压到本地文件夹，会看到其中包含了 certs/localhost_trust_chain.pem 文件。我们可以用下面的命令创建 Kubernetes：

kubectl create secret generic docker-registry-auth-token-rootcertbundle --from-file YOUR_PATH_TO/certs/localhost_trust_chain.pem

上述命令中需要用本地路径来替换 YOUR_PATH_TO/certs/localhost_trust_chain.pem。执行之后就创建了一个名为 docker-registry-auth-token-rootcertbundle 的 Secret，其中包含了必要的证书内容。

配置镜像仓库

用 Helm 安装 Docker 镜像仓库的文档：https://github.com/twuni/docker-registry.helm。我们的配置文件大致如下：

configData:
  auth:
    token:
      realm: https://sso.ssotest.staging.talkingquickly.co.uk/auth/realms/master/protocol/docker-v2/auth
      service: simple-docker-registry
      issuer: https://sso.ssotest.staging.talkingquickly.co.uk/auth/realms/master
      rootcertbundle: /root-cert-bundle/localhost_trust_chain.pem
ingress:
  enabled: true
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-production
  hosts:
    - registry-keycloak.ssotest.staging.talkingquickly.co.uk

  tls:
  - hosts:
    - registry-keycloak.ssotest.staging.talkingquickly.co.uk
    secretName: keycloak-registry-tls-secret

extraVolumes:
  - name: docker-registry-auth-token-rootcertbundle
    secret:
      secretName: docker-registry-auth-token-rootcertbundle

extraVolumeMounts:
  - mountPath: /root-cert-bundle
    name: docker-registry-auth-token-rootcertbundle
    readOnly: true

这里的配置来源于 Keycloak 文档，configData 字段配置使用基于 Keycloak 的 Token 认证。

接下来需要更新 Ingress 定义，加入 Docker 镜像库的 URL，例如 registry-keycloak.ssotest.staging.talkingquickly.co.uk。nginx.ingress.kubernetes.io/proxy-body-size: "0" 这一行注解移除了 Ningx 的最大 Body 长度限制，避免推送大镜像时出现的 413 Request Entity Too Large 错误信息。

extraVolumes 节创建了一个存储卷，用来加载我们的 docker-registry-auth-token-rootcertbundle Secret。extraVolumeMounts 一节将这个卷加载到 Docker 镜像库的 /root-cert-bundle 路径，和 configData 中配置的 rootcertbundle 一致。

安装 Docker 镜像库

使用 Helm 安装镜像仓库：

helm repo add twuni https://helm.twun.io
helm upgrade --install simple-docker-registry twuni/docker-registry --values ./docker-registry/values-docker-registry.yml

测试镜像库

我们需要等待一段时间，让 LetsEncrypt 生成证书，我们可以用 kubectl get certificates 命令查看进度。完成之后就能够进行登录了：

docker login registry-keycloak.ssotest.staging.talkingquickly.co.uk

上边的 URL 应该替换为我们的 Ingress 地址。可以输入 Keycloak 用户名进行认证：

sername: someusername
Password:
WARNING! Your password will be stored unencrypted in /home/ben/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

测试一下镜像推送和拉取：

docker image tag SOME_IMAGE_REF registry-keycloak.ssotest.staging.talkingquickly.co.uk/SOME_NAME
docker push registry-keycloak.ssotest.staging.talkingquickly.co.uk/SOME_NAME
docker pull registry-keycloak.ssotest.staging.talkingquickly.co.uk/SOME_NAME

会看到两种操作都成功了。

登出再试试看：

docker logout registry-keycloak.ssotest.staging.talkingquickly.co.uk
docker pull registry-keycloak.ssotest.staging.talkingquickly.co.uk/SOME_NAME

会看到拒绝访问的错误信息。

在 Kubernetes 中使用

为了访问仓库中的镜像，需要创建合适的 Image Pull Secret，可以参看 Kubernetes 文档完成这个过程。

总结

我们现在就有了一个只允许 Keycloak 认证用户访问的 Docker 镜像库。想要更高级的配置，例如只有特定用户才能访问仓库，或者更细粒度的访问控制，应该换用 Harbor。

用 Keycloak 为 Harbor 提供单点登录，实现完整镜像仓库功能

安装 Harbor

官方提供了 Helm Chart。

和多数 Helm Chart 一样，values 文件内容相当丰富。接下来我们会定制 Ingress 内容和 TLS 证书。必须在安装完成之后使用 Web UI 或者 API 配置 OIDC。我们的 Values 配置包含如下内容：

expose:
  type: ingress
  tls:
    certSource: secret
    secret:
      secretName: harbor-ingress-tls
  ingress:
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt-production

    hosts:
      core: core.harbor.ssotest.staging.talkingquickly.co.uk

harborAdminPassword: 85nsafg87ehfgk0fgsgfg6u
externalURL: https://core.harbor.ssotest.staging.talkingquickly.co.uk
secretKey: "8d10dlskeit8fhtg"

notary:
  enabled: false

metrics:
  enabled: true

有几个需要注意的配置：

certSource：secret，其中包含 secretName: harbor-ingress-tls 告知 Harbor 使用 Cert Manager 为 Ingress 生成的证书，而不是自行生成。这样就避免 docker login 时出现 x509: certificate signed by unknown authority；
core：Ingress URL 应该用 Harbor URL 替换；
harbourAdminPassword、externalURL 以及 secretKey：都要替换为当前环境的配置内容，secretKey 应该是一个随机的 16 字符。

加入 Helm 仓库，并安装 Harbor：

helm repo add harbor https://helm.goharbor.io
helm upgrade --install harbor-registry harbor/harbor --values=./harbor/values-harbor.yml

命令结束之后，我们就可以使用 Ingress URL 访问 Harbor 了，用户名是 admin，密码则是 harbourAdminPassword 中的配置内容。这些组件启动需要一段时间，通常还会看到一些 CrashLoopBackoff 之类的信息出现。

记住还不能用 Harbor 管理员账号进行 docker login，目前 Harbor 中还没有任何的常规用户。因为要切换到 OIDC 登录，所以除了管理用户，我们不会创建任何常规用户。如果我们现在创建了测试用户，然后再删掉，我们还是不能切换到 OIDC 登录。

创建 Keycloak 客户端应用

在 Keycloak 中创建一个新的客户端应用，ID 为 harbor，客户端协议为 openid-connect，并进行如下配置：

Access Type：confidential
Valid Redirect URIs：https://YOUR_HARBOR_CORE_INGRESS_DOMAIN/c/oidc/callback

然后保存客户端应用配置，记录 credentials 卡片的内容。

最后来到客户端应用的 Mappers 卡片创建如下的协议映射关系：

Name：Groups；
Mapper Type：Group Membership；
Token Claim Name：groups；
All Other Options：On。

配置 Harbor OIDC

通过 Ingress 地址使用用户名 admin 和 harborAdminPassword 中配置的密码登录到 Harbor 界面。进入 Administration 页面，接下来打开 Configuration 并选择 Authentication 卡片，修改 Auth Mode 为 OIDC，输入下列配置：

OIDC Provider Name：Keycloak；
OIDC Endpoint：https://YOUR_KEYCLOAK_BASE_URL/auth/realms/YOURREALM；
OIDC Client ID：harbor；
OIDC Client Secret：前面记录的客户端应用凭据；
Group Claim Name：groups；
OIDC Scope：openid,profile,email,offline_access；
Verify Certificate：根据实际情况决定；
Automatic Onboarding：checked；
Username Claim：preferred_username。

然后就可以使用 Test OIDC Server 按钮来测试配置，成功后点击 Save。

测试

如果我们现在登出管理账号（或者启动一个匿名浏览器），回到 Harbor Core 的 Ingress URL，会看到一个 Login with OIDC Provider 选项。选择这个选项之后，会被重定向到 Keycloak 进行登录，这里我们应该使用一个常规 Keycloak 用户（Master Realm），不要用 Keycloak 管理用户。登录到 Harbor 之后，Harbor 会自动根据 Keycloak 的配置创建一个用户名。

回到管理员账号，进入Administrator 和 Groups，就会看到 Keycloak 用户所属群组已经被复制到 Harbor。这意味着可以把特定的群组连接到特定项目，从而自动授予用户某个项目的访问权限。

默认情况下所有用户都能创建项目。所有 Keycloak 用户都能登录到 Harbor，所以最好只允许管理员能够创建项目，可以用 Harbor 的 Administration/Configuration/System Settings 来完成这一限制。

可以用管理员身份进行测试，创建一个叫做 test1 的私有项目，浏览项目的 Members 卡片，选择 + Group，输出 /Administrators 作为群组名称，并设置角色为 Project Admin。 Keyclok 的 Administrators 所有用户都能自动被授予该项目的 Project Admin 权限。

使用 Docker

假设我们创建了叫做 test1 的私有项目，并让我们的 Keycloak Master Realm 账号能够访问这个项目，我们就能够使用 Docker 客户端登录了，例如 docker login core.harbor.ssotest.staging.talkingquickly.co.uk。

然后输入 Keycloak 的 Master realm 中的用户名。而密码不应该使用 Keycloak 的密码，而是从 Harbor 获取，在用户页面右上角选择 User Profile，在其中拷贝 CLI 密码。

然后尝试推送镜像：

docker tag SOURCE_IMAGE[:TAG] core.harbor.ssotest.staging.talkingquickly.co.uk/test1/REPOSITORY[:TAG]
docker push core.harbor.ssotest.staging.talkingquickly.co.uk/test1/REPOSITORY[:TAG]

如果我们要在 CI 服务器或者 Kubernetes 中使用这个仓库，可以在 Harbor 中进入 Robot Accounts 卡片生成受限的访问 Token。

从命令行中配置 Harbor OIDC

Ansible 之类的自动化环境中是非常需要从命令行中完成任务的。因此 Harbor 提供了完善的 API，用管理员账号登录，点击底部的 Harbor API v2.0，就能通过 Swagger 查看 API 文档。缺省情况下可以用 YOUR_INGRESS_URL/api/v2.0/ 访问 API。要查看当前配置可以使用：

curl -u "admin:HARBOR_ADMIN_PASSWORD" -H "Content-Type: application/json" -ki YOUR_INGRESS_URL/api/v2.0/configurations

目前为止，Harbor 官网文档有些滞后，实际的命令返回内容中，为现有配置的可选项目提供了更好的概括信息。用命令行设置 OIDC 认证：

curl -X PUT -u "admin:YOUR_ADMIN_PASSWORD" -H "Content-Type: application/json" -ki YOUR_HARBOR_CORE_INGRESS_URL/api/v2.0/configurations -d'{"auth_mode":"oidc_auth", "oidc_name":"Keycloak Auth", "oidc_endpoint":"YOUR_KEYCLOAK_REALM_INGRESS", "oidc_client_id":"harbor", "oidc_client_secret":"YOUR_KEYCLOAK_CLIENT_SECRET", "oidc_scope":"openid,profile,email,offline_access", "oidc_groups_claim":"groups", "oidc_auto_onboard":"true", "oidc_user_claim":"preferred_username"}'

返回状态码为 200，表明我们已经成功地完成了 Keycloak 认证设置。然后做出限制，只有管理员才能创建项目：

curl -X PUT -u "admin:YOUR_ADMIN_PASSWORD" -H "Content-Type: application/json" -ki YOUR_HARBOR_CORE_INGRESS_URL/api/v2.0/configurations -d '{"project_creation_restriction":"adminonly"}'

Harbor API 非常全面，例如我们可以使用 API 创建项目，并为群组授权访问该项目。因此它的 Swagger API 非常值得一看。

在 Kubernetes 中使用

要在 Kubernetes 中访问这个仓库，需要根据官方文档，使用项目的 Robot Token 创建合适的 Image Pull Secret。

结论

我们现在有了一个自托管的 Docker 镜像仓库，并且完全集成了 Keycloak 进行认证。如果想要用 Ansible、Chef 之类的配置管理工具，还能使用命令行完成这些配置。

关于 KubeArmor 的闲言碎语

Tue, 11 May 2021 22:48:19 +0800

早上看到了一篇关于 KubeArmor 的简介，觉得还挺新鲜的，就坐下看了一下介绍，并没有进行实际的测试，把它和我之前比较熟悉的一些类似技术做一点比较。

上图是官方提供的架构说明，它依赖于 AppArmor、SeLinux（下个版本）以及 KRSI（未来）这样的 LSM，对容器中的进程进行监控和限制，借助 eBPF 技术将进程信息和 Kubernetes 关联起来，从而获取到进程的 K8s 相关信息，能够根据策略阻止或者上报违规行为，并把过程发送到日志、标准输出以及 gRPC 目标之中，未来还会支持数据库、Kafka、ES 等。目前关注的行为包括以下几个方面

进程执行
文件访问
网络操作
Capabilities

它的定义和 PSP 以及 SecurityContext 都不同，采用了类似 Kyverno 类似的方式，定义规则，然后用 Label Selector 将策略关联到 Pod 上，例如源码中提供的例子：

apiVersion: security.accuknox.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-ubuntu-1-proc-dir-block
  namespace: multiubuntu
spec:
  selector:
    matchLabels:
      container: ubuntu-1
  process:
    matchDirectories:
    - dir: /sbin/
  action:
    Block

规则针对标签 container=ubuntu-1 的 Pod 中的容器，禁止执行 /sbin/ 下的命令。

个人觉得功能方面最相似的工具就是 Falco 了，它的配置无疑比相对“传统”的 Falco 方便了许多，并且还有 BLOCK 能力；但是其输入条件的丰富程度是远不如 Falco 的，例如对 ServiceAccount、Verb、Subresource 等 K8s 特定元数据的输入支持，条件语法也不如 Falco 灵活。

以下结论纯属胡说

OPA/Kyverno 有这种功能就有意思了。

项目地址：https://github.com/accuknox/KubeArmor

《我曾目睹的微服务灾难》的读后感

Sun, 09 May 2021 10:54:22 +0800

2011-2012 年，我所在的团队正在给某国字号企业交付一个集团级的企业应用，这个应用覆盖了除 IaaS 之外的整个上层，层级和宽度上来说都算得上是个大家伙了。在当时，这个项目有几个新鲜的点，例如硬件全部采用通用的 x86 刀片服务器，全部基础软件都使用了开源软件——例如 LAMP、Nginx、MongoDB（是的你没看错，就是 MongoDB），使用 Java、PHP、ASP.NET 等多种平台的多个厂商协作交付；除此之外，还设计了和当时大行其道的 SoA 不太一样的一种架构，这个架构有几个特点：

因为其中几百个子系统都是为各自不同的业务（部门）服务的，换句话说，其实我当时的建设过程是多个建设方对应多个甲方的，因此我们采取的策略是以业务为核心，用高内聚低耦合的基本原则进行子系统的拆分。
提供一种基于 HTTP 的二进制传输协议，不同开发商依照约定接口各自用各自的开发平台和各自的数据库进行开发和交付。
部分全局能力，例如认证鉴权、门户、PaaS 级服务及其 SDK 由总集成商提供。
对于高负载应用，其横向扩展能力是首要考量标准（在那个年代，扩缩容是个复杂且高危的操作），在满足业务需求的基本条件下，对子系统中的模块，按照若干原则进行拆分为不同进程：
- 可扩缩和不可扩缩容的模块
- 扩缩容不同步的模块
- 负载规模不一致的不同模块

总的说来这次交付是相当成功的，然而无损创新是不太符合历史规律的，这种架构带来的问题同样挠头：

数据流转：前面提到，很多子系统会使用自己的数据库，所以有些数据需要在不同子系统之间进行流转，就有可能造成数出多头的问题。
监控要求高：刀片服务器和小型机相比，数量大增、性能和稳定性又稍有不足，因此对硬件和系统进行监控的需求就陡然提高，另外因为进程之间、节点之间通信次数和通信量的暴涨，对于网络连通性、磁盘和网络 IO 等的监控需求也是水涨船高。
运维难度大：不同的应用、不同的平台、大量进程，还有更要命的不同的数据库，对运维团队的要求极高（事实上离开项目一年之后我还能听到来自该项目运维团队的骂声。）
….

回到《灾难》一文，其中提到的很多更加具体的点，摘抄几点，一起休闲一下。

灾难一：服务太小

20 名工程师组成了维护 50 项服务的小组。一人负责一项服务还不够！：我一直认为，微服务是一个向现实妥协的过程，这个现实应该是全面的，它不仅是业务的现实、也是团队能力的现实，这个语境下所提倡的全能小团队，其能力虽然宽泛，但即使是业务软件也是有其服务上限的，不尊重业务负载和不尊重团队负载，并没有什么区别。量入为出是个基本要求。

Another smell was when someone told me that deploying a new feature in service A also needed a deployment — at the same time — in service B.（有人要求我把一个新功能同时部署到两个不同服务之中）：这个例子很有代表性，这里的 Someone 同时是 Service A 和 Service B 两个不同服务的所有者或者部分所有者。所以这一点就面临几个问题：

这两个服务应该分开的么？为什么会共享同一个功能？
新功能是不是应该拆分开来，成为第三个服务？
Someone 到底是谁？

与仅仅在 IDE 中查看一个项目不同，人们需要一次打开多个项目才能了解所有这些混乱的情况。：其实即使是一个单体应用，只要它规模太大，在外人来说也是很难突然就能够 “make sense of all that mess” 了——别人的代码在功能和非功能层面满足服务要求，没有在边界外造成不良影响，按照契约进行开发和测试，根据讲定的边界做好各种限制各种观测，为啥非要把手伸那么长呢，是职责不清还是拆分有误？

灾难二：开发环境

Mobile developers not developing a feature before it was in a development environment or backend developers who wanted to try their service didn’t break any business flow. It was also problematic if someone wanted to test the whole flow in a mobile app before production.：这个问题涉及到的是依赖服务之间的协作开发的问题，实际上所有不同实体之间的调用，不管是内部的函数调用、还是古代的 COM+、CORBA，后来的 WebService/RESTful 等等，都面临同样的环境和上下游依赖问题。至于后续的若干的问题，实际上都是全局角度上的微服务治理问题——其实不管有没有微服务，协作单元多了一定会出现这种情况，像 Grafana Stack、ES Stack、Skywalking 等观测技术，以及 Service Mesh 等的网格技术，都是为了解决这样的难题的。十二要素、云原生等方法也给出了相对具体的设计、部署和运行方法的支持。

灾难三：端到端测试

这个——非常特别同意。

灾难四：巨大的共享数据库

这个其实应该属于典型的人祸了，到现在应该没人会认为共享数据库的多个进程能够称之为微服务了。

灾难五：API 网关

Suddenly, you have your “API gateway” being a single-point-of-failure — because people find it easier to handle authentication in a single place — and with some unintended business logic inside it. Instead of having a monolith getting all of the traffic, now you have a home-made Spring Boot service getting all of it!：网关和服务网格这样的产品，发展下来经常会扩展成具备大量功能的超级工具，这给人一种联想——上了工具之后写写配置就有功能用了这实在是太棒了。然而 Java 开发者或者 YAML 工程师都会知道，配置这事太难了，以至于出现了 OPA、PIPY 这样直接让配置工程师撸代码的“反潮流”工具。

事实上采用一个开源/第三方软件或者库，因其规模不同，对应的评价工作量是完全不同的，尤其对于 Kong、Istio 这样的大家伙来说，比起“用不用”的问题来说，“用多少”和“怎么用”的问题可能更加复杂，动辄“全面拥抱”可能是一个非常冒险的行为。

灾难六：超时、重试和弹性

这个似乎是服务间调用的普遍情况，我不确定这是微服务的锅。

结论

在实施转型或者说改造的过程中，难免会遇到这样那样的问题，然而微服务其实并没有什么特别的——就特别多、特别碎。如果能在全局层面做好观测、做好治理，练好基本功，让每个服务都能各司其职又不互相妨碍，是不是微服务又能有什么关系呢。微服务是为业务服务，同现状和解的，抛开目的和现实，单纯为微服务而微服务，很可能除了话题，一无所获。

参考阅读

做云自缚——应用上云之路

Tue, 27 Apr 2021 16:48:14 +0800

今天扯个闲篇，说说应用上云的事情。

最近这几年，一直都在围着“应用上云”这四个字转悠，看到很多成功的和不太成功的应用上云活动，是的——一个失败的都没有，所以云原生真是厉害，对吧？

应用上云成功了会怎么样呢？一般成功案例会共享的几个好处：

应用更快交付、能用更高的频率迭代
更高的应用密度，更有效地使用资源
监控日志等可观察性方面的增强
弹性伸缩在削峰填谷方面的卓越表现
…

如果用上了 Service Mesh 或者类似微服务治理技术，多半还会提到分布式追踪、熔断、限流等的好处。

然而面对这种种诱人后果的展示时，很多像我一样的中老年 IT 人可能都会发出一句常见的老年人诘问：这些东西以前没有吗？

Jenkins 的前身 Hudson 诞生于 2004 年，2011 年定名 Jenkins。
Maven 大约诞生于 2001 年。
SonarQube 大约诞生于 2007 年。
Zabbix 也二十多岁了。
SpringCloud 其实跟 Kubernetes 几乎同龄。

所以是什么让云原生的林林总总从厚重的历史中脱颖而出的？我认为是 Docker，那个 “Build once, Run anywhere, Configure once, Run anything” 的 Docker。在 Docker 出现之前，IT 界为了造词疲于奔命，从 CMM 到敏捷、从 CI/CD 到 DevOps，另外还有十二要素、微服务、重构等等的方法。而 Docker 出现之后，随着 Google 不断的勒索，Docker 提出的容器镜像打包和运行标准，逐步“贡献”出来成为开放标准，CxI 已经成为云原生世界中最重要的标准群。

名言说：无产阶级失去的只是枷锁，而他们获得的将是整个世界。而我理解的云原生，跟这个口号恰好相反——软件通过自投罗网的方式，交出部分自由，获得自称云原生的资格。“自废武功”的应用有多不自由呢？

要清楚地了解从操作系统、构建系统、软件库等的依赖，用内聚的方式进行打包，形成单一的容器镜像（文件）
为了能在通用且较为低配的容器节点上顺利运行，通常需要对软件的资源规模有一个足够进行量化的认识，甚至需要为了资源、容量等问题对应用进行拆分。
为了进行扩缩容，微服务提供的服务接口要努力摒弃状态，实现幂等，甚至还要完善健康检查、优雅退出等以前不关注的边角料功能。
甚至连临时文件和日志都不能随意输出了。
…

在应用屈服了之后，过去一直无法施展拳脚的很多方法和工具也焕发了新生——例如 DevOps、敏捷、微服务，甚至还诞生了更具通用性的服务网格、更大跨度的分布式追踪等“更厚”的基础设施。这些先进又复杂的底层设施，因为面对的是具备通用性的业务应用，也具备了明确的支持能力。

结论

好好打镜像，好好写 YAML，我们都有美好的未来。

在 Kubernetes 中检查镜像签名

Tue, 20 Apr 2021 00:42:38 +0800

之前连续写了几篇 Shell Operator 的东西，后来又写了一篇 cosign 的介绍，细心的读者可能会猜到，最终我的目的就是会用 Shell Operator 结合 cosign 来检查镜像的签名，以此保障镜像的完整性——是的，这个过程相当容易。

Shell Operator 除了初期的调度和 Prometheus Exporter 功能之外，最近又加入了 Validating Webhook 的能力，和以前的几篇文章的内容结合起来，能非常轻松地实现检查镜像签名的能力。

简单地设计如下功能：

创建密钥对，以私钥对镜像进行签名，公钥用 Secret 的形式保存进集群。
创建 Shell Operator 配置，只针对打出了特定标签的命名空间中的对象进行检查。
配置保存为 Configmap。
部署 Shell Operator 组成的 Validating Webhook.
在特定命名空间中创建工作负载，触发校验功能。
Shell Operator 使用公钥进行校验，校验通过才能成功运行。

我们给 Webhook 编写如下配置：

  config:
    namespace:
      labelSelector:
        matchLabels:
          signed: "required"
    rules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
      scope:       "Namespaced"

配置内容声明，仅对标签为 signed=required 的命名空间中的 Deployments 对象生效。将配置文件生成为 Configmap，保存到 Configmap 中，运行期加载为存储卷，然后就可以在代码中如此调用：

parser = argparse.ArgumentParser(description='Pod hook for Shell-Operator')
parser.add_argument('--config', action='store_true')
args = parser.parse_args()
CONFIG_FILE = os.getenv("CONFIG_FILE", "/etc/cosign-validator/config.yaml")

if args.config:
    with open(CONFIG_FILE) as cfg:
        print("".join(cfg.readlines()))
    sys.exit(0)

公钥文件保存在 Secret 里，这里假设我们加载为 /etc/cosign-keys/cosign.pub，就可以用如下代码进行校验：

# 响应文件名称
RESPONSE_FILE = os.getenv("VALIDATING_RESPONSE_PATH")
...
    key_file = "/etc/cosign-keys/cosign.pub"
    for container in json_obj[0]["review"]["request"]["object"]["spec"]["template"]["spec"]["containers"]:
        image = container["image"]
        try:
            # TODO: Read public key name from annotation
            subprocess.check_call([
                "/usr/local/bin/cosign",
                "verify", "-key", key_file, image])
        except subprocess.CalledProcessError:
            message = image
            break
...
with open(RESPONSE_FILE, "w") as writer:
    if len(message) == 0:
        writer.write('{"allowed":true}')
    else:
        content = '{"allowed":false, "message":"The image ' + message +' is not signed properly"}'
        writer.write(content)

主体代码之后，就需要考虑如何部署了，首先要生成 Docker 镜像：

# 一段构建，生成 cosign
FROM golang:1.16.2-alpine3.13 as builder
RUN apk add --no-cache git=2.30.2-r0
RUN go install github.com/sigstore/cosign/cmd/cosign@v0.1.0
# 二段构建，加入代码到 hooks 目录
FROM flant/shell-operator:v1.0.0-rc.2
RUN apk --no-cache add python3=3.8.8-r0
COPY --from=builder /go/bin/cosign /usr/local/bin
COPY cosign-validation.py /hooks

Webhook 需要根据服务名称等信息生成证书用于和 API Server 之间的通信过程，此处略过，可以直接参看源代码。另外为了能够注册服务，还需要一个具备权限的 ClusterRole：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cosign-validator
rules:
- apiGroups: ["admissionregistration.k8s.io"]
  resources:
  - validatingwebhookconfigurations
  verbs:
  - list
  - create
  - update

这些对象和证书可以用 Helm Chart 组织起来，进行集成安装部署。

部署成功后，可以尝试分别使用签名和未签名镜像进行部署，会看到未签名镜像会被拒绝。详细操作和测试过程可以参见视频。

项目代码：https://github.com/fleeto/sign-validator

在 Kubernetes 读取 Vault 中的机密信息

Wed, 14 Apr 2021 15:03:13 +0800

在 Kubernetes 中，我们通常会使用 Secret 对象来保存密码、证书等机密内容，然而 kubeadm 缺省部署的情况下，Secret 内容是用明文方式存储在 ETCD 数据库中的。能够轻松的用 etcdctl 工具获取到 Secret 的内容。通过修改 --encryption-provider-config 参数可以使用静态加密或者 KMS Server 的方式提高 Secret 数据的安全性，这种方式要求修改 API Server 的参数，在托管环境下可能没有那么方便，Hashicorp Vault 提供了一个变通的方式，用 Sidecar 把 Vault 中的内容加载成为业务容器中的文件。

安装和启动 Vault

官网提供了各种系统中的安装指导，例如 CentOS 中可以用包管理器来安装：

$ yum install -y yum-utils
$ yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
$ yum -y install vault
...

安装结束后，就可以启动一个开发服务器了：

$ vault server -dev -dev-root-token-id root -dev-listen-address [主机地址]:8200
...
WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
...
You may need to set the following environment variable:

    $ export VAULT_ADDR='http://9.134.14.252:8200'

The unseal key and root token are displayed below in case you want to
seal/unseal the Vault or re-authenticate.

Unseal Key: rpn1ad4t3B4OeUFRAJWUjcmsCmCcEJFaPFjWLbs0IFM=
Root Token: root
...

上面的命令中，指定了登录 Token 为 root，监听地址为 [主机地址]:8200，返回信息中也有提示，开发服务的内容是保存在内存中的，无法适应生产环境的应用。

写入测试数据

首先登陆 Vault：

$ vault login root
Success! You are now authenticated. The token information displayed below
...

然后创建测试数据：

vault kv put secret/devwebapp/config username='giraffe' password='salsa'
Key              Value
---              -----
created_time     2020-08-11T16:59:42.076636Z
deletion_time    n/a
destroyed        false
version          1

在 Kubernetes 中引入 Vault 服务

在 Kubernetes 中可以为 Vault 创建 Endpoint 和 Service，用于为集群内提供服务：

apiVersion: v1
kind: Service
metadata:
  name: external-vault
  namespace: default
spec:
  ports:
  - protocol: TCP
    port: 8200
---
apiVersion: v1
kind: Endpoints
metadata:
  name: external-vault
subsets:
  - addresses:
      - ip: [主机地址]
    ports:
      - port: 8200

这样我们就给外部的 Vault 服务创建了一个集群内的服务端点。接下来创建一个 Deployment 来测试读取数据：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: devwebapp-through-service
  labels:
    app: devwebapp-through-service
spec:
  replicas: 1
  selector:
    matchLabels:
      app: devwebapp-through-service
  template:
    metadata:
      labels:
        app: devwebapp-through-service
    spec:
      containers:
      - name: app
        image: burtlo/devwebapp-ruby:k8s
        imagePullPolicy: Always
        env:
        - name: SERVICE_PORT
          value: "8080"
        - name: VAULT_ADDR
          value: "http://external-vault:8200"

这个镜像中会使用我们预先设置的开发 Token 来访问 Vault 服务，例如：

$ kubectl exec \
    $(kubectl get pod --selector='app=devwebapp-through-service' --output='jsonpath={.items[0].metadata.name}') \
    -- curl -s localhost:8080 ; echo
{"password"=>"salsa", "username"=>"giraffe"}

安装 Vault 注入器

使用 Helm 进行安装：

$ helm repo add hashicorp https://helm.releases.hashicorp.com
"hashicorp" has been added to your repositories
$ helm install vault hashicorp/vault \
    --set "injector.externalVaultAddr=http://external-vault:8200"

这个安装器会创建 RBAC 相关内容，MutatingWebhook 以及用于执行注入的 Deployment 和 Service。

对接 Kubernetes 认证

接下来要让 Vault 接收并许可来自 Kubernetes 的请求：

# 获取 ServiceAccount 的 Token
$ VAULT_HELM_SECRET_NAME=$(kubectl get secrets --output=json | jq -r '.items[].metadata | select(.name|startswith("vault-token-")).name')

# 启用认证方式
$ vault auth enable kubernetes
Success! Enabled kubernetes auth method at: kubernetes/

# 获取 Token 内容
$ TOKEN_REVIEW_JWT=$(kubectl get secret $VAULT_HELM_SECRET_NAME --output='go-template={{ .data.token }}' | base64 --decode)

# 获取 Kubectl 的 CA 证书
$ KUBE_CA_CERT=$(kubectl config view --raw --minify --flatten --output='jsonpath={.clusters[].cluster.certificate-authority-data}' | base64 --decode)

# 获取 API Server 的地址
$ KUBE_HOST=$(kubectl config view --raw --minify --flatten --output='jsonpath={.clusters[].cluster.server}')

准备工作完成之后，就可以把这个认证配置写入 Vault：

$ vault write auth/kubernetes/config \
        token_reviewer_jwt="$TOKEN_REVIEW_JWT" \
        kubernetes_host="$KUBE_HOST" \
        kubernetes_ca_cert="$KUBE_CA_CERT"
...

编写读取策略：

$ vault policy write devwebapp - <<EOF
path "secret/data/devwebapp/config" {
  capabilities = ["read"]
}
EOF

为 Kubernetes 创建授权角色：

$ vault write auth/kubernetes/role/devweb-app \
        bound_service_account_names=internal-app \
        bound_service_account_namespaces=default \
        policies=devwebapp \
        ttl=24h

注入 Sidecar

在测试 Deployment 中加入注解：

...
spec:
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "devweb-app"
        vault.hashicorp.com/agent-inject-secret-credentials.txt: "secret/data/devwebapp/config"
...

上面的注解表明，使用 devweb-app 角色，读取 secret/data/devwebapp/config 中的数据，保存到 /vault/secrets 目录的 credentials.txt 文件之中。

修改之后，等新的 Pod 启动成功。验证一下：

$ kubectl exec -it \
    $(kubectl get pod --selector='app=devwebapp' --output='jsonpath={.items[0].metadata.name}') \
    -c app -- cat /vault/secrets/credentials.txt
data: map[password:salsa username:giraffe]
metadata: map[created_time:2019-12-20T18:17:50.930264759Z deletion_time: destroyed:false version:2]

后记

这实际上是官方案例的一个翻译，另外 Vault 也提供了基于 secrets-store-csi-driver 的挂载方案供选用。

用 Trivy 扫描新操作系统的漏洞

Fri, 09 Apr 2021 23:37:02 +0800

Trivy 是个来自 Aqua Security的漏洞扫描系统，现已经被 Github Action、Harbor 等主流工具集成，能够非常方便的对镜像进行漏洞扫描，其扫描范围除了操作系统及其包管理系统安装的软件包之外，最近还加入了对 Ruby、PHP 等的漏洞检测，应该是该领域目前目前采用最广的开源工具之一了。

在我们使用 Trivy 对系统进行扫描加固的时候，遇到了一个问题，openEuler 这样的年轻操作系统，还没被 Trivy 接入其数据库之中，如何能借助这样的主流工具进行漏洞扫描呢？

漏洞的发现、处理、披露是个复杂的流程，下面引文来自我的译作《容器安全》（《Container Security: Fundamental Technology Concepts that Protect Containerized Applications 1st Edition》(Liz Rice)）：

一旦发现了新的漏洞，赛跑就开始了，系统管理员必须抢先修复漏洞，否则就可能遭受针对性的攻击。如果直接公开发布新问题，就相当于为攻击者开启了利用漏洞的自由竞赛。为了避免这种情况发明了一个概念，叫做负责任的安全披露。发现漏洞的安全研究人员会联系相关软件的开发者或供应商。双方商定一个时限，在这个时限之后，研究人员可以公布他们的发现。在这里，对供应商来说，有一些积极的压力，要求他们努力及时提供修复，因为在公布之前提供修复，对供应商和用户都有好处。新发现的问题会有一个唯一标示符，前缀为 CVE，是 Common Vulnerabilities and Exposures 的缩写，CVE 后面是年份代码。例如 ShellShock 漏洞是 2014 年被发现的，其标示符为 CVE-2014-6271。管理这些编码的机构是 MITRE，MITRE 监管着一些 CVE 编码授权机构（简称 CNA），CNA 能够在特定领域中签发 CVE ID。有些大型软件商（例如微软、红帽以及 Oracle）就是 CNA，能在各自产品范围内授予 CVE 编码。Github 在 2019 年末也获得了 CNA 资格。在 NVD（National Vulnerability Database（国家漏洞数据库））中使用 CVE 编码跟踪受到该漏洞影响的软件包和版本。有了受影响的软件包版本的列表，所以如果当前使用的软件版本出现在这个列表里，是不是代表当前环境已经受到影响了？并不一定，这和当前使用的 Linux 发行版是相关的，可能发行版自身已经针对该软件包发布了一个补丁版本。以 ShellShock 为例。这是一个存在于 GNU Bash 中的严重漏洞。NVD 上的 CVE-2014-6271 页面里列出了一个很长的列表，覆盖了从 1.14.0 到 4.3 的版本范围。如果运行一个旧版本的 Ubuntu 12.04 并且发现其中的 Bash 版本是 4.2-2ubuntu2.2，你可能会认为这是一个基于 bash 4.2 的版本，属于受影响之列。实际上根据 Ubuntu 的官方说法，这个版本已经修复了该漏洞，是安全的。Ubuntu 维护者认为，与其让所有 12.04 用户升级到全新的 bash 版本，不如单独进行补丁并发布一个小的补丁版本。

因此扫描工具除了需要关注 CVE 的通用信息之外，更重要的是引入发行版开发商的安全数据库，才能准确地完成扫描任务。

Trivy 的基本功能

Trivy 工具链

Trivy 自身只是一个扫描工具，实际上支撑这个工具的还有一个工具链，多种工具/库的协同，完成了从 CVE 到扫描识别的各个环节，其中包括：

vuln-list-update：负责更新各个来源的威胁数据，转换成 JSON 数据，保存在 vuln-list 项目之中。
trivy-db：既是工具，也是库，用于操作 Trivy 的数据库。
fanal：从 vuln-list 获取数据，并构建成 bbolt 格式的数据库文件，可以用 upload 命令上传到 Github Release。
Trivy：获取 trivy-db 的 Release 数据，进行漏洞扫描工作。

综上所述，Trivy 的总体工作流程：

从操作系统厂商等 CVE 源获取数据，使用 vuln-list-update 脚本进行汇总，转换为一致的 JSON 数据，保存到 vuln-list 项目。
trivy-db 从 vuln-list 下载数据，转换为 bbolt 格式，发布到 trivy-db 的 Release。
Trivy 下载 trivy-db 数据，作为本地检测的数据源。

Trivy 的扫描流程

Trivy 首先会使用 Fanal 对待扫描镜像进行检测，Fanal 会根据基础镜像哈希码查询缓存（MACOS 中是 ~/Library/Caches/trivy/fanal/fanal.db）中是否保存了对应的“哈希-操作系统”记录，如果没有，则会解压基础镜像层，遍历其中文件，并根据其 analyzer 中包含的各个操作系统的文件特征来判断基础镜像的操作系统，例如 Alpine 的特征文件是 etc/alpine-release，而 Photon 的特征文件是 usr/lib/os-release 和 etc/os-release；如果有，则直接从缓存数据中取出对应的操作系统名称和版本。

ospkg 中的 detect.go 中硬编码了操作系统和扫描器的对应关系，例如：

case fos.RedHat, fos.CentOS:
  return redhat.NewScanner()

确定了具体的扫描器之后，就会调用具体的扫描器，根据漏洞库 ~/Library/Caches/trivy/db/trivy.db 作为数据源进行扫描。

扫描新操作的方法

篡改 Fanal 缓存

如果我们假设新系统可以和 Redhat 8 共享同样的漏洞库，就可以直接在 Fanal 缓存中加入新的的镜像关系，对应到 Redhat 8 上，就能够进行扫描了，例如：

正式一点的方式

篡改缓存的扫描方法是非常不负责的，这大概不会代表真实的操作系统安全现状。根据上文工具链的介绍，应该能清楚地了解到这个过程：

首先要 Fork vuln-list-update，其中加入新操作系统的数据源，并转换为通用格式，例如：

{
    ...
 "cwe": "CWE-120",
  "statement": "",
  "acknowledgement": "",
  "name": "CVE-2021-0326",
  "document_distribution": "",
  "details": [
    "In p2p_copy_client_info of p2p.c, there is a possible out of bounds write due to a missing bounds check. This could lead to remote code execution if the target device is performing a Wi-Fi Direct search, with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-8.1 Android-9Android ID: A-172937525"
  ],
  "references": [
    "https://w1.fi/security/2020-2/wpa_supplicant-p2p-group-info-processing-vulnerability.txt"
  ]
  ...
}

接下来要修改 Fanal，除了在其中加入新系统的甄别方法，例如 /etc/openEuler-release 的解析过程。

然后是创建新操作系统的扫描器，基本上可以参照 Debian/Redhat/Alpine 几个大体系的扫描器完成工作。

上述工作可以通过分叉的方式自己独立运行，也可以通过 PR 的方式回馈给 Trivy 项目组，公开成为通用的扫描方案。

借助 Shell Operator 监控集群中的镜像漏洞

Tue, 30 Mar 2021 22:14:50 +0800

在使用 Shell-Operator，让 Pod 继承节点标签一文中，展示了使用 Shell Operator 在创建工作负载时从对应节点拷贝指定标签的方法。Shell Operator 还有个功能就是生成 Prometheus Metrics，本文就是从这个角度出发，用 Shell Operator 定时调用 Trivy 扫描指定命名空间下的所有在用镜像，并输出指标给 Prometheus，最终可以进行展示和告警。

Shell Operator 除了上次提到的根据 Kubernetes 事件进行触发之外，还包含了在启动时和定期运行两种触发方式，这里我们用定时触发的方式：

configVersion: v1
schedule:
- name: "scan images each 5 min"
  crontab: "*/5 * * * *"
  allowFailure: true

这里我定义了一个 5 分钟触发一次的任务。镜像接受一个缺省为 NS_LABEL="trivy=true" 的标签，每次触发时，会根据这个标签选择命名空间，获取选定命名空间中运行的镜像，并调用 trivy i -f json [image] 输出结果，将结果转换为 Prometheus 指标进行输出。

FROM flant/shell-operator:v1.0.0-rc.2
ENV TRIVY_CACHE_DIR=/data/trivy \
    TRIVY_QUIET=true \
    GITHUB_TOKEN="" \
    NS_LABEL="trivy=true"
RUN apk --no-cache add python3=3.8.8-r0
COPY trivy-scanner.py /hooks
COPY trivy /usr/local/bin
VOLUME [ "/data/trivy", "/data/cache" ]

上文中的几个环境变量：

TRIVY_CACHE_DIR：指定 Trivy 缓存目录，可以在 Kubernetes 中把 Trivy 工作目录持久化。
TRIVY_QUIET：Trivy 环境变量，指定 Trivy 用静默方式运行。
GITHUB_TOKEN：Trivy 会使用该 Token 更新漏洞库，防止触发 Rate Limit。
NS_LABLE：仅对符合标签的命名空间进行扫描。

在脚本中执行的任务还是很简单的三部曲：

kubectl get ns
kubectl get po
trivy

可以看到这里需要列表查看 Namespace 和 Pod 对象，因此我们的 RBAC 需要进行相应的配置，例如设置 ClusterRole：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: trivy-scanner
rules:
- resources:
  - pods
  - namespaces
  verbs:
  - get
  - watch
  - list

实际上也可以通过之前用到的 Kubernetes 事件进行触发。因此这里还保留了 watch 事件。

Deployment 需要注意一点是，Shell Operator 使用 9115 端口的 /metrics 开放指标数据供 Prometheus 抓取，因此需要使用 annotations 对此进行标注。

使用 Trivy 获取到 JSON 格式出具的扫描结果之后，就可以利用 Shell Operator 的指标输出能力，把数据整理为如下格式：

{"name":"so_vulnerabilities","set":0,"labels":{"image":"dustise/sleep:v0.9.6","severity":"UNKNOWN"}}
{"name":"so_vulnerabilities","set":1,"labels":{"image":"dustise/sleep:v0.9.6","severity":"HIGH"}}

每行一条记录，输出到 $METRICS_PATH 环境变量指定的文本文件中，Shell Operator 会把它转换为 Prometheus 指标：

so_vulnerabilities{hook="trivy-scanner.py",image="dustise/sleep:v0.9.6",severity="CRITICAL"} 1
so_vulnerabilities{hook="trivy-scanner.py",image="dustise/sleep:v0.9.6",severity="HIGH"} 11
so_vulnerabilities{hook="trivy-scanner.py",image="dustise/sleep:v0.9.6",severity="LOW"} 2
so_vulnerabilities{hook="trivy-scanner.py",image="dustise/sleep:v0.9.6",severity="MEDIUM"} 9
so_vulnerabilities{hook="trivy-scanner.py",image="dustise/sleep:v0.9.6",severity="UNKNOWN"} 0

接下来就可以在 Prometheus 中检查输出内容，出具监控图表或者制定告警规则了。

在 Kubernetes 中防范 CVS-2016-2183

Fri, 26 Mar 2021 18:56:28 +0800

是的我又被安全团队抓到了，这次是 CVE-2016-2183 漏洞

在 Kubernetes 环境中检查镜像签名的一种方法

Sat, 20 Mar 2021 00:19:56 +0800

Kubernetes 的供应链安全需求中，有一个重要的镜像签署和校验的环节，这个环节可以使用 OPA 结合 Notary 的方式来完成。最近 Linux基金会宣布免费 sigstore 签名服务，以确认软件的来源和真实性，在项目网站闲逛时，发现一个叫做 cosign 的子项目，这是个轻量级的选择，让我非常有兴趣，于是就有了本文。

部署

目前这个工具还没有提供二进制发布，需要克隆源代码，并使用 go 1.5 进行构建，具体方法请参阅项目页面。简单说就是

# git clone https://github.com/sigstore/cosign.git
...
# cd cosign
# go build -o cosign ./cmd/cosign
...

这个工具的最基础功能有三个，分别是生成密钥对、镜像签名和校验签名。

生成密钥对

这个功能是很直白的：

cosign generate-key-pair
Enter password for private key:
Enter again:
Private key written to cosign.key
Public key written to cosign.pub

执行命令之后，输入密码，就会生成密钥对文件，私钥和公钥分别是 consign.key 和 cosign.pub。

签名

可以使用前边生成的密钥对进行签名，例如我的工具镜像：

cosign sign -key cosign.key dustise/sleep:v0.9.6
Enter password for private key:
Pushing signature to: index.docker.io/dustise/sleep:sha256-92dad62e00d08157a3921b7d7b568a247a8b24e8a067ad5dc20b210d7b1c2ad1.cosign

读者需要注意的一点是，这个功能是对仓库中镜像的哈希码生效的，因此签署过程无需本地镜像的参与，cosign 会直接在镜像仓库中获取对应 tag 的 sha256 内容，签署之后生成一个 OCI 镜像推送到该镜像的原有仓库之中，例如前面为 dustise/sleep:v0.9.6 进行签名，就生成了一个 dustise/sleep:sha256-92da.....1c2ad1.cosign 的镜像。如果被签名镜像在本地不存在，在完成操作之后，使用 docker images 命令查看，会发现被签署镜像和签署生成的镜像都不存在于本地。

另外一个就是，因为这里有 Push 操作，因此这个签署过程通常是有登录镜像库的需求的。

校验

校验过程很简单，使用 verify 指令，指定公钥即可，例如：

cosign verify  -key cosign.pub dustise/sleep:v0.9.6
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
  - Any certificates were verified against the Fulcio roots.
...

注意

如果使用 cosign 来进行签署，过程基本上来说还算是愉快的，私钥放置在 CI 之中，而公钥则可以保存在集群里，简单一点的方式，使用客户端定期扫描；复杂的方式，可以实现一个简单的 admission controller 来根据 Selector 对负载进行校验，同样需要注意的是，cosign 只针对远程（镜像库）进行操作，对本地的同 Tag 替换是没什么防御力的，因此这里还要使用 Always Pull 的策略进行弥补（可以使用 Kyverno 或者 Gatekeeper 来强制实施）。

在 Kubernetes 上运行“别人的”应用

Fri, 19 Mar 2021 11:12:29 +0800

在帮助企业进行基于私有环境的云原生转型的过程中，帮客户把存量应用迁移到 Kubenrnetes 上，是个常规任务。通常说来，在解决了初步的技术可行性之后，接下来要解决的就是资源分配的问题，我们已经讨论过，在近乎同样的资源总量情况下，少量大节点构成的集群和大量小节点构成的集群的一些差异，然而这里还是缺少一个完整的方法——如何把现有应用的需求转换为资源设计呢？

调研

要为应用分配资源，首先要明确资源所包含的项目，除了显而易见的 CPU 和内存之外，往往还会包含一些因地制宜的项目，例如：

每节点 Pod 数量上限：例如 Kubernetes 缺省限制为 110，而在新面世的 AutoPilot 中，缺省上限就只有 32 个了。
Pod IP：有些环境中，Pod 会具有神奇的直通 IP，这些 IP 通常是用 IP 池的方式进行管理的，这也是一个受限资源。
GPU：GPU 这种高价资源，自然是受限的，并且不同驱动方式的用法也有不同，例如 TKEStack 的 GPU Manager 能够用千分之一为单位进行分配。
存储：原本运行在虚拟机上的应用可能会使用一定量的存储，在这里需要对其用法进行正确的区分，按需转换为使用临时存储、本地存储、分布式（块/文件）存储。
对集群外提供的服务：所需的域名和转换规则等。
…

在把各种资源分门别类都罗列清楚之后，就可以给业主方设计一份应用资源问卷了，其中应包含如下要素：

工作负载类型：普通服务应用、批处理、定时任务等。
资源需求：应用属主需填写自己每个应用下，每个组件的的副本数量、资源用量上下限；如果存在 HPA 需求，应该了解伸缩的上下限。
权限需求：对于内核能力、root 用户等的特殊要求，如无要求，通常设置为非 root 访问的非特权模式。
注明对内对外的依赖关系：用于后续的网络策略设计。

这里对资源需求部分还有一个需要注意的点就是 Sidecar 以及一些“隐藏”进程，例如监控 Agent 等，这些东西同样会占用系统资源，有时用量还比较大，并且这些进程是随着应用组件实例进行伸缩的，因此其资源需求应该并入到所在的主要进程。

实践过程中，这个步骤会占用相当多的时间，在独占虚拟机/物理机运行时，很多业务方其实并不清楚应用的具体资源需求，是否能够构建镜像、是否能够在 Kubernetes 中运行也都是未知数，因此在调研过程中可能需要进行更多的沟通和培训工作。关于应用自身对 Kubernetes 的适应性，我通常会有几个简单的问题：

能够多副本运行么？
需要用 Root 身份启动么？
能够随意重启么？
能够自动水平扩容么？
重新部署的标准步骤是怎样的？
日志和临时存储的用法和用量？
镜像尺寸。
更新频率和方法。
健康和存活检测的方法。

这些问题本身的答案并不重要，重要的是能够提醒对方，对于自身应用行为应该有一个深入且诚实的了解。

规划

在得到调研结果之后，就可以据此进行设计了。除了调研结果中的几个变量之外，Kubernetes 的实施过程中还包含些隐含的约束条件，这些约束条件一方面限制了对于集群的设计规模，另一方面也能够辅助我们对集群进行资源配置。

节点数量：通常我们会使用 3 Master 的结构设计集群，如果 3 个控制节点如果只有 2 个计算节点，可能会显得非常古怪，因此通常计算节点都应该数倍于管理节点的数量。
Pod 数量：一个生产环境中的计算节点，即使在空载环境下，也会运行一些系统需要的 Daemonset，例如常见的 kube-proxy、node-exporter，所以在一个计算节点上的业务容器数量和资源，至少也不应该少于这些常驻 Pod 的数量。
资源冗余：节点容量通常应该是总量-系统占用-保留量，分配到每个节点上容器（包括业务、系统）的资源 Request 和 Limit 总和，不应超出节点容量。
空余节点：部署应用后，集群所有容器容量上限和集群业务节点总容量的差，最少应该大于集群中的最大计算节点的容量，以此保证在遭遇节点故障时可以有一个基本的容错能力。
服务疏散：一般来说，我们会建议多副本服务平均分散在多个节点之中，因此节点数量不应少于任何服务的副本数量。
节点疏散：在使用虚拟机作为节点时时，建议分布到不同的物理机上，避免因为物理节点故障导致大范围容器节点问题。

在有了这一系列的文档之后，基本上是可以设计出来一个有理有据的合适规模的集群的。

实施和反馈

在应用成功在集群上试运行成功之后，应该有一段重点观察期，我们可以用 Prometheus 对新晋应用进行监控，有几个指标需要重点关注：

容器的重启动次数：应用的最基本存活状况，如果应用发生频繁重启，应该进行有针对性的分析。
应用运行时，各项资源消耗的平均值、中位数、最大值等，将其和应用申请资源的最小和最大值进行比较，以此评估应用的实际资源需求并作出整改。
集群总体资源的消耗和空闲量，以此来评估节点的总体资源使用情况。
存储占用量的监控：防止因为存储溢出造成意外损失。
工作副本设计数和实际数的差：不为 0 的情况需要针对性调查。

补充

这里提到的内容都是非常基础的内容，针对的也是基础的业务应用容器化转型工作。相信在实际工作中，还会有更多的资源考量、监控指标以及非功能性限制加入到这个设计过程中，帮助读者更好地进行集群规模的设计。

介绍一个小工具：KubeNurse——集群网络监控

Mon, 01 Mar 2021 15:57:30 +0800

地址

Kubenurse：https://github.com/postfinance/kubenurse

简介

在 Kubernetes 集群运行中，一个常见故障就是集群内网络故障，经常会因为临时策略变更或者网络抖动导致一些古怪问题，而实际场景里的虚拟机和网络的监控经常是由其它部门管理的，如果从业务和 Kubernetes 这样的上层设施着手，可能需要一些时间才能解决问题。kubenurse 项目使用 HTTP 检测的方式提供了常用的几个监控指标。

这个工具的实现也很直接，用 Daemonset 的形式部署在每个集群节点上，每个 Pod 都会通过 HTTP 检测的方式对上述几种目标分别进行访问，最后用 Prometheus Summary 指标的形式暴露出来用于监控。检测机制如图所示：

每个 Pod 都开放了 8080 的 http 端口，包含以下端点：

/ 或者 /alive：返回本节点信息
/alwayshappy：返回 HTTP 200 用于心跳
/metrics：暴露 Prometheus 指标数据

/alive 返回的节点信息如下：

{
  "api_server_direct": "ok",
  "api_server_dns": "ok",
  "me_ingress": "ok",
  "me_service": "ok",
  "hostname": "kubenurse-1234-x2bwx",
  "neighbourhood_state": "ok",
  "neighbourhood": [
   {
    "PodName": "kubenurse-1234-8fh2x",
    "PodIP": "10.10.10.67",
    "HostIP": "10.12.12.66",
    "NodeName": "k8s-66.example.com",
    "Phase": "Running"
   },
   {
    "PodName": "kubenurse-1234-ffjbs",
    "PodIP": "10.10.10.138",
    "HostIP": "10.12.12.89",
    "NodeName": "k8s-89.example.com",
    "Phase": "Running"
   }
  ],
  "headers": {
   "Accept": [
    "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8"
   ],
   "Accept-Encoding": [
    "gzip, deflate, br"
   ],
   ...
  }
}

可以看到，其中包含了上述所说的几个检测结果。

部署

源码中包含了一个 example 目录，简单地 kubectl apply 就可以完成部署，这里有两个可能需要修改的地方：

缺省命名空间是 kube-system，建议查找替换，并要注意调整 RBAC 授权。
涉及 Ingress 检测，因此要注意提供正确的域名。

监控

部署成功之后，Prometheus 会根据 Daemonset 中的注解采集数据：

...
      annotations:
        prometheus.io/path: "/metrics"
        prometheus.io/port: "8080"
        prometheus.io/scheme: "http"
        prometheus.io/scrape: "true"
...

访问任意 Pod 的 :8080/metrics 端点，会看到如下指标：

kubenurse_errors：如果检测过程中出现错误，这个计数器会进行累加。
kubenurse_request：一个 Summary 类型的指标，正常检测结果的时间消耗分布。

这两个指标使用 type 标签对结果进行标识，对应几种不同的检测目标：

api_server_direct：从节点直接检测 API Server
api_server_dns：从节点通过 DNS 检测 API Server
me_ingress：通过 Ingress 检测本服务 Service
me_service：使用 Service 检测本服务 Service
path_$KUBELET_HOSTNAME：节点之间的互相检测

如此一来，我们就可以根据各种延迟时间的分布情况，以及返回错误的数量来确认集群网络状况了。

注意

节点较多时，每次采集可能会产生 n*(n-1) 次访问，会造成较重负载，可以给 Pod 打标签，并使用标签过滤的方式来减少请求，但是这样一来，就会导致检测结果不够全面的问题，因此还需对实际应用进行权衡。

Kubernetes 策略引擎对比：OPA/Gatekeeper vs Kyverno

Tue, 23 Feb 2021 16:57:55 +0800

Kubernetes 的 Pod Security Policy（PSP）即将被淘汰和移除，所以需要找到一个替代方案来填补这个即将出现的空白。目前看来，Kubernetes 自身并没有准备相应的替代方案，因此需要在 Kubernetes 之外寻求解决之道。CNCF 的两个头部项目可能会成为首选的替代产品，它们分别是基于 Open Policy Agent（OPA）的 Gatekeeper 以及 Kyverno，两个产品各行有千秋，但是目前还没有对这两个产品进行过正式的比较，这就让面临选择的用户无从下手了。这两个项目都是全功能的 Kubernetes 策略引擎，因此其功能不仅限于替代 PSP。本文尝试对 Gatekeeper 和 Kyverno 进行一个中立客观的比较，让用户能够据此作出决策。这里仅从 Kubernetes 的视角来对这两个项目来进行评价。

因为本文仅仅涉及 Kubernetes，因此对后续对 OPA/Gatekeeper 项目会简称为 Gatekeeper。

为了透明起见，我想公开说明我个人的立场。我是 Kyverno 而不是 GateKeeper 的撰稿人。我在 Kyverno 上写过几篇博客，在 Gatekeeper 上则没有。我过去还曾对 OPA Rego 提出过一些批评。然而，我的目标是把所有这些和任何个人感情放在一边，并试图以全新的方式来对待这两个项目，没有任何偏见和偏爱。

在和 Kyverno 和 OPA 两个社区进行平等地沟通，让双方的管理者和贡献者公平地对比较标准和结果进行评论。在参与比较、评论等方面均没有偏向任何项目。

导言

Kubernetes 策略是什么

Kubernetes 的 Pod Security Policy，正如其名字所暗示的，仅是针对 Pod 工作的，是一种用来验证和控制 Pod 及其属性的机制。另外 PSP 只能屏蔽非法 Pod 的创建，无法执行任何补救/纠正措施。而 Gatekeeper 和 Kyverno 的作用范围就不是局限在 Pod 上，并且也有更多更深入的功能，而不只是简单的验证功能。策略引擎是一种能对整个 Kubernetes 环境进行全局控制的方法。

Gatekeeper 简介

Gatekeeper 是一个由 Google、微软等多个公司合作推出的开源项目，后来捐赠给了 CNCF。现已经历了三次迭代。Gatekeeper 是通用策略引擎 Open Policy Agent（OPA）的 Kubernetes 专用实现。由于 Open Policy Agent 与 Gatekeeper 之间的关系，该项目经常被写成“OPA Gatekeeper”来表明这层关系。Gatekeeper 实现了请求验证功能，最近还加入了变异能力。OPA 的一个主要特征是依赖于使用一种叫做 Rego 的专用编程语言，这种语言被用来实现策略决策的必要逻辑。通过 Rego，OPA 能够广泛适用于包括 Kubernetes 在内的多种不同的软件，实现高层次的逻辑操作。

Kyverno 简介

Kyverno 是来自 Nirmata 的开源项目，后来也捐赠给了 CNCF。和 Gatekeeper一样，Kyverno 也是一个具有验证和变异能力的 Kubernetes 策略引擎，但是它还有生成资源的功能，最近还加入了 API 对象查询的能力。与 Gatekeeper 不同，Kyverno 原本就是为 Kubernetes 编写的。和 Gatekeeper 相比，Kyverno 除了对象生成功能之外，还无需专用语言即可编写策略，从实现语言的角度上来看，Kyverno 的模型更为简洁。

对比

下面的三个表格对两个项目的特征和质量进行分类，并试图以最客观的方式进行对比。这些维度分别是：

特征/功能维度用于描述技术属性；
社区/生态系统维度用于描述落地情况和组织属性；
杂项。

特征/功能	Gatekeeper	Kyverno
验证	✅	✅
变异	✅（Alpha）	✅
生成	❌	✅
原生策略对象	✅	✅
监控指标	✅	❌
OpenAPI 验证（`kubectl explain`）	❌	✅
高可用	✅	❌
API 对象查询	✅	✅（Alpha）
具备测试能力的 CLI 工具	✅ 独立的客户端	✅
策略审计	✅	✅

社区/生态系统	Gatekeeper	Kyverno
CNCF 状态	毕业（OPA）	沙箱
合作伙伴生态系统采用（注 1）	◗	◔
Github 状态（星，分叉、版本、提交）	1,543, 280, 38, 510	702, 72, 60, 3,034
社区认同（注 1）	◗	◔
策略样本库	✅	✅

注 1：无精确定义，Gatekeeper 看起来比 Kyverno 采用数量更多，但是并没有具体数字。注 2：无客观标准，Gatekeeper 历史更长，社区认可度可能更高。

杂项	Gatekeeper	Kyverno
需要编程	✅	✅
可以在 Kubernetes 之外工作	✅	❌
诞生时间	2017 年 7 月	2019 年 5 月
创始公司	Styra（OPA）	Nirmata
文档成熟度	◗（注 1）	◕

注 1：并没有统一的评判标准。这里的评价基于 Gatekeeper 的功能，而不是 Rego。

分析

根据前面的功能对比，我做了一个简单的归纳，列出两个产品的优劣，这里只写出了标题内容，并不够详尽。

Gatekeeper 的优势

能够表达非常复杂的策略；
社区更为成熟；
支持多副本模式，更好的可用性和伸缩性。

Gatekeeper 的劣势

需要编程语言支持，该语言的学习曲线较为陡峭，可能会产生大量技术债，并延长交付时间；
变异能力还处在萌芽期；
没有生成能力，意味着它的主要应用场景就在验证方面；
策略复杂冗长，需要多个对象协同实现。

Kyverno 的优势

Kubernetes 风格的策略表达方式，非常易于编写；
成熟的变异能力；
独特的生成和同步能力，扩展了应用场景；
快速交付，场景丰富。

Kyverno 的劣势

受到语言能力的限制，难以实现复杂策略；
较为年轻，社区接受度不高；
API 对象查询能力还很初级；
没有高可用能力（还在路线图阶段）。

警告：下面的内容是我根据前面的对比表和优势劣势列表，再加上自己对这两个工具的体验，以及在云原生社区的走访，综合起来的意见分析。如果你没有兴趣看我的观点，文章就到此为止了。

Kubernetes 是一个声明式的系统：用户向 Kubernetes 提出对状态的要求，Kubernetes 通过各种控制器，去协调观察到的状态，以使其与用户期望的状态一致。这就是云原生平台的核心价值主张。为了实现这一目标，逻辑实现的重任从用户身上转移到了平台本身。每个资源类型都存在一些内部逻辑，这些逻辑就是协调其状态所需的能力。对于 Gatekeeper 来说，到目前为止最大的弱点是它需要一种叫做 Rego 的专门的编程语言来实现这种逻辑，这种语言在其他地方都无法使用。这是一个现实，因为 OPA 是一个通用的策略引擎。只有通过 Gatekeeper 将其改编成 Kubernetes 形式，才能利用其能力。那么实际上，用户负责描述他们希望调和的对象（策略），以及提供必要的逻辑（Rego）来调和它。使用外部 DSL 来管理 Kubernetes 策略，在很多方面都会变得繁琐和复杂，并给项目增加技术债务。作为一种权衡，其明显的优势是可以实现非常强大的策略。毕竟，当一个人需要编写一种编程语言时，他只受限于该语言的能力及其输入。不过，如果可以在其他地方利用 OPA，就可以分摊这种费用。

相比 Gatekeeper 来说，Kyverno 的第一印象就是没有那么复杂的技术需求。因为它是专门为 Kubernetes 构建的，并且用声明式的方法来表达策略，所以它的心理模型与 Kubernetes 对象的描述和协调方式是相同的。执行策略决策所需的逻辑被从用户的负担中移除，成为工具本身的领域。这种模式导致策略的编写方式得到了极大的简化，全面的降低了策略引擎的使用难度。Kyverno 的编译和生成能力，使它从一个简单的准入控制器转变为一个真正的自动化工具。通过结合这三种能力，再加上最近增加的 API 查询能力，Kyverno 能够执行 Gatekeeper 所不能执行的任务，而且还能够消除可能在整个集群和/或组织中分散使用的其他和不同的工具。这种简单性加上它的自动化能力和对其他工具的整合，为新用户以及有经验的用户和操作者带来了巨大的价值。

根据所介绍的信息，我认为 Kyverno 应该是应用 Kubernetes 策略的一个比较自然的选择。但如果用户符合下面两个用例中的一种或两种，就更应该选择 Gatekeeper。

有一种需求和具体意图，使用一致的核心工具将策略应用于组织内不同的系统（即，不仅仅是Kubernetes）。

反对意见：根据我的经验，无论是在云原生社区内部还是外部，大多数组织目前已经在使用其他工具将策略应用于现有系统。这通常是因为这些系统以及为这些系统实施策略的软件在 Kubernetes 以及 OPA 和 Gatekeeper 之前就已经存在。此外，这些现有工具通常不要求使用编程语言来实现其策略。因此，考虑到现有的知识、运营和资本投资，大多数组织不太可能为了实现工具一致性带来的价值，选择放弃这些工具，转而使用技术负担较重的新工具。

太长不看：如果你正在寻找一个跨 Kubernetes 和其他系统使用的单一策略引擎，Kyverno 不适合你。
策略的复杂度很高。

反对意见：根据我的经验，大多数 Kubernetes 用户都没有使用包括 PSP 在内的任何策略支持。而 2020 年对在 AWS 上运行容器化工作负载的客户的调查也得到了类似的结果，只有 49% 的客户使用策略。这些用户中的绝大多数都在做的是重复的策略——例如“容器不应该有特权”或“确保所有命名空间都带有给定的标签”或“验证 Pods 没有使用 hostPath 卷”等。“复杂”这个词是相对的，有点主观，但这样的策略表达方式绝对不复杂。Kyverno 允许以最简单的形式编写策略，这反过来又更容易推理和维护。如果要为一个更复杂、更困难的工具支付额外的价格，就应该尽量物尽其用，否则无法获得价值。

太长不看：如果无需实现高度复杂的策略，Gatekeeper 不会带来好处。

结语

Gatekeeper 和 Kyverno 项目本身都是有价值、有能力的策略引擎，每个项目都有各自的优缺点。最终，用户应该根据自己的需求和限制条件进行评估并做出最明智的决定，但作为一般建议，所有生产用户都应该计划使用策略引擎来保护集群的安全并简化 Kubernetes 管理。

介绍一个小工具：网络策略可视化编辑器

Fri, 12 Feb 2021 09:05:21 +0800

引子

跳过本节不影响阅读

既然是牛年第一篇，总要写点废话起个头。另外写小工具系列经常面对的一个难题就是——怎样凑够 300 字的原创门槛。

2020 年有大半年我都在唠叨云原生安全的事情，现在的情况按照我的理解，有点像 2000 年附近的互联网——各种东西都在往新瓶子里装，那时候的新瓶子是互联网，现在的新瓶子是云原生；那时候的旧酒是邮件、留言板、传呼机，现在的旧酒除了这些生活内容之外，多了更多的 ToB/G 的内容；从前的较大规模的公开互联网服务多数是自建自维护的，现在的公开服务则往往会用到大量的公有云、SaaS/PaaS 服务以及第三方交付项目。

在 Kubernetes 来说：

推出了 CKS 认证
OPA 毕业
Kyverno 进入沙箱
Redhat 收购 StackRox

综上，经过轰轰烈烈的云原生运动之后，安全问题就已经被怼到了我们面前，很多时候一些重点服务一旦遭到破坏，虽说安全相关的黑产已经有了成熟的获利链条；然而在责任方来说，的确可以挤出一句——这不是钱的事儿。

正文

言归正传，今天要介绍的是一个安全相关的网络策略小工具。

网络策略是 Kubernetes 内置的重要安全机制之一，用它可以轻松地使用 Namespace、Label Selector、CIDR 等方式，限制 Pod 的 Ingress/Egress 访问，相对于 RBAC 来说，这东西其实更贴近传统网络策略的限制方式，但是目前应用还较少，也就显得比较难用了。Cilium 推出的这个可视化编辑器，是个很好的入门工具。

缺省界面如图所示：

整个界面分为几个部分：

A：可视化编辑区：区域中可以用点选的方式产生不同的 Ingress Egress 规则。
B：代码编辑区：交互式编辑区产生的策略变更都会用 YAML 代码的形式反映在该区域，另外左上角还可以通过上传的方式载入现有 YAML 文件，上传的内容也会反向映射回到可视化编辑区中。
C：该区域是教学区域，下拉菜单中包含了几个常用的策略的相关教学，注意这里的是教学，给出的可能是一个待修复的策略和修复方法，不要直接复制使用。

可视化编辑区分为左中右三个部分：

1：这里可以定义策略的主体，例如命名空间、名称、策略对应的管理目标（Pod Selector），另外还可以定义 Ingress 和 Egress 的缺省行为，例如缺省 Deny 或者 Allow，这里可以看到，随着策略的变化，相应的连接线颜色会发生变化。
2：Ingress 区域，管理进入 Pod 的流量，分为集群外、集群内、本命名空间三种配置方法。
3：Egress 区域，管理从 Pod 发出的流量，和 Ingress 区域一样，分为三种配置。

例如新建一个缺省禁止所有其它命名空间访问的策略，只要新建策略，在 1 区点击 Ingress，将其设为 Default Deny，然后在 2 区点击 In Namespace，在弹出窗口中选择 Allow from any pod 即可。最终结果如图所示：

除了 All 之外，编辑器还支持 namespaceSelector、podSelector 以及集群外 CIDR 等的源头选择。Egress 策略中也包括对目标端口的设置。

结论

这才能叫可视化吧。

写给小白的 kubectl 入门

Tue, 02 Feb 2021 22:19:49 +0800

前言

意外又看到不少正在学 Kubernetes 新手。想想本人写过各种自己懂或不懂、信或不信的原理、机制、方法和工具等等各种东西，唯独没写过 kubectl，其实这东西也是值得一写的——比如说去年我才从一线同学的操作里学会用 -A 代替 --all-namespaces。理顺 kubectl 的用法，也会对 Kubernetes 的知识体系以及运维工作有很大的帮助。

对 Kubernetes 稍有了解的读者应该都知道声明式 API 的说法，kubectl 就是一个这种 API 的客户端，所以 kubectl 的主要功能就是用来操作对象的。

开局两张图

下图是个常见的使用方式：

其实本来想写主谓宾定状补的，后来想想还得复习一下，算了算了。

一般的 kubectl 使用都是这么个顺序，参数是可以调整位置的，暂且如此就可以了。

用一个思维导图来归纳一下：

动作

在 kubectl 中被称为 command 也就是命令。使用 kubectl --help 能看到可用的命令列表：

$ kubectl --help
kubectl controls the Kubernetes cluster manager.

 Find more information at: https://kubernetes.io/docs/reference/kubectl/overview/

Basic Commands (Beginner):
  create        Create a resource from a file or from stdin.
...
  run           在集群中运行一个指定的镜像
...

Basic Commands (Intermediate):
  explain       查看资源的文档
  get           显示一个或更多 resources
...
Deploy Commands:
  rollout       Manage the rollout of a resource
...

可以看到 kubectl 的命令行帮助非常不错，不仅有功能说明、分类，还有难度标识，甚至有部分的中文说明，kubectl 的每个命令都可以用 --help 查看进一步的帮助说明。

这里列出了很多可用的命令，按照操作能力，主流命令基本可以分为增删改查（CRUD）四种。

C

新建命令用于在集群中创建对象，最常用的新建命令应该是 create、run 了，create 能够创建多种对象，而 run 则主要用来创建 Pod。这两个命令都需要在命令行中使用参数的方式来表达待创建的对象的字段内容，其表达力非常粗糙和有限，并且带有明显的命令式 API 风味，在我的日常工作中已经很少用到这样的命令了。

但是这种命令往往有个妙用，--dry-run=client（旧版本中是 --dry-run），可以在不产生实际操作的情况下，测试命令的输出，加上 -o yaml，可以帮助输出 YAML 文档。

R

get 是最常用的查询指令，用于获取对象列表和基本信息，而 describe 则用于获取一个对象的详细信息。另外一个常用的读取指令就是 Debug 常用的日志查看指令：kubectl logs。

U

最重要的更新命令可以说是 apply，edit 了，patch、label、annotation、scale 等命令也算常用。

apply 是把 yaml 提交给 Kubernetes 集群的最常用方式，而 edit patch 都是用于修改线上负载的常用手段。label 和 annotation 命令则是用于修改对象元数据的，例如标签和注解。

D

这个没什么好说——delete

获取帮助

kubectl 的所有命令、子命令都支持 --help 参数，可以用这种方式获取帮助。

kubectl options 命令能够获取 kubectl 的所有全局参数。

常用参数

-f：很多指令（不只是 apply 和 create）都可以用 -f <文件名> 的方式进行输入，如果使用管道操作，则可以用参数 -f - 接收 STDIN 的输入。

-l：可以使用各种对象上的标签对操作范围进行过滤，例如 -l app=hello

-o：指定输出格式，这个参数相对复杂，最常用的是 yaml 或者 json 用于输出机器报文，还可以用 JSON Path 或者 Go Template 对结果进行处理。

对象

对象通常是类型+名称的一个组合，可以用 kubectl 获得当前集群支持的对象类型：

如上图，输出内容包含几个列：名称、简称、API 群组、是否归属命名空间以及对象的 Kind 属性。例如常用的 Deployment：

名称：Deployment
简称：Deploy
API 群组：apps
归属命名空间：是
Kind：Deployment

使用命令 kubectl get deploy，就能获得当前命名空间中的 Deployment 对象列表，如果在尾巴上加入 Deployment 的名称，就能得到符合名称要求的 Deployment 对象，

Schema

前面提到的 -f 参数，或者是 get -o yaml，都要用到具体的对象数据结构，这个结构到底是哪里规定的呢？基本结构可以分为三个部分，以一个 Namespace 为例：

apiVersion: v1
kind: Namespace
metadata:
  name: default
spec:
  finalizers:
  - kubernetes

一般会分为四个基础字段：apiVersion、kind、metadata、status 以及 spec。

apiVersion：格式为 <apiGroup>/<apiVersion>，一个对象的 API Group，可以用前文提到的 api-resources 命令查到，而版本则可以通过 kubectl api-versions 查询得到。
kind：对应 api-resources 命令输出的字段。
metadata：元数据，其中包括标签、注解、名称等字段，如果对象是属于命名空间的，也会把命名空间写在这里。
status：这个字段的内容通常是由 Kubenretes 自动填写的。经常会被省略掉。
spec：具体的对象内容，可以由几个途径获取其定义结构
- 部分资源可以使用 kubectl explain <对象类别> 获得解释
- 如果该资源在集群中有对象存在，可以使用 kubectl get <对象类别> <对象名称> -o yaml 的方式获得原文，向其致敬。
- 如果前两种方法都没有，就需要去查看 Kubernetes 或者第三方的 API Reference 了。

最后

看了上面的解释，是不是对 Kubernetes 的控制台操作有点底了？

我就要在容器里写文件！

Sun, 31 Jan 2021 00:43:14 +0800

在生产环境上遇到过一个讨厌的事情，有业务应用在容器中写入大量日志，导致磁盘空间爆满，引发了大面积驱逐。这种情况还有个比较烦心的事情就是无从监控，因此也不能用告警解决。

docker ps --size 可以凑合试一下。

虽说提倡使用标准输出来打印日志，通过 Docker 参数控制日志翻转，但是第三方容器的写入很难劝说整改，并且客观存在写入临时文件等的情况，所以还是要想个办法，在受控的情况下进行写入。

为了防止这种情况的出现，很自然的想出对策——避免容器内的任意写入行为，在 securityContext 里面加上 readOnlyRootFilesystem: true 就可以了：

  containers:
  - image: dustise/sleep:v0.9.6
    name: sleep
    securityContext:
      readOnlyRootFilesystem: true

这个容器创建之后，进入容器发现已经无法写入了。要写入文件，必须使用加载卷的方式，才能在指定位置进行写入，限制了卷尺寸，也就限制了文件写入了。

  containers:
  - image: dustise/sleep:v0.9.6
    name: sleep
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:
      sizeLimit: "100Mi"

这里我们创建了一个限制尺寸为 100Mi 的卷，然后进入 Pod 尝试写入一个 500M 的文件：

$ df -h /cache
Filesystem                Size      Used Available Use% Mounted on
/dev/vda1                98.3G     17.3G     76.8G  18% /cache

$ dd if=/dev/zero of=/cache/data.txt bs=500M count=1
1+0 records in
1+0 records out
$ command terminated with exit code 137

可以看到这个卷的尺寸并非我们指定的 100M，而是整个数据盘的大小，后面文件成功写入了，但是过几分钟之后，Shell 被踢出，发现 Pod 被驱逐了：

$ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
sleep-68bc88849b-5rwrd   0/1     Evicted   0          7m48s
sleep-68bc88849b-b7wz5   1/1     Running   0          104s

$ kubectl describe po sleep-68bc88849b-5rwrd
...
  Warning  Evicted    2m42s  kubelet            Usage of EmptyDir volume "cache-volume" exceeds the limit "100Mi".
  Normal   Killing    2m42s  kubelet            Stopping container sleep

可以看到驱逐原因的确是超出了限制。

驱逐是个比较慢的过程，可能不太合适，我们知道，emptyDir 还有一种内存的方式，会有改善么？

emptyDir:
  sizeLimit: "100Mi"
  medium: "Memory"

同样测试，发现还是被驱逐了。这种类型的卷是会占用容器的内存限制的（这点在实际应用时一定要注意，防止 emptyDir 挤占业务应用内存），加上 limit 会不会有所好转呢？

resources:
  requests:
    memory: "300Mi"
  limits:
    memory: "300Mi"

再次进入容器：

$ df -h /cache
Filesystem                Size      Used Available Use% Mounted on
tmpfs                     7.7G    100.0M      7.6G   1% /cache

$ dd if=/dev/zero of=/cache/data.txt bs=500M count=1
dd: error writing '/cache/data.txt': Out of memory
0+1 records in
0+0 records out

这次的反应速度就很快了，直接被拒绝。

Limit 这么好用，如果直接限制 Ephemeral Storage 会不会又能快速反应，又不影响内存占用呢？答案是否定的，这个资源的 Limit 同样是使用驱逐机制实现的。

1.20 中新增了一个 Feature gate：SizeMemoryBackedVolumes

如果放弃内存 emptyDir 的话，hostPath 能满足要求么？

apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: task-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

申请了一个 1G 的 PVC 之后，再尝试创建文件，很遗憾，最终我在 /mnt/data 目录下收获了 10G 的文件。甚至也没有驱逐过程，换用 Local Persistent Volume 也没有任何变化。

结论

Kubernetes 容器中写入文件是一个非常不推荐的操作。两种本地卷都无法达成限制目的。如果没有外部存储设施，仅能通过 emptyDir 实现简单的写入限制，内存类型的会侵占应用内存，而磁盘类型的限制则要依赖于驱逐机制相对迟缓地完成操作。

介绍一个小工具：Dyff

Sun, 24 Jan 2021 16:07:19 +0800

YAML 工人经常需要对类似的 YAML 进行对比，查看其中的更新或者状态变化，通用的 diff 工具经常是能胜任的，例如：

$ diff n1.yaml n2.yaml
...
<       - image: dustise/sleep:v0.9.5
---
>       - image: dustise/sleep:v0.9.6

但是如果出现了字段的平移，或者新加了一些元素，结果可能就比较难看了，例如移动几个字段的位置：

$ diff n1.yaml n2.yaml
11,13d11
<   progressDeadlineSeconds: 600
<   replicas: 1
<   revisionHistoryLimit: 10
19d16
<       maxSurge: 25%
20a18
>       maxSurge: 25%
21a20,22
>   progressDeadlineSeconds: 500
>   replicas: 1
>   revisionHistoryLimit: 10
...

这几个字段发生变化并移位之后，就比较难用肉眼观测具体的有效变更了。这种情况下，Dyff 就可以派上用场了。

安装很容易，在 macOS 中可以使用 Homebrew 进行安装：brew install homeport/tap/dyff，Linux 和 macOS 中也可以使用脚本 curl --silent --location https://tinyurl.com/y4qvdl4d |bash 进行安装。

官方文档中展示了它的基本子命令 between：

如果对一个手写的 yaml 和它的线上版本进行对比，可能会有很麻烦的输出，例如 managedFiled、status 等字段：

$ kubectl get deploy sleep -o yaml | dyff bw sleep.yaml  -
...
+ one map entry added:
  status:
...
metadata
  + six map entries added:
    creationTimestamp: 2021-01-24T07:51:40Z
    generation: 1
    managedFields:
...
spec.template.spec
  + one map entry added:
    securityContext: {}

spec.template.spec.containers.sleep
  + one map entry added:
    resources: {}
...

这里可以用 krew 目录中的 neat 插件进行处理，这个插件能将线上运行对象所输出的 YAML 进行清理，能大大地减少状态字段的干扰，同样也支持管道操作，例如：

kubectl get deploy sleep -o yaml | kubectl neat - |  dyff bw sleep.yaml  -

这样处理一下之后，视野就会清楚很多了。

除了对比之外，dyff 还支持 yaml 和 json 的互转，加上 neat 的操作可以是这样：

$ kubectl get deploy sleep -o yaml | kubectl neat - | dyff json -
{
  "apiVersion": "apps/v1",
  "kind": "Deployment",
  "metadata": {
    "annotations": {
      "deployment.kubernetes.io/revision": "1"
    },

Kubernetes 将弃用 PSP

Wed, 20 Jan 2021 14:21:41 +0800

太长不看版：

Merged：deprecate PSP in 1.21, but leave removal at 1.25 #97171

Pod Security Policy 是 Kubernetes 的重要安全措施之一，它首先定义角色，其中规定了对 Pod 行为的限制，其中包括对特权容器、主机网络、Capability、加载卷类型等内容进行了限制，然后通过 RBAC 把 SA-Pod-PSP 三者结合起来，完成对 Pod 权限的限制。相对于 SecurytContext 来说，PSP 更具强制性和可管理性，CIS Kubernetes Benchmark（v1.6）中明确地把启用 PSP 设置为记分项目，很多 Kubernetes 安全相关软件也会据此进行检查。

然而 PSP 是无法缺省启用的，还有一些其它缺陷，因此在 #97171 中，Kubernetes 1.21 把 PSP 加入了淘汰队列，并在 1.25 中移除。

讨论中可以看到，几个备选方案包括：

升级 PSP
第三方策略引擎
缺省启用宽松策略

目前可用的唯一方案就是启用策略引擎，因此 OPA/Gatekeeper 或 Kyverno 等策略引擎的重要性将进一步提高。遇到扫描报告里的“未启用 PSP”也可以理直气壮了。

参考链接

#97171：https://github.com/kubernetes/kubernetes/pull/97171
PodSecurityPolicy，Present and Future：https://docs.google.com/presentation/d/1Kv6BSBNyLCyglMbK7e6tVOaDYe89LV2aHL2Hlb-9HX8/edit#slide=id.p
Pod Security Policy：https://kubernetes.io/docs/concepts/policy/pod-security-policy/
Security Context：https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

使用 Shell-Operator，让 Pod 继承节点标签

Wed, 13 Jan 2021 10:48:07 +0800

前一段时间发了一篇 Shell Operator 的介绍，搓例子的时候，就想起个需求，我想把 Pod 所在节点上的特定标签复制给 Pod，例如机架、虚拟机节点所在的物理机等，都可以用标签的形式来表达，并可以用这些标签进行选择和统计等。

Shell Operator 的基本开发流程是：

编写配置文件，确定触发条件。
开发操作脚本，打包容器镜像。
确定操作权限，设置 RBAC。
运行和测试。

官方的例子中，入口脚本如果带有参数 --config，就会返回一段 YAML 格式的配置文件，这部分是硬编码到代码之中的，例如：

#!/usr/bin/env bash
if [[ $1 == "--config" ]] ; then
  cat <<EOF
configVersion: v1
kubernetes:
- apiVersion: v1
  kind: Pod
  executeHookOnEvent: ["Added"]
EOF
...

在 K8s 中，我们可以用 Configmap 的形式来提供配置文件，提高其适应能力：

if args.config:
    with open(CONFIG_FILE) as cfg:
        print("".join(cfg.readlines()))
    sys.exit(0)

配置文件的处理方式：

configVersion: v1
kubernetes:
- apiVersion: v1
  kind: Pod
  executeHookOnEvent: ["Modified"]
  labelSelector:
    matchExpressions:
    - {key: node-dc, operator: DoesNotExist}
    - {key: node-label, operator: Exists}
  jqFilter: .spec.nodeName

以 Pod 的 ‘Modified’ 事件触发 Hook。
使用 jqFilter 关注 .spec.nodeName 字段的变化，仅变化时触发
给对象 Pod 提供两个标签
- node-dc 用于标注该对象是否已经完成标签复制，完成的不触发。
- node-label 用于标注该对象是否需要进行标签复制，没有该标签的不进行触发。

用这个配置文件生成 ConfigMap，预备给 Pod 进行加载。

配置文件的位置由环境变量 CONFIG_FILE 决定，缺省值为 /etc/auto-labeler/config.yaml

把源码和 Dockerfile 拷贝在一起生成镜像，这里用 Python 编写的脚本，所以需要加入 Python3 的包：

FROM flant/shell-operator:latest-alpine3.11
RUN apk --no-cache add python3
ADD auto-labeler.py /hooks

/hooks 目录里面的可执行文件都会被视为 Hook 脚本。这个目录的定义可以用环境变量 SHELL_OPERATOR_HOOKS_DIR 进行修改。

这个功能需要读取 Node 信息，并为 Pod 打标签，Pod 中的 Kubectl 会用 ServiceAccount 凭据对集群进行操作。所以需要进行 RBAC 配置。源码中的 rbac.yaml 文件包含了所需的内容。

以上步骤都完成之后，部署工作组件（例如 operator.yaml），就可以进行测试了，

测试

首先给各个节点打入标签，例如：

kubectl label node \
    gke-gcp-vlab-k8s-default-pool-176e8788-n7bl \
    node-dc=datacenter node-rack=10002 node-name=vm009

代码中的 sample-workload.yaml 就是一个给 Pod 打好了 node-label 标签的实例。部署之后可以进行 Scale，查看标签的生效情况。

介绍一个小工具：SSL-exporter

Sat, 09 Jan 2021 00:01:13 +0800

Kubeadm 安装时的证书有效期设置为 1 年，虽说有 sealos 这样的不知名安装器以及各种方案来更新证书，但是对于像我一样经常跟不知来源的 Kubernetes 集群打交道的人来说，这个有效期就是达摩什么的利剑，不一定什么时候会砍到脖子上。如果能用 Prometheus 对证书有效期进行监控或者告警，就能更好地保护好自己的脖子了，ssl-exporter 就是这么个有趣的项目。

ssl-exporter 是个 Prometheus Exporter，能提供多种针对 SSL 的检测手段，包括：https 证书生效/失效时间、文件证书生效/失效时间，OCSP 等相关指标。下面用 API Server 证书检测来验证这一功能：

首先进行部署：

apiVersion: v1
kind: Service
metadata:
  labels:
    name: ssl-exporter
  name: ssl-exporter
spec:
  ports:
    - name: ssl-exporter
      protocol: TCP
      port: 9219
      targetPort: 9219
  selector:
    app: ssl-exporter
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ssl-exporter
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ssl-exporter
  template:
    metadata:
      name: ssl-exporter
      labels:
        app: ssl-exporter
    spec:
      initContainers:
        # Install kube ca cert as a root CA
        - name: ca
          image: alpine
          command:
            - sh
            - -c
            - |
              set -e
              apk add --update ca-certificates
              cp /var/run/secrets/kubernetes.io/serviceaccount/ca.crt /usr/local/share/ca-certificates/kube-ca.crt
              update-ca-certificates
              cp /etc/ssl/certs/* /ssl-certs
          volumeMounts:
            - name: ssl-certs
              mountPath: /ssl-certs
      containers:
        - name: ssl-exporter
          image: ribbybibby/ssl-exporter:v0.6.0
          ports:
            - name: tcp
              containerPort: 9219
          volumeMounts:
            - name: ssl-certs
              mountPath: /etc/ssl/certs
      volumes:
        - name: ssl-certs
          emptyDir: {}

上面的 YAML 部署了一个 Deployment 和 Service，在 9219 端口上提供 Exporter 服务。

接下来在 Prometheus 中配置一下抓取 Kubernetes 服务的内容：

- job_name: ssl-exporter
  metrics_path: /probe
  static_configs:
  - targets:
    - kubernetes.default.svc:443
  relabel_configs:
  - source_labels: [__address__]
    target_label: __param_target
  - source_labels: [__param_target]
    target_label: instance
  - target_label: __address__
    replacement: ssl-exporter:9219

接下来就可以进行查询了，查询语句：(ssl_cert_not_after-time())/3600/24，这个表达式查询各个目标的过期时间和当前时间的差。执行查询获取到过期天数，查询结果是 349 天。同样的表达式，复制到 Alertmanager 中，就可以及时的获取到证书的过期时间了。

送容器下乡

Wed, 06 Jan 2021 14:50:56 +0800

Kubernetes 上天了

2020 年里，Kubernetes 的疆界有了一个有趣的扩展——美国人把 Kubernetes 和 Istio 装到了 F16 战斗机上。战斗机应该算是真边缘了吧？读了几篇相关材料，发现整个过程远不止一个极限部署这么简单，DoD 在军方的大背景下，实现了一整套基于 DevSecOps 理念的云原生生态，那么一个问题就是，为什么单独要说 Kubernetes 和 Istio 呢？只是因为热门吗？

我的看法是，容器化和容器编排，是云原生的“阵眼”。云原生是个覆盖方方面面的体系，除了我们熟知的容器链条等技术要素之外，还以方法论的方式渗透到整个 IT 环境的市场、商务、架构、开发、运维、安全等各个方面。而其中的容器技术，其底蕴来自于几十年来整个业界不断的虚拟化和隔离技术的积累，是云原生的众多概念中，最能被“看得见，摸得着”的形象。同时作为制品和运行时的一等公民，容器和（Kubernetes 的）声明式 API 结合起来，已经能够满足绝大多数业务应用的运行需要。一个常见的 Kubernetes 环境，有足够条件能够符合 12 要素中至少一半的要求。这个组合是最常见也是最应该的云原生入门选择。很大程度上，Kubernetes 能走到哪里，云原生才能走到哪里。

部署是个大问题

回到前面的新闻，把 Kubernetes 装到哪里，当然不代表成功，但是它代表了一个重要的方向，YAML 架构师们都知道——只要这东西起来了，给我一个 Helm，就能搞他个天翻地覆。所以从诞生之初直到现在，Kubernetes 的部署都是个大问题。

然而一谈到 F16 之流的边缘部署，不可避免的会想到奇奇怪怪的设备们，长期以来都有一个固定的句式——我们给 XX 减肥，把它塞到资源有限的 YY 设备里。不过这对 Kubernetes 可能不太合适。

我一直对“魔改”这个事情有点抵触——感觉像是在车子上跳下来，虽然会有一个更高的速度，但是很难保障你真的就是火箭鱼雷航天飞机，下车才是刚起步，更多的情况是，跳车之后快了一瞬间，才发现跟不上了。

资源不足的设备，和上不了容器的用是一样的，如果存在真正的需求，它们自然会适应实际需要，无法适应只能说是需求不强。强扭的瓜不甜，只想要瓜不管甜不甜的可以忽略。

所以在我一个 YAML 架构师的眼里，Kubernetes 下乡，应该是基于原装的 Kubernetes，在一定程度内，满足大部分容器化业务的支撑需要，其它的东西，应该是设备归设备、虚机归虚机。Kubernetes 目前的下乡重点，应该在边缘机房，而非末梢节点。

什么样的 Kubernetes 能下乡

那么要让 Kubernetes 下乡，除了要求“原装货”，乡下有点什么不一样呢？

非标准环境

通常的边缘环境不会是标准数据中心，少到两三台利旧服务器，大到几个一体化机柜，各个节点会有参差不齐的硬件水平和规模，散热、供电水平通常达不到一个持续高可用运行的需要。

弱网络

和散热供电一样，位于边缘的节点的网络可能会有较高的延迟，甚至较长时间的断网，周期性的网络不可用，以及需要隧道才能互访的情况。

此外还有跨地域边缘节点组成的集群，节点之间、节点和控制平面之间的通信同时都可能遭遇网络问题，会把情况进一步的复杂化。

反锁定

我们历尽千辛万苦将 Kubernetes 送到乡下之后，可能会有很多嗷嗷待哺的容器化应用要运行，以及各方厂商的种种设备尝试接入进行就近处理，因此对通用性的需要是显而易见的，简单说就是远端的计算节点应该有足够的软硬件兼容性，能够以一定的标准运行在通用硬件、虚拟化和操作系统上，支撑多种厂商的、或通用或边缘的软件系统的运行。

低运维

通常来说，运维人员还是围绕数据中心工作的，被“下放”的 Kubernetes 必须能够在一个少运维甚至零运维的情况下运行，原本在数据中心如臂使指的虚拟化、Ansible 之流可能都会因为前方条件的不足而受到种种限制，此时就要求我们的远端节点有强大的自愈、自治和被远程运维的能力。

没结论

这几天偶尔看了一些边缘集群的一些东西，看到减肥蔚然成风，想起多年以前我对 Java 太吃内存的嘲讽，有感而发。

（闲聊）听说 K8s 要甩了 Docker？

Wed, 02 Dec 2020 21:01:13 +0800

今天偶然看到 Kubernetes 1.20 的 ChangeLog，其中有一行大动作：

Deprecation
Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. (#94624, @dims) [SIG Node]

大意是，Kubelet 中的 Docker 支持已经进入淘汰阶段，将在未来移除。原因是 Kubelet 中使用 dockershim 组件为 Docker 提供了 CRI 支持，Kubernetes 认为维护这个组件是有问题的。建议用户评估并迁移到 CRI 支持更完善的运行时上。

其中引用了 9 月提出的 PR #94624。其中提出，为了使用 Docker，从 moby 进行了大量移植开发了 dockershim 嵌入到 Kubelet 之中。Kubelet 和 CRI 的正确沟通方式是像 containerd、cri-o 这样。各自使用独自的进程，互相以 gRPC 进行对接。Docker 目前仍然是主流，进行迁移需要广而告之并逐步推进。

实际上早在 2018 年 5 月，Kubernetes 的 Containerd 集成就已经宣告了 GA。其中有两张图很能说明问题：

在 1.0 中，Kubelet 使用 Docker Shim 和 Docker 进行通信，Docker 再和下面的 containerd 进行通信。

此时如果采用 containerd 作为运行时，Kubelet 要使用 CRI Containerd 和 Containerd 打交道，不过相对于 Docker，还是少了一跳。

在 1.1 中这个结构得到了优化——Containerd 直接内置 CRI 接口，Kubelet 甩掉包袱可以直接用 CRI 方式对 Containerd 进行控制，这样就又省了一跳。

此时 Docker 在这个调用链上的位置已经有点尴尬。随着其它 CRI 运行时的发展，这种尴尬越发明显。#94624 中提到过，Docker 有个优势就是提供了 Build 等“Kubelet 不需要但是很有用”的功能；然而换个角度来看，这些功能是有悖于单一职责的原则的。

个人认为，Docker 这样的全能选手，在计算节点上的长期存在证明了这个阶段里，计算节点还没有进入理想的 cattle 状态，用户一方面还没有心思对“多余”的功能进行剪裁，另一方面还有可能人工进入节点上进行运行时范围以外的操作。在 GA 一年多之后，砍刀开始落下，说明了什么呢？

容器和 Docker 这两个经常被混用的词，其间的边界可能会变得越来越清晰，构建、运行、管理越来越倾向于使用各自领域的专业工具各司其职；
计算节点会变得更加“没性格”，换句话说，仅为了“运行容器”为目的的基础设施软件，例如操作系统、CRI 这样的工具会逐步代替大而全的通用 Linux Server 操作系统和 Docker 出现在容器节点上；
“没性格”的计算节点将会更加容易地被创建、运行、调整和销毁，也就是说会提高容器集群规模的伸缩能力，甚至逐渐形成普遍的动态扩缩容能力。
集群级别的批量化、自动化运维能力的要求会越来越高——或者以后的节点上没有 ssh、vim 也未可知。

带点个人感情的说，前两天刚刚遭遇 DockerHub 限流的我还是生出了一点卑鄙的快意，Google 的铁拳再一次敲在了 Docker 的头上，Docker EE 怎么办？但是 Docker Desktop for Mac 还是真香的。

一切从巡检开始——Prometheus 的告警迭代小窍门

Sun, 29 Nov 2020 16:40:02 +0800

Prometheus 是 CNCF 的二号项目，大致相当于各种基于 K8s 的平台的标配监控方案了，其原始产品在高可用、性能等方面都有一些不足，好在几年来社区以及终端用户的持续贡献后，在大规模大流量的场景方面已经有了长足的进步。

Prometheus 具备 CNCF 中顶级项目的普遍优势：架构优雅、社区活跃、扩展方便、生态健康。它提供了大量的 Exporter，常见软件多数都会有对应的 Exporter 用于产生监控数据，另外借助 Prometheus API，能够很方便的编写自己的 Exporter。在查询方面，虽说 PromQL 的古怪语法经常遭人诟病，但的确能够编写非常灵活的查询和告警。

在实际落地过程中，监控和告警是非常重要的一个功能特性，但是不同项目、不同的运维团队、不同的工作负载，都有可能会有不同的告警关注点。告警信息是通常有成本的，在部分项目中可能还要走正式的上线/变更流程，因此通常来说都需要有一个平衡的过程，对告警项目以及告警阈值进行开发、测试、上线、反馈、调整等一系列迭代过程。

在项目过程中，我们可以采用一种巡检+告警的模式来完成这一迭代过程。简单来说分为这样几个大步骤：

写代码，从配置文件中读取 PromQL 查询语句，使用 Rest API 从 Prometheus 中获取指标。
将预备使用的告警指标写入配置文件。
在巡检过程中执行这些查询，并生成报表。

在每次巡检过程中生成的报告里，着重关注这些新的监控数据，并把新数据和系统中对应的监控对象的实际情况进行对比，用多次巡检过程进行磨合之后，就可以上线到告警系统中，正式投入使用了。这种糙快猛的做法，一方面使用同样的语法规则，很方便的能在告警和巡检之间进行指标定义的迁移；另一方面，巡检的指标可以采用较为敏感的阈值设置，用于发现趋势性的或者重要但是紧急度不高的指标进行处理。

相对于告警来说，巡检的自由度稍大，并且没有外发成本，更能够方便的进行调整迭代，避免无用告警和过量告警。

另外推荐一个网站：Awesome Prometheus Alerts，这里汇集了很多的告警规则代码，非常适合用在监控系统的初期建设上。

云原生安全白皮书

Tue, 24 Nov 2020 22:33:16 +0800

原文：Cloud Native Security White Paper

执行摘要

目的

云原生的开发和部署模式已经成为业界趋势，技术、产品、标准和解决方案的生态系统也在同步的扩张之中，决策者面临着跟进复杂设计的挑战。CISO 要在这个动荡的战场中实践业务价值，这个角色显得尤为重要。云原生模式鼓励消费模式的变化，和采用需要集成安全实践的现代工作流程（如敏捷方法和 DevOps）。

问题分析

面对快速开发和部署的迫切需要，基于边界的传统安全保障显得力不从心。传统安全方法偏重于对边界进行保护，而更复杂的云原生应用则倾向于识别动态工作负载中的属性和元数据来进行保护，这样才能为应用的模式转换保驾护航。这种方式能对工作负载进行识别和保护，以此适应云原生应用的规模扩展以及快速变化的需要。模式的转变要求使用面向安全的架构设计（例如零信任），并且在应用安全生命周期中采用更多的自动化方法。作为云原生环境的典型特征，容器化也需要最新的最佳实践。安全措施的变更会触及组织内的多个利益方，并且会对开发和运维人员的生产力造成影响，因此其权衡过程会持续存在。云原生应用并没有跳出开发、发布、部署和运维的圈子，但是新的模式需要新的安全机制，从而保障（新方式下）能够保障这些环节目标的达成。云原生应用的生命周期可以建模为开发、发布、部署和运行时这样几个不同的阶段。和传统安全方法相比，云原生安全有机会在不同的阶段注入各自的安全保障，而不是用独立的安全措施来干预应用的生命周期。需要指出的是，需要针对这些概念的使用和整合、相关工具和流程的教育和培训，云原生的落地和应用可能难以为继，甚至被打回原形。

生命周期

开发

对云原生应用来说，建议在应用生命周期的早期就引入安全保障。尽早地使用安全测试来识别合规和配置的相关问题，从而为持续改进提供快速、可操作的反馈流程。这种方式能够使用同样的工作流程来处理安全问题和 Pipeline 中的其它常规问题（例如 Bug 修复或者 CI 失败）。这种模型中使用的现代的安全方法符合设计模式（例如 12 要素）要求，并且能保障交付过程的完整性。云原生的概念和 IaC（基础设施即代码）的实践密不可分，以此确保能够在早期进行安全检查后，按照预期执行。这样的过程能够识别错误配置，并可以尽早在 IaC 和编排清单中实施最佳实践，从而降低长期成本并提高安全价值。

发布

软件供应链安全在快速的软件迭代过程中尤其重要。云原生应用的完整性保障不仅针对工作负载自身，还需保证其创建和运维过程的完整性。对于开源软件和第三方应用的强依赖加剧了这方面的要求。Pipeline 生产的制品（例如容器镜像）需要持续地进行自动扫描和更新，从而避免遭受漏洞、恶意软件、危险代码以及其它不当行为的侵害。完成这些检查之后，应该对制品进行签名来保障其完整性和不可否认性。

部署

在开发和发布过程中集成的安全性能够对候选工作负载的属性进行实时的持续的验证（例如制品签名的验证、容器镜像和运行时的安全策略等）。随安全的工作负载同时部署的可观察性支持，提供了对日志和指标的支持，进一步完善了安全保障的覆盖面积。

运行时

云原生运行环境应提供策略和资源限制功能。对工作负载进行运行时资源限制（例如 Linux 的 cgroup 隔离）就是一个在云原生环境中进行限制和可观察性的原语的例子。可以把云原生运行时环境分解为具备不同安全问题的关联的组件层（例如硬件、主机、容器镜像运行时和编排）。

在云原生环境中，普遍采用了微服务架构。应用通常会由独立且目标单一的微服务组成，这些微服务需要通过服务层进行通信，容器编排层完成了这一任务。这种相互纠缠的组件架构下，安全方面的最佳实践包括只有被许可的进程才能在容器的命名空间内运行、预防和告知未经授权的资源访问、以及能够感知恶意行为的网络监控。服务网格是另一个常见的抽象，它在避免对工作负载进行变更的情况下，为被编排的服务提供了加固和补充的功能（例如 API 流量日志、传输加密、认证、授权以及可观察性等）。

建议

相对传统安全模型，云原生安全同样要对尽职性、完整性、信任关系以及威胁防范提供支持，在此基础之上还加入了临时性、分布式和不可变设施的现代概念。在这种快速变化的环境中，要在迭代中实现与开发 Pipeline 自动同步的安全保障才能防止迭代失败。组织必须对这些核心安全概念进行学习分析和应用，避免在应用加固和环境管理方面的落后；需要对相关的第三方执行同样的标准；并对其云功能和安全支持方面的员工进行持续的教育和培训。因为复杂性的增加和组件的复杂关系，必须通过在整个生命周期和运行环境中整合安全保障能力来制止未授权访问。强烈建议组织根据攻击框架[^2]来确认安全堆栈的覆盖面。另外组织还可以采用安全左移[^3]的方式，扩大 DevOps 的能力，在 Pipeline 执行之前、之中和之后进行持续、适用的检查，对进入生命周期的任何新东西进行校验。

结论

如果一个组织以战略的高度重视云原生安全的落地工作，能够在大规模情况下提供高可用、可信、韧性和冗余的应用能力，保证客户和开发者能够以他们期望的效率，安全地访问所需资源。安全是一个跨学科领域，并不能独立于开发之外，也不仅仅局限在技术范畴。开发、运维和安全人员都必须紧密交流和协作，推动该领域的持续进步。与任何技术创新一样，真正使社区和云原生安全成为可能的是人。

简介

本文尝试让组织及其技术领导者能够清晰地理解云原生，从而能够将其纳入原有生命周期，并确定其应用方式。云原生安全是一个覆盖多个专业技术和实践领域的多目标、多约束的问题空间。在初期运维过程中有很多工作都和安全领域重叠，例如身份管理和存储方案。然而云原生安全的覆盖面远不止于此，它还是一个关系到人本身的问题空间，其中包含了个人、团队以及组织。它是一种机制和流程，人类和系统借此进行交互，对云原生应用和技术造成深远影响。

目标读者

我们的目标读者是希望交付安全云原生技术生态的企业、政府机构以及非营利组织的首席安全观(CSO)、首席信息安全观 (CISO) 或者首席技术官 (CTO) 。其它的组织利益相关方，包括负责设计实现安全云原生产品和服务的项目经理、产品经理和架构师。当然其他对云原生安全有兴趣的人也都可以参考本文。

云原生的目标

包括容器和微服务架构在内的新技术的采用和创新带来了新的挑战。现代组织中，安全需求的优先级已经大幅提升。围绕云原生技术的加速创新，威胁范围也在扩大。安全领导者要负责保护人力[^4]和非人力的资产，要在满足严格合规性要求的同时，采取措施来预防、检测和对应安全问题。一个老生常谈的埋怨就是，安全措施降低了 DevOps 团队的速度和敏捷性。因此安全领导层必须（和 DevOps 团队）进行更紧密的合作并增进双方的理解，让 DevOps 团队也能同样共享网络风险方面的所有权。

企业需要采用的安全云原生模式和架构必须进行分享，确保业界能够用更高优先级来实施安全实践，并将其集成到现代应用生命周期之中。强调安全架构和安全行业领导者的协同作用，并在漏洞管理、零信任、云安全和 DevSecOps 等方面调整组织的架构目标，这是当务之急。

本文中的概念是具备普遍性的，并不偏向于特定的组件或者服务。

但是这里并不会对安全和云原生方面的基本概念进行扫盲，也不会推荐特定的技术和工具，当然，叙述过程中可能会使用一些相关工具被列举在相关专题中，或者进行示例。

除了本文中的建议之外，与数据和隐私保护（例如 GDPR、PCI DSS）的相关内容需要额外的监管相关的方面进行考虑。建议读者另行寻找相关咨询资源对这方面的技术控制和合规风险提供支持。

假设

CNCF 在 CNCF 技术监督委员会（TOC）的 GitHub 仓库中提供了云原生的定义。本文不会改变这一定义或对其进行扩展。

云原生的落地和现代软件开发方法论都在持续演进之中。构成云原生技术栈的技术也会随着时间的推移不断变化。云原生 Landscape 中会持续支持这个不断变化的技术栈。

本文中出现的工作负载这个词，代表已经或者将要开发、运维、发布以及部署到基于云的运行时环境的任何产品、项目、应用或者系统。

云原生的层次

图 1

云原生技术栈由基础、环境和生命周期构成。云原生技术栈可能用不同的模型（例如 IaaS、PaaS、CaaS 或者 FaaS）进行部署。每一种模型都提供了各自的抽象，以此来简化云原生环境的管理和运维。这些模型中有一些是已经广为人知并被广泛采用，我们会聚焦在云原生特有的模型上。

CaaS（容器即服务）模型让用户通过基于容器的虚拟化平台及其 API 或者 Web 管理界面对容器、应用和集群进行编排和其它管理工作。CaaS 帮助用户构建容器化应用，其中内置以代码方式表达的安全策略，这些应用能运行在私有云、自建数据中心和公有云上。CaaS 有助于简化容器的构建过程。有了微服务的编排和部署，CaaS 帮助企业更快地发布软件，并且具备在混合云、多云环境下的移植性，同时还降低了基础设施和运维成本。CaaS 模型之所以能节约成本，是因为它能够帮助企业简化容器管理，并给企业仅为实际的 CaaS 需求买单的选择。CaaS 以容器为基础资源，而 IaaS 环境中的基础资源则是虚拟机和裸金属。

FaaS（功能即服务）是另一种云原生部署模型，它是一种云原生服务的形态，让企业用户能够根据事件来触发代码的执行，避免了构建运行微服务的复杂的基础设施管理工作。在云上运行应用通常提供虚拟环境，管理操作系统和 Web 组件等。有了 FaaS 之后，物理硬件、寻积极操作系统以及 Web 服务器软件管理都由云服务提供商自动支持。这样一来，用户就能专注于单独的微服务功能代码，并且只需要向云服务商用弹性的方式支付资源的实际使用费用。

生命周期

云原生语境下的生命周期指的是在云环境下，帮助实现有韧性、可管理、可观测的工作负载的技术和实践。如图一所示，生命周期由四个持续阶段构成：开发、发布、部署和运行时。每个阶段都是前一个阶段的扩展和放大，同实要放行安全工作负载的运行，并提供相应支持。

生命周期过程

对于安全实现来说，供应链的管理和合适的安全基线是非常重要的。

供应链

组织有责任确保它们开发的工作负载的供应链能够接受可操作的安全分析。供应链安全可以分为两个部分：为创建工作负载供应支撑环境的服务和工具（开发工具）的安全，以及组成工作负载的组件（例如库、依赖和镜像）的安全。供应链必须以能够接受检查的方式来构建，软件供应链输出的制品也应该能够使用签署的方式确认来源。为保障依赖项的正常运行并阻止可能的破坏行为，对第三方包的真实性和完整性进行校验非常必要。

云原生应用的一个显著特征就是软件复用，这些软件可能以软件包或容器镜像的方式，通过开源仓库进行构建和分发。正因如此，对于开发、运维和安全人员来说，确保应用中的制品和依赖不包含已知的恶意软件和缺陷是个必要工作。容器镜像可能包含的恶意软件，很明显会威胁到运行时环境[^5]。在持续集成过程中和容器仓库中进行周期性扫描和按需扫描能够有效防范这些问题。

使用这些手段实现可检测的、安全的软件发布和运维操作。在工作负载的产生过程中进行威胁检测让组织能够快速向开发团队进行反馈，并阻止不安全的或有漏洞的更新被发布和部署。对现存软件进行周期性的扫描，能够发现新公布的问题，从而避免其造成危害。

安全基准

安全基准（例如 NIST Application Security Container Guide、 Center for Internet Security (CIS), NIST Security Strategies for microservices 以及 OpenSCAP）为开发团队和组织提供了创建“缺省即安全”的工作负载的指引。采纳并实现这些安全标准，让团队能够基于加固的基线进行测试。然而这些基准无法深入数据流，也无法干涉平台的用法。因此这些内容应该作为一个指南，而非检查表。

接下来的几节将详细分析在整个应用程序生命周期中集成安全的意义、工具、机制和最佳实践。

开发

图 2

云原生应用的安全需要体现在应用的整个生命周期之中。开发环境是这个周期的第一个环节，这个环节输出的是制品，例如 IaaS、应用和容器清单等，这些制品会被用于云原生应用的部署和配置。经验表明，这些制品会是多种攻击的来源。接下来的内容会介绍这个阶段里需要介绍多种工具、流程和检查过程，以此减少运行时应用程序的攻击面。

开发过程中的安全检查

在应用开发过程中的安全加固是一个重要环节。安全需求也是需求的一部分，应该尽早在软件开发过程中进行引入。安全需求通常是围绕业务的风险和合规性进行的。这些需求如果不在早期进行处理，而是在生命周期的后续才开始进行的话，就会拖慢 DevOps 过程，提高总体成本。DevOps 团队还需要使用专门工具在这些应用的部署之前对危险配置和漏洞进行检测。这些工具应该无缝集成到 DevOps 团队现有的熟悉的工作链之中，在不阻碍敏捷性的同时，提高安全性。例如可以在开发 IDE 中或者创建 PR 的时候对 IaaS 模板以及应用清单文件进行扫描，并生成丰富的上下文相关的安全信息，开发团队就能够尽早、迅速、轻松地采取行动。加入这些步骤后能够避免已知漏洞和高危配置。云原生组件应该是 API 驱动的，被编排的业务应用能够和复杂的调试工具进行交付。

团队应该部署独立的开发、测试和生产环境，从而为应用开发者提供隔离的设施，对基础镜像、容器、应用、虚拟机镜像以及进行开发、测试和部署。有些组织可能已经在尝试金丝雀部署和蓝绿部署。以及其他部署模型在现场进行动态和交互测试，以此进一步提高效率。

测试方案的开发

开发、运维和安全人员应该为关键业务、有高威特征、变化频繁或具有历史问题的代码和基础设施建立测试方案。威胁建模可以识别高风险和高影响的代码热点，提高开发测试的投资回报率（ROI）。测试对象可以包括部署、操作系统、基础设施和数据库加固、应用测试（静态和动态源码测试、容器配置）、集成或系统测试（应用程序和基础设施组件及其交互的验收）和冒烟测试（针对实时系统的部署后检查）。测试作者应该能够全面地访问开发和测试环境，从而能够快速地开发测试方案，同时减少持续集成（CI）反馈循环次数。作者应该能在本地和共享测试环境中运行系统测试套件。

代码评审

对工作负载或基础设施的细微变更可能引发意料之外的安全问题。为减少风险，建议合并 PR 之前应用四眼原则进行评审。

发布

图 3

这个阶段会使用镜像定义和规范来构建后续步骤的制品，例如容器镜像、虚拟机镜像等。在现代 CI/CD 语境下，发布阶段中包含了系统性的应用测试，以此识别软件中的 Bug 和故障。然而对开源软件和包的复用，有可能会把安全威胁引入到制品之中。为了防止这种情况，需要对制品进行扫描，并验证其完整性，防止发生篡改。后续内容会为开发和运维人员介绍识别和保护容器镜像、CI/CD 流水线的工具、技术以及基础设施。还可以对制品进行加密来满足额外的保密需求。

如果遭遇泄密等问题导致制品不可信，应对密钥进行更换并重新签署。

构建流水线

不同安全级别和敏感性的项目，应对 CI 服务器应进行分别的隔离和保护。需要提权的基础设施构建应在专用的持续构建服务上运行。编排器应该为流水线创建和执行构建策略。

供应链工具可以对流水线的元数据进行搜集和签名。后续步骤能够对签名进行检查，并借此确信前面的步骤已经完成。

读者要确保 CI/CD 设施的安全。例如及时进行安全更新，并通过硬件安全模块或者凭据管理器对密钥进行保护，防止泄露。

镜像扫描

镜像扫描是应用镜像生命周期中的重要步骤。在把镜像部署到生产环境之前对其进行扫描是非常必要的。具备了这一能力之后，开发、运维和安全人员就能够获知已知问题的详细信息例如严重性、CVSS 评级以及对应的补救和修复措施。将容器漏洞扫描和流水线的合规规则结合在一起，能够确保仅有打过合适补丁的应用能够部署到生产环境，从而降低攻击风险。容器扫描还能帮助识别开源软件包和基础镜像中可能存在的恶意软件。镜像扫描仅是对现状的识别而非预防措施。组织需要谨慎选择扫描工具、在合理的环节中进行调用，在合乎规则的情况下，提供可操作的输出信息。

镜像加固

容器镜像是构建管道的第一次输出。因此必须对其进行安全加固，加固过程不仅需要考虑降低威胁，还要为整体环境下的应用运行提供可配置的能力。

需要在安全保障目标中评估以下几个问题：

执行环境应该限制到特定用户么？
资源访问应该受限么？
需要在内核级对进程执行做限制么？

容易应用清单扫描

应用清单描述了部署容器化应用所需的配置。正如在安全基准部分介绍的那样，NIST 800-190 之类的材料中推荐了容器化应用的最佳安全实践和配置。可以在 CI/CD 中对清单进行必要的扫描。

容器化应用清单的加固

和容器镜像类似，容器应用清单的加密也可以在构建和运行时进行。

需要在安全保障目标中评估以下几个问题：

满足环境运行目标的最小化限制是什么样的？

测试

云原生应用应该适用于传统应用相同的测试套件和质量标准——例如代码清洁、[测试金字塔]()[(https://martinfowler.com/articles/practical-test-pyramid.html]，为开发人员提供测试所需完整的基础设施，通过静态安全扫描（SAST）、依赖分析和扫描、动态应用安全测试（DAST）（例如 Mocking）等，为安全和合规提供实时的保障能力。

确定了安全问题之后（例如错误的防火墙或路由规则），进行根本原因分析之后，如果认为它有可能重复发生的话，开发人员就应该编写一个自动化测试，防止问题卷土重来。在测试失败时，团队应该收到反馈，改正 bug，试图在下一次合并中通过测试。（有效的测试）能够防范对同一段代码的变更造成的问题复现。

基础设施的单元测试是预防性措施，测试目标是基础设施即代码（IaC）配置中涉及的实体和输入项。针对现存基础设施的安全测试是一种检测性控制，并包含了保障、历史回归和意外配置检测（例如防火墙规则全面开放、过度授权的身份与访问管理（IAM）策略、未认证的端点）等内容。

基础设施和工作负载的加固应得到全面测试套件的支持，随着系统的成熟，基础设施和工作负载也能得到逐步加固。在构建过程中应该有对加固项目的测试，这些检查也应该在部署时执行，以评估整个生命周期中可能发生的变化或回归。

静态分析和安全测试

IaC 和应用清单、软件代码以及 IaC 的静态分析过程可能包括对错误配置的识别和漏洞扫描。IaC 代码应该和应用工作负载使用同样的流水线策略控制。

IaC 日益流行，越来越多组织使用这种方式来进行云和容器基础设施的部署，所以要警惕其配置问题可能暴露的攻击面。

在进行应用和基础设施的部署之前，应该对这些模板进行扫描，发现其中的不安全配置和其它安全问题。需要着重考虑的几个方面：

应用清单中包含的漏洞镜像。
一些不当配置（例如允许特权逃逸）。
安全上下文和系统调用可能对系统产生威胁。
资源限制。

动态分析

对已部署的基础设施进行动态分析，可能包含 RBAC 和 IAM 配置的检查，对网络暴露面的校验。确认 SOC 能够在各个环境中生效。动态分析也应该是测试的一环，应该在非生产环境中运行。

安全测试

对应用程序进行自动的安全测试是安全团队的工作焦点之一。测试套件需要进行持续更新，和组织入侵模型一致，能够对系统进行持续的可复用的安全测试。自动化的安全测试避免了人工的检查点控制，降低了时间消耗，提高了安全性和发布效率；自动化安全测试还能够显式的执行安全威胁来按需展示控制能力，从而提高系统安全性，并保持合规性。

制品和镜像

仓库

开源组件经常是从公共源中拉取的，组织应在管线中为各个阶段创建仓库。只有认证的开发者能够访问共有仓库，拉取基础镜像，基础镜像被保存到内部仓库，被组织中的团队大量使用。不同的团队或小组应该使用独立的私有仓库来保存各自的开发中的制品，最后一个 Staging 或预生产仓库用于保存用在生产环境里的镜像。这中措施能更严格地控制开源组件的出处和安全性，同时可以对 CI/CD 链的各个阶段进行不同类型的测试。

不管是什么仓库，都必须通过专门的认证和权限模型实施访问控制。对所有的连接都应使用双向 TLS。

签名、信任和完整性

在构建时对镜像内容进行签名，在使用前对签名进行校验，能够保证镜像数据在构建和部署之间不会被篡改，这样就保证了制品的完整性和可信性。确认过程首先要表明一个制品是经过审批的，还要验证制品是否具有有效的签名。在最简单的情况下，每个制品都可以由一个签名者签名，表明制品通过了测试和验证过程。然而多数情况下的软件供应链是比较复杂的，一个制品的构建依赖于多个验证步骤，因此需要有一组实体的认证。这方面的例子有：

容器镜像签名：对容器镜像清单进行签名的过程。
配置签名：对配置文件进行签名：GitOps 方式中很常见，能够对配置进行检查和验证。
包签名：对一个制品包进行签名。

对于通用软件工件，如库或 OCI 制品，签名表示它们的来源是经组织批准使用的。制品的签名和验证非常重要。强烈建议仓库使用双向认证，对仓库中镜像的变更或者提交代码都需要进行认证。

加密

对容器镜像进行加密，可以保证其数据的机密性，从构建阶段到运行阶段，数据都是保密的。即使发布过程受损，镜像内容仍然是保密的。这种机制可以用于保护交易密文或者其它机密材料。

镜像加密的还有一个使用场景就是对容器镜像进行授权。当镜像加密与密钥管理和/或授权和凭证分发相结合时，可以要求容器映像只能在特定平台上运行。容器镜像授权对于合规性使用案例非常有用，例如地理围栏或出口控制和数字版权媒体管理。

部署

图 4

The “Deploy” phase is responsible for incorporating a sequence of ‘pre-flight’ checks in order to ensure that the applications that are going to be deployed in the runtime environment conform and comply with organization wide security and compliance policies.

部署前置检查

部署之前应该对现状进行调研，检查以下状态：

镜像签名和完整性。
镜像的运行时策略（避免恶意软件和严重缺陷）
容器运行时策略（例如避免权限过高）
主机漏洞和合规控制。
工作负载、应用和网络安全策略。

可观察性和指标

把可观察性和指标引入云原生架构，能够提高安全方面的观察力，有助于解决和缓解异常情况；这个领域的工具能够收集信息并进行可视化展示。如果加入行为和启发式分析能力，团队能够检测到可疑事件、不明调用等异常行为并进行上报。AI、机器学习以及统计模型都是促进行为分析和启发式分析的手段。

应对和调查

应用应该提供日志，对认证、鉴权、行为和故障进行记录。开发人员应该在计划和设计阶段就开始这些工作。这些要素构成的证据链条，对于进行调查和根本原因跟踪时会非常有帮助。

对事故的应对和处理都需要进行取证，根据证据确定事件的根本原因，并为解决措施的实施提供反馈。容器环境的短暂性要求更灵活的工具集来对证据进行捕获和分析。将取证功能集成到事件响应计划和程序中，将提供获取和处理证据的方法，缩短确定根本原因的时间，并最大限度地减少损害风险。

运行时环境

图 5

运行时阶段包括三个关键领域：计算、访问和存储。虽说运行时环境是依赖开发、发布和部署阶段的成功完成，但运行时的安全性同样取决于前几个阶段的安全实践的有效性。以下各段将详细介绍这些关键组件的安全要求和影响。

计算

云原生计算的复杂性很高，并且还在持续演进之中。如果核心组件没有动用计算能力，组织就无法确保工作负载的安全。

Cloud native compute is a highly complex and continually evolving construct. Without core components to make compute utilization occur, organizations cannot ensure workloads are secure.

例如在共享主机上，用软件虚拟化环境运行的容器化多租户应用，这里使用面向容器的操作系统是非常有益的，这种操作系统是只读的，无关服务会被禁用。这样就很好地减小了攻击面；它还提供了隔离和资源限制，开发人员能够在共享主机内核上运行隔离的应用程序。为了增加防御纵深，注意不要让不同的数据敏感工作负载运行在同一个操作系统内核上。

安全应该贯穿容器平台和服务的所有层级，可以使用可信平台模块（TPM）或虚拟TPM（vTPM）硬件作为信任链的根基。基于硬件的信任链可以扩展到操作系统内核及其组件，以实现可信启动、系统镜像、容器运行时和容器镜像等的加密验证。

操作系统提供了 crypto 库之类的系统组件，用于远程连接、进程启动、管理等的内核函数。操作系统是容器的基础，因此操作系统漏洞会影响到这些主机上运行的所有容器和应用。同时配置不当的容器也会影响到主机内核的安全，从而影响到该主机上运行的所有容器中的服务。

编排

任何编排系统都会有很多组件，这些组件被分成控制、数据之类的不同平面。有时会需要有上层建筑，负责在几个不同的的相互独立的控制平面上维持状态。

编排系统都会面对威胁，这些威胁可能影响部署的整体安全性和运行时的持续安全性。恶意访问编排 API、未经授权访问和更改键值存储、编排器仪表板控制集群、拦截控制平面流量、API 滥用、拦截应用流量等都是潜在的威胁领域。使用最佳实践和加固配置来防止暴露在这些威胁中是很重要的[^7]。另外，对初始配置的任何更改都需要在运行时进行监控和检测，以确保集群的持续安全。其他的安全最佳实践，如最小化对控制平面的管理访问、职责分离和最小特权原则等，都应该得到执行。

安全策略

编排器的安全特性和各种配置选项必须认真对待，要对容器运行时所生成的容器的特权需要严加管控。使用高层次的策略和治理构造可以强制执行这些安全限制。

资源申请和限制

通过 cgroups 在不同的对象层级使用不同的资源请求和限制，有助于防止工作负载有意（如 Fork 炸弹攻击或挖矿）或无意（如在内存中读取大文件而未进行输入验证、水平自动缩放导致计算资源耗尽）的耗尽节点和集群资源。

审计日志分析

审计日志分析是识别和关联系统入侵、滥用或配置不当的最成熟方法之一。持续的地、自动化德对审计日志进行分析和关联，对于安全团队来说至关重要。和传统应用对比，云原生架构能够为工作负载生成更精细的审计配置，更方便进行过滤。对日志的过滤能力，能够避免下游处理机制的过载。与传统的日志分析一样，将日志中的数据关联/上下文转化为 “信息”，生成可操作的审计事件是重中之重，一次为基础来触发决策和进行事件响应。

违反组织政策的行为，会根据预先配置的一套规则进行过滤和识别。

为了能够对使用集群的实体的行为进行审计，启用 API 审计并对特定 API 或者动词进行过滤是很重要的。这些API 组或动词是安全团队、集群管理员或其他研究领域的团队的工作重心之一。攻击者可能会通过禁用日志或删除其活动日志来掩盖踪迹，为了制止这种行为，应尽快将日志转发到通过集群级凭证无法访问的位置。处理警报的系统应定期对假阳性报告进行调整，以避免警报泛滥、疲劳，并防止假阴性情况的出现。

控制平面认证和根证书

管理员应该配置所有的编排器控制平面组件，要求其使用双向认证，并且用周期性轮转的证书来进行认证，以此加固现有的控制平面。证书签发使用的 CA 可以是编排器自己的 CA，也可以是外部的。管理员应小心保护 CA 私钥。

Secret 加密

在容器编排或者部署环境中，可以在外部管理器或者编排器内部对 Secret 进行管理，介绍几个不同的保护方法：

使用外部密钥管理系统（KMS）加密
- KMS 是一种保护 Secret 的安全方式，这种方式中，密钥在外部 KMS 中加密，KMS 回家米保存 DEK（Data Encryption Key），用 DEK 加密后的数据保存在 ETCD 中。这种方式有一个选项是把 DEK 缓存在内存中，减少对外部 KMS 可用性的依赖，并更快的在创建 Pod 的时候进行解密。
完全用编排器管理加密
- 这种方式也会对 Secret 进行加密，但是密钥也同样由编排器管理。
不加密
- 例如某些编排器会用 Base64 对 Secret 进行编码，然后直接存储在键值库中。

使用外部秘密管理器可以限制使用未加密的 Secret 的风险，并降低密钥管理工作的复杂性。多数情况下，这些工具会以 controller 或者 operator 的形式运行，从而在运行时透明地进行注入或者证书翻转。

容器

运行时

容器运行时的监控和保护，需要从进程、文件和网络的角度入手。容器中只能使用被许可的 Capability 和系统调用（如 seccomp）。对于关键挂载点和文件的更改需要被监控和阻止。对二进制文件、证书和远程访问配置的更改需要被制止，还应保证容器仅执行允许范围内的网络访问。此外，还应检测并拒绝指向恶意域的网络流量。

微服务以及杜绝隐式信任

微服务方式部署的容器化应用，其边界就是微服务本身。因此定义策略限制特定微服务之间的通信是有必要的。0 信任微服务架构能够在微服务受到威胁时，禁止横向移动，减少威胁半径。运维人员应该确保使用网络策略之类的能力来对容器间通信进行限制，仅允许被授权的东西向访问流量。NIST SP 800-204 中做了一些微服务安全策略的工作，可以作为实现安全微服务架构的指南。

镜像信任和内容保护

组织可以使用策略引擎仅允许运行保障被授权和签名的镜像，从而实现可信的可控的工作负载。另外加密容器允许对容器中的敏感代码、方法或者数据进行保护。

服务网格

服务网格在服务之间进行连接，并在连接中加入了流量控制、服务发现、负载均衡、韧性、可观测性、安全性等额外能力。服务网格中的微服务无需在应用层次实现这些能力，开发者可以聚焦在业务逻辑的实现上。为了有效地确保云原生服务之间的通信安全，企业应该使用服务网格的动态数据加密来消除 Pod 之间和工作负载之间的隐式信任。试用服务网格还能够解决身份问题，（云原生环境下）3 层、4 层、IP 地址的认证都已经无法有效反应工作负载的身份。服务网格不但提供了网络侧的隔离和安全，还在网络层提供了重试、超时以及断路器等服务治理能力。服务网格在工作负载级别上提供的授权能够增强访问控制方面的安全性。

服务网格能够减小云原生环境中的被攻击面积，并提供零信任应用网络所需的框架基础。

运行时检测

通过对已部署工作负载的监控，团队能够判断当前运行状态是否符合预期。组织应持续对环境进行安全扫描和监控，否则环境中的工作负载可能会变成攻击者的游乐场。使用工具对来自容器的系统调用和网络流量进行检测、跟踪、汇总和报告，来检测意外或者恶意行为。

虽然回归测试和安全测试可以帮助防止已知的、预期的问题被部署到生产环境中，但是要阻止的不止这些。应该对工作负载进行动态扫描，以检测之前未知的恶意行为。例如在工作负载运行了 X 天之后，改写的 Sleep 命令从 etcd 进行数据渗透，这样的行为在大多数环境中都是预期之外，因此不包括在安全测试中。工作负载中的木马，可能存在时间或事件方式的延迟，只有通过与基线预期进行比较才能检测到，这通常是在彻底的活动和扫描监控中才能发现的。

Functions

Serverless function 是很容易受到攻击的，必须进行适当的保护。限制进程只能执行白名单中的 Function，不允许进程更改关键系统挂载点等。

Function 必须进行限制，仅允许访问特定服务，可以使用网络或者授权模型来完成这个限制。另外 Egress 网络必须进行监控，管理员通过监控来检测或阻止对 C&C（Command & Conrol）以及其它危险网域的访问。Ingress 网络的监控则可以检查和移除涉嫌渗透攻击的恶意流量和命令（例如 SQL 注入）。

Serverless function 中，可供租户使用的控制措施相对有限。例如损坏的身份验证、不安全的依赖服务以及不安全的 API 集成都可能成为安全问题的根源。确定所有 Function 都在租户资源中，进行数据隔离都有助于解决这些问题，然而隔离环境可能因为资源受限造成性能受损。

Bootstrapping

要对计算节点进行初始化，建立信任数据，然后才能保障工作负载和配置运行在正确的节点上。这个过程检查计算节点的物理和逻辑定位，并为其提供认证。一般来说，云供应商的供给过程会完成这个工作，也会依赖第三方进行信任的检查。

存储

云原生存储涉及到很多技术，按照访问方式可以分为两类，一类是面向工作负载的存储（例如卷）包括块存储、文件系统等；另一类是通过 API 访问的存储，例如对象存储、键值存储和数据库。

存储系统包含是数据访问界面，其中定义了应用或工作负载存储以及消费数据的接口，这个接口可以通过访问控制、认证、授权和加密传输等方式进行保护。

存储系统还包含一个控制平面管理界面，它通常是一个受认证和 TLS 保护的 API，也可能有更细致的访问粒度。一般来说，控制界面只能由编排器或者服务管理员通过服务账号的方式来使用。

存储栈

存储解决方案都由多层功能组成的，这些功能定义了数据的存储、检索、保护，及其与应用程序、编排器和/或操作系统的交互方式。每一层都有可能影响和冲击存储系统的安全性。一个常见的例子是将文件或块持久化到对象存储的文件系统。包括提供对外访问能力的顶层之内的每一层，都是需要一视同仁进行保护的。

编排

大多数编排系统都会实现各种抽象和虚拟化层，其中可能包括文件系统（如绑定挂载）、卷管理器以及基于协调器策略的用户或组级别的权限应用。与容器化和微服务架构的许多组件一样，对卷和存储的保护始终依赖于其他能力。如果用户能够在编排器或容器运行时内将他们的权限升级到 root，他们就会在环境中造成破坏。零信任、最小权限和访问控制的实现和执行是成功保护云原生架构中存储安全的关键。

系统拓扑和数据保护

要保护数据访问路径，和保障分布式拓扑中跨节点通信安全性，关键在于理解系统的存储拓扑。

常见的拓扑结构包括：

所有计算节点访问中央存储服务的集中式模型
将功能分布在多个节点上的分布式模型
以及将应用和存储工作负载结合在同一节点上的超融合模型。

要根据系统的拓扑模型来选择特定的、分层的安全机制，来保护存储中的数据和在存储位置之间传输的数据。

存储系统的关键功能就是为系统或服务中的持久化数据提供保护。这种保护首先通过向授权用户提供数据来实现，并应作为系统中的一个透明层存在。保护措施还可以包括奇偶校验或镜像、擦除码或复制等技术。接下来是针对完整性的保护，存储系统会在块、对象或文件中增加哈希和校验，主要是为了检测和恢复被破坏的数据，但也可以增加一层保护，防止数据被篡改。

缓存

缓存层，通常是完全独立的系统，是为了提高存储系统的性能，特别是文件系统、对象和数据库的性能而实施的。缓存层是数据层的前哨，因此同样需要应用适当的访问控制和安全策略，

数据服务

存储系统通常会实现一些数据服务，一次提供额外的功能对核心存储功能进行补充，这些功能可以在堆栈的不同层实施，例如复制和快照（数据的时间点副本）。这些服务通常用于将数据副本移动到远程位置，必须确保相同的访问控制和安全策略也适用于远程位置的数据。

物理和非易失性存储

因为云原生功能可以在内部进行部署，云原生存储安全并不局限于虚拟的云原生架构。重要的是存储系统最终会将数据持久化在某种形式的物理存储层上，这种存储层一般是非易失性的。现代物理存储（如SSD）通常支持安全功能，例如根据 OPAL 标准进行自我加密，以及快速/安全擦除功能。当包含数据的设备需要离开安全的物理位置时（例如出现故障后要返回给厂商），安全擦除是很重要的。

存储加密

存储系统可以提供数据加密，从而对数据进行保密。传输中或存储中的数据都可以实施加密，当使用存储系统时，应确保加密功能的实现是独立于应用的。

加密是有计算开销的，因此会对性能产生影响，但许多系统上都有加速选项可以减少这一开销。在选择数据的加密种类时，要考虑数据路径、大小和访问频率，以及安全算法的法规要求或额外的安全保护措施需求。此外，团队在考虑架构的加密要求时，也同样应该缓存的加密问题。

传输中的数据（网络中的数据）和静止中的数据（磁盘上的数据）都是加密保护的目标。存储客户端或存储服务器中都可以进行加密，加密的粒度将因系统而异（例如每卷、每组或全局密钥）。在许多系统中，传输中的数据是用 TLS 保护的（TLS 的额外好处是通过证书提供一个认证层[^8]。旧的协议（如 iSCSI）可能更难保证传输中的安全（尽管可以使用更复杂的解决方案，如 IPsec 或加密的VPN[^9]）。静止状态下的数据一般使用标准的对称加密算法（如 AES）进行保护，并可采用特定的加密模式（如针对块设备的 XTS）进行部署。

加密功能通常依赖于和密钥管理系统的集成。

持久卷保护

要确保只有授权的容器和工作负载才能访问卷，就需要对持久卷的访问进行保护。首要措施就是为命名空间定义信任边界，以隔离对卷的访问。使用安全策略阻止容器组访问工作节点加载的卷，并确保只有合适的工作节点能够访问卷。尤其需要注意的是，特权容器能够加载不同命名空间中的加载卷，所以需要其它措施来进行保护。

指定卷的 UID 或 GID 仍然允许同一命名空间的容器访问，不会提供数据保护。NFSv3 会假设客户端已经进行了认证和授权，而不进行验证。在实施保护时，必须考虑认证和授权的发生点，以及是否存在该操作的验证。

制品仓库

制品库应该对 OCI 制品进行签署和核实。同样需要注意的是，缓存和发布工具也应该有这种能力，确保缓存层有能力检测篡改或者对数据集投毒的企图。

CNCF 存储白皮书提供了更多的云原生存储的概念、术语、使用模式等技术资料。

访问

认证和访问管理

一个面向云原生架构的全面的认证和访问管理（IAM）方案至少要提供服务认证能力。维护或者运营自建云、混合云的组织，需要进行用户和设备的身份管理。如果是多云环境中的应用和工作负载，身份联合是实现成功的关键因素。

应用程序和工作负载应该显示地使用双向认证的方式进行授权。由于云计算的短暂性，密钥轮换和寿命需要频繁而短暂，以维持敏态和控制的需求，在凭证发生泄露时，其泄露半径也能得到有效控制。

为了让客户端和服务器通过加密技术双向验证身份，所有的工作负载都必须利用相互/双向传输认证。

认证和授权必须在环境内部和整个环境中独立确定（决定点）和执行（执行点）。理想情况下，应实时确认所有工作负载的安全操作，在可能的情况下验证更新的访问控制和文件权限，因为缓存可能允许未经授权的访问（例如访问被撤销未在缓存中进行验证）。工作负载的授权是根据属性和角色/权限分配给它们的。强烈建议组织同时使用基于属性的访问控制（ABAC）和基于角色的访问控制（RBAC），以便在所有环境中和整个工作负载生命周期中提供精细的授权执行。这样的态势可以实现深度防御，所有的工作负载都能够接受、消费和转发终端用户的身份进行上下文或动态授权。这可以通过使用身份文件和令牌来实现。如果不执行这一点，就会限制组织真正对系统对系统和服务对服务的调用进行最小权限]访问控制的能力。

需要注意的是，在微服务的背景下，应用或服务身份也是至关重要的，应用的身份可能会被恶意服务欺骗和冒充。使用强认证系统和服务网格可以帮助克服这些问题。

所有工作负载和集群的控制过程，不管是人还是非人。都需要进行认证，他们的行动必须根据控制策略，对每个请求的上下文、目的和输出进行评估。为了简化认证过程，可以和企业功能（如多因子认证）进行对接。必须通过本节提到的访问控制机制进行授权。

凭据管理

硬件安全模块（HSM）

读者应该尽可能使用 HSM 这样的技术，用物理方式进行密钥保护。如果无法做到，则应该使用软件的证书管理器。

凭据管理周期

加密密钥数据应该由 HSM 或者基于软件的密钥管理系统生成。

Secret 的有效期应该尽可能短，超过期限后即宣告失效。为了达成“短寿”目标，密钥的生成机制应该是高可用、高易用的。如果使用了长效的 Secret，则应建立相应的流程和指导，定期进行轮换或撤销，特别是在秘密意外泄露的情况下。所有秘密都必须通过安全的通信方式进行分发，并应得到与其保护的访问或数据水平相称的保护。

在任何情况下，Secret 都应该在工作负载运行时通过非持久性的机制进行注入，这些内容不会在日志、审计、或者系统转储（例如环境变量）时泄露。

可用性

拒绝服务攻击和分布式拒绝服务攻击

云原生应用程序中的拒绝服务攻击是一种网络攻击。攻击者尝试破坏关键的云原生应用组件（例如微服务）、或者云原生应用赖以运行的编排层组件以及健康检测系统，让云原生服务无法正常提供服务。拒绝服务供给通常会通过项关键微服务或资源发起大量无效请求，引发系统过载的方式，来阻止系统的正常运行。

典型的分布式拒绝服务攻击会包含大量的入站流量，对云原生应用或者其依赖的上游设施进行冲击，这些流量来自大量不同的源头，需要在攻击到达云原生应用之前识别和转移流量，来缓解攻击造成的损害。

安全保障

从根本上来说，安全就是一个风险管理的过程，其目标是检测和解决系统风险。组织根据自身风险状况和容忍度来对系统进行持续加固，以期降低、转移或者消解风险。安全团队可以对组件进行评估，制定最小化、有弹性、功能正常的加固方案。例如团队决定更新基础镜像，应该对更新可能增加的额外端口、权限和软件包进行审查，接受、改变或进行限制。

而合规原则是一种控制原则，用来确定或创建需求，并根据需求对系统进行评估。评估结果是二进制的（通过或失败），但可能包含第 1 类（假阳性）或第 2 类（假阴性）错误，应视作 CI/CD 管线的测试结果进行评估。因此，合规性和安全保证是相辅相成且无法互换的过程。合规系统不能保证安全，安全系统也不能保证合规。

威胁建模

对于采用云原生技术的组织来说，对风险进行识别，并对识别结果进行控制和消解的主要机制就是对应用、数据流、支持流程和基础设施进行威胁建模。实现这一目标的方法与典型的威胁建模差别很小。以下指南是对 OWASP 威胁建模法的改进，建议用于云原生环境。

端到端架构

如果对个人或组织的云原生架构有了清晰的认识，就应该对数据影响进行指导和分类。这有助于团队根据架构进行数据的分布和其他保护机制的建设。云原生架构不仅仅是针对核心组件的，还应该包含源码、存储等所有软件开发周期中的其它元素。在对威胁建模时，这些相关因素都应该考虑。

威胁识别

在考虑针对云原生能力特定的威胁时，建议采用成熟的、使用良好的模型，例如 STRIDE 或者 OCTAVE。云原生架构的常见威胁包括但不限于如下内容：

通过社会工程方法窃取凭证，获取管理员身份。
篡改 API 服务配置文件或者证书，导致 API Server 重启，或破坏 TLS 认证失败。
禁用或配置错误的审计策略，导致对攻击行为缺乏证据支持。
如果攻击者破坏了正在运行的工作负载，成功进行渗透之后，就有可能造成信息泄露。
拒绝服务攻击能够导致没有资源限制的容器消耗整个节点的 CPU 和内存，导致节点离线。
特权 Pod 或者缺乏限制的安全策略，可能导致特权提升的后果。

云原生安全需要考虑的威胁者和已知的威胁模型是一致的：

内部恶意
内部无意
外部恶意
外部无意

建议各组织利用 Cloud Native Landscape 的现有资源，获取有关云原生架构威胁的其他信息。

利用管线和 IaC 可能对某些威胁产生消解作用，或降低其成功或发生的可能性。

与任何云原生流程一样，迭代和反馈非常重要。在威胁建模的背景下，应重新评估现有的措施、机制和指标，判断其是否准确地反映了架构不断变化的运行状态。

威胁情报

从设计和目的来看，云原生应用是由多个动态组件组成的集合，这些组件包含第一方和第三方的代码和工具，这意味着必须跟进网络活动和云原生应用组件应用威胁情报。网络威胁情报是关于威胁和威胁行为者的信息，有助于缓解有害事件。云原生系统中的威胁情报将利用在网络或主机上观察到的指标，如IP地址、域名、URL和文件哈希，这些指标可用于协助识别威胁。行为指标，如威胁行为者的战术、技术和程序，也可用于识别云原生组件中的威胁行为者活动。MITRE ATT&CK 云框架包括可作为建立和验证可观察性的起点的云原生战术和技术。

事件响应

如果组织机已经具备了事件响应和分流机制，关注点应该放在如何将既有机制应用到云原生工作负载的问题上，云原生工作负载在节点隔离（Pod 会在不同节点上漂移）、网络（IP 地址动态分配）和不可变性（对容器内文件系统的更改通常会在重启后丢失）方面和传统流程的假设很不一样。因此需要重新评估这些假设并根据需要更新应用或者更新应对流程。观察工具和取证工具需要了解云原生应用的特点（例如 Pod 和容器），以便管理或重建受损系统。在一些编排系统中，因为将工作负载视为无个性的不持久的，证据的获取可能比较困难。另外要提到的一点是，从头构建事件响应和分流机制是可行的，但是不在本文范围之内。

安全堆栈

环境

预检安全工具

环境预检安全工具应最大限度地进行加固并确保遵守安全方面的最佳实践，同时最大限度地减少与托管环境、网络和协调层有关的权限。工具还应该确保合规性不会在运行时被破坏。

计算和节点检查

应利用工具确保计算资源的加固和安全性，例如用主机漏洞扫描器和 CIS 基准扫描器进行检查，通过后才能将资源标记为可以交付。

运行上下文

覆盖预检安全的工具适合作为 CI 管线的一部分，对文件、制品（例如容器）和 IaC 进行扫描。CD 管线中运行的安全工具更适合在特定上下文的特定配置中运行。

运行中的安全工具

工作负载和运行时安全

运行时安全工具可以分为四个关键的保护区域：

进程、容器或者系统层的安全
网络安全
数据安全
应用安全

每个保护区域都可以使用多种工具。策略引擎可以执行手动编写或者基于推荐系统的策略。策略一旦投入使用，这些工具将提供可预测的结果，并且可以在仅做监视、或者强制模式下使用策略。

威胁和漏洞信息可以让安全工具能够拦截来自未知威胁和已识别威胁的异常行为和安全事件。这些信息通常会定期更新。这些信息不但能够补充策略引擎的能力，还能实现为一个覆盖更大领域的防御工具。团队应该关注网络威胁情报中已知的 C&C 服务器、挖矿域名、恶意软件校验和等信息，从而有目的的更新策略工具。

尽管现有工具可以提供机制来管理由误报和误报问题产生的噪声并处理已知威胁，并使用策略驱动的防护来规范操作，但基于机器学习（ML）的安全工具提供了已知和未知威胁的检测层，超出了可预测工具可以建立的范围。例如，对基于身份的授权日志进行基于行为的分析，以检测内部威胁和破坏，或者对编排器审计日志进行自适应分析，以检测服务帐户的试探和盗用行为。机器学习驱动的主机系统调用模式分析可用于检测容器逃逸尝试，或主机爆破尝试。

用于监控和跟踪云原生编排器的安全工具通常以特定领域的商业产品的形式提供，其中会包含跨越多个领域的强大功能，例如策略控制、合规检查、基于 AI/ML 的异常检测和良好的集成接口。

和工作负载一样，用云原生方式实现的用于监视，报告或控制环境安全性的工具会更加便于使用，管理和部署。

零信任架构

零信任架构通过细粒度拆分、微边界的架构，并通过执行策略限制消除数据、资产、应用程序和服务的隐式信任，从而减轻了网络威胁横向扩散的可能性。零信任架构的最常见实现方法是依赖于加密概念的。首先要用硬件或者令牌来保护特定的密钥信息，并且能够用安全的方式和平台进行通信。

零信任架构通常由几个部分组成：

每个实体都能创建自己的标识
每个实体都能独立地认证其它实体（例如用公钥体系）
实体之间的通信是加密且不可篡改的

零信任架构以信任根来创建零信任的各个组成部分：给实体或者进程绑定防篡改的信任能力，构成框架的基础成员。然后需要实现自证、验证、和证明实体身份的能力。例如对于容器服务的来说，如何检查该容器是否是它声称的身份？这需要使用编排器进行验证，但是要信任编排器，我们需要确保其不受干扰地运行，只有它在运行受信任的操作系统和 BIOS 等基础设施上的时候，才能确保这一点。这实际上也是一个信任链条。

零信任架构也需要实体之间的通信安全。网络分段能为零信任架构提供帮助，值得考虑，但这并不能覆盖零信任的需求。编排器的网络策略以及服务网格都是全面的零信任方案组件。网上有更多零信任相关概念的相关信息。

最小权限

最小权限原则非常重要，某种程度上说，是云原生架构中最重要的一方面，这个技术栈的所有层面在进行认证和授权的设计实现过程中，都需要考虑这个原则。传统的最小权限原则是在账户层考虑的，这个账户可能是人，也可能是服务。

云原生环境中，应该在堆栈的每个层次使用最小权限原则。在评估负责每个层次的工具时，也应该考虑到这一点。在探索各种产品和能力时，会发现很多容器缺省就是特权模式的，或者是要求 root 权限进行运维的。因此可能需要一些额外的隔离措施来运行这些特权负载。组织需要考虑对不同特权的领域进行隔离，在工作负载和部署中采用最小权限模式，可能包括从 cgroup 和系统调用，到制品管理和非 root 构建等多个方面。

为了持续减少潜在的攻击面积和和控制影响范围，组织需要在其架构的每一个层次上实施最低权限原则。这不仅适用于在其角色中执行各种功能的个人，也适用于在特定环境中执行的服务和工作负载。无根服务和容器对于确保如果攻击者确实进入组织的环境，他们不能轻易地在他们获得访问权的容器和底层主机或其他主机上的容器之间进行穿越至关重要。

强制性访问控制（MAC，例如如 SELinux 和 AppArmor）可以限制超出为容器或命名空间设置的权限，并在主机级别提供额外的容器隔离，以防止容器越狱或从一个容器转向另一个容器以升级，得到超出现有访问控制所允许的权限。

角色和责任

在转向云原生架构和部署时，组织应该对传统安全角色和责任进行调整，并创建云原生特有的新安全角色。随着现代开发方法论的快速发展，以及 IT 活动与业务需求的更好结合，安全工作必须具有适应性、具备应对实际风险相匹配的能力和透明性。期望开发人员和运维人员成为安全专家是不合理的。安全从业人员需要与开发、运维和其他项目角色合作，使安全和合规性的执行和开发生命周期充分结合。开发人员使用的工具就能实时报告发现（安全）问题，并像处理构建失败一样去解决问题。

在云原生环境中管理安全性时，在 DevOps 环境中经常出现界限模糊的情况，这里还是应该进行明确的职责分离（SoD）。尽管开发人员将更多地参与实施和执行安全措施，但他们无需设置策略，也不必了解角色所不需要的区域等。应根据组织的风险承受能力和业务实践，在角色之间、产品之间和应用团队之间进行职责分离。可以理解，小组织中的个人会履行许多职责以保持业务蓬勃发展时，这种分拆可能很困难。然而，随着组织的不断发展，个人的认知也会发生变化，实施不同角色的权限让个人能够发挥独特作用，也有助于执行 SoD。最终将重组角色重新分配给新的成员，但是不会为新角色增加范围。

随着产品和服务迁移上云，组织将需要重新评估其资产风险。随着使用中的技术及其部署堆栈的所有权和管理方面的变化，管理人员会面临风险态势的急剧变化。资源提供者和团队之间的共同责任将要求更改风险接受、转移和新的缓解机制的阈值。

合规

系统应当具备一定安全控制措施，能够应对监管和合规性指导，让云原生资源更加安全。这样做还可能使相关监管机构和审计人员的工作过程变得更加方便，系统甚至可以通过设计和规划，最终使用插件模式实现对各种监管机构的自动合规。虽然合规性通常需要利用安全基准来提高安全性和配置管理的执行力，如 CIS 基准，还是建议使用机器可读的合规性控制框架和语言。

监管审计

金融、卫生、政府等行业需要遵守特定的要求来进行系统保护。用户信任这些系统和他们的交互是安全的和私密的。每个组织都应该评估适用于自己的监管标准（例如 PCI-DSS、HIPAA、FedRAMP、GDPR 等），然后要确定如何把具体需求落地到自己的云原生系统之中，以及如何在现实世界中实施这些标准。这种支持特定标准的证据收集机制应该尽量通过不可抵赖性的环节来实现自动化。

角色和用例

重点是安全、保护、检测和尽可能的自动响应。它不一定是单独的开发工具，而是透明地集成到开发流程中的安全工具，以执行安全策略，在此过程中可以进行快速反馈和最直接的补救行动。有关云原生安全用例的具体信息，请参考 [SIG-Security 的用例列表]（https://github.com/cncf/sig-security/blob/master/usecases.md）。

业界

企业

企业采用云原生模式的核心关注点是：在满足业务目标的同时，保持当前的流程和程序。当整个组织引入新的标准和实践时，将互操作性、数据丢失或泄漏以及安全风险暴露保持在最低限度。

微型企业

小企业采用云原生模式的核心关注点在于能否专注于短期目标，能否促进创新以应对激烈的竞争。资源、预算、技术深度和最佳实践的缺乏阻碍了他们适应云原生解决方案的能力。小企业需要可重复的模式和小规模的 IT 足迹来解决这些挑战。

金融

金融行业关注的核心领域是未经授权的信息披露、欺诈和资金可用性，这对成功采用云原生技术至关重要。欺诈会直接影响资金的可用性，因此金融交易的完整性是头等大事。

医疗

医疗保健行业关注的核心领域是未经授权的信息披露、记录的及时性和可用性以及记录的准确性，这些都是采用云原生技术成败的决定性因素。由于医疗行业的性质和实践，记录及其相关内容的可用性是做出医疗决策的基础。在没有这些信息的情况下，就会形成新的记录。

学术和教育

教育机构成功采用云原生技术的核心关注领域可能取决于预期的最终用户。面向未成年人的机构可能有额外的法律要求，以保护未成年人的机密性，因此要重视访问控制能力。除此以外，各机构应关注教育内容对终端用户的可用性。

公共领域

公共部门组织关注的核心领域是安全、数据主权、合规性和供应商锁定，这些领域对于成功的云原生至关重要。这些障碍来自于机构为保护公共利益而制定的法规。在公共部门，保持公共和政府实体之间的和谐和信任是必须保障的。此外，部署和功能的及时性也可能是一个强有力的考虑因素。采用云原生，加上现代方法论，可以提高组织效率，这对公共部门的许多领域会产生极大促进。

云原生安全的演变

容器技术是一个不断发展的领域，得到了广泛的应用。云原生技术的威胁状况以及在缓解和解决这些威胁的方法也在不断变化。除了安全容器平台的复杂生态系统外，这些都需要一个全面制定、深思熟虑的安全策略，并对安全策略的执行、响应和操作纪律进行技术控制和自动化。

如果实施得当，容器可以提供巨大的安全优势。它们提供了更大的透明度、模块化、减少攻击面、更容易的应用组件更新以及应用组件运行的一致环境。这种一致性使得并行安全能够在开发、测试和生产运行环境中茁壮成长。它们还可以减少企业范围内安全事件的影响，当实现应用程序之间建立的适当隔离时（基本上可以在可能拥有扁平网络的企业中实现微观分段），作为分层防御-深度安全策略的一部分。

在当前安全方面的所有挑战、所需安全工具的数量以及市场上技能和人才的短缺，确保容器平台的安全是一个巨大的挑战。我们预计，随着云提供商提供的容器服务产品越来越成熟，在互不兼容的规范上集成了更多的云原生安全与智能工具，我们将看到更多的迁移到云端。这些产品作为共同责任模式的一部分，最终会降低企业的开销。

因此容器的采用、以及云原生的采用，将继续推动企业的数字化转型进程。企业已经开始尝试 Serverless 架构和设计来提供一些服务，但考虑到在编排 Function 构建业务功能时，可视性降低的挑战，以及现有的大量尚未知晓的安全挑战，使用 Serverless 构建整个业务功能仍在发展阶段。简而言之，随着服务提供商的安全控制以类似于现有容器生态系统的方式减少消费者的开销，Serverless 在云原生架构中的应用预计将随着时间的推移而增加。

然而，威胁状况总体上保持不变，顶级弱点始终被同一组攻击者利用。我们看到的最显著的变化是攻击者针对云原生组织和应用采取的攻击方式和机制。任何针对容器编排者和部署的攻击都在增加，这一点从通过渗透或木马镜像进行的挖矿行为可以看出。与任何开始达到市场饱和的创新技术一样，攻击者会利用任何可用机会。

随着这些攻击变得更普遍、更复杂、更扩大，云原生安全必须不断发展，企业和 DevOps 团队需要更加重视。我们看到安全策略即代码的案例越来越多，但在安全策略的执行、检测和响应方面，还有很大的演进和增加自动化的空间。很明显，即时和自动化的安全智能和响应将是挫败攻击，甚至从攻击中自我修复的关键。甚至可能在§[^9]发生时进行调整和整合。

容器取证工具和技术将需要不断发展，以跟上云原生的发展方向。这一点尤为重要，因为在基础设施即服务和其他即服务模式的背景下，事件的数量和复杂性都在增加。

结论

在过去的十五年里，社区见证了云服务和技术的快速应用，最近更是大力推动云原生模式的发展。如同安全行业的任何新商品一样，创新者们都在不断摸索和推进技术的早期应用和测试。

处于技术鸿沟边缘或早期多数的组织，应认真分析和应用核心安全概念，以缓解加固和环境控制的滞后现状。

虽然对于我们今天看到的和未来即将出现的大多数创新来说，可能还不存在针对安全的指导和控制，但在设计、开发和部署新功能时，可以持续应用云原生架构中的核心安全概念。

这些核心安全概念是：

防止未经授权的访问（个人和非个人实体）通过持续地从已知的良好状态重新建立基础，减少资产对未经授权实体的暴露。
不变性以保持内容和代码的完整性。
服务、工具和内容的可用性——分布提供弹性和冗余。
审计和问责——提供了一个机制来确保合规，并跟踪授权的变化。

参考

NIST 800-204 Security Strategies for Microservices-based Application Systems

NIST 800-190 Application Container Security Guide

https://www.cisecurity.org/benchmark/Kubernetes/

Threat Modeling: 12 Available Methods

https://owasp.org/www-community/Application_Threat_Modeling

NIST Application Security Container Guide, Center for Internet Security (CIS), NIST Security Strategies for microservices and OpenSCAP benchmarks exist for Docker, Kubernetes, and several managed Kubernetes distributions.

MITRE ATT&CK Matrix For Kubernetes

致谢

This white paper is a community effort driven by the members of the CNCF Security-SIG. Thank you to everyone for their outstanding contributions. Special thanks to Emily Fox and Jeyappragash JJ.

Contributors:

Aradhna Chetal - TIAA
Brandon Lum - IBM
Chase Pettet - Mirantis (Chase.Pettet@mirantis.com)
Emily Fox - US National Security Agency (NSA)
Gadi Naor - Alcide
Harmeet Singh - IBM
Jeff Lombardo - Independent
Jeyappragash JJ - Tetrate IO
Pushkar Joglekar - Visa
Rowan Baker - ControlPlane
Andrew Martin - ControlPlane
Trishank Karthik Kuppusamy - Datadog
Vinay Venkataraghavan -Prisma Cloud (Palo Alto Networks)
Wayne Haber - GitLab
Mark Bower
Alex Chircop - StorageOS

Reviewers:

@justincappos
@lumjjb
@whaber
@craigbox
@anvega
@magnologan
Alok Raj - XenonStack (alok@xenonstack.com)
@nyrahul
@ranio1
@lizrice
@justincormack

[1^]: Another model to consider is Cloud, Clusters, Containers, and Code: https://kubernetes.io/docs/concepts/security/overview/

[2^]: Example - MITRE ATT&CK Framework for Kubernetes

[3^]: Shifting security left often leaves organizations to lapse operational security monitoring. It is important that security exists in all parts of the lifecycle and organizations continually evaluate other aspects of their business and technology processes where they may reach beyond modern security paradigms to embrace security as a culture and habit.

[4^]: Human capital is a vital asset necessary to the success of any organization, the corresponding intellectual property and relational capital brought as a result is equally in need of protection.

[5^] https://blog.aquasec.com/malicious-container-image-docker-container-host

[6^]: According to Applied Software Measurement, Capers Jones, 1996 and adjusting for inflation - 85% of defects are introduced during coding with a cost of $41 to fix compared to a post release fix cost of $26,542.

[7^]: cisecurity.org maintains a listing of benchmarks for hardening

[8^] It is critical to note that while authentication is available for use, mutual authentication is the preferred mechanism to not only verify the client but also the server (outsider versus insider).

[9^]: Utilization of a VPN does not guarantee encryption.

[10^]: The concept of regression proofing is best explained as a facet of antifragile behaviors within technology environments. Instead of remaining resilient and robust against adverse conditions and attacks, technology can proactively adapt and thrive when subjected to them.

eBPF 概念和基本原理

Fri, 13 Nov 2020 21:16:35 +0800

原文：What is eBPF and How Does it Work?

作者：Virag Mody

大约一年前，有个朋友想要用 Rust 开发一个 EVM Assembler。在他的一再要求之下，我开始帮忙编写单元测试。那时候我还不大了解操作系统的相关知识，只好开始学习一些语法和词法方面的东西。很快这个事情就无以为继了，然而我对操作系统有了一些整体了解。之后他对 eBPF 赞赏有加时，我觉得我的春天又来了。

eBPF 的门槛有点高，有 500 字的小品，也有 Cilium 铺天盖地的文档。我编写本文的目的，是针对这一新技术读者提供一个全面的入门介绍，用户可以以此为基础，进行进一步的探索。后续可以阅读 Linux Weekly News、Brenden Gregg 的网站以及 Cilium 文档学习更多相关知识。本文设计的内容包括：

eBPF 的用处
eBPF 的原理
eBPF 的实例
如何开始使用 eBPF

eBPF 的用处

有了 eBPF，无需修改内核，也不用加载内核模块，程序员也能在内核中执行自定义的字节码。eBPF 和内核紧密联系，下面先介绍一些相关的基本概念。

Linux 系统分为内核空间和用户空间。内核空间是操作系统的核心，对所有硬件都具备不受限制的完整的访问能力，例如内存、存储以及 CPU 等。内核既然具备了这样的超级权限，势必需要严加保护，仅允许运行最可靠的代码。而用户空间运行的就是非内核的进程——例如 I/O、文件系统等。这些进程仅能通过内核开放的系统调用，对硬件进行有限的访问。换句话说，用户空间的程序一定要经过内核空间的过滤。

系统调用接口能够满足绝大多数需要，开发者在面对新的硬件、文件系统、网络协议甚至自定义的系统调用时，还是需要更多的弹性的。在不修改内核源码的情况下，用户代码要直接访问硬件怎么办呢？可以使用 Linux 内核模块（LKM）。用户空间一般是需要通过系统调用来访问内核空间，而 LKM 是直接加载到内核的，是内核的一部分。LKM 最有价值的特点之一，就是可以在运行时加载，不用编译内核也不用重启机器。

图 1：LKM 的动态加载和卸载

LKM 非常有用，但是也引入了很多风险。内核和用户空间不同，要进行不同的安全考量。内核空间是为了操作系统内核这样的特权代码准备的。系统调用连接了内核和用户空间，让用户空间能够对硬件进行合适的操作。换个说法，LKM 是能够让内核崩溃的。模块和内核的紧密关系，使得安全和升级成本直线升高。

eBPF 是什么

eBPF 是一个用于访问 Linux 内核服务和硬件的新方法。这一新技术已经用于网络、出错、跟踪以及防火墙等方面。

dtrace 是一个 Solaris 和 BSD 操作系统上的动态跟踪工具，eBPF 受到 dtrace 的启发，原意是设计一个更好的 Linux 跟踪工具。跟 dtrace 不同的是，Linux 无法获取运行中系统的鸟瞰视图，它被系统调用、库调用以及函数所限制。一小撮工程师在 Berkeley Packet Filter（BPF）基础之上，构建一个内核虚拟机级别的包过滤机制，提供了类似 dtrace 的功能。2014 年第一个版本适配了 Linux 3.18，提供的功能相对较少。要使用完整的 eBPF，需要 Linux 4.4 或以上。

上图对 eBPF 架构进行了一个简单的展示。eBPF 程序需要满足一系列的需求，才能被加载到内核。Verifier 中有一万多行代码用来对 eBPF 程序进行检查。Verifier 会遍历对 eBPF 程序在内核中可能的执行路径进行遍历，确保程序能够在不出现导致内核锁定的循环的情况下运行完成。除此之外还有其它必须满足的检查，例如有效的寄存器状态、程序大小以及越界等。安全控制方面，eBPF 和 LKM 是颇有差异的。

如果所有的检查都通过了，eBPF 程序被加载并编译到内核中，并监听特定的信号。该信号以事件的形式出现，会被传递给被加载的 eBPF 程序。一旦被触发，字节码就会根据其中的指令执行并收集信息。

所以 eBPF 到底做了什么？程序员能够在不增加或者修改内核代码的情况下，就能够在 Linux 内核中执行自定义的字节码。虽说还远不能整体取代 LKM，eBPF 程序可以自定义代码来和受保护的硬件资源进行交互，对内核的威胁最小。

eBPF 的机制

前面介绍了 eBPF 的基础架构。这些能力是由多个组件协同实现的，每一种都有自己的复杂度。

eBPF 程序剖析

事件和钩子

eBPF 程序是在内核中被事件触发的。在一些特定的指令被执行时时，这些事件会在钩子处被捕获。钩子被触发就会执行 eBPF 程序，对数据进行捕获和操作。钩子定位的多样性正是 eBPF 的闪光点之一。例如下面几种：

系统调用：当用户空间程序通过系统调用执行内核功能时。
功能的进入和退出：在函数退出之前拦截调用。
网络事件：当接收到数据包时。
kprobe 和 uprobe：挂接到内核或用户函数中。

辅助函数

eBPF 程序被触发时，会调用辅助函数。这些特别的函数让 eBPF 能够有访问内存的丰富功能。例如 Helper 能够执行一系列的任务：

在数据表中对键值对进行搜索、更新以及删除。
生成伪随机数。
搜集和标记隧道元数据。
把 eBPF 程序连接起来，这个功能被称为 tail call。
执行 Socket 相关任务，例如绑定、获取 Cookie、数据包重定向等。

这些助手函数必须是内核定义的，换句话说，eBPF 程序的调用能力是受到一个白名单限制的。这个名单很长，并且还在持续增长之中。

Map

要在 eBPF 程序和内核以及用户空间之间存储和共享数据，eBPF 需要使用 Map。正如其名，Map 是一种键值对。Map 能够支持多种数据结构，eBPF 程序能够通过辅助函数在 Map 中发送和接收数据。

执行 eBPF 程序

加载和校验

所有 eBPF 程序都是以字节码的形式执行的，因此需要有办法把高级语言编译成这种字节码。eBPF 使用 LLVM 作为后端，前端可以介入任何语言。因为 eBPF 使用 C 编写的，所以前端使用的是 Clang。但在字节码被 Hook 之前，必须通过一系列的检查。在一个类似虚拟机的环境下用内核 Verifier阻止带有循环、权限不正确或者导致崩溃的程序运行。如果程序通过了所有的检查，字节码会使用 bpf() 系统调用被载入到 Hook 上。

JIT 编译器

校验结束后，eBPF 字节码会被 JIT 编译器转译成本地机器码。eBPF 是 64 位编码，共有 11 个寄存器，因此 eBPF 和 x86、ARM 以及 arm64 等硬件都能紧密对接。虽然 eBPF 受到 VM 限制，JIT 过程保障了它的运行性能。

总结

上面的概念们放在一起，eBPF 程序通过安全检查后插入钩子，被事件触发之后，程序会启动执行，用辅助函数和 Map 来对数据进行存储和操作。下一届我们来研究一下它们的协同方式。

一个例子

在 Gravitational 有一个叫做 Teleport 的开源项目，其中使用了 eBPF 程序进行跟踪和网络操作。有的组织希望知道 SSH 会话中发生了什么，Teleport 提供 SSH 访问途径的同时，加入了对用户行为的记录。可以通过对命令编码、在 Shell 脚本中运行命令的方式来进行混淆，从而阻碍对会话的记录。

Teleport 4.2 中，我们引入了会话记录，其中用了三个 eBPF 程序来获取 SSH 会话，并将其转化为结构化的事件。

例如 echo Y3VybCBodHRwOi8vd3d3LmV4YW1wbGUuY29tCg== | base64 --decode | sh，我们能够在终端抓取到这个命令，但是这并无意义，用户已经对命令进行了混淆，但是有了 eBPF，我们就能知道，用户试图隐藏的是 curl：

{
  "event": "session.command",
  "path": "/bin/sh",
  "program": "sh",
  "argv": [],
  "login": "centos",
  "user": "jsmith"
}
{
  "event": "session.command",
  "path": "/bin/base64",
  "program": "base64",
  "argv": [
    "--decode"
  ],
  "login": "centos",
  "user": "jsmith"
}
{
  "event": "session.command",
  "path": "/bin/curl",
    "argv": [
    "http://www.example.com"
  ],
  "program": "curl",
  "return_code": 0,
  "login": "centos",
  "user": "jsmith"
}
{
  "event": "session.network",
  "program": "curl",
  "src_addr": "172.31.43.104",
  "dst_addr": "93.184.216.34",
  "dst_port": 80,
  "login": "centos",
  "user": "jsmith",
  "version": 4
}

借助 eBPF 的能力，我们把这种混淆行为转换为事件流，便于导出和分析。Teleport 用 execsnoop、opensnoop 以及 tcpconnect 来恢复这些事件。特别会关注的是 tcpconnect，它最终将信息以 JSON 的形式返回来。

tcpconnect 会跟踪 TCP 连接。像 Teleport 这样用 SSH 证书管理访问的工具来说，必须要知道 TCP 连接的发起情况。tcpconnect 能跟踪 connect() 系统调用，该调用会在 Socket 上初始化一个连接。要对这个情况进行跟踪，tcpconnect 在内核中插入了一个 kprobe，能够动态进入任何例程：

# initialize
BPF b = BPF(text=bpf_text) b.attach_kprobe(event="tcp_v4_connect", fn_name="trace_connect_entry") b.attach_kretprobe(event="tcp_v4_connect", fn_name="trace_connect_v4_return")

程序被触发以后，tcpconnect 会开始输出信息，下表展示的就是这样的信息：

$ ./tcpconnect
PID   COMM  SADDR             DADDR           DPORT
-----------------------------------------------------
2315  curl  172.31.43.104     93.184.216.34   80

所有这些数据都是用辅助函数收集而来。如果看看 Python 代码，会发现 tcpconnect 试用了来自 bcc 的 BPF 库的辅助函数来对上述输出内容进行格式化。

...
struct ipv4_data_t data4 = {.pid = pid, .ip = ipver}; 
data4.saddr = skp->__sk_common.skc_rcv_saddr; 
data4.daddr = skp->__sk_common.skc_daddr; 
data4.dport = ntohs(dport); 
bpf_get_current_comm(&data4.task, sizeof(data4.task));
...

eBPF 入门

行文至此，我希望读者已经对 eBPF 有了一个最基础的了解，知道了他的重要性以及基本原理。是时候浏览更多技术文档和文章了。本文中提供了不少链接，不过这里最推荐的是 Quinten Monnet 的博客。

自行编写代码，开发自己的 eBPF 可能有点难。但是很多开源的开发工具链正在涌现，简化了很多 eBPF 的相关场景。下面介绍几个最流行的：

BCC：BCC 是一个工具包用于创建高效的内核跟踪和处理程序，并包含了很多有用的工具和示例。BCC 简化了 BPF 程序的开发，内核指令使用 C 指令（包含了 LLVM 的封装），前端使用的是 Python 和 LUA。BCC 有很多用途，例如性能分析和网络流量控制。BCC 还为其它程序提供了 API。
bpftrace：BPFtrace 是一个高级跟踪语言，用 LLVM 作为后端把脚本编译为 BPF 字节码，并用 BCC 和 Linux BPF 系统进行交互，并支持现有的 Linux 跟踪能力：kprobe、uprobe 以及 tracepoint。
Go、C/C++ 以及 Rust 的通用库。

结论

eBPF 还是个很新鲜的技术，让程序员在不修改内核空间的情况下，能够在内核中执行自定义的字节码并从内核函数中获取更多信息。原本这些目标需要通过系统调用或内核模块来完成，eBPF 降低了所需的复杂度和危险性。简单来说，eBPF 的工作流程：

把 eBPF 程序编译成字节码。
在载入到 Hook 之前，在虚拟机中对程序进行校验。
把程序附加到内核之中，被特定事件触发。
JIT 编译。
在程序被触发时，调用辅助函数处理数据。
在用户空间和内核空间之间使用键值对共享数据。

介绍一个不太小的工具：Shell Operator

Sat, 07 Nov 2020 11:29:44 +0800

Shell Operator 是个冷僻又有点用的东西。这个工具的角度比较刁钻——使用的特定事件来触发 Shell 脚本。

这个工具的使用方式也很有趣，要定义某个任务：

编写任务脚本
使用它的基础镜像，加入任务脚本，打包生成一个 Docker 镜像并推送
把镜像部署到集群之中
对应事件出现时，将执行该任务脚本。

触发方法

Shell Operator 支持多种事件触发，包括 Kubernetes、启动时执行以及定期执行。

定期执行方式可以使用类似 Crontab 的语法，定义特定时间内执行指定脚本。

启动时执行只会执行一次。

Kubernetes 事件触发条件和 Admission Webhook 类似，但是更加细致，支持多种对象的 Added、Modified、Deleted 操作。可以根据名称、标签、特定字段、命名空间进行过滤，还可以使用 jq 语法进行进一步的过滤。

写个脚本

项目 README.md 就提供了一个简单的例子，大致体现了 Shell Operator 的功能和用法。

首先生成一个脚本文件，并设置权限为可执行：

#!/usr/bin/env bash

if [[ $1 == "--config" ]] ; then
  cat <<EOF
configVersion: v1
kubernetes:
- apiVersion: v1
  kind: Pod
  executeHookOnEvent: ["Added"]
EOF
else
  podName=$(jq -r .[0].object.metadata.name $BINDING_CONTEXT_PATH)
  echo "Pod '${podName}' added"
fi

这个小脚本体现了 Hook 的基本用法，如果使用 --config 参数启动，则会输出一个 YAML 格式的配置文件，其中表明该脚本会在 Kubernetes 中加入新的 Pod 时候触发。

configVersion: v1
kubernetes:
- apiVersion: v1
  kind: Pod
  executeHookOnEvent: ["Added"]

在无参数启动时，则会运行这个 Hook 的主逻辑，在 Hook 被触发时，会把触发时的上下文内容以 JSON 的形式保存到一个文件，文件名会保存到 $BINDING_CONTEXT_PATH。这里会用 jq 从文件的 JSON 中获取 Pod 名称，并展示出来。

构建镜像并运行

项目提供了一个基础镜像 flant/shell-operator:latest，其中内置了 bash、kubectl、jq 以及 shell-operator 的可执行文件。把脚本加入镜像：

FROM flant/shell-operator:latest
ADD pods-hook.sh /hooks

构建镜像并推送到镜像库之后，为了让任务正常运行，要给它创建命名空间以及具备合适权限的 ServiceAccount：

$ kubectl create namespace example-monitor-pods
...
$ kubectl create serviceaccount monitor-pods-acc \
    --namespace example-monitor-pods
...
$ kubectl create clusterrole monitor-pods \
    --verb=get,watch,list --resource=pods
...
$ kubectl create clusterrolebinding monitor-pods \
    --clusterrole=monitor-pods \
    --serviceaccount=example-monitor-pods:monitor-pods-acc
...

monitor-pods-acc 具备了对 Pod 对象进行 get、watch 以及 list 操作的能力。我们用这个 ServiceAccount 以及前面生成的镜像，生成一个 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: shell-operator
  namespace: example-monitor-pods
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/port: '9115'
spec:
  containers:
  - name: shell-operator
    image: dustise/shell-operator:monitor-pods
    imagePullPolicy: Always
  serviceAccountName: monitor-pods-acc

触发 Hook

这个 Pod 启动之后，新建一个 Deployment，再看 Hook 的日志：

$ kubectl create deployment sleep  --image=dustise/sleep:v0.9.5
deployment.apps/sleep created
$ kubectl logs -f shell-operator  -n example-monitor-pods
...
{"binding":"kubernetes","event":"kubernetes","hook":"pods-hook.sh","level":"info","msg":"Pod 'sleep-84d5994d88-qnc7c' added","output":"stdout","queue":"main","task":"HookRun","time":"2020-11-07T15:46:21Z"}
...

监控信息

细心的读者会看到，前面的 Pod 包含了一个 Prometheus 的注解，如果打开 Prometheus 就会看到其中多出了一系列 shell_operator_hook 前缀的监控指标，例如：

shell_operator_tasks_queue_action_duration_seconds_bucket{queue_action="AddLast",queue_name="main",le="0"} 0
shell_operator_tasks_queue_action_duration_seconds_bucket{queue_action="AddLast",queue_name="main",le="1e-06"} 0
shell_operator_tasks_queue_action_duration_seconds_bucket{queue_action="AddLast",queue_name="main",le="2e-06"} 0

并且，Shell Operator 还支持加入自定义的监控指标，只要将指标写入文件，并把文件名保存到 $METRICS_PATH 环境变量之中就可以。

用途

这东西非常适合急救——在一些特殊场合，根据特定条件，对指定对象进行一些操作，例如注解、标签、清除、重启等。

做个 openEuler 的系统镜像

Thu, 05 Nov 2020 14:26:49 +0800

前几天突然想知道，操作系统镜像是怎么搞的。放狗搜了一下，发现官网提供了一些这方面的介绍，看来很轻松，结合以前翻译的镜像是怎样炼成的，一时手痒，就想用菊厂操作系统新秀 openEuler 练练手——恩是 openEuler 不是那啥。

根据 Docker 官网介绍，几个流行操作系统都有自己的构建脚本，主要流程就是几个步骤：

安装操作系统
安装工具依赖项目
运行脚本构建镜像
获取镜像

openEuler 安装之后，可以看到是个 Yum 系的系统，所以可以参考一下 CentOS 的脚本，粗看上来，依赖并不复杂，yum、docker 以及 tar。撸起袖子开工就是了。

安装

在 openEuler 官网下载 ISO 文件：https://openeuler.org/en/download/。这里我选择了 LTS 的最小化版本。使用 Parallels Desktop 安装虚拟机，安装之后对几个依赖进行验证。

首先发现这个系统可能因为某些原因并没有内置 Repo 源，个人用户自然无需担心这个问题，在 /etc/yum.repos.d 中加入软件源：

[openeuler]
name=openEuler
baseurl=https://repo.openeuler.org/openEuler-20.03-LTS/OS/x86_64/
enabled=1
gpgcheck=0

Docker 的安装也可以使用 CentOS 的源：

[docker]
name=Docker CE Stable - $basearch
baseurl=https://download.docker.com/linux/centos/7/$basearch/stable
enabled=1
gpgcheck=0

[extra]
name=Extra
baseurl=http://mirror.centos.org/centos/7/extras/x86_64
enabled=1
gpgcheck=0

其中的 Extra 库来自 CentOS，用于满足一些 Docker 的安装依赖。

yum install docker-ce docker-ce-cli containerd.io --nobest 安装 Docker，之后就可以运行部署脚本了：

$ ./mkimage-yum.sh
...

不过虚拟机下运行成功并不是这么容易的，这个脚本的运行会在 /tmp 中运行，大概需要 900MB 的磁盘空间，和 40k 左右的 inode。建议运行之前使用 df -h -i 查看一下 /tmp 的可用情况。openEuler 的缺省 /tmp 较小，可以使用 mount -o remount,size=15G /tmp/ 调整。

如果一切正常的话，会看到在大量的错误信息之后，看到一行输出：success。这是脚本在生成镜像 TAR 文件，使用 Docker 加载并运行之后输出的。可以查看一下这个镜像：

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
openeuler           20.03               fe7ddc25c484        5 hours ago         1.57GB

$ docker run -it openeuler:20.03 bash

Welcome to 4.19.90-2003.4.0.0036.oe1.x86_64

System information as of time:  Thu Nov  5 08:56:29 UTC 2020

System load:    0.02
Processes:      5
Memory used:    7.3%
Swap used:      0.9%
Usage On:       9%
IP address:     172.17.0.2
Users online:   0

另外，如果仔细点看上面提供的 YUM Repoistory，会发现一个神奇的文件夹，其中包含了 x86 和 aarch64 两个架构的原厂镜像_所以本文仅供学习交流，不建议用于商业用途，请于 24 小时内忘掉。

节省镜像库空间的一个思路

Sun, 01 Nov 2020 19:33:05 +0800

最近遇到一个有趣的状况，某镜像仓库占用了大量的磁盘空间。通常要解决这种问题，给 Registry 发删除指令，并进行 GC 就可以了。然而很多时候，所有镜像都正常，在删除多个 Tag 甚至是 Repository 之后，问题仍然没能缓解，原理也很容易理解——删除的镜像虽然大，可能只是复用了一些比较大的层，删除镜像并不会真正的发出，所以还是需要对镜像库的存储进行更多的了解，进行进一步的统计，在层一级对镜像仓库进行分析，才能获取更有效的途径。

Docker Registry Exporter

首先发现了一个有意思的项目：DockerRegistryExporter，这个项目是一个 Python 编写的 Prometheus Exporter，其中包含四个 Gauge：

-repository_tags_total：按镜像计算的 Tag 数量。 -repository_revisions_total：按镜像计算的版本数量。 -repository_tag_layers_total：以镜像和 Tag 计算的 Layer 数量。 -repository_tag_size_bytes：以镜像和 Tag 计算的文件尺寸。

该镜像使用挂卷的方式，直接对镜像库文件系统进行扫描，例如：

containers:
- image: registry:2
  name: registry
  ports:
  - containerPort: 5000
    name: http
    protocol: TCP
  readinessProbe:
    httpGet:
      path: /
      port: 5000
    initialDelaySeconds: 1
    timeoutSeconds: 1
  livenessProbe:
    httpGet:
      path: /
      port: 5000
    initialDelaySeconds: 1
    timeoutSeconds: 1
  volumeMounts:
  - name: storage
    mountPath: /var/lib/registry

- image: skyuk/docker-registry-exporter:v1.0.0
  name: registry-exporter
  args:
    - /var/lib/registry/docker/registry/v2
  ports:
  - containerPort: 8080
    name: http
    protocol: TCP
  volumeMounts:
  - name: storage
    mountPath: /var/lib/registry

volumes:
- name: storage
  persistentVolumeClaim:
    claimName: registry

通过Sidecar的部署方式和Registry容器共享文件系统，可以定时输出监控指标，例如：

$ curl http://registry:8080
# HELP repository_tag_size_bytes Size of eachtag
# TYPE repository_tag_size_bytes gauge
repository_tag_size_bytes{repository="org/image1", tag="0.3.0"} 162749959.0
repository_tag_size_bytes{repository="org/image2", tag="1009140546"} 226608092.0
...

然而这并不能满足我的要求，关于引用的数据并没有体现，另外前面也提到，我们需要比较精确地获得镜像版本、Tag 和 Layer 之间的引用关系以及各自的尺寸，用 PromQL 有点别扭。

我做了个奇怪的事情

这并不是一个很常见的需求，只能是一个清理之前的准备动作，目前看来我需要找到的就是引用数量少、但是体量比较大的 Layer，但是谁知道以后会需要什么新的标准呢？干脆把这些东西写入到数据库里算了，把这些东西写入数据库之后，还掌握 SQL 这样传统才艺的程序员就可以随便搞一搞其它条件了。

关于镜像仓库的一点基础

镜像库根目录中有两个子目录：blobs 中保存了所有的 Layer，而 repositories 中则是以镜像为单位保存的元数据。

首先看看镜像的数据

$ tree/org/repo/gameserver
.
├── revisions
│   └── sha256
│       └── ecfb0206e8b...
│           └── link
└── tags
    └── latest
        ├── current
        │   └── link
        └── index
            └── sha256
                └── ecfb020...
                    └── link

每个镜像的 Manifests 有两个目录，分别承载的是版本和 Tag，正常来说 Tag 和版本是一致的，但实际上在一些特别情况下，这两个数量可能是不一致的，就会导致只用 Tag 已经无法拉取该镜像，属于一种半孤立状态，应该说是需要清除的。

两个目录中的link文件中包含的是一个哈希码，可以使用这个哈希码在_layers中查找到该镜像的版本/tag 对应的清单层，使用这个字符串可以在根_layer中查到对应的目录，目录下面的data文件中就是每个层的具体数据，对于清单层，其中会是一个json字符串：

{
    "schemaVersion": 2,
    "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
    "config": {
        "mediaType": "application/vnd.docker.container.image.v1+json",
        "size": 2694,
        "digest": "sha256:7929bcd70e47d3726d55a870b2ca11c25792758f3ba8b4ff136811f0809af636"
    },
    "layers": [
        {
            "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
            "size": 2546278,
            "digest": "sha256:3db1cceb1cccb362634e914bfe76d329c64d148262a9e139a046337d82e1aeec"
        },
        {
            "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
            "size": 32,
            "digest": "sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1"
        }
    ]
}

这里看到清单中包含两个主节点，config 和 layer，至此，一个镜像是由三种不同的层构成的：清单、Config 和 Layer。我们关注的主要是 Layer，其中的 data 文件包含的就是各层的具体内容，清单和 Config 中都是文本，Layer 通常都是二进制的，也是我们要关注的主要内容。

接下来的问题就顺理成章了，把 Repository、Tag、Revision 以及 Layer 的关系建立起来，随便用个 SQL 语句，就能够按照具体需求对“引用少、尺寸大”的 Layer 进行过滤了。

用 Notary 和 OPA 在 Kubernetes 上使用内容签名

Sat, 17 Oct 2020 01:18:58 +0800

原文：Ensure Content Trust on Kubernetes using Notary and Open Policy Agent

作者：Daniel Geiger Maximilian Siegert

在 Kubernetes 上使用策略对部署行为进行限制，仅允许运行有签名的镜像。

我们希望借助本文，让读者了解到如何在 Kubernetes 中使用可信镜像，其中依赖两个著名的 CNCF 开源项目：Notary 和 OPA。主要思路是使用 OPA 策略来定义自己的内容限制策略。

主要内容如下：

完成示例的先决条件
Notary 和镜像信任的基本概念
在 Kubernetes 上安装 Kubernetes
OPA 和 Admission Control 的基本概念
在 Kubernetes 上安装 OPA
定义 Validating Admission Control 控制内容信任
定义 Mutating Admission Control 完成自动化
总结和展望

如果读者已经熟知 Notary 或者 OPA 的相关内容，可以跳过上述的两节基本概念部分。

完成示例的先决条件

如果要遵循后续的安装步骤，需要下列准备：

如果是 Kubernetes 集群，至少启用了 MutatingAdmissionWebhook 和ValidatingAdmissionWebhook；如果是 Minikube，应该使用如下启动方式：
```
$ minikube start \
--extra-config=apiserver.enable-admission-plugins=MutatingAdmissionWebhook,ValidatingAdmissionWebhook
```
私有镜像库，或者一个 Docker Hub ID，用于推送签名镜像。
从我们的 Github 仓库获取用于安装 OPA、Notary 以及 Notary-Wrapper 的 Helm Chart。

Notary 和镜像信任的基本概念

将代码、可执行文件或者脚本进行签名，保障仅有受信内容才可运行，这是一个已知的最佳实践。软件签名不是什么新概念，有很多相关的供应商和方案，每个组织都有自己的方式来处理制品的签署和信任。然而如果把目光投向容器领域，可能会发现并没有那么多选择。

Notary 是什么

你可能已经听说过 Notary，这是一个基于 TUF 项目的用于软件制品签名的开源软件。

Notary 如何运作

首先说说 Notary 的核心概念。Notary 使用角色和元数据文件对受信集合内容进行签署，这些内容被称为全局唯一名称（GUN——Global Unique Name）。

以 Docker 镜像为例，GUN 相当于 [registry]/[repository name]:[tag]。

[registry] 是镜像的源仓库，[repository name] 是镜像的名称。[tag] 对镜像进行标记（通常代表版本）。

Notary 借助 TUF 的角色和密钥层级关系对镜像进行签名。有五种密钥类型用于对元数据文件进行签署，并用 .json 的方式保存到 Notary 数据库。下图描述了密钥层级以及这些密钥的典型存储位置。

根密钥：每个 GUN 都有自己的根角色和密钥。根密钥是所有信任关系的基础，用于对根级元数据文件（其中包含根 ID、目标、快照以及时间戳公钥的 ID）进行签名。通常这个密钥是由（GUN）的属主管理的，并使用离线的方式进行保存（例如在本地目录或者硬件密钥设备）。
目标密钥：目标密钥负责签署目标元数据文件，其中包含该集合中的所有文件名、尺寸以及对应的哈希值。这个元数据文件用于对该仓库中的所有实际内容进行完整性验证。这还表示目标元数据文件包含了每个镜像标签的入口。目标密钥可以使用委托角色把信任关系委托给其它的合作者。目标密钥也是属于 GUN 属主的，同样用离线方式保存。
委托密钥：如上文所说，目标密钥能够委托给其它角色。这些角色会有自己的密钥来签署被委托的元数据文件，其中同样会包含该集合中的文件名、尺寸以及对应的哈希。委托元数据文件能用于校验仓库中部分或者全部内容的完整性。这些密钥属于这个集合的协作者。
快照密钥：快照密钥负责签署快照元数据文件，其中遍历了每个 GUN 的根、目标和委托元数据。这个元数据文件的目标就是验证其它元数据文件的完整性。快照密钥属于协作属主（本地），或者如果 Notary 服务（通过委托角色使用多个协作者）。
时间戳密钥：时间戳密钥用于签署时间戳元数据文件，这个密钥的存在目的是保障集合的时效性。这其中包含了元数据的最短过期时间、最近快照的文件名、尺寸以及哈希。这个元数据文件用来检验快照文件的完整性。时间戳密钥由 Notary 服务保存，这样这个密钥就能自动的根据服务器的请求自动重新生成。

管理密钥的 Notary 服务架构包括两个组件：

Notary 服务器，用来保存和更新信任 GUN 的签署后元数据文件。
Notary Signer 保存了私钥，用于为 Notary Server 提供元数据签署能力。

Docker 文档中这张 Notary 的示意图很好的概括了客户端与 Notary Server 以及 Signer 之间的通信。下图是一个简化版本：

Notary 服务器可以使用 JWT Token 进行认证。如果没有使用这个功能，可以简单地上传新的元数据文件。如果客户端上传了新的元数据文件，Notary Server 会对老版本进行冲突检测，并对签名、校验和以及元数据的有效性进行检测。
上传的元数据通过验证以后，Notary 服务器会生成时间戳元数据，并将元数据发给 Signer 进行签名。
Notary Signer 从数据库中获取加密的密钥，解密后对元数据进行签署。如果签署成功，则将签名发回给 Notary 服务器。
Notary Server 是所有受信集合（GUN）真实状态的来源，TUF 数据库中存储了客户端上传和服务器生成的元数据。生成的时间戳和快照元数据证明客户端上传的元数据是该可信集合的最新数据。Notary 服务器会通知客户其上传成功。
客户端能够从服务器下载最新的元数据。Notary 服务器从数据库中取出元数据即可。

如果时间戳过期，Notary 服务器会重新完成流程，生成新的时间戳，申请 Signer 签名，并在数据库中保存新签署的时间戳。然后发送新的时间戳以及用户请求的其它元数据。

Notary 签署过程看起来很复杂，不过一个好消息就是，Docker 客户端中集成了用 Notary 签署镜像的能力。可以轻松地使用环境变量在本地设备上启用镜像信任机制：

DOCKER_CONTENT_TRUST=1：在客户端启用 Notary
DOCKER_CONTENT_TRUST_SERVER=”<url-to-your-Notary-server>”：使用自己的 Notary 服务提供信任关系

设置这些之后，Docker 客户端就会在拉取之前检查签名，并在推送之前请求签署凭据来对镜像进行签名。Docker HUB 还提供了自己的缺省 Notary 服务 https://notary.docker.io，如果启用了内容信任，会用它对推送镜像进行签署。

如果拉取镜像是有签名的，可以简单的使用 docker trust inspect <GUN> 来检查签名情况：

$ docker trust inspect nginx:latest
[
    {
        "Name": "nginx:latest",
        "SignedTags": [
            {
                "SignedTag": "latest",
                "Digest": "b2xxxxxxxxxxxxx4a0395f18b9f7999b768f2",
                "Signers": [
                    "Repo Admin"
                ]
            }
        ],
        "Signers": [],
        "AdministrativeKeys": [
            {
                "Name": "Root",
                "Keys": [
                    {
                        "ID": "d2fxxxxxxx042989d4655a176e8aad40d"
                    }
                ]
            },
            ...
        ]
    }
]

除了使用 docker trust 之外，也可以下载 Notary 客户端，直接和服务器进行通信。

在 Kubernetes 上安装 Notary

到现在我们已经对 Notary 的工作机制有了个初步的认识。我们可以更进一步，在 Kubernetes 上安装自己的 Notary 服务。我们准备了两个 Shell 脚本和 Helm Chart，这样就可以很方便的进行安装了。开始之前请克隆我们的代码仓库：

$ git clone https://github.com/k8s-gadgets/k8s-content-trust
...

安装

进入 notary-k8s 目录。

可选项目：构建 Notary 并加入自己的镜像库。要从头构建最新的 Notary 镜像，需要从 build 目录开始。如果要构建和推送 Notary 镜像到你自己的镜像仓库，可以编辑 build.sh 文件，编辑 REGISTRY 变量，使之匹配自己的镜像库，并执行 build.sh 脚本。

$ bash build.sh
...

接下来需要进入 helm/notary 目录，并生成 TLS 证书，来确保和 Notary 服务通信的安全性：

$ cd helm/notary
...
$ bash generateCerts.sh
...

在准备好 Docker 镜像并把 TLS 证书写入 Chart 之后，就可以使用 Helm 在 Kubernetes 上进行部署了。另外也可以看看 values.yaml 文件，修改一些必要的参数，例如缺省密码（passwordalias1Name、 passwordalias1Value）或者私有仓库。

然后就是创建命名空间并安装 Helm Chart：

$ kubectl create namespace notary
# 切换到 notary 命名空间
$ helm install notary notary

检查镜像是否已经启动运行：

$ kubectl get pods –n notary
...

如果 Pod 已经运行，就表明 Notary 安装成功了。然而在我们试用 Notary 服务之前，我们应该提交最后生成的 Notary Wrapper 模板。

Notary Wrapper 是我们写的一个扩展，借助这个扩展，OPA 就能就能和 Notary 服务进行交互了。这是一个 CLI REST 界面，仅实现了获取已签名镜像哈希以及在服务上检查新人数据的功能。

从 notary-k8s/helm/certs 复制证书文件到 helm/notary-wrapper/certs：

notary-wrapper.crt
notary-wrapper.key
root-ca.crt

进入源码的 notary-wrapper 子目录。创建 OPA 命名空间并执行 Helm 安装过程。

$ kubectl create namespace opa
# switch to namespace opa
helm install notary-wrapper notary-wrapper

测试 Notary

组件安装结束之后，就可以开始用我们的信任数据来测试 Notary 了，下图展示了这个过程：

我们需要签署一些本地镜像作为测试素材，所以首先从 Docker Hub 拉取一些镜像：

如果你已经启用了 DOCKER_CONTENT_TRUST，并且没有指定 DOCKER_CONTENT_TRUST_SERVER，或者指定到了你的新服务器，拉取过程可能会失败。

docker pull nginx:latest
docker pull busybox:latest

下一步就要连接我们的 Notary 客户端和服务器了：

把 Notary 服务器加入 /etc/hosts：127.0.0.1 notary-server-svc
在终端中打开第二个 Tab，并为 Notary Server 的 Pod 创建一个端口转发，以便本地使用：kubectl port-forward notary-server-<...> 4443:4443

第一次要签名之前，要把你的 root-ca.crt 从安装目录拷贝到你的 .docker/tls 目录：

mkdir -p $HOME/.docker/tls/notary-server-svc:4443
cp <...>/helm/notary/certs/root-ca.crt $HOME/.docker/tls/notary-server-svc:4443/

回到第一个终端 Tab，启用内容信任机制：

export DOCKER_CONTENT_TRUST_SERVER=https://notary-server-svc:4443
export DOCKER_CONTENT_TRUST=1

Notary 已经启动，应该已经无法拉取任何没有被你的 Notary 服务签名的镜像了。不过可以打标签、签名和推送镜像（在我们的例子中，我们会简单的推送到我们自己的 Docker Hub 空间，使用的是我们自己的镜像签名）：

docker tag nginx:latest docker.io/<hub-id>/nginx:1 
docker push docker.io/<hub-id>/nginx:1
docker tag busybox:latest docker.io/<hub-id>busybox:1
docker push docker.io/<hub-id>/busybox:1

这个推送命令会提示生成密码，用于请求签名密钥。这些步骤完成后，镜像会被推送到 Docker Hub，信任数据则会保存到 Notary Server。要进行校验，可以使用前面提到的 docker trust inspect 命令，如果安装了 Notary 客户端，也可以用 notary list 命令。命令执行结果类似：

$ notary -s https://notary-server-svc:4443 --tlscacert $HOME/.docker/tls/notary-server-svc:4443/root-ca.crt list docker.io/<hub-id>/nginx
# output
NAME    DIGEST                                SIZE (BYTES)  ROLE
----    ------                                ------------  ----
1       cccef6d6bdea671c394954b0dxxxxxxxx     948           targets

如果必须重新部署 Notary，并使用新的密钥进行镜像签署，必须删除之前存储在 .docker/tls 目录中保存的密钥。另外还需要删除 .docker/trust/tuf 中现存的需要重新签署的镜像的信任数据。

现在可以开始测试 Notary Wrapper。再新开一个终端 Tab，在 /etc/hosts 文件中加入该服务的地址：127.0.0.1 notary-wrapper-svc。

保存之后，对端口 4445 进行端口转发：

# switch to namespace opa
kubectl port-forward notary-wrapper-<...> 4445:4445

完成后就可以使用两个操作来检查 GUN、Tag 后者哈希的信任数据了，因为我们用的是 TLS 连接，要信任前面生成的根证书：

把 GUN 和 Tag 数据提交给 https://notary-wrapper-svc:4445/list，获取最新的镜像信任数据，例如：

$ curl -X POST https://notary-wrapper-svc:4445/list -H “Content-Type: application/json” -d ‘{“GUN”:”docker.io/<hub-id>/nginx”, “Tag”:”1", “notaryServer”:”notary-server-svc.notary.svc:4443”}’ --cacert PATH/TO/YOUR/NOTARY/certs/root-ca.crt
# output - One item
{
    "Name":"1",
    "Digest":"cccef6d6bdexxxxxx422",
    "Size":"948",
    "Role":"targets"
}

把 GUN 和哈希码发送到 https://notary-wrapper-svc:4445/verify 验证这个哈希对应的信任数据是否存在（返回码 200 或 404）。如果不知道哈希吗，可以使用 docker inspect GUN:Tag 命令查看。

$ curl -X POST https://notary-wrapper-svc:4445/verify -H “Content-Type: application/json” -d ‘{“GUN”:”docker.io/<hub-id>/nginx”, “SHA”:”<your-RepoDigest>”, “notaryServer”:”notary-server-svc.notary.svc:4443”}’ --cacert PATH/TO/YOUR/NOTARY/certs/root-ca.crt
...

后面会使用 Notary Wrapper 来实现内容信任。完成这个测试之后，就可以关闭端口转发，继续下面的内容了。

在 Kubernetes 上实施内容信任

现在我们已经可以签署镜像生成信任数据了，拼图还差最后一块——在 Kubernetes 上实施内容信任策略。这临门一脚的难处在于，Kubernetes 中并没有提供什么开关可以激活内容信任。

又一个可能的方案就是依赖底层的 Docker 引擎，调用镜像验证插件，启用 DOCKER_CONTENT_TRUST（可以参考这个 Issue），这种方法有两个弊端：

集群节点需要依赖 Docker 引擎完成信任工作。
DOCKER_CONTENT_TRUST 是个非此即彼的开关，打开之后，无法拉取没有在 Notary 上签名的镜像。
DOCKER_CONTENT_TRUST 只能检查一个镜像是否存在签名元数据，但是并不负责检查该签名是否属于这个 Tag。

为了克服几个弊端，我们把注意力放在了 Kubernetes Admission Control 上。

OPA 和 Admission Control 的基本概念

长话短说。Kubernetes Admission Controller 是一种插件机制，可以用来对集群上的资源进行校验和配置。它的作用包含在 Kubernetes API 请求的生命周期之中，除了内置的 30 个控制器（例如 PodSecurity Policy）之外，还会有使用自己的控制规则的需要。就可以创建自己的 Validating 或者 Mutating Webhook 了。

Mutating：这种 Webhook 会对请求对象进行变更，来满足特定的配置需求。
Validating：它可以对请求对象进行验证，拒绝验证失败的请求。

Admission Control 触发的顺序是非常重要的知识点：

Kubernetes 会首先执行 Mutating 过程，然后才是进行验证。这样就能确保被变更过的请求对象能够正确地被校验。OPA 就是最好的实现 Mutaiting 和 Validating Webhook 的方法之一。

什么是 OPA

OPA 是一个通用的策略引擎，它使用一种高级的声明式语言（Rego）编写策略。下图展示了 OPA 集成到 Kubernetes API 生命周期的形式：

在 Kubernetes 上安装 OPA

我们希望在 Kubernetes 上借助 OPA/Rego 的弹性策略实现内容信任机制。然而在开始之前，首先要在集群上部署 OPA。

假设你已经有了符合条件的集群，在完成命名空间创建和 Notary 步骤之后，就可以开始进入仓库中的 OPA 目录开始安装了。

Kubernetes 和 OPA 之间的通信必须是 TLS 加密的，因此需要给 OPA 创建额外的证书和密钥。

# copy the root-ca
cp ~/PATH/TO/k8-content-trust/notary-k8s/helm/notary/certs/root-ca.crt ~/PATH/TO/k8-content-trust/open-policy-agent/helm/opa/certs
# generate the additional OPA certs 
cd helm/opa
bash generateCerts.sh

OPA 在安装后是自动生效的，因此应该排除一些命名空间：

kubectl label ns kube-system openpolicyagent.org/webhook=ignore
kubectl label ns opa openpolicyagent.org/webhook=ignore
kubectl label ns notary openpolicyagent.org/webhook=ignore

接下来我们要确认一下 values.yaml 中的 validating 和 mutating 是否已经配置（晚些时候我们会设置 mutating: true）：

# open-policy-agent/helm/opa/values.yml
...
validating: true
mutating: false
...

# switch to namespace opa
helm upgrade --install opa opa

在安装结束之后，可以在终端打开一个新 Tab，会看到 OPA 日志中 API Server 的进入请求。

# ctrl-c to exit
kubectl logs -n opa -f opa-deploy-<...> opa

定义 Validating Admission Control 控制内容信任

总算到了有意思的部分了，开始实现内容信任机制。Notary 和 OPA 都已整装待发，首先我们想拒绝一切不受信任的镜像。要完成这个任务，要先搞清楚 Docker Tag 和哈希之间的关系。

一般来说，我们会使用 GUN 以及标签来部署镜像。然而多数人会忽略一个事实，镜像标签是可以覆盖的，因此它的唯一性是靠不住的。一个集合的所有者能够用同样的 Tag 多次推送变更了的已签署镜像。为了避免这种情况，应该使用唯一摘要进行镜像拉取。

我们定义两条 Rego 规则来完成这个 Webhook：

拒绝只使用普通 Tag (包括 latest)的部署。
拒绝使用了哈希但是没有被 Notary 签名的镜像。

已经随 Helm 安装好。

先看看第一条规则（helm/opa/policy/validating/rules.rego）

package policy.validating

operations := {"CREATE", "UPDATE"}

kind := {"Pod", "Deployment"}

# rule to deny digests for pods and deployments
deny[msg] {
  operations[input.request.operation]
  kind[input.request.kind.kind]
  image = get_images[_]
  not contains(image.name, "@sha256:")
  msg := sprintf("%v contains tag; only images with checksum are allowed", [image.name])
}

# rule deny if digest is not in notary
deny[msg] {
  operations[input.request.operation]
  kind[input.request.kind.kind]
  image = get_images[_]
  contains(image.name, "@sha256:")

  # Example to mock digest comparison
  # parts := split_image(image.name)
  # not parts.digest == "@sha256:50"

  get_checksum_status(image.name) != 200
  msg := sprintf("No trust data found for the following image: %v ", [image.name])
}

# helper rules
# get images if pod
get_images[x] {
  input.request.kind.kind == "Pod"
  name := input.request.object.spec.containers[i].image
  x := {
    "index": i,
    "name": name,
  }
}

## get images if deployment
get_images[x] {
  input.request.kind.kind == "Deployment"
  name := input.request.object.spec.template.spec.containers[i].image
  x := {
    "index": i,
    "name": name,
  }
}

# rule to split gun and tag
split_image(image) = x {
  parts := split(image, "@sha256:")
  x := {
    "gun": parts[0],
    "digest": parts[1],
  }
}

# rule to get digest from notary-wrapper
get_checksum_status(image) = status {
  wrapperRootCa := "/etc/certs/notary/root-ca.crt"
  notaryWrapperURL = "https://notary-wrapper-svc.opa.svc:4445/verify"
  parts := split_image(image)
  body := {
    "GUN": parts.gun,
    "SHA": parts.digest,
    "notaryServer": "notary-server-svc.notary.svc:4443",
  }

  headers_json := {"Content-Type": "application/json"}
  output := http.send({"method": "post", "url": notaryWrapperURL, "headers": headers_json, "body": body, "tls_ca_cert_file": wrapperRootCa})
  status := output.status_code
}

上面的规则会检查尝试创建或更新 Pod 或者 Deployment 类型的 API 请求。

根据资源类型，get_image[x] 规则会确保遍历请求中的所有容器，检查这些容器是否用摘要（例如 [GUN]@sha256:[digest hash]）进行拉取。

因此简单的检查一下，镜像是否用了 @sha256 就可以了。否则我们会认为此次尝试部署的是一个用 Tag 标识的镜像。如果这一规则被触发，请求就会被阻拦，并得到返回的错误消息。

接下来我们继续定义第二个规则，拒绝没有被 Notary 信任的摘要。

在这个规则里，我们在 get_checksum_status(image) 中用了 OPA 中集成的 http.send 函数。首先会从请求中获取每个镜像的哈希，然后在 get_checksum_status(image) 中发送镜像的 GUN 和摘要到 Notary Wrapper，Notary Wrapper 会检查每个镜像是否都已签名。如果请求返回的不是 200，那么部署动作会被制止。

简单说 http.send 函数在目标不可用时不会返回响应（可以参考 OPA 的一个功能申请）。在我们这里因为有了 Notary Wrapper，只要它正常工作，就不会遇到这个困扰。然而一旦 Notary Wrapper 不可用，OPA 也会故障，会被 ValidatingWebhookConfiguration 中的 failurePolicy: Fail 定义所捕获。

上面描述的两条规则就足以在 Kubernetes 集群中完成对内容信任的控制了。

要进行测试，只需要简单的部署一个新的 Pod：

# trust-pinning-test
apiVersion: v1
kind: Pod
metadata:
  name: trust-pinning-test
  namespace: default
spec:
  containers:
  # trigger rule 1:
  - image: GUN/<hub-id>/nginx:1
  # trigger rule 2:
  # - image: GUN/<hub-id>/nginx@sha256:89cce606b29fb2xxxxx
  # valid deployment:
  # - image: GUN/<hub-id>/nginx@sha256:<your-signed-RepoDigest>

另外在 open-policy-agent/tests 中还包含了多个针对不同需求的过个测试。

接下来的示意图展示了我们目前的工作成果：

每次部署都会发出 API 请求，随即开始校验过程：

请求触发了校验 Webhook，发起对 OPA 的调用。
OPA 会检查镜像的拉取方式，如果使用的是摘要方式，就会向 Notary Wrapper 请求信任数据。Notary Wrapper 则会从 Notary 服务器查询数据，并返回给 OPA，OPA 据此进行决策。如果没有触发规则，Kubernetes 会继续部署。
根据哈希从镜像库拉取（本例中是 DockerHub）。
部署 Pod。

到此为止，我们已经成功的实现了内容信任机制。然而查询 RepoDigests 是个很麻烦的事情。如果能基于 Tag 使用内容信任就两全其美了。

定义 Mutating Admission Control 完成自动化

Mutating Webhook 是用于在校验之前对请求内容进行变更的，我们接下来会编写这样一个功能。每次用户尝试部署一个带标签的镜像时，就启动 Webhook，自动将镜像引用改为哈希模式。大致工作流程如下：

API 请求流经 Webhook：

如果请求中包含 Pod，操作类型是创建或者更新，并且镜像是用 Tag 标识的，就会触发 OPA 的 Mutating Webhook（在所有的验证之前）。
OPA 会用 Tag 去检查镜像，接下来 OPA 会为每个标签发起新的 http.send 请求到 Notary Wrapper，向 Notary 服务器发起查询。
如果 Notary Wrapper 在 Notary 服务器上找到了对应这个标签的条目，就会返回最新的 RepoDigest 给 OPA，否则报错。
OPA 对 Deployment 进行修改，把镜像标签更换为哈希，并把变更后的请求内容发送给 API Server。
API Server 继续完成创建或更新流程，校验 Webhook 会对请求进行检查，如果请求有效，就用 RepoDigest 从可信的仓库拉取镜像，并完成部署。

因为我们已经在安装过程中给 OPA 注册了 Mutating Webhook，我们只需要加入新的 Rego 规则就可以了。最简单的方式就是回到本地的 Helm 目录，启用 mutating，然后执行 helm upgrade：

# open-policy-agent/helm/opa/values.yml
...
validating: true
mutating: true

# switch to namespace opa
helm upgrade --install opa opa

OPA 中的 Mutating Webhook 是 main 方法的一部分，这个方法会在 API 请求时发起变更。helm upgrade 会加入下面的新规则：

package policy.mutating

import data.k8s.matches

main = {
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": response,
}

default uid = "missing-uid"

uid = input.request.uid

# default allow without patch
response = r {
  count(patch) == 0
  r := {
    "uid": uid,
    "allowed": true,
  }
}

# response with patch
response = {
  "uid": input.request.uid,
  "allowed": true,
  "patchType": "JSONPatch",
  "patch": patch_bytes,
} {
  count(patch) > 0
  patch_json = json.marshal(patch)
  patch_bytes = base64url.encode(patch_json)
}

# patch
default patch = []

patch = result {
  operations := {"CREATE", "UPDATE"}
  kind := {"Pod", "Deployment"}
  
  
  operations[input.request.operation]
  kind[input.request.kind.kind]

  # construct patch for each image in the container array that requires it.
  result := [p |
    image = get_images[_]
    not contains(image.name, "@sha256:")

    parts := split_image(image.name)

    # format: registry/project@sha256:xxx
    patchedImage := concat("", [parts.gun, "@sha256:", get_digest(image.name)])

    # cconstruct JSON Patch for the deployment.
    # kube-apiserver expects changes to be represented as
    # JSON Patch operation against the resource.
    # the JSON Patch must be JSON serialized and base64 encoded.
    p := {
      "op": "replace",
      "path": get_path(image.index),
      "value": patchedImage,
    }
  ]
}

# helper rules

# rule to compute images set
# the first line ensures that its matched to the right k8s resource
# the second line iterates over each container and extracts the image
get_images[x] {
  input.request.kind.kind == "Pod"
  name := input.request.object.spec.containers[i].image
  x := {
    "index": i,
    "name": name,
  }
}

get_images[x] {
  input.request.kind.kind == "Deployment"
  name := input.request.object.spec.template.spec.containers[i].image
  x := {
    "index": i,
    "name": name,
  }
}

# construct and returns json path for "Pods"
get_path(index) = path {
  input.request.kind.kind == "Pod"
  path := concat("/", ["", "spec", "containers", format_int(index, 10), "image"])
}

# construct and returns json path for "Deployment"
get_path(index) = path {
  input.request.kind.kind == "Deployment"
  path := concat("/", ["", "spec", "template", "spec", "containers", format_int(index, 10), "image"])
}

split_image(image) = x {
  parts := split(image, ":")
  x := {
    "gun": parts[0],
    "tag": parts[1],
  }
}

# helper rule to retrieve the digest from notary using notary-wrapper
get_digest(image) = digest {
  wrapperRootCa := "/etc/certs/notary/root-ca.crt"
  notaryWrapperURL = "https://notary-wrapper-svc.opa.svc:4445/list"
  parts := split_image(image)
  body := {
    "GUN": parts.gun,
    "Tag": parts.tag,
    "notaryServer": "notary-server-svc.notary.svc:4443"
  }

  headers_json := {"Content-Type": "application/json"}
  output := http.send({"method": "post", "url": notaryWrapperURL, "headers": headers_json, "body": body, "tls_ca_cert_file": wrapperRootCa})
  digest := output.body.Digest
}

简单说一下这段代码的功能：

OPA 会使用 response 规则中的代码加入需要的响应。
第一个 response 针对的是无需变更的请求，允许任意的 API 请求通过。
第二个 response 会调用 patch 规则。
patch 规则会对任何面向 Pod 或者 Deployment 的 API 请求进行变更。结果参数首先会获取 API 请求中的镜像，检查是否每个镜像都是使用哈希进行拉取的（URL 中包含了 @shar256:）。
如果不满足上一个条件，就会使用 split_image 规则将镜像分为名称和标签两部分。
split_image 返回的是一个数组，get_digest 中使用这个数组调用 http.send 函数通过 Notary Wrapper 向 Notary 请求哈希。如果 Notary 没有对应的哈希，会得到 404 的返回值。
Kubernetes 中使用 .json 格式的补丁。.json 补丁（赋值给 p）需要在 path 参数中指定的路径上执行 replace 操作，从而替换原有的拉取方式。在 Pod 和 Deployment 中，镜像字段的路径是不同的，我们需要创建两个 get_digest 和 get_path 来应对两种情况。
OPA 会对补丁进行编码，并返回变更后的 API 请求给 API Server，继续后续操作。

如果想要测试这个 Webhook，可以看看 open-policy-agent/tests，如果保存了前面的校验 Webhook，可以测试一下有效和无效的 Tag 或者哈希。下表总结了 Webhook 的响应情况：

总结和展望

最终，我们成功地在 Kubernetes 集群上，无需改动部署习惯的情况下，实现了内容信任机制，除了这个，OPA 还能做很多其它的校验工作。

我们知道这篇文章很长，但是我希望尽可能多地为读者提供更多细节。我们认为，虽然有很多的容器扫描和加固方面的技术，镜像签署和信任是目前容器安全方面的最大盲区之一。

下一步需要做点什么呢？还有很多细节我们没能说明：

性能：校验和变更过程的性能测试。
生产就绪：提供高可用的 Notary 部署，并把客户端（包括 Docker 客户端）做到硬件安全模块。
CI-CD 集成：在 CI/CD 中自动化地进行签名。

感谢阅读全文，希望对你有所助益。这里尤其要感谢来自 OPA/Styra 的 Asad、Torin 以及 Jeff，对我们编写的规则作出很多支持。

释放 Kubernetes 故障节点上的 RBD 卷

Thu, 01 Oct 2020 00:22:06 +0800

在 Kubernetes 节点发生故障时，在 40 秒内（由 Controller Manager 的 --node-monitor-grace-period 参数指定），节点进入 NotReady 状态，经过 5 分钟（由 --pod-eviction-timeout 参数指定），Master 会开始尝试删除故障节点上的 Pod，然而由于节点已经失控，这些 Pod 会持续处于 Terminating 状态。

一旦 Pod 带有一个独占卷，例如我现在使用的 Ceph RBD 卷，情况就会变得更加尴尬：RBD 卷被绑定在故障节点上，PV 映射到这个镜像，PVC 是独占的，无法绑定到新的 Pod，因此该 Pod 无法正确运行。要让这个 Pod 在别的节点上正常运行，需要用合适的路线重新建立 RBD Image 到 PV 到 PVC 的联系。

备份

大家都很清楚，数据相关的操作是高危操作，因此下面的任何步骤执行之前，首先要进行的就是备份。备份操作同样也需要沿着 RBD->PV->PVC 的线路完整进行。

kubectl get pvc，会输出 PVC 绑定的 PV，将 PV 和 PVC 的 YAML 都进行导出备份。
kubectl get pv -o yaml，其中的 spec.rbd.image 字段会指明对应的 RBD Image。使用 RBD 相关命令对 RBD Image 进行备份。

节点主机可用

有些情况下，节点作为 Kubernetes Node 的功能无法正常工作，但是节点本身是可用的，例如无法连接到 API Server 的情况。例如下面的工作负载：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: sleep
    version: v1
  name: sleep
spec:
  selector:
    matchLabels:
      app: sleep
      version: v1
  template:
    metadata:
      labels:
        app: sleep
        version: v1
    spec:
      containers:
      - image: something/nginx:0.1
        imagePullPolicy: Always
        name: sleep
        volumeMounts:
          - name: pvc1
            mountPath: /data
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      volumes:
      - name: pvc1
        persistentVolumeClaim:
          claimName: claim1
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

提交到集群后，会创建一个 Deployment 和 PVC，查看一下所在节点：

$ kubectl get po -o wide
...
sleep-6f7c8cc954-5bzsk ... 10.10.11.21

登录该节点，停止 Kubelet 制造一个 NotReady。使用 watch kubectl get nodes,pods 命令持续观察，会发现如前所述，首先节点进入 NotReady 状态，几分钟之后，Pod 发生如下变化：

$ kubectl get pods
sleep-6f7c8cc954-pqjj6   0/1     ContainerCreating   0          41s
sleep-6f7c8cc954-rcpnc   1/1     Terminating         0          8m44s

原有 Pod 进入 Terminating 状态，新创建了一个 Pod，但是新 Pod 会持续处于 ContainerCreating 状态，查看这个 Pod 的状态：

$ kubectl desribe po sleep-6f7c8cc954-pqjj6
...
Multi-Attach error for volume "pvc-2de7d17c-04c6-11eb-b22b-5254002d96de" Volume is already used by pod(s) sleep-6f7c8cc954-rcpnc
...

可以看到因为存储卷是独占的，导致 Pod 无法成功创建。是不是删除 Pod 就能解决了呢？因为节点不可用，删除是无效的，因此这里需要强行删除：

$ kubectl delete po sleep-6f7c8cc954-rcpnc --force --grace-period=0
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "sleep-6f7c8cc954-rcpnc" force deleted

然而 Pod 仍然无法创建，错误原因：

$ kubectl describe po sleep-6f7c8cc954-fhl8c
Warning  FailedAttachVolume  18s   attachdetach-controller  Multi-Attach error for volume "pvc-2de7d17c-04c6-11eb-b22b-5254002d96de" Volume is already exclusively attached to one node and can't be attached to another

出现另一个错误，PV 已经被绑定到不可用节点。

要解决这个问题，可以使用现有 PV 的 YAML 新建一个 PV，强制指向原有的 RBD Image：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pvc-manual
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 1Gi
  persistentVolumeReclaimPolicy: Delete
  rbd:
    fsType: ext4
    image: kubernetes-dynamic-pvc-3498797d-04c6-11eb-b6b6-4e0deb79a72b
    keyring: /etc/ceph/keyring
    monitors:
    - 10.10.11.11:6789
    - 10.10.11.12:6789
    - 10.10.11.13:6789
    pool: k8s
    secretRef:
      name: ceph-secret
      namespace: ceph
    user: admin
  storageClassName: rbd
  volumeMode: Filesystem

会创建一个新的 PV，状态为 Available。接下来就创建一个新的 PVC，指向新创建的 PV：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  volumeName: pvc-manual

把 Deployment 也创建起来，使用新的 PVC，发现 Pod 保持在 ContainerCreating 状态，查看 Pod 信息会看到：

$ kubectl describe po sleep-6f7c8cc954-5hptw 
Warning  FailedMount             62s (x2 over 112s)   kubelet, 10.10.11.22     MountVolume.WaitForAttach failed for volume "pvc-manual" : rbd image k8s/kubernetes-dynamic-pvc-3498797d-04c6-11eb-b6b6-4e0deb79a72b is still being used
Warning  FailedMount             24s (x2 over 2m41s)  kubelet, 10.10.11.22     Unable to mount volumes for pod "sleep-6f7c8cc954-5hptw_default(9d6caec9-04d1-11eb-afd2-525400c74ddd)": timeout expired waiting for volumes to attach or mount for pod "default"/"sleep-6f7c8cc954-5hptw". list of unmounted volumes=[pvc1]. list of unattached volumes=[pvc1 default-token-97tqr]

此处信息表明，RBD 镜像被占用，接下来我们去故障节点解除这个占用。

首先我们要查找绑定了这一镜像的容器，可以用如下脚本实现：

#!/bin/env python2
import subprocess
import re


print("Searching for docker instances mounting rbds")
mount_list = subprocess.check_output("mount")
dev_list = {}
mount_list = mount_list.split("\n")
regex = r"^(\/dev\/rbd\d+)\son\s.*?\/pods\/([0-9a-z-]+)\/volumes.*?$"

for mount_line in mount_list:
  mat = re.search(regex,mount_line)
  if mat is None:
    continue
  dev_list[mat.group(1)] = mat.group(2)

docker_list = subprocess.check_output(["docker", "ps"])
docker_list = docker_list.split("\n")

for dev in dev_list.keys():
  docker_str = dev_list[dev]
  for docker_process in docker_list:
    if not docker_str in docker_process:
      continue
    docker_id = docker_process.split(" ")[0]
    print "Dev: {}\tDocker ID: {}\n".format([dev, docker_id])

上面的脚本功能很简单，使用 mount 命令列出所有加载卷，然后过滤出 /dev/rbd\d+ 的加载，并识别其中是否符合 Pod 加载的特征，最终会用 容器 ID: 设备名称 的格式输出结果。

$ python2 show-rbd.py
Searching for docker instances mounting rbds
Dev: /dev/rbd0  Docker ID: 033b1185008c
Dev: /dev/rbd0  Docker ID: b716592e5aae

停止并删除其中的容器，并调用 umount /dev/rbd0 卸载卷。最后使用 rbd unmap /dev/rbd0 命令解除关联。再次创建 Pod，会发现 Pod 成功运行。

节点主机不可用

这种情况和前面类似，但是需要在 Ceph 服务端断开关系。

首先查看对应镜像的状态：

$ rbd status kubernetes-dynamic-pvc-fa69dfa7-04d4-11eb-b6b6-4e0deb79a72b -p k8s
Watchers:
    watcher=10.10.11.23:0/4208975345 client.364378 cookie=18446462598732840961

这里看到其中的关联关系。将对应 watcher 拉黑：

$ ceph osd blacklist add 10.10.11.23:0/4208975345
blacklisting 10.10.11.23:0/4208975345 until 2020-10-02T18:37:00.985286+0000 (3600 sec)

后记

整个过程中会涉及到多次删除、覆盖等操作，稍有差池都会导致重要损失，此处描述的步骤也难免有些疏漏，因此务必做好备份工作，这样即使是 RBD 镜像丢失，也可以通过重建 PV 的方式恢复服务。

别问我为啥用 Deployment 跑有状态应用。。

伸手党的容器镜像加固流程

Tue, 15 Sep 2020 20:19:20 +0800

人在江湖飘，哪能不挨刀

说了好几期 CIS 之类的运行时安全问题，K8s 在运行过程中，还有个常见的安全威胁就是镜像漏洞，不少同学都有在实施过程中因为镜像漏洞问题被吊打的经验，今天就结合个人经验，说说镜像漏洞修复的一般流程。

这里主要指的是第三方镜像的修复过程，Scratch 不在此列。

开局一张图：

graph TD
  start(修复任务) --> base_or_app{基础/应用}
  base_or_app-->|业务漏洞|official_image{官方镜像}
  base_or_app-->|基底漏洞|os_updated{底层更新}
  os_updated-->|是|reos_pass{底层扫描}
  os_updated-->|否|change_os(更换底层)
  change_os-->reos_pass
  reos_pass-->|已解决|can_build
  reos_pass-->|未解决|change_os
  official_image --> |是|image_updated{是否已更新?}
  official_image --> |否|can_build{源码齐全}
  image_updated --> |是|rescan_pass{重新扫描通过}
  rescan_pass --> |是|fin(结案)
  rescan_pass --> |否|start
  image_updated -->|否|can_build
  can_build --> |是|docker_build(docker build)
  can_build --> |否|docker_cp(docker cp/commit)
  docker_cp --> rescan_pass
  docker_build --> rescan_pass
  change_os --> rescan_pass

修复任务分析

通常扫描报告会明确指明确切的问题源头、相关软件包、问题版本、修复版本等，首先要根据报告判断修复的目标。修复目标并不一定是固定的，有些情况下可能仅需要修复公开的高危漏洞，有些可能要求更多。

我们都知道，容器镜像是个分层结构，底层通常由操作系统（例如 debian:buster-slim）或者特定运行时（例如 openjdk:16）构成；另外可能构建应用程序，或者直接通过 COPY/ADD 的方式加入应用程序；另外还会通过 CMD、ENV 等指令设置运行环境等。软件漏洞多发于底层和应用程序层，因此这里需要根据扫描报告，确认我们的修复目标。

软件配置问题也可能造成漏洞，可以另行讲解。

应用层漏洞

如果要修复的问题是处于应用层，就要判断该镜像是否为官方镜像，如果答案是肯定的，则可以直接更新官方镜像，通常同一个大版本下的小版本更新，都是兼容的，可以更新之后直接进行测试和复查。

如果官方没有针对性的修复，或者镜像并未更新，就可能需要自己构建镜像了。

如果是开源软件，强烈建议提交 Issue 或者 PR

基础层漏洞

如果是基础层漏洞，除了可以像应用层修复一样，检查版本更新之外，还有另一个选项，就是更换不同的基础层，例如从 Debian 更换为 Ubuntu，这种方式对于 all-in-one 形式的应用（例如大多数用 golang 构建的应用）尤其有效，如果应用程序依赖众多，就不合适了。另外众所周知，Alpine 和我们常用的发行版差异较大，因此也不太合适直接切换。

镜像构建

是不是就一个 docker build 就可以了？多数时候是的。不过要分成几种情况。

有 Dockerfile 的情况
- 官方已经发布二进制物料：这种情况通过修改 Dockerfile 加入更新的二进制文件之后，执行 docker build 即可。
- 官方未发布二进制物料：这种就需要根据源码进行构建，然后再生成 Docker 镜像。
没有 Dockerfile 的情况
- 有的软件源码中通过 Makefile 等方式提供了从二进制到镜像的构建方法，通常需要在 README.md 或者 BUILD.md 中查找线索。
- 更换底层的情况，通常需要自己照猫画虎，重新编写 Dockerfile。
- 还有一种比较尴尬的情况——有二进制物料，但是没 Dockerfile，这种我通常会使用 docker cp->docker commit 的不入流方式。
- 另外一种尴尬情况就是，官方只提供了 Docker 镜像，但是我们想要换掉基础层，这种情况和上面类似，用 docker cp 把官方镜像中的应用文件复制出来即可。

复测

在完成修复步骤之后，可以针对性地进行复测，查看修复情况，循环往复直到完成目标为止。

Kubernetes：移除 CPU 限制，服务运行更快

Fri, 11 Sep 2020 23:57:35 +0800

原文：Kubernetes: Make your services faster by removing CPU limits

作者：ERIC KHUN

我们（Buffer）早在 2016 年就开始使用 Kubernetes 了。我们使用 kops 对 Kubernetes 集群进行管理，其中包含了大约 60 个运行在 AWS 的节点，运行着 1500 个左右的容器。我们的微服务迁移之路充满坎坷。在和 Kubernetes 相处多年以后，我们还是会时不时遭到它的毒打。本文接下来要讨论的案例就是这样——CPU Limit 是一头披着狼皮的羊。

CPU 限制和流控

Google 等公司强烈建议设置 CPU 限制。如果不进行这一限制，节点上的容器可能会耗尽所有 CPU 资源，这可能会引发多种意料之外的事故——例如导致 Kubernetes 关键进程（比如说 kubelet）停止响应。因此理论上为容器设置 CPU 限制能够很好的对节点进行保护。

该特性能限制一个容器在给定周期内（缺省为 100 毫秒）能够消耗的最大 CPU 时间。受限的容器永远无法消耗超过限制的 CPU 资源。Kubernetes 使用 CFS 配额技术对容器进行流控，制止其使用超限的 CPU 资源。也就是说 CPU 的使用受到了限制，会让容器变慢（可能增加响应时间）。

不设置 CPU 限制会怎样

我们很不幸地遭遇了这种情况，在每个节点上运行的 kubelet 进程停止响应。此时节点进入 NotReady 状态，并且其上运行的容器被重新调度到其它节点，又引发其它节点的问题——这可能不是我们希望的情况。

发现流控和延迟的问题

容器运行过程中又一个关键指标就是 throttling。该指标显示了你的容器受到流控的次数。我们有一个奇怪的发现：不管容器的 CPU 消耗是否逼近了上限，都会遇到流控。下图是我们一个主要 API 的表现：

这里的 CPU 上限设置为 800m，而实际运行的最大值仅为 200m。如此一来我们似乎应该认为，CPU 资源足够，无需限流。实际情况呢？

这里可以看到，虽说 CPU 的消耗远没有达到上限附近，还是发生了限流。

我们找到一些资源（github issue、Zalando 的分享、omio 的帖子），都说到了 CPU 限流引起服务响应变慢的问题。

为什么在 CPU 消耗不多的时候还是触发了限流呢？，长话短说的话，这是一个 Linux 内核的 Bug，他会对设置了 CPU 限制的容器进行不必要的流控。如果对其中的细节感兴趣，我们推荐你看看 Dave Chiluk 的精彩演讲，相关的还有一篇文字稿，其中涉及到了更多细节。

移除 CPU 限制（有副作用）

经过多次讨论，我们决定删掉所有关键服务上的 CPU 限制。

事关集群稳定，这是一个艰难的决定。我们的在集群的测试中出现过一些不稳定的情况，部分服务占用过多资源，破坏了同一节点内的其它服务。

如何在去除限制之后保障集群稳定性

隔离不限制 CPU 的服务

因为有的服务会占用太多资源，导致节点进入 NotReady 状态。我们决定把一些这些服务放到特定节点上（taint），如此一来，不受限的服务就不会干扰到受限服务，让我们可以轻易地分辨节点的故障原因。

为容器分配合适的 CPU 和内存 requests

我们最担心的事情就是服务占用太多资源导致节点不可用。然而我们使用 Datadog 让集群变得易于监控，我们花了几个月的时间，对每个我们希望放开限制的服务的运行情况进行观察，根据监控结果，我们将这些容器的 CPU 请求值设置为观测到的上限的 120%。这样就保障了容器的资源需求。

上图可见，CPU 用量的峰值为 242m，我们就根据这个峰值来设置其 CPU 请求值。这个服务是面向用户的，因此其资源使用的波动和流量波动是相匹配的。

同样的方法可以用在内存的设置上。如果觉得还不放心，可以使用 HPA 来增强服务的弹性，并在节点资源不足时告警，或者使用集群的自动扩容能力。

这个操作客观上会降低容器密度。

结果

在几周的调整之后，我们得到了下表的结果，表格中可以看到，所有服务的延迟都大大降低了。

我们的着陆页面（buffer.com），其响应速度提高了 22 倍。

这个内核问题修复了么

4.19 或更高版本的 Linux 发行版已经纠正了该问题（再次感谢 Dave Chiluk 发现并解决了这个问题）。

然而直到 2020 年 9 月 2 号，阅读相关 Issue 时，我们还是看到很多 Linux 项目在引用这个问题，因此我猜测还有一些 LInux 发行版存在该问题。

如果你使用的 Linux 发行版使用的内核小于 4.19，建议为节点进行内核升级。但是任何情况下，我们都建议读者删掉 CPU 限制，看看监控中的流控数据。下面的列表并不完全：

Debian：Buster 版本最近进行了修复，可能有些早期版本也做了补丁。
Ubuntu：Ubuntu Focal Fosa 20.04 已经修复。
EKS 在 2019 年就修复了这个问题。如果版本落后的话，建议升级一下 AMI。
kops 在 2020 年 6 月的 kops 1.18 中开始使用 Ubuntu 20.04 作为缺省的主机镜像。然而如果使用的是低版本 kops，可能就需要等着补丁发布了（我们也在等）。
GKE：在 2020 年 1 月修复了这个问题。但是看起来这个情况还时有发生

这样就解决了么

我不确定是否完全解决。我希望拿到修复后的内核之后，尝试根据本文内容进行实现。

总结

如果你在 Linux 下运行 Docker容器（不管是Kubernetes/Mesos/Swarm），你可能会因为节流而导致容器表现不佳。
把你的发行版升级到最新版本，希望这个错误得到修复
取消 CPU 限制是解决这个问题的一个办法，但这是很危险的，应该格外小心（最好先升级你的内核，并先监控节流）。
如果你取消了 CPU 限制，请仔细监控节点中 CPU 和内存的使用情况，并确保你的 CPU 请求够大，一个安全的方法是，如果资源使用量大，就使用 HPA 来创建新的 Pod，这样 Kubernetes 就会安排在空间富余的节点中了。

kubectl 的奇技淫巧

Thu, 10 Sep 2020 19:44:49 +0800

原文：Ready-to-use commands and tips for kubectl

作者：Flant staff

Kubectl 是 Kubernetes 最重要的命令行工具。在 Flant，我们会在 Wiki 和 Slack 上相互分享 Kubectl 的妙用（其实我们还有个搜索引擎，不过那就是另外一回事了）。多年以来，我们在 kubectl 方面积累了很多技巧，现在想要将其中的部分分享给社区。

我相信很多读者对这些命令都非常熟悉；然而我还是希望读者能够从本文中有所获益，进而提高生产力。

下列内容有的是来自我们的工程师，还有的是来自互联网。我们对后者也进行了测试，并且确认其有效性。

现在开始吧。

获取 Pod 和节点

我猜你知道如何获取 Kubernetes 集群中所有 Namespace 的 Pod——使用 --all-namepsaces 就可以。然而不少朋友还不知道，现在这一开关还有了 -A 的缩写。
如何查找非 running 状态的 Pod 呢？
```
kubectl get pods -A --field-selector=status.phase!=Running | grep -v Complete
```
顺便一说，--field-selector 是个值得深入一点的参数。

如何获取节点列表及其内存容量：

kubectl get no -o json | \
  jq -r '.items | sort_by(.status.capacity.memory)[]|[.metadata.name,.status.capacity.memory]| @tsv'

获取节点列表，其中包含运行在每个节点上的 Pod 数量：

kubectl get po -o json --all-namespaces | \
  jq '.items | group_by(.spec.nodeName) | map({"nodeName": .[0].spec.nodeName, "count": length}) | sort_by(.count)'

有时候 DaemonSet 因为某种原因没能在某个节点上启动。手动搜索会有点麻烦：

$ ns=my-namespace
$ pod_template=my-pod
$ kubectl get node | grep -v \"$(kubectl -n ${ns} get pod --all-namespaces -o wide | fgrep ${pod_template} | awk '{print $8}' | xargs -n 1 echo -n "\|" | sed 's/[[:space:]]*//g')\"

使用 kubectl top 获取 Pod 列表并根据其消耗的 CPU 或内存进行排序：

# cpu
$ kubectl top pods -A | sort --reverse --key 3 --numeric
# memory
$ kubectl top pods -A | sort --reverse --key 4 --numeric

获取 Pod 列表，并根据重启次数进行排序：

kubectl get pods –sort-by=.status.containerStatuses[0].restartCount

当然也可以使用 PodStatus 以及 ContainerStatus 的其它字段进行排序。

获取其它数据

运行 Ingress 时，经常要获取 Service 对象的 selector 字段，用来查找 Pod。过去要打开 Service 的清单才能完成这个任务，现在使用 -o wide 参数也可以：

$ kubectl -n jaeger get svc -o wide
NAME                            TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)                                  AGE   SELECTOR
jaeger-cassandra                ClusterIP   None              <none>        9042/TCP                                 77d   app=cassandracluster,cassandracluster=jaeger-cassandra,cluster=jaeger-cassandra

如何输出 Pod 的 requests 和 limits：

$ kubectl get pods -A -o=custom-columns='NAME:spec.containers[*].name,MEMREQ:spec.containers[*].resources.requests.memory,MEMLIM:spec.containers[*].resources.limits.memory,CPUREQ:spec.containers[*].resources.requests.cpu,CPULIM:spec.containers[*].resources.limits.cpu'
NAME                                  MEMREQ       MEMLIM        CPUREQ   CPULIM
coredns                               70Mi         170Mi         100m     <none>
coredns                               70Mi         170Mi         100m     <none>
...

kubectl run（以及 create、apply、patch）命令有个厉害的参数 --dry-run，该参数让用户无需真正操作集群就能观察集群的行为，如果配合 -o yaml，就能输出命令对应的 YAML：
```
$ kubectl run test --image=grafana/grafana --dry-run -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  replicas: 1
  selector:
    matchLabels:
      run: test
```
简单的把输出内容保存到文件，删除无用字段就可以使用了。

1.18 开始 kubectl run 生成的是 Pod 而非 Deployment。

获取指定资源的描述清单：

kubectl explain hpa
KIND:     HorizontalPodAutoscaler
VERSION:  autoscaling/v1
DESCRIPTION:
     configuration of a horizontal pod autoscaler.
FIELDS:
   apiVersion    <string>
...

网络

获取集群节点的内部 IP：

$ kubectl get nodes -o json | jq -r '.items[].status.addresses[]? | select (.type == "InternalIP") | .address' | \
  paste -sd "\n" -
9.134.14.252

获取所有的 Service 对象以及其 nodePort：

$ kubectl get -A svc -o json | jq -r '.items[] | [.metadata.name,([.spec.ports[].nodePort | tostring ] | join("|"))]| @tsv'

kubernetes  null
...

在排除 CNI（例如 Flannel）故障的时候，经常会需要检查路由来识别故障 Pod。Pod 子网在这里非常有用：

$ kubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}' | tr " " "\n"                                                            fix-doc-azure-container-registry-config  ✭
10.120.0.0/24
10.120.1.0/24
10.120.2.0/24

日志

使用可读的时间格式输出日志：

$ kubectl logs -f fluentbit-gke-qq9w9  -c fluentbit --timestamps
2020-09-10T13:10:49.822321364Z Fluent Bit v1.3.11
2020-09-10T13:10:49.822373900Z Copyright (C) Treasure Data
2020-09-10T13:10:49.822379743Z
2020-09-10T13:10:49.822383264Z [2020/09/10 13:10:49] [ info] Configuration:

只输出尾部日志：

kubectl logs -f fluentbit-gke-qq9w9  -c fluentbit --tail=10
[2020/09/10 13:10:49] [ info] ___________
[2020/09/10 13:10:49] [ info]  filters:
[2020/09/10 13:10:49] [ info]      parser.0
...

输出一个 Pod 中所有容器的日志：

kubectl -n my-namespace logs -f my-pod –all-containers
使用标签选择器输出多个 Pod 的日志：

kubectl -n my-namespace logs -f -l app=nginx
获取“前一个”容器的日志（例如崩溃的情况）：

kubectl -n my-namespace logs my-pod –previous

其它

把 Secret 复制到其它命名空间：

kubectl get secrets -o json --namespace namespace-old | \
  jq '.items[].metadata.namespace = "namespace-new"' | \
  kubectl create-f  -

下面两个命令可以生成一个用于测试的自签发证书：

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=grafana.mysite.ru/O=MyOrganization"
kubectl -n myapp create secret tls selfsecret --key tls.key --cert tls.crt

Kubernetes 无状态应用的一般特征

Mon, 07 Sep 2020 22:42:02 +0800

以 12 要素为代表的微服务标准，很好地给微服务的特征做出了指导。然而具体到以容器形式在 Kubernetes 上运行的无状态业务应用上，这个标准是有些高层的——它看重的是方法和架构。如果仅从外在视角来对一个“顺眼”的 Kubernetes 应用进行观察，这个应用应该有什么特征呢？

依赖关系清晰

微服务应用通常会有各种外部依赖，例如数据库、缓存、队列等平台能力，或者业务上的依赖服务等，因此一个健康的微服务组合而成的应用，必须能处理好依赖关系。

微服务的启动顺序不是固定的，并且存在独立更新、重启的可能。而很多应用仅在启动时进行连接，这就要求在 Kubernetes 上运行的应用，首先在启动时，不会因为暂时无法连接依赖服务直接崩溃；同时在运行期间，也有处理这种随时处理重连的能力。

具备自检能力

存活检测关注的是进程是否活跃，是否应该重新启动；就绪检测代表的是服务能力，是否应该保存在 Service 的负载均衡池中。

在没有设置就绪检测的情况下，Pod 一旦启动成功，K8s 就会把相关服务的请求发给该实例，如果这个实例启动较慢，就有可能对业务造成损失。同理，存活和就绪检测应该分别进行，例如业务阻塞时，暂时将实例摘除，但是无需重启，即可逐步恢复服务能力。

联系到前面的依赖关系问题，在微服务环境中，一个服务的就绪检测应该仅仅关注本应用的情况，检测过程中不应包含对依赖服务的调用——否则所有依赖故障服务的其它服务的就绪检查失败，造成大面积故障。

日志采集和处理

应用不应继续把日志输出到本地文件，而应该输出到 stdout 和 stderr；
集群应该针对容器的 stdout、stderr 提供统一的日志采集，建议使用 Daemonset 而非 Sidecar；
进行日志采集的同时，集群应提供 ES、Loki 或其它类似机制来对日志进行处理，并且其处理和存储能力应该有初步预案；
应用日志应提供分级开关，保证同一镜像在不同环境中可以输出不同数量和级别的日志信息。

尽量优雅关停

容器命令入口应该有能力接收 SIGTERM，并在需要的情况下传递给业务主进程；
应用进程接收到 SIGTERM 信号之后，不应立刻关停，而是处理好剩余的在途业务；
使用 preStop 等 Pod 生命周期手段来完成特定任务；
避免使用长连接，保持简单负载均衡的有效性。

故障预防和应对

避免运行单 Pod 的 Deployment；
使用 Pod 软亲和避免同 Deployment 中的不同 Pod 分布在同一节点上；
遭遇不可恢复的故障，应该允许应用崩溃，由 K8s 重新启动；
定义 PDB（Pod disruption budgets），告知 K8s 为应用提供最低 Pod 数量保障。

资源使用

必须定义 CPU 和内存的 Requests；
必须定义内存的 Limits；
同一集群中的不同微服务，如果有不同 QoS 要求，应该定义不同的 qosClass，避免被无差别驱逐。

安全相关

应清晰掌握并声明应用运行所需的 Linux Capabiltiy；
避免使用 Root 身份运行容器；
使用只读的 RootFS，所有写入需求应该使用存储卷来完成；
避免特权逃逸。

OPA Gatekeeper 几条入门策略

Mon, 17 Aug 2020 01:13:16 +0800

Gatekeeper 是基于 OPA（Open Policy Agent）的一个 Kubernetes 策略解决方案。在之前的文章中说过，在 PSP/RBAC 等内置方案之外，在 Kubernetes 中还可以通过策略来实现一些额外的管理、安全方面的限制，本文将会从安装开始，介绍几条实用的小策略。

安装篇

安装可以通过 kubectl 来进行：

$ kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

namespace/gatekeeper-system created
......
gatekeeper-validating-webhook-configuration created

或者也可以使用 Helm（目前只支持 Helm 2）：

helm repo add gatekeeper https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/charts/gatekeeper
helm install gatekeeper/gatekeeper --devel

策略简介

Gatekeeper 的策略通常是由两个资源对象组成的：Template 和 Constraint。

Template：其定义分为两部分：crd 和 targets，crd 的确是一个 CRD 定义，也就是说生成一个 Template CR 对象，会随之生成一个 CRD；targets 则是一组 rego 为主体的代码包——个人表示很反对这种 YAML 中加代码的粗暴行径。

Contsraint：这个对象的定义来自于 Template 生成的 CRD，它负责为模板输出两种内容：其一是对 Kubernetes 资源对象的过滤，其二就是根据 CRD 定义，为 Template 提供输入参数。

只允许特定用户名操作特定命名空间

在 cluster-admin 成为缺省用户的情况下，我们希望限制特定用户在 Namespace 中的能力，例如下面的规则，会检查用户名前缀是否为命名空间名称：

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: ns-user
spec:
  crd:
    spec:
      names:
        kind: ns-user
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package nsuser
        violation[{"msg": msg}] {
          user_name = input.review.userInfo.username
          ns = input.review.object.metadata.namespace
          not startswith(user_name, ns)
          msg = sprintf("User %v is denied.", [user_name])
        }

上面的代码有几个需要注意的：

metadata.name 要和 spec.crd.spec.names.kind 一致
规则顺序执行，使用 startswith 函数判断输入内容里面的用户名和命名空间是否为前缀关系
如果一致，则规则停止执行；如果不一致，则输出拒绝信息。

声明了 Template 之后，使用 kubectl apply -f 提交到集群。

然后创建一个 constraints：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: ns-user
metadata:
  name: ns-user
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["ServiceAccount"]

这里的 kind 字段使用的就是前面模板生成的 CRD（所以 template 和 contsrint 同时创建的话，后者的创建过程可能失败）。在 match 字段中，我们限制面向的是 ServiceAccount 对象，接下来测试一下：

$ kubectl create sa ab
Error from server ([denied by ns-user] User dustise@gmail.com is denied.): admission webhook "validation.gatekeeper.sh" denied the request: [denied by ns-user] User dustise@gmail.com is denied.

$ kubectl create sa sbac --kubeconfig=kubeconfig-defaultsa -n default
serviceaccount/sbac created

$ kubectl create deployment nginx --image=nginx
deployment.apps/nginx created

上面可以看到，策略成功发挥作用，使用缺省用户无法创建 sa，但是可以创建 deployment，换用名为 defaultsa 的用户，则能够创建成功。

这里如果多做一点测试，会发现 DELETE 操作是不受限制的，原因是 Gatekeeper 的 Webhook 配置去掉了对 DELETE 的反应，可以 kubectl edit ValidatingWebhookConfiguration gatekeeper-validating-webhook-configuration 进行编辑，在 operations 字段中加入 DELETE 元素。

只允许特定镜像前缀

如果在某集群中，我们要求仅适用内网仓库中的镜像，可以使用如下策略：

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: imagecheck
spec:
  crd:
    spec:
      names:
        kind: imagecheck
      validation:
        openAPIV3Schema:
          properties:
            prefix:
              type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package image
        violation[{"msg": msg}] {
          containers = input.review.object.spec.template.spec.containers
                some i
                image := containers[i].image
                not startswith(image, input.parameters.prefix)
                msg := sprintf("Image '%v' is not allowed.", [image])
        }

相对前面的模板，这个模板复杂了一些：

在 spec.validation 字段中加入了一个字符串类型的属性，用这个属性作为参数，定义允许使用的容器前缀，使用 input.parameters.prefix 的方式来引用参数。

有一行奇怪的代码 some i，some关键字声明了一个名为 i 的变量，规则会使用变量 i 对数组进行轮询，查找前缀不符合参数要求的镜像名称。

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: imagecheck
metadata:
name: imagecheck
spec:
match:
kinds:
  - apiGroups: ["apps"]
    kinds:
    - "Deployment"
    - "DaemonSet"
    - "StatefulSet"
parameters:
prefix: "dustise/"

Constraints 中注明，对 Deployment 等三种对象进行校验，要求其镜像前缀为 dustise/，下面我们进行一个测试：

$ kubectl create deployment sleep --image=nginx
Error from server ([denied by imagecheck] Image 'nginx' is not allowed.): admission webhook "validation.gatekeeper.sh" denied the request: [denied by imagecheck] Image 'nginx' is not allowed.

$ kubectl create deployment sleep --image=dustise/sleep
deployment.apps/sleep created

Nginx 镜像被禁止，而 dustise/sleep 镜像则成功创建。

Pod 必须具备资源限制

我们建议所有 Pod 都配置资源限制和请求，便于调度，也能预防系统资源滥用。下面的模板会遍历 Pod 定义，并对资源限制不完整的容器发出警告。

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: resource-limit
spec:
  crd:
    spec:
      names:
        kind: resource-limit
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package limit
        resources_defined(x) {
          x.resources; x.resources.limits; x.resources.requests
        }
        violation[{"msg": msg}] {
          ctr_list = input.review.object.spec.template.spec.containers
          some i
          ctr = ctr_list[i]
          not resources_defined(ctr)
          msg = sprintf("%v containers without 'resource' fields", [ctr.name])
        }

模板文件中，我们定义了一个函数，分号分割的三个判断构成了逻辑与的关系，缺乏任何一个字段都会导致返回 false。

接下来创建类似的 Constraint 对象：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: resource-limit
metadata:
  name: resource-limit
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds:
        - "Deployment"
        - "DaemonSet"
        - "StatefulSet"

再次创建 Deployment，会看到新的拒绝信息：

$ kubectl create deployment sleep2 --image=dustise/sleep 
Error from server ([denied by resource-limit] sleep containers without 'resource' fields): admission webhook "validation.gatekeeper.sh" denied the request: [denied by resource-limit] sleep containers without 'resource' fields

如果创建下列代码所包含的 Deployment 对象，则会成功：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: sleep
  name: sleep
spec:
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      containers:
      - image: dustise/sleep
        imagePullPolicy: Always
        name: sleep
        resources:
          limits:
            cpu: 100m
          requests:
            cpu: 100m
      dnsPolicy: ClusterFirst

小结

Rego 语法还是有点烦人的，好在官方源码中提供了一些样例和基本用途的代码库可以参考。另外也可以用 Rego Playground 进行在线调试，来编写稍微复杂一点的策略。

我还是喜欢 Kyverno..

Kubernetes 为什么需要策略支持

Wed, 29 Jul 2020 10:13:09 +0800

Kubernetes 中内置了 RBAC、SecurityContext、PodSecurityPolicy 几个对象，用于为集群的运维和运营工作提供安全支持，那么为什么还要出现 Gatekeeper、Kyverno、Polaris 等策略系统呢？答案呼之欲出——不够用。首先看看几个内置手段的工作范围。

RBAC

这是一个最基础的访问控制手段，它的任务就是描述“谁”能把“什么”“怎么样”。

谁：这个主语通常指的是操作主体，在 RBAC 体系中，会在 RoleBinding 或 ClusterRoleBinding 的 Subject 字段中进行指定，其取值范围包括 user、group 以及 ServiceAccount 等。
什么：Kubernetes 中的对象，例如 Pod、Namespace、NetworkPolicy 等，除此之外还包括对象的子对象，例如 Pod 的 logs、exec 等。这个内容在 Role 或者 ClusterRole 的 resources 字段中进行表达。
怎么样：允许特定用户对特定资源进行的操作，例如 get、create 和 update 等，这个内容保存在 Role 或者 ClusterRole 对象的 verbs 字段中。

RBAC 相对来说是一个比较粗放的模型，实际工作中可能会有更复杂的需要，例如 Pod、NetworkPolicy 或者复杂 Operator 的 CRD，都是需要精细控制的。

SecurityContext

SecurityContext 负责定义 Pod 和容器的一些具体行为，可以直接在 Pod 中进行定义。

注意 SecurityContext 字段在容器和 Pod 两个级别都是存在的，容器级别的对象类型为 SecurityContext，其限制范围包括：

allowPrivilegeEscalation
capabilities
privileged
procMount
readOnlyRootFilesystem
runAsGroup
runAsNonRoot
runAsUser
seLinuxOptions
windowsOptions

而 Pod 级别的对象类型为 PodSecurityContext，其限制范围包括：

fsGroup
fsGroupChangePolicy
runAsGroup
runAsNonRoot
runAsUser
seLinuxOptions
supplementalGroups
sysctls
windowsOptions

PodSecurityPolicy

PSP 像是 RBAC 的延伸，通过 PodSecurityPolicy 对象定制 Pod 的安全规则，再借助 RBAC 的形式授权给用户，从而允许或者禁止特定用户/ServiceAccount 所创建的 Pod 的安全相关的能力。

和前面两种措施不同，PSP 并不是开箱即用的，需要单独启用这个 AdmissionController。在启用之前要注意，PSP 除了需要显式启用，还需要进行显式授权，必须为当前集群中运行的所有 Pod 所属的 ServiceAccount 赋予合适的 PSP，才能启用该功能，否则会造成大量的系统 Pod 无法正常运行。

PSP 基本覆盖了 SecurityContext 的各项能力，除此之外还加入了一些特技：

hostPID、hostIPC
hostNetwork、hostPorts
allowedHostPaths

和可以自由发挥的 SecurityContext 相比，PSP 具备更多能力，也具备更大的强制性，可能会对既有集群上的业务造成一定影响，需要慎重使用。

工作负载安全

根据前面的了解，我们借助 Kubernetes 自有的安全设置能力，已经能够对工作负载进行很多有助于提高安全性的设置，这是否足够了呢？其实是存在一些漏洞的，例如管理需要，我们要求必须提供资源限制，可以使用如下的的 Kyverno 策略：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-cpu-memory
spec:
  validationFailureAction: enforce
  rules:
    - name: check-pod-resources
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "CPU and memory resource requests and limits are required"
        pattern:
          spec:
            containers:
              - name: "*"
                resources:
                  limits:
                    memory: "?*"
                    cpu: "?*"
                  requests:
                    memory: "?*"
                    cpu: "?*"

用类似的手法，还可以检查标签、标注等是否合规。

参考 CIS Kubernetes Benchmark (v151)，考虑以下几个要求：

5.1.1 Ensure that the cluster-admin role is only used where required

这是一个不计分项目，确保仅在必要时使用 cluster-admin 身份（例如 kubeadm 生成的缺省 kubeconfig 文件）。下面的 Kyverno 规则可以用于制止 cluster-admin 身份的用户创建 deployment：

apiVersion : kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: deny-cluster-admin
spec:
  validationFailureAction: enforce
  background: false
  rules:
  - name: deny-cluster-admin
    match:
      resources:
        kinds:
        - Deployment
      namespace: default
      clusterroles:
      - cluster-admin
    validate:
      message: "cluster-admin is denied"
      deny: {}

在没有启用 PSP 的情况下，可以用如下策略完成这个限制：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-hostnetwork
spec:
  validationFailureAction: enforce
  background: false
  rules:
  - name: check-hostnetwork
    match:
      resources:
        kinds:
        - Deployment
    validate:
      message: "Hostnetwork is not allowed"
      pattern:
        spec:
          template:
            spec:
              =(hostNetwork): "!true"

5.5.1 Configure Image Provenance using ImagePolicyWebhook admission controller

又一个不计分，但是个人认为很有用的规则，例如特定命名空间内，只会运行同样来源的镜像：

apiVersion : kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: image-prefix
spec:
  validationFailureAction: enforce
  background: false
  rules:
  - name: image-prefix
    match:
      resources:
        kinds:
        - Deployment
      namespace: default  
    validate:
      message: "Registry is not allowed"
      pattern:
        spec:
          template:
            spec:
              containers:
              - name: "*"
                image: "trust-me/*"

针对 Kubernetes 工作负载的策略工具

Thu, 16 Jul 2020 08:35:47 +0800

原文：Enforcing policies and governance for Kubernetes workloads

作者：Amit Saha

本文将会讲述使用 conftest 这样的静态工具以及 Gatekeeper 之类的集群内 Operator 为 Kubernetes 工作负载提供策略支持的方法。

本文所讲的策略，指的是在 Kubernetes 中，阻止特定工作负载进行部署的方法。

这种要求通常是出于合规的考虑，有一些最佳实践可以推荐给集群管理员：

不要运行特权 Pod。
不要用 root 运行 Pod。
指定资源限制。
不要使用 latest 标签的镜像。
限制 Linux capability 的使用。

除去上述安全要求，可能还会有一些应用管理方面的需要，例如：

所有工作负载都应该有 project 和 app 标签。
所有工作负载都应该从特定镜像库获取（例如 my-company.com）。

最后还有一类需求，防止工作负载之间的冲突，例如多个服务不应使用同样的 Ingress 主机名。

下面会分别讲述集群内外进行策略实施的方法。

不符合策略规定的工作负载将被拒绝部署。

集群外方式是通过对 YAML 文件进行静态检查之后，根据检查结果决定是否放行的。

有多种工具能够完成这一任务。

集群内方式是使用 Validating admission controller，这些控制器会在工作负载进入数据库之前进行调用。

本文所涉的代码可以在 github 找到。

不合规的 Deployment

假设我们有这样一个 YAML：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
  labels:
    app: http-echo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: http-echo
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: http-echo
        image: hashicorp/http-echo
        args: ["-text", "hello-world"]
        ports:
        - containerPort: 5678

      - name: http-echo-1
        image: hashicorp/http-echo:latest
        args: ["-text", "hello-world"]
        ports:
        - containerPort: 5678

上面的清单会生成一个 Pod，其中包含两个容器，这两个容器使用的是同一个镜像。

第一个容器没有指定镜像标签，另外一个用的是 latest，最终他们使用的都是 hashicorp/http-echo 镜像的 latest 版本。

这不符合前面说的最佳实践，应该阻止这种工作负载在我们的集群上运行。正确的指定镜像的方式是填写精确的标签，例如 hashicorp/http-echo:0.2.3。

那么就看看如何使用静态分析的方式，制定策略来制止这种工作负载的部署。

要阻止这种资源到达集群，可能要在如下位置嵌入这个分析过程：

Git 的 pre-commit，在进入 GIT 之前进行检查。
作为 CI/CD Pipeline 的一部分，在 Git 分支合并到主线之前进行检查。
作为 CI/CD Pipeline 的一部分，在资源被提交到集群之间进行检查。

使用 Conftest 实时策略

Conftest 是一个针对配置文件的测试框架，能够用于对 Kubernetes 清单文件进行检查和校验。

Conftest 的测试使用一种叫 Rego 的 DSL 编写。

可以根据项目网站上的安装指导进行安装。

目前的最新版本为 0.19.0。

接下来定义两条策略：

package main

deny[msg] {
  input.kind == "Deployment"
  image := input.spec.template.spec.containers[_].image
  not count(split(image, ":")) == 2
  msg := sprintf("image '%v' doesn't specify a valid tag", [image])
}

deny[msg] {
  input.kind == "Deployment"
  image := input.spec.template.spec.containers[_].image
  endswith(image, "latest")
  msg := sprintf("image '%v' uses latest tag", [image])
}

猜猜这两条策略有什么用？

两个策略都是用在 Deployment 对象上的，他们会从 spec.container 字段中获取内容。

第一条规则用于检查镜像是否带有标签：

  not count(split(image, ":")) == 2

第二条规则会检查，标签是否为 latest：

  endswith(image, "latest")

如果条件为真，那么 deny 块就会被判为非法。

如果代码中的 deny 超过一个，conftest 会分别进行检查，如果任意一个 deny 生效，都会做出违规判断。

把这段代码保存为 check_image_tag.rego，并运行 conftest 对 deployment.yaml 进行检查：

$ conftest test -p conftest-checks test-data/deployment.yaml
FAIL - test-data/deployment.yaml - image 'hashicorp/http-echo' doesn't specify a valid tag
FAIL - test-data/deployment.yaml - image 'hashicorp/http-echo:latest' uses latest tag

2 tests, 0 passed, 0 warnings, 2 failures

两个测试的结果都是失败。

conftest 是静态的，需要在把 YAML 提交给集群之前进行检查。

如果已经在使用 CICD 工具向集群提交 YAML，就需要新增一个步骤，使用 conftest 策略对所有资源进行校验。

但是这样就可以阻止用户向集群提交使用 latest 标签的 Deployment 对象吗？

当然了，所有具备权限的人，只要跳过 CICD 就可以用 kubectl apply -f deployment.yaml 中在集群中创建这种违规对象。

所以要在集群中部署动态检查来弥补这种不足——在非法对象被发送给集群之后拒绝。

Kubernetes API

回顾一下创建下面 Pod 的过程：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: sise
    image: learnk8s/app:1.0.0
    ports:
    - containerPort: 8080

kubectl apply -f pod.yaml 执行之后，对象定义被发送给 API Server：

YAML 保存到 ETCD。
调度器把 Pod 分配给 Node。
Kubelet 收到 Pod 定义，并创建对象。

只有这么一点么？

如果 YAML 有拼写错误怎么办？

如何阻止无效的 YAML 进入 ETCD？

在 kubectl apply 时候，首先是 Kubelet 做了一些事：

在客户端对资源定义进行检查。
把 YAML 转换为 JSON。
从 KUBECONFIG 读入配置。
把对象报文发送给 kube-apiserver。

api-server 收到请求之后，也不会立即存入 etcd。

首先他要检查请求者身份是否合法，也就是进行认证。

通过认证之后，还要判断该用户是否有权创建资源？

身份和权限不能混为一谈，能访问集群不代表能够读写所有对象。鉴权过程通常是使用 RBAC 机制实现。

有了 RBAC，就可以通过适当的授权来限制用户的能力了。

假设用户已经能够通过认证并且具备所需权限，是不是就能够把 Pod 定义保存到 Pod 之中了？并不是。

api-server 自身也是一个 Pipeline。

请求报文在保存到数据库之前，还要经过几个组件。认证和授权就是这些组件的一部分，还有其他组件。

在对象进入数据库之前，首先会由 Admission Controller 进行处理。

这个步骤中，就有机会对当前资源进行更多检查。Kubernetes 缺省启用了几个 Admission Controller：

kube-apiserver 的 --enable-admission-plugins 中可以看到启用的项目。

下面用 NamespaceLifecycle 为例来看看 Admission Controller 的行为。

Validating admission controllers

NamespaceLifecycle 会阻止用户在不存在的 Namespace 中创建 Pod，例如下面的定义：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace: does-not-exist
spec:
  containers:
  - name: sise
    image: learnk8s/app:1.0.0
    ports:
    - containerPort: 8080

YAML 结构是有效的，所以它能通过 kubectl 的校验，提交给集群。

假设用户通过了认证和鉴权，这个请求就会进入 NamespaceLifecycle。does-not-exist 命名空间并不存在，请求被拒绝。

另外 NamespaceLifecycle 还会阻止删除 default、kube-system 和 kube-public 命名空间的请求。

用于对请求进行校验的控制器被集中在 Validating 分类之中。

除此之外还有另外一个分类，被称为 Mutating。

Mutating admission controllers

从名字就看得出，Mutating Controller 控制器能够对请求报文做出变更。

DefaultStorageClass 就是一个很好的例子。

假设要创建一个 PVC 对象：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

这个对象提交之后，如果使用 kubectl get pvc，会发现存储卷状态为 Bound 并且被赋予了一个 standard 的 StorageClass。

NAME     STATUS   VOLUME         CAPACITY   ACCESS MODES   STORAGECLASS   AGE
my-pvc   Bound    pvc-059f2da2   3Gi        RWO            standard       3s

很明显我们的 YAML 中并没有这些定义。用 kubectl get pvc my-pvc -0 yaml 查看一下 YAML，会看到如下内容：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi
  storageClassName: standard
  volumeMode: Filesystem
  volumeName: pvc-059f2da2-a216-42b7-875e-e7da327605dd

多出了一行 storageClassName: standard。这里的 standard 并不是 API 中硬编码的，而是把缺省 StorageClass 的名字注入到 spec.storageClassName 之中。

可以用命令读取缺省 StorageClass：

$ kubectl get storageclass
NAME                 PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE   AGE
standard (default)   k8s.io/minikube-hostpath   Delete          Immediate           8m

如果缺省 StorageClass 名称为 aws-ebs，DefaultStorageClass Admission Controller 会把它注入到之前 standard 所在的位置。

Kubernetes 带有多个 Mutating 和 Validating Admission Controller，官方网站上有完整的列表。

请求在经过这些关卡之后，才能保存到数据库。

如果想要自定义检查或变更过程，如何能加入自己的规则呢？

Admission Controller 的扩展性

除了 Kubernetes 内置之外，他也可以使用自己的 Admission Controller。

有两个可编程的点：MutationAdmissionWebhook 和 ValidationAdmissionWebhook。可以在这两个 Webhook 上注册自己的组件，这样在 Admission 阶段就可以使用自定义的组件来处理对象了。

因此可以编写一个组件，来检查当前 Pod 是否使用了来自特定私有镜像库的镜像。

把这个组件注册到 ValidationAdmissionWebhook，来对容器定义做出放行或阻拦的决策。

这就是 Gatekeeper 的用途——它可以被注册到集群，对请求信息进行校验。

用 Gatekeeper 实施策略

Gatekeeper 让 Kubernetes 管理员可以定义策略来保证集群的合规性，并符合最佳实践的要求。

Gatekeeper 会将自己注册到 Validation Webhook。

提交到集群的任何资源都会被活动的策略进行检查。

同时 Gatekeeper 也符合 Kubernetes 的架构建议，使用 CRD 来管理策略，因此它的策略也是 Kubernetes 资源。

Google 云文档在这方面有很精彩的阐述。

从内部看，Gatekeeper 使用 Open Policy Agent(OPA) 作为核心的策略引擎，策略使用 Rego 语言编写——和 conftest 一样。

在下面的内容里，会尝试使用 Gatekeeper。此处要求用户使用管理用户操作 Kubernetes，使用下面的指令部署 Gatekeeper：

kubectl apply -f \
https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

检查运行情况：

$ kubectl -n gatekeeper-system describe svc gatekeeper-webhook-service
Name:              gatekeeper-webhook-service
Namespace:         gatekeeper-system
Labels:            gatekeeper.sh/system=yes
Annotations:       ...
Type:              ClusterIP
IP:                10.102.199.165
Port:              <unset>  443/TCP
TargetPort:        8443/TCP
Endpoints:         172.18.0.4:8443

这个服务就是用于验证的的。所有的 Pod、Deployment、Service 等，都要受到 Gatekeeper 的监管

使用 ContstraintTemplate 定义可复用的策略

在 Gatekeeper 中，首先需要使用 ContstraintTemplate 创建策略。

下面的 ContstraintTemplate 定义会拒绝使用 latest 标签的镜像。

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8simagetagvalid
spec:
  crd:
    spec:
      names:
        kind: K8sImageTagValid
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8simagetagvalid

        violation[{"msg": msg, "details":{}}] {
          image := input.review.object.spec.template.spec.containers[_].image
          not count(split(image, ":")) == 2
          msg := sprintf("image '%v' doesn't specify a valid tag", [image])
        }

        violation[{"msg": msg, "details":{}}] {
          image := input.review.object.spec.template.spec.containers[_].image
          endswith(image, "latest")
          msg := sprintf("image '%v' uses latest tag", [image])
        }

这个策略和前面 conftest 的策略类似，但是也有些区别。

输入对象名称为 input.review.object，而不是 input，这里也无需检查输入对象的 kind。
deny 规则改为 violation。

violation 块的签名是一个包含两个属性的对象。

第一个是字符串类型的 msg。
第二个是 details 对象，其中可以包含任意属性。

这两个属性都会用作返回值。

接下来用 kubectl 把这个定义提交到集群。然后就可以使用 describe 命令查询模板情况：

$ kubectl apply -f templates/check_image_tag.yaml
constrainttemplate.templates.gatekeeper.sh/k8simagetagvalid created

$ kubectl describe constrainttemplate.templates.gatekeeper.sh/k8simagetagvalid
Name:         k8simagetagvalid
Namespace:
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"templates.gatekeeper.sh/v1beta1","kind":"ConstraintTemplate","metadata":
                {"annotations":{},"name":"k8simagetagvalid"},"spec"...
API Version:  templates.gatekeeper.sh/v1beta1
Kind:         ConstraintTemplate

这个对象并不能直接用于进行校验。它只是一个策略定义，要使用这个策略，还要创建一个 Constraint。

创建一个 Constraint

Constraint 对象的含义是“在集群中使用这个策略”。

可以把 ConstraintTemplates 当做一本菜谱，其中包含虽然包含几百个菜式，但是菜谱本身是无法食用的。必须选择菜谱并按照菜谱要求提供相应的材料，进行合适的操作，才能烤出蛋糕。

下面举个例子，用前面的 K8sImageTagValid 创建一个 Contraint：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sImageTagValid
metadata:
  name: valid-image-tag
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]

这个 Constraint 引用了 ConstraintTemplate，并用 spec.match 字段规定了适用的资源类型。这里我们要求针对 api 组下的 Deployment 对象进行检查。

这些字段是数组类型的，因此可以指定多个值，把检查范围扩展到 StatefulSet、DaemonSet 等。

用 kubectl apply 提交这个对象。

测试策略

用带有两个镜像的 Deployment 进行测试：

$ kubectl apply -f deployment.yaml
Error from server ([denied by valid-image-tag] image 'hashicorp/http-echo' doesn't specify a valid tag
[denied by valid-image-tag] image 'hashicorp/http-echo:latest' uses latest tag): error when creating
"test-data/deployment.yaml": admission webhook "validation.gatekeeper.sh" denied the request:
[denied by valid-image-tag] image 'hashicorp/http-echo' doesn't specify a valid tag
[denied by valid-image-tag] image 'hashicorp/http-echo:latest' uses latest tag

Gatekeeper 拒绝了输入内容，可以看出这个过程是不能跳过的。

如果集群中正在运行工作负载，此时实施 Gatekeeper 策略可能会很有难度——这有因为合规问题导致业务中断的风险。

Gatekeeper 还允许使用 dry-run 模式运行 Constraint：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sImageTagValid
metadata:
  name: valid-image-tag
spec:
  enforcementAction: dryrun
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]

这个模式中，策略不会阻止工作负载的部署，但是会在对象的 Violation 字段中记录违规行为：

$ kubectl describe k8simagetagvalid.constraints.gatekeeper.sh/valid-image-tag
Name:         valid-image-tag
Namespace:
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
....

  Total Violations:  2
  Violations:
    Enforcement Action:  dryrun
    Kind:                Deployment
    Message:             image 'hashicorp/http-echo' doesn't specify a valid tag
    Name:                http-echo
    Namespace:           default
    Enforcement Action:  dryrun
    Kind:                Deployment
    Message:             image 'hashicorp/http-echo:latest' uses latest tag
    Name:                http-echo
    Namespace:           default
Events:                  <none>

在确保所有工作负载都合规之后，就可以移除 dry-run，正式启用策略了。

标签检查

这个例子会检查 Deployment 对象，要求必须包含 project 和 app 两个标签。

如果用 conftest：

package main

deny[msg] {
  input.kind == "Deployment"

  required := {"app", "project"}
  provided := {label | input.metadata.labels[label]}
  missing := required - provided

  count(missing) > 0
  msg = sprintf("you must provide labels: %v", [missing])
}

上面代码中：

required 是一个集合，其中包含了 app 和 project 两个元素。我们希望每个 Deployment 都包含这两个标签。
provided 会从输入中读取当前对象的标签。
两个集合相减，得到缺失的标签的集合，赋值给 missing。
用 count() 函数获取 missing 集合的元素数量，如果大于零，代表该输入不合规。

测试一下：

$ conftest test -p conftest-checks/check_labels.rego test-data/deployment.yaml
FAIL - test-data/deployment.yaml - you must provide labels: {"project"}
1 test, 0 passed, 0 warnings, 1 failure

在 YAML 中加入要求的标签，才能通过测试。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
  labels:
    app: http-echo
    project: test
...

前面提到，这样的不合规对象还是可以提交给集群的，因此还是需要 Gatekeeper 来在集群之中使用策略。

首先创建一个 ConstraintTemplate：

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        # Schema for the `parameters` field
        openAPIV3Schema:
          properties:
            labels:
              type: array
              items: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels

        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("you must provide labels: %v", [missing])
        }

上述代码演示了如何从输入中抓取参数。

并且这里使用 openAPIV3Schema 对输入进行过滤，这一节代码表示要求输入对象有一个参数 label，其数据类型为字符串数组。所有输入都通过 input.parameters 属性传递给 constraint。

模板提交以后，就可以据此创建 Contstraint 了：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: deployment-must-have-labels
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]
  parameters:
    labels: ["app", "project"]

这个对象提交以后，集群中就有了校验镜像和校验标签的两个 Constraint。

再次创建前面的 Deployment：

$ kubectl apply -f deployment.yaml
Error from server ([denied by deployment-must-have-labels] you must provide labels: {"project"}
[denied by valid-image-tag] image 'hashicorp/http-echo' doesn't specify a valid tag
[denied by valid-image-tag] image 'hashicorp/http-echo:latest' uses latest tag): error when creating
"deployment.yaml": admission webhook "validation.gatekeeper.sh" denied the request:
[denied by deployment-must-have-labels] you must provide labels: {"project"}
[denied by valid-image-tag] image 'hashicorp/http-echo' doesn't specify a valid tag
[denied by valid-image-tag] image 'hashicorp/http-echo:latest' uses latest tag

意料之中的创建失败。只有修改 YAML，合规之后才能通过。

总结

Conftest 和 Gatekeeper 都是用 Rego 语言定义策略的，这两个工具结合起来就能覆盖集群内外的校验要求了。

正如你所见，Conftest 的 Rego 策略需要做点修改才能用在 Gatekeeper 里。Konstraint 项目可以解决这个问题。该工具能把 Conftest 策略转换为 Gatekeeper 的 ConstraintTemplate 和 Constraint，并且它还能方便地对策略进行测试。

除了本文的两个工具之外，集群内外的策略检查都还有别的选择。它们的主要优势就是使用了通用的 Rego 语言。例如 Polaris 同时提供了集群内外的校验功能。然而它使用的是基于 JSON 的策略描述方法，其表达能力远弱于 Rego。

容器化囧途——没上容器时好好的？

Fri, 12 Jun 2020 03:08:20 +0800

如果寿司店老板说，有一种人叫寿司人，寿司人的一切都是为了吃寿司，寿司人比别的人都厉害，你肯定会嗤之以鼻；云厂商提出了云原生概念，倒是拥趸甚多——这是因为云比寿司好吃多了，它提供的好处，足以让人铤而走险，削减脑袋挤上云计算的车，这也就是业务上云了。

从参与《Kubernetes 权威指南》第二版到现在已经好几年了，在几年的容器化、云原生的推动过程中，因为一直从事企业服务的勾当，这个小视野里的绝大多数应用，都是证明可以成功容器化的。有一句很著名的程序员语录：“在我机器上是好的”，在推动应用上云的过程中，我听到的最多的噪音就是：没上容器时候是好的。

”在我机器上是好的“的原因应该说是很清楚的——环境失控、或者应用没有适应能力。Kubernetes 和各种公有云都很成熟，就先不展开环境问题了，说说应用自身需要回答的几个很直白的问题。

你的应用敢重启吗

容器本身是易失的，而在微服务设计中也强调了一点——面向故障的设计，不敢重启的应用，一定意义上就意味着该应用并无应对故障的准备。容器的重启和漂移，对这种应用来说，会有灾难性后果。

你的应用依赖清晰么

从面向对象到微服务，都不断地在强调，高内聚、低耦合、面向契约等等等等，这些名词都在倡导一种有清晰边界，有明确接触方式的应用实现方法。没有明确依赖关系的应用，连正常的割接、移机、扩展都会有巨大风险，更不要说从主机环境迁移到容器云上了。

你了解应用的资源使用情况么

很多计算资源宽裕的企业，对应用运行过程中的资源使用毫不在意，这种情况在上容器时会造成巨大的困扰——毕竟一般不会提供一个 64G 内存的容器。CPU、内存、IO、网络等需求，在容器化的过程中，都需要有个清楚的摸查。

你的应用可观测么

完善的应用框架都会提供一系列的观测支持、包括调用跟踪、资源报表、日志输出、健康检查、服务监控等。不过也有不少应用并没有重视这方面的东西、或者错误使用。比如常见的把进程存活或者端口监听当做健康检查的标准、或者模糊不清的日志输出，这些观测性的缺憾，最终都会成为容器化的缺憾。

你的应用的可用性需求明确么

很多用户受到误导，以为上了云，会自动漂移的应用就能够 N 个 9 了，事实上容器平台或者公有云对应用高可用的支持也是有限度的，应用自身对高可用的需求、运行平台在高可用方面的支持应该有一个全面的了解，并据此相互配合达成可用性目标。

也算结论

容器不是拦路虎，它是照妖镜，从 Dockerfile 到 YAML，再到 DevOps 和不可变环境，都对应用提出了更高的要求。赶不上容器末班车的原因可能是——你太慢了。

Kubernetes 中 HostPath 的风险和防范

Tue, 02 Jun 2020 23:48:48 +0800

Kubernetes 的安全问题，被提及比较多的一般包括几个点：

Docker & Kubernetes 参数加固
RBAC
Root 镜像
特权容器

众所周知，很多安全问题是爆发在内部的，因此有了零信任的说法。内网能够比较容易地接触在成功接触集群之后，仅仅通过对 HostPath 的使用，就有机会对集群和运行其上的工作负载进行窥探，甚至进行写入操作。

下面会分为三个部分，分别介绍可能接触集群的方法，入侵危害、以及建议的防范手段。

接触集群

要入侵一个集群，通常需要用某种方式和集群进行接触，通常方式有几种：

意外暴露无鉴权的明文端口

部分集群管理员为了方便访问，或者其他历史遗留原因，选择使用无鉴权的 API Server，或者暴露 Kubelet 的只读端口。

意外暴露 Dashboard 类服务

很多同学偏爱图形化的 Dashboard 服务，这类服务通常需要有较高的授权级别，可以运行较多的管理任务。

安装恶意应用

现在很多软件使用 curl | kubectl -f - 的形式进行快速安装，对于有外网访问能力的 Kubernetes 集群来说，不加验证的运行未知应用，随时处于引狼入室的威胁之中。

Kubeadm 安装后会缺省提供一个 admin.conf 文件，其中包含了集群管理员身份的客户端证书，能够完全控制集群。

公有云账号

GKE、AKS 等集群环境，其 Kubernetes 账号是来自公有云的，因此公有云对容器集群具有全权处置的能力，其中也包含生成集群管理员的能力。

建议严格管理公有云相关账号，根据使用责任对不同系统进行分离。

入侵危害

敏感文件

Pod 中加载了敏感文件之后，可能通过 cp 获取这些文件，甚至还可以尝试使用 exec 进行写入工作。随便举几个例子：

/etc
/root
/var/lib

这些位置的文件包含了身份证书、信任链、各种配置文件，被读取，破坏、甚至被篡改会发生什么呢？

服务发现

以 Pod 为基础，能够访问集群内的各种服务，进一步扩散影响范围。

防范

使用 PSP 或者 OPA/Kyverno 等策略工具，限制 hostPath 的加载，必须加载的，也应该控制在指定目录。
控制镜像来源，杜绝不明来源的镜像进入集群。
启用审计策略。
/etc/kubernetes/*、~/.kube 设置权限为 600。
管理员身份的 kubeconfig 文件应该单独存放。如有可能，应该使用 OIDC 等第三方进行登录。
使用 RBAC 为特定职责的用户开放最小权限，严格控制 exec attach portforward 等权限。
Kubelet、APIServer 的明文端口必须关闭。
使用网络策略，防止未经明确放行的服务访问。

Kubernetes 的授权和审计

Sun, 24 May 2020 22:51:33 +0800

Kubernetes 中的账号和认证，除了基础的双向证书认证之外，还有 OIDC 等方式的第三方集成能力，这里暂且不提。这里主要想谈谈授权和审计方面的内容。

很多 Kubernetes 集群，都是一个 cluster-admin 走天下的，这和 Linux 里面只使用一个 root 账号一样，因此要完成授权和审计任务，首先需要创建的东西就是一个新用户。

在使用本地证书进行用户管理的情况下，创建新用户通常有这样几种方法：

创建一个新的 ServiceAccount，使用 SA 的 Token 进行认证。
使用 Kubernetes 所使用的 CA，签发新的客户端证书。
创建 CSR，提交到 Kubernetes 上，通过后，获取客户端证书。

上面几个方法，完成后生成 kubeconfig 文件，并使用 RBAC 为新用户进行最小化授权，就可以用这些新用户的身份来完成“普通”用户的操作了。

在 Kubeadm 中启用审计

Kubeadm 的配置文件中加入如下内容：

apiServer:
  extraArgs:
    audit-log-path: /var/log/k8s/audit.log
    audit-policy-file: /etc/kubernetes/audit.yaml
    audit-log-maxage: "1"
    audit-log-maxsize: "100"
    audit-log-maxbackup: "1"
  extraVolumes:
  - name: audit-config
    hostPath: /etc/k8s/audit.yaml
    mountPath: /etc/kubernetes/audit.yaml
    readOnly: true
    pathType: File
  - name: audit-log
    hostPath: /var/log/k8s
    mountPath: /var/log/k8s

这个文件中指定了两个加载卷，分别用于存储配置文件和审计日志。API Server 会据此进行审计配置并输出日志。官方提供了审计策略的配置样例：

apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
  - "RequestReceived"
rules:
  - level: None
    verbs: ["get", "list", "watch"]
  # Log pod changes at RequestResponse level
  - level: RequestResponse
    resources:
    - group: ""
      # Resource "pods" doesn't match requests to any subresource of pods,
      # which is consistent with the RBAC policy.
      resources: ["pods"]
  # Log "pods/log", "pods/status" at Metadata level

有了 RBAC + 审计，结合专人专用的操作账户，我们就能够对用户在集群上的操作有个初步的了解，例如如下记录：

...
  "requestURI": "/apis/apps/v1/namespaces/default/deployments",
  "verb": "create",
  "user": {
    "username": "commonuser",
    "groups": [
      "dev",
      "system:authenticated"
    ]
  }
...

就代表用户 commonuser 新建了一个 Deployment。审计信息中还包括了事件发生的时间、IP、当时的 RBAC 角色等。

把审计日志汇总到 Elasticsearch 或者 Loki 之中，就能够获得集群范围内的所有我们关注的记录的操作了。

为 Kubeadm 集群启动 PSP

RBAC 决定一个用户能够操作什么资源（例如 Pod、Deployment、Service、SA 等），能够如何操作（例如创建、删除），而 PSP 则确定了 Pod 自身所能完成的任务：例如加载主机卷、使用 sysctl 等。

启动 PSP 是个相对来说较危险的操作。首先要做的就是获取现在运行之中的应用所使用的策略，并将策略涉及的权限和当前使用的 ServiceAccount 对应起来，简单说来步骤如下：

遍历运行中的 Pod，获取其中的特权情况，以及当前使用的 ServiceAccount。
根据特权情况编写 PodSecurityPolicy 策略。
为策略设置 Role 或者 ClusterRole，绑定到 ServiceAccount。

Krew 有个 psp-advice 插件，能完成上面的前两个步骤——形成单一的 PSP 对象，相对来说有些粗放。例如使用这个插件在一个启动了 Calico 的 Kubeadm 集群上生成的 PSP（kubectl advise-psp inspect）：

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  creationTimestamp: null
spec:
  allowedHostPaths:
  - pathPrefix: /lib/modules
    readOnly: true
  - pathPrefix: /var/lib/calico
    readOnly: true
  - pathPrefix: /opt/cni/bin
    readOnly: true
  - pathPrefix: /var/run/nodeagent
    readOnly: true
  - pathPrefix: /var/lib/cni/networks
    readOnly: true
  - pathPrefix: /usr/libexec/kubernetes/kubelet-plugins/volume/exec/nodeagent~uds
    readOnly: true
  - pathPrefix: /run/xtables.lock
    readOnly: true
  - pathPrefix: /etc/cni/net.d
    readOnly: true
  - pathPrefix: /var/run/calico
    readOnly: true
  fsGroup:
    rule: RunAsAny
  hostNetwork: true
  hostPorts:
  hostPorts:
  - max: 0
    min: 0
  privileged: true
  runAsUser:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - hostPath
  - secret
  - configMap

我们可以简单的为这个 PSP 生成一个 Role，并绑定到当前运行的 SA 上：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kube-system-psp
  namespace: kube-system
rules:
- apiGroups:
  - extensions
  resourceNames:
  - kube-system
  resources:
  - podsecuritypolicies
  verbs:
  - use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kube-system-psp
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kube-system-psp
subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system
- kind: ServiceAccount
...

完成所有步骤之后，在 API Server 的 --enable-admission-plugins 参数里面加入 PodSecurityPolicy，重新启动服务即可。

接下来就可以使用 PSP 为各个不同的 SA、用户创建角色，确定各种情况下创建 Pod 的安全策略，例如绝大多数业务 Pod 是无需使用特权模式、HostNetwork 的。

结论

各司其职是个基础，在 RBAC/PSP 支持下，能够比较容易的针对用户、ServiceAccount、Namespace 进行细粒度的权限控制，例如对各种资源的操作权限、对 Pod 的日志、Exec 等操作、以及 Pod 自身的卷加载、特权申请等都可以进行控制，并且还可以通过审计功能进行事后追溯。

Kubernetes 中的 Pod 安全策略

Sun, 03 May 2020 10:29:06 +0800

很多人分不清 SecurityContext 和 PodSecurityPolicy 这两个关键字的差别，其实很简单：

SecurityContext 是 Pod 中的一个字段，而 PSP 是一个独立的资源类型。
SecurityContext 是 Pod 自身对安全上下文的声明；而 PSP 则是强制实施的——不合规矩的 Pod 无法创建。

PSP 的用法和 RBAC 是紧密相关的，换句话说，应用 PSP 的基础要求是：

不同运维人员的操作账号需要互相隔离并进行单独授权。
不同命名空间，不同 ServiceAccount 也同样要纳入管理流程。

PSP 环境下，运维人员或者新应用要接入集群，除了 RBAC 设置之外，还需要声明其工作范围所需的安全策略，并进行绑定，才能完成工作。

PSP 的官方文档中提到，PSP 是通过 Admission Controller 启用的，并且注明了：启用 PSP 是一个有风险的工作，未经合理授权，可能导致 Pod 无法创建。

开始之前，首先设置一个别名，在 default 命名空间新建 ServiceAccount 来模拟一个有权创建 Pod 的用户：

$ kubectl create sa common
serviceaccount/common created

$ kubectl create rolebinding common --clusterrole=edit --serviceaccount=default:common
rolebinding.rbac.authorization.k8s.io/common created

$ alias kube-common='kubectl --as=system:serviceaccount:default:common'

第一个 PSP

我们首先创建一个不允许创建特权 Pod 的策略：

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: noprivileged
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

保存为 psp.noprivileged.yaml 并提交给集群。

接下来创建两个 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: noprivileged
spec:
  containers:
  - name: pause
    image: k8s.gcr.io/pause
---
apiVersion: v1
kind: Pod
metadata:
  name: privileged
spec:
  containers:
  - name: pause
    image: k8s.gcr.io/pause
    securityContext:
      privileged: true

用普通用户创建这个 Pod：

$ kube-common apply -f pod.yaml && kube-common delete -f pod.yaml
pod/noprivileged created
pod/privileged created
pod "noprivileged" deleted
pod "privileged" deleted

可以看到，在不允许创建特权容器的规则之中，我们的用户还是能够创建特权容器，这是因为还没启用 PSP，接下来在集群设置中启动 PSP，各种环境的启用方式不同，例如在 GKE 环境：

$ gcloud beta container clusters update gcp-k8s --enable-pod-security-policy --zone=asia-east1-a
Updating gcp-vlab-k8s...done.

删除重建 Pod：

$ kube-common apply -f pod.yaml && kube-common delete -f pod.yaml
Error from server (Forbidden): error when creating "pod.yaml": pods "noprivileged" is forbidden: unable to validate against any pod security policy: []
Error from server (Forbidden): error when creating "pod.yaml": pods "privileged" is forbidden: unable to validate against any pod security policy: []

可以看到，Pod 的新建请求被拒绝了——然而使用集群管理员身份还是能成功创建的：

$ kubectl apply -f pod.yaml && kubectl delete -f pod.yaml
pod/noprivileged created
pod/privileged created
pod "noprivileged" deleted
pod "privileged" deleted

全员 admin 是万恶之源。

用 RBAC 进行授权：

$ kubectl create role psp:noprivileged \
    --verb=use \
    --resource=podsecuritypolicy \
    --resource-name=noprivileged
role.rbac.authorization.k8s.io/psp:noprivileged created

$ kubectl create rolebinding common:psp:noprivileged \
    --role=psp:noprivileged \
    --serviceaccount=default:common
rolebinding.rbac.authorization.k8s.io/common:psp:noprivileged created

再试试普通用户的能力：

$ kube-common apply -f pod.yaml ; kube-common delete -f pod.yaml
pod/noprivileged created
Error from server (Forbidden): error when creating "pod.yaml": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]
pod "noprivileged" deleted
Error from server (NotFound): error when deleting "pod.yaml": pods "privileged" not found

非特权 Pod 才能够成功创建，这符合我们的预期。

副作用

Pod 成功创建了之后，顺理成章，做个 Deployment 看看：

kind: Deployment
metadata:
  name: privileged
spec:
  replicas: 1  
  template:
    metadata:
      labels:
        app: pause
        version: v1
    spec:
      containers:
      - name: sleep
        image: k8s.gcr.io/pause
        securityContext:
          privileged: true
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: noprivileged
spec:
  replicas: 1
  template:
    serviceAccount: common
    metadata:
      labels:
        app: pause
        version: v1
    spec:
      containers:
      - name: sleep
        image: k8s.gcr.io/pause

我们会发现，Deployment 无法正常工作：

$ kubectl get pods
kuNo resources found in default namespace.
$ kubectl get deployment
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
noprivileged   0/1     0            0           15m
privileged     0/1     0            0           15m

查看一下事件：

$ kubectl get events | grep policy
8m38s       Warning   FailedCreate        replicaset/noprivileged-6f94f9c9b8                 Error creating: pods "noprivileged-6f94f9c9b8-" is forbidden: unable to validate against any pod security policy: []
8m38s       Warning   FailedCreate        replicaset/privileged-6d78d5458                    Error creating: pods "privileged-6d78d5458-" is forbidden: unable to validate against any pod security policy: []

这次的 Pod 不是由我们授权的 common 用户创建的，而是由 RS Controller 启动的，因此会失败，加入一个 Service Account：

...
    spec:
      serviceAccount: common
      containers:
...
    spec:
      serviceAccount: common
      containers:
...

提交变更，会发现非特权 Pod 开始创建：

$ kubectl get pods
NAME                            READY   STATUS    RESTARTS   AGE
noprivileged-6cf595c5bd-rc8cx   1/1     Running   0          4s

系统 Pod 怎么办

这时候我想到个问题，其它 Pod 会不会受到影响？我删除了 kube-system 下面的一个 kube-proxy 的 Pod，发现这个 Pod 自动重建了，没有受到 PSP 的影响，查看一下 RBAC 相关配置，会发现 GCP 在更新集群的过程中已经为系统服务进行了预设：

$ kubectl get rolebinding
...
gce:podsecuritypolicy:kube-proxy                    80m
gce:podsecuritypolicy:metadata-agent                80m
gce:podsecuritypolicy:metadata-proxy                80m
gce:podsecuritypolicy:nodes                         80m
...

追查下去：

$ kubectl get rolebinding gce:podsecuritypolicy:metadata-proxy -o yaml
...
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: gce:podsecuritypolicy:privileged
subjects:
- kind: ServiceAccount
  name: metadata-proxy
  namespace: kube-system

如果追查其中涉及到的 ClusterRole，会发现它指向一个 PSP：

$ kubectl get clusterrole gce:podsecuritypolicy:privileged -o yaml
...
rules:
- apiGroups:
  - policy
  resourceNames:
  - gce.privileged
  resources:
  - podsecuritypolicies
  verbs:
  - use

看看这个 PSP 的内容：

$ kubectl get psp  gce.privileged -o yaml
...
    privileged: true
...

的确包含了特权 Pod 的内容。

最后看看负责创建这个特权 Pod 的 Daemonset：

$  kubectl get daemonset  metadata-proxy-v0.1 -o yaml
...
      serviceAccount: metadata-proxy
      serviceAccountName: metadata-proxy
...

PSP 的限制能力

分为以下几个大方面：

特权容器
主机命名空间：例如 HostPID、HostNetwork 等。
卷和文件系统：例如 PVC、configMap、emptyDir 等卷类型，以及 fsGroup、AllowedHostPaths 等加载能力。
用户和组：运行身份
提权：是否允许
Capability 和 sysctl
SeLinux、AppArmor 等。

马后炮

kubectl 的 advise-psp 插件，能够根据当前运行的 Pod，提取出所需的 PSP 信息。

参考链接

https://kubernetes.io/docs/concepts/policy/pod-security-policy/

镜像是怎样炼成的

Fri, 24 Apr 2020 08:45:50 +0800

作者：Nicola Apicella

原文：How are docker images built? A look into the Linux overlay file-systems and the OCI specification

要使用 Docker，就不可避免地要和 Docker 镜像打交道。本文将会讲述 Docker 镜像的基石： Overlay 文件系统。首先我会简单介绍一下这个文件系统，接下来会看看如何把这个技术用在 Docker 镜像上，以及 Docker 是怎样从 Dockerfile 构建出 Docker 镜像的。最后还会介绍分层缓存以及 OCI 格式的容器镜像。

遵循我的一贯风格，我会尽可能的让本文具备更好的操作性。

Overlay 文件系统是什么

Overlay 文件系统（也被称为联合文件系统），能够使用两个或更多的目录创建一个联合：它由低层和高层的目录组成。文件系统中低层的目录是只读的，而高层的文件系统则是可读可写的。我们可以试试加载一个，看看操作效果。

创建 Overlay 文件系统

我们可以创建几个目录然后把它们联合起来。首先会创建一个叫做 “mount” 的目录，我们将它作为这个联合的父目录。接下来会创建 “layer-1”、“layer-2”、“layer-3”、“layer-4” 着几个目录。最后还要创建一个叫做 “workdir” 的目录， Overlay 文件系统必须有这个目录才能正常工作。

这些目录可以随意命名，不过 “layer-1”、“layer-2” 这样的命名方式，和 Docker 镜像对比起来会比较容易理解。


$ cd /tmp && mkdir overlay-example && cd overlay-example

[2020-04-19 16:02:35] [ubuntu] [/tmp/overlay-example]  
> mkdir mount layer-1 layer-2 layer-3 layer-4 workdir

[2020-04-19 16:02:38] [ubuntu] [/tmp/overlay-example]  
$ ls
layer-1  layer-2  layer-3  layer-4 mount  workdir

然后要在除 “layer-4” 之外的每个目录下创建文件，这个步骤也不是必要的，只是为了更像镜像：

[2020-04-19 16:02:40] [ubuntu] [/tmp/overlay-example]  
$ echo "Layer-1 file" > ./layer-1/some-file-in-layer-1

[2020-04-19 16:03:36] [ubuntu] [/tmp/overlay-example]  
$ echo "Layer-2 file" > ./layer-2/some-file-in-layer-2

[2020-04-19 16:03:53] [ubuntu] [/tmp/overlay-example]  
$ echo "Layer-3 file" > ./layer-3/some-file-in-layer-3

我们来挂载这个文件系统：

sudo mount -t overlay overlay-example \
-o lowerdir=/tmp/overlay-example/layer-1:/tmp/overlay-example/layer-2:/tmp/overlay-example/layer-3,upperdir=/tmp/overlay-example/layer-4,workdir=/tmp/overlay-example/workdir \
/tmp/overlay-example/mount

看看挂载目录的内容：

[2020-04-19 16:13:28] [ubuntu] [/tmp/overlay-example]  
> cd mount/

[2020-04-19 16:13:31] [ubuntu] [/tmp/overlay-example/mount]  
> ls -la
total 20
drwxr-xr-x 1 napicell domain^users 4096 Apr 19 16:07 .
drwxr-xr-x 8 napicell domain^users 4096 Apr 19 16:07 ..
-rw-r--r-- 1 napicell domain^users   13 Apr 19 16:03 some-file-in-layer-1
-rw-r--r-- 1 napicell domain^users   13 Apr 19 16:03 some-file-in-layer-2
-rw-r--r-- 1 napicell domain^users   13 Apr 19 16:03 some-file-in-layer-3

不出所料，前三层的文件都被加载到了挂载根目录。可以看到我们之前写入文件的内容：

$ cat some-file-in-layer-3
Layer-3 file

试试创建文件

$ echo "new content" > new-file

$ ls
new-file  some-file-in-layer-1  some-file-in-layer-2  some-file-in-layer-3

新文件在哪里呢？自然是在上层，我们的例子里就是 “layer-4”：

 [2020-04-19 16:23:49] [ubuntu] [/tmp/overlay-example]  
 pactvm > tree
.
├── layer-1
│   └── some-file-in-layer-1
├── layer-2
│   └── some-file-in-layer-2
├── layer-3
│   └── some-file-in-layer-3
├── layer-4
│   └── new-file
├── mount
│   ├── new-file
│   ├── some-file-in-layer-1
│   ├── some-file-in-layer-2
│   └── some-file-in-layer-3
└── workdir
    └── work [error opening dir]

7 directories, 8 files

试试看删除文件：

[2020-04-19 16:27:33] [ubuntu] [/tmp/overlay-example/mount]  
> rm some-file-in-layer-2

[2020-04-19 16:28:58] [ubuntu] [/tmp/overlay-example/mount]  
> ls
new-file  some-file-in-layer-1  some-file-in-layer-3

你猜猜，原始文件系统中的 “layer-2” 目录会怎么样：

 [2020-04-19 16:29:57] [ubuntu] [/tmp/overlay-example]  
 pactvm > tree
.
├── layer-1
│   └── some-file-in-layer-1
├── layer-2
│   └── some-file-in-layer-2
├── layer-3
│   └── some-file-in-layer-3
├── layer-4
│   ├── new-file
│   └── some-file-in-layer-2
├── mount
│   ├── new-file
│   ├── some-file-in-layer-1
│   └── some-file-in-layer-3
└── workdir
    └── work [error opening dir]

7 directories, 8 files

“layer-4” 中出现了个新文件 “some-file-in-layer-2”。奇怪的是这个文件的属性（”Character file“），这种文件在 Overlay 文件系统中被称为 ”Whitout“，用于表达被删除的文件。

 [2020-04-19 16:31:09] [ubuntu] [/tmp/overlay-example/layer-4]  
 pactvm > ls -la
total 12
drwxr-xr-x 2 napicell domain^users 4096 Apr 19 16:28 .
drwxr-xr-x 8 napicell domain^users 4096 Apr 19 16:07 ..
-rw-r--r-- 1 napicell domain^users   12 Apr 19 16:23 new-file
c--------- 1 root     root         0, 0 Apr 19 16:28 some-file-in-layer-2

完成之后，卸载这个文件系统，然后删除目录：

[2020-04-19 16:37:11] [ubuntu] [/tmp/overlay-example]  
$ sudo umount /tmp/overlay-example/mount && rm -rf *

理顺概念

正如开篇所说， Overlay 文件系统上可以把多个目录联合在一起。在前边的例子里，这个联合过程由 “layer-{1,2,3,4}” 在 “mount” 目录里组成。对文件的修改、创建和删除都在上层发生——也就是这里的 “layer-4”，因此这一层也被称为差异层。上层的文件会对下层文件造成遮盖。假设 “layer-2” 和 “layer-1” 中，在相同的相对目录下有同名的文件，那么在 “mount” 目录中就会以 “layer-2” 为准。下一节将会看看这一技术在 Docker 镜像中的应用。

什么是 Docker 镜像

简单总结，Docker 镜像就是一个 Tar 文件，其中包含一个根文件系统和一些愿数据。你可能听说过，Dockerfile 中的每一行都会生成一个层。例如下面的代码就会生成一个三层的镜像：

FROM scratch
ADD my-files /doc
ADD hello /
CMD ["/hello"]

“docker run” 的过程很复杂，但是本文中只会关注和镜像有关的一点点内容。概括的说，Docker 会下载这个文件包，把每个层解压到单独的目录中，然后用 Overlay 文件系统将这些目录以及用于进行写入的一个上层空目录联合起来。当你在容器中进行修改、创建或者删除操作时，这些变更都会保存到这个空目录中。容器退出时，Docker 会清理这个目录——这就是在容器中的变更无法保持的原因。

层缓存

要运行容器，就要构建镜像，Docker 将这两个步骤分离开来独立运作，是它得以流行的重要原因。OCI 就是业界公认的规范。

OCI 当前包括两个规范：运行规范和镜像规范。运行规范描述了如何运行一个解压到磁盘上的 “复合文件系统” 。简单说来，OCI 实现会把 OCI 镜像下载回来，然后解压到一个 OCI 运行时复合文件系统之中。这一操作完成后就可以让 OCI 运行时运行了。

标准化的意义就是让其他人可以自己开发容器的构建工具和运行时。例如 jess/img、Buildah 以及 Skopeo 都是可以脱离 Docker 构建镜像的工具。类似地还有很多容器运行时，例如 runc（Docker 使用）和 rkt。

其他的 Overlay 文件系统

Docker 能够使用的联合文件系统不止这一种。任何有差异层和联合特性的文件系统都是可能的候选者。例如 Docker 还能运行在 aufs、btrfs、zfs 和 devicemapper 系统上。

构建镜像时发生了什么

假设我们要使用下面的 Dockerfile 来构建镜像：

FROM ubuntu
RUN apt-get update
...

简单描述一下这个过程：

Docker 下载 FROM 语句中指定的 tar 文件，这是目标镜像的第一层。
加载一个联合文件系统，其底层就是刚下载的部分，在上面创建一个空目录。
在 chroot 中启动一个 bash，运行 RUN 语句中的命令：RUN: chroot . /bin/bash -c "apt get update"。
命令结束后，会把上层目录压缩，形成新镜像中的新的一层。
如果 Dockerfile 中包含其它命令，就以之前构建的层次为基础，从第二步开始重复创建新层，直到完成所有语句后退出。

上述过程是个极度简化的过程，其中缺乏一些常见指令，例如 ENTRYPOINT、ENV 等。这些内容会被写入元数据，和文件层封装在一起。

结论

这种将根文件系统和每个差异层都进行打包的思路非常强大。它不仅是 Docker 的基础，我想还能用在其它一些领域里，以后可能会诞生更多这类工具。

在 Kubernetes 上用 Krustlet 调度 WASM

Tue, 14 Apr 2020 12:42:59 +0800

前言

坊间有两个传言：

Kubernetes 正在成长为一个统一调度器
WASM 如果早点成气候，就没 Docker 什么事了

Krustlet 往前踏了一小步：他的官方描述是“Kubernetes Kubelet in Rust for running WASM”——使用 Rust 实现的 Kubelet，可以在 Kubernetes 中运行 WASM。

Krustlet 是 Deis 实验室的产品，算是 Helm 的同门师兄弟。

项目还非常初期，包括镜像拉取、Pod 生命周期等功能都没能完整实现，只能作为一个概念方面的尝试。

部署

官方提供了 EKS、AKS 以及 Kind 的部署方案，这里我们使用 Kind 进行部署。使用如下配置文件定义一个三节点集群：

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
- role: worker

$ kind create cluster --config=config-3-node.yaml
Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.17.0) 🖼
 ✓ Preparing nodes 📦 📦 📦 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾

集群启动之后，就可以安装 Krustlet 了。

踩坑过程中，注意到 Krustlet 的几个依赖项目：

Openssl 1.1.x 支持，所以有些老系统可能需要升级；
接入 Krustlet 时，需要满足接入新节点的 Kubernetes 权限要求；
Krustlet 和 Kubelet 一样，也要使用 kubeconfig 文件进行认证。

在 Release 页面可能找到压缩包下载，目前支持 Linux 和 MacOS 两个平台。

解压之后，创建 ~/.krustlet/lib 目录，将压缩包中的 *.so 和 *.dylib 复制到 ~/.krustlet/lib 之中，可执行文件复制到 /usr/local/bin

接下来为 krustlet 准备用于加入 Kubernetes 的证书：

#!/bin/sh
mkdir -p ~/.krustlet/config
cd ~/.krustlet/config
openssl req -new -sha256 -newkey rsa:2048 -keyout krustlet.key -out krustlet.csr -days 365 -nodes -subj "/C=US/ST=./L=./O=./OU=./CN=krustlet"
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
  name: krustlet
spec:
  request: $(cat krustlet.csr | base64 | tr -d '\n')
  usages:
  - digital signature
  - key encipherment
  - server auth
EOF
kubectl certificate approve krustlet
kubectl get csr krustlet -o jsonpath='{.status.certificate}' | base64 --decode > krustlet.crt
openssl pkcs12 -export -out certificate.pfx -inkey krustlet.key -in krustlet.crt -password "pass:password"

启动

启动过程很简单：

$ krustlet-wasi  --pfx-password password --node-ip 10.89.81.61
[2020-04-14T06:16:34Z ERROR kubelet::kubelet] Error handling event: error decoding response body: missing field `access_token` at line 1 column 501
[2020-04-14T06:18:04Z ERROR kubelet::kubelet] Error handling event: error decoding response body: missing field `detail` at line 1 column 119
[2020-04-14T06:28:37Z ERROR kubelet::kubelet] Error handling event: error decoding response body: missing field `detail` at line 1 column 119

其中的 --node-ip 参数是可选的，在 Docker for OS X 中，需要用 ifconfig en0 确定一下适配器 IP，如果是在物理机/虚拟机环境中，这个参数可以省略或者根据实际情况做出调整。

是的你没看错，启动就出了点小问题。接下来看看节点情况：

$ kubectl get nodes
NAME                 STATUS   ROLES    AGE    VERSION
kind-control-plane   Ready    master   136m   v1.17.0
kind-worker          Ready    <none>   136m   v1.17.0
kind-worker2         Ready    <none>   136m   v1.17.0
kind-worker3         Ready    <none>   136m   v1.17.0
abcd-mb0       Ready    agent    111m   v1.17.0

看看节点的情况：

$ kubectl describe nodes abcd-mb0
...
Taints:             krustlet/arch=wasm32-wasi:NoExecute
...
System Info:
  Machine ID:
  System UUID:
  Boot ID:
  Kernel Version:
  OS Image:
  Operating System:           linux
  Architecture:               wasm-wasi
  Container Runtime Version:  mvp
  Kubelet Version:            v1.17.0
  Kube-Proxy Version:         v1.17.0
...
  Operating System:           linux
  Architecture:               wasm-wasi
  Container Runtime Version:  mvp
...

可以看到有很多信息是缺失的，说明项目的确很早期。

Taints 字段的定义，要求特定 Pod 才能调度到该节点上。

最后其架构显示的是 wasm-wasi。

运行一个 Pod

编写一个 YAML 文件：

apiVersion: v1
kind: Pod
metadata:
  name: krustlet-tutorial
spec:
  containers:
    - name: krustlet-tutorial
      image: webassembly.azurecr.io/hello-world-wasi-rust:v0.1.0
      imagePullPolicy: Always
  tolerations:
    - key: "node.kubernetes.io/network-unavailable"
      operator: "Exists"
      effect: "NoSchedule"
    - key: "krustlet/arch"
      operator: "Equal"
      value: "wasm32-wasi"
      effect: "NoExecute"

镜像名好像很普通，Pull 一下：

$ docker pull webassembly.azurecr.io/hello-world-wasi-rust:v0.1.0
v0.1.0: Pulling from hello-world-wasi-rust
670adc713612: Pulling fs layer
invalid rootfs in image configuration

看来这个镜像并不普通。。后面会讲一下。

Pod 定义中声明了 tolerations，让该 Pod 可以在新节点上运行。提交 yaml 之后，可以看到 Pod 运行：

$ kubectl get pods -w
NAME                READY   STATUS    RESTARTS   AGE
krustlet-tutorial   0/1     Pending   0          6s
krustlet-tutorial   0/1     Running   0          8s
krustlet-tutorial   1/1     Running   0       8s
krustlet-tutorial   0/1     ExitCode:0   0          8s

看到这个 Pod 飞快的完成了运行并成功退出，查看他的日志：

hello from stdout!
hello from stderr!
Args are: []

镜像

前面使用 docker pull 未能成功下载，这是因为这个镜像其实是一个封装为 OCI 的 WASM，可以使用 was-to-oci 工具下载，并使用 wasmtime 尝试运行：

$ wasm-to-oci pull registry.microservice.rocks/module-wasm:v1
INFO[0007] Pulled: registry.microservice.rocks/module-wasm:v1
INFO[0007] Size: 1964621
INFO[0007] Digest: sha256:670adc7136128af3a2848d86c18013b1009e7dedb8a686ecacda175094aa083c

完成后可以看到当前目录出现了一个 module.wasm 文件，运行一下：

$ wasmtime module.wasm
hello from stdout!
hello from stderr!
Args are: ["module.wasm"]

反过来，也可以使用这个工具把 WASM 文件推送到镜像库中。例如：

$  wasm-to-oci push module.wasm registry.microservice.rocks/module-wasm:v1
INFO[0001] Pushed: registry.microservice.rocks/module-wasm:v1
INFO[0001] Size: 1964621
INFO[0001] Digest: sha256:54b09224f004231ffb37d14ac478a101d94c58aac93b8da7b67ed84147763d09

玩后感

目前 Krustlet 对 Docker Registry 的支持似乎是有问题的，因此无法运行我们自己用 wasm-to-oci 推送到私库的 WASM。网络通信等内容也就无法测试了。好在目前版本只是 0.1.0，还有很多值得一等。

自己的 Kubernetes 控制器（3）——改进和部署

Mon, 13 Apr 2020 16:21:32 +0800

我们在前面讲述了 Kubernetes 控制器的概念。简单说来控制器就是个控制回路，用来将当前状态协调到目标状态。第二篇使用 Java 实现了一个控制器。这一篇会讲讲如何部署控制器，以及如何对控制器进行改进。

集群内外

在第一篇中提到过，控制器在集群内外都能运行，只要能够完成必要的通信过程就可以。缺省情况下，官方 Kubernetes 客户端和 Fabric8 客户端都会尝试使用 ~/.kube/config 配置中存储的凭据。也就是说只要使用 kubectl 命令能访问集群，就能运行这个控制器。

交付物可以是以下几种形式：独立的 JAR，应用服务器中部署的 WebApp，甚至是一个包含很多 Class 文件的目录。这种方法的缺点是，应该把所有与所选择的方法相关的常规任务都照顾到。

另一方面，用容器化应用的方式在 Kubernetes 集群中运行会有很多好处：自动化、监控、伸缩、自愈等。如此看来，没有不容器化的道理。因此我们要给我们的控制器进行容器化。

控制器的容器化

给 Java 应用进行容器化的最直接方式就是使用 Jib 插件。这个插件在 Maven 和 Gradle 中可用，兼容于普通应用、Spring Boot 和 Micronaut 应用；它生成的镜像会分为不同的层次：最上层是业务类，下面则是依赖库。这种构建方式加快了更新镜像的构建速度：当业务更新时，只需要更换最上面的层就可以了。

Jib 配置样例：

<plugin>
    <groupId>com.google.cloud.tools</groupId>
    <artifactId>jib-maven-plugin</artifactId>
    <version>1.8.0</version>
    <configuration>
        <from>
            <image>gcr.io/distroless/java:debug</image>
        </from>
        <to>
            <image>jvm-operator:${project.version}</image>
        </to>
    </configuration>
    <executions>
        <execution>
            <phase>compile</phase>
            <goals>
                <goal>dockerBuild</goal>
            </goals>
        </execution>
    </executions>
</plugin>

缺省镜像没有 Shell，为了方便调试，提供一个 debug Tag
目标镜像的标签来自于 POM
在 compile 阶段会运行插件。注意镜像并没有进行打包操作，因此 package 阶段可以跳过
可用的目标包括 build 和 dockerBuild。前者无需本地 Docker，并把镜像上传到 DockerHub；后者会把镜像构建到本地 Docker 中

到了这一步，写个 Kubernetes 配置就很容易了。

deploy.yml

apiVersion: v1
kind: Pod
metadata:
  namespace: jvmoperator
  name: custom-operator
spec:
  containers:
    - name: custom-operator
      image: jvm-operator:1.10
      imagePullPolicy: Never

上边的代码段偷懒声明了一个简单的 Pod。真实世界的配置会用 Deployment。

kubectl apply -f deploy.yml

不幸的是，这个命令会失败，输出下列内容：

java.net.ProtocolException: Expected HTTP 101 response but was '403 Forbidden'
  at okhttp3.internal.ws.RealWebSocket.checkResponse(RealWebSocket.java:229)
  at okhttp3.internal.ws.RealWebSocket$2.onResponse(RealWebSocket.java:196)
  at okhttp3.RealCall$AsyncCall.execute(RealCall.java:203)
  at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)

鉴权

这个错误仅在集群内运行时候发生，原因是权限不足。给 Kubernetes API 发送请求是个危险行为，缺省情况下每个请求都会返回错误。因此这个容器需要有合适的授权：

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  namespace: jvmoperator
  name: operator-example
rules:
  - apiGroups:
      - ""
    resources:
      - pods
    verbs:
      - watch
      - create
      - delete
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: operator-service
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: operator-example
subjects:
  - kind: ServiceAccount
    name: operator-service
    namespace: jvmoperator
roleRef:
  kind: ClusterRole
  name: operator-example
  apiGroup: rbac.authorization.k8s.io

Kubernetes 中用 RBAC 的方式进行鉴权。这方面的主题比较复杂，想要细致学习，可以参考相关文档。

提交上述代码后，这个 Pod 就能够使用新的 ServiceAccount 运行了——只要做一点简单的修改：

apiVersion: v1
kind: Pod
metadata:
  namespace: jvmoperator
  name: custom-operator
spec:
  serviceAccountName: operator-service
  containers:
    - name: custom-operator
      image: jvm-operator:1.8
      imagePullPolicy: Never

容器化 JVM 应用的隐患

早期版本的 JVM 会返回主机的 CPU 和内存数量，而不是容器的。JVM 尝试占用不存在的内存，会导致 OutOfMemoryError。Kubernetes 则会杀死行为异常的 Pod。如果被杀死 Pod 是 ReplicaSet 的一部分，就会新建一个 Pod。这个过程很不利联想。JDK 10 开始这个问题已经解决了（这个特性也被融合到 JDK 8 的新版本之中）。

JVM 能够根据工作负载来调整应用程序的编译代码，这是优于静态编译的原生可执行程序的。JVM 需要大量的额外内存来实现这一点。而且 JVM 的启动时间相当长。由于自适应编译后的代码需要时间，所以在启动后的一段时间内，性能都不会符合要求。这也是为什么在 JVM 上的性能指标总是要在较长的预热时间后再进行测量的原因。最后，与原生可执行文件相比，容器的大小要大得多，因为它嵌入了 JVM 本身。

REPOSITORY            TAG          IMAGE ID            CREATED             SIZE
jvm-operator          1.8          bdaa419c75e2        50 years ago        141MB

综上所述，JVM 并非容器化应用的好对象。

克服 JVM 的限制

有两种方式能够克服上述的 JVM 问题

使用 Java 9 中引入的模块系统，JDK 提供了一个思路，让原生可执行文件只包含引用到的模块，抛弃其它内容。这样就见效了可执行尺寸。
使用 Graal VM 的 Substrate VM

Substrate VM 是一个能够将 Java 预编译成可执行镜像的框架。

Graal VM 能帮助你：

把应用打包成单一的 JAR
从 JAR 创建原生可执行文件
把原生可执行文件进行容器化

不幸的是，Jib 没有 GraalVM 的配置。因此需要使用多阶段 Dockerfile：

构建 JAR
从 JAR 构建原生可执行文件

容器化

ARG VERSION=1.10

FROM zenika/alpine-maven:3 as build
COPY src src
COPY pom.xml pom.xml
RUN mvn package

FROM oracle/graalvm-ce:19.2.1 as native
ARG VERSION
COPY --from=build /usr/src/app/target/jvm-operator-$VERSION.jar \
              /var/jvm-operator-$VERSION.jar
WORKDIR /opt/graalvm
RUN gu install native-image \
&& native-image -jar /var/jvm-operator-$VERSION.jar \
&& mv jvm-operator-$VERSION /opt/jvm-operator-$VERSION

FROM scratch
ARG VERSION
WORKDIR /home
COPY --from=native /opt/jvm-operator-$VERSION operator
ENTRYPOINT ["./operator"]

Graal VM 发行版中缺省是不包括 Substrate VM 的，因此首先要进行安装
在前面步骤生成的 JAR 上执行 native-image 过程
使用 scratch 镜像为基础。在编译过程中使用 --static 选项打包，来包含所依赖的库

这样就缩减了镜像的尺寸：

REPOSITORY            TAG          IMAGE ID            CREATED             SIZE
jvm-operator          1.10         340d4d9a767e        6 weeks ago         52.7MB

Substrate VM 包含很多配置项目，为了达到上面的效果，需要这样的一组参数：

native-image.properties

Args=  -J-Xmx3072m \
       --static \
       --allow-incomplete-classpath \
       --no-fallback \
       --no-server \
       -H:EnableURLProtocols=https \
       -H:ConfigurationFileDirectories=/var/config

应对反射

AOT 过程在反射基础上还有诸多限制。根据底层代码的编写方式不同，可能会受到更多的影响。在不同状况之中，有不同的方法来解决这个问题。这些都将在以后的帖子中介绍：现在我们先来关注一下反射。

在 Java 中，一些底层代码或多或少依赖于基于运行时的反射。不幸的是，Substrate VM 会删除它认为不需要的代码。不过，这可以通过JSON文件来配置。鉴于依赖反射的调用量，手动配置是一项艰巨的任务。

Substrate VM 提供了一个更好的选择：它提供了一个 Java 代理，可以在运行中的控制器的命令行中设置。这个代理会拦截控制器应用程序内部的每一个反射调用，并将其记录在一个专门的 reflect-config.json 文件中。

在以后的阶段，这个文件（和其他类似的文件一起）可以反馈到编译过程中，这样通过反射访问的代码就会被保留下来。一种方法是通过命令行来送入它们。另一种是将它们打包到 JAR 里面，放在一个专门的文件夹里：这允许库的提供者提供与 AOT 兼容的 JAR，应该是首选的方式。

根据具体应用的不同，可能还会需要额外的步骤。更多信息，请参考：《How to cope with incompatible code in Graal VM AOT compilation》。

结论

三篇文章，我们讲述了 Kubernetes 控制器的实现方法。开发过程中我们看到，这并不是一项艰巨的任务。在这其中提到的技术基础之上，能够实现更多更好的功能。

最后我们在 Kubernetes 集群上运行了新开发的 Java 控制器。后续我们引入 Graal VM 创建了一个原生可执行文件。虽然它使构建过程更加复杂，但使用这样的原生可执行文件消除了 JVM 平台的一些限制：它大大减少了映像大小、内存消耗以及启动时间。

完整的源码可以在 Github 上找到

自己的 Kubernetes 控制器（2）——用 Java 开发

Mon, 13 Apr 2020 15:01:52 +0800

前面文章中，我们大概描述了开发自定义 Kubernetes 控制器的基础内容。其中我们提到，只要能够使用 HTTP/JSON 就可以满足开发需求。本文中就言归正传开始开发。

开发使用的技术栈可以 Python、NodeJS 或者 Ruby。我的博客叫“Java Geek”，所以这里选择的是 Java。

这个案例中我们使用 Sidecar 模式：每次有 Pod 调度，就生成一个并行的 Pod；当前面的 Pod 被删除，后面的 Pod 也随之删除。

选择合适的工具

为了在 Java 中调用 REST 接口，就首先要生成绑定的结构。有几种方式可以完成这项工作：

最无聊的方式就是手工完成：认真对待所有请求和响应的 JSON 数据，据此开发对应的 Java 对象，选择 JSON 序列化框架，以及 HTTP 客户端。
次选的方式是使用 Swagger 或者 APiary 这样的代码生成器：API 提供者需要使用某种方式来提供对应的模型，开发者使用相应工具来生成代码。
最好的方式是，已经有客户端库提供了绑定结构。

Kubernetes 属于第三种——它已经为多种语言提供了绑定代码。只不过这种语言封装和 REST API 非常相近，不太符合我的习惯。例如获取所有命名空间下所有 Pod 的代码：

ApiClient client = Config.defaultClient();
CoreV1Api core = new CoreV1Api(client);
V1PodList pods =
    core.listPodForAllNamespaces(null, null, null, null, null, null, null, null);

所有 null 都需要传递

这就是我所说的 和 REST API 非常相近，幸运的是，还有其他选项：Fabric8 在 Github 上提供了 Java API。等价代码：

KubernetesClient client = new DefaultKubernetesClient();
PodList pods = client.pods().inAnyNamespace().list();

不再需要无用的 null 参数。

Fabric8 概述

简单说来，Fabric8 API 里面，在 KubernetesClient 示例中可以获取所有 Kubernetes 资源：

client.namespaces()
client.services()
client.nodes()
等等

根据资源的特性，可以使用命名空间进行过滤：

client.pods().inAnyNamespace()
client.pods().inNamespace("ns")

列出所有命名空间的所有 Pod：

client.pods().inAnyNamespace().list();

删除命名空间 ns 中的所有 Pod：

client.pods().delete(client.pods().inNamespace("ns").list().getItems());

创建一个名为 ns 的命名空间：

client.namespaces()
  .createNew()
    .withApiVersion("v1")
    .withNewMetadata()
      .withName("ns")
    .endMetadata()
  .done();

实现控制回路

Kubernetes 控制器只是一个控制回路，它会监视集群状态，并尝试将其调整为目标状态。为了跟进调度和删除事件，就需要实现观察者模式。应用订阅事件，在事件发生时，调用相关的回调。

下面是一个简化版的类图：

实际实现代码：

public class DummyWatcher implements Watcher<Pod> {

  @Override
  public void eventReceived(Action action, Pod pod) {
    switch (action) {
      // 新 Pod
      case ADDED:
        break;
      // Pod 修改
      case MODIFIED:
        break;
      // Pod 删除
      case DELETED:
        break;
      // Pod 出错
      case ERROR:
        break;
    }
  }

  // 删除所有资源。如果客户端正确关闭，`cause` 为 `null`
  @Override
  public void onClose(KubernetesClientException cause) {

  }
}

client.pods()
  .inAnyNamespace()
  .watch(DummyWatcher());

细枝末节

我们已经准备好实现 Sidecar 模式了。我不会贴出所有代码，毕竟有 Github，只会贴出一些必要内容。

标记 Sidecar

我们的控制器要在 Pod 新建世加入 Sidecar，并在 Pod 移除时也删除 Sidecar。这个逻辑有一点问题：如果 Sidecar pod 被调度，就会触发监控事件，就会加入新的 Sidecar，这个过程会不断重复下去。因此有必要对 Sidecar Pod 进行标记。在带有标记的 Pod 被创建时，不会触发创建逻辑。

有几种方式来对 Sidecar Pod 进行标记：

给 Pod 加入后缀，比如 sidecar

添加特定标签：

client.pods()
.inNamespace("ns")
.createNew()
.withNewMetadata()
  .addToLabels("sidecar", "true")
.endMetadata()
.done();

和 Pod 一起删除 Sidecar

Pod 应该有且只有一个 Sidecar，并且随 Pod 的创建和销毁同步进行创建和销毁。

因此 Sidecar 数据结构中需要有一个指向主 Pod 的引用。这样在 Pod 删除时，如果它不是 Sidecar Pod，我们就能找到它的 Sidecar 并删除。

最直白的方式就是在住 Pod 删除时直接删除 Sidecar，不过这需要做不少事。Kubernetes 中可以把两个 Pod 的生命周期使用 ownerReference 关联起来。这样就可以让 Kubernetes 自行处理删除逻辑了。

用 API 实现非常直观：

client.pods()
  .inNamespace("ns")
  .createNew()
    .withNewMetadata()
      .addNewOwnerReference()
        .withApiVersion("v1")
        .withKind("Pod")
        .withName(podName)
        .withUid(pod.getMetadata().getUid())
      .endOwnerReference()
    .endMetadata()
  .done();

保持 Sidecar

添加了 Sidecar 并不意味着他会永远保持。例如属于一个 Deployment 的 Pod 会被删除，Deployment 的核心功能就是保持副本数为期望值。

类似的，如果一个 Sidecar 被删除，并且主 Pod 还保持存活，就应该创建新的 Sidecar，并维持 ownerReference。

结论

本文描述了用 Java 实现 Kubernetes 控制器的过程。有了 Fabric8 API，这个过程相当直接。主要需要解决的问题就是删除和创建逻辑。下一篇也就是最后一篇，会讲解部署和运行的过程。

本文涉及的完整代码保存在 Github。

自己的 Kubernetes 控制器（1）——工作准备

Mon, 13 Apr 2020 11:33:12 +0800

原文：Your own Kubernetes controller - Laying out the work

作者：Nicolas Fränkel

时至今日，Kubernetes 已经成为容器化应用部署的首选平台，是个难以忽视的存在。

Kubernetes是一个开源系统，用于自动化部署、扩展和管理容器化应用程序。

短短几年里，Kubernetes 在 CNCF 的大旗下高歌猛进，在 DevOps 领域已经深入人心。这其中的原因众说纷纭，其中一个非常有说服力的理由是，用户能够避免被锁定在单一云提供商的 API 上。如果你对 2000 年左右微软的桌面垄断有所了解，你可能会明白我的意思。

Kubernetes 的扩展相对来说比较容易，这是它获得广泛认同的一个重要原因。很多软件供应商在 Docker 镜像之外，还会提供一或多个 Operator。

我假设读者仅对 Kubernetes 有所了解，对控制器一无所知，在这个假设的基础上，我将用三篇连载来讲述如何使用 Go 以外的语言实现自己的控制器。

控制器是什么

配置管理工具可以分为两种：

分类	描述	工具
指令式	指定做事方法，例如启动两个节点	Ansible、SaltStack 等
声明式	指定目标状态，例如总计五个节点	Puppet、Chef 等

声明式的工具通常会周期性的执行以下任务：

查询当前状态
评估要从当前状态达到目标状态所需完成的步骤
执行这些步骤

这个算法描述的是一个控制回路。

Kubernetes 里，已经有了这些控制回路的实现。例如 ReplicaSet 和 Deployment。这两个对象都可以针对特定镜像设置目标 Pod 数量。Kubernetes 会持续生成副本，直到达到预设的实例数量。如果副本数量发生变化，那么就会新建或删除副本，以达到目标副本数量。

现在你可能已经猜到了，控制器就是一个控制循环的实现：检查当前状态，用现有状态计算差异，弥补差异。除了 Deployment 和 ReplicaSet 的控制器之外，Kubernetes 还提供了很多开箱即用的控制器。

Service
DeamonSet
PersistentVolume
Job
…

其实大多数的 Kubernetes 资源都是由控制器管理的。

初识 Operator

对控制器感兴趣的读者，可能已经在搜索过程中偶然发现了 Operator 这个名词。如果你的时间非常有限，我建议你跳过这一部分，将这两个术语视为近义词即可。

前面说到 Kubernetes 的扩展性。其中一个扩展方法就是创建控制器，这也是本文的的重点内容。另一个方式就是对 Kubernetes 模型本身进行扩展：在开箱即用的 Pod、Job 等内置资源以外，还可以使用 CRD 来提供额外的资源类型。

例如下面的代码定义了一个叫做 Hazelcast 的资源：

hazelcast-crd.yml

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: hazelcasts.hazelcast.com
spec:
  group: hazelcast.com
  names:
    kind: Hazelcast
    listKind: HazelcastList
    plural: hazelcasts
    singular: hazelcast
  scope: Namespaced
  subresources:
    status: {}
versions:
    - name: v1alpha1
      served: true
      storage: true

把文件提交给 API Server，让 Kubernetes 注册这个新的 Hazelcast CRD。

kubectl apply -f hazelcast-crd.yml

这个动作完成之后，就可以像其他内置资源一样进行常用操作了：

kubectl get hazelcasts

Operator 就是一个用于某种 CRD 的控制器。如果知道怎么实现控制器，也就能够创建 Operator 了。

控制器的需求

现在我们看看 Kubernetes 控制器的需求。

控制器的部署位置

下图是一个简化的 Kubernetes 架构图：

Kubernetes 的内置控制器是其控制平面的组成部分。然而自定义控制器是不会出现在这里（Controller Manager）的。控制器没什么限制，它可以在集群内部以 Pod 的形式运行，也可以作为独立的外部进程。

当然 Pod 形式会享受各种 Kubernetes 上运行容器化应用的福利，例如自愈等。

和 Kubernetes 的通信

在 Kubernetes 中，API Server 是一个通信组件。客户端发送 HTTP 请求，API Server 处理请求后发回响应。给 kubectl 加上参数就能观察到这一过程：

$ kubectl get pods --v=8
I0209 12:36:31.330067   13717 round_trippers.go:420] GET https://192.168.99.103:8443/api/v1/namespaces/default/pods?limit=500
I0209 12:36:31.330078   13717 round_trippers.go:427] Request Headers:
I0209 12:36:31.330081   13717 round_trippers.go:431]     Accept: application/json;as=Table;v=v1beta1;g=meta.k8s.io, application/json
I0209 12:36:31.330085   13717 round_trippers.go:431]     User-Agent: kubectl/v1.17.2 (darwin/amd64) kubernetes/59603c6
I0209 12:36:31.339770   13717 round_trippers.go:446] Response Status: 200 OK in 9 milliseconds
I0209 12:36:31.339780   13717 round_trippers.go:449] Response Headers:
I0209 12:36:31.339798   13717 round_trippers.go:452]     Content-Length: 2933
I0209 12:36:31.339804   13717 round_trippers.go:452]     Date: Sun, 09 Feb 2020 11:36:31 GMT
I0209 12:36:31.339822   13717 round_trippers.go:452]     Content-Type: application/json
I0209 12:36:31.340084   13717 request.go:1017] Response Body:
{ "kind":"Table",
  "apiVersion":"meta.k8s.io/v1beta1",
  "metadata":{
    "selfLink":"/api/v1/namespaces/default/pods",
    "resourceVersion":"2387836" },
  "columnDefinitions":[
    { "name":"Name",
      "type":"string",
      "format":"name",
      "description":"Name must be unique within a namespace. Is required when creating resources, although some resources may allow a client to request the generation of an appropriate name automatically. Name is primarily intended for creation idempotence and configuration definition. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/identifiers#names",
      "priority":0 },
    { "name":"Ready",
      "type":"string",
      "format":"",
      "description":"The aggregate readiness state of this pod for accepting traffic.",
      "priority":0 },
    { "name":"Status",
      "type":"string",
      "format":"",
      "description":"The aggregate status of the containers in this pod.",
      "priority":0 },
    { "name":"Restarts",
      "type":"integer",
      "format":"",
      "description":"The number of times the containers in this pod have been restarted.",
      "priority":0 },
    { "name":"Age",
      "type":"stri
[truncated 1909 chars]

这个通信过程的需求很简单：

能够处理 HTTP 的请求和响应
JSON 解析（或者说序列化和反序列化）

是的，有 JSON 和 HTTP 的处理能力就够了，所以要编写一个控制器，并不一定必须使用特定语言（例如 Go），理论上用单纯的 Shell 也是可以实现的。

Go 的定位

在进入实现细节之前，首先要看看 Kubernetes 的生态。

历史上好像 Kubernetes 的祖先是用 Java 开发的，后来被移植到了 Go 上。这可能是部分代码不符合 Go 语言风格的原因。尽管 Go 具有垃圾收集功能，但它还是被称为一种低级语言，很适合运行接近于裸机的软件。这种说法是否成立，远远超出了本文的范围，也超出了我的能力。

然而 Kubernetes 生态中大量软件是使用 Go 语言编写的，我想是有其原因的。

如果你已经对 Go 相当了解，那么继续使用是个很好的选择——改弦易辙需要勇气。这并不只是一个语言的问题，除了语法之外，还有很多其他内容：

要多久才能用新语言写出地道的代码

我记得我在学习 Java 的时候，读过 C 语言开发者写的代码。虽然语法是 Java，但是却写出了 C 语言的风格，例如在方法结束之前释放本地变量的引用。

多久才能搞清楚在什么条件下使用什么库

我不了解 Go，但是我知道 Java。Java 生态的丰富是人所皆知的。例如测试的场景，就有 JUnit 4、JUnit 5 以及 TestNG 可以选择，另外需要加入断言库么？这还只是测试呢。

选择正确的工具链要多久

如果已经在使用 JetBrains 的产品，那么从 JetBrains IDE 之间跳转是比较容易的，例如 IDEA 和 GoLand。但是 IDE 市场非常混乱，例如微软正在推广的包含丰富插件的 VS Code。而 Java 世界中，Eclipse 仍然占据客观的市场份额。各种产品都有自己的优劣，自己的拥趸。工具的选择可能在组织内部引发圣战。

新工具形成生产力要多久

各种 IDE 都有各自的玩法。例如我从 Eclipse 切换到 IntelliJ 的过程中，几个星期后才停掉了频繁保存文件的习惯。除了 IDE 之外，还有除错工具等。新的语言能怎么除错？有什么先决条件么？

另外前面说的几个点只是开发，如果考虑到相关的构建、集成和投产环境，其投入可能又会有数倍的增长。

我希望上面几点能够让读者意识到，语言的切换事关重大。在很多情况下，沿用原有的语言可能是个更好的选择。

结论

本文的第一部分，大概了解了一下 Kubernetes 控制器的基础内容。我们详细介绍了什么是控制器，以及开发控制器的需要：即能够与 HTTP/JSON 通信。在下一篇帖子中，我们将详细介绍并实际开发自己的自定义控制器。

给 Node Exporter 加上 Basic 认证

Thu, 09 Apr 2020 22:30:05 +0800

前两天在成老师群里问了个无聊的问题——Node Exporter 输出的数据，是不是就应该匿名获取呢？本着 0 信任原则，缺省情况下使用 Host Network 的 Node Exporter 暴露的端口的确是令人稍有不安的，那么如何改善呢？

Node Exporter 新版本中提供了一个 TLS 认证的实验性功能，恰好 Prometheus 也是支持双向 TLS 认证的。不过很多服务会通过 Endpoint 方式提供 Exporter 服务，用 Nginx Sidecar 会是个更加通用的方式。下面举个简单的例子，其他的 Exporter 也可以照猫画虎，并且 Nginx 很成熟，完全可以提供其他更丰富的认证能力。

首先使用 Helm 安装 Prometheus：

helm install stable/prometheus \
--generate-name \
--set alertmanager.enabled=false\
--set nodeExporter.hostNetwork=false \
--set pushgateway.enabled=false \
--set server.persistentVolume.enabled=false

启动之后，会生成一组 Prometheus 组件的资源对象，要修改的包括几个项目：

生成 Basic 认证所需的文件
为 Nginx 编写反向代理配置
以 Sidecar 的形式把 Nginx 加入 Node Exporter 的 Pod 中
变更 Node Exporter 的抓取配置
变更 Prometheus 的采集参数

可以使用 htpasswd 工具生成密码文件，例如：htpasswd -c -m passwd.dat admin。

接下来编写一个配置文件片段：

server {
    listen  9101;
    server_name localhost;
    auth_basic   "login";
    auth_basic_user_file /etc/nginx/conf.d/passwd.dat;

    location / {
        root   /usr/share/nginx/html;
        proxy_pass http://127.0.0.1:9100;
    }
}

这里使用一个非常简单的配置，引用前面生成的密码文件进行验证，并且对来自 9091 端口的请求，转发到同一个 Pod 中 9100 端口的 Node Exporter 上。

用前面的两个文件生成 Configmap 供容器引用：

kubectl create configmap nginx-config \
--from-file=proxy.conf --from-file=passwd.dat

生成 Nginx 配置之后，就需要把 Nginx 加入 NodeExporter 了，可以使用 kubectl edit 在线编辑，或者导出 YAML，加入如下内容：

    spec:
      containers:
        ...
        - image: nginx:stable-alpine
          ports:
          - containerPort: 9101
            name: proxy
            protocol: TCP
          name: nginx
          volumeMounts:
            - mountPath: /etc/nginx/conf.d
              name: nginx-config
              readOnly: true
      ...
      volumes:
        ...
        - name: nginx-config
          configMap:
            name: nginx-config

因为端口发生了变化，所以还需要修改 Service 的抓取标签，注解中加入：

  annotations:
    prometheus.io/port: "9101"
    prometheus.io/scrape: "true"

最后修改 Prometheus 的配置，在 kubernetes-service-endpoints 加入如下内容：

    - job_name: kubernetes-service-endpoints
      basic_auth:
        username: admin
        password: password

重启 Prometheus，之后，可以看到工作还是继续进行，但是使用 CURL 访问会得到 401：

$ curl http://192.168.14.252:9101/metrics
<html>
<head><title>401 Authorization Required</title></head>
<body>
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.16.1</center>
</body>
</html>

以此类推，如果在 Nginx 中引入 TLS 双向认证，还可以使用 CA 的方式对认证过程进行进一步的集中管理，让更多的 Exporter 进入管理范围。

Kubernetes 1.18 中 Ingress 的增强

Sun, 05 Apr 2020 17:41:31 +0800

作者：Rob Scott (Google) Christopher M Luciano (IBM)

原文：Improvements to the Ingress API in Kubernetes 1.18

Kubernetes 的 Ingress API 是大量 Ingress 控制器的基础，它们通过这一 API，用方便强大的方式为 Kubernetes 提供入站流量的支持。在 Kubernetes 1.18 中，这个 API 有了三个显著的变化：

新的 pathType 字段可以用来匹配 Ingress 路径。
IngressClass 资源能够指定控制器实现 Ingress 的方法。
主机名中可以使用通配符。

使用 Path Type 改进路径匹配

Path Type 的新概念让用户可以指定路径的匹配方式，目前有三种：

ImplementationSpecific（缺省）：这种匹配方式的行为取决于 IngressClass 控制器的实现。
Extract：以区分大小写的方式精确匹配整个 URL 路径。
Prefix：区分大消息，根据以 / 分割的 URL 元素进行前缀匹配。

使用 Ingress Class 扩展配置

Ingress 资源的设计初衷就是易用性，尝试使用简单的字段为所有应用提供支持。随着应用场景的不断增加，为了适应更广泛的需求，越来越多的 Ingress 控制器要靠大量的自定义注解来完成更复杂的配置。IngressClass 资源提供了一种替换部分注解的思路。

每个 IngressClass 中都指明了用于实现 Ingress 的控制器类型，并且可以引用自定义资源来使用更多参数。

apiVersion: networking.k8s.io/v1beta1
kind: IngressClass
metadata:
  name: external-lb
spec:
  controller: example.com/ingress-controller
  parameters:
    apiGroup: k8s.example.com/v1alpha
    kind: IngressParameters
    name: external-lb

指定 Ingess 的 Class

Ingress 规范中加入了 ingressClassName 字段，用来指定实现这个 Ingress 资源的的 IngressClass。

淘汰 Ingress 注解

在 1.18 加入 IngressClass 之前，需要在 Ingess 资源中使用 kubernetes.io/ingress.class 注解来指定 Ingress 控制器。在没有官方定义的情况下，这个注解被大量的 Ingress 控制器所支持。现在是时候淘汰他了。

设置缺省的 IngressClass

可以使用 ingressclass.kubernetes.io/is-default-class 注解，将其设置为 True，就代表所在的 IngressClass 为缺省控制器。没有显示指定 IngressClassName 的新的 Ingress 资源都会使用该控制器。

主机名通配符

很多 Ingress 控制器都支持通配符，例如 *.foo.com 可以匹配 app1.foo.com，但是直到目前为止，规范还是假设使用完全匹配的 FQDN。主机名现在也可以使用通配符了。

Host	Host Header	匹配?
`*.foo.com`	`*.foo.com`	根据后缀匹配
`*.foo.com`	`*.foo.com`	不匹配，通配符只能对应一个 DNS 项
`*.foo.com`	`foo.com`	不匹配，通配符只能对应一个 DNS 项

总结一下

新的 Ingress 功能扩展了配置能力，下面是一个例子，其中用到了上面提到的三个新特性：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: example-ingress
spec:
  ingressClassName: external-lb
  rules:
  - host: *.example.com
    http:
      paths:
      - path: /example
        pathType: Prefix
        backend:
          serviceName: example-service
          servicePort: 80

Ingress 控制器支持

这个功能是 Kubernetes 1.18 中新增的，因此各种控制器都需要一段时间才能提供支持。请关注相关产品的官方文档。

Ingress 的未来

Ingress API 将在 1.19 进入稳定阶段。它会持续使用简单的方式为 Kubernetes 入站流量提供支持。这个 API 的设计重心就在于轻量和简单，但是更好的配置能力和更广泛的案例支持也是一个持续的努力方向。

目前还在开发一组高配置能力的 API。被称为 Service API 的新 API 会提供一种 Ingress 的替代方案。它的存在目的不是替代 Ingress，而是提供一种更具配置能力的新方案。请查看 Github 上的 Service API 项目。

如何编写一个支持 Krew 的 kubectl 插件

Thu, 02 Apr 2020 10:13:24 +0800

krew 简介

Krew 是一个用来管理 Kubectl 插件的工具，名字大概来自于 OS X 下著名的软件包管理器 Homebrew，使用 Krew 能够方便的查找、安装和使用 Kubectl 插件，例如：

$ kubectl krew search
NAME                            DESCRIPTION                                         INSTALLED
access-matrix                   Show an RBAC access matrix for server resources     no
advise-psp                      Suggests PodSecurityPolicies for cluster.           no
...

$ kubectl krew install tree
Updated the local copy of plugin index.
Installing plugin: tree
...

$  kubectl tree deployment coredns -nkube-system
NAMESPACE    NAME                                READY  REASON  AGE
kube-system  Deployment/coredns                  -              140d
kube-system  └─ReplicaSet/coredns-76d9d9bcc7   -              140d
kube-system    ├─Pod/coredns-76d9d9bcc7-m6d4c  True           4d10h
kube-system    └─Pod/coredns-76d9d9bcc7-zvf9c  True           4d10h

很方便的几个步骤，就可以查询、安装和使用新插件了。

Krew 除了落在客户端的可执行文件之外，和其它软件包管理系统一样，也同样需要有一个索引系统，并根据索引进行软件查询和下载，下载之后的软件保存在本地，供 kubectl 调用。

索引

Krew 的索引保存在一个名为 krew-index 的代码库中。其中的 plugins 目录保存了一组 yaml 文件，就是插件的目录。

YAML 清单

随意打开一个清单文件，可以看到这样的内容：

apiVersion: krew.googlecontainertools.github.com/v1alpha2
kind: Plugin
metadata:
  name: access-matrix
spec:
  version: v0.4.4
  platforms:
  - bin: access-matrix
    uri: https://github.com/corneliusweig/rakkess/releases/download/v0.4.4/access-matrix-amd64-linux.tar.gz
    sha256: 53b1ee5865d11360cea3e59b91cdc6707ee30845567e63657782ee11815f1de4
    files:
      - from: ./LICENSE
        to: .
      - from: ./access-matrix-amd64-linux
        to: access-matrix
    selector:
      matchLabels:
        os: linux
        arch: amd64
  shortDescription: Show an RBAC access matrix for server resources
  homepage: https://github.com/corneliusweig/rakkess
  caveats: |
      Usage:
        kubectl access-matrix
  description: ..

其中 apiVersion 和 kind 是固定内容。platforms 是一个数组，指定不同平台下的不同用法。下一级的 bin 表明了执行命令；uri 和 sha256 分别指的是下载位置以及压缩包的校验码；接下来的 files 是一个拷贝命令——从解压后的文件夹中拷贝文件；最后的 selector 则是针对不同平台的选择标准。

所以要编写一个能够通过 Krew 进行管理的 kubectl 插件，需要以下几个步骤：

编写插件代码
制作清单和调试
上传到 krew-index

下面用一个实际的例子来说明一下这个过程。

编写插件代码

插件代码本身的编写非常简单和随意，可以用你喜欢的任何语言，例如 golang、python 或者 shell。只有一个推荐的命名规则：kubectl-rm，在 kubectl 中调用时就可以使用 kubectl rm 了。例如我要编写一个对输出 JSON 进行过滤的插件，代码如下：

#!/bin/sh

METADATA=${JSON_METADATA-".metadata.resourceVersion, .metadata.selfLink, .metadata.managedFields, .metadata.generation, .metadata.uid, .metadata.creationTimestamp"}
STATUS=${JSON_STATUS-".status"}
ANNOTATION=${JSON_ANNOTATION-".metadata.annotations.\"kubectl.kubernetes.io/last-applied-configuration\", .metadata.annotations.\"deployment.kubernetes.io/revision\""}
SPEC=${JSON_SPEC-".spec.template.metadata.creationTimestamp, .spec.revisionHistoryLimit, .spec.templateGeneration"}

if ! [ -x "$(command -v jq)" ]; then
  echo 'Error: jq is not installed.' >&2
  exit 1
fi

if [ $# -lt 2 ]
  then
    echo "Usage: $0 [workload-type] [object-name] [other parameters for kubectl]"
    echo "Workload types: 'deployment', 'daemonset', 'configmap', 'statefulset', 'secret'"
    echo "Example: $0 deploy coredns -n kube-system"
    exit 1
fi

TYPE=$1
NAME=$2
OTHER=$*

kubectl get ${OTHER} -ojson | jq -S "del(${METADATA}, ${STATUS}, ${ANNOTATION}, ${SPEC})"

想法很简单，获取运行中的对象描述，使用 JQ 对数据进行清理和排序，输出一个相对标准的结果，便于不同环境间的比较和部署的导出。

虽然最后是通过 kubectl std-json 的方式调用，这里的 $0 指的仍然是脚本自身。

制作清单和测试

照猫画虎，按照上面的 YAML 代码，编写自己的清单。

清单要求，需要打一个压缩包便于下载，我们把可执行文件和 LICENSE 文件放置到单独的目录 kubectl-std-json-v0.1.0 中，压缩生成一个 .tar.gz 文件，部分清单如下

    uri: https://github.com/fleeto/kubectl-std-json/releases/download/v0.1.0/kubectl-std-json-v0.1.0.tar.gz
    sha256: e1ad2398eaed5442042da134fb046fa8276042dd4122da4d872a8e91aeb2a339
    bin: kubectl-std-json
    files:
    - from: kubectl-std-json-*/kubectl-std-json
      to: .
    - from: kubectl-std-json-*/LICENSE
      to: .

平台选择方面，我们只支持 OSX 和 Linux，因此只要一个平台元素即可。

压缩包的校验码可以使用 shasum -a 256 命令生成。

上传压缩包之后，可以使用 kubectl krew install --manifest 命令来测试安装。如果一切顺利，在本地就可以使用了。

krew-index

接下来的操作很常规：fork krew-index，把你的清单写入 plugins 目录，提交 PR 即可。

根据 Configmap/Secret 变化更新 Deployment

Mon, 23 Mar 2020 19:34:30 +0800

这个项目叫做 Reloader，它可以监控 Configmap/Secret 的变化，根据 Annotation 选择 Deployment，对相关 Deployment 进行滚动更新。

简单工具的安装还是很简单的：

kubectl apply -f \
https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml

首先创建我们要用到的配置对象，其中包含了一个 Secret 和一个 Configmap：

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: password
data:
  password: YWJjZGVm
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: login
data:
  login.conf: |
    [login]
    url="http://ciduy.com"
    user="adminbacd"

接下来部署一个应用作为应用负载，来验证 Reloader 的功能：

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    reloader.stakater.com/auto: "true"
  labels:
    app: debugger
  name: debugger
spec:
  replicas: 1
  selector:
    matchLabels:
      app: debugger
  template:
    metadata:
      labels:
        app: debugger
    spec:
      containers:
      - image: dustise/sleep:latest
        name: sleep
        env:
        - name: PASSWORD
          valueFrom:
            secretKeyRef:
              name: password
              key: password
        volumeMounts:
        - name: cm-sample
          mountPath: /etc/cm
      volumes:
      - name: cm-sample
        configMap:
          name: login

这里的 Annotation 表示自动监控相关对象。

接下来随意改动一下 Configmap 或者 Secret 的值，就会看到 Pod 重建了。

自动变更有时也需要手工指定的辅助的，例如服务依赖的情况，可以依赖上游服务的 Configmap 变更进行重启；或者是对某些可以自动处理的配置文件进行忽略处理，都可以使用如下两个注解：

secret.reloader.stakater.com/reload: "secret1,secret2"
configmap.reloader.stakater.com/reload: "configmap1, configmap2"

补充

Reloader 的命令行还有两个参数：

--namespaces-to-ignore：忽略部分命名空间的监听
--resources-to-ignore：忽略部分对象的变更

Kubernetes 集群规模杂谈

Sun, 22 Mar 2020 08:38:38 +0800

节点数量

早在 Kubernetes 1.2 时候，就已经宣布达到 1000 节点的规模了，在 1.6 版本更达到了 5000 节点的规模。各大厂也都有了各自的超大规模单一集群。然而普罗大众的情况是如何呢？ Sysdig 在 2019 年度容器应用报告中得到的结果是，大于 50 节点规模的集群不足 10%，另外一个佐证是 Mohamed Ahmed 的一篇调查报告中也提供了类似的数据。这种情况的一种解释是，目前的应用阶段还比较早期，处于试探期间；然而从一个侧面来说，Sysdig 的调研对象针对的是生产应用，也就是说处于生产应用状态下的集群，绝大多数都是这种小规模集群。根据对 CNCF Landscape 中 Distribution 分类的产品的抽查，也可以看到随处可见的 Kubernetes As Service 类似功能的实现，这也证实了小集群协作方案的落地趋势。相对于少量大集群，多个小集群的差异在于：

隔离程度高

虽然现在存在不少沙箱容器实现，然而最易用的、生态最为成熟的方案还是 Docker为代表的传统容器方案，传统容器方案所缺失的隔离能力，通过多租户多集群方式是一个非常自然的思路。

实现难度低

国内几个大厂都有自己的大规模 Kubernetes 集群实现方式，然而通常需要对基础组件大动干戈，甚至不惜使用无法回流社区的孤岛版本，虽然部分大企业的研究院等相关部门已经具备了非常强的研发实力，然而对于通常的 To B 场景来说，这并不是一个合适的选择。

运管成本高

多个集群很明显会需要更多的运维和管理人力的投入。

资源利用率低

多个集群都会有自己的 Master 组件、ETCD 集群、网络组件等，这些都会抢占更多原本属于工作负载的系统资源，客观上降低了资源的总体利用率。

节点尺寸

目前很多 Kubernetes 系统都会使用虚拟机来做为节点。那么虚拟机的资源是多分还是少分呢？下表是一个简单的对比：

	大节点	小节点	备注
节点数量	少	多	同样的资源总量情况下，相对来说小资源节点会得到更多的数量。
运维成本	低	高	通常情况下，节点的运维成本是和节点数量正相关的。
容错能力	低	高	较大的节点上通常会集中较多的应用，因此在节点出现故障时，可能会带来更大的损失。
资源粒度	大	小	单节点资源较大，因此其资源粒度也较大。
应用副本数	少	多	同一应用的多个副本，如果调度到同一个节点上的话，对于提高其负载能力和健壮性来说并无裨益。
副本规模	大	小	毫无疑问，具备更多资源的大节点，能够运行更大资源需求范围的容器应用。
系统开销	少	多	每个虚拟机都会有自己的操作系统、网络等基础开销，因此相对于少量大节点来说，大量的小节点会消耗更多的资源。
虚拟机分配难度	高	低	过大的节点资源需求，如果采用虚拟机分配，就需要有更大规模的物理机提供支持。

除了这些原则性的条目之外，更重要的决策依据就是运行在集群上的应用需求。例如某租户的集群需要支撑 20 个应用，共 300 个 Pod，按照常见的每节点 30-50 Pod 的分布，就需要 6-10 个运算节点（Node）。以 10 节点算，加入系统保留、冗余等计算，可能需要 10 * 120G 的虚拟机实例；然而考虑到故障情况——一个节点的故障，最好的结果也是短期内降低 10% 的算力。如果扩张到 40 个 32G 的虚拟机节点，会大幅降低单节点故障的影响——当然也会提高网络的复杂性和效率要求。

应用资源

Java 应用是特别常见的迁移案例，除掉微服务化、网格、分布式等改造要求之外，资源的申请和限制是一个必须要面对的门槛。requests 是个用于调度的定义，Kubernetes 根据这个要求来选择能够满足要求的节点来分配应用；而 limits 则会用于触发 OOM。

众所周知的是，Java 的早期版本是无法识别容器内的内存限制的，因此如果没有限制堆内存上限，又开启了 limits，就会被 Kubernetes 杀掉。因此针对容器中运行的情况，需要进行一些启动参数的设置。

如果允许更新到新版本的 JVM，可以使用新引入的 UseCGroupMemoryLimitForHeap、MaxRAMFraction 参数，让 JVM 直接继承容器的定义。

如果无法直接升级，那么就有必要设置 xmx 和 xms 参数了，这里有几个小建议：

xmx 和 xms，request 和 limits 建议设成一致，能省掉很多麻烦。
tmpfs、filemapping 等都是可能的内存大户。
JVM 并不是唯一的内存消耗者，一般建议 Limit 大于 XMX 25% 以上。
/sys/fs/cgroup/memory/memory.stat 是你的好朋友。

Kubernetes 中的 CPU 和内存

Kubernetes 集群中的资源，主要关注的是 CPU 和内存两种。Pod 的定义中会定义对资源需求的声明，声明方式分为 Request 和 Limit。

Request 是一个调度参数，可以理解为基本需求：一个 Pod 中的所有容器的 Request 之和，就是 Pod 对资源的最小需求，调度器根据这个最小需求来选择具备条件的节点，在其上运行被调度的 Pod。

Limit 是一个安全参数，它的值一定大于 Request，顾名思义，它声明的是上限：

CPU是弹性资源，如果容器使用CPU达到Limit，就无法进一步提高运算能力，可能会导致运算速度无法满足需求。

Memory 是非弹性资源，如果容器使用 Memory 达到 Limit，就会触发 cgroup 的 OOM 事件，导致容器被杀死。

综上所述，Memory超限会对业务产生更大伤害，那么是不是不设限会更安全？答案很显然是否定的：

不设置 Limit，一旦引发系统 OOM 或者驱逐事件，宏观来看，都会导致一个不可预知的结果。
不设置 Request，Kubernetes 调度器会失去重要的调度标准，会影响负载分布的准确性。

一般来说如果 Limit 大于 Request（称为 Burstable），Kubernetes 会根据 Request 将 Pod 调度到满足 Request 要求的节点上去，然而一旦内存消耗从 Request 向着 Limit 增长的过程中出现了节点内存不足的情况，仍然会引发驱逐问题，因此对于保障级别高的业务，我们强烈建议将 Limit 设置为和 Request 相等。

副本和节点数量

目前 Kubernetes 的主流网络模型是基于 iptables 的，很显然 Service、Endpoint 和 Pod 并非越多越好。

而对于应用来说更多的副本数往往意味着更好的容错能力——同样损失一个副本，越多总数意味着业务损失越小。

参考资料

https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/
https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/
https://dig.sysdig.com/c/pf-2019-container-usage-report?x=u_WFRi&mkt_tok=eyJpIjoiWW1GbVptUmtOakk1T1RVNCIsInQiOiJCUitxTXpSYUpXbVJOUDBUK09sbDh4aDVDNkZURHFXK0UwdUNEbkp6UG43XC9VamJIbm9obzJ6MDdcL3EwYXRHS0dTMVdrQXlJaEZDUFd5WnE0WUpXa1ZNVHZyRFkrYjlTNmhwb3d4cFk0alBSOHBqY09mY0pkaDV1VkZCeCtOaHpnIn0%3D

用 CRD 来控制 Kubernetes 日志流

Tue, 10 Mar 2020 16:31:49 +0800

概述

Banzai logging operator 已经出到了 v3 版本。这个项目以 Fluentd 为基础，使用 Operator 的实现模式，在 Kubernetes 上用 CRD 的形式，对日志的采集行为进行定制，并进行过滤、路由等操作，最终可以将日志输出到 Elasticsearch、Loki、S3、Kafka 等多种后端。

图中可见，Logging 把日志分为了采集、路由和输出三个阶段。这三个阶段对应三种不同的 CRD：

采集：使用 fluentbit 对日志进行采集
路由：在 fluentd 中使用多种条件对日志条目进行过滤，并将结果发往目标
输出：可以定义各种后端用于接收存储日志。

安装

可以使用 Helm 进行安装：


$ kubectl create ns logging
namespace/logging created

$ helm repo add banzaicloud-stable \
    https://kubernetes-charts.banzaicloud.com
"banzaicloud-stable" has been added to your repositories

$ helm install --namespace logging \
    logging banzaicloud-stable/logging-operator \
    --set createCustomResource=false

...

安装之后，会看到 logging 命名空间中的 Pod：


$ kubectl get po -n logging
NAME                                         READY   STATUS      RESTARTS   AGE
...
logging-logging-operator-7b4f9987f9-86clp    1/1     Running     0          120m

Logging

首先可以定义一个新的 Logging 对象：

apiVersion: logging.banzaicloud.io/v1beta1
kind: Logging
metadata:
  name: default-logging-simple
spec:
  fluentd: {}
  fluentbit: {}
  controlNamespace: logging

提交到集群：

$ kubectl apply -f empty-logging.yaml
logging.logging.banzaicloud.io/empty-logging created
$ kubectl get pods
NAME                                         READY   STATUS              RESTARTS   AGE
empty-logging-fluentbit-2pghs                0/1     ContainerCreating   0          0s
empty-logging-fluentbit-cc4r4                0/1     ContainerCreating   0          0s
empty-logging-fluentbit-jzkpr                0/1     ContainerCreating   0          0s
empty-logging-fluentd-0                      0/2     Pending
...

Describe 新生成的 Pod，会发现它们加载了几个 Secret 作为配置文件。例如 fluentbit 的内容：

$ kubectl view-secret empty-logging-fluentbit
Choosing key: fluent-bit.conf
...
[OUTPUT]
    Name          forward
    Match         *
    Host          empty-logging-fluentd.logging.svc
    Port          24240

    Retry_Limit   False

这里的配置表明，采集器收集到的日志会输出到 empty-logging-fluentd 的服务之中。

追查一下 fluentd 的配置内容，发现其输出配置为空，也就是说，没有提供输出能力。

查看 operator 的日志：

$ kubectl logs -f -l app.kubernetes.io/name=logging-operator
...
{"level":"info","ts":1583835777.4591844,"logger":"controllers.Logging","msg":"resource created","name":"empty-logging-fluentbit","namespace":"logging","apiVersion":"apps/v1","kind":"DaemonSet"}
...
{"level":"info","ts":1583835834.1114376,"logger":"controllers.Logging","msg":"no flows found, generating empty model"}

输出日志中表示，缺乏 flow 定义。

Output

先使用 Helm 安装 Loki，然后定义一个 output：

apiVersion: logging.banzaicloud.io/v1beta1
kind: Output
metadata:
 name: loki-output
spec:
 loki:
   url: http://loki-1583844504.loki:3100
   configure_kubernetes_labels: true
   buffer:
     timekey: 1m
     timekey_wait: 30s
     timekey_use_utc: true

创建这个资源之后，Secret 和 Pod 都没发生什么变化，甚至 Operator Pod 的日志都没有输出内容，看来还是需要创建 Flow 将日志输出过去。

Flow

创建如下的 Flow 对象：

apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow
metadata:
  name: loki-flow
spec:
  filters:
    - tag_normaliser: {}
    - parser:
        remove_key_name_field: true
        reserve_data: true
        parse:
          type: nginx
  match:
    - select:
        labels:
          app.kubernetes.io/name: log-generator
  outputRefs:
    - loki-output

其中 filters 成员中标识了我们要对应用进行的处理，使用 tag_normaliser 加入 Kubernetes 标签。

在 match 中使用标签加入过滤功能，这里选择了 app.kubernetes.io/name: log-generator 的标签对

outputRefs 指定输出到前面创建的 loki-output。

CRD 创建之后

进入 fluentd Pod 的 Shell，会发现配置发生变化：

$ cat fluentd/app-config/fluentd.conf

<match **>
...
    <match>
      labels app.kubernetes.io/name:log-generator
      namespaces logging
...
  <match kubernetes.**>
    @type tag_normaliser
    @id loki-flow_0_tag_normaliser
    format ${namespace_name}.${pod_name}.${container_name}
  </match>
  <filter **>
    @type parser
    @id loki-flow_1_parser
...
    <parse>
      @type nginx
...
  <match **>
    @type loki

部署一个应用：

apiVersion: apps/v1
kind: Deployment
metadata:
 name: log-generator
spec:
 selector:
   matchLabels:
     app.kubernetes.io/name: log-generator
 replicas: 1
 template:
   metadata:
     labels:
       app.kubernetes.io/name: log-generator
   spec:
     containers:
     - name: nginx
       image: banzaicloud/log-generator:0.3.2

此时打开 Loki 的 Grafana，就能对日志进行查询了：

结语

这个产品很好的展示了 Operator 固化运维技能的特征。化繁为简，将日志集采过程中所需的复杂知识，精选为一系列的配置组合，以 CRD 的形式呈现给非专家型客户，开箱即用。

kubectl 的 view-secret 插件，Bug 比较严重，不要问我是怎么知道的。

kube-scan 和 KCCSS

Sun, 01 Mar 2020 01:55:44 +0800

在 Kubernetes 中使用声明式 API 来定义工作负载，因为工作负载的灵活多变，这种定义的随意性是很大的，很容易因为复制黏贴、手工运维等原因给 Pod 分配不需要的特权，造成安全隐患。kube-scan 就是针对这种情况而出现的一个工具，它根据内置的二十几个检查项目，对工作负载描述的安全性进行打分，从最安全的 0 分，到最危险的 10 分。

kube-scan 所使用的计分项和算法，被称为 Kubernetes Common Configuration Scoring System (KCCSS)，是一套仿造 CVSS 的 Kubernetes 配置评分系统，它从对完整性、可用性和保密性三个方面的威胁来评价安全漏洞，评分标准对降低工作负载安全性的评价，如果在同样方面已经做出了合适的补救措施，还可以挽回这部分的扣减。

快速开始

老一套的部署方式：

$ kubectl apply -f \
    https://raw.githubusercontent.com/octarinesec/kube-scan/master/kube-scan.yaml
namespace/kube-scan created
configmap/kube-scan created
serviceaccount/kube-scan created
clusterrole.rbac.authorization.k8s.io/kube-scan created
clusterrolebinding.rbac.authorization.k8s.io/kube-scan created
deployment.apps/kube-scan created
service/kube-scan-ui created

可以看到创建了一个新的命名空间 kube-scan，其中有一个 kube-scan-ui:80 的服务。尝试访问一下，页面会显示出当前集群中运行的有风险载荷，例如使用 Helm 缺省安装的 Traefik：

点击 show more，会显示对应问题的详细信息：

往前一步

通过对部署文件的观察，会发现这个 Pod 里有两个容器，分别命名为 kube-scan-ui 和 kube-scan，粗浅判断这是一个前后端分离的任务。在浏览器中打开调试工具，会发现对 <host-name>/api/risks 的访问，直接访问这个地址，会拿到一个 JSON 响应：

{
    "data": [{
        "kind": "Deployment",
        "name": "traefik-1583034161",
        "namespace": "infra",
        "domain": "",
        "risk": {
            "riskScore": 7,
            "riskCategory": "Medium",
            "riskItems": [{
                    "name": "AllowPrivilegeEscalation",
                    "riskCategory": "Low",
                    "type": "Basic",
                    "title": "Workload allows privilege escalation",
                    "shortDescription": "Privilege escalation allows programs inside the container to run as root",
                    "description": "Privilege escalation allows programs inside the container to run as root, even if the main process is not root, which can give those programs control over that container, host and even cluster",
                    "confidentiality": "Low",
                    "confidentialityDescription": "Root processes that can escape the containers have the ability to read secrets from Kubernetes, Docker and other applications",

这样一来，我们就可以考虑，将 UI 部分去掉，仅留下后端服务。如此一来，就可以通过简单的代码，把扫描过程集成到日常运维工作之中了。

另外一些小秘密

kube-scan 的文档非常贫瘠，因此只能从 YAML 和源码中找到一些东西。

刷新时间

YAML 中有一个环境变量 KUBESCAN_REFRESH_STATE_INTERVAL_MINUTES，原定的刷新时间是 1440 分钟也就是 24 小时。修改这一变量就能进行更快的刷新了。

KCCSS 配置

安装过程中生成了一个 Configmap 对象 kube-scan，其中保存了 kube-scan 的评价标准，在他的代码中可以看到已经支持的各种威胁和补救措施。basic 节点中列出了目前能够判断的威胁列表，例如下面的定义：

- name: "privileged"
  title: "Workload is privileged"
  shortDescription: "Processes inside a privileged containers get full access to the host"
  description: "..."
  confidentiality: "High"
  confidentialityDescription: "..."
  integrity: "Low"
  integrityDescription: "..."
  availability: "Low"
  availabilityDescription: "..."
  exploitability: "Moderate"
  attackVector: "Local"
  scope: "Host"
  handler: "IsPrivileged"

其中有一些非常易读的关键信息，例如问题的名称、标题、描述，以及对完整性、可用性和保密性的影响级别，最后是攻击来源、难度和范围。

评分方法

定时对工作负载进行检查，然后调用源码 formula.go 中实现的评分过程，整体流程如下：

GetHandler 根据配置文件中的 handler 字段获取处理方法。
用查询到的 Handler 函数对工作负载进行检查，如果存在该问题，则根据问题涉及范围，检查该工作负载是否已经有针对性的进行了加固，以此来调整该项目得分。
根据 Risk 和 Remediation 生成结果列表。

注意如下命名空间是硬编码忽略的 {“octarine”, “kube-system”, “kube-public”, “octarine-tiller”, “istio-system”, “octarine-dataplane”, “kube-scan”}

结论

KCCSS 和 kube-scan 两个项目的文档都非常稀少，很不友好。
特征库更新困难，需要同时更新源码和配置。
仅提供了对全集群进行扫描，实际应用的情况下，如果能加入单个对象进行检查的手段可能会更加实用。

简介：CIS Kubernetes 安全基准指南

Sat, 22 Feb 2020 21:24:06 +0800

在使用 Kube Bench 的过程中注意到，其指导依据来自于 CIS Benchmark，于是顺藤摸瓜，下载了 CIS Kubernetews Be nchmark 的 PDF 版本，全文有两百多页，阅读量还蛮大的，因此对其进行整理，便于大家参考使用。

简介

CIS 的指导原则里把建议行为分成了两级：

一级：使用该建议不会造成负面影响。
二级：仅建议在非常强调安全性的系统中使用，可能对系统有副作用。

另外还将具体的检测结果分为计分和不计分两种结果。

以上两个维度可以用来对系统进行现状评估，也有助于读者选择性地采纳加固措施。

整个指南分为五个部分：

控制平面组件
etcd
控制平面配置
节点配置
策略

检查项概要

所有运行参数文件、kubeconfig 文件以及证书，权限至少应为 644 并且属于 root:root。
API Server
- 南向和北向通信
  - 关闭匿名访问
  - 禁止明文通信
- 认证
  - 启用 Node,RBAC 认证
  - 禁用 Token 和 Basic 认证
  - 禁用 Alwaysallow
- Admission Control
  - 禁用：AlwaysAdmit
  - 启用：AlwaysPullImages、AlwaysAdmit、EventRateLimit、ServiceAccount、NamespaceLifecycle、PodSecurityPolicy、NodeRestriction
- 关闭 profiling
- 启用审计日志
- 启用请求超时
- 启用 --service-account-lookup
- --tls-cipher-suites 仅使用新的、强加密算法
- 使用 oidc 等模式来代替客户端证书认证。
Controller Manager
- 关闭 profiling
- 开启 --use-service-account-credentials
- 绑定 127.0.0.1
- 启用 --service-account-private-key-file
- --feature-gates 启用 RotateKubeletServerCertificate
Scheduler
- 关闭 profiling
- 绑定 127.0.0.1
ETCD
- 启用节点间和客户端的双向认证
- 设置数据文件权限
- 禁用 --auto-tls
- 使用独立的 CA 证书
工作节点
- Kubelet、Kube-proxy 的服务和配置文件权限
- 关闭匿名访问
- --authorization-mode 禁用 AlwaysAllow
- kubelet 参数 --read-only-port 为 0
- --streaming-connection-idle-timeout 不应设置为 0
- --protect-kernel-defaults 设置为 true
- --make-iptables-util-chains 设置为 true
- 不要设置 --hostname-override
- HTTPS 访问
- --rotate-certificates 设置为 true
- --event-qps 设置足够高，或者为 0
- --feature-gates 启用 RotateKubeletServerCertificate
RBAC 和 ServiceAccount
- 仅在需要时才使用 cluster-admin 角色
- 限制对 secret 的访问
- 限制使用通配符
- 限制分配 Pod 创建权限
- 仅在需要时才加载 Token，缺省将 automountServic eAccountToken 为 false
- 使用不同的 ServiceAccount
Pod Security Policy
- 使用 PSP 不应泛泛使用 privileged
- 使用 PSP 谨慎控制如下授权
  - hostPID
  - hostIPC
  - hostNetwork
  - allowPrivilegeEscalation
  - runAsUser.rule
  - NET_RAW
- 不应提供全面放行的 PSP 策略
网络策略和 CNI
- 支持策略的 CNI
- 所有命名空间都定义网络策略
Secret 管理
- 建议使用文件而非环境变量
- 使用外部 Secret 存储
扩展准入控制
- 保障镜像来源
通用策略
- 命名空间隔离
- 在 Docker 中启用 seccomp
- 为 Pod 和容器启用 Security context
- 不用缺省命名空间

Loki Stack：乞丐版 EFK

Wed, 12 Feb 2020 23:27:36 +0800

简介

踩入 Kubernetes 的坑以后，不可避免的就会遇到一个需求就是日志的集中采集和检索，这方面最负盛名的就是 ElasticSearch 了，这东西的强大是毋庸置疑的——又强又大。但是我多数时间跟日志打交道只会问一个问题：特定时间范围内，某应用都输出了什么日志？强大的全文检索能力，其实是很少用到的。但无论你用或者不用，索引就在那里，吃你传输和硬盘。

Loki 给穷人们带来了福音，它是一个可水平伸缩的、高可用的以及多租户的日志集中系统，有这么多功能，唯独没有全文检索。在其简介中，自称是受到 Prometheus 的启发：仅保存和处理元数据，而对日志正文不闻不问。

和 EFK 类似，Loki Stack 也由采集端、服务端和交互端三个部分构成，其中采集端是可变的，目前支持 Promtail、FluentBit 和 Fluentd 三种，服务端和交互端分别使用的是 Loki 和 Grafana。

部署

使用 Helm 可以非常方便的部署 Loki Stack，首先使用 helm repo add loki https://grafana.github.io/loki/charts && helm repo update 加入仓库并更新。

这里使用的是 Helm 3。

helm install stable/grafana  \
    --set ingress.enabled=true \
    --set ingress.hosts={grafana.yamler.io} \
    --set persistence.enabled=true \
    --generate-name

首先安装 Grafana，并设置持久化存储以及 grafana.yamler.io 的域名。

接下来继续使用 Helm 安装 Loki：

helm install loki/loki  \
    --set persistence.enabled=true \
    --set replicas=2 --generate-name

这里为 Loki 部署了两个实例的 Statefulset。并启用了持久化存储。

最后安装 Fluentbit 作为日志采集端：

helm install fluent-bit loki/fluent-bit \
--set "loki.serviceName=loki-1581527457"

此处的服务名来自 Loki 部署的 Service 名称。

初始化

接下来登入 Grafana，添加 Loki 作为数据源，由于没有开启认证，因此只需要设置 URL 即可，例如：http://loki-1581527457:3100。添加之后，就可以点击 Explore 按钮进入查询交互了。

查询

Grafana 中为 Loki 提供了两种类型的查询，分别是 Metrics 和 Log，也就是统计数字和日志本体。

Loki 使用一种称为 LogQL 的语法来进行日志检索，语法类似 PromQL。例如假设要查询 Loki 的日志：{app="loki"}

当然也可以使用 node、container 等标签进行查询。具体标签生成的过程完全在采集器内部进行定义。

又或者查询一个 Metrics：

sum(count_over_time({job="fluent-bit"}[5m])) by (level)，统计该任务的日志生成数量：

结论

除了上面演示的简单功能之外，Loki 还支持认证、监控、跟踪、多租户等丰富的功能（而且免费）。因此如果对全文检索没有执着需求的话，Loki 应该是个非常合适的替代方案，能很好很便宜地满足前面提到的简单需求。

介绍一个不太小的工具——Stash

Fri, 31 Jan 2020 23:34:25 +0800

AppCode Stash 是一个构建在 Restic 基础之上的工具，用于备份 Kubernetes 上运行的有状态应用，它使用一个有趣的 Sidecar，能够方便的通过共享卷的方式来对 RWO 模式的存储卷进行备份。提供了批量备份、备份模板、可扩展的应用（主要是数据库）备份等功能。备份目标包括 Kubernetes 卷、S3 等常见设施。主要功能包括：

备份和恢复工作负载数据：包括 Deploy、DaemonSet、StatefulSet 等等。
备份和恢复独立存储卷。
备份和恢复数据库：PostgreSQL、MySQL、MongoDB、ElasticSearch。
卷快照：支持 CSI 卷快照功能的集群。
计划备份。
自动备份：使用注解和模板进行备份。
多种备份存储目标：支持 S3、Azure、GCP 以及存储卷等多种设施。
可监控：支持 Prometheus 监控。
提供 kubectl 插件。
可扩展开发。
支持 hook 和 Webhook。

安装

使用 Helm 3 安装：

$ helm repo add appscode https://charts.appscode.com/stable/
"appscode" has been added to your repositories
$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "appscode" chart repository
...
Update Complete. ⎈ Happy Helming!⎈
$ helm search repo appscode/stash --version v0.9.0-rc.4
NAME            CHART VERSION APP VERSION DESCRIPTION
appscode/stash  v0.9.0-rc.4    v0.9.0-rc.4  Stash by AppsCode - Backup your Kubernetes Volumes

$ helm install stash-operator appscode/stash \
  --version v0.9.0-rc.4 \
  --namespace kube-system

完成之后，可以使用如下命令进行校验：

$ kubectl get pods --all-namespaces -l app=stash --watch
NAMESPACE     NAME                              READY     STATUS    RESTARTS   AGE
kube-system   stash-operator-859d6bdb56-m9br5   2/2       Running   2          5s
$ kubectl get crd -l app=stash
NAME                                 AGE
recoveries.stash.appscode.com        5s
repositories.stash.appscode.com      5s
restics.stash.appscode.com           5s

安装完毕之后，就可以尝试第一次备份操作了。

创建备份后端

这里简单使用一个 PVC 来做为备份存储的后端。

Restic 的备份过程需要指定一个密码，这里使用一个 Secret 来保存密码：

$ echo -n 'changeit' > RESTIC_PASSWORD
$ kubectl create secret generic backup-password --from-file=./RESTIC_PASSWORD
secret/local-secret created

接下来创建一个 PVC，作为备份文件的存储目标：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: backend-pvc
spec:
  resources:
    requests:
      storage: 8Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce

在 Stash 中新建一个 Repository，用刚才的 PVC 作为存储：

apiVersion: stash.appscode.com/v1alpha1
kind: Repository
metadata:
  name: backend-repository
spec:
  backend:
    local:
      mountPath: /storage/data
      persistentVolumeClaim:
        claimName: backend-pvc
    storageSecretName: backup-password

此处的 local 段，指明了在本地加载一个卷作为备份文件的存储目标。官方文档中介绍了各种存储后端的用法。

storageSecretName 除了刚才提到的备份密码之外，还用于存储后端的认证凭据，例如使用 S3 后端就需要这样的 Secret：

$ echo -n 'changeit' > RESTIC_PASSWORD
$ echo -n '<your-azure-storage-account-name>' > AZURE_ACCOUNT_NAME
$ echo -n '<your-azure-storage-account-key>' > AZURE_ACCOUNT_KEY
$ kubectl create secret generic -n demo azure-secret \
    --from-file=./RESTIC_PASSWORD \
    --from-file=./AZURE_ACCOUNT_NAME \
    --from-file=./AZURE_ACCOUNT_KEY
secret/azure-secret created

创建工作负载

接下来随便运行一个应用，挂载 PVC 来模拟业务应用来进行备份。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
        version: v1
    spec:
      containers:
        - name: sleep
          image: dustise/sleep
          imagePullPolicy: IfNotPresent
          resources:
            limits:
              cpu: 100m
              memory: 100M
            requests:
              cpu: 100m
              memory: 100M
          volumeMounts:
          - name: storage
            mountPath: /data
      volumes:
        - name: storage
          persistentVolumeClaim:
            claimName: workload-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: workload-pvc
spec:
  resources:
    requests:
      storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce

Pod 正常运行后，生成一个文件：

$ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
sleep-76b447c854-7xmgf   1/1     Running   0          9m17s
$ kubectl exec -it sleep-76b447c854-7xmgf -c sleep -- fallocate -l 5M /data/file-5m.txt
$ kubectl exec -it sleep-76b447c854-7xmgf -c sleep ls /data
file-5m.txt     lost+found

备份

BackupConfiguration 是一个 CRD，用于连接工作负载和备份存储目标。

apiVersion: stash.appscode.com/v1beta1
kind: BackupConfiguration
metadata:
  name: backupconfig-sleep
spec:
  repository:
    name: backend-repository
  # 每五分钟一次备份
  schedule: "*/5 * * * *"
  target:
    ref:
      apiVersion: apps/v1
      kind: Deployment
      name: sleep
    # 加载工作负载中的卷
    volumeMounts:
    - name: storage
      mountPath: /data
    paths:
    - /data
  retentionPolicy:
    name: 'keep-last-5'
    keepLast: 5
    prune: true

创建之后，会发现业务 Pod 被注入了 Sidecar，正在重启。

$ kubectl get pods
NAME                     READY   STATUS              RESTARTS   AGE
sleep-569b786766-mwmrb   0/2     ContainerCreating   0          3s
sleep-76b447c854-7bvtz   1/1     Running             0          10m

并且系统中出现了新的 CronJob 和 BackupSession 对象：

$ kubectl get cronjob
NAME                              SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
stash-backup-backupconfig-sleep   */5 * * * *   False     0        4m31s           36m

$ kubectl get backupsession
NAME                            INVOKER-TYPE          INVOKER-NAME         PHASE       AGE
backupconfig-sleep-1580535011   BackupConfiguration   backupconfig-sleep   Succeeded   39s

上面看到，这个 BackupSession 已经成功了一次，就可以看看 Repository 有没有什么变化了：

$ kubectl get repository
NAME                 INTEGRITY   SIZE   SNAPSHOT-COUNT   LAST-SUCCESSFUL-BACKUP   AGE
backend-repository   true               5                4m58s                    61m

Describe 一下这个对象，会看到其中包含的快照数量，以及文件尺寸。

恢复

备份之后，我们新建一个 Deployment，作为恢复的目标：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep-restore
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep-restore
  template:
    metadata:
      labels:
        app: sleep-restore
        version: v1
    spec:
      containers:
        - name: sleep-restore
          image: dustise/sleep
          imagePullPolicy: IfNotPresent
          resources:
            limits:
              cpu: 100m
              memory: 100M
            requests:
              cpu: 100m
              memory: 100M
          volumeMounts:
          - name: storage
            mountPath: /data
      volumes:
        - name: storage
          persistentVolumeClaim:
            claimName: restore-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restore-pvc
spec:
  resources:
    requests:
      storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce

然后创建一个 RestoreSession 对象：

apiVersion: stash.appscode.com/v1beta1
kind: RestoreSession
metadata:
  name: deployment-restore
spec:
  repository:
    name: backend-repository
  rules:
  - paths:
    - /data
  target:
    ref:
      apiVersion: apps/v1
      kind: Deployment
      name: sleep-restore
    volumeMounts:
    - name:  storage
      mountPath: /data

使用 kubectl 提交对象，启动还原过程。

通过 kubectl get po 的观察，可以看到新建的 Pod 也重启了，这次加入的不是 Sidecar，而是一个 init-container。容器重建之后，可以进入 Pod 查看，例如：

$ kubectl exec -it sleep-restore-76ff947f9b-s52px ls /data
file-5m.txt     lost+found

其它

除了 Deployment 之外，Stash 还支持 Statefulset、Daemonset 的备份。另外能通过 AppBind 和 Task 等对象完成针对特定数据库的备份和恢复；通过 BackupBatch 来实现一个应用多种数据的备份；最后更可以使用 BackupPrint 对象根据 Annotation 进行自动备份。

缺点也是有的：

目前只是 RC 版本。
后面提到的几种功能复杂性都比本文演示的 Deployment 备份要复杂得多。
文档非常好，但是不够完善，并且略有瑕疵。
注入过程会引发业务中断。
…

用在生产环境还是颇为冒险的，好在备份恢复从来就不是个容易的事情，这东西至少有很好的参考价值。

Kubernetes 权威指南第二章校对（3）

Thu, 30 Jan 2020 23:12:47 +0800

春节宅在家伺候小祖宗，可惜老外们不休息，新东西一坨接着一坨，安装部分又超级没有技术含量，因此疯狂拖延。今天终于把二进制安装过程的 API Server 部分弄好。这部分还只有一个 API Server，后续内容的推进过程中，还有很大的可能发生变化。太讨厌了——第二章可能是个修身养性的章节。

首先是觉得在 service 里面引用环境变量的方式似乎没有什么特别的好处。因此丢弃了环境变量文件，直接把参数写入了 Service 文件。

其次，匿名访问、http 访问都是严重不建议的方式，现稿虽然后面加入了证书相关内容，难免造成误导，这里直接把证书内容加入到每个组件的安装过程之中，让读者在跳着读时候，也能够收到一个相对完整的效果。

更新后的 kube-apiserver.service：

[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=etcd.service
Wants=etcd.service
[Service]
ExecStart=/usr/bin/kube-apiserver \
--allow-privileged=true \
--authorization-mode=Node,RBAC \
--client-ca-file=/etc/kubernetes/pki/ca.crt \
--enable-admission-plugins=NodeRestriction \
--enable-bootstrap-token-auth=true \
--etcd-cafile=/etc/kubernetes/pki/ca.crt \
--etcd-certfile=/etc/kubernetes/pki/etcd-client.crt \
--etcd-keyfile=/etc/kubernetes/pki/etcd-client.key \
--etcd-servers=https://127.0.0.1:2379 \
--insecure-port=0 \
--kubelet-client-certificate=/etc/kubernetes/pki/kubelet-client.crt \
--kubelet-client-key=/etc/kubernetes/pki/kubelet-client.key \
--kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname \
--secure-port=6443 \
--service-cluster-ip-range=10.96.0.0/12 \
--tls-cert-file=/etc/kubernetes/pki/apiserver.crt \
--tls-private-key-file=/etc/kubernetes/pki/apiserver.key
Restart=on-failure
Type=notify
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target

kube-apiserver 需要一系列的数字证书才能启动。必要的证书参数包括：

--client-ca-file：客户端（例如 kubectl）使用客户端证书作为凭据访问 apiserver 时，用于签发客户端证书的 ca 证书文件。
--etcd-cafile、--etcd-certfile、--etcd-keyfile：apiserver 作为客户端，使用 https 协议访问 etcd 时，所信任的 ca 证书文件，以及客户端证书文件和密钥。
--kubelet-client-certificate、--kubelet-client-key：apiserver 访问 kubelet 时所使用的证书文件和密钥。
--tls-cert-file、--tls-private-key-file：apiserver 提供 https 服务时所使用的证书文件和密钥。

etcd 一节中，我们已经了解了服务器证书的生成方法，这里为了简单起见，把所有用于签发证书的 ca 证书统一为前面生成过的 /etc/kubernetes/pki/ca.crt。几个证书参数中，只有 --tls-cert-file 是和前面的 etcd-server.crt 一样的https 服务端证书，生成方法是一样的，差别在于 [alt_names] 字段，其中除了包括服务器的 IP 之外，还包含了几个 DNS 名称，代表的是缺省的 Kubernetes 服务，摘录如下：

DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster.local
IP.1 = 10.211.55.33
IP.2 = 127.0.0.1

使用这个cnf文件生成apiserver的服务端密钥和证书文件：

# openssl genrsa -out apiserver.key 2048
# openssl req -new -key apiserver.key -subj "/CN=kubernetes" -config apiserver.cnf -out apiserver.csr
# openssl x509 -req -in apiserver.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out apiserver.crt -days 365 -extensions v3_req -extfile apiserver.cnf

这些命令执行成功后，生成 apiserver.key 和 apiserver.crt 两个文件，这两个证书将用于 apiserver 的--tls-private-key-file、--tls-cert-file 两个参数。

生成 apiserver 的服务端证书后，还需要为 etcd 和 kubelet 生成客户端证书。客户端证书相对简单，主要关注的是 -subj 参数。

首先是 etcd 的客户端证书，设置 CN=apiserver，OU=kubernetes：

# openssl genrsa -out etcd-client.key 2048
# openssl req -new -out etcd-client.csr -key etcd-client.key -subj "/CN=apiserver/OU=kubernetes"
# openssl x509 -req -in etcd-client.csr -out etcd-client.crt -signkey etcd-client.key -CA ca.crt -CAkey ca.key -CAcreateserial -days 365

类似地，生成 kubelet 客户端证书，和 etcd 客户端类似，不同是的 -subj 参数，命令如下：

# openssl genrsa -out kubelet-client.key 2048
# openssl req -new -out kubelet-client.csr -key kubelet-client.key -subj "/CN= kube-apiserver-kubelet-client /OU= system:masters"
# openssl x509 -req -in kubelet-client.csr -out kubelet-client.crt -signkey kubelet-client.key -CA ca.crt -CAkey ca.key -CAcreateserial -days 365

service文件和一系列的证书都生成完毕之后，用如下命令启动kube-apiserver服务：

# systemctl daemon-reload
# systemctl start kube-apiserver

服务启动之后，可以使用 curl 尝试访问 apiserver 的端口：

# curl https://127.0.0.1:6443
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {

  },
  "code": 403
}

返回了鉴权失败的信息，证明 apiserver 在正常运行了。

浅谈 Kubernetes 中的服务发现

Wed, 29 Jan 2020 09:42:04 +0800

原文：Demystifying Kubernetes service discovery

作者：Nigel Poulton

Kubernetes 服务发现是一个经常让我产生困惑的主题之一。本文分为两个部分：

网络方面的背景知识
深入了解 Kubernetes 服务发现

要了解服务发现，首先要了解背后的网络知识。这部分内容相对浅显，如果读者熟知这一部分，完全可以跳过，直接阅读服务发现部分。

开始之前还有一个需要提醒的事情就是，为了详细描述这一过程，本文略长。

Kubernetes 网络基础

要开始服务发现的探索之前，需要理解以下内容：

Kubernetes 应用运行在容器之中，容器处于 Pod 之内。
每个 Pod 都会附着在同一个大的扁平的 IP 网络之中，被称为 Pod 网络（通常是 VXLAN 叠加网络）。
每个 Pod 都有自己的唯一的 IP 地址，这个 IP 地址在 Pod 网络中是可路由的。

上述三个因素结合起来，让每个应用（应用的组件和服务）无需通过 NAT 之类的网络过程，就能够直接通信。

动态网络

在对应用进行横向扩容时，会在 Pod 网络中加入新的 Pod，新 Pod 自然也伴随着新的 IP 地址；如果对应用进行缩容，旧的 Pod 及其 IP 会被删除。这个过程看起来很是混乱。

应用的滚动更新和撤回也存在同样的情形——加入新版本的新 Pod，或者移除旧版本的旧 Pod。新 Pod 会加入新 IP 到 Pod 网络中，被终结的旧 Pod 会删除其现存 IP。

如果没有其它因素，每个应用服务都需要对网络进行监控，并管理一个健康 Pod 的列表。这个过程会非常痛苦，另外在每个应用中编写这个逻辑也是很低效的。幸运的是，Kubernetes 用一个对象完成了这个过程——Service。

把这个对象叫做 Service 是个坏主意，我们已经用这个单词来形容应用的进程或组件了。

还有一个值得注意的事情：Kubernetes 执行 IP 地址管理（IPAM）职责，对 Pod 网络上已使用和可用的 IP 地址进行跟踪。

Service 带来稳定性

Kubernetes Service 对象在一组提供服务的 Pod 之前创建一个稳定的网络端点，并为这些 Pod 进行负载分配。

一般会在一组完成同样工作的 Pod 之前放置一个 Service 对象。例如可以在你的 Web 前端 Pod 前方提供一个 Service，在认证服务 Pod 之前提供另一个。行使不同职责的 Pod 之前就不应该用单一的 Service 了。

客户端和 Service 通信，Service 负责把流量负载均衡给 Pod。

在上图中，底部的 Pod 会因为伸缩、更新、故障等情况发生变化，而 Service 会对这些变化进行跟踪。同时 Service 的名字、IP 和端口都不会发生变化。

Kubernetes Service 解析

可以把 Kubernetes Service 理解为前端和后端两部分：

前端：名称、IP 和端口等不变的部分。
后端：符合特定标签选择条件的 Pod 集合。

前端是稳定可靠的，它的名称、IP 和端口在 Service 的整个生命周期中都不会改变。前端的稳定性意味着无需担心客户端 DNS 缓存超时等问题。

后端是高度动态的，其中包括一组符合标签选择条件的 Pod，会通过负载均衡的方式进行访问。

这里的负载均衡是一个简单的 4 层轮询。它工作在连接层面，所以同一个连接里发起的所有请求都会进入同一个 Pod。因为在 4 层工作，所以对于 7 层的 HTTP 头或者 Cookie 之类的东西是无法感知的。

小结

应用在容器中运行，在 Kubernetes 中体现为 Pod 的形式。Kubernetes 集群中的所有 Pod 都处于同一个平面的 Pod 网络，有自己的 IP 地址。这意味着所有的 Pod 之间都能直接连接。然而 Pod 是不稳定的，可能因为各种因素创建和销毁。Kubernetes 提供了稳定的网络端点，称为 Service，这个对象处于一组相似的 Pod 前方，提供了稳定的名称、IP 和端口。客户端连接到 Service，Service 把流量负载均衡给 Pod。

接下来聊聊服务发现。

深入了解 Kubernetes 服务发现

服务发现实际上包含两个功能点：

服务注册
服务发现

服务注册

服务注册过程指的是在服务注册表中登记一个服务，以便让其它服务发现。

Kubernetes 使用 DNS 作为服务注册表。

为了满足这一需要，每个 Kubernetes 集群都会在 kube-system 命名空间中用 Pod 的形式运行一个 DNS 服务，通常称之为集群 DNS。

每个 Kubernetes 服务都会自动注册到集群 DNS 之中。

注册过程大致如下：

向 API Server 用 POST 方式提交一个新的 Service 定义；
这个请求需要经过认证、鉴权以及其它的准入策略检查过程之后才会放行；
Service 得到一个 ClusterIP（虚拟 IP 地址），并保存到集群数据仓库；
在集群范围内传播 Service 配置；
集群 DNS 服务得知该 Service 的创建，据此创建必要的 DNS A 记录。

上面过程中，第 5 个步骤是关键环节。集群 DNS 使用的是 CoreDNS，以 Kubernetes 原生应用的形式运行。CoreDNS 实现了一个控制器，会对 API Server 进行监听，一旦发现有新建的 Service 对象，就创建一个从 Service 名称映射到 ClusterIP 的域名记录。这样 Service 就不必自行向 DNS 进行注册，CoreDNS 控制器会关注新创建的 Service 对象，并实现后续的 DNS 过程。

DNS 中注册的名称就是 metadata.name，而 ClusterIP 则由 Kubernetes 自行分配。

Service 对象注册到集群 DNS 之中后，就能够被运行在集群中的其它 Pod 发现了。

Endpoint 对象

Service 的前端创建成功并注册到服务注册表（DNS）之后，剩下的就是后端的工作了。后端包含一个 Pod 列表，Service 对象会把流量分发给这些 Pod。

毫无疑问，这个 Pod 列表需要是最新的。

Service 对象有一个 Label Selector 字段，这个字段是一个标签列表，符合列表条件的 Pod 就会被服务纳入到服务的负载均衡范围之中。参见下图：

Kubernetes 自动为每个 Service 创建 Endpoints 对象。Endpoints 对象的职责就是保存一个符合 Service 标签选择器标准的 Pod 列表，这些 Pod 将接收来自 Service 的流量。

下面的图中，Service 会选择两个 Pod，并且还展示了 Service 的 Endpoints 对象，这个对象里包含了两个符合 Service 选择标准的 Pod 的 IP。

在后面我们将解释网络如何把 ClusterIP 流量转发给 Pod IP 的过程，还会引用到 Endpoints 对象。

服务发现

假设我们在一个 Kubernetes 集群中有两个应用，my-app 和 your-app，my-app 的 Pod 的前端是一个名为 my-app-svc 的 Service 对象；your-app Pod 之前的 Service 就是 your-app-svc。

这两个 Service 对象对应的 DNS 记录是：

my-app-svc：10.0.0.10
your-app-svc：10.0.0.20

要使用服务发现功能，每个 Pod 都需要知道集群 DNS 的位置才能使用它。因此每个 Pod 中的每个容器的 /etc/resolv.conf 文件都被配置为使用集群 DNS 进行解析。

如果 my-app 中的 Pod 想要连接到 your-app 中的 Pod，就得向 DNS 服务器发起对域名 your-app-svc 的查询。假设它们本地的 DNS 解析缓存中没有这个记录，则需要把查询提交到集群 DNS 服务器。会得到 you-app-svc 的 ClusterIP（VIP）。

这里有个前提就是 my-app 需要知道目标服务的名称。

至此，my-app 中的 Pod 得到了一个目标 IP 地址，然而这只是个虚拟 IP，在转入目标 Pod 之前，还有些网络工作要做。

网络

一个 Pod 得到了 Service 的 ClusterIP 之后，就尝试向这个 IP 发送流量。然而 ClusterIP 所在的网络被称为 Service Network，这个网络有点特别——没有路由指向它。

因为没有路由，所有容器把发现这种地址的流量都发送到了缺省网关（名为 CBR0 的网桥）。这些流量会被转发给 Pod 所在节点的网卡上。节点的网络栈也同样没有路由能到达 Service Network，所以只能发送到自己的缺省网关。路由到节点缺省网关的数据包会通过 Node 内核——这里有了变化。

回顾一下前面的内容。首先 Service 对象的配置是全集群范围有效的，另外还会再次说到 Endpoints 对象。我们要在回顾中发现他们各自在这一过程中的职责。

每个 Kubernetes 节点上都会运行一个叫做 kube-proxy 的系统服务。这是一个基于 Pod 运行的 Kubernetes 原生应用，它所实现的控制器会监控 API Server 上 Service 的变化，并据此创建 iptables 或者 IPVS 规则，这些规则告知节点，捕获目标为 Service 网络的报文，并转发给 Pod IP。

有趣的是，kube-proxy 并不是一个普遍意义上的代理。它的工作不过是创建和管理 iptables/IPVS 规则。这个命名的原因是它过去使用 unserspace 模式的代理。

每个新 Service 对象的配置，其中包含它的 ClusterIP 以及 Endpoints 对象（其中包含健康 Pod 的列表），都会被发送给每个节点上的 kube-proxy 进程。kube-proxy 会创建 iptables 或者 IPVS 规则，告知节点捕获目标为 Service ClusterIP 的流量，并根据 Endpoints 对象的内容转发给对应的 Pod。

也就是说每次节点内核处理到目标为 Service 网络的数据包时，都会对数据包的 Header 进行改写，把目标 IP 改为 Service Endpoints 对象中的健康 Pod 的 IP。

原本使用的 iptables 正在被 IPVS 取代（Kubernetes 1.11 进入稳定期）。长话短说，iptables 是一个包过滤器，并非为负载均衡设计的。IPVS 是一个 4 层的负载均衡器，其性能和实现方式都比 iptables 更适合这种使用场景。

总结

需要消化的内容很多，简单回顾一下。

创建新的 Service 对象时，会得到一个虚拟 IP，被称为 ClusterIP。服务名及其 ClusterIP 被自动注册到集群 DNS 中，并且会创建相关的 Endpoints 对象用于保存符合标签条件的健康 Pod 的列表，Service 对象会向列表中的 Pod 转发流量。

与此同时集群中所有节点都会配置相应的 iptables/IPVS 规则，监听目标为 ClusterIP 的流量并转发给真实的 Pod IP。这个过程如下图所示：

一个 Pod 需要用 Service 连接其它 Pod。首先向集群 DNS 发出查询，把 Service 名称解析为 ClusterIP，然后把流量发送给位于 Service 网络的 ClusterIP 上。然而没有到 Service 网络的路由，所以 Pod 把流量发送给它的缺省网关。这一行为导致流量被转发给 Pod 所在节点的网卡，然后是节点的缺省网关。这个操作中，节点的内核修改了数据包 Header 中的目标 IP，使其转向健康的 Pod。

最终所有 Pod 都是在同一个可路由的扁平的叠加网络上，剩下的内容就很简单了。

CSI 的内联暂存卷

Fri, 24 Jan 2020 14:35:19 +0800

原文：CSI Ephemeral Inline Volumes

作者：Patrick Ohly

Kubernetes 利用外部存储驱动提供出来的存储卷一般来说都是持久化的，它的生命周期可以完全独立于 Pod，（特定情况下）也可以和第一个用到该卷的 Pod（后绑定模式）有着宽松的耦合关系。在 Kubernetes 中使用 PVC 和 PV 对象完成了存储卷的申请和供给机制。起初，容器存储接口（CSI）支持的存储卷只能用于 PVC/PV 的场合。

但有些情况下，数据卷的内容和生命周期是和 Pod 紧密相关的。例如有的驱动会使用动态的创建 Secret 生成卷，这个 Secret 是为了运行在 Pod 中的应用特意创建的。这种卷需要和 Pod 一起生成，并且作为 Pod 的一部分，和 Pod 一起终结。可以在 Pod Spec 中（用内联/inline 的方式）定义这种卷。

从 Kubernetes 1.15 开始，CSI 驱动也能用于这种内联暂存卷了。这个功能还处于 Alpha 阶段，因此在 1.15 中需要打开 CSIInlineVolume 特性开关才能尝试使用这一新功能。而 1.16 中，该功能升级为 Beta 阶段，因此是缺省打开的。

虽说这个功能用到了两个现存的 gRPC 调用（NodePublishVolume 和 NodeUnpublishVolume)，但是其中的用法和 CSI 规范并不一致：在暂存卷中，Kubelet 在向 CSI 驱动请求卷时，只调用了 NodePublishVolume。跳过了其他的（例如 CreateVolume、NodeStageVolume）调用，所以要对 CSI 驱动进行一些改变。Pod Spec 中写明了卷参数，这个参数会被拷贝给 NodePublishVolumeRequest.volume_context。目前没有标准化的参数，即使是容量这种参数也是定义在 CSI 驱动之中的。类似地，在 Pod 结束需要释放存储卷时，只调用了 NodeUnpublishVolume。

起初有考虑分别为持久化和暂存卷编写不同的 CSI 驱动。但是有些驱动提供的存储在两种模式下都可以使用，例如 PMEM-CSI 管理的是由 Intel Optane 技术提供的持久化内存方式的本地存储。这种类型的存储既可以用作一种比普通 SSD 更快的持久化存储，也可以用作比 DRAM 更大容量的暂时性存储。

因此在 Kubernetes 1.16 中产生了变化：用户可以使用 CSIDriver 的 volumeLifecycleModes 字段来确定该驱动支持的卷类型。启用加载时 Pod 信息功能之后，驱动程序能够获取卷模式的信息，并在 NodePublishRequest.volume_context 加入 csi.storage.k8s.io/ephemeral。

关于 CSI 驱动支持内联暂存卷的更多信息，可以浏览 Kubernetes CSI 文档及其原始设计文档。

后续内容中包含了真实的示例以及内容总结。

示例

PMEM-CSI

在 v0.6.0 中加入了内联暂存的支持。在使用 Intel Optane 技术的主机上可以使用这种驱动，GCE 的特定类型服务器或者 QEMU 的硬件模拟上都是可用的。QEMU 方式已经集成到了 Makefile，只需要 Go、Docker 和 KVM 即可，所以示例中用了这种方式：

git clone --branch release-0.6 https://github.com/intel/pmem-csi
cd pmem-csi
TEST_DISTRO=clear TEST_DISTRO_VERSION=32080 TEST_PMEM_REGISTRY=intel make start

启动四节点集群需要一些时间：

The test cluster is ready. Log in with /work/pmem-csi/_work/pmem-govm/ssh-pmem-govm, run kubectl once logged in.
Alternatively, KUBECONFIG=/work/pmem-csi/_work/pmem-govm/kube.config can also be used directly.

To try out the pmem-csi driver persistent volumes:
...

To try out the pmem-csi driver ephemeral volumes:
   cat deploy/kubernetes-1.17/pmem-app-ephemeral.yaml | /work/pmem-csi/_work/pmem-govm/ssh-pmem-govm kubectl create -f -

deploy/kubernetes-1.17/pmem-app-ephemeral.yaml 定义了一个卷：

kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app-inline-volume
spec:
  containers:
    - name: my-frontend
      image: busybox
      command: [ "sleep", "100000" ]
      volumeMounts:
      - mountPath: "/data"
        name: my-csi-volume
  volumes:
  - name: my-csi-volume
    csi:
      driver: pmem-csi.intel.com
      fsType: "xfs"
      volumeAttributes:
        size: "2Gi"
        nsmode: "fsdax"

Pod 启动之后，可以观察一下：

$ kubectl describe pods/my-csi-app-inline-volume
Name:         my-csi-app-inline-volume
...
Volumes:
  my-csi-volume:
    Type:              CSI (a Container Storage Interface (CSI) volume source)
    Driver:            pmem-csi.intel.com
    FSType:            xfs
    ReadOnly:          false
    VolumeAttributes:      nsmode=fsdax
                           size=2Gi
$ kubectl exec my-csi-app-inline-volume -- df -h /data
Filesystem                Size      Used Available Use% Mounted on
/dev/ndbus0region0fsdax/d7eb073f2ab1937b88531fce28e19aa385e93696
                          1.9G     34.2M      1.8G   2% /data

Image Populator

自动解包容器镜像，并以暂存卷的方式访问内容。这个驱动还在开发之中，但是可以用下面的方式安装试用镜像：

kubectl create -f https://github.com/kubernetes-csi/csi-driver-image-populator/raw/master/deploy/kubernetes-1.16/csi-image-csidriverinfo.yaml
kubectl create -f https://github.com/kubernetes-csi/csi-driver-image-populator/raw/master/deploy/kubernetes-1.16/csi-image-daemonset.yaml

下面这个 Pod 会运行一个 Nginx，并从 kfox1111/misc:test 镜像中获取数据提供服务：

$ kubectl create -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.13-alpine
    ports:
    - containerPort: 80
    volumeMounts:
    - name: data
      mountPath: /usr/share/nginx/html
  volumes:
  - name: data
    csi:
      driver: image.csi.k8s.io
      volumeAttributes:
          image: kfox1111/misc:test
EOF

测试一下读取数据：

$ kubectl exec nginx -- cat /usr/share/nginx/html/test
testing

cert-manager-csi

这个驱动和 cert-manager 协同工作，其目的是无缝地为 Pod 完成证书的请求和加载。这对于 mTLS 或者其它需要使用可信、有效证书的 Pod 间安全连接的工作是很有意义的。这个项目还在实验之中。

下一步

提出这个功能的原因之一就是，Kubernetes 把一个 Pod 调度到节点上时，对节点的存储情况是无知的。Pod 被调度之后，CSI 必须在该节点上创建卷。如果失败，Pod 无法启动，这个过程会一直持续到存储卷可用。存储能力跟踪的 KEP 是一个解决问题的尝试。

另外还有一个相关的用于标准化容量参数的 KEP。

Kubernetes 权威指南第二章校对（2）

Sat, 18 Jan 2020 00:06:57 +0800

校对的错误

san 同学不经意的一扫，就看到了上一篇中的两个错误：

Kubeadm 文档中虽然没提到对 CPU 的检测，实际上单核虚拟机运行是会被 preflight 拒绝的。
preflight 步骤中的：sockert 应为 socket。

书接前回

近期俗务缠身，第二章的二进制部分又有较多需要更新的内容，因此拖延的比较厉害，见谅见谅。

二进制部署这部分和现状的主要差别是：

https 已经是标配，而书中用分离的方式来讲述证书部分，显得强调不足。
Kubernetes 的二进制文件下载方式发生了一些变化。
etcd 的配置和验证方法也要更新。

关于 ca 证书

出于安全方面的考虑，Kubernetes 各组件之间的通信都要求使用 https 通信来完成，这就要求我们要为参与通信的各种组件提供证书来支持 https 通信。一般来说，因为都是内部通信，会采用自签署的根证书来签发其它所有证书。统一的根证书有利于建立信任关系，操作也更加方便，因此这里使用单一 CA 的方案。

生成自签署根证书很容易：

# openssl genrsa -out ca.key 2048
Generating RSA private key, 2048 bit long modulus
...+++
...........................................................................................................................
.....................................+++
e is 65537 (0x10001)
# openssl req -subj "/CN=Kubernetes CA" -new -x509 -days 3650 -key ca.key -out ca.crt

这里需要注意的是 -days 参数，这个参数代表的是 ca 的有效期，后续的内容中也会看到这个参数，建议读者认真对待这个参数，防止后面的使用过程中，因为证书失效造成不必要的损失。把新生成的证书和密钥保存到 /etc/kubernetes/pki/，后面我们将会使用这个 ca 签署其它的证书。自签发的 ca 证书应该加入到集群中所有节点的信任列表之中，以保证该 ca 签发的证书能够得到所有节点的信任。例如在 CentOS 7 中需要使用如下命令：

# cp ca.crt /etc/pki/ca-trust/source/anchors/
# update-ca-trust

etcd服务

etcd 是 Kubernetes 集群的主数据库，需要在安装 Kubernetes 各服务之前完成安装和启动。

从官方 GitHub 可以找到 etcd 的发行包，下载解压之后，将 etcd 和 etcdctl 文件复制到 /usr/bin目录。

为 etcd 编写 systemd 服务配置文件（/usr/lib/systemd/system/etcd.service）：

[Unit]
Description=Etcd Server
After=network.target
[Service]
Type=notify
ExecStart=/usr/bin/etcd \
  --data-dir=/var/lib/etcd \
  --client-cert-auth=false \
  --cert-file=/etc/kubernetes/pki/etcd-server.crt \
  --key-file=/etc/kubernetes/pki/etcd-server.key \
  --trusted-ca-file=/etc/kubernetes/pki/ca.crt \
  --listen-client-urls=https://127.0.0.1:2379,https://10.211.55.33:2379 \
  --advertise-client-urls=https://10.211.55.33:2379 \
  --name=kubguide1
Restart=always
RestartSec=10s
LimitNOFILE=40000
[Install]
WantedBy=multi-user.target

--data-dir 参数指定了 etcd 的数据存储路径。在实际环境中需要注意：etcd 承担了整个集群的核心存储工作，因此对所在磁盘的性能是有较高需求的。

--listen-client-urls 定义了 etcd 服务器的监听地址。 --cert-file、--key-file 以及 --trusted-ca-file 三个参数的组合形成了一个 ca 到证书的信任链：不论是 etcd 自身还是和 etcd 进行通信的kube-apiserver，都强烈建议使用 https 进行通信，因此上面的命令行中设置了一组证书。

在启动之前，要使用前面的 ca 文件签发一个 etcd 服务器的证书。

为证书编写一个配置文件 etcd-server.cnf：

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost
IP.1 = 10.211.55.33
IP.2 = 127.0.0.1

文件中的 DNS 和 IP 字段应该覆盖 etcd 服务器的所有监听地址。

生成证书密钥：

# openssl genrsa -out etcd-server.key 2048

生成签发请求：

# openssl req -new -key etcd-server.key -subj "/CN=etcd-server" \
    -config etcd-server.cnf -out etcd-server.csr

签发证书：

# openssl x509 -req -in etcd-server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
    -out etcd-server.crt -days 365 -extensions v3_req -extfile etcd-server.cnf

完成证书生成步骤之后，把 *.key 和 *.crt 文件保存到 /etc/kubernetes/pki 目录中，就可以通过systemctl start命令启动 etcd 服务了。同时，使用 systemctl enable 命令将服务加入开机启动列表中：

# systemctl daemon-reload
# systemctl enable etcd.service
# systemctl start etcd.service

通过执行 etcdctl cluster-health，可以验证 etcd 是否正确启动：

# etcdctl --endpoints https://127.0.0.1:2379 cluster-health
member 8e9e05c52164694d is healthy: got healthy result from https://10.211.55.33:2379
cluster is healthy

一个小工具：Hadolint

Sun, 12 Jan 2020 22:12:50 +0800

Hadolint 是使用不明觉厉的 Haskell 实现的 Dockerfile linter，其实现依据来自于 Docker 官网推荐的 Dockerfile 最佳实践。

在 Mac 下的安装只要使用简单的 brew install hadolint 就能够完成安装，其它平台也有各自的支持方式。

用法非常简单：hadolint <dockerfile> 即可，例如我们编写一个简单的 Dockerfile：

$ cat << EOF > /tmp/Dockerfile                                                                             master  ✱
heredoc> FROM alpine
heredoc> CMD ["sleep", "3600"]
heredoc> EOF

$ hadolint /tmp/Dockerfile
/tmp/Dockerfile:1 DL3006 Always tag the version of an image explicitly

可以使用 --ignore 参数忽略指定的问题，如果是固定配置，可以使用 -c 参数指定配置文件。例如下面的配置：

ignored:
  - DL3000
  - SC1010

trustedRegistries:
  - docker.io
  - my-company.com:5000

其检测范围包括在 README 有非常详细的描述，并在连接中给出了建议。

hadolint 提供了很多集成选项，可以集成到 Jenkins、Gitlab 等自动化流程中使用，在 vim、VSCode、Atom 编辑器中也可以直接生效。

README：https://github.com/hadolint/hadolint/blob/master/README.md
集成选项：https://github.com/hadolint/hadolint/blob/master/docs/INTEGRATION.md

Istiod——回到单体的理由

Sat, 11 Jan 2020 20:59:19 +0800

原文：Istio as an Example of When Not to Do Microservices

作者：Christian Posta

近五年来，我尽心尽力帮助各种组织踏入云原生之路。要让团队变得现代化并增强基于软件的产品的交付能力，人、过程以及技术决策都很重要。当应用架构的上限已经成为应对变化和加速发展的瓶颈时，微服务方法可能是合适的，但这并不是唯一的方法。

微服务并非应用架构的乌托邦。

过去，我在这方面发表了一些看法，例如我认为很多团队无法将其落地，实现过程中的困难之处，还提出了一些长远来看会对这项工作有益处的技术。甚至还写了一本书来讲述这一主题。

尽管很多组织已经踏上微服务之旅，远离微服务一文仍然可能是个好起点。

如果你已经踏上了微服务旅程

如果发现微服务不灵，就该正视现实。拨乱反正是做出成功产品的正确举措。

尽管出发点是好的，但开始使用微服务之后，开倒车还是有可能的。如果之前的假设或周遭环境已经发生了变化，重回单体架构也是可以理解的。

为微服务通信构建服务网格的 Istio 社区，控制平面的实现将最终从微服务架构转向更为单体的方式。Google API 基础设施的首席工程师和架构师 Louis Ryan，在 2019 年 KubeConNA 上讲述了这一变化的动机，并在设计文档中进行了阐述。从 Istio 1.5 开始（可能会在 2020 年 2 月中旬），我们可能就会看到 istiod 了，这个组件把前作中多个组件集成为单一进程。

Istio 用于解决因为微服务、云原生架构引入的复杂的应用网络问题，所以为什么 Istio 自身却反其道而行之？最直接答案是：

事实证明，微服务的复杂性无法实现其预期的价值或目标。相反，它违背了这些目标。

对于 Istio 项目来说，似乎单体方式能更好的为目标服务。

微服务模式的 Istio

Istio 是一个开源的服务网格产品，其实现和其它同类产品大同小异，由控制平面和数据平面组成。数据平面由反向代理服务器组成，这些反向代理和各个应用实例伴行，并替代应用行使通信职责。控制平面在请求路径之外，用于对数据平面的行为进行管控。

Istio 的控制平面分为几个组成部分，其职责如下：

Pilot：核心的数据平面配置（xDS）服务器。
Galley：配置监听、验证和转发。
Injector：负责数据平面的注册和初始化。
Citadel：证书签发、Secret 生成、CA 集成等。
Telemetry：Mixer 组件之一，负责聚合监控信息到多种后端。
Policy：Mixer 组件之二，在请求路径之中负责实现策略支持。

运维人员通过一组配置指令来借由这些部件为数据平面提供服务并对其进行控制。

微服务的好处

微服务能够降低变更过程中因为耦合产生的冲突，因此能加快组织的调整速度。有了微服务架构的帮助，每个服务都能可以有自己的团队，独立进行运维，有各自的变更频率和生命周期。这使得开发和运维能够轻装上阵，不会因为变更过程中的锁定、同步、协作等问题拖慢部署和变更的进度。

拆分成微服务的另一个原因就是它的用法和扩展方式。例如一个需要大量读写的服务，能从读写分离上受益，这是因为读取过程需要更多内存（缓存），而写入需要更多的存储或者网络资源。拆分之后就可以放心的给读取服务分配大量内存，而写入服务则可以运行在 SSD 或者 EBS/SAN 等设施加持的服务器上。

拆分微服务的另外几个理由：

安全考虑
领域分隔
针对不同语言的优化
安全分级

微服务架构的复杂性是第一号问题。当单体应用拆分为一些互相通信的小玩意之后，架构的复杂性以及对应的基础设施的复杂性都显而易见地提高了。

除非已经清楚的意识到，这是为了获得更多好处，而做出的一种必要的妥协；否则就应该对假设进行评估，并及时做出反应——这就是 Istio 现在的举措。

回头草

首先要清楚，你的服务是谁开发谁运维的。在 Istio 社区，项目里不同的工作组维持着不同的组件。另一方面，下载、安装和运维 Istio 的用户就不那么清楚了。目前看来，都是由单一的工作组（甚至一个人）在操作 Istio 的控制平面。某种程度上，一组微服务构建的 Istio 控制平面更适合被当做一个更大规模的 SaaS 看待，但是目前的情况看来并非如此。

第二个需要注意的就是部署问题。这些微服务能独自部署么？Istio 的回答是：理论上可以，但实际上可能并非如此。当新版本 Istio 发布时，需要更新/部署所有控制平面的组件。

最后一个问题：”Istio 的各个组件，有各自不同的安全考量和伸缩需求吗？“，答案也并不肯定。来自 istiod 的一段陈述：

目前看来，对于多数组件来说并非如此。然而——控制平面的成本由单一的功能（xDS）决定。相对而言，其它所有组件的消耗微不足道，因此分离并无必要。

为了安全起见，所有的控制平面都处于相同的特权级别：

当前的情况下，Mutating Webhook、Envoy Bootstrap 以及 Pilot，这几个组件的特权级别和 Citadel 基本持平，对它们的滥用所引发的损失几乎相同。

Istio 设计文档中的潜台词就是——“复杂性是万恶之源，或者换个说法：停止焦虑，爱上单体”。

istiod 是一个单体应用，它用较低的复杂性提供了和之前版本一致的功能。组成旧版控制平面的服务都还以子模块的方式存在于项目之中，但提供了更好的运维体验。操作者只需关注单一二进制文件的运行和升级了。

Istio 一旦转向单体的控制平面，会大幅降低复杂性，从而：

只需要对一个单独的服务进行部署和升级。
因为无需关注编排服务自身的配置，因此配置复杂度也降低了。
更容易除错。
提高分发、共享和缓存的效率，降低开销。

另外你可以看一下 Istiod 的 Demo 视频。这个视频基于一个早期版本，因此并不完善。

结论

很高兴看到 Istio 社区在持续提高其易用性和可运维性。转向单体应用的 Istio 带来了很多好处。这个过程会对你的项目产生什么启发么？如果有的话，你会采取什么措施么？

Kubernetes 权威指南第二章校对（1）

Mon, 06 Jan 2020 23:58:31 +0800

权威指南第二章的内容，是 Kubernetes 有史以来最经久不衰的入门话题：安装。

这里出了个巧合，编写第二章时，我负责的是 kubeadm 的部分，搭建虚拟机集群准备开始校对的时候，发现这一批虚拟机被分配的 IP 和写稿时候是一样的——10.211.55.30-32

kubeadm init

在 kubeadm init 命令配置一节，原本使用了我自己的 Docker hub 仓库，现在 AWS 提供了 gcr 镜像，这里也就顺便改成了：imageRepository: gcr.azk8s.cn/google_containers。

init 命令执行过程中，会进行预检，官方文档中也介绍了预检内容：

init命令首先会执行一段称为preflight的预检工作，对当前的服务器状况进行检查，会导致检查不通过的情况包括：

Kubnernetes 需求：
- 操作系统是否为 Linux；
- 内核是否为 3.10+ 或者 4+，并启用特定开关；
- 是否有合适的 cgroup 子系统配置；
Docker 服务不存在或者无法工作；
crictl sockert 无应答。
当前用户不是 root；
主机名称不是有效的 DNS 子域；
kubelet 版本低于 kubeadm 的要求（通常能够容忍一个小版本号的差异）；
kubelet 版本比 kubeadm 版本高出一个小版本号以上；
API Server 的绑定端口（10250、10251以及10252）被占用；
/etc/kubernetes/manifest 已经存在并且非空；
/proc/sys/net/bridge/bridge-nf-call-iptables 不存在或者内容中不包含“1”；
公布地址为 ipv6 并且 /proc/sys/net/bridge/bridge-nf-call-ip6tables 文件不存在或者内容中不包含“1”；
找不到 ip、iptables、mount 或者 nsenter 命令；
启用了交换文件；
如果指定了外部 etcd：
- 如果 etcd 版本低于 3.0.14；
- 如果 etcd 中引用了不存在的证书或密钥。
如果没有指定外部的 etcd：
- 如果 2379 端口被占用；
- 如果 Etcd.DataDir 路径已经存在并且非空；
如果认证模式为 ABAC：
- abac_policy.json 文件不存在。
如果认证模式为 WebHook：
- webhook_authz.conf 不存在。

常见的三个操作

以CentOS 7.5 Minimal版本为例，一般会有三个需要修改的地方：

关闭交换文件：

swapoff -a
删除 /etc/fstab/ 中的 swap 一行，重新启动。

使用 sysctl 设置net.bridge.bridge-nf-call-iptables 和 net.ipv4.ip_forward 为 1。

设置 Docker 配置文件 /etc/docker/daemon.json 内容如下，设置 Docker的 cgroupdriver 为 systemd，并重新启动 Docker 服务：

{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
]
}

单节点集群

该操作并非删除标签，而是去污点操作。

参考连接

预检：https://kubernetes.io/docs/reference/setup-tools/kubeadm/implementation-details/
Building large clusters：https://kubernetes.io/docs/setup/best-practices/cluster-large/

用 k8up 把 PVC 备份到 S3

Sat, 04 Jan 2020 22:04:14 +0800

k8up 是一个基于 Restic 的备份工具，可以一次性的或者周期性的把指定的 PVC 备份到 S3 协议的对象存储上去，备份内容还可以使用 Restic 恢复到 S3 或者 PVC 上。除了 PVC，后续还可以用命令的方式，例如 mysqldump，把数据库等内容备份出来。

安装和初始化

Helm 安装即可：

helm repo add appuio https://charts.appuio.ch
helm repo update
helm install appuio/k8up

安装过程会生成一系列的 CRD，会在后续步骤中使用。

后续过程中需要两个 Secret，分别用来加密备份和访问 S3：

$ kubectl create secret generic s3secret --from-literal token=[hidden] \
    --from-literal key=[hidden]
secret/s3secret created
$ kubectl create secret generic backup --from-literal password=PassW0rd
secret/backup created

备份 PVC

k8up 会选择命名空间中注解为 appuio.ch/backup: "true" 的 PVC 进行备份，我们用下文的工作负载生成两个 PVC，运行起来之后，两个 PVC 分别挂载到容器的 /data1 和 /data2 目录中，可以登录到 Pod，在其中生成文件：

$ kubectl exec -it debugger-7b8f654484-hrcg9 bash
bash-4.4# echo "Hello world" > /data/data.txt

创建一次性任务：

apiVersion: backup.appuio.ch/v1alpha1
kind: Backup
metadata:
  name: backup-now
spec:
  keepJobs: 4
  backend:
    repoPasswordSecretRef:
      name: backup
      key: password
    s3:
      endpoint: https://s3.amazonaws.com
      bucket: dustise
      accessKeyIDSecretRef:
        name: s3secret
        key: token
      secretAccessKeySecretRef:
        name: s3secret
        key: key

查看 Pod 日志：

$ kubectl logs -f k8up-1578112449-84d7d4d6cc-q6qsh
2020/01/04 14:30:10 [INFO] New backup job received backup-now in namespace default
2020/01/04 14:30:10 [INFO] Listing all PVCs with annotation appuio.ch/backup in namespace default
2020/01/04 14:30:10 [INFO] Adding data to list
...
2020/01/04 14:30:29 [INFO] default/backupjob-1578148210 is running
2020/01/04 14:30:37 [INFO] default/backupjob-1578148210 finished successfully

两个卷的备份均已完成，查看 S3 的情况：

$ s3cmd la
                       DIR   s3://dustise/data/
                       DIR   s3://dustise/index/
                       DIR   s3://dustise/keys/
                       DIR   s3://dustise/snapshots/
2020-01-04 14:30       155   s3://dustise/config

发现已经初始化了一个备份结构。

还原

备份成功之后，我们希望还原一下，看看备份的内容。

新建一个 PVC 用作还原目标：

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: restore
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

创建一个还原命令：

apiVersion: backup.appuio.ch/v1alpha1
kind: Restore
metadata:
  name: restore2pvc
  namespace: default
spec:
  backend:
    repoPasswordSecretRef:
      key: password
      name: backup
    s3:
      accessKeyIDSecretRef:
        key: token
        name: s3secret
      bucket: dustise
      endpoint: https://s3.amazonaws.com
      secretAccessKeySecretRef:
        key: key
        name: s3secret
  restoreMethod:
    folder:
      claimName: restore

查看运行日志：

$ kubectl logs -f k8up-1578112449-84d7d4d6cc-q6qsh
2020/01/04 14:43:45 [INFO] Received restore job restore-now in namespace default
2020/01/04 14:43:45 [INFO] default/restorejob-1578149025 is running
2020/01/04 14:43:45 [INFO] default/restorejob-1578149025 is running
2020/01/04 14:43:59 [INFO] default/restorejob-1578149025 is running
2020/01/04 14:44:15 [INFO] default/restorejob-1578149025 finished successfully

查看该卷内容，会发现其中有一个 data/data 目录，包含了我们的备份内容。

附录

连接

https://k8up.io/
https://github.com/restic/restic

源码

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: debugger
  name: debugger
spec:
  replicas: 1
  selector:
    matchLabels:
      app: debugger
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: debugger
    spec:
      containers:
      - image: dustise/sleep
        name: sleep
        resources: {}
        volumeMounts:
        - name: data
          mountPath: /data
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: data
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: data
  annotations:
    appuio.ch/backup: "true"
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

2020，我要重学 Kubernetes

Mon, 30 Dec 2019 16:00:34 +0800

一眨眼，2019 就剩下最后一天，疏于照料的公众号也放了满天的鸽子。一方面今年做了老豆又换了工作，生活工作节奏还调整的不太好；另一方面云原生方面的作者也越来越多，总觉得题材不够吃，也就懈怠了。

回顾 2016 年参与《Kubernetes 权威指南》第二版的编写工作以来，因为其他几位作者不像我一样喜欢凑热闹，顶着本书作者的大帽子，一路混吃混喝也有三四年了。然而对 Kubernetes 的了解本来就不够全面，再加上云原生的世界日新月异，面对一些 Kubernetes 问题已经感觉颇有不足，一些特性的了解也还停留在老版本阶段，再次学习看来是很有必要的。然而学习应该有些彩头有个目标才有意思，因此我决定从给 Kubernetes 权威指南开始，逐章进行勘误，并根据当前情况进行增补或者点评。

今天是第一章。

点评

RC 已经被淘汰，以 Deployment 取而代之。
对存储卷的简介，也稍嫌过时，没有提到 CSI 和 PVC
过分强调 Docker。
核心组件部分应该加入 CRD 的介绍。
多处 API 版本都需要更新。

例如 MySQL 的 RC 就应该更新为：

apiVersion: apps/v1 # API 版本
kind: Deployment  # 副本控制器RC
metadata:
  labels: # 标签
    app: mysql
  name: mysql # 对象名称，全局唯一
spec:
  replicas: 1 # 预期的副本数量
  selector:
    matchLabels:
      app: mysql
  template:  # Pod 模板
    metadata:
      labels:
        app: mysql
    spec:
      containers:  # 定义容器
      - image: mysql:5.7.28
        name: mysql
        ports:
        - containerPort: 3306                   # 容器应用监听的端口号
        env:                                # 注入容器内的环境变量
        - name: MYSQL_ROOT_PASSWORD
          value: "123456"

另外本书作者们在 Github 建设了一个仓库，用于接收读者们的勘误建议：

https://github.com/kubeguide/K8sDefinitiveGuide-V4-corrigendum/

第一章内容很泛，技术内容较少，导致本篇内容严重枯燥，这里就搞个小抽奖，顺便欢迎一下即将到来的元旦假期，欢迎在本文评论区发表意见建议，我会选择顺眼部分送出权威指南一本，以感谢读者大人的支持。

应用未迁，资源先行

Sat, 21 Dec 2019 22:47:13 +0800

引子

在企业服务和云原生的夹缝里厮混了这些年，见到了很多成功或不成功的 K8s 迁移案例。企业在向 Kubernetes 靠拢的过程中，一直有几个跟资源相关的尴尬问题：

单个大集群，还是多个小集群？
少量大节点，还是大量小节点？
应用的资源如何配合 K8s 的策略进行分配？

这些问题有很多模棱两可的相关素材，在任何一个迁移过程中提起这些问题，都能引发大规模的磨洋工事件。然而对于我一直关注的“XX 管理系统”之类的应用来说，这就不是一个大问题了——随大流的应用，选择一个随大流的方向，大概是比较合适的，而 CNCF 红红火火恍恍惚惚，自然不会缺乏数据了。本着这个思路，就诞生了这一篇没什么技术含量的文章。

集群规模

早在 Kubernetes 1.2 时候，就已经宣布达到 1000 节点的规模了，在 1.6 版本更达到了 5000 节点的规模。各大厂也都有了各自的超大规模单一集群。然而普罗大众的情况是如何呢？在 Sysdig 2019 年度容器应用报告中得到的结果是，大于 50 节点规模的集群不足 10%，另外一个佐证是 Mohamed Ahmed 的一篇调查报告中也提供了类似的数据。这种情况的一种解释是，目前的应用阶段还比较早期，处于试探期间；然而从一个侧面来说，Sysdig 的调研对象针对的是生产应用，也就是说处于生产应用状态下的集群，绝大多数都是这种小规模集群。根据对 CNCF Landscape 中 Distribution 分类的产品的抽查，也可以看到随处可见的 Kubernetes As Service 类似功能的实现，这也证实了小集群协作方案的落地趋势。相对于少量大集群，多个小集群的差异在于：

隔离程度高

虽然现在存在不少沙箱容器实现，然而最易用的、生态最为成熟的方案还是 Docker 为代表的传统容器方案，传统容器方案所缺失的隔离能力，通过多租户多集群方式是一个非常自然的思路。

实现难度低

运管成本高

多个集群很明显会需要更多的运维和管理人力的投入。

资源利用率低

多个集群都会有自己的 Master 组件、ETCD 集群、网络组件等，这些都会抢占更多原本属于工作负载的系统资源，客观上降低了资源的总体利用率。

节点

目前很多 Kubernetes 系统都会使用虚拟机来做为节点。那么虚拟机的资源是多分还是少分呢？下表是一个简单的对比：

	大节点	小节点	备注
节点数量	少	多	同样的资源总量情况下，相对来说小资源节点会得到更多的数量。
运维成本	低	高	通常情况下，节点的运维成本是和节点数量正相关的。
容错能力	低	高	较大的节点上通常会集中较多的应用，因此在节点出现故障时，可能会带来更大的损失。
资源粒度	大	小	单节点资源较大，因此其资源粒度也较大。
应用副本数	少	多	同一应用的多个副本，如果调度到同一个节点上的话，对于提高其负载能力和健壮性来说并无裨益。
副本规模	大	小	毫无疑问，具备更多资源的大节点，能够运行更大资源需求范围的容器应用。
系统开销	少	多	每个虚拟机都会有自己的操作系统、网络等基础开销，因此相对于少量大节点来说，大量的小节点会消耗更多的资源。

除了这些原则性的条目之外，更重要的决策依据就是运行在集群上的应用需求。例如某租户的集群需要支撑 20 个应用，共300 个 Pod，按照常见的每节点 30-50 Pod 的分布，就需要 6-10 个运算节点（Node）。以 10 节点算，加入系统保留、冗余等计算，可能需要 10 * 120G 的虚拟机实例；然而考虑到故障情况——一个节点的故障，最好的结果也是短期内降低 10% 的算力。如果扩张到 40 个 32G 的虚拟机节点，会大幅降低单节点故障的影响——当然也会提高网络的复杂性和效率要求。

应用资源

Java 应用是特别常见的迁移案例，除掉微服务化、网格、分布式等改造要求之外，资源的申请和限制是一个必须要面对的门槛。requests 是个用于调度的定义，Kubernetes 根据这个要求来选择能够满足要求的节点来分配应用。而 limits 则会用于触发 OOM。

众所周知的是，Java 的早期版本是无法识别容器内的内存限制的，因此如果没有限制堆内存上限，又开启了 limits，就会被 Kubernetes 杀掉。因此针对容器中运行的情况，需要进行一些启动参数的设置。

如果允许更新到新版本的 JVM，可以使用新引入的 UseCGroupMemoryLimitForHeap、MaxRAMFraction 参数，让 JVM 直接继承容器的定义。

如果无法直接升级，那么就有必要设置 xmx 和 xms 参数了，这里有几个小建议：

xmx 和 xms，request 和 limits 建议设成一致，能省掉很多麻烦。
tmpfs、filemapping 等都是可能的内存大户。
JVM 并不是唯一的内存消耗者，一般建议 Limit 大于 XMX 25% 以上。
/sys/fs/cgroup/memory/memory.stat 是你的好朋友。

使用 Harbor 提供可信镜像

Fri, 13 Dec 2019 10:39:08 +0800

应用上云的过程中，过了部署关和应用改造关之后，安全就是下一个大问题了。对于容器化应用来说，镜像的安全是个非常根本的问题，例如 Harbor 中集成了 Clair 组件，用于对镜像进行漏洞扫描；之前介绍的 Trivy 也能够提供对镜像各层进行扫描的能力，类似的工具还有很多。在完成镜像本身的安全保障之后，一方面要把安全构建出来的镜像能够”原汁原味“的提供给运行时进行使用，同时还要对运行时环境进行约束，只允许获取和运行可靠镜像，如此才能够保证镜像供应链的完整。

快速上手

Harbor 中提供了 Notary 服务来提供了这方面的保障，Docker 17.12 之后也提供了对应的运行时支持。

这里用 1.10.0 版本的 Harbor 为例，在安装命令中加入参数 --with-notary 就可以启用这个服务了。启动 Harbor 之后，使用 Docker 客户端的终端设置环境变量：export DOCKER_CONTENT_TRUST=1。启用 Docker 的内容信任模式。

使用 docker login 命令登录仓库，然后进行镜像推送，例如：

$ docker push 10.211.55.27/sign/clare:s1
The push refers to repository [10.211.55.27/sign/clare]
bbef02a499c4: Layer already exists
...
47a4bb1cfbc7: Layer already exists
s1: digest: sha256:bafc293fd765dbbad5ed3d57d771f0566e5d63a668213f1f61c469cbb199fca6 size: 1162
Signing and pushing trust metadata
You are about to create a new root signing key passphrase. This passphrase
...
Enter passphrase for new root key with ID b52c1ba:
Repeat passphrase for new root key with ID b52c1ba:
Enter passphrase for new repository key with ID c37e6d2:
Repeat passphrase for new repository key with ID c37e6d2:
Error: trust data missing for remote repository 10.211.55.27/sign/clare or remote repository not found: timestamp key trust data unavailable.  Has a notary repository been initialized?

这里多出了一个初始化过程，在我们照章输入密码之后，发现出了错，这是因为我们没有设置 Notary 服务地址，加入环境变量来解决：export DOCKER_CONTENT_TRUST_SERVER=https://10.211.55.27:4443。

再次推送：

$ docker push 10.211.55.27/sign/clare:s1
The push refers to repository [10.211.55.27/sign/clare]
...
Repeat passphrase for new repository key with ID d6068a9:
Finished initializing "10.211.55.27/sign/clare"
Successfully signed 10.211.55.27/sign/clare:s1

可以看到，推送已经成功了，并且还有签署成功的反馈。查看一下他的签名信息：

$ docker trust inspect 10.211.55.27/sign/clare:s1
[
    {
        "Name": "10.211.55.27/sign/clare:s1",
        "SignedTags": [
            {
                "SignedTag": "s1",
                "Digest": "bafc293fd765dbbad5ed3d57d771f0566e5d63a668213f1f61c469cbb199fca6",
                "Signers": [
                    "Repo Admin"
                ]
            }

...

如果我们取消 Docker 内容信任：unset DOCKER_CONTENT_TRUST。接下来推送一个新镜像：

$ docker push 10.211.55.27/sign/alpine:latest
The push refers to repository [10.211.55.27/sign/alpine]
77cae8ab23bf: Pushed

再次开启 Docker 内容信任开关：export DOCKER_CONTENT_TRUST=1，尝试拉取：

$ docker pull 10.211.55.27/sign/alpine:latest
Error: remote trust data does not exist for 10.211.55.27/sign/alpine: 10.211.55.27:4443 does not have trust data for 10.211.55.27/sign/alpine

可以看到 Docker 拒绝了未经签署的镜像。

幕后

Docker 包含了简写为 DCT 的内容签名（Docker Content Trust）支持，能够借助 Notary 进行内容签署和校验。首次签署时会要求生成根密钥，每次创建一个新的 Repository 时候，会为其单独生成签署密钥。接下来，每个 Tag 的推送都会进行签署，从而保证内容的稳定性。

问题

Kubernetes 能享受到这个么？
托管 Kubernetes 怎么办？
多镜像仓库怎么办？

Rudr 初体验

Wed, 04 Dec 2019 21:20:35 +0800

OAM（开放应用模型）是一次对应用运行及其支撑环境进行抽象的有意思的尝试，与之对应的控制器 Rudr 也在同一时间诞生。有了 Rudr，OAM 就不是一个简单的标准，而是一个可以尝试落地的原型了。官方仓库提供了很好的入门文档，借此文档的帮助，能够很好的理解规范中莫名其妙的概念。这里就按照官方教程走一通，看看这种方法让应用部署运行过程发生了什么变化。

安装

Rudr 需要 Kubernetes 1.15 以上的版本，并且使用 Helm 3 进行安装。

$ git clone https://github.com/oam-dev/rudr.git
正克隆到 'rudr'...
remote: Enumerating objects: 49, done.
...
$ cd rudr
...
$ helm install rudr charts/rudr
...
NOTES:
Rudr is a Kubernetes controller to manage Configuration CRDs.

It has been successfully installed.

非常谦虚的一个 Note。

部署一个 Component

Component 是 OAM 中的一个运行单位，代表一种运行负载，其类型可能有 Server、Job 等。下面使用示例代码创建一个 Component 对象：

$ kubectl apply -f examples/helloworld-python-component.yaml
componentschematic.core.oam.dev/helloworld-python-v1 created
$ kubectl get component
NAME                   AGE
helloworld-python-v1   35s

查看这个源文件，其中声明了一个 Server 类型的组件，用参数的方式定义了两个环境变量 TARGET 和 PORT。

查看 Traits

接下来看看 Kubernetes + Rudr 为应用提供了哪些运行支撑能力：

$ kubectl get traits
NAME             AGE
autoscaler       13m
empty            13m
ingress          13m
manual-scaler    13m
volume-mounter   13m

熟悉 Kubernetes 的同学应该看得出，除了奇怪的 empty，其他都是常见的部署元素。

$ kubectl get traits autoscaler -o yaml
apiVersion: core.oam.dev/v1alpha1
kind: Trait
...
spec:
  appliesTo:
  - core.oam.dev/v1alpha1.Server
  - core.oam.dev/v1alpha1.Task
  properties: |
    {
      "$schema": "http://json-schema.org/draft-
...

这里可以看到，HPA 适用于 Server 和 Task 两种组件，定义了最大实例数、最小实例数以及 CPU/内存消耗阈值。

运行应用

有了 Component 和 Trait，接下来可以用 Configuration 启动应用了：

$ kubectl apply -f examples/first-app-config.yaml
applicationconfiguration.core.oam.dev/first-app created
$ kubectl get pods
NAME                                              READY   STATUS    RESTARTS   AGE
first-app-helloworld-python-v1-855479556f-6qvk8   1/1     Running   0          38s
...
$ kubectl get ingress
NAME                                           HOSTS         ADDRESS   PORTS   AGE
first-app-helloworld-python-v1-trait-ingress   example.com             80      12m

Pod 已经启动，Ingress 对象也已经建立起来，可以看看他的运行结果：

$ export POD_NAME=$(kubectl get pods -l "oam.dev/instance-name=first-app-helloworld-python-v1,app.kubernetes.io/name=first-app" -o jsonpath="{.items[0].metadata.name}")
...
$ kubectl port-forward $POD_NAME 9999:9999 &
Forwarding from [::1]:9999 -> 9999
$ curl http://127.0.0.1:9999
Hello Rudr!

修改配置

使用 kubectl edit 修改上一步的配置，把 target 参数修改为 World：

...
    parameterValues:
    - name: target
      value: World
...

应用之后，会看到 Pod 被重建，重新执行上面的测试步骤，返回信息变成 Hello World。

结论

实际上单就这个例子来说，对比入门的 Deployment + Service + Ingress 三件套来说，复杂度并没有什么区别。然而 Component 对象的工作负载类型除了 Server 之外，还有 Job、Serverless 等复杂类型，用 Traits 可以描述多种运维能力，更不要说还有暂未浮出水面的 Application Scope 对象，猜测这个模型在公有云、多云以及混合云下，可能会有相当大的想象空间。

istioctl 中的一些小工具

Tue, 03 Dec 2019 19:38:20 +0800

引子

许久不见，istioctl 中加入了不少有趣的新命令。装备党自然是喜欢小工具了，选几个有趣的命令分享给大家。

Analyze

Istio 的配置是比较繁杂的，相信玩过的朋友都比较有体会， istioctl x analyze，可以对 Istio 进行一些检查，

目前该工具支持的检测范围包括：

IST0001：内部错误，基本上是属于实现部分的 Bug。
IST0002：对象中存在过期特性。
IST0101：应用对象不存在，例如有 VirtualService 无 Workload。
IST0102：命名空间未开启自动注入。
IST0103：有 Pod 没有注入 Istio Proxy。
IST0104：网关端口没有工作负载。
IST0105：Sidecar 版本和 Istio 版本不一致。
IST0106：文件格式错误。
IST0107：注解目标错误。
IST0108：未知注解。
IST0109：网关内 VirtualService 主机名冲突。
IST0110：Sidecar 对象选择器重叠。
IST0111：多于一个 Sidecar 对象没有负载选择器。
IST0112：多端口服务的 VirtualService 缺乏选择。

例如：

$ istioctl x analyze -k
Warn [IST0103] (Pod httpbin-7d9d5b55b9-jslpp.default) The pod is missing its Istio proxy. Run 'kubectl delete pod httpbin-
7d9d5b55b9-jslpp -n default' to restart it
Error: Analyzer found issues.

Dashboard

可能是向 Linkerd 致敬？

打开 Istio 的各种仪表盘页面：

controlz：打开指定控制平面组件的 ctrlz 界面。
envoy：打开特定 Pod 的 Envoy 仪表盘
grafana：缺省 Grafana 页面
jaeger、kiali、zipkin 和 Prometheus 页面

Metrics

查看指定服务的性能指标：

总体 RPS
错误 RPS
P50 延迟
P90 延迟
P99 延迟

Manifest

用于生成或安装 Istio 清单，例如推荐的安装方式：istioctl manifest apply --set profile=demo

Profile

几个内置的安装配置，用于 Manifest 命令的 set profile，其中包含：

minimal
remote
sds
default
demo

Describe

根据 Pod 和 Service，获取相关的配置内容，例如：

$ istioctl x describe service httpbin
Service: httpbin
   Port: http 8000/HTTP targets pod port 80
Pod is PERMISSIVE, client protocol unspecified
VirtualService: httpbin
   1 HTTP route(s)

用 Python 脚本拉取 Docker 镜像

Sun, 10 Nov 2019 00:19:51 +0800

好久没有介绍小工具了，今天碰到一个，简单粗糙但是有用的一个，这个工具有多简单粗糙呢？证据有二：

连 Python shebang 都没有；
简单到原创 300 字都很难凑够。

言归正传：安装工经常会遇到一个问题：没 Docker 怎么拉镜像？这个小工具就是做这个事情的。

该项目同样是个开源项目，地址为：https://github.com/NotGlop/docker-drag

这个项目使用 Python 的 Request 库，借助 API 直接从仓库中拉取镜像，并保存为 TAR 文件。

保存下来的 Tar 文件可以直接使用 docker load -i 命令进行载入。由于去掉了对 Docker/Podman/xxxx 等的依赖，在实际工作中，例如对于文件传输或者 CICD 流程来说，这个脚本都有可能发挥很有意思的作用。

用法也是相当的简单粗暴：python3 docker_pull.py [image name]，就完成任务了。

例如：

$ python3 docker_pull.py nginx:alpine
Creating image structure in: tmp_nginx_alpine
89d9c30c1d48: Pull complete [2787134]
110ad692b782: Pull complete [5953615]
Docker image pulled: library_nginx.tar

$ ls library_nginx.tar
library_nginx.tar

或者放到镜像里：

FROM alpine:3.10.3
RUN apk add -u ca-certificates python3 \
    && pip3 install requests \
    && wget https://raw.githubusercontent.com/NotGlop/docker-drag/master/docker_pull.py

Zalando 是如何管理 140 多个 Kubernetes 集群的

Sat, 02 Nov 2019 23:41:56 +0800

原文：HOW ZALANDO MANAGES 140+ KUBERNETES CLUSTERS

作者：Henning Jacobs

最近我接到一个问题：“你是如何管理这么多 Kubernetes 的？”。本文试图揭示 Zalando 在 AWS 管理 140 多个 Kubernetes 集群的秘密。

我写过一篇文章：为什么需要多集群，Mikkel 在 KubeCon EU 2018 上做了关于如何在 Kubernetes 基础设施上进行持续交付的精彩分享。这里基本是对现存信息的一个梳理。

背景

Zalando 有 200 多个开发团队，他们全权负责自己的应用，其中也包括 7*24 待命的支持工作。我们的 Kubernetes 平台团队为 1000 多个 Zalando 开发者提供 Kubernetes 即服务的支持工作，工作过程中我们遵循如下准则：

杜绝手工操作：所有集群更新和运维都要全自动。
没有宠物集群：集群应该整齐划一，无需任何额外的配置和微调。
韧性：为交付团队提供稳固的基础设施，保障其关键应用的运行环境。
自动伸缩：集群应该自动适应应用负载的规模，根据需求进行伸缩。

架构

我们的集群是成对供应的，例如给每个域或者“产品社区”提供一个生产、一个非生产环境。

每个集群都是属于一个全新的、隔离的 AWS 账号。我们使用一个自定义的 Python 工具（Seven Seconds）对 AWS 基础设施进行配置，对 Kubernetes 和非 Kubernetes 账号一视同仁（即将下线的 STUPS 基础设施）。

我们整个生产环境的配置都保存在 Github 上。集群使用 CloudFormation（CF）模板。每个集群至少有四个 CF 栈：

ETCD 集群（存在于主节点之外）：etcd-cluster.yaml
主集群：cluster.yaml
主机群节点池：master stack.yaml
缺省的工作节点池：worker stack.yaml

可以有多种工作节点池，例如 GPU 节点、EC2 Spot 实例等。

注意：我们没有使用 Terraform（从来没有）。

主节点和工作节点都运行在我们的自定义 AMI 上。这个 AMI 是从 Ubuntu 基础上构建出来的，并且包含了 Kubernetes 所需的所有 Docker 镜像。从前我们用过 ContainerLinux，后来还是决定采用更主流的发行版，以保证持续性。这个预制的 AMI 还帮我们减少了启动时间（集群伸缩更快）。

配置

所有的集群以及 AWS 账号，都注册在一个中央集群仓库中。集群仓库使用 PostgreSQL 为数据库，提供了一组 REST API。可以在 Github 上浏览这个 OpenAPI 的规范。每个集群都有如下属性：

只读的集群 ID，例如 “aws:123123123123:us-east-1:kube-9”
集群别名：例如 “foobarlab”
所在的 AWS 账号(账号 ID 和 Region)
环境（生产还是测试）
配置成熟度（稳定、Beta、Alpha 或者 dev）
生命周期（已供给、已分配或者已销毁）
集群特定的键值对信息，例如外部 API Key 等。
已配置好的节点池（也就是 EC2 实例类型）和针对节点池的键值对配置

我们的工具集（kube-resource-report 和 kube-web-view）能够查询集群仓库的 REST API，列出所有集群，比如 zkubectl 命令行工具能够列出集群：

$ zkubectl list
Id                                           │Alias                           │Environment│Channel│Version
aws:123740508747:eu-central-1:kube-1          foobarlab                        production  stable  5f4316c
aws:456818767898:eu-central-1:kube-1          foobarlab-test                   test        beta    9f1b369
aws:789484029646:eu-central-1:kube-1          abckub                           production  stable  5f4316c
aws:012345670034:eu-central-1:kube-1          abckub-test
...

你会看到两对集群（foobarlab 和 abckub），生产集群使用的是 stable，非生产集群则使用 beta 配置。Version 列显示的是当前集群配置的 git sha。

用 Kubernetes Web View 对类似的集群进行渲染：

还可以参考我的另一篇文章：缺乏多集群支撑案例的 Kubernetes Web UI。

更新

集群生命周期管理器持续的对集群仓库以及 Git 仓库的变更进行监控。CLM 会在如下时机进行变更：

CloudFormation 更新
节点必须进行滚动更新（例如 AMI 发生变化）
Kubernetes 自身发生了变更（多数时候的表现是 kube-system 中的 DaemonSet 和 Deployment 的变更）

通过对 dev 分支发起 PR 的方式来初始化一个更新动作（例如更新一些系统组件）。每个变更的 PR 都会自动的进行端到端测试。只有通过测试并且由人手工批准的 PR 才能够合并。端到端测试过程会针对新建的集群运行官方的 Kubernetes 一致性验证，以及 Zalando 自己的测试案例。这个测试的范围包括：

集群的创建和更新（端到端测试会用前一个版本创建一个新的集群，并用 PR 内容进行更新）
Kubernetes 的核心功能：Deployment、StatefulSet 等
Zalando 的准入控制器逻辑
审计日志
Ingress、外部 DNS、AWS ALB 以及 Skipper
PodSecurityPolicy
使用自定义指标进行自动伸缩
测试 AWS IAM 集成

每个 e2e 测试目前需要 35-59 分钟。测试成功的 PR，只需要一个 +1，就能进行合并：

每个变更都会在不同的分支中迁移，一直到进入稳定分支。

在滚动更新集群节点以及集群的自动伸缩过程中，我们的基础设施必须对正在预备下线的服务器上运行的 Pod 进行驱逐。可以使用 Pod Disruption Budgets 的声明，来保障平稳的更新过程。我们为更新或类似行为定义了下面的 SLA：

SLA	生产集群	测试集群
更新期间强制终结的 Pod 的最小生存期	3 天	8 小时
在选定节点之后，需要等待多久才开始强行终结 Pod	6 小时	2 小时
同一个节点上强行终结 Pod 的时间间隔	5 分钟	5 分钟
同一个 PDB 中将被终止的就绪 Pod 的最小生存期	1 小时	1 小时
同一个 PDB 中将被终止的未就绪 Pod 的最小生存期	6 小时	6 小时

因此应用 Pod 会在 3 天之后被强行终止——即使定义了 PDB 的情况。这种行为模式让我们在部分应用配置失常的情况下也能持续更新。

注意：我们的用户（开发团队）可以在任何时间阻止集群更新（例如发现了问题）。

请参见 Miokkel 的 KubeCon 演讲

避免配置发散

所有的集群看起来都差不多，只有少量配置项目有些不同：

Secret：例如外部日志服务的凭据
节点池以及其中的实例规格

Cluster Autoscaler 能根据资源需要对集群的节点池进行伸缩，无需手工配置节点池的大小。下图是我们一个集群在两天之内的伸缩情况：

有些组件需要根据集群大小进行纵向伸缩。我们使用 Vertical Pod Autoscaler（VPA）来避免对这些值进行手工调节。目前有如下系统组件在使用 VPA：

Prometheus
外部 DNS
Heapster/Metrics Server
我们的 ALB Ingres 控制器

我们最小的 Prometheus 实例仅仅使用 512 MB，也有使用 9GB 的大户，例如下图：

监控

我们主要的监控系统是 ZMON，ZMON 中有个实体的概念，表达的是你要监控的对象——例如服务器、Pod 甚至是团队。

创建一个新的集群会自动注册新的实体（例如新的 AWS 账号、节点、Deployment、Pod 等）。从而为新的实体启用一些常用检查和告警。

ZMON 提供了指标、告警以及仪表盘。

我们的 Kubernetes 团队不会在 Pod 重启时候收到警告。开发团队负责应用的整个生命周期。

我们还使用 OpenTracing（LightStep）获得跨集群的可观察性，中心化应用日志（Scalyr）、kube-resource-report 和 kube-web-view）。

魔改 Kubernetes

我们的配置是否对 Kubernetes 进行了大量魔改呢？答案是：不很多：

Kubernetes API 认证用了 Zalando Oauth token
使用 Kubelet 参数禁用 CPU Throlling
强制 request == limit，防止内存超售
使用外部 DNS ALB Ingress 控制器，以及 Skipper，Ingress 注解是可选的，不过 Skipper 有些有用的功能
PlatformCredentialsSet 是一个用来集成 OAuth 的 CRD
我们用 StackSet来实现流量切换和渐进部署
kube-downscaler 用于在作业后降级测试部署
我们的 DNS 配置有些不同：我们使用 ndots: 2 的配置（官方配置是 ndots: 5）

非生产集群提供的是类似 GKE 或者 Digital Ocean 集群类似的普通集群的功能。生产集群有些容器：

只能通过 CICD 进行 Kubernetes API 的操作
用 Webhook 执行强制的合规措施，例如使用某些标签，或者允许用于生产的镜像

总结

我们的这种做法再过去几年中工作良好，让我们在无需扩张团队的情况下得到了成长：

我们能够无缝的把我们一个老的 Kubernetes 1.4 在无停服的情况下，升级到 1.14
我们能够跟进 Kubernetes 的季度发布，也就是说我们在每个季度都可以进行升级
频繁的集群更新让大家开始接受一个观点：小的中断是正常的（目前的 Pod 最长寿 20 多天）
我们尝试避免出现宠物集群：集群看起来差不多，VPA 协助我们避免人工调节
我们的自动端到端测试救了我们不止一次（例如最近 1.14.7 的 Issue(https://twitter.com/try_except_/status/1181602709155323905)）

要进一步了解这方面的信息，可以看看 Zalando 的公开仓库，还可以在 Twitter 上找到我们的一些团队成员：

也欢迎和 ZalandoTech、和我打个招呼。

YAML 程序员眼中的 OAM

Mon, 21 Oct 2019 14:30:23 +0800

在 10.17 ，阿里云和微软联袂发布了一个有意思的新东西：OAM（开放应用模型）。这个项目要解决的问题是：用一致的、定义良好的模型来对应用进行描述。

Kubernetes 达成了一个小目标：不管是什么云，上面都有 Kubernetes 的一席之地。OAM 的小目标是什么呢？

OAM 用（Holy）YAML 对应用程序进行了描述，其中核心组件包含了几个：

Component：组件交付物
Application Scope：部署目标
Traits：运维能力
Application Configuration：应用配置

一头雾水是吧？还好每个对象都提供了代码范例，可以拿来解释。

Component

一种类似 Pod 的东西。。。

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: admin-backend
  annotations:
    version: v1.0.0
    description: >
      Sample component schematic that describes the backend for our Twitter bot.
spec:
  workloadType: core.oam.dev/v1.SingletonServer
  osType: linux
  parameters:
  ...
  - name: twitter-access-token-secret
    description: Twitter API access token secret
    type: string
    required: true
  containers:
  - name: my-twitter-bot-backend
    image:
      name: example/my-twitter-bot-backend:1.0.0
      digest: sha256:6c3c624b58dbbcd3c0dd82b4c53f04194d1247c6eebdaab7c610cf7d66709b3b
    resources:
      cpu:
        required: 1.0
      memory:
        required: 100MB
      volumes:
      - name: config
        mountPath: /var/lib/my-twitter-bot/conf
        accessMode: RW
        sharingPolicy: Exclusive
    ports:
    - name: http
      value: 8080
    env:
    ...
    - name: TWITTER_ACCESS_TOKEN_SECRET
      fromParam: 'twitter-access-token-secret'
    livenessProbe:
      httpGet:
        port: 8080
        path: /healthz
    readinessProbe:
      httpGet:
        port: 8080
        path: /healthz

很像 Kubernetes 有没有？容器、参数、资源（外部加载卷的加载方式，类似 volumeMount 也定义在资源里）、端口和环境变量都是 YAML 程序员们很熟悉的东西。最值得注意的是 workloadType，工作负载的类型可以分为核心和扩展两个大类，其中核心工作负载有一个明确要求：所有实现本规范的平台必须支持核心工作负载。

核心工作负载有几个类型：

Server：可多实例运行的，对外提供服务的守护进程。
Singleton Server：只能单实例运行的，对外提供服务的守护进程。
Worker：能够多实例运行，不对外提供服务的守护进程。
Singleton Worker：不对外提供服务，不可复制的守护进程。
Task：不对外提供服务，可复制，非守护进程（一次性）。
Singleton Task：不对外提供服务，不可复制，非守护进程（一次性）。

另外这里还有一个字段叫 ConfigFile，用于存储配置内容。

在组件模型一节的尾部，给出了下面这样的例子：

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: azurefunction
  annotations:
    version: v1.0.0
    description: "Extended workflow example"
spec:
  workloadType: azure.com/v1.Function
  parameters:
  - name: github-token
    description: GitHub API session key
    type: string
    required: true
  workloadSettings:
    - name: source
      value: git://git.example.com/function/myfunction.git
    - name: github_token
      fromParam: github-token

这个例子展示的是扩展类型的组件：从 git 拉取代码，用于提供 Function 服务。

Trait

一种运行平台中，针对特定工作负载进行运维支撑的能力，例如下面例子中的手动伸缩，似乎 Service Mesh 也应该名列此列？

apiVersion: core.oam.dev/v1alpha1
kind: Trait
metadata:
  name: ManualScaler
  annotations:
    version: v1.0.0
    description: "Allow operators to manually scale a workloads that allow multiple replicas."
spec:
  appliesTo:
    - core.oam.dev/v1alpha1.Server
    - core.oam.dev/v1alpha1.Worker
    - core.oam.dev/v1alpha1.Task
  properties:
    type: object
    properties: |
      {
        "$schema": "http://json-schema.org/draft-07/schema#",
        "type": "object",
        "required": ["replicaCount],
        "properties": {
          "replicaCount": {
            "type": "integer",
            "description": "the target number of replicas to scale a component to.",
            "minimum": 0
          }
        }
      }

这里定义了一个用来做手动伸缩的 Trait，它仅适用于第一节中提到的几个可伸缩的工作负载类型。这个 Traits 仅包含一个必要字段，用于设置副本数量。

但是在 YAML 里面包 JSON 真的好吗？

Application Scopes

百撕不得其解的一个概念。通过外部设施，如网络或者健康对应用范围进行划分，把应用进行聚合。并且在 Application Configuration 中作为一个部署目标进行实例化。

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationScope
metadata:
  name: health
  annotations:
    version: v1.0.0
    description: "aggregated health state for a group of components."
spec:
  type: core.oam.dev/v1alpha1.HealthScope
  allowComponentOverlap: true
  parameters:
    - name: probe-method
      description: The method to probe the components, e.g. 'httpGet'.
      type: string
      required: true
...
    - name: required-healthy-components
      description: Comma-separated list of names of the components required to be healthy for the scope to be health.
      type: []string
      required: false

Application Configuration

前面的几个概念中，描述了组件的定义、平台提供的运维能力、以及应用的部署范围，最终应用要运行起来，需要进行一个部署过程，部署过程除了把前面提到的对象组合起来之外，还需要加入一些配置内容。本对象就是用来完成这一功能的。

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: my-vpc-network
spec:
  variables:
    - name: networkName
      value: "my-vpc"
  scopes:
    - name: network
      type: core.oam.dev/v1alpha1.Network
      properties:
        - name: network-id
          value: "[fromVariable(networkName)]"
        - name: subnet-id
          value: "my-subnet"
---
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: custom-single-app
  annotations:
    version: v1.0.0
    description: "Customized version of single-app"
spec:
  variables:
    - name: message
      value: "Well hello there"
    - name: domainName
      value: "www.example.com"
  components:
    - componentName: frontend
      instanceName: web-front-end
      parameterValues:
        - name: message
          value: "[fromVariable(message)]"
      traits:
        - name: Ingress
          properties:
            - name: host
              value: "[fromVaraible(domainName)]"
            - name: path
              value: "/"
      applicationScopes:
        - my-vpc-network

    - componentName: backend
      instanceName: database
      applicationScopes:
        - my-vpc-network

这一组文件对象完成了几个任务：

创建了一个网络类型的 Application Scope，my-vpc-network。
引用一个叫做 frontend 的组件，生成 web-front-end 对象，并赋予参数 message。
为 web-front-end 提供一个 Ingress 对象。
将两个实例部署在 my-vpc-network。

后记

这几个对象里，基本形成了一个从交付物到运维的标准过程和定义，并且也直接使用 Rust 实现了基于这一规范的工具。符合这个规范的应用，就能能够在支持 OAM 的平台上进行运行和运维，虽然应用自身的结构、拓扑、构建、观测还有很多元素要实现，但是这些基础元素，应该已经能够发挥很好的示范效果了。

印象里 OAM 的新闻稿里有一句话，OAM 和其他应用模型是不同的，它没有供应商锁定问题，因为它是构建在 Kubernetes 的基础之上的：Kubernetes 就是在锁定横行的环境下，利用更高层次的抽象来打破旧锁定，造就新锁定的。

Kubernetes 存活检测的危险性

Fri, 18 Oct 2019 00:32:27 +0800

原文：LIVENESS PROBES ARE DANGEROUS

Kubernetes 的 livenessProbe 是有一定危险性的。建议在用例清晰，并且理解足够深刻的情况下才使用这个功能。本文会涉及到存活检测以及就绪检测，并做出一些应该或者不该的建议。

我的同事 Sandor 最近说了一下他看到的问题，其中包括了错误的存活检测和就绪检测的内容：

Most people that are new to #kubernetes do the same mistakes:
- no readinessprobe
- wrong readinessprobe
- livenessprobe = readinessprobe
- non graceful shutdown
- graceful shutdown which is not graceful enough, best use lifecycle hook https://t.co/OeNHqghhzC
- pre fork mode
— Sandor Szücs (@sszuecs@hachyderm.io) (@sszuecs) September 21, 2019

没有就绪检测
错误的就绪检测
混淆了就绪检测和存活检测
不优雅的退出
不够优雅的优雅关闭，最好使用生命周期 Hook
Fork 模式

错误的存活检测过程可能加重负载问题（雪崩式故障加上延长容器应用启动时间的风险），会引发其他负面问题，例如破坏依赖（参见我另一篇关于 K3s 和 ACME 速率限制的文章）。存活检测和外部数据健康检查的依赖是最差的情况：数据库的一点小问题会重启你的所有应用。

在喊出“不要使用存活检测”口号之前，还是先看看存活检测和就绪检测的用途。

注意下文很多来自 Zalando 的内部文档。

就绪和存活检测

Kubernetes 提供了两个很棒的功能，分别是就绪检测和存活检测。这两个功能会周期性的执行一个动作（比如说发出 HTTP 请求，打开一个 TCP 连接或者在容器中运行一个命令），从而确认你的应用正在如常运行。

Kubernetes 使用就绪检测来探测容器是否准备好开始接收流量。如果 Pod 中所有的容器都准备就绪，这个 Pod 就被当做是就绪状态。这种信号的一个用途就是来控制 Kubernetes 服务的后端 Pod（尤其是 Ingress）。

Kubernetes 使用存活检测来确定是否需要重启容器。例如存活检测能够检查到运行中应用的死锁，这种应用正在运行，但是不会有任何进展。重启这种容器能够在有 Bug 的情况下提高应用的可用性，然而也可能会引起级联故障（见后）。

如果一个应用的存活或者就绪检测失败了，在尝试对其进行更新时，滚动更新的过程可能会挂死——K8s 会想要等待你的 Pod 进入就绪状态。

举个栗子

就绪检测会使用 HTTP 协议，检查 /health 路径（缺省行为：10 秒钟间隔、1 秒钟超时、成功阈值 1，失败阈值：3）：

...
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080
...

建议

对于使用 HTTP 端点提供服务（尤其是 REST 服务）的微服务来说，严重建议定义一个就绪检测，用来检测你的应用（Pod）是否准备好接收请求。
确认你的就绪检测设置覆盖了 Web 服务器的真实端口。
- 如果你的就绪检测中使用了管理员端口（比如说 9090），如果主要 HTTP 端口（例如 8080）准备就绪，务必要确认该端点仅返回 OK。
- 为就绪检测使用专属端口可能在主端口线程池的拥塞时报告错误的状态（主服务池已满，然而健康检测依然能够通过）。
确保就绪检测包含了数据库的初始化和迁移过程。
- 最简单的方式就是仅在初始化完成之后才打开 HTTP 端口，也就是说，不设置健康状态，只是不启动 Web 服务器，直到数据库迁移完成。
使用 http Get 访问知名的健康检查端点（例如 /health）来完成就绪检测。
理解缺省行为（缺省行为：10 秒钟间隔、1 秒钟超时、成功阈值 1，失败阈值 3）：
- 在大概 30 秒（3 次失败的检测）后，这个 Pod 会成为未就绪状态。
如果你的技术栈（例如 Java/Spring）允许的话，可以使用不同的管理端口，把监控、检测端口和业务流量分开。
- 注意前面提到的线程问题。
可以使用就绪检测来对应用进行缓存和预热，在容器完成预热之前，返回 503.
- 建议阅读 1.6 中新增的 stateupProbe

反对

不要依赖外部因素，以免发生雪崩
- 例如有个有状态的 REST 服务，其中包含了 10 个依赖一个 Postgres 数据库的 Pod：如果数据库和网络不稳定，会导致 10 个 Pod 关闭，很显然这种反应会让结果变得更差。
- Spring Data 的缺省行为是检查数据库连接。
- 这里所说的外部因素，还包含本集群中的其它 Pod，也就是说你的检测过程不应该依赖其它 Pod 的状态，以防止雪崩：
  - 对于具有分布式状态的应用(例如跨 Pod 的内存缓存)，可能会有所不同。
在清楚为什么要使用存活检测，了解其后果之前，不用使用存活检测
- 存活检测能够帮助你恢复“卡死”的容器，但是如果你的应用够成熟，是不应该出现这种情况的——更好的对策是有目的地崩溃，以恢复正常状态。
- 失败的存活检测会导致容器重启，可能会让性能问题更加恶化：容器重启是有停机时间的（损失时间至少是你的应用的启动时间，例如 30 秒），这样就会造成更多错误，让其它容器承受更多压力，可能引起更多容器的崩溃。
如果使用存活检测，不要让存活检测和就绪检测使用同样的条件
- 可以让存活检测使用同样的健康检测方法，但是设置更高的 failureThreshold（例如 3 次失败之后设置为未就绪，10 次失败后才让存活检测失败）
不要使用 exec 检测：这是一个已知问题，会导致僵尸进程。
- 参考 Datadog 的故障经历。

总结

在 Web App 中使用就绪检测来确定该 Pod 可以接受流量。
仅在的确需要时候使用存活检测。
不恰当的检测方法可能会损失可用性甚至有引发雪崩的危险。

The 99% case for application developers is:
- use readinessprobe
- don’t use livenessprobe
I see too often both are the same, because of time no one checks what the difference is and if so it’s not easy enough to understand the impact.
— Sandor Szücs (@sszuecs@hachyderm.io) (@sszuecs) September 22, 2019

在 OS X 下构建 ARM 64 镜像

Thu, 17 Oct 2019 01:51:55 +0800

Mac OS X 的 Docker 桌面版中加入了一个 buildx 的试验特性，启用之后，可以直接在 MAC 系统中构建 ARM64 和 ARM7 的镜像。启用方法很简单，打开 Docker 的配置窗口，进行如下配置：

打开这个功能之后，Docker 会重新启动一次，命令行中的 Docker 就多出一个 buildx 命令，可以用于构建异构镜像了。进行构建之前，首先进行初始化：

$ docker buildx create --name builderx
$ docker buildx use mybuilder
$ docker buildx inspect --bootstrap
...
Endpoint:  unix:///var/run/docker.sock
Status:    running

接下来我们随便写一个 Dockerfile：

FROM ubuntu:18.10
CMD ["tini", "--", "sleep", "1d"]

在镜像库或者 Docker hub 上创建一个新仓库，就可以尝试 Build->Push 的操作了：

$ docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7 -t dustise/debug-container:v0.2 . --push
 => [internal] load .dockerignore                                                                                    0.0s
 => => transferring context: 2B                                                                                      0.0s
 => [internal] load build definition from Dockerfile                                                                 0.0s
 => => transferring dockerfile: 182B                                                                                 0.0s
 => [linux/arm64 internal] load metadata for docker.io/library/ubuntu:18.10                                          3.5s
 => [linux/arm/v7 internal] load metadata for docker.io/library/ubuntu:18.10                                         4.0s
 => [linux/amd64 internal] load metadata for docker.io/library/ubuntu:18.10                                          3.5s
 => [linux/arm64 1/2] FROM docker.io/library/ubuntu:18.10@sha256:7d657275047118bb77b052c4c0ae43e8a289ca2879ebfa78a7  0.0s

 ...
 => => pushing layers                                                                                                5.1s
 => => pushing manifest for docker.io/dustise/debug-container:v0.2

接下来可以打开你的 Harbor 或者 Docker Hub 查看一下，镜像库中是否已经加入了多平台的镜像内容：

buildx 还有 save 语法，可以直接将构建结果输出为压缩包，但是目前还没有提供完整支持。

可能是最适合自定义的 Pipeline：Tekton

Thu, 03 Oct 2019 20:37:11 +0800

持续集成是云原生应用的支柱技术之一，因此在交付基于云原生的一些支撑产品的时候，CICD 是一个无法拒绝的需求。为了满足这种需要，自然而然会想到对 Jenkins(X) 或者 Gitlab 进行集成，然而这两个东西虽说功能强大，却也不是为了做螺丝钉而设计的，其中包含了大量的周边功能，并非我们产品的需要，并且其接口和 Pipeline 设计也不太容易复用和提供给用户进行定制，而 Tekton 这个东西就有趣多了：

Kubernetes 原生 Tekton 的所有配置都是使用 CRD 方式进行编写存储的，非常易于检索和使用。
配置和流程分离 Tekton 的 Pipeline 和配置可以分开编写，使用名称进行引用。
轻量级核心的 Pipeline 非常轻便，适合作为组件进行集成，另外也有周边的 Dashboard、Trigger、CLI 等工具，能够进一步挖掘其潜力。
可复用、组合的 Pipeline 构建方式非常适合在集成过程中对 Pipeline 进行定制。

安装

安装过程非常轻松：

$ kubectl apply -f \
    https://storage.googleapis.com/tekton-releases/latest/release.yaml
namespace/tekton-pipelines created
podsecuritypolicy.policy/tekton-pipelines created
clusterrole.rbac.authorization.k8s.io/tekton-pipelines-admin created
...
$ kubectl get pods -n tekton-pipelines
NAME                                           READY   STATUS    RESTARTS   AGE
tekton-pipelines-controller-5888756f5c-t5kgx   1/1     Running   0          2m10s
tekton-pipelines-webhook-7494f6f84b-gm92g      1/1     Running   0          2m10s

概念

今天的内容主要涉及几个 CRD：

Task：任务环节。
TaskRun：Task 对象的运行参数。
Pipeline：Task 的组合。
PipelineRun：Pipeline 的运行参数。

Hello world

这里有个比 Hello world 稍稍复杂一点的小例子：

下载一个文件。
传递给下一个环节。

为什么不用官方例子呢？我想糊弄过 CI/CD/DevOps 的同学们应该都清楚，能使用容器、能执行 Shell、能获得输出、能传递文件，这几个能力加起来，足够冒充工具链小能手了。循序渐进并不适合心急的朋友们。

下载文件并显示内容

首先引入的是 Task 对象：

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: get-http-file
spec:
  steps:
    - name: show
      image: dustise/sleep
      command:
        - curl
      args:
        - "-s"
        - "https://httpbin.org/ip"

这里定义了一个 Task CRD，使用 kubectl apply -f 提交到集群，会看到 task.tekton.dev/get-http-file created 的反馈信息。

要运行这个环节，可以创建一个 TaskRun 对象：

apiVersion: tekton.dev/v1alpha1
kind: TaskRun
metadata:
  name: get-http-file-run
spec:
  taskRef:
    name: get-http-file

提交之后，可以使用 kubectl get taskrun get-http-file-run -o yaml 来查看任务执行状况：

apiVersion: tekton.dev/v1alpha1
kind: TaskRun
metadata:
...
status:
...
  conditions:
  - message: All Steps have completed executing
    reason: Succeeded
    status: "True"
    type: Succeeded
  podName: get-http-file-run-pod-51fddd
...

这里能看到很多任务执行信息，还能看到执行这个步骤的 Pod 名称，看看它的日志：

$ kubectl logs -f get-http-file-run-pod-51fddd
{
  "origin": "165.22.223.124, 165.22.223.124"
}

看来 CICD 过程中的日志输出和命令执行基本是有保障的，那么如何完成工件的传递呢？

文件传递

通常我们都会想到使用 PVC 来进行文件存储和共享，例如：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: trans
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

首先把上面的步骤命令行改为：

command:
- curl
args:
- "-s"
- "-o"
- "/share/share.json"
- "https://httpbin.org/ip"
volumeMounts:
- name: trans
  mountPath: /share

第二个步骤就更加简单，只要显示文件内容即可：

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: display
spec:
  steps:
    - name: showcontent
      image: alpine
      command: ["cat"]
      args: ["/share/share.json"]
      volumeMounts:
        - name: trans
          mountPath: /share

这里需要使用 Pipeline 对象把步骤连接起来。

apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: pipeline1
spec:
  tasks:
  - name: step1
    taskRef:
      name: download
  - name: step2
    runAfter: [step1]
    taskRef:
      name: display

这里的定义，使用 Pipeline 对象把两个步骤串联起来，其中使用 taskRef 对我们定义的 download 和 display 两个 Task 对象进行引用，并且使用 runAfter 数组定义先后顺序。

和 TaskRun 类似，Pipeline 定义之后，还需要用 PipelineRun 对象来执行一次，上面的 Task 中只定义了 volumeMounts，具体的 Volume 就要在 PipelineRun 中定义：

apiVersion: tekton.dev/v1alpha1
kind: PipelineRun
metadata:
  name: pprun1
spec:
  pipelineRef:
    name: pipeline1
  podTemplate:
    volumes:
      - name: trans
        persistentVolumeClaim:
          claimName: trans

把 PipelineRun 提交到集群之后，就可以看到，Pipeline 开始运行，可以使用 kubectl get 和 kubectl logs 来查看运行情况。

结果

这个项目还是很符合它的名字的描述的，真的只有 Pipeline 而已，它的最重要职责就是用 CRD 进行解耦，用 Step->Task->Pipeline 的三级形式对 CICD 中的动作进行抽象和分离；用 Task/TaskRun 以及 Pipeline/PipelineRun/Resource 的组合，把运行环节和输入输出内容进行分离。这样一来，就提供了一个稳定、可重构和组合的过程引擎，以及可定制的执行能力。

Tekton 还提供了一些其它周边项目，例如 Dashboard、Trigger 等，能给 Pipeline 项目提供一定的帮助。

掀起 Traefik 2 的盖头来

Sun, 22 Sep 2019 17:54:03 +0800

Traefik 2.0 发布也有几天了，根据通稿来看，有几个新的功能值得注意：

开始使用 CRD 来完成原本使用 Ingress + 注解来完成的任务。
加入了一个中间件概念，来提供丰富多样的控制能力。
终于支持 TCP 了。

我的测试集群中经常会使用 Traefik 做 Ingress，又有 Maesh 加入 Service Mesh 的暖场战之中，所以 Traefik 2.0 还是值得看看的。它的文档做的还不太完善，着实花了一段时间来摸索，这里做个记录，方便后续的使用和学习。

安装

我知道开篇说安装特别 Low，但是奇葩的是这个版本的安装文档居然只提到了一个 Docker 下的安装过程，只是在一个不起眼的角落里有一个针对 Kubernetes 环境的安装清单。

我做了一些修改，源码参见：

这里有一点需要注意的，Traefik 缺省开放三个端口：80、443 和 8080，其中 8080 是管理端口。建议将其分为两个服务，把管理端口和业务端口做个隔离，方便使用不同策略进行访问控制。另外 Configmap 中加入了访问日志方便调试，可酌情关闭。

例如下面把 Ingress 端口分配给 Loadbalancer，而管理端口仅设置为 ClusterIP。

---
apiVersion: v1
kind: Service
metadata:
  name: traefik-ingress
  namespace: traefik-system
  labels:
    app: traefik
spec:
  ports:
  - name: https
    protocol: TCP
    port: 443
    targetPort: 443
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80
  type: LoadBalancer
  selector:
    app: traefik
---
apiVersion: v1
kind: Service
metadata:
  name: traefik-admin
  namespace: traefik-system
  labels:
    app: traefik
spec:
  ports:
  - name: admin
    protocol: TCP
    port: 8080
    targetPort: 8080
  type: ClusterIP
  selector:
    app: traefik
---

配置文件很简单，只要加入 Kubernetes 内部接口的端点即可：

providers:
  kubernetescrd:
    endpoint: https://kubernetes.default

然后给 80 和 443 端口所在的 Loadbalancer 提供一个域名，用于后续的规则设置。

部署测试服务

随便部署一个 HTTP 服务，例如 Istio 用到的 HTTPBIN

这个服务开放了 8000 端口提供 HTTP 服务，后面我们会用这个服务进行限流测试。

开放 Dashboard

前面把 Dashboard 的服务类型设置为 ClusterIP，创建一个 CRD 就能够通过 Traefik 开放服务了：

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: traefik-dashboard
spec:
  entryPoints:
    - web
  routes:
  - match: Host(`traefik.microservice.xyz`)
    kind: Rule
    services:
    - name: traefik-admin
      port: 8080

这里使用了一个表达式来对流量进行筛选，表达式目前的支持范围如下表所示：

接下来用了几个不同级别的对象：

entryPoints：开放端口，例如我们部署中的 web 或 websecure。
routes：路由规则。
match：一个匹配表达式，这里我们指定匹配域名 traefik.microservice.xyz
name 和 Port：此处使用 Service 的定义

提交之后，就可以使用指定域名访问 Dashboard 了：

当然了，这个并不重要。

开启一个插件

用同样的方法，给 HTTPBIN 开放一个路由：

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: httpbin
spec:
  entryPoints:
  - web
  routes:
  - kind: Rule
    match: Host(`httpbin.microservice.xyz`)
    services:
    - name: httpbin
      port: 8000

在路由定义中，可以使用插件，对该路由的进出流量进行处理，例如重定向、认证、重试等功能。

Ratelimit 的用法很简单，官网文档也有说明，我们模仿写一个：

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: httpbin-traffic
spec:
  rateLimit:
    burst: 1
    average: 2

其中的单位稍显死板，是 qps。但是怎么把这个对象加入到 Route 里面就不太明显了：

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: httpbin
...
    services:
    - name: httpbin
      port: 8000
    middlewares:
    - name: httpbin-traffic

提交之后，可以看看 Dashboard 去看看这条规则的详情：

这条路由的 Middleware 中加入了新的元素，下面可以测试一下：

$ siege httpbin.microservice.xyz/get
** SIEGE 4.0.4
** Preparing 25 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200     1.68 secs:     398 bytes ==> GET  /get
HTTP/1.1 429     1.68 secs:      17 bytes ==> GET  /get
HTTP/1.1 429     1.68 secs:      17 bytes ==> GET  /get
HTTP/1.1 429     1.68 secs:      17 bytes ==> GET  /get
HTTP/1.1 429     1.68 secs:      17 bytes ==> GET  /get

看到极少出现 200 的响应码，多数都是 429，证明限流生效了。

废话

真是不知道 Kubernetes 用户哪里对不起 Traefik 了。。

不要被锁定在反锁定的路上

Mon, 09 Sep 2019 11:31:21 +0800

原文：Don’t get locked up into avoiding lock-in

作者：Gregor Hohpe

减少或者避免被锁定，会消耗架构设计工作中的很大一部分成本。这是一个神圣的职责：架构就是提供选项，而锁定则刚好相反。然而锁定不是非白即黑的：摆脱某一方面的锁定，往往意味着在其它方面被锁定。同样地，开源软件之类的流行概念，据说天然的消除锁定，这并非事实。是时候详细考察一下锁定问题，防止我们被锁定在反锁定的路上。

架构师的主要职责之一就是提供选择。这些选项让系统能够容忍变化，有了选择的自由，我们可以耐心的等待信息完整之后才作出决定，以及应对一些预计外的事件。锁定的含义则刚好相反：锁定使得软件很难从一种方案切换到另一种方案。很多架构师可能会将锁定视为大敌，同时认为自己守护着 IT 世界中的自由，在这世界中，组件可以被随意替换和互联。

但是架构从来都不简单——这是个事关妥协的生意。经验丰富的架构师知道，锁定的重要性，可能会超过避免锁定的重要性。锁定有很多方面，有时候还可能是最佳方案。所以我们进入架构师电梯，仔细观察一下锁定这个事。

开源+混合多云=无锁定

近年来，我们用来部署软件的平台越来越强——现代云平台不止告诉我，我们的照片是小狗还是饼干，它们还会编译代码，进行部署，配置必要的基础设施，并保存数据。

这种便利性和生产力的急剧提高，带来了全新的锁定方式。吸引了很多架构师注意的混合多云方案，就是一个用于审视锁定问题的好例子。假设你有一个要部署到云上的应用。这很简单，但是在架构师的视角来看，却会有很多选择、很多权衡，尤其是在锁定方面。

你可能想要把你的应用部署在容器里。这听起来很棒，但是你会使用 ECS 来运行它么？这是 AWS 的专属。考虑 Kubernetes ？它是开源的而且能够在绝大多数环境上运行——其中也包括自建设施。问题解决了么？还没有——你被锁定在 Kubernetes 上了——想想那些 YAML 吧。所以这是从锁定走向锁定。如果你使用的是托管 Kubernetes 例如 GKE 和 EKS，你还可能被锁定到 Kubernetes 的特定版本和特定扩展上。

如果想要让软件运行在私有设施中，也还有 AWS Outposts 的选项，所以你还是有得选。但这还是 AWS 的专有品种。你可能已经被锁定到 VMWare，它也能和 VMWare 集成，所以这有什么不同么？Google 的 Anthos 也是同样产品，它使用开源组件构建而成，但还是专属品：你可以把应用迁移到不同的云上——前提是你继续使用 ANthos。所以这就是锁定的意思，对吧？

另外如果你把你的部署自动化和你的应用运行时漂亮的分割开来，是否意味着切换基础设施更容易了？降低锁定的风险了？嘿，甚至还有跨平台的基础设施即代码的工具呢，是不是就完全消灭这些担忧了？

至于存储方面，AWS S3 如何？其它云供应商提供了 S3 兼容的 API，所以 S3 可以视为兼容多云，没有锁定了，但 S3 的确是 AWS 的专属阿。还可以把所有数据访问藏到抽象层之后，然后适配本地环境，这样总算可以了？

看起来避免锁定不那么简单，甚至会让你迷失在逃离锁定之路上。尽管如此，我推荐 Simon Wardley 的 Take on Hybrid Cloud

锁定的阴影

电梯架构师（乘着架构师电梯上上下下的人）眼中的锁定是灰色的，而不是象有些人的眼里的非黑即白。在考虑系统设计时，他们会意识到象锁定或者耦合这种事情并不是一个非此即彼的事情。两个系统并不能简单的判断耦合与否，同样地，也无法简单的判断是否被锁定到一个产品。这种问题的内部是有一些微妙之处的。例如锁定问题可以拆分成多个维度：

供应商锁定：IT 人嘴里的锁定很多时候指的是这种情况。它描述的是难于从现有供应商切换到其竞争对手。举两个例子，如果想要从 Siebel CRM 迁移到 SalesForce CRM，或者从 IBM DB2 数据库切换到 Oracle，都会是伤筋动骨的事情，这就是锁定。供应商或多或少的会从这种锁定中受益。这种锁定中往往包含了对应的商业安排，例如长期授权和支持协议能够获得更好的折扣。
产品锁定：在从一个供应商的产品迁移到另一个供应商的产品时，供应商和产品都发生了变化，所以两者是可以合二为一的。开源产品能够避免厂商锁定，但是并无法避免产品锁定：如果你在使用 Kubernetes 或 Cassandra，就当然是被锁定到了特定产品的 API、配置和功能上了。如果在一个专业（尤其是企业）环境中工作，你可能还需要商业支持，这样就又产生了供应商锁定。深度定制、集成以及专用扩展，都是产品锁定的形态：这些做法都提高了更换产品的难度，开源产品也无法避免。
版本锁定：除了被锁定在产品上，还可能被锁定到特定版本。新版本如果破坏了现存的定制和扩展（SAP？）。有些版本更新可能还要你重做应用——比如 AngularJS 和 Angular2。还有更差劲的情况就是，版本锁定的传染：某特定的产品版本需要特定（通常是过期的）操作系统版本，或者类似的情况，这会让迁移的尝试变得困难重重。如果供应商决定弃用你的版本，或者停止整条产品线，这种锁定造成的后果就很严重：需要在失去支持和大动干戈之间作出选择。情况还可能进一步恶化：例如你的旧版本系统中发现了严重漏洞，却无法找到对应的更新。
架构锁定：还有可能被锁定到特定类型的架构之中。例如，在大量使用 Kubernetes 的过程中，你可能会构建很多的小服务，这些小服务可以以容器的形式进行部署，对外提供 API。如果想要迁移到 Serverless 架构，就要把服务的粒度向单一功能的方向进行调整，把状态管理转移到外部，实现事件驱动架构等等。这种变更往往意味着对应用架构的整体修改。
平台锁定：产品锁定的一种特例是平台锁定，常见于云平台。这种平台不仅支持应用运行，可能还掌握了你的用户账号以及相关的访问权限、安全策略、基础设施分配等方面。它们还提供了应用级别的服务，例如存储或机器学习，这通常也是专有的。远离这些服务看起来好像能够减少平台锁定，但是这种做法就否定了上云的主要动机。这就让人进退两难了。
技能锁定：在开发人员开始熟悉特定的产品或架构之后，技能锁定就产生了：要使用不同的产品和技术，就需要重新培训（或者招聘）开发人员，这都需要投入。技能的可用性是当今 IT 的一个主要约束，这种锁定也就非常实际了。有些小众的企业产品只有很少的开发者，这就直接导致了开发成本的上升。这种情况在使用定制语言，或者”只需配置“/“无需代码”的情况下尤为常见。
法务锁定：你可能会因为法务问题锁定到特定的解决方案，合规要求就是个常见情况。假设一个云供应商的数据中心在国外，你可能就无法把数据迁移到这个供应商的云上。有的软件即使是可以顺畅的在云上运行，供应商的授权可能也不允许它迁移上云。如果你坚持上云，就会违反授权条款。法务方面的限制远比我们平时所理解的要多，我们面临的选择好像：你的小飞机是由 70 年代设计的使用含铅汽油的过时引擎驱动的，然而新引擎的采用，可能产生巨大的法律风险。
智力锁定：最微不足道的也是最危险的锁定就是对思维的锁定。在和特定的供应商和架构合作之后，可能会把一些假设吸收到你的决策依据里，这可能会导致你拒绝其它方案。例如在面对横向扩展架构时，你可能因为它的扩展不够线性（两倍硬件没有产生两倍性能），得出效率低下的结论，从而拒绝这种方案。在技术层面，这种思考方式忽略了一个问题，这种方案的主旨在于扩展性，而不是效率。或者你会讨厌快速的发布周期，因为你相信频繁的变更会导致更多的缺陷。还有你可能会被告知，编码很昂贵、耗时并易错，所以最好用配置完成一切。

总的说来，锁定绝对不是简单的二元世界，理解了各种不同的锁定方式，有助于作出更加清晰的决策。这个列表也戳穿了一些常见的谬误，例如开源软件神奇的解除锁定的能力。开源软件能够防止厂商锁定，但是绝大多数其它的锁定同样存在。这当然不是说开源软件的坏话，只是说，开源软件并非治愈锁定的良药。

使用模型做好决策

有经验的架构师不会只盯住阴暗面，他们会执行优秀的决策纪律。纪律很重要，因为我们的决策能力往往比我们的自我感觉要差得多。如果这方面有疑问，建议阅读 Kahneman 的 Kahneman’s Thinking, Fast and Slow。

提高决策能力的最有效方法就是使用模型。就算是简单的模型，也能在改善决策的过程中提供很大帮助：

简单但令人回味的模型是伟大科学家的标志，过分的细化和参数化通常意味着平庸。 George Box

所以不要嘲笑深受管理咨询行业宠爱的二乘二矩阵，我们接下来会发现，这是一种非常简单有效的模型。

下一个事关模型的关键点：常识告诉我们，面对不确定性，必须尽快响应——毕竟世界一直在变。但是事与愿违：当我们必须处理很多相互依赖、高度不确定性以及小概率事件时，糟糕的决策会把事情搞得更糟。模型能帮助我们把更多的结构化和规律加入决策过程。是否接受锁定、接受什么样的锁定，都是这样的问题，所以我们要使用一些模型。

关于锁定的二乘二矩阵

一个简单的模型能够让我们克服以锁定为耻的观念。首先我们必须意识到，很难完全杜绝锁定的发生，因此一定程度的锁定在所难免。第二，如果锁定能带来与之相配的收益，那么我们也会乐见其成的，例如一个竞争对手所不具备的的独特的功能。

我们把这些因素用一个最简单的模型来表达——二乘二矩阵：

上面的矩阵使用以下的两个维度来描述我们的选择：

切换成本（也就是锁定）：对我们来说，迁移到别的方案有多难？
唯一的实用价值：我们从这个解决方案中获取了什么无法被其它工具取代的好处？

我们可以看看这四个分区了：

Disposable：没有独特功能且易于更换的组件是可以不太担心的。我们可以和他们维持现状，如果遇到问题，可以轻松的进行替换。普通的东西，普通的对待就很好。例如很多开发者的 IDE（EMACS 可能是个例外）都是这样的：随意混合搭配，无需过于依赖。存储你所有照片和个人数据的云存储，很大程度上把你的手机也变成了可抛弃的，稍候还会对这个例子进行更多介绍。
Accepted Lock-in：这个区域指的是把你锁定到特定产品和供应商的组件，但是这种锁定是有回报的——得到了独特的功能。虽然我们提倡减少锁定，但是这种交换相对来说是比较容易接受的。例如使用了 Google Cloud 的 BigQuery 或者 AWS 的 Bare Metal Instance，很明显就是被锁定了，然而这个锁定是根据收益作出的决策。如果是一个小应用，使用 AWS 原生服务也是可以的，这是因为没有迁移的需要，而缩减开发和运维成本是更重要的事情。
Caution：这部分是最不受欢迎的区域了，产生了锁定，但是又没有与之想匹配的回报。传统的关系数据库就可以放到这个位置——使用商用数据库真的增加了你的收入了么？没有。然而向外迁移可能需要很大投入。如果为发射到外太空的嵌入式系统选择了特定的硬件，这也没什么问题——几乎没有迁移的机会。
Ideal：这是最佳区域——提供了独特的实用价值，但是还能够方便的切换。听起来这好像是我们的理想境界，但是你会发现这个区域的定义是矛盾的：如果一个解决方案提供了唯一的实用价值，其它竞品无法提供，那他的切换就是困难的。S3 可能就是这个类别中的一个例子：多个云供应商都接受了同样的 API，迁移出去，例如迁移到 GCP 相对来说是很方便的。每个实现都会在某些方面有一些明显优势，要保护跨平台的可移植性，很重要的一点就是：不允许 API 保留授权或者取得专利。

这个模型的确很简单，把你的软件（或者硬件）组件放到这个矩阵里面是个值得尝试的做法。这样的方法不仅为你的风险进行了可视化，还把你的决策传达给了利益相关者。

举一个日常的例子，你可能决定使用下列物品，这些物品有各自的功能，也有锁定风险（从右上角开始逆时针方向）。

你所钟爱的 iPhone 把你锁定到了供应商的生态系统中，但是也给了你独有的体验，所以你认为这是可以接受的锁定。
移动通信服务商的合约把你锁定到了单一的网络上，但是各个服务商的区别其实不大，所以把它放到 Caution 是合适的。
充电器有标准接口，不幸的是很多 iPhone 不是，但是还有各种转换装置让这个小玩意处在 Disposable 位置。
很多 App，例如 Messaging，提供了功能，例如和朋友进行联系，但是他们的的设计就是方便切换的，例如通过手机的联系人名单，所以可以放在 Ideal。

这里要注意的就是唯一实用价值：每个供应商都会提供一些唯一功能——这就是差异化。然而这里需要关注的是这些功能是否能转化为唯一价值。例如有的云供应商提供了能够服务于十亿用户的强大全球网络。这令人印象深刻，也具备唯一性，但这对普通的企业来说却没什么意义，他们可能只服务于百万用户，也仅在单一国家内提供服务。当然也有人在有限速的小国家开法拉利的，并非所有决定都是理性的，但法拉利和云平台不同，可能给出不同的实用价值。

锁定的实际成本

这个简单的矩阵太有用了，完全停不下来。前面的矩阵把切换成本作为单一元素（维度），现在可以将其拆分为两个维度：

这个矩阵把替换的成本从替换的可能性（主动或者被动）拆分开来。较低的替换可能性结合较低的替换成本应该不会令人困扰，但是相对的替换成本较高、又有较高替换概率的就值得注意了。在另外一角，虽然替换成本高企，但是发生的可能性不大——这一区域可能需要做一些保全措施，措施包括限制更改范围，或者增加运维成本。你也可以选择接受这种风险——在 Oracle 和 DB2 之间进行切换的机会并不多。最后如果切换的可能性很大，成本又不高，那就无需费神了——拥抱变化，设计系统，完成切换。但奇怪的是，尽管大量的小范围变化很容易实现，但这种场景往往不会象左上角那样得到大量关注，这就是决策过程中经常出现的错误：难于完成的戏剧化场景，往往因为一个“万一”，吸引了更多的注意力。

在我们谈论锁定的意愿时，可能需要在多个角度考虑一下切换的理由：供应商退出业务、提价、或者无力支持现有规模以及功能需求。有趣的是，减少锁定的愿望经常成为谈判的手段：在续约谈判中，你可能会提示你的供应商，在产品架构设计角度来看，从他们的产品中切换是可行的，成本也是可以接受的。这样你就给出了 BATNA（Best Alternative To a Negotiated Agreement）够低的信息。这种架构方式虽然不一定会用起来，但它会产生实际的威慑力，就如冷战期间的物资储备一样。你可能只是伪装，并不会真的去除锁定，但是这种情况下，你最好是个好玩家，以免被供应商翻了底牌——比如和你的开发人员打探消息。

减少锁定：执行价格

再回到我们起初提到的选项类比问题，如果避免锁定给了你（多个）选项，那么切换成本就是这个选项的执行价格。有价值的选项应该能降低切换成本。我们当然希望所有系统都能在绿色区域中，具备最小的切换成本，但是实际发生的投资可能并不总能降低。

例如很多架构师会反对锁定到特定的数据库或者云供应商。然而发生切换的机率如何？5% 或者更少？那么你怎么才能把切换成本从 50000（假设）美金降低到接近于 0？切换成本远远大于 2500 美金（50000 * 5%）。因此最小化转换成本并非（架构设计的）唯一目标，很容易变成过度投资。这也类似过度保险：支付巨额溢价，能把免赔偿额度降低到 0，但这通常不是最经济最合理的选择。

一个最终模型（这是唯一一次不使用矩阵方式）能够帮助你决定，在降低切换成本上投入多少才是合适的。下图的蓝线，是转换可能性和转换成本的乘积，代表了转换的负债。这张图展示了它和前期投资的关系：

进行投资肯定能减少债务，或者降低执行成本、降低切换可能性也都能降低。例如使用 ORM 框架是一个较小的投资，能够降低对数据库厂商的锁定。还可以创建一个元数据语言，能够转换成每个厂商的数据库的本地存储过程语法。这能让你在不被锁定的情况下释放数据库的所有性能，但是这就需要为一个相对比较小众的场景进行大量投资了。

红线很有意思，表达的是前期投资和潜在债务的累计。这是应该尽量降低的总体花费。在多数情况下，随着前期投资的提高，会进入一个最佳区域。针对降低锁定的额外投资实际上会导致更高的总体成本。原因也很简单：投资回报率，尤其是在切换概率较低的时候。如果我们把架构做成超级有弹性，我们可能会进入过度投资的范围。Yagni（You ain’t gonna need it）的家伙们会走向另外一端——中庸之道是快乐之源。

避免锁定的总成本

现在在锁定方面我们对锁定的成本做了一些研究，我们需要更进一步的看看避免锁定的总体成本，前面的模型，我们假设避免锁定是一个简单的成本问题。实际上这个成本能够分解为几个不同方面。

工时：这需要一些额外的工作，最终都要算成工时的。如果我们选择在 Kubernetes 上部署容器以减少云提供商锁定，就需要投入工时学习新工具，编写 Dockerfile，配置 Kubernetes 等。
成本：额外的现金成本，比如说产品授权，雇佣外部供应商或者参加 KubeCon。
利用率不足：这是一种间接成本。为了不被锁定，经常会避免使用供应商特有的功能。这样就造成了对既有软件的使用不足。这样就意味着，要么投入工时补足缺失的部分，要么任由产品存在短板。
复杂性：复杂性是个经常被忽视的核心元素。很多减少锁定的方法就是引入新的抽象层：JDBC、容器、通用 API。所有的有用的工具，都会增加系统的总体复杂性，也就增加了新成员的学习成本，以及系统错误的机率。
新的锁定：避免一种锁定，往往会引起新的锁定。例如为了避免 AWS CloudFormation，取而代之的是 Terraform 或者 Pulumi，它们都支持多个云供应商。然而现在你就被锁定在额外供应商的其它产品上了，还是要鉴别一下这是否是你想要的。

架构师要计算减少锁定的成本，应该对这个列表做一个检查，看是不是存在什么盲点。同样地，避免锁定的尝试可能会是有泄漏的，例如 Terrorform 是个好工具，但是它的脚本使用了很多供应商特定的构造。实现细节的泄漏，就会提高云间切换的成本。

整合视角

有了这么多的理论铺垫，我们看看一些贴地气的例子。

部署容器

一个公司会把他们的代码打包为 Docker 容器，部署在 AWS ECS 上，所以它们锁定在了 AWS 上。应该引入开源的 Kubernetes 来避免锁定么？速度是它们的主要问题，当前的 ECS 解决方案表现很好，我认为迁移可能难有回报。切换云供应商的概率很低，它们有更重要的事情可以做。

建议：接受锁定。

关系型数据库访问

很多应用程序会使用关系型数据库，有很多厂商和开源产品。然而 SQL 的方言、存储过程以及定制的管理控制台都是锁定的。你要投资多少来避免锁定呢？多数语言和运行时通用框架（例如 Hibernetes）都以低成本提供了某种程度的数据库中立。如果希望降低执行价格，还应该避免使用 SQL 函数以及存储过程，但这会降低产品性能或提高硬件水平。

建议：使用低成本机制来降低锁定程度。不要想着零成本切换。

迁移上云

除了把数据库从一个供应商切换到另一个，你可能更感兴趣的是把应用和数据库迁移到云上。除了技术考量之外，你需要考虑一下有些供应商的授权协议可能会让这种迁移很不划算。这种情况下，选择一个开源数据库可能是个更好的办法。

建议：如果能够满足你的需要，那么选择一个开源的数据库，可能需要接受某种程度的锁定。

多云

很多企业痴迷于可移植到多云的想法，病体除了更复杂、更精密也更昂贵的计划，这些计划表面上可以让它们免于被云供应商锁定。然而大多数这些尝试，都在否定上云的初衷：低阻力以及使用托管服务（例如存储和数据库）的能力。

建议：谨慎从事。参考我在多云方面的文章。

用思维的速度做架构

似乎人们可以投入大量时间去关心锁定的问题。有些人甚至会因为我们的方法太过“学术性”而不予理会，学术性这个词我通常都无法认为是个贬义词，这是我们受教育的地方。不过老式的非此即彼的架构方法，是不是更简单，可能还更高效呢？

事实上，思维的速度很快。只需要几分钟就能够读完这篇文章里提到的所有模型，并作出良好的决策——无需任何花俏的工具，只需要纸或白板。快速完成架构思考的关键是集中注意力。而要做出精致的幻灯片，需要提前几周进行安排，通常也不会有具备实际专业知识的人参与并作出决策。

鸣谢

感谢作出有益反馈并提供输入的几位朋友：

Manlio Grillo

Michael Plöd

Michele Danieli

Scott Davis

Kustomize Fomulas

Fri, 06 Sep 2019 01:50:43 +0800

项目地址 Kustomize-patch-formulas

这个项目有两个目的。

第一点就是，既然有了 Kustomize，使用碎片来拼接复杂的 YAML 就很方便了，设想以下情况：

一个只会写简单 Deployment 的小白，随时要去翻书，查查如何加入资源限制，如何加载存储卷，如何设置环境变量….，翻完用完，俩月之后同样的痛苦再来一次，周而复始。。好吧我就是那个小白。

Kustomize 能不能让这个过程舒服一点？

开始摸索 Kustomize 之后，我觉得有救了，只要我把需要的配置碎片积累下来，用的时候稍作修改，然后用 Kustomize 渲染出来，是不是就省了不少麻烦了？另外对一些巨型的 YAML，比如多个 Deployment 和 Service 和 VirtualService 什么的混成一个文件的情况，直接上手修改是很辛苦的，用这种方式也可以方便快捷的进行一些变更。

更近一步的，这些补丁都很小，如果稍稍做点模板处理，用个小脚本加工成正式的 Patch，复用能力会进一步增强。

第二点就是，就算不考虑这些问题，把常见的配置碎片搜集起来也是对 Kubernetes 运维工作很有帮助的。

用法

例如我们有一个简单的 Deployment， /tmp/deploy.yaml：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flaskapp
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: flaskapp
        version: v1
    spec:
      containers:
        - name: flaskapp
          image: dustise/flaskapp
          imagePullPolicy: IfNotPresent
          env:
            - name: version
              value: v1
          ports:
            - containerPort: 80

克隆本项目之后，我们希望借助其中的补丁，为这个对象加入资源限制和 ServiceAccount：

$ ./gen_kustomize.py -i /tmp/deploy.yaml -o kust
$ tree kust
kust
├── base
│   ├── deploy.yaml
│   └── kustomization.yaml
└── overlay

这个命令会为该文件创建一个 Kustomization。其中的 -i 参数可以加入多个文件，都会被复制到目标目录（kust）的 base 之中。

接下来向其中加入补丁：

$ ./add_patch.py kubernetes/deployment/resource-patch.yaml \
    --set container_name=flaskapp deployment_name=flaskapp \
    limit_cpu=100m limit_memory=100Mi request_cpu=100m \
    request_memory=100Mi \
    -t kust
$ ./add_patch.py kubernetes/deployment/serviceaccount-patch.yaml \
    --set container_name=flaskapp \
    deployment_name=flaskapp service_account=default \
    -t kust

这里的第一个参数是补丁文件的位置，--set 后面以 key=value 的形式为模板进行赋值。模板的写法也很简单，例如：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: $deployment_name
spec:
  replicas: 1
  template:
    spec:
      serviceAccount: $service_account

使用的是 Python 模板，只要简单的在变量前加入 $ 即可，因为对 Helm 深感疲惫，暂时不准备接入太复杂的模板方式，毕竟补丁本身越小越精确就越好。

加入补丁之后，使用 kustomize build kust/overlay 进行渲染：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flaskapp
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: flaskapp
        version: v1
    spec:
      containers:
      - env:
        - name: version
          value: v1
        image: dustise/flaskapp
        imagePullPolicy: IfNotPresent
        name: flaskapp
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 100m
            memory: 100Mi
          requests:
            cpu: 100m
            memory: 100Mi
      serviceAccount: default

可以看到，这里生成了完整的目标文件。

需要贡献

这个项目还非常低级，不堪一用，觉得这个小东西有意思的朋友可以提供：

新的补丁模板。
测试框架。
新的玩法。
各种建议。

Funny Kind

Thu, 29 Aug 2019 02:57:10 +0800

昨天的帖子可能是这个公众号诞生以来好笑的一幕——这个实操环节因为错上加错，收获了一个正确结果，以及好几个“在看”。

事实上我们编写的 config.yaml，在文末的命令行中并没有引用，所以其中的快速安装的结果完全是 Kind 的功劳，和之前的证书操作、镜像操作没有一毛钱的关系。Kind 镜像自带了 Kubeadm 部署所需内容，因此它的的离线安装正常来说只需要：

Docker 正常运转
本地有 Kind 镜像。

私库之类的东西，完全不需要。

昨天的错误原因主要在于：Docker 信任的 CA，并不被 Dind 所接受，所以要使用私库，首先要把自签发 CA 加入 Kind 镜像的信任列表，源码显示，它用的是 Ubuntu，因此可以这样构建一个新镜像：

FROM kindest/node:v1.15.3
COPY ca.crt /usr/local/share/ca-certificates/ca.crt
RUN update-ca-certificates

有了这个信任关系，就可以从容的使用私库了，例如：

#!/bin/sh
kind create cluster --image kindest/node:customize \
    --config config/kind-config.yaml

使用这个镜像，就会加入对私库的信任关系，也就能够满足使用私库的需求了。

使用 Kind 构建离线集群安装包

Tue, 27 Aug 2019 23:29:07 +0800

Kind（Kubernetes in Docker）是一个 Kubernetes 孵化项目，它使用 Docker 为节点进行 Kubernetes 的快速部署，可以方便的搭建 Kubernetes 集群，虽然简单，但也是通过 Kubernetes 一致性认证的安装器，因此用来做测试还是比较可靠的。

按照社区的一贯德行，安装过程虽然只要有个 Docker 就可以了，但是对网络有严重的依赖。在 Workshop 之类的场合，会受到很大限制。这种情况下，有一个离线包就会非常方便了。

获取安装文件

本文会从一个新安装的 CentOS Mini 服务器为例，逐个步骤展示构建离线 Kind 安装包的过程。最后再安装一个

这里假设这个服务器有“优秀”的互联网连接。

Docker 离线包

首先我们要为 Docker 的离线安装准备好 RPM 包，新建一个目录 rpms，用来下载安装包：

$ yum install --downloadonly --downloaddir=./rpms \
    yum-utils device-mapper-persistent-data lvm2

执行完毕之后，会在 rpms 目录中找到 Docker 的依赖包，接下来获取 Docker 的 RPM。

$ yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo
$ yum --downloadonly --downloaddir=./rpms \
    install docker-ce docker-ce-cli containerd.io

如此就获得了 Docker 自身以及所有的依赖 RPM 包。可以使用 rpm 直接安装。并启动 Docker 服务。

Kubeadm 和 Kubectl

根据官方文档：

$ cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

$ yum install --downloadonly --downloaddir=./rpms \
kubectl kubeadm --disableexcludes=kubernetes

这里做了一点修改：不再安装 kubelet，也不启动服务，仅用于获取安装包。

获取镜像

使用 rpm 安装 kubeadm，开始获取安装所需的所有镜像：

$ kubeadm config images list --kubernetes-version=v1.15.3
k8s.gcr.io/kube-apiserver:v1.15.3
k8s.gcr.io/kube-controller-manager:v1.15.3
k8s.gcr.io/kube-scheduler:v1.15.3
k8s.gcr.io/kube-proxy:v1.15.3
k8s.gcr.io/pause:3.1
k8s.gcr.io/etcd:3.3.10
k8s.gcr.io/coredns:1.3.1

拿到列表了就可以逐个拉取处理镜像，这里给个小脚本：

#!/bin/sh
for image in `kubeadm config images list --kubernetes-version=$1`
do
  image_name=`echo ${image} | sed "s/k8s.gcr.io.//g"`
  docker pull "${image}"
  docker tag "${image}" "${image_name}"
  file_name="${image_name}.tgz"
  docker save "${image_name}" | gzip > "${file_name}"
  docker rmi "${image}"
  docker rmi "${image_name}"
done

这样我们就有了所有 Kubeadm 所需的镜像。另外我们还需要两个辅助镜像：kindest/node:v1.15.3 以及 registry:2.7.1。

CFSSL 和 Kind

$ wget https://github.com/kubernetes-sigs/kind/releases/download/v0.5.1/kind-linux-amd6
$ wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
$ wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64

这样我们已经获得了所有安装所需的文件。可以进入离线步骤了。

安装

RPM 安装

把前面获得的 Kubectl 安装起来。

签发证书

使用 CFSSL 生成证书，首先生成 CA。

ca-csr.json：

{
    "CN": "Kubernetes CA",
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "ca": {
       "expiry": "87600h"
    }
}

cfssl gencert -initca ca-csr.json | cfssljson -bare ca 生成 CA 证书。

把证书加入信任列表：

$ update-ca-trust enable
$ cp ca.pem /etc/pki/ca-trust/source/anchors/
$ update-ca-trust extract

更新之后，需要重启 Docker 服务，让 Docker 也信任这一 CA。

然后是生成镜像库所需的服务器证书：

config.json：

{
    "signing": {
        "default": {
            "expiry": "87600h"
        },
        "profiles": {
            "server": {
                "expiry": "87600h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "server auth",
                    "client auth"
                ]
            },
            "user": {
                "expiry": "87600h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "client auth"
                ]
            }
        }
    }
}

server.json：

{
    "CN": "Registry",
    "hosts": [
      "127.0.0.1","10.211.55.10"
    ]
}

接下来签发证书：

$ cfssl gencert -ca ca.pem -ca-key ca-key.pem -config=config.json \
     -profile=server server.json | cfssljson -bare registry

这里的 IP 地址要跟本地地址对应。

启动镜像库

使用 docker load -i，载入了 registry 镜像，把仓库运行起来：

#!/bin/sh
docker run -d \
   --name="registry2" \
   -v "$(pwd)/storage":/var/lib/registry \
   -p 5000:5000 \
  -v "$(pwd)/certs":/certs \
  -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/registry.pem \
  -e REGISTRY_HTTP_TLS_KEY=/certs/registry-key.pem \
   --restart=always \
   registry:2.7.1

如此就在 5000 端口启动了一个镜像库。

推送镜像到私库

把前面的所有镜像都载入 Docker，Tag 之后推入私库，最后在私库里就有了一系列的镜像，例如 10.211.55.10:5000/pause:3.1。

安装集群

为了能够使用私库的镜像，要对 Kind 进行一点配置：

kind: Cluster
apiVersion: kind.sigs.k8s.io/v1alpha3
kubeadmConfigPatches:
- |
  apiVersion: kubeadm.k8s.io/v1beta2
  kind: ClusterConfiguration
  metadata:
    name: config
  networking:
    serviceSubnet: 10.0.0.0/16
  imageRepository: 10.211.55.10:5000
  nodeRegistration:
    kubeletExtraArgs:
      pod-infra-container-image: 10.211.55.10:5000/pause:3.1
- |
  apiVersion: kubeadm.k8s.io/v1beta2
  kind: InitConfiguration
  metadata:
    name: config
  networking:
    serviceSubnet: 10.0.0.0/16
  imageRepository: 10.211.55.10:5000
nodes:
- role: control-plane

$ kind create cluster --image kindest/node:v1.15.3
Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.15.3) 🖼
 ✓ Preparing nodes 📦
 ✓ Creating kubeadm config 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Cluster creation complete. You can now use the cluster with:

export KUBECONFIG="$(kind get kubeconfig-path --name="kind")"

如此这般，Kind 集群就启动了。我们可以测试一下：

$ export KUBECONFIG="$(kind get kubeconfig-path --name="kind")"
$ kubectl get pods --all-namespaces
NAMESPACE     NAME                                         READY   STATUS    RESTARTS   AGE
kube-system   coredns-5c98db65d4-lkg92                     1/1     Running   0          72m
kube-system   coredns-5c98db65d4-rhv7g                     1/1     Running   0          72m
kube-system   etcd-kind-control-plane                      1/1     Running   0          71m
kube-system   kindnet-892gh                                1/1     Running   1          72m
kube-system   kube-apiserver-kind-control-plane            1/1     Running   0          71m
kube-system   kube-controller-manager-kind-control-plane   1/1     Running   0          71m
kube-system   kube-proxy-nd4ml                             1/1     Running   0          72m
kube-system   kube-scheduler-kind-control-plane            1/1     Running   0          71m

离线环境下部署镜像

Kind 提供了一个 load 命令，可以把镜像载入所有“节点”，例如：

$ kind load docker-image 10.211.55.10:5000/registry:2.7.1
$ kubectl run registry --image=10.211.55.10:5000/registry:2.7.1 --replicas=2
$ kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/registry created
$ kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
registry-6b7648c4f4-g8zxr   1/1     Running   0          24s

后记

很明显，这些步骤是可以自动化的，只需要分发一个安装包，就能够很方便的快速部署、删除一整套的 Kubernetes，可以用随需部署的方式完成环境的搭建和删除。

kubectl exec 的来龙去脉

Tue, 27 Aug 2019 18:16:58 +0800

原文：How does ‘kubectl exec’ work?

作者：Erkan Erol

上周五，一个同事问了我一个问题——如何使用 client-go 在 Pod 中执行命令。我答不出来，而且注意到我从来没想过 kubectl exec 的实现机制。我对这个问题有一点认识，但又不是很确定。我记下了这个题目，进行了一番探索，在阅读了大量博客、文档和代码之后，收获了很多知识。本文中我会分享这个过程中的理解和发现。

环境

我使用 https://github.com/ecomm-integration-ballerina/kubernetes-cluster 中的工具在我的 Macbook 上创建 Kubernetes 集群。缺省配置不允许运行 kubectl exec，我在 Kubelet 配置中修改了 IP 地址，具体原因参见博客：Playing with kubeadm in Vagrant Machines。

Any machine = my MacBook
IP of master node = 192.168.205.10
IP of worker node = 192.168.205.11
API server port = 6443

组件

kubectl exec 进程：在我们运行 kubectl exec 时，会启动一个进程。可以在任何一台能够访问到 Kubernetes API Server 的机器上运行该命令。
api-server：运行在 Master 上，提供开放的 Kubernetes API，它是 Kubernetes 控制平面的前端。
kubelet：在集群所有节点上都会运行这个进程，它负责让容器以 Pod 的模式运行。
容器运行时：负责运行容器，例如 Docker、cri-o、containerd…
内核：工作节点上的操作系统内核，负责管理进程。
目标容器：组成 Pod 的容器，在工作节点上运行。

探索

客户端的活动

在缺省命名空间中创建一个 Pod：

# kubectl run exec-test-nginx --image=nginx

执行 sleep 5000，来进行观察：

# ps -ef |grep kubectl
501  8507  8409   0  7:19PM ttys000    0:00.13 kubectl exec -it exec-test-nginx-6558988d5-fgxgg -- sh

检查该进程的网络活动，会看到连接到 API Server 的通信（192.168.205.10.6443）

$ netstat -atnv |grep 8507
tcp4       0      0  192.168.205.1.51673    192.168.205.10.6443    ESTABLISHED 131072 131768   8507      0 0x0102 0x00000020
tcp4       0      0  192.168.205.1.51672    192.168.205.10.6443    ESTABLISHED 131072 131768   8507      0 0x0102 0x00000028

再看看代码。kubectl 发起了一个包含 exec 子资源的 POST 请求：

req := restClient.Post().
        Resource("pods").
        Name(pod.Name).
        Namespace(pod.Namespace).
        SubResource("exec")
req.VersionedParams(&corev1.PodExecOptions{
        Container: containerName,
        Command:   p.Command,
        Stdin:     p.Stdin,
        Stdout:    p.Out != nil,
        Stderr:    p.ErrOut != nil,
        TTY:       t.Raw,
}, scheme.ParameterCodec)

return p.Executor.Execute("POST", req.URL(), p.Config, p.In, p.Out, p.ErrOut, t.Raw, sizeQueue)

Master 上的活动

在 API Server 端当然也能观察到请求的情况：

handler.go:143] kube-apiserver: POST "/api/v1/namespaces/default/pods/exec-test-nginx-6558988d5-fgxgg/exec" satisfied by gorestful with webservice /api/v1
upgradeaware.go:261] Connecting to backend proxy (intercepting redirects) https://192.168.205.11:10250/exec/default/exec-test-nginx-6558988d5-fgxgg/exec-test-nginx?command=sh&input=1&output=1&tty=1
Headers: map[Connection:[Upgrade] Content-Length:[0] Upgrade:[SPDY/3.1] User-Agent:[kubectl/v1.12.10 (darwin/amd64) kubernetes/e3c1340] X-Forwarded-For:[192.168.205.1] X-Stream-Protocol-Version:[v4.channel.k8s.io v3.channel.k8s.io v2.channel.k8s.io channel.k8s.io]]

HTTP 请求中包含了协议升级的请求，SPDY 允许在单个 TCP 连接上复用独立的 stdin/stdout/stderr/spdy-error 流。

API Server 收到请求，绑定到 PodExecOptions：

// PodExecOptions is the query options to a Pod's remote exec call
type PodExecOptions struct {
        metav1.TypeMeta

        // Stdin if true indicates that stdin is to be redirected for the exec call
        Stdin bool

        // Stdout if true indicates that stdout is to be redirected for the exec call
        Stdout bool

        // Stderr if true indicates that stderr is to be redirected for the exec call
        Stderr bool

        // TTY if true indicates that a tty will be allocated for the exec call
        TTY bool

        // Container in which to execute the command.
        Container string

        // Command is the remote command to execute; argv array; not executed within a shell.
        Command []string
}

为了执行必要的动作，API Server 需要知道联系地址：

// ExecLocation returns the exec URL for a pod container. If opts.Container is blank
// and only one container is present in the pod, that container is used.
func ExecLocation(
        getter ResourceGetter,
        connInfo client.ConnectionInfoGetter,
        ctx context.Context,
        name string,
        opts *api.PodExecOptions,
) (*url.URL, http.RoundTripper, error) {
        return streamLocation(getter, connInfo, ctx, name, opts, opts.Container, "exec")
}

当然这个端点是来自 Node：

nodeName := types.NodeName(pod.Spec.NodeName)
if len(nodeName) == 0 {
        // If pod has not been assigned a host, return an empty location
        return nil, nil, errors.NewBadRequest(fmt.Sprintf("pod %s does not have a host assigned", name))
}
nodeInfo, err := connInfo.GetConnectionInfo(ctx, nodeName)

Kubelet 提供了一个端口，API Server 可以进行连接：

// GetConnectionInfo retrieves connection info from the status of a Node API object.
func (k *NodeConnectionInfoGetter) GetConnectionInfo(ctx context.Context, nodeName types.NodeName) (*ConnectionInfo, error) {
        node, err := k.nodes.Get(ctx, string(nodeName), metav1.GetOptions{})
        if err != nil {
                return nil, err
        }

        // Find a kubelet-reported address, using preferred address type
        host, err := nodeutil.GetPreferredNodeAddress(node, k.preferredAddressTypes)
        if err != nil {
                return nil, err
        }

        // Use the kubelet-reported port, if present
        port := int(node.Status.DaemonEndpoints.KubeletEndpoint.Port)
        if port <= 0 {
                port = k.defaultPort
        }

        return &ConnectionInfo{
                Scheme:    k.scheme,
                Hostname:  host,
                Port:      strconv.Itoa(port),
                Transport: k.transport,
        }, nil
}

API Server to Kubelet Kubelet 开放的是一个 HTTPS 端点。缺省情况下 API Server 是不会验证 Kubelet 的服务证书的，这样这个连接就存在遭到中间人攻击的隐患，在不受信任的或者公开的网络上运行是不安全的。

现在，API Server 得到了端点地址，打开连接：

// Connect returns a handler for the pod exec proxy
func (r *ExecREST) Connect(ctx context.Context, name string, opts runtime.Object, responder rest.Responder) (http.Handler, error) {
        execOpts, ok := opts.(*api.PodExecOptions)
        if !ok {
                return nil, fmt.Errorf("invalid options object: %#v", opts)
        }
        location, transport, err := pod.ExecLocation(r.Store, r.KubeletConn, ctx, name, execOpts)
        if err != nil {
                return nil, err
        }
        return newThrottledUpgradeAwareProxyHandler(location, transport, false, true, true, responder), nil
}

看看 Master 上发生了什么。

首先确定一下工作节点的 IP，这里是 192.168.205.11：

$ kubectl get nodes k8s-node-1 -o wide
NAME         STATUS   ROLES    AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
k8s-node-1   Ready    <none>   9h    v1.15.3   192.168.205.11   <none>        Ubuntu 16.04.6 LTS   4.4.0-159-generic   docker://17.3.3

然后查找 Kubelet 的端口号：

$ kubectl get nodes k8s-node-1 -o jsonpath='{.status.daemonEndpoints.kubeletEndpoint}'
map[Port:10250]

接下来看看是不是存在到工作节点的连接？看到连接之后，如果杀掉 exec 进程，这个连接就会消失。这说明这个连接是 API Server 响应 exec 请求而生成的：

$ netstat -atn |grep 192.168.205.11
tcp        0      0 192.168.205.10:37870    192.168.205.11:10250    ESTABLISHED
...

目前为止，kubectl 和 API Server 之间的连接还存在，并且 API Server 和 Kubelet 之间也建立了连接。

工作节点上的活动

接下来我们连接到工作节点上，看看这里发生了什么。

首先我们同样能看到连接，第二行显示了 Master 的地址：192.168.205.10。

// worker node
$ netstat -atn |grep 10250
tcp6       0      0 :::10250                :::*                    LISTEN
tcp6       0      0 192.168.205.11:10250    192.168.205.10:37870    ESTABLISHED

我们的 sleep 命令呢？也可以看到：

// worker node
$ ps -afx
...
31463 ?        Sl     0:00      \_ docker-containerd-shim 7d974065bbb3107074ce31c51f5ef40aea8dcd535ae11a7b8f2dd180b8ed583a /var/run/docker/libcontainerd/7d974065bbb3107074ce31c51
31478 pts/0    Ss     0:00          \_ sh
31485 pts/0    S+     0:00              \_ sleep 5000
...

Kubelet 是如何做到的？

Kubelet 提供了一个服务端口，用来响应 API Server 的请求：

// Server is the library interface to serve the stream requests.
type Server interface {
        http.Handler

        // Get the serving URL for the requests.
        // Requests must not be nil. Responses may be nil iff an error is returned.
        GetExec(*runtimeapi.ExecRequest) (*runtimeapi.ExecResponse, error)
        GetAttach(req *runtimeapi.AttachRequest) (*runtimeapi.AttachResponse, error)
        GetPortForward(*runtimeapi.PortForwardRequest) (*runtimeapi.PortForwardResponse, error)

        // Start the server.
        // addr is the address to serve on (address:port) stayUp indicates whether the server should
        // listen until Stop() is called, or automatically stop after all expected connections are
        // closed. Calling Get{Exec,Attach,PortForward} increments the expected connection count.
        // Function does not return until the server is stopped.
        Start(stayUp bool) error
        // Stop the server, and terminate any open connections.
        Stop() error
}

Kubelet 为 exec 请求生成一个响应端点：

func (s *server) GetExec(req *runtimeapi.ExecRequest) (*runtimeapi.ExecResponse, error) {
        if err := validateExecRequest(req); err != nil {
                return nil, err
        }
        token, err := s.cache.Insert(req)
        if err != nil {
                return nil, err
        }
        return &runtimeapi.ExecResponse{
                Url: s.buildURL("exec", token),
        }, nil
}

它返回的不是命令结果，而是一个用于通信的端点：

type ExecResponse struct {
        // Fully qualified URL of the exec streaming server.
        Url                  string   `protobuf:"bytes,1,opt,name=url,proto3" json:"url,omitempty"`
        XXX_NoUnkeyedLiteral struct{} `json:"-"`
        XXX_sizecache        int32    `json:"-"`
}

Kubelet 实现了一个 CRI 规范中的 RuntimeServiceClient 接口：

// For semantics around ctx use and closing/ending streaming RPCs, please refer to https://godoc.org/google.golang.org/grpc#ClientConn.NewStream.
type RuntimeServiceClient interface {
        // Version returns the runtime name, runtime version, and runtime API version.
        Version(ctx context.Context, in *VersionRequest, opts ...grpc.CallOption) (*VersionResponse, error)
        // RunPodSandbox creates and starts a pod-level sandbox. Runtimes must ensure
        // the sandbox is in the ready state on success.
        RunPodSandbox(ctx context.Context, in *RunPodSandboxRequest, opts ...grpc.CallOption) (*RunPodSandboxResponse, error)
        // StopPodSandbox stops any running process that is part of the sandbox and
        // reclaims network resources (e.g., IP addresses) allocated to the sandbox.
        // If there are any running containers in the sandbox, they must be forcibly
        // terminated.
        // This call is idempotent, and must not return an error if all relevant
        // resources have already been reclaimed. kubelet will call StopPodSandbox
        // at least once before calling RemovePodSandbox. It will also attempt to
        // reclaim resources eagerly, as soon as a sandbox is not needed. Hence,
        // multiple StopPodSandbox calls are expected.
        StopPodSandbox(ctx context.Context, in *StopPodSandboxRequest, opts ...grpc.CallOption) (*StopPodSandboxResponse, error)
        // RemovePodSandbox removes the sandbox. If there are any running containers
        // in the sandbox, they must be forcibly terminated and removed.
        // This call is idempotent, and must not return an error if the sandbox has
        // already been removed.
        RemovePodSandbox(ctx context.Context, in *RemovePodSandboxRequest, opts ...grpc.CallOption) (*RemovePodSandboxResponse, error)
        // PodSandboxStatus returns the status of the PodSandbox. If the PodSandbox is not
        // present, returns an error.
        PodSandboxStatus(ctx context.Context, in *PodSandboxStatusRequest, opts ...grpc.CallOption) (*PodSandboxStatusResponse, error)
        // ListPodSandbox returns a list of PodSandboxes.
        ListPodSandbox(ctx context.Context, in *ListPodSandboxRequest, opts ...grpc.CallOption) (*ListPodSandboxResponse, error)
        // CreateContainer creates a new container in specified PodSandbox
        CreateContainer(ctx context.Context, in *CreateContainerRequest, opts ...grpc.CallOption) (*CreateContainerResponse, error)
        // StartContainer starts the container.
        StartContainer(ctx context.Context, in *StartContainerRequest, opts ...grpc.CallOption) (*StartContainerResponse, error)
        // StopContainer stops a running container with a grace period (i.e., timeout).
        // This call is idempotent, and must not return an error if the container has
        // already been stopped.
        // TODO: what must the runtime do after the grace period is reached?
        StopContainer(ctx context.Context, in *StopContainerRequest, opts ...grpc.CallOption) (*StopContainerResponse, error)
        // RemoveContainer removes the container. If the container is running, the
        // container must be forcibly removed.
        // This call is idempotent, and must not return an error if the container has
        // already been removed.
        RemoveContainer(ctx context.Context, in *RemoveContainerRequest, opts ...grpc.CallOption) (*RemoveContainerResponse, error)
        // ListContainers lists all containers by filters.
        ListContainers(ctx context.Context, in *ListContainersRequest, opts ...grpc.CallOption) (*ListContainersResponse, error)
        // ContainerStatus returns status of the container. If the container is not
        // present, returns an error.
        ContainerStatus(ctx context.Context, in *ContainerStatusRequest, opts ...grpc.CallOption) (*ContainerStatusResponse, error)
        // UpdateContainerResources updates ContainerConfig of the container.
        UpdateContainerResources(ctx context.Context, in *UpdateContainerResourcesRequest, opts ...grpc.CallOption) (*UpdateContainerResourcesResponse, error)
        // ReopenContainerLog asks runtime to reopen the stdout/stderr log file
        // for the container. This is often called after the log file has been
        // rotated. If the container is not running, container runtime can choose
        // to either create a new log file and return nil, or return an error.
        // Once it returns error, new container log file MUST NOT be created.
        ReopenContainerLog(ctx context.Context, in *ReopenContainerLogRequest, opts ...grpc.CallOption) (*ReopenContainerLogResponse, error)
        // ExecSync runs a command in a container synchronously.
        ExecSync(ctx context.Context, in *ExecSyncRequest, opts ...grpc.CallOption) (*ExecSyncResponse, error)
        // Exec prepares a streaming endpoint to execute a command in the container.
        Exec(ctx context.Context, in *ExecRequest, opts ...grpc.CallOption) (*ExecResponse, error)
        // Attach prepares a streaming endpoint to attach to a running container.
        Attach(ctx context.Context, in *AttachRequest, opts ...grpc.CallOption) (*AttachResponse, error)
        // PortForward prepares a streaming endpoint to forward ports from a PodSandbox.
        PortForward(ctx context.Context, in *PortForwardRequest, opts ...grpc.CallOption) (*PortForwardResponse, error)
        // ContainerStats returns stats of the container. If the container does not
        // exist, the call returns an error.
        ContainerStats(ctx context.Context, in *ContainerStatsRequest, opts ...grpc.CallOption) (*ContainerStatsResponse, error)
        // ListContainerStats returns stats of all running containers.
        ListContainerStats(ctx context.Context, in *ListContainerStatsRequest, opts ...grpc.CallOption) (*ListContainerStatsResponse, error)
        // UpdateRuntimeConfig updates the runtime configuration based on the given request.
        UpdateRuntimeConfig(ctx context.Context, in *UpdateRuntimeConfigRequest, opts ...grpc.CallOption) (*UpdateRuntimeConfigResponse, error)
        // Status returns the status of the runtime.
        Status(ctx context.Context, in *StatusRequest, opts ...grpc.CallOption) (*StatusResponse, error)
}

使用 gRPC 通过 CRI 调用方法：

type runtimeServiceClient struct {
        cc *grpc.ClientConn
}

func (c *runtimeServiceClient) Exec(ctx context.Context, in *ExecRequest, opts ...grpc.CallOption) (*ExecResponse, error) {
        out := new(ExecResponse)
        err := c.cc.Invoke(ctx, "/runtime.v1alpha2.RuntimeService/Exec", in, out, opts...)
        if err != nil {
                return nil, err
        }
        return out, nil
}

容器运行时负责实现 RuntimeServiceServer：

// RuntimeServiceServer is the server API for RuntimeService service.
type RuntimeServiceServer interface {
        // Version returns the runtime name, runtime version, and runtime API version.
        Version(context.Context, *VersionRequest) (*VersionResponse, error)
        // RunPodSandbox creates and starts a pod-level sandbox. Runtimes must ensure
        // the sandbox is in the ready state on success.
        RunPodSandbox(context.Context, *RunPodSandboxRequest) (*RunPodSandboxResponse, error)
        // StopPodSandbox stops any running process that is part of the sandbox and
        // reclaims network resources (e.g., IP addresses) allocated to the sandbox.
        // If there are any running containers in the sandbox, they must be forcibly
        // terminated.
        // This call is idempotent, and must not return an error if all relevant
        // resources have already been reclaimed. kubelet will call StopPodSandbox
        // at least once before calling RemovePodSandbox. It will also attempt to
        // reclaim resources eagerly, as soon as a sandbox is not needed. Hence,
        // multiple StopPodSandbox calls are expected.
        StopPodSandbox(context.Context, *StopPodSandboxRequest) (*StopPodSandboxResponse, error)
        // RemovePodSandbox removes the sandbox. If there are any running containers
        // in the sandbox, they must be forcibly terminated and removed.
        // This call is idempotent, and must not return an error if the sandbox has
        // already been removed.
        RemovePodSandbox(context.Context, *RemovePodSandboxRequest) (*RemovePodSandboxResponse, error)
        // PodSandboxStatus returns the status of the PodSandbox. If the PodSandbox is not
        // present, returns an error.
        PodSandboxStatus(context.Context, *PodSandboxStatusRequest) (*PodSandboxStatusResponse, error)
        // ListPodSandbox returns a list of PodSandboxes.
        ListPodSandbox(context.Context, *ListPodSandboxRequest) (*ListPodSandboxResponse, error)
        // CreateContainer creates a new container in specified PodSandbox
        CreateContainer(context.Context, *CreateContainerRequest) (*CreateContainerResponse, error)
        // StartContainer starts the container.
        StartContainer(context.Context, *StartContainerRequest) (*StartContainerResponse, error)
        // StopContainer stops a running container with a grace period (i.e., timeout).
        // This call is idempotent, and must not return an error if the container has
        // already been stopped.
        // TODO: what must the runtime do after the grace period is reached?
        StopContainer(context.Context, *StopContainerRequest) (*StopContainerResponse, error)
        // RemoveContainer removes the container. If the container is running, the
        // container must be forcibly removed.
        // This call is idempotent, and must not return an error if the container has
        // already been removed.
        RemoveContainer(context.Context, *RemoveContainerRequest) (*RemoveContainerResponse, error)
        // ListContainers lists all containers by filters.
        ListContainers(context.Context, *ListContainersRequest) (*ListContainersResponse, error)
        // ContainerStatus returns status of the container. If the container is not
        // present, returns an error.
        ContainerStatus(context.Context, *ContainerStatusRequest) (*ContainerStatusResponse, error)
        // UpdateContainerResources updates ContainerConfig of the container.
        UpdateContainerResources(context.Context, *UpdateContainerResourcesRequest) (*UpdateContainerResourcesResponse, error)
        // ReopenContainerLog asks runtime to reopen the stdout/stderr log file
        // for the container. This is often called after the log file has been
        // rotated. If the container is not running, container runtime can choose
        // to either create a new log file and return nil, or return an error.
        // Once it returns error, new container log file MUST NOT be created.
        ReopenContainerLog(context.Context, *ReopenContainerLogRequest) (*ReopenContainerLogResponse, error)
        // ExecSync runs a command in a container synchronously.
        ExecSync(context.Context, *ExecSyncRequest) (*ExecSyncResponse, error)
        // Exec prepares a streaming endpoint to execute a command in the container.
        Exec(context.Context, *ExecRequest) (*ExecResponse, error)
        // Attach prepares a streaming endpoint to attach to a running container.
        Attach(context.Context, *AttachRequest) (*AttachResponse, error)
        // PortForward prepares a streaming endpoint to forward ports from a PodSandbox.
        PortForward(context.Context, *PortForwardRequest) (*PortForwardResponse, error)
        // ContainerStats returns stats of the container. If the container does not
        // exist, the call returns an error.
        ContainerStats(context.Context, *ContainerStatsRequest) (*ContainerStatsResponse, error)
        // ListContainerStats returns stats of all running containers.
        ListContainerStats(context.Context, *ListContainerStatsRequest) (*ListContainerStatsResponse, error)
        // UpdateRuntimeConfig updates the runtime configuration based on the given request.
        UpdateRuntimeConfig(context.Context, *UpdateRuntimeConfigRequest) (*UpdateRuntimeConfigResponse, error)
        // Status returns the status of the runtime.
        Status(context.Context, *StatusRequest) (*StatusResponse, error)
}

既然如此，我们就该看看 Kubelet 和容器运行时之间的连接。

// worker node
$ ss -a -p |grep kubelet
...
u_str  ESTAB      0      0       * 157937                * 157387                users:(("kubelet",pid=5714,fd=33))
...

在 Kubelet（PID=5714）和 Docker 之间有一个新的 Unix Socket 连接：

// worker node
$ ss -a -p |grep 157387
...
u_str  ESTAB      0      0       * 157937                * 157387                users:(("kubelet",pid=5714,fd=33))
u_str  ESTAB      0      0      /var/run/docker.sock 157387                * 157937                users:(("dockerd",pid=1186,fd=14))
...

是 Docker 守护进程（PID 1186）执行了我们的命令：

// worker node.
$ ps -afx
...
 1186 ?        Ssl    0:55 /usr/bin/dockerd -H fd://
17784 ?        Sl     0:00      \_ docker-containerd-shim 53a0a08547b2f95986402d7f3b3e78702516244df049ba6c5aa012e81264aa3c /var/run/docker/libcontainerd/53a0a08547b2f95986402d7f3
17801 pts/2    Ss     0:00          \_ sh
17827 pts/2    S+     0:00              \_ sleep 5000
...

容器运行时的活动

看看 cri-o 的源码，了解一下相关内容。运行逻辑和 Docker 类似。

它提供了一个服务，实现了 RuntimeServiceServer：

// Server implements the RuntimeService and ImageService
type Server struct {
        config          libconfig.Config
        seccompProfile  *seccomp.Seccomp
        stream          StreamService
        netPlugin       ocicni.CNIPlugin
        hostportManager hostport.HostPortManager

        appArmorProfile string
        hostIP          string
        bindAddress     string

        *lib.ContainerServer
        monitorsChan      chan struct{}
        defaultIDMappings *idtools.IDMappings
        systemContext     *types.SystemContext // Never nil

        updateLock sync.RWMutex

        seccompEnabled  bool
        appArmorEnabled bool
}

// Exec prepares a streaming endpoint to execute a command in the container.
func (s *Server) Exec(ctx context.Context, req *pb.ExecRequest) (resp *pb.ExecResponse, err error) {
        const operation = "exec"
        defer func() {
                recordOperation(operation, time.Now())
                recordError(operation, err)
        }()

        resp, err = s.getExec(req)
        if err != nil {
                return nil, fmt.Errorf("unable to prepare exec endpoint: %v", err)
        }

        return resp, nil
}

链条的最后一环，容器运行时在工作节点上执行命令：

// ExecContainer prepares a streaming endpoint to execute a command in the container.
func (r *runtimeOCI) ExecContainer(c *Container, cmd []string, stdin io.Reader, stdout, stderr io.WriteCloser, tty bool, resize <-chan remotecommand.TerminalSize) error {
        processFile, err := prepareProcessExec(c, cmd, tty)
        if err != nil {
                return err
        }
        defer os.RemoveAll(processFile.Name())

        args := []string{rootFlag, r.root, "exec"}
        args = append(args, "--process", processFile.Name(), c.ID())
        execCmd := exec.Command(r.path, args...)
        if v, found := os.LookupEnv("XDG_RUNTIME_DIR"); found {
                execCmd.Env = append(execCmd.Env, fmt.Sprintf("XDG_RUNTIME_DIR=%s", v))
        }
        var cmdErr, copyError error
        if tty {
                cmdErr = ttyCmd(execCmd, stdin, stdout, resize)
        } else {
                if stdin != nil {
                        // Use an os.Pipe here as it returns true *os.File objects.
                        // This way, if you run 'kubectl exec <pod> -i bash' (no tty) and type 'exit',
                        // the call below to execCmd.Run() can unblock because its Stdin is the read half
                        // of the pipe.
                        r, w, err := os.Pipe()
                        if err != nil {
                                return err
                        }
                        go func() { _, copyError = pools.Copy(w, stdin) }()

                        execCmd.Stdin = r
                }
                if stdout != nil {
                        execCmd.Stdout = stdout
                }
                if stderr != nil {
                        execCmd.Stderr = stderr
                }

                cmdErr = execCmd.Run()
        }

        if copyError != nil {
                return copyError
        }
        if exitErr, ok := cmdErr.(*exec.ExitError); ok {
                return &utilexec.ExitErrorWrapper{ExitError: exitErr}
        }
        return cmdErr
}

最后，内核执行了任务：

总结

API Server 会向 Kubelet 发起连接。
在 exec 结束之前，连接持续存在。
- Kubectl 和 API Server 之间
- API Server 和 Kubelet 之间
- Kubelet 和容器运行时之间
Kubectl 或者 API Server 无法在工作节点上运行任何东西。Kubelet 可以通过和容器运行时的互动来完成任务。

Kustomize 中的增删改查

Sat, 17 Aug 2019 23:12:56 +0800

在之前的文章中，我曾经说过，相对于 Helm Chart，Kustomize 具有更平缓的学习曲线，更灵活的派生方式，当然这也不是没有代价的，Kustomize 的分享方式和规范性都弱于 Helm Chart，而且上游对下游也是相当缺乏控制能力的。

本文会从实际出发，列出一系列的场景，看看拿到一个上游应用的标准 YAML 之后，如何使用 Kustomize 对其进行增删改查，形成新的 Kubernetes 资源组，完成对派生应用的定义。

准备工作

首先我们创建实验目录 lab/base，在其中生成一组 YAML 文件，作为后续实验的基础（base），这是一个很简单的应用，只有一个 Deployment：

deploy.yaml：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flaskapp
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: flaskapp
        version: v1
    spec:
      containers:
        - name: flaskapp
          image: dustise/flaskapp
          imagePullPolicy: IfNotPresent
          env:
            - name: version
              value: v1
          ports:
            - containerPort: 80

如果使用 Kubectl 提交，会在当前命名空间中新建一个 Deployment 和一个 Pod，当然我们暂时不会这么做。

接下来是创建一个 Kustomize 的定义，作为后续实验的基础，基础定义很简单，它甚至可能不会由上游应用的开发者编写，而是下游的定制者用它来做一个基础。

kustomization.yaml：

resources:
- deploy.yaml

对它进行渲染，会毫无意外的出现一个和 deploy.yaml 一样的输出内容：

kubectl kustomize base
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flaskapp
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: flaskapp
...

增

创建一个新的工作目录，lab/overlays/c，本节的内容都会使用这个目录来完成。

在继承上游应用的 YAML 时，经常需要向其中加入定制元素，比如加入新的 Ingress、Service、Configmap 等，还有可能新增一些对象内的定义。下面的两个例子分别展示了 Kustomize 完成这类任务的方法。

加入新对象

上面的 Base 中，有了一个孤零零的 Deployment，多数的业务应用还是需要有个 Service 提供服务的，我们就给它加入一个新对象。

在 c 目录中，新建一个 service.yaml：

apiVersion: v1
kind: Service
metadata:
  name: flaskapp
  labels:
    app: flaskapp
spec:
  selector:
    app: flaskapp
    version: v1
  ports:
    - name: http
      port: 80
      targetPort: 80

然后新建一个 kustomization.yaml：

bases:
- ../../base
resources:
- service.yaml

执行命令 kustomize build overlays/c，可以看到，在原有 Deployment 的基础上，新增了一个服务。

新增字段

很多应用都会声明运行时的资源需求，但是我们的 base 中并没有这个字段，Kustomize 可以用补丁的方式加入这个字段。

首先创建一个补丁文件 overlays/c/resource-patch.yaml：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flaskapp
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: flaskapp
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "64Mi"
            cpu: "250m"

上面的补丁文件用最简单的字段赋值标识出了要打补丁的位置，并加入了资源限制。

修改 overlays/c/kustomization.yaml，加入补丁：

bases:
- ../../base
resources:
- service.yaml
patchesStrategicMerge:
- resource-patch.yaml

再次使用 kustomize build overlays/c，或者直接使用 kubectl apply -k overlays/c，都能看到，资源限制已经应用。

创建 Configmap 并加载

在 overlays/c 下面新建一个配置文件 config.ini：

key=value

新增的 configMapGenerator 要求使用 config.ini 生成一个 ConfigMap。

然后再做一个补丁文件 env-patch.yaml，用来加载 Config：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flaskapp
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: flaskapp
        env:
        - name: CONFIG
          valueFrom:
            configMapKeyRef:
              name: config-ini
              key: config.ini

修改 kustomization.yaml，加入我们的 Configmap 和补丁，结果为如下内容：

bases:
- ../../base
resources:
- service.yaml
configMapGenerator:
- name: config-ini
  files:
    - config.ini
patchesStrategicMerge:
- resource-patch.yaml
- env-patch.yaml
generatorOptions:
  disableNameSuffixHash: true

kubectl apply -k overlays/c 之后，会看到 Pod 中加入了对 Configmap 的引用，进入 Pod 也能看到新增的环境变量，例如：

$ kubectl exec -it flaskapp-5b886b8dfc-qq68w env | grep CONFIG
CONFIG=key=value

删

创建一个新的工作目录，lab/overlays/d，本节的内容都会使用这个目录来完成。

使用 patchesStrategicMerge 的特定语法，可以删除指定内容。

删除一个对象

在 c 案例中新建的 Service 对象，我并不想要，如何通过 Kustomize 删掉？同样也使用打补丁的方式来解决。首先创建一个继承自 overlays/c 的 Kustomization，在 overlays/d 中创建 kustomization.yaml：

bases:
- ../c
patchesStrategicMerge:
- remove-svc.yaml

以及 remove-svc.yaml：

kind: Service
apiVersion: v1
metadata:
  name: flaskapp
$patch: delete

运行 kustomize build overlays/d，可以看到，输出内容中的 Service 不见了。

删除一个字段

接下来我们用类似的方法，删除前面设置的环境变量：

新建一个 remove-field.yaml：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flaskapp
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: flaskapp
        version: v1
    spec:
      containers:
        - name: flaskapp
          image: dustise/flaskapp
          env:
          - name: CONFIG
            $patch: delete

再把补丁加入 kustomization.yaml：

bases:
- ../c
patchesStrategicMerge:
- remove-svc.yamlƒ
- remove-field.yaml

再次 kustomize build overlays/d，可以看到新的环境变量已经被删除。

改

创建一个新的工作目录，lab/overlays/u，本节的内容都会使用这个目录来完成。

除了 patchesStrategicMerge 之外，kustomize 还提供了一些方便快捷的方式能够对特定内容进行修改。

修改名字

可以用 namePrefix 和 nameSuffix 修改对象的名字，例如我们要给所有名字加上 overlay-u：

kustomization.yaml：

bases:
- ../c
namePrefix: overlay-u

接下来可以看看结果：

$ kubectl apply -k overlays/u --dry-run -o yaml | grep -E "^\s+name:"
    name: overlay-u-config-ini
    name: overlay-u-flaskapp
    name: overlay-u-flaskapp
                name: overlay-u-config-ini
          name: flaskapp

输出内容中，前三个分别是 ConfigMap、Service 以及 Deployment，第四行中对 Configmap 的引用也修改成了新的名字。

除了修改名字之外，还有以下几个暴力的修改功能：

命名空间：namespaces
注解：commonAnnotations
标签：commonLabels

说这几个东西比较野蛮的原因是：他们的应用范围是整个 Kustomization，例如下面的定制：

bases:
- ../c
namePrefix: overlay-u
commonLabels:
    auto: label

生成之后会发现，从 Service、Deployment、Configmap 一直到 Pod，都会打上新标签。

修改镜像

修改镜像也是个常见任务，相对上面的几个暴力修改，镜像的修改相对精确一点——从一种镜像修改为另一种，例如我们把 flaskapp 的镜像更换为 nginx:alpine：

kustomization.yaml：

bases:
- ../c
namePrefix: overlay-u
commonLabels:
    auto: label
images:
- name: dustise/flaskapp
  newName: nginx
  newTag: alpine

修改副本数量

修改副本数量，指定资源名称以及副本数量即可：

例如如下的 kustomization.yaml：

bases:
- ../c
replicas:
- name: flaskapp
  count: 2

使用 kustomize build overlays/u，会看到 Deployment 的该字段已经改为 2。

查

创建一个新的工作目录，lab/overlays/r，本节的内容都会使用这个目录来完成。

前面提到，namePrefix 修改了 ConfigMap 的名称之后，加载这个 CM 的 Deployment 也会修改引用的名称，然而如果在其它位置，例如命令行参数或者环境变量中引用的服务名称之类，就无法完成修改了。假设我们给 Deployment 中加入一个新的环境变量，叫 deploy，用如下的 kustomization.yaml 实现：

bases:
- ../../base
namePrefix: overlay-r-
patchesStrategicMerge:
- env-patch.yaml

其中引用的 env-patch.yaml：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flaskapp
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: flaskapp
        env:
        - name: deploy
          value: flaskapp

kustomize build overlays/r 渲染出来之后，很明显的 value 已经无法对应：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: overlay-r-flaskapp
...
      - env:
        - name: svc
          value: flaskapp
        - name: version

在 kustomization.yaml 中加入 vars，用一系列条件选择一个对象来进行引用，为变量赋值：

...
vars:
- name: DEPLOY_NAME
  objref:
    kind: Deployment
    name: flaskapp
    apiVersion: extensions/v1beta1

把 env-patch.yaml 中的环境变量定义修改为引用新变量：

...
        - name: deploy
          value: $(DEPLOY_NAME)

再次 kustomize build overlays/r，会看到符合预期的输出内容：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: overlay-r-flaskapp
...
        - name: deploy
          value: overlay-r-flaskapp

命令行

除了上面说的这些声明式的用法之外，kustomize 还提供了更为即兴的 edit 命令，可以进行现场修改，进一步的提高了灵活（混乱）程度，有兴趣的读者可以自行摸索。

Helm 和 Kustomize：不只是含谷量的区别

Thu, 08 Aug 2019 00:57:37 +0800

Kustomize 问世的时候，我是比较鄙视的——非要造个谷歌的轮子么？不过最近抽出时间熟悉了一下 Kustomize，发现我还是带了有色眼镜。二者功能虽然有所重叠，但是工作思路的差别还是很大的，下面就简单做一点比较，权当引玉之砖。

Helm

Helm 是 Kubernetes 中的第一个对应用程序进行管理的支撑工具，经常会拿来同 Yum、apt 等工具进行类比。Helm 由几个不同的组件构成：

CLI：客户端工具，有几大功能
- 从 Chart 服务器获取列表、搜索 Chart 项目
- 安装 Chart
- 构建 Chart
- 充当 Chart 服务器
- 和 Tiller 协同管理应用生命周期
- 渲染 Chart 为 Kubernetes 生成 YAML
Tiller：需要用特定授权和 API Server 进行通信，Kubernetes 集群内外部署都可以。
- 它是 Helm 的内鬼，负责接收来自 Cli 的指令，完成对集群内应用生命周期的控制。
- 3.0 中将取消 Tiller。
Repository：
- 是存储 Helm Chart 的仓库，可以被 Cli 工具缓存、检索，CLI 也可以获取 Chart 进行后续操作。
- 和 Tiller 一样，Repository 也不是必要组件，CLI 完全可以仅在本地工作。

Helm Chart

Helm 使用 Chart 对应用程序进行描述，它使用 Go Template 对应用部署所需的 YAML 进行抽象，形成应用部署模板，在需要进行部署时，可以编写 yaml 为模板中的变量进行赋值，也可以在 Helm CLI 的命令行中使用 --set name=value 的方式来对简单变量进行赋值，完成赋值之后，可以选择使用 helm template 指令将 Chart + Value 的组合渲染成为 YAML 供 kubectl 使用，也可以使用 helm install 直接通过 Tiller 进行安装。

Helm 的特色

强大的生命周期管理：有 Tiller 的帮助，可以实现对应用程序实例（Release）的查询、安装、卸载、升级、回滚等复杂操作。
严格的基础版本管控：Chart 是一种模板，Chart 的用户仅能通过对 values 的控制来定制应用的部署行为，模板中没有提供变量的位置，是无法在下游直接进行变更的。
方便的命令行：对于简单变量，可以在部署的同时直接指定内容，方便部署。
插件和工具：Helm 拥趸众多，提供了不少用于 CICD 或者其它方面辅助功能的插件和工具。

Kustomize

Kustomize 是一个新晋选手，只有一个 CLI 工具，在 Kubernetes 1.14 之后，甚至这唯一的工具也成为 kubectl 的一部分，可以说是很轻量级了。

Base + Overlay

在 Kustomize 的文档中明确说明：

kustomize is a command line tool supporting template-free, structured customization of declarative configuration targetted to k8s-style objects.

它放弃了对模板的要求，改用 Base + Overlay 的方式对应用的原始 YAML 进行派生。Overlay，顾名思义，就是覆盖。Kustomize 的 Overlay 可以在 Base 的基础上，通过对 resource、generator、transformer 等的定义，形成新的应用定义，不论 Base 还是 Overlay，都可以通过 kustomize build 生成有效的 YAML。

Kustomize 的特色

功能简单清晰，kubectl 直接支持。
不考虑派生，仅作为应用的 YAML 组织方式也很有帮助。
也有自己的插件系统。例如可以用简单的 YAML 定义，使用文件生成 Configmap/Secret。

比较

Kustomize 自称因为去掉了模板语法，更易使用，对此我保留看法，如果仅就入门使用来看，二者差异并不大。

Tiller 和 Repository 都并非必须，因此在部署上，Kustomize 的优势也不是很大。

我认为他们的区别主要在工作流程上：

Helm 的基础流程比较瀑布：定义 Chart->填充->运行，在 Chart 中没有定义的内容是无法更改的；
Kustomize 的用法比较迭代：Base 和 Overlay 都是可以独立运作的，增加新对象，或者对编写 Base 时未预料的内容进行变更，都不在话下。

例如我们定义了一个很基础的应用，由 Deployment + Service 组成，如果后续部署中需要完成两个变更：

新建 Ingress 对象
修改镜像地址/名称/TAG

在 Helm 中需要：

在 Chart 中加入对 Ingress 的定义
用变量控制 Ingress 是否进行渲染
Ingress 模板应该包含特定的主机名、注解等变量
把镜像也定义成变量
在 Values.yaml 中对这些变量进行赋值。

而在 Kustomize 中：

无需对 Base 进行修改
直接在新的 Overlay 中写入 Ingress Resource
使用内置的 image transformer 替换原有镜像

结论

要公开发布一个较为复杂的应用，例如 Istio，编写良好的 Chart 能给用户很大帮助，用户在缺失一点发挥空间的情况下，通过对 values.yaml 的阅读，就能对这种复杂的部署产生一个较为深入的认识。

如果是常见的业务应用，因为不同部署之间的差异不大，但是未必可以提前做好变化限制，用 Kustomize 可能会是一个更好的选择。

Kubernetes Deployment 终极指南

Sun, 28 Jul 2019 23:27:01 +0800

原文：Kubernetes Deployments: The Ultimate Guide

作者：Jérôme Petazzoni

要把容器化的应用部署起来？在 Kubernetes 中部署容器化应用，总要涉及到 Deployment，这里有这个对象的所有内容。

我们最早学会的 Kubernetes 命令之一就是 kubectl run。具备 Docker 经验的用户，不免会用 docker run 命令和这个命令进行对比，结论可能是：运行容器就是这么简单。

我们来看看，在运行一个基本的 kubectl run 命令的时候，都发生了些什么：

$ kubectl run web --image=nginx
deployment.apps/web created

集群中创建了什么？

$ kubectl get all
NAME                       READY     STATUS    RESTARTS   AGE
pod/web-65899c769f-dhtdx   1/1       Running   0          11s

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   46s

NAME                  DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/web   1         1         1            1           11s

NAME                             DESIRED   CURRENT   READY     AGE
replicaset.apps/web-65899c769f   1         1         1         11s

我们并没有看到容器，而是一组未知对象：

Deployment：web
ReplicaSet：web-65899c769f
Pod：web-65899c769f-dhtdx

此处的 kubernetes 服务可以忽略，它在我们运行命令之前就已经存在了。

我只想要个容器！为什么看到了三个不同的对象？

简单说来，这些 Kubernetes 对象能在不停服务的情况下，为应用提供渐进式部署、回滚以及伸缩的支持。

初次见面难免会好奇：究竟是怎么回事？在了解这些问题之后，就会理解每个对象的角色和存在价值了。

持续集成提升了对代码的信心。要把这种信心扩展到发布流程之中，部署操作就需要更多保障。

容器和 Pod

在 Kubernetes 中，一个 Deployment 的最小单元不是容器，而是 Pod。Pod 是一组容器（当然这一组也可以只有一个），它们运行在同一台服务器中，并共享一些资源。

例如 Pod 中的容器能够通过 localhost 互相通信。在网络视角中，这些容器中的所有进程都是本地的。

但是我们永远无法创建独立的容器：最相近的操作也只能是创建一个仅包含单一容器的一个 Pod。

我们想让 Kubernetes 创建 NGINX，完整的台词是：“我要一个 Pod，其中只包含一个容器，这个容器运行的是 nginx 镜像”。

# pod-nginx.yml
# Create it with:
#    kubectl apply -f pod-nginx.yml
apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
    - image: nginx
      name: nginx
      ports:
        - containerPort: 80
          name: http

这就只有一个 Pod，那 ReplicaSet 和 Deployment 是怎么回事？

指令和声明

Kubernetes 是一个声明式系统（和指令式系统相对），这就意味着我们无法给它发出命令。我们不能说：“运行这个容器”。我们能做的只能是——描述我们需要的东西，然后等 Kubernetes 根据现有内容，同步为预期内容。

打个比方，我们可以说：“我要一个 40 英尺高的有黄色门的蓝色容器”，Kubernetes 会为我们查找这种容器，如果找不到，就会创建一个；如果已经有了，但它是绿色红门的，Kubernetes 就会帮我们上色；如果已经有了完全符合要求的容器，因为现有内容和预期内容一致，所以 Kubernetes 什么都不会做。

回到软件容器的话题，我们可以说：“我想要一个名字叫 web 的 Pod，其中应该有单独的容器，运行的是 nginx 镜像”。

如果这个 Pod 不存在，Kubernetes 会创建出来。如果符合我们要求的 Pod 已经存在，Kubernetes 无需进行任何动作。

基于这种思路，怎样对 web 应用进行伸缩，来满足多容器或 Pod 的运行需要呢？

ReplicaSet 简化了 Pod 的伸缩过程

如果我们只有一个 Pod，我们想要更多的同样的 Pod，我们可能会给 Kubernetes 提出这样的要求：“我们需要一个叫做 web2 的 Pod，具体要求是：…”，然后重复之前的 Pod 规范。想要多少 Pod，就重复执行多少次。

这明显很不方便，我们要自己跟踪所有的 Pod，确保它们都同步了正确的状态，并符合特定的规范。

Kubernetes 提供了高级一些的抽象来简化这个过程：ReplicaSet。ReplicaSet 的对象结构和 Pod 很相似，只不过它还有个副本数量的字段，用于描述我们所需要的符合规范的 Pod 数量。

有了 ReplicaSet，我们就可以告诉 Kubernetes：“我需要一个叫做 web 的 ReplicaSet，其中包含 3 个 Pod，这些 Pod 符合如下规范：……”，Kubernetes 会根据这个指令来确认，是不是刚好有三个符合规范的 Pod。如果我们从头开始，就会创建这 3 个 Pod。如果已经有了 3 个 Pod，什么事都不会发生——我们的要求和现状一致。

# pod-replicas.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: web-replicas
  labels:
    app: web
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        app: web
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

ReplicaSet 的伸缩和高可用

我们可以修改现存 ReplicaSet 的副本数量，以此来完成伸缩。Kubernetes 会根据伸缩指令来创建或删除 Pod，让 Pod 数量符合要求。

高可用方面，因为 Kubernetes 会持续的对集群进行监控，确保无论什么情况下都保有指定数量的运行实例。

如果节点当机，恰好其中有一个 web 所属的 Pod，Kubernetes 会另外创建一个 Pod 来替换它。如果节点没有当机，不过是有一段时间无法联系或者没有响应，那么它再次恢复可用之后，就会多出一个 Pod，Kubernetes 会中止一个 Pod 来保证数量符合要求。

修改 Pod 定义会发生什么

修改 Pod 定义并不罕见。比如我们经常会希望把容器镜像替换为新版本。

记住：ReplicaSet 的使命是，“确保有 N 个符合规范的 Pod。”如果我们修改了定义，会发生什么呢——突然就没有符合新规范的 Pod 了。

写到这里，我们已经知道了声明式系统的工作方式：Kubernetes 会立刻创建 N 个符合新规范的 Pod。旧的 Pod 会一致存在，直到我们手工清理。

如果能用 CI/CD 对这些过期 Pod 做一个自动清理可能不错；如果新 Pod 的创建能用更优雅的方式也会更好。

Deployment 驱动的 ReplicaSet

前面说的需要就是 Deployment 的职责。粗看上去，Deployment 的规范和 ReplicaSet 很像：其中包含了 Pod 规范，以及副本数量。（还有一些后面会讨论的参数）

# deployment-nginx.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Deployment 并不会直接负责 Pod 的创建和删除。它会把这些工作委托给一个或多个 ReplicaSet。

在我们创建 Deployment 的时候，它会用自己的 Pod 规范创建一个 ReplicaSet。

当更新一个 Deployment 并修改副本数量时，它会把更新内容传递给下游的 ReplicaSet。

当配置发生了变化

需要更新 Pod 规范的时候，事情就有意思了。例如我们可能需要使用新版本的镜像（因为我们发布了新的版本），或者修改应用的参数（通过命令行参数、环境变量或者配置文件）。

在我们更新 Pod 规范时，Deployment 会用新的 Pod 规范创建新的 ReplicaSet。新的 ReplicaSet 的初始实例数量是 0。接下来 ReplicaSet 的实例数量会逐步提升，同时逐渐减少另一个 ReplicaSet 的尺寸。

可以想象一下，面前有个混音台，我们要让新的 ReplicaSet 淡入，同时把旧的那个淡出。

整个过程之中，请求被发送给新旧两个 ReplicaSet，用户不会感觉服务中断。

全景大致如此，其中还有很多小细节，让整个过程更加健壮。

损坏的 `Deployment` 以及就绪检测

如果我们推出了一个故障版本，因为 Kubernetes 会持续把旧 Pod 替换成新的（故障）版本，它可能会让整个应用坏掉（逐个 Pod）。

除非我们用上了就绪检测。

就绪检测是在容器规范中加入的一个测试过程。他是一个二进制测试，结果只有两个“能行”或者“不行”，这个测试会以指定的间隔被执行（缺省情况下是每 10 秒）。

Kubernetes 支持三种方式的就绪检测：

在容器内运行一个命令；
向容器发出一个 HTTP(S) 请求；
向容器发起一个 TCP 连接。

Kubernetes 会通过测试结果来了解容器及其所处 Pod 是否准备就绪可以接受流量。在我们推出新版本时，Kubernetes 会等到新 Pod 测试得到“就绪”结果之后，才会进入下一步。

如果一个 Pod 因为就绪检测持续失败，永远无法进入就绪状态，Kubernetes 也不会进入下一步。部署过程会停止，应用会继续使用老版本运行，直到我们解决了问题。

如果没有就绪检测，那么这个容器成功启动后就会被当成是就绪状态。所以最好能使用就绪检测来保障业务。

使用 Rollback 来从故障版本中快速恢复

在滚动更新过程中或之后的任何时间，我们都可以告诉 Kubernetes：“我改主意了，请回到这个 Deployment 的前一个版本。”，这个操作会切换新旧 ReplicaSet 的地位。在这个点开始，会提高旧版 ReplicaSet 的实例数量到指定数值，同时降低新版的的实例数量。

一般来说，并不限于新旧两个 ReplicaSet。归根结底，有一个 ReplicaSet 被视为“最新”版本，我们可以将这个版本作为目标 ReplicaSet，所谓目标，就是我们希望运行的，也是 Kubernetes 会逐步拉起的一个版本。同时也可以有任意多个其它版本的 ReplicaSet，对应旧版本。

例如我们在运行 10 个副本的版本 1 应用，然后开始推出版本 2。在某个时间点，我们可能有了 7 个版本 1、3 个版本 2 的 Pod 正在运行。如果我们不想等版本 2 完全推出，决定推出版本 3。在版本 3 部署的时候，我们又想回到版本 1。整个过程，Kubernetes 都会根据需要对各个版本的 ReplicaSet 中的副本数量进行调整。

MaxSurge 和 MaxUnavailable

Kubernetes 不一定是一次更新一个 Pod 的。之前我们提到 Deployment 还有一些额外的参数，这些参数中包括了 MaxSurge 和 MaxUnavailable，这两个参数决定了更新过程的速度。

试想一下，推出新版本过程中的两个策略：

我们可能对应用的可用性非常谨慎，因此决定在关闭旧版本 Pod 之前，首先要启动新 Pod。只有新 Pod 启动、运行并就绪之后，才终结旧 Pod。
上这个假设中有个隐含条件就是我们的集群中是有剩余资源的。然而如果我们的集群已经满载，无法负担多余 Pod 的消耗，那么我们自然是希望首先关掉旧的，然后才启动新的。

MaxSurge 指出了我们在滚动更新时，可以有多少个额外的 Pod；而 MaxUnavailable 则代表在滚动更新时，我们可以忍受多少个 Pod 无法提供服务。这两个参数可以是 Pod 数量，也可以是 Deployment 的实例数量百分比；两个参数都可以设置为 0（但是不能同时为 0）。

接下来看看这两个参数的常见取值，以及背后的意图。

MaxUnavailable 设置为 0 意味着：“在新 Pod 启动并就绪之前，不要关闭任何旧 Pod”。

MaxSurge 设置为 100% 的意思是：“立即启动所有新 Pod”，也就是说我们有足够的资源，我们希望尽快完成更新。

这两个参数的却升值都是 25%，如果我们更新一个 100 Pod 的 Deployment，会立刻创建 25 个新 Old，同时会关闭 25 个旧 Pod。每次有 Pod 启动就绪，就可以关闭旧 Pod。每次有旧 Pod 完成关闭过程（释放资源），就可以创建另一个新 Pod 了。

演示时间

可以很方便的观察这些参数的作用。我们不需要编写自己的 YAML、定义就绪检测等东西。

我们需要做的事情只是，使用一个无效的镜像，例如一个不存在的镜像。这个容器永远无法启动，Kubernetes 也永远无法把它标记为就绪。

如果你有个 Kubernewtes 集群（Minikube 或者 Docker 桌面版的单结点集群都可以），可以在不同终端运行下面的命令，来看看发生了什么：

kubectl get pods -w
kubectl get replicasets -w
kubectl get deployments -w
kubectl get events -w

然后用下面的命令来创建、伸缩以及更新一个 Deployment：

kubectl run deployment web --image=nginx
kubectl scale deployment web --replicas=10
kubectl set image deployment web nginx=that-image-does-not-exist

会看到部署过程停顿了，但是还有 80% 的应用容量是可用的。

如果我们运行 kubectl rollout undo deployment web，Kubernetes 就会回滚到使用 nginx 镜像的旧版本。

理解选择器和标签

前面我们说过，ReplicaSet 的任务是确保有 N 个符合规范的 Pod。这其实并不完全。实际上 ReplicaSet 并不关心 Pod 的规范，它关心的只是标签。

换句话说，不论 Pod 运行的是 nginx 还是 redis 还是什么别的什么东西；所有的关注点都是，它们要有正确的标签。前面的例子中，标签大概是 run=web 以及 pod-template-hash=xxxyyyzzz 的形式。

ReplicaSet 包含了一个 selector 成员，内容是一个逻辑表达式，功能和 SQL 中的 SELECT 类似，用来选择符合要求的 Pod。ReplicaSet 保证 Pod 的数量正确，如有必要，就会新建或者删除 Pod，但是不会修改已经存在的 Pod。

这样会有个设想：可能可以手工创建带有这些标签的 Pod ，但是却用的不同镜像（或者不同配置），就能骗过 ReplicaSet 了。

粗看上去，这可能是个很大的潜在问题。但实际上，我们很难恰巧选择了正确的标签，这是因为标签中包含了根据 Pod 规范运算得出的哈希值。

Service 负载均衡

选择器还用在 Service 上，这个对象负责 Kubernetes 的内外部的负载均衡。我们可以给 web 创建一个 Service：

kubectl expose deployment web --port=80

这个服务会有它自己的内部 IP 地址（ClusterIP），连接到这个地址的 80 端口会被负载均衡到这个 Deployment 所有 Pod 之中。

事实上这个连接的负载均衡范围是所有符合 Service 标签选择器的 Pod 中，例如这里对应的是 run=web。

在我们编辑 Deployment 并触发滚动时，就会创建新的 ReplicaSet。这个 ReplicaSet 会创建 Pod，新 Pod 标签会包含 run=web，所以这些 Pod 就会自动的接到流量。

这表明在滚动更新时，Deployment 不需要因为 Pod 的的启动停止，而去重新配置或者通知负载均衡器。负载均衡器通过 selector 自动的完成任务。

如果你好奇就绪检测的内幕：Pod 只有在所有成员容器都通过就绪检测之后才会作为有效的 Endpoint 被加入服务。换句话说，Pod 只有准备就绪之后才会开始接收流量。

Kubernetes 部署的高级策略

有些事后我们希望在推出新版本时候还有更多的控制。

两个知名流行技术是蓝绿部署以及金丝雀部署。

Kubernetes 中的蓝绿部署

在蓝绿部署中，我们希望立即把所有流量从旧版本切换到新版本，而不是象之前说的渐进切换。提出这种要求可能有几个原因：

我们不想混合新旧请求，希望能够尽可能清晰的从旧版本切换到新版本；
我们正在更新多个组件（例如 Web 前端和 API 后端），不想新版本前端和旧版后端发生联系；
如果出现问题，我们希望有能力尽快回滚，无需等旧版本容器重启。

在 Kubernetes 中，可以用创建多个 Deployment 的方式来完成蓝绿部署，通过对 Service 的 Selector 字段的控制来进行切换。

下面的命令会创建两个 Deployment：blue 和 green，分别使用 nginx 和 httpd 镜像：

kubectl create deployment blue --image=nginx
kubectl create deployment green --image=httpd

接下来我们创建一个 Service，起初不会发送任何流量：

kubectl create service clusterip web --tcp=80

然后我们更新 web 服务的选择器：kubectl edit service web。这个命令会从 Kunernetes API 中抓取服务对象的定义，在文本编辑器中打开。在其中查找：

selector:
  app: web

把其中的 web 替换成 blue 或者 green 或者别的什么。保存并退出。kubectl 会把更新的定义推送给 Kubernetes API，然后 web 服务现在就会向特定的 Deployment 发送流量了。

可以用 kubectl get svc web 命令获取服务的地址，并使用 curl 进行访问。

我们用文本编辑器作出的变更，也可以完全使用命令行来完成，例如 kubectl patch 命令：

kubectl patch service web -p '{"spec": {"selector": {"app": "green"}}}'

蓝绿部署的好处是，流量切换几乎是立刻完成的，推出和回滚都可以很方便的通过更新 Serevice 定义来完成。

用 Kubernetes 完成金丝雀部署

有时我们不想让测试版本影响所有用户，即使是短时间也不行。所以我们可以部分推出新版本。例如我们部署新旧两组实例，1% 的流量发送给新版本。

接下来我们在新旧版本的监控数据中进行观察。如果情况允许，就可以向前推进；如果延迟、错误率或者其它什么东西看起来有问题，就回滚到旧版本。

由于 Kubernetes 的标签和选择器的机制，可以很简单的实现这种策略。

前面的例子中，我们修改了服务的选择器，接下来我们修改一下 Pod 标签。

例如设置服务的选择器，让它选择带有 status=enabled 的 Pod，然后给特定的 Pod 打上标签：

kubectl label pod fronted-aabbccdd-xyz status=enabled

也可以一次打上多个标签：

kubectl label pods -l app=blue,version=v1.5 status=enabled

删除标签同样简单：

kubectl label pods -l app=blue,version=v1.4 status-

结论

我们看到了一些用于安全部署的技术，其中的一些能够很方便的降低因部署造成的停机时间，这让我们可以在不担心影响用户的情况下提高部署频度。

有些技术给我们系上安全带，阻止问题版本影响服务。还有些别的服务让我们感觉安心。有点像主机游戏中的保存按钮——在尝试困难操作之前，我们知道如果出了问题，我们还可以回到从前。

Kubernetes 让开发和运维团队能够使用这些技术来提高部署的安全性。如果部署的危险系数降低，那么就可以更频繁地、渐进地进行部署，并可以更方便的观察变更的后果。

这一切都会让我们的新特性和修复特性能够更快面世，让我们的应用有更好的可用性。这也是实现容器化和持续交付的重要基础。

介绍一个小工具：Kubeseal

Wed, 24 Jul 2019 21:25:21 +0800

今天更新 Homebrew 的时候，眼角余光撇到一个 kube 开头的 Formula：kubeseal，名字还挺酷的，brew home 看了一下项目主页，还是 bitnami 的作品，就多看了下，发现是一个不明觉厉的工具，本着“来都来了”的乐观精神，写了这一篇不知所云的东西（还发现了个 Issue）。

（可能也许大概差不多）有一种情况，我们需要用 YAML 的形式生成一个 Secret，但是我们希望 YAML 自身的内容是加密的，以保证传输过程中，Secret 自身的内容不会被截获，但是同时这个 YAML 还能用于生成我们需要的 Secret。

Kubeseal 就可以解决这个问题，它在安装时，生成一个 TLS Secret，可以用来对 Secret 进行加密，用 CRD 的方式来进行 Secret 保存，把加密的 CRD YAML 提交到集群，Kubeseal 的服务端控制器会根据 CRD 内容进行解密，生成真正的 Secret。

安装

目前 Kubeseal 版本为 v0.8，安装很方便：

# 服务端
$ kubectl apply -f kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.8.0/controller.yaml
# 客户端（Homebrew）
$ brew install kubeseal
...

安装结束后，在 kube-system 命名空间中，生成了 Kubeseal 的控制器，以及用于加解密的 Secret：

$ kubectl get secret,deploy -n kube-system | grep seal
secret/sealed-secrets-controller-token-v4gbx   kubernetes.io/service-account-token   3      6h26m
secret/sealed-secrets-keyb2tvx                 kubernetes.io/tls                     2      6h26m
secret/sealed-secrets-keyhjmbs                 kubernetes.io/tls                     2      21m
deployment.extensions/sealed-secrets-controller   1/1     1            1           6h26m
$ kubectl api-resources| grep seal
sealedsecrets                                    bitnami.com                    true         SealedSecret

创建一个“加密”的 Secret

# 生成 Secret 的 YAML
$ kubectl create secret generic top-secret \
> --dry-run --from-literal=cloud=grass -o json  > mario.json
# 加密
$ cat mario.json | kubeseal > mario-secret.json

查看新生成的 mario-secret.json：

{
  "kind": "SealedSecret",
  "apiVersion": "bitnami.com/v1alpha1",
  "metadata": {
    "name": "top-secret",
    "namespace": "default",
    "creationTimestamp": null
  },
  "spec": {
    "template": {
      "metadata": {
        "name": "top-secret",
        "namespace": "default",
        "creationTimestamp": null
      }
    },
    "encryptedData": {
      "cloud": "AgA89tN49OyoDn/19+QF4Qi7w5aq5v71Xvkzu9cA6mzF/QoDInq3xWnPHl6tt93yurZC0WY+XhlLYVHss3nfrkNtdR8+GSQioTiCRiy1oXnWW3ku37eJGbe7sbd3qIm/uoR/Q3Bvg138zhYfApdeI2T1ePfjDGOsqRRhwhYY5RHAJUsbCC1H0+EO/j/Cg/DmAheFbJHgHtVnHz0eEC6JOrFtLr5YpKXEgEnDIyULoj+TtGL5VXpDzDXwf5OZNvKLgOHl80WwmJWDeyjbbE0RGoPW7rcCyOwlMe/ywRaKgJqpgEm0n/v+3Wb87kd5du8cRsFWKc1ObK4UL0Gq4FMDNXI3m1rBFkeq7AEFiyKSkqlMnPQSOslMcq10hfEmUeOqiJE/GejUlvnhyix9zit83LNlzYxgWMRav+b5CI3PbxpFxAN6r+p+wfKmAMLMh7sfGsYbj5i1vvFbztCrFlGy5UzDBV4tz58mAjDUduyHAzSHkSXHTtMo5YFMk/awonpuUIbQVtGdfyLLqQlyvkcOIdCPVFiMSbRkr0ySPFXDilQp61VtY1002bu5kM6y30fKMSBhjY3ZCes6cz8RpytVszCF8fWDcJSDfI6eGBbgKkRNtm4CPRn6QZA5etgPJxry0PyCZCAmnhfcDodeZgy+bPbR4+G1YoxGq3UaTUhsf6R/nT/rvccphnIr/VrSd+/P9XgY4kZPnw=="
    }
  },
  "status": {

  }
}

把这个文件提交到集群，并查看生成的 Secret：

# 看看是否生成了 secret
$ kubectl get secrets
NAME                  TYPE                                  DATA   AGE
...
top-secret            Opaque                                1      6s
# 查看 top-secret 内容
$ kubectl view-secret top-secret cloud
grass

备份、恢复和轮转

前面提到，Kubeseal 安装过程中除了生成 Deployment 之外，还生成了一个 Secret，仔细观察会看到这个 Secret 带有一个标签：sealedsecrets.bitnami.com/sealed-secrets-key=active，代表这个 Secret 是正用于加密的。只要把这个 Secret 进行备份，或者复制到其它集群上，就可以用同样的密钥进行加密了。如果把这个标签值修改为 compromised，就代表这一密钥已经过期。

对 Secret 进行上述的修改之后，可以删除控制器 Pod，以便生成并启用新的密钥，当然，过去生成的加密内容也不再有效，需要重新进行加密。

结论

看都看了，万一有人有用呢。。。。

使用 Kyverno 定义 Kubernetes 策略

Fri, 19 Jul 2019 09:56:01 +0800

Kubernetes 的日常使用过程中，在对象提交给集群之前，我们会有很多机会，很多方法对资源的 Yaml 定义进行检查和处理。很多读者应该也会知道，资源提交之后，还有机会使用 Admission Controller 对资源动动手脚，这其中其实有很多可以提炼出来的标准动作，可以用统一的控制器来进行处理，Kyverno 就是这样一个工具。有了 Kyverno 的帮助，YAML 程序员可以根据条件对资源进行筛选，符合条件的资源可以：

验证资源：对资源定义进行检查，不符合条件的资源拒绝创建，从而保证集群资源的合规性。
修改资源：在资源定义中进行注入，强制资源部分行为的一致性。
生成资源：在资源创建时，同时创建相关的资源。

安装

安装过程是很简单的，安装清单文件位于 https://github.com/nirmata/kyverno/raw/master/definitions/install.yaml，使用 kubectl 直接部署即可：

$ kubectl create -f https://github.com/nirmata/kyverno/raw/master/definitions/install.yaml
customresourcedefinition.apiextensions.k8s.io/policies.kyverno.io created
namespace/kyverno created
service/kyverno-svc created
serviceaccount/kyverno-service-account created
clusterrolebinding.rbac.authorization.k8s.io/kyverno-admin created
deployment.extensions/kyverno created

有一点需要注意的是资源的类型范围，可以在主进程的命令行参数中设定不需要处理的资源类型，缺省设置为：

  containers:
    - name: kyverno
      image: nirmata/kyverno:latest
      args: ["--filterKind","Node,Event,APIService,Policy,TokenReview,SubjectAccessReview"]
      ports:

策略定义

安装完成后，就可以编写策略了，策略的规则不算复杂，具体格式可以从 install.yaml 中的 CRD 定义里面推断出来。

apiVersion : kyverno.io/v1alpha1
kind: Policy
metadata:
  name: sample-policy
spec:
  rules: # 规则数组，spec 的唯一下级
  - name: check-rule-1
    resource: # 定义选择条件，限制生效范围
      kinds: # 生效对象类型数组，必要字段
      - Deployment
      - StatefulSet
      namespace: default  # 命名空间
      name: "*" # 资源名称
      selector: # 用更加复杂一点的方式来定义选择方式
        matchLabels: # 精确匹配标签
          app: some-app
        matchExpressions: # 表达式匹配标签
          key: "operator"
          operator: In
          values:
          - v2
          - v3
    validate:
      ...
    mutate:
      ...
    generate:
      ...

resource 部分是固定的，而 validate mutate generate 三个动作则各有各的结构。

下面用几个例子来演示一下他的功能。

验证资源（validate）

定义一个限制特定命名空间下镜像地址的策略如下：

apiVersion : kyverno.io/v1alpha1
kind: Policy
metadata:
  name: check-registries
spec:
  rules:
  - name: check-registries
    resource:
      kinds:
      - Deployment
      namespace: default
    validate:
      message: "Registry is not allowed"
      pattern:
        spec:
          template:
            spec:
              containers:
              - name: "*"
                image: "docker.io/citizenstig/*"

这个策略文件中，pattern 部分和我们要处理的 deployment 文档结构一致，其中支持通配符，可以用它来对目标进行校验，这里我们要求 default 命名空间中的 Deplyment 对象，containers 下的 image 字段必须符合 docker.io/citizenstig/* 的通配符要求。

例如下面的的 Deployment 就无法创建：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: httpbin
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      containers:
        - name: httpbin
          image: citizenstig/httpbin
          imagePullPolicy: IfNotPresent

$ kubectl apply -f httpbin.yaml
Error from server: error when creating "httpbin.yaml": admission webhook "nirmata.kyverno.validating-webhook" denied the request:
Policy check-registries failed with following rules;rulename: check-registries;Rule check-registries: Validation has failed, err Failed to validate value citizenstig/httpbin with pattern docker.io/citizenstig/*. Path: /spec/template/spec/containers/0/image/.

但是如果我们换个命名空间就没问题了：

$ kubectl create ns free
kunamespace/free created
$ kubectl apply -f httpbin.yaml -n free
deployment.extensions/httpbin created

又或者我们不用 Deployment，直接创建 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: static-httpbin
spec:
  containers:
    - name: httpbin
      image: citizenstig/httpbin

果然就能够创建成功了：

$ kubectl apply -f pod.yaml
pod/static-httpbin created

这样的绕过自然是我们不想要的，但是可以改变策略，把限制做到 Pod 上：

  rules:
  - name: check-registries
    resource:
      kinds:
      - Pod
      namespace: default
    validate:
      message: "Registry is not allowed"
      pattern:
        spec:
          containers:
          - name: "*"
            image: "docker.io/citizenstig/*"

这样更新之后，不管是 Deployment 还是静态 Pod 都无法通过了。

如果使用 kubectl edit deploy httpbin 把 image 字段修改为 docker.io/citizenstig/httpbin，就能看到 deployment 能够正常工作了。

或者我们可以要求所有 Pod 都必须指定 CPU 限制：

validate:
  message: "resources/limits is needed."
  pattern:
    spec:
      template:
        spec:
          containers:
          - resources:
              limits:
                cpu: "*"

这个策略提交之后，上面的 Deploy 就再次无法部署了：

$ kubectl apply -f httpbin.yaml
Error from server: error when creating "httpbin.yaml": admission webhook "nirmata.kyverno.validating-webhook" denied the request:
...
Path: /spec/template/spec/containers/0/resources/limits/. Expected map[string]interface {}, found <nil>.

修改清单，加入资源限制，即可满足条件。

修改资源（mutate）

这里也可以做类似自动注入的内容，例如我们可以要求所有 default 命名空间中的 Deployment，如果 deployment 标签中有 io=heavy，则分配到 ssd=true 的节点上。

apiVersion : kyverno.io/v1alpha1
kind: Policy
metadata:
  name: assign-ssd
spec:
  rules:
  - name: assign-ssd
    resource:
      kinds:
      - Deployment
      namespace: default
      selector:
        matchLabels:
          io: heavy
    mutate:
      overlay:
        spec:
          template:
            spec:
              nodeSelector:
                ssd: true

修改一下上面的 Deployment，加上标签：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: httpbin
  labels:
    io: heavy
spec:
...

提交到集群之后，查看变更结果：

$ kubectl get deployments httpbin -o yaml
apiVersion: extensions/v1beta1
kind: Deployment
...
    spec:
...
      dnsPolicy: ClusterFirst
      nodeSelector:
        ssd: "true"

看到多出来的 nodeSelector 字段，如果查看 Pod 信息，也会发现这个 Deployment 的所有 Pod 都分配到了指定的节点上。

创建资源（generate）

有时候我们在 Kubernetes 上创建资源的时候，可能希望同时提供一些缺省资源，例如一个新的命名空间，我们希望其中包含缺省的 Configmap 或者 SA 或者资源限制。

例如我们要在新建 test-n 的命名空间的同时，创建名为 dummy 的 sa。

apiVersion : kyverno.io/v1alpha1
kind: Policy
metadata:
  name: auto-sa
spec:
  rules:
  - name: auto-sa
    resource:
      kinds:
      - Namespace
      name: "test-*"
    generate:
      kind: ServiceAccount
      name: dummy
      data:
        spec: {}
        metadata:
          labels:
            source: "webhook"

这个策略生效后，每次我们创建形如 test-* 的命名空间，其中都会生成对应的名为 dummy 的 ServiceAccount，并且有标签：source=webhook。

Generate 还提供了复制对象的方法，例如每个新命名空间中都应该复制一个名为 conn 的 Configmap，就可以使用如下策略：

apiVersion : kyverno.io/v1alpha1
kind: Policy
metadata:
  name: auto-cm
spec:
  rules:
  - name: auto-cm
    resource:
      kinds:
      - Namespace
      name: "test-*"
    generate:
        kind: ConfigMap
        name: conn
        clone:
          namespace: default
          name: conn

随意验证一下：

$ kubectl create configmap conn \
    --from-literal=mysql=mysql \
    --from-literal=mongodb=mongodb
configmap/conn created
$ kubectl create ns test-6
namespace/test-6 created
$ kubectl get cm,sa -n test-6
NAME             DATA   AGE
configmap/conn   2      6s

NAME                     SECRETS   AGE
serviceaccount/default   1         7s
serviceaccount/dummy     1         6s

这里会发现，随着新的命名空间的创建，新的 SA 和 CM 也都出现了。

结论

相对于其他的类似工具，Kyverno 在灵活、强大和易用之间取得了一个很好的平衡，不需要太多学习时间，就能够提供相当方便的功能，官网提供了大量的针对各种场景的样例，非常值得一看。

参考链接

项目主页：https://kyverno.io/

在 Linkerd2 中进行流量拆分

Fri, 12 Jul 2019 11:40:31 +0800

最新发布的 Linkerd 2.4，加入了对流量拆分的支持。

安装最新版本之后，可以看到这个流量拆分功能所使用的 API 资源并非来自 Linkerd，而是 SMI 规范的一部分。

$ curl -sL https://run.linkerd.io/install | sh
...
$ kubectl api-resources | grep -i split
trafficsplits ts split.smi-spec.io true TrafficSplit

和 Istio 的 Service + Selector 的拆分方式不同，Linkerd 其实没有什么特别的上游定义方式，简单的定义独立的 Service 即可。例如我们要从 flaskapp 服务分流到 v1 和 v2 两个版本，在 Istio 中，需要定义一个 flaskapp 服务，然后使用标签，在 Service 的标签子集中，选择两组 Subset 作为目的地。而在 Linkerd/SMI 中，就需要分别定义三个服务了，例如 flaskapp、flaskapp-v1、flaskapp-v2。下面简单操练一下。

$ wget https://raw.githubusercontent.com/fleeto/istio-for-beginner/master/code/flaskapp/flaskapp.istio.yaml
$ linkerd inject flaskapp.istio.yaml | kubectl apply -f -
...
$ wget https://raw.githubusercontent.com/fleeto/istio-for-beginner/master/code/sleep/sleep.yaml
$ linkerd inject sleep.yaml | kubectl apply -f -
...

分别安装了两个版本的 flaskapp，和一个版本的 sleep 服务之后。再创建两个 flaskapp 的分版本服务。

apiVersion: v1
kind: Service
metadata:
  name: flaskapp-v1
  labels:
    app: flaskapp
spec:
  selector:
    app: flaskapp
    version: v1
  ports:
    - name: http
      port: 80
      targetPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: flaskapp-v2
  labels:
    app: flaskapp
spec:
  selector:
    app: flaskapp
    version: v2
  ports:
    - name: http
      port: 80
      targetPort: 80

创建两个服务之后，就可以尝试拆分了，同样是一个 YAML：

apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata:
  name: flask-split
spec:
  service: flaskapp
  backends:
  - service: flaskapp-v1
    weight: 1
  - service: flaskapp-v2
    weight: 500m

注意这里的定义和 Istio 也稍有不同，使用权重而非百分比进行分流。

可以在 Sleep 中进行测试：

$ for i in {1..1000}; do curl -sSL http://flaskapp/env/version | grep v1; done | wc -l
660

可以看到，按照我们的权重分配，成功进行了分流。但是目前在 SMI 中并没有看到条件选择的相关内容，因此目前的功能还比较初级。可以通过 Flagger 的加持，实现更加复杂的功能。

33 个 Kubernetes 安全工具

Thu, 11 Jul 2019 15:00:49 +0800

原文：33 Kubernetes security tools

作者：Mateo Burillo

Kubernetes 安全工具——分类

为了方便读者浏览目录，我们把这些工具按照主要功能和范围进行了分类：

Kubernetes 镜像扫描和静态分析
Kubernetes 运行时安全
Kubernetes 网络安全
镜像分发和机密管理
Kubernetes 安全审计
端到端的 Kubernetes 安全商业产品

我们最爱的容器编排平台已经成熟，会有越来越多的 Kubernetes 安全工具涌现出来，如果读者发现我们列表的错漏，请在 Twitter 上联系 @sysdig。

言归正传。

Kubernetes 镜像扫描

Anchore

主页：https://anchore.com

许可：免费（Apache）以及商业产品

Anchore 引擎不但能够对容器镜像进行分析，更可以使用用户自定义的策略来完成自定义的安全检查。

除了利用 CVE 数据库来对已知威胁进行扫描之外，Anchore 还提供了很多附加标准可以进行配置，来作为扫描策略的一部分：Dockerfile 检查、凭据泄露、语言相关内容（mpm、maven 等）、软件许可等。

Clair

主页：https://coreos.com/clair

许可：免费（Apache）

Clair 是最早开源的镜像扫描项目之一，也是 Quay 镜像库的安全扫描引擎。Clair 能从很多数据源中拉取 CVE 信息，其中包括来自 Debian、RedHat 或者 Ubuntu 安全团队的特定发行版的威胁列表。

和 Anchore 不同的是，Clair 专注于威胁检测和 CVE 匹配的功能，也提供了一定的扩展性，让用户通过实现可插接驱动来实现扩展。

Dagda

主页：https://github.com/eliasgranderubio/dagda

许可：免费（Apache）

Dagda 会针对容器镜像中已知的漏洞、特洛伊、病毒、恶意软件和其它恶意威胁进行静态分析。

和其它的 Kubernetes 安全工具相比，Dagda 有两个与众不同之处：

原生集成了 ClamAV，不仅可以扫描镜像，还能用作防毒软件。
Dagda 还提供了运行时保护功能。从 Docker 守护进程实时收集事件，并和 Falco 集成识别安全事件。

KubeXray

主页：https://github.com/jfrog/kubexray

许可：免费（Apache），但是需要从 JFrog Xray（商业产品）获取数据。

KubeXray 监听 Kubernetes API Server 的事件，并利用 JFrog Xray（商业产品）的元数据来确认只有符合策略要求的 Pod 才能运行。

KubeXray 不只会对新建或者更新的容器部署进行审计（Kuberentes 准入控制就是这样），还能动态的根据新的安全策略对运行中的容器进行检查，并删除有漏洞的镜像所对应的资源。

Snyk

主页：https://snyk.io/

许可：免费（Apache）以及商业产品

Snyk 是一个特别的漏洞检测工具，其特点是着眼于开发工作流，自称是开发第一的解决方案。

Snyk 会直接链接到代码仓库，解析项目结构，并分析引入的代码及其直接和间接依赖。Snyk 支持很多流行的编程语言，还能发现潜在的许可风险。

Trivy

主页：https://github.com/knqyf263/trivy

许可：免费（AGPL）

Trivy 是个简单全面的容器漏洞检测工具，能够方便的和 CI/CD 进行集成。它的安装和操作都很简单，只需要一个二进制文件，无需安装数据库和其它的附加内容。

Trivy 的简便性的一个缺点是需要学习如何解析和转发它的 JSON 输出，这才能方便其它工具进行调用。

Kubernetes 运行时安全

Falco

主页：https://falco.org/

许可：免费（Apache）

Falco 是一个云原生的运行时安全工具，CNCF 成员项目。

利用 Sysdig 的 Linux 内核指令和系统调用分析，Falco 能够深入理解系统行为。它的运行时规则引擎能够检测应用、容器、主机以及 Kubernetes 的反常行为。

凭借 Falco，在每个 Kubernetes 节点部署一个代理，无需修改或者注入第三方代码或者加入 Sidecar 容器，就能够得到完整的运行时可见性以及威胁检测。

Linux 运行时安全框架

原生的 Linux 框架其实不能算作是“Kubernetes 安全工具”，但它们的运行时安全上下文是可以包括在 Kubernetes 的 Pod 安全策略之中的（PSP），所以还是值得一提。

AppArmor 为容器内的进程附加一个安全档案，其中定义了文件系统、权限、网络访问规则、库链接等。这是一个访问控制系统，会阻止未经授权的动作发生。

SELinux 是一个 Linux 内核安全模块，和 AppArmor 有点相似，常常被拉来做比较。SELinux 更加强大，粒度更细，也比 AppArmor 更有弹性，学习曲线更加陡峭、也更加复杂。

Seccomp 和 seccomp-bpf 允许对系统调用进行过滤，可以防止用户的二进制文对主机操作系统件执行通常情况下并不需要的危险操作。它和 Falco 有些类似，不过 Seccomp 没有为容器提供特别的支持。

开源版 Sysdig

主页：https://www.sysdig.com/opensource

许可：免费（Apache）

Sysdig 是一个全面的 Linux 系统（在 Windows 和 Mac OSX 下也提供了有限支持）下的观察、排错和调试工具。可以用来对主机操作系统以及运行其上的容器进行详细的监控和观察。

Sysdig 还对容器运行时以及 Kubernetes 元数据提供了原生支持，能在收集到的系统活动数据中加入额外的维度和标签。Sysdig 提供了很多方式来探索 Kubernetes 集群：可以使用 kubectl capture 创建一个是检点的快照，或者使用 kubectl dig 来进行交互访问。

Kubernetes 网络安全

Aporeto

主页：https://www.aporeto.com/

许可：商业

Aporeto 提供了“从网络和基础设施中解耦的安全性”。这意味着你的 Kubernetes 服务不只是获得了一个本地 ID（也就是 Kubernetes ServiceAccount），还有一个全局 ID/指纹，可以以此为基础和任何其它服务进行安全和双向校验的通信。

Aporeto 生成的唯一身份，不仅可以提供给 Kubernetes 或者容器，还能提供给主机、云函数和用户使用，根据这些身份和网络安全策略的配置，可以选择性的对通信进行放行或者阻断。

Calico

主页：https://www.projectcalico.org/

许可：免费（Apache）

Calico 经常随容器编排系统一同部署，用于实现容器之间的虚拟网络。在基础的网络功能之外，Calico 项目还实现了 Kubernetes 网络策略规范，以及自己的一套安全策略，其中包括了端点的 ACL 和基于注解的入栈/出栈网络安全规则。

Cilium

主页：https://www.cilium.io/

许可：免费（Apache）

Cilium 提供了容器防火墙以及网络安全功能，适用于 Kubernetes 和微服务负载。Cilium 依赖于一种新的 Linux 内核技术——BPF，用它来执行核心数据路径的过滤、监控、重整、重定向等功能。

Cilium 能够根据容器身份（Docker 或者 Kubernetes 标签和元数据）进行网络访问策略的定义。Cilium 还能理解并过滤多种 HTTP、gRPC 这样的 L7 协议（例如可以设置两个 Kubernetes 部署之间 REST API 的访问性）。

Istio

主页：https://istio.io/

许可：免费（Apache）

Istio 是广为人知的服务网格产品，它通过部署平台无关的控制平面，并把所有托管服务流量重新路由到动态配置的 Envoy Proxy 上完成网格功能。Istio 占据了通信的主动权，能够为微服务和容器实现多种网络安全策略。

Istio 网络安全能力包括：透明的 TLS 加密，能够自动把微服务通信升级为 HTTPS，并且它具备 RBAC 以及鉴权能力，可以在集群中不同工作负载之间进行通信时进行接受或者拒绝的决策。

Tigera

主页：https://www.tigera.io/

许可：商业

Tigera 的“Kubernetes 防火墙”技术，以零信任网络的理念来加固 Kubernetes 的网络安全。

与其它 Kubernetes 原生网络解决方案类似，Tigera 利用 Kubernetes 元数据来识别集群中的不同服务和实体，提供跨多云或混合单体-容器基础设施运行时检测、持续合规性检查和网络监控能力。

Trireme

主页：https://www.aporeto.com/opensource/

许可：免费（Apache）

Trireme 是一个简单直接的 Kubernetes 网络策略规范的实现。它有一个与众不同的特点：无需一个中心控制平面来对网格进行协调，因此这个方案具备很好的伸缩能力。Trireme 通过在每个节点上安装代理的方式来影响主机的 TCP/IP 网络栈。

镜像分发和机密管理

Grafeas

主页：https://grafeas.io/

许可：免费（Apache）

Grafeas 是一个开源的 API，用于对软件供应链进行审计和监管。泛泛而论，Grafeas 是一个元数据和审计日志收集工具，可以用来跟踪组织中的安全合规实践。

这种集中起来的信息可以帮助用户回答类似这样的安全问题：

某个容器是谁构建并签名的？
所有的安全扫描和策略检查都通过了么？什么时候的事？这些工具都输出了什么信息？
谁把它部署到生产环境的？用什么参数部署的？

Portieris

主页：https://github.com/IBM/portieris

许可：免费（Apache）

Portieris 是一个 Kubernetes 准入控制器，可以用于内容信任。它依赖 Notary 服务器以此作为信任源头并签署工件。

一旦修改了 Kubernetes 的工作负载，Portieris 就会为请求的容器镜像拉取签名信息和内容信任策略，如果需要的话，还可以修改 API 对象的内容，并以签署版本的镜像来进行替换。

Vault

主页：https://www.vaultproject.io/

许可：免费（MPL）

Vault 是一个用于存储机密（例如密码、Token、Secret 等）的高度安全的存储方案，它支持很多高级功能，例如临时安全令牌或者受编排的密钥翻转。

可以用 Helm 在 Kubernetes 集群中部署 Vault 的 Chart，使用 Consul 作为存储后端。它支持 Kubernetes 的本地资源，比如说 ServiceAccount Token，甚至还能作为缺省的 Kubernetes Secret 仓库。

Kubernetes 安全审计

Kube-bench

主页：https://github.com/aquasecurity/kube-bench

许可：免费（Apache）

Kube-Bench 是一个 Go 应用，它会运行 CIS Kubernetes 基准测试中的测试，来检查 Kubernetes 部署的安全程度。

Kube-Bench 会扫描你的 Kubernetes 集群组件（ETCD、API、Controller Manager 等）、敏感文件授权、不安全的帐号或者开放端口、资源配额、API 速率限制等方面查找不安全的配置参数。

Kube-Hunter

主页：https://github.com/aquasecurity/kube-hunter

许可：免费（Apache）

Kube-Hunter 在 Kubernetes 集群中查找安全弱点（例如远程代码执行或者信息泄露）。可以把 Kube-Hunter 作为一个远程扫描器，来从外部攻击者的视角来观察你的集群；也可以用 Pod 的方式来运行。

Kube-Hunter 有个特别之处就是“active hunting”，它不仅会报告问题，而且还会尝试利用在 Kubernetes 集群中发现的问题，这种操作可能对集群有害，应小心使用。

Kubeaudit

主页：https://github.com/Shopify/kubeaudit

许可：免费（MIT）

Kubeaudit 是一个免费的命令行工具，由 Shopify 提供，用于对 Kubernetes 的配置进行多方面的审计。其中包含无限制的镜像使用、以 Root 身份运行、特权运行以及缺省的 ServiceAccount 等。

Kubeaudit 由很多其它有趣的功能，例如扫描处理本地的 YAML 来查找配置缺陷和安全问题，并且自动修复。

Kubesec

主页：https://kubesec.io/

许可：免费（Apache）

Kubesec 是一个比较特别的 Kubernetes 安全工具，它会直接对 YAML 进行扫描，查找其中描述的 Kubernetes 资源是否使用了较弱的安全参数。

例如它可以检测到 Pod 的过高权限，使用 root 作为默认用户、附加到主机网络命名空间、危险的加载操作（例如 /proc 或者 Docker Socket）。它还提供了一个在线的演示，可以在上面提交 YAML 体验这一功能。

Open Policy Agent

主页：https://www.openpolicyagent.org/

许可：免费（Apache）

OPA 的目标是把安全策略和最佳实践从特定的运行时平台（Docker、Kubernetes、Mesosphere、Openshift 等）中解耦出来。

例如可以把 OPA 作为 Kubernetes 准入控制器后端进行部署，这样 OPA 代理就可以接管安全决策，根据自定义安全约束，对请求进行校验、拒绝甚至是就地修改。OPA 使用一种自有的 DSL（Rego）编写策略。

端到端的 Kubernetes 安全商业产品

我们决定创建一个单独的分类来介绍商业产品，这是因为它们经常会覆盖安全工作的多个方面。下表做了一些简要对比。

	镜像扫描	容器合规	运行时安全	网络安全	Forensics	Kubernetes 审计
AquaSec	Y	Y	Y	Y	Y	Y
Capsule8			Y	Y	Y	Y
Caviring	Y	Y	Y			Y
Google SCC	Y		Y	插件	Y
Layered Insight	Y	Y	Y	Y
NeuVector	Y	Y	Y	Y	Y	Y
StackRox	Y	Y	Y	Y	Y	Y
Sysdig Secure	Y	Y	Y	Y	Y	Y
Tenable Container security	Y	Y	Y
Twistlock	Y	Y	Y	Y	Y	Y

Aqua Security

主页：https://www.aquasec.com/

许可：商业

AquaSec 是一个针对容器和云负载的商业安全工具，包括：

能够集成到容器仓库或者 CICD 的镜像扫描。
能够检测容器修改或异常行为的运行时保护。
容器原生的应用程序防火墙。
针对云服务的 Serverless 安全。
集成到事件日志的合规和审计报告。

Capsule 8

主页：https://capsule8.com/

许可：商业

Capsule 8 在你的自建或云端 Kubernetes 集群中部署探针，从而集成到基础设施之中。这个探针会搜集主机和网络指标，通过这些数据和攻击行为模式进行匹配。

Capsule 8 团队负责在 0 day 攻击到达你的集群之前进行检测和阻止。他们的安全团队能够将安全规则推送到探针上，从而阻止软件威胁。

Cavirin

主页：https://www.cavirin.com/

许可：商业

Cavirin 专注于为不同的安全标准化机构提供企业版本。它的镜像扫描功能，还可以与 CI/CD 管道进行集成，在将不合规的镜像推送到镜像库之前阻止它们。

Cavirin 安全套件使用机器学习为网络安全状态提供类似信用的评分，提供补救技巧，以改善安全状况或安全标准合规性。

Google Cloud Security Command Center

主页：https://cloud.google.com/security-command-center/

许可：商业

Google SCC 能帮安全团队收集数据、识别威胁并在业务损失之前对其采取行动。

SCC 是一个统一的控制面板，在这里可以集成不同的安全报告、资产清单以及第三方安全引擎。

SCC 提供的 API 可以集成来自不同来源（Sysdig Secure 或者 Falco）的 Kubernetes 安全事件。

Layered Insight (Qualys)

主页：https://layeredinsight.com/

许可：商业

Layered Insight（现在是 Qualys 的一部分）是围绕“嵌入式安全性”的概念设计的。它用静态分析技术扫描原有镜像漏洞并通过 CVE 检查后，Layered Insight 会注入一个二进制代理，生成一个中间镜像。

这个二进制代理包括容器网络流量、I/O 流以及应用程序活动的运行时安全性探测，还包括基础架构运营商或 DevOps 团队提供的自定义安全检查内容。

Neuverctor

主页：https://neuvector.com/

许可：商业

NeuVector 通过分析网络活动和应用程序行为，为每个映像创建定制的安全配置文件，来执行容器安全基准和运行时保护。它还可以主动阻止威胁，通过修改本地网络防火墙来隔离可疑活动。

NeuVector 的网络集成，标记为“安全网格”，能够对服务网格中的所有网络连接执行数据包深度检查和 L7 过滤。

StackRox

主页：https://www.stackrox.com/

许可：商业

StackRox 容器安全平台的设计目标是涵盖 Kubernetes 集群中应用程序的整个生命周期。与此列表中的其它商业方案一样，它会根据观察到的容器行为生成运行时配置文件，并会在发现异常情况时自动发出警报。

StackRox 平台还将使用 CIS Kubernetes 基准以及其他容器合规性基准，对 Kubernetes 配置进行评估。

Sysdig Secure

主页：https://sysdig.com/products/secure/

许可：商业

Sysdig Secure 在整个容器生命周期内对云原生应用程序实施保护。它把镜像扫描，运行时保护和取证结合在一起，以识别漏洞、阻止威胁，执行合规性并对微服务中的活动进行审计。

一些重要功能包括：

Scanning images in a registry or as part of the CI/CD process to uncover vulnerable libraries, packages, and configuration Run-time detection to protect containers in production with behavioral profiles Record pre- and post-attack activity through system calls with microsecond level granularity 250+ out of the box compliance checks to keep your configuration secure

在镜像库中，或作为 CI/CD 过程的一部分对镜像进行扫描，以发现易受攻击的库、包和配置内容。
运行时检测，使用行为配置文件来保护生产中的容器。
通过系统调用，在毫秒一级对攻击前后的行为进行记录。
开箱即用的超过 250 项合规性检查，帮助用户保持配置安全。

Tenable Container Security

主页：https://www.tenable.com/products/tenable-io/container-security

许可：商业

在容器问世之前，Tenable 在安全行业广为人知，它的 Nusus 是一款流行的漏洞扫描和安全审计工具。

Tenable Container security 利用他们在计算机安全领域的经验，将 CI/CD 与漏洞数据库、专门的恶意软件检测引擎和安全威胁补救建议集成在一起。

Twistlock (Palo Alto Networks)

主页：https://www.twistlock.com/

许可：商业

Twistlock 自诩为云优先的、容器优先的平台，提供与云提供商（AWS，Azure，GCP）、容器编排器（Kubernetes，Mesospehere，Openshift，Docker），Serverless 运行时，网格框架和 CI/CD 工具的特定集成。

除了通常的容器安全企业功能，如 CI/CD 管道集成或镜像扫描，Twistlock 使用机器学习技术来生成行为模式和容器感知网络规则。

Twistlock 被 Palo Alto Networks 收购，Palo Alto Networks 也是 Evident.io 和 Redlock 安全解决方案的所有者。期待这三个平台合而为一，整合到 Palo Alto 的 PRISMA 中。

为容器提供更好的隔离：沙箱容器技术概览

Wed, 10 Jul 2019 17:14:41 +0800

原文：Making Containers More Isolated: An Overview of Sandboxed Container Technologies

作者：Jay Chen

摘要

既然主流 IT 工业都在采用基于容器的基础设施（云原生方案），那么了解这一技术的短板就很重要了。Docker、LXC 以及 RKT 等传统容器都是共享主机操作系统核心的，因此不能称之为真正的沙箱。这些技术的资源利用率很高，但是受攻击面积和潜在的攻击影响都很大，在多租户的云环境中，不同客户的容器会被同样的进行编排，这种威胁就尤其明显。主机操作系统在为每个容器创建虚拟的用户空间时，不同容器之间的隔离是很薄弱的，这是造成上述问题的根本原因。基于这样的现状，真正的沙箱式容器，成为很多研发工作的焦点。多数方案都对容器之间的边界进行了重新架构，以增强隔离。本文覆盖了四个项目，分别来自于 IBM、Google、Amazon 以及 OpenStack，几个方案的目标是一致的：为容器提供更强的隔离。IBM Nabla 在 Unikernel 的基础上构建容器；Google 的 gVisor 为运行的容器创建一个特定的内核；Amazon 的 Firecracker 是一个超轻量级的沙箱应用管理程序；OpenStack 将容器置入特定的为容器编排平台优化的虚拟机之中。下面对几个方案的概述，有助于读者应对即将到来的转型机会。

目前的容器技术

容器是一种对应用进行打包、分享和部署的现代化方式。与把所有功能打包为单一软件的单体应用相反，容器化应用或微服务的设计目标是专注于单一任务。容器中包含要完成这一任务所需的所有依赖项目（包、库和一些二进制文件）。正因如此，容器化应用是平台无关的，能够在任何操作系统上运行，并不在意其版本或者已部署软件。这给开发人员带来了极大的方便，再也不用为不同的客户和平台准备不同版本的软件了。因此也有了一个不太准确的想法：把容器当成了“轻量级虚拟机”。当容器在主机上完成部署之后，每个容器的资源，例如文件系统、进程和网络栈都会被安置在一个虚拟的隔离环境之中，其它容器无法访问这一隔离环境。这个技术能够在一个集群内同时运行几百或几千个容器，容器化应用能够轻松的通过复制容器实例的方式进行伸缩。

目前容器技术的发展，得益于两项技术的进步：Linux 命名空间以及 Linux Control Group（cgroup）。命名空间虚拟隔离的用户空间，并且给应用分配独立的系统资源，例如文件系统、网络栈、进程号以及用户编号等。在这个隔离的用户空间中，PID = 1 的应用程序控制了文件系统的根，并可以用 root 的身份运行。这个抽象的用户空间允许每个应用都不受同一主机上运行的其它应用的影响。目前有六个可用的命名空间：mount、inter-process communication (ipc)、UNIX time-sharing system (uts)、process id (pid)、network 以及 user。另外还提议了两个额外的命名空间，分别是 time 和 syslog，但是 Linux 社区还在对其规范进行定义。Cgroups 为应用进行硬件的限制、优先级、审计和控制。CPU、内存、设备和网络都是硬件资源。当把命名空间和 cgroup 组合起来，我们就可以在单一主机上，安全的运行多个应用，并且其中的每个应用都有各自的隔离环境，这是容器的的根本。

虚拟机和容器之间的区别是，虚拟机是硬件层的虚拟化，而容器是操作系统级的。虚拟机管理器（VMM）为每个虚拟机模拟一个硬件环境，容器运行时则为每个容器模拟一个操作系统。虚拟机共享主机的物理硬件，容器会共享主机操作系统的内核以及物理硬件。因为容器从主机上共享的资源更多，它们对存储、内存以及 CPU 的利用比虚拟机更加有效。然而共享越多，其代价就是容器之间、容器和主机之间的信任边界就越模糊。图 1 中描述了虚拟机和容器的架构差异。

相对于命名空间隔离技术而言，虚拟化硬件隔离通常会有更好的安全边界。容器（进程）中逃出的攻击者，往往比虚拟机中逃出的攻击者具有更大的威胁。命名空间和 cgroup 的弱隔离是造成这种风险的原因。Linux 为每个进程中加入新的属性字段，通过这种方式实现了命名空间和 cgroup。这些在 /proc 文件系统中的字段会告诉主机操作系统，一个进程是否能看到其它进程，或者这个进程能够使用的 CPU 或内存的预算。如果从主机操作系统上查看运行中的进程和线程（例如 top 和 ps 命令），容器进程看起来和主机上的其它进程都是很相似的。一般来说 LXC 或者 Docker 这样的传统容器，在同一主机上运行时，会共享统一主机的同一内核，因此不能称其为沙箱。例如 CVE-2014-3519、CVE-2016-5195、CVE-2016-9962、CVE-2017-5123 以及 CVE-2019-5736，都会从容器中越狱而出。多数内核漏洞都适用于容器逃逸，这是因为内核漏洞通常会导致权限升级，最终允许受攻击的进程在原命名空间之外获得控制权。除了经由软件漏洞进行的攻击之外，错误的配置，例如部署一个具备过高权限（例如 CAP_SYS_ADMIN、privileged）的容器，或者关键挂载点（例如 /var/run/docker.sock）都可能引发容器逃逸。想在多租户集群中部署容器、或者把包含有敏感数据的容器和其它不受信容器部署在同一主机上，就要考虑一下发生灾难性后果的可能性了。

这些安全性方面的担忧，促使研究人员为容器构建了更强的信任边界。具体的解决方式就是创建一个真正的沙箱容器，尽可能的从主机操作系统中隔离开来。多数解决方案都是一种混合架构，在虚拟机的强信任边界和容器的高效率之间尝试取得平衡。在成文之时，还没有任何一个项目成熟到能够成为标准，但未来的容器发展毫无疑问地会采纳其中一些有用的概念。本文的剩余部分会讨论几个有前途的项目，并对它们的特点进行比较。

我们会从 Unikernel 开始，它是最早的一个单一目标虚拟机的尝试，它把应用和最小化的操作系统库打包成为单一镜像。很多致力于创建安全、低耗的最优化虚拟机镜像的未来项目，都以 Unikernel 的概念为基础。然后我们会看看 IBM 的 Nabla，这个项目的目标是像容器一样的运行 Unikernel 应用；接下来是 Google gVisor，它在用户空间的内核中运行容器。在这两个类 Unikernel 项目之后，我们把目光转向以虚拟机为基础的容器方案，Amazon 的 Firecracker 以及 OpenStack Kata。最后一节的结论中，会对所有的方案进行比较。

Unikernel

虚拟化技术让云计算成为可能。Xen 以及 KVM 这样的 VMM 是 AWS 和 GCP 的基石之一。虽然现代 VMM 能在单一集群内处理几百个虚拟机，然而传统的通用操作系统构建出来的虚拟机通常没有为在虚拟化环境中的运行进行优化。通用操作系统的设计目标是尽可能支持更多类型的应用程序，所以它的核心会包含所有类型的驱动、协议以及调度器。然而当前云中运行的虚拟机通常是被单一应用独占的，例如 DNS、代理服务器或者数据库。每个应用都只依赖于一小部分内核功能，闲置的内核功能不但浪费了系统资源，还扩大了攻击面积。更多的代码，就要面对更多的安全和隐患和 Bug。这种现状促使计算机科学家们用最小化的内核功能来支持单一应用，从而设计出了单一用途的操作系统。

操作系统研究者们在 90 年代提出了 Unikernel 的概念。Unikernel 是一个特别的单寻址空间的虚拟机镜像，能够直接运行在 VMM 上。它把应用程序及其依赖的内核功能打包到一个镜像之中。 Nemesis和 Exokernel 是 Unikernel 最早的两个学术项目。图 2 描述了 Unikernel 虚拟机镜像创建和部署的过程。

Unikernel 把内核拆分为多个库，只将应用依赖的库打包到镜像里。跟虚拟机类似，Unikernel 在虚拟机 VMM 上工作。低耗的 Unikernel 能够快速的启动和扩容。Unikernel 的突出特点就是安全、低耗、高度优化和快速启动。Unikernel 镜像只包含应用依赖的库，如果不做特别要求，其中甚至连 Shell 都没有，这就减小了受攻击面积。不但是攻击者缺乏落脚点，就算是有定制失误的镜像，其影响范围也只在它自己的实例之中。Unikernel 镜像只有几兆，因此能在几十毫秒内完成启动，还可以在单一主机上运行几百个实例。用单一寻址空间代替多数现代操作系统中使用的多级页表，Unikernel 应用的内存访问延迟比虚拟机中更低。由于应用是在构建镜像时进行编译的，编译器能够进行更多的静态类型检查，从而优化二进制文件的效率。

Unikernel.org 维护了一个 Unikernel 项目的列表。即便是具有这样鲜明的特点，Unikernel 还是没有获得太多关注。Docker 2016 年收购了一家 Unikernel 的初创公司，大家认为 Docker 可能要把容器打包到 Unikernel 里面。三年后，还是没有出现任何集成的迹象。进展缓慢的重要原因之一就是，还没有成熟的构建 Unikernel 应用的成熟工具，大多数 Unikernel 应用只能在特定 VMM 中运行。另外要把应用移植到 Unikernel 上，可能需要针对不同语言进行定制，并且手动选择依赖的内核库。Unikernel 中的监控和排错即使能做得到，也会对性能造成很大影响。所有这些限制，都降低了开发者向 Unikernel 迁移的意愿。容器和 Unikernel 有很多相似之处。它们都是单一用途的只读镜像，意味着镜像中的组件无法更新或补丁，要更新应用就必须更新镜像。今天的 Unikernel 有点像前 Docker 时代：没有容器运行时可用，开发者必须使用 chroot、unshare 和 cgroup 等基础工具来把应用放入沙箱。

IBM Nabla

IBM 的研究者们提出了 Unikernel as process 的点子：Unikernel 应用以进程的形式在特定的虚拟机系统中运行。IBM 的 Nabla Containers 项目，用面向 Unikernel 的 Nabla Tender 替换了 QEMU 这样的通用 VMM，进一步强化了 Unikernel 的信任边界。Unikernel 和通用 VMM 之间的 Hypercall 还是一个很大的受攻击面积，所以针对 Unikernel 的 VMM 可以使用更少的系统调用，从而显著的提高安全性。Nabla Tender 拦截 Unikernel 发送给 VMM 的 Hypercall，并翻译为系统调用。Linux Seccomp 策略会阻断所有 Tender 不需要的系统调用。Unikernel 和 Nabla Tender 以用户空间进程的形式在主机上运行。图 3 展示了 Nabla 在 Unikernel 应用和主机之间创建瘦接口的过程。

研究者声称，Nabla Tender 和主机的通信使用了不到 7 个系统调用。由于系统调用是用户空间进程和操作系统内核之间的桥梁，越少的系统调用，就越难攻击到核心。把 Unikernel 运行为进程还有个好处就是使用 gdb 这类基于进程的调试器进行调试。

为了和容器编排平台对接，Nabla 还提供了符合 OCI 运行时标准的 Nabla 运行时 runnc。OCI 运行时标准规范了运行时客户端（例如 Docker 和 Kubelet）以及运行时（例如 Runc）之间的 API。Nabla 还提供了一个镜像构建器，用于创建能够使用 runnc 运行的 Unikernel 镜像。Unikernel 和传统容器的文件系统之间存在差异，因此 Nabla 没有遵循 OCI 的镜像标准，换句话说， Docker 镜像和 runnc 是不兼容的。在本文写作期间，这个项目还在早期试验阶段，还有一些功能缺失，例如加载/访问主机文件系统的能力、加入多网卡的能力（Kubernetes 需要）或者从其它 Unikernel 镜像进行引用的能力。

Google gVisor

Google gVisor 是 GCP App Engine、Cloud Functions 和 CloudML 中使用的沙箱技术。Google 意识到在公有云基础设施中运行不受信容器的风险，以及虚拟机沙箱的低效，因此开发了用户空间的内核作为沙箱来运行不受信应用。gVisor 通过拦截所有从应用到主机内核的系统调用，并使用用户空间中 gVisor 的内核实现来处理这些调用。本质上来说，gVisor 是 VMM 和客户内核的组合，图 4 展示了 gVisor 的架构。

gVisor 在应用和主机之间建立了稳固的安全边界。这个边界限制了应用在用户空间的系统调用。无需依赖虚拟硬件，gVisor 以主机进程的方式运行，充当主机和应用之间的沙箱。哨兵实现了多数的 Linux 系统调用，尤其是内核功能，例如信号分发、内存管理、网络栈以及线程模型。哨兵已经实现了 319 个 Linux 系统调用中的 70% 多，用于为沙箱应用提供支持。哨兵和主机内核的通信只使用了不到 20 个 Linux 系统调用。gVisor 和 Nabla 有很相似的策略：保护主机。它们都使用了不到 10%的系统调用来和主机内核通信。gVisor 创建通用核心，而 Nabla 依赖的是 Unikernel，它们都是在用户空间运行特定的客户内核来支持沙箱应用的运行。

有人可能会奇怪，开源的 Linux 内核已经如此稳定，为什么 gVisor 还要重新实现一个。gVisor 的内核使用的是 Golang，其中的强类型安全以及内存管理都比 C 编写的 Linux 内核更安全。gVisor 的另外一个重要卖点就是它和 Docker、Kubernetes 以及 OCI 标准的紧密集成。把运行时修改为 gVisor runsc，就能拉取和运行大多数的 Docker 镜像了。在 Kubernetes 里，可以把整个 Pod（而非每个容器分别）运行在 gVisor 沙箱中。

gVisor 还在婴儿期，也一样有一些限制。gVisor 要拦截和处理沙箱应用中的系统调用，总要有一定开销，因此不适合系统调用繁重的应用。注意 Nabla 没有这个开销，这是因为 Unikernel 应用不进行系统调用。Nabla 只使用 7 个系统调用来处理 Hypercall。gVisor 没有直接的硬件访问（透传），所以如果应用需要硬件（例如 GPC）访问，就无法在 gVisor 上运行。最后，gVisor 没有实现所有的系统调用，因此使用了未实现系统调用的应用是无法在 gVisor 上运行的。

Amazon Firecracker

Amazon Firecracker 用于 AWS Lambda 和 AWS Fargate。它是一个 VMM，会创建轻量级虚拟机（MicroVM），特别适合多租户容器和无服务器场景。在 Firecracker 出现之前，Lambda 和 Fargate 都在每个客户独立的 EC2 虚拟机上运行，从而保证强隔离。虽然在公有云中，虚拟机的强隔离性要优于容器，但是使用通用的 VMM 和虚拟机来做应用沙箱是很不经济的。Firecracker 为云原生应用定制了 VMM，兼顾了安全和性能两方面问题。Firecracker VMM 为每个客户虚拟机提供了最小操作系统功能，并且模拟设备来增强安全和性能。可以用 Linux 内核以及 ext4 文件系统轻松的构建运行在 Firecracker 之上的虚拟机镜像，Amazon 在 2017 年开始开发 Firecracker，并在 2018 年开源。

和 Unikernel 概念类似，只有一个功能和设备的小子集可以用于容器操作。和传统虚拟机对比，microVM 在受攻击面积、内存消耗和启动时间方面都很有优势。评估表明，Firecracker 的 microVM，运行在 2CPU 和 256G 内存的主机上，消耗不到 5MB 内存，启动大约用了 125ms。图 5 展示了 Firecracker 架构以及它的安全边界。

Firecracker VMM 依赖于 KVM，每个 Firecrfacker 实例都以用户空间进程的方式运行。每个 Firecracker 进程都被 seccomp、cgroup 和命名空间策略锁定，因此它的系统调用、硬件资源、文件系统和网络活动都被严格限制。每个 Firecracker 进程中都有多个线程。API 线程作为客户端和主机以及 microVM 之间的控制平面。VMM 线程呈现了一个 virtIO 设备的最小集（网络和块设备）。Firecracker 只提供了 4 个模拟设备给 microVM：virtio-block、virtio-net、串口控制台以及一个用于停止 microVM 的只有一个按钮的键盘。为了安全性考虑，虚拟机不提供和主机分享文件的机制。主机上的数据（例如容器镜像），通过块设备暴露给 microVM。虚拟机的网络接口由网桥上的 TAP 设备提供支持。所有的出栈数据包都会拷贝到 TAP 设备，并受 cgroup 策略的速率限制。安全边界的层次最大程度的降低了用户应用之间互相干扰的可能性。

目前为止，Firecracker 还没有完全和 Docker 以及 Kubernetes 完成集成。Firecracker 不支持硬件透传，所以需要 GPU 以及任何设备加速访问的应用都无法兼容。它限制了虚拟机和主机的文件共享以及网络模型。然而这个项目有强力的社区支持，应该很快会和 OCI 标准打通并支持更多应用。

OpenStack Kata

出于对传统容器安全性的担忧，Intel 在 2015 年启动了它们以虚拟机为基础的容器技术：Clear　Container。Clear Container 依赖 Intel VT 的硬件虚拟化技术以及高度定制的 QEMU-KVM（qemu-lite）来提供高性能的基于虚拟机的容器。在 2017 年，Clear container 项目加入了 Hyper RunV，这是一个基于 hypervisor 的 OCI 运行时，从而启动了 Kata 容器项目。继承了 Clear Container 的所有财产，Kata 现在支持更多的基础设施和容器规范。

Kata 完整的集成了 OCI、CRI 以及 CNI，它支持多种网络模型以及可配置的客户内核，这样一些有特别网络需求或者内存版本限制的应用就可以得到支持了，图 6 展示了 Kata 和现有编排平台的交互。

Kata 在主机上有一个 kata-runtime，用于配置新容器。在 Kata VM 中的每个容器，在主机上都有对应的 Kata Shim。Kata Shim 从客户端接收 API 请求（Docker 或 Kubelet），通过 VSock 转发请求到 Kata 虚拟机中的代理。Kata 作出很多优化启动时间的优化。NEMU 是一个轻量级的 QEMU，约有 80% 的设备和包被删除。VM-Templating 克隆一个运行中的 Kata VM 实例，并分享给其它新启动的 Kata VM。这一操作能够显著降低启动时间以及内存消耗，但是可能受到跨虚拟机的边缘通道攻击，例如 CVE-2015-2877。热插拔功能让虚拟机以最小资源启动（例如 CPU、内存、virtio block），并在有申请时加入额外的资源。

Kata 容器和 Firecracker 都是基于虚拟机的沙箱技术，也都是服务于云原生应用的。但是它们用不同的方法来实现目标。Firecarcker 用一个特定的 VMM 来给客户操作系统创建安全的虚拟化环境，而 Kata 是一个为运行容器而高度优化的轻量级虚拟机。有人已经尝试在 Firecracker VMM 上运行 Kata。这个项目还在试验阶段，也许会把两个项目的长处融为一体。

结论

我们已经看了多个用于解决容器隔离问题的方案。IBM Nabla 是一个基于 Unikernel 的方案，把应用打包为特别的虚拟机。Google gVisor 是特制 VMM 和客户操作系统核心的结合，提供了应用和主机之间的安全界面。Amazon Firecracker 是一个特定的 VMM，为每个客户操作系统提供最小化的硬件和内核资源。Kata 是高度优化的虚拟机，内置了容器引擎，可以运行在 VMM 上。这些方案各有优劣，很难说那个更好。表格 1 中展示了一个针对重要功能的对比表。如果你有应用运行在 Unikernel 系统中，例如 MirageOS 或者 IncludeOS，Nabla 是最佳选择。gVisor 是目前和 Docker 和 Kubernetes 集成最好的，但是因为系统调用实现不完整，有些应用可能无法运行。Firecracker 支持自定义的客户操作系统镜像，所以如果你的应用需要在特定虚拟机上运行，它是你的最佳方案。Kata 兼容 OCI，在 KVM 以及 Xen 上都能运行。它可以简单的在混合环境中部署微服务。

虽然可能需要很长时间，才能看到有一个或多个解决方案最终被主流接受，但已经可以看到大多数云厂商已采取行动来解决这些问题。对于构建本地云原生平台的组织而言，它不是世界末日。快速修补、最小权限配置和网络分段等常见做法都可以有效地减少被攻击面。

Linkerd v2：响应实际生产需求的新一代服务网格

Tue, 02 Jul 2019 13:20:58 +0800

原文：Linkerd v2: How Lessons from Production Adoption Resulted in a Rewrite of the Service Mesh

作者：William Morgan

关键信息

Linkerd 2.0 在一个被广泛接受的服务网格产品的基础上进行了大量改造，原产品使用 Scala 实现，从 Twitter 的 Finagle RPC 系统中受益良多。
新版本产品从 JVM 转为使用 Go（控制平面）和 Rust（数据平面）协作实现。
Buoyant 团队在 Rust 网络栈方向进行了深入的探索，并简化 UX，提升易用性，降低学习门槛。最终造就了更快、更轻更简单的运维体验。
Linkerd 2.0 诞生至今已经过了 6 个多月，团队相信这次重写已经开始获得回报，很多从前面对 Linkerd 1.x 感觉无从下手的用户，现在已经满意的开始使用 2.x。

服务网格正成为现代云原生技术栈的重要成员。它把服务间通信（数据中心的惯用语中称之为东西向流量）的机制从应用代码迁移到了平台层，并提供了用于对通信进行度量和处理的工具，让运维人员以及平台所有者得到一个基本独立于应用代码的观察和控制层。

服务网格这个名词的历史还很短，背后的概念却不是那么新潮。这些概念在 Twitter、Netflix 和 Google 等公司中使用了超过十年，一般是通过 Finagle、Hystrix 以及 Stubby 这样的胖客户端形式实现的。从技术视角来看，现代服务网格中，部署协作代理（Sidecar）的方式是胖客户端组件的变体，将客户端库换成代理服务器，这种方式因为 Docker 和 Kubernetes 这样的容器和容器编排系统的流行而逐步成为可能。

服务网格的流行趋势始于 Linkerd，它是服务网格的最早产品和项目。在 2016 年发布第一个版本开始，目前有两条并行的开发路线：原始的 1.x 分支，构建在 “Twitter 技术栈” 之上，包含了 Scala、Finagle、Netty 以及 JVM；2.x 分支使用 Rust 和 Go 从头做起。

Linkerd 2.0 的出现，不仅是对底层的重新实现、还因为在多年以来的生产环境中的应用过程中总结了很多经验教训，所以在方法层面也有了很大改观。本文将对这些实践经验进行讨论，并探究其成为 Linkerd 2.0 哲学、设计和实现基础的原因。

Linkerd 是什么？值得注意么？

Linkerd 是一个开源的服务网格项目，也是 CNCF 成员。它在 2016 年出现，为全球各种规模的公司提供生产级别的架构支持，客户不仅包含 Strava 和 Planet Labs 这样的初创公司，还有 ComCast、Expedia、Ask 和 Chase Bank 等大型企业。

Linkerd 为微服务应用提供了可观察行、韧性和安全性方面的支撑。尤其重要的是，这些功能是属于平台层的。这意味着 Linkerd 的功能是跨越所有服务、独立于实现方式的，这就让平台的所有者能够跳出对开发团队的路线图和路线选择的依赖，进行独立思考。例如 Linkerd 能够在服务之间的通信中加入 TLS，让平台运维人员能够配置证书的生成、分发和验证过程，无需在服务开发团队的路线图中加入 TLS 的相关工作。

Linkerd 是通过在网格中的服务中加入透明的 L5/L7 代理完成工作的。这些代理构成了 Linkerd 的数据平面，负责处理各自代理服务的所有出入流量。数据平面受到控制平面的管理，Linkerd 的控制平面是一组进程，为运维人员提供集中的对流量进行观测和管理的服务。

Linkerd 基于对现实的一个认识：流经微服务的通信，和应用自身的代码一样，都是其运维工作的重要组成部分。Linkerd 无法介入微服务的内部，但是可以通过对成功率、吞吐量以及响应延迟的观测，来报告服务的健康情况。与此类似，Linkerd 无法修改应用的错误处理逻辑，但是可以通过对失败或缓慢的请求进行重试，来提高服务的健康程度。Linkerd 还能对连接进行加密，提供安全的服务身份认证，使用流量迁移的方式完成金丝雀和蓝绿部署等功能。

Linkerd 1.x

我们在 Twitter 运行的应用，是业界最早、最大规模的微服务应用之一，Linkerd 就诞生于这种运维经验之中。Twitter 从三层的 RoR 应用迁移到了 Mesos 和 JVM 基础之上的类似云原生的架构，这个过程中创建了一个库：Finagle，它为每个服务提供了服务发现、重试、监控等功能。Finagle 是 Twitter 进入大规模微服务阶段的重要一步。

Linkerd 1.x 诞生于 2016 年，根植于经过生产考验的 Twitter 技术栈：Finagle、Scala、Nettfy 和 JVM。我们最初的目标很简单：把 Finagle 的强力语义公诸于世。用 Scala 库的形式提供异步 RPC 支持是很受限的，因此我们将 Finagle 绑定为代理服务器的形式，这样就可以为各种语言编写的应用提供服务了。与此同时，容器和编排系统的快速蹿红，很好的降低了为每个服务实例部署代理的成本。Linkerd 增长强劲，尤其是在快速推进 Docker 和 Kubernetes 之类新技术的云原生社区。

从无到有，Linkerd 和服务网格模型本身都得到了长足的进步。今天 Linkerd 的 1.x 分支正在世界各地的公司中广泛采用，并在持续的发展之中。

Linkerd 的经验教训

Linkerd 虽然很成功，很多组织还是不想将 Linkerd 部署到生产环境，或者愿意这样做，但是要进行大量投入。

这种情况的形成，有很多方面的原因。有的组织不想把 JVM 引进到自己的环境之中。JVM 的运维较为复杂，有些运维团队因为这样那样的原因，拒绝任何基于 JVM 的软件进入他们的系统——尤其是 Linkerd 这样担任关键角色的系统。

其它的组织不愿意为 Linkerd 分配系统资源。一般来说，Linkerd 1.0 在资源充足的情况下，是很能承受规模负载的——单一进程每秒能够处理几万的的请求；然而对付小负载的能力让人不太满意——单进程的 RSS 很难降低到 150MB 以下。Scala、Netty 和 Finagle 加剧了资源问题——它们的共同目标都是在资源充足的环境下提供最大的吞吐量。

一个组织可能要部署成百上千个 Linkerd 代理，资源消耗颇为可观。作为妥协，我们建议用户为每个节点而非进程部署数据平面，这样用户能够降低资源消耗。然而这样一来就提高了运维的复杂性，限制了 Linkerd 的能力实现，例如为每个服务提供 TLS 证书。

最近 JVM 在这方面有了长足的进步。Linkerd 1.x 的资源消耗和尾部延迟在 IBM OpenJ9 上都大有改观，并且 Oracle 的 GraalVM 承诺会作出进一步的改善。

最后一点，还有复杂性方面的问题。Finagle 是一个功能非常丰富的库，我们将其中的很多功能直接通过配置文件的形式暴露给了用户。结果是 Linkerd 1.x 具有很好的定制性和弹性，但是也有了陡峭的学习曲线。其中一个设计失误就是引入了 dtab 这一来自 Finagle 的路由语言作为基础配置原语。任何想要对 Linkerd 行为进行定制的用户都会陷入到 dtab 之中，在投入使用之前都需要进行很多的智力投入。

重新开始

尽管 Linkerd 的接受度还在上升之中，我们在 2017 年底得出共识，我们必须重新审视我们的方案。Linkerd 的价值主张无疑是正确的，但是它对运维团队的高要求可能不太必要。当我们反思我们在协助组织采用 Linkerd 的经验时，我们确认了一些面向未来的关键原则：

节省资源：Linkerd 应该尽可能的降低性能和资源成本，尤其是代理层。
开箱即用：Linkerd 不应该扰乱现存的应用，也不应该依赖复杂的配置。
简单易用：Linkerd 应该能够用较低的认知门槛来进行韵味。组件应该让用户感觉到清晰，其行为应该易于理解。

每一项需求都是一系列的挑战，为了降低系统资源需求，我们只能告别 JVM。为了开箱即用，我们需要在网络协议检测等复杂技术上进行钻研。最后，简单是最复杂的需求，我们要在每个方面明确的落实极简主义、渐进性和内省的原则。

面对这次重写，我们认为我们首先应该专注于一个初始的用例。我们决定聚焦在 Kubernetes 环境下的通用协议，包括 HTTP、HTTP/2 以及 gRPC，这只是一个起点，以后会突破这些约束进行扩展。

目标 1：节省资源

Linkerd 1.x 中，控制平面和数据平面都是同一个平台的产物。然而这两个组件的需求是很不一样的。数据平面会伴随每个服务的每个实例一同部署，处理进出该服务的所有流量，因此必须又快又小。另外它还必须安全：Linkerd 的用户相信它能够用于处理敏感信息，符合 PCI 和 HIPAA 的合规性要求。

而控制平面是单独部署的，并不存在于请求的处理路径之中，对速度和资源的需求较低。它更看重对扩展和迭代的支持。

很明显 Go 是控制平面的理想实现平台。Go 具有运行时支持，以及类似 JVM 的垃圾回收机制，这一平台为现代网络服务而进行了优化，其运行成本大大低于 JVM。相对于 JVM，Go 语言的静态二进制、内存占用和启动时间都是很吸引人的。我们的性能测试结果中，Go 比本地编译的语言稍慢，但是对于控制平面来说就足够快了。最后，Go 的生态系统让我们获得了很多关于 Kubernetes 的相关功能支持，另外我们认为这个语言的低门槛和流行度也都有助于开源社区的贡献。

我们考虑过用 Go 和 C++ 开发数据平面，然而 Rust 注定是最符合我们需求的选择。Rust 专注于安全，尤其是它强大的 Borrow checker，在编译时强制执行安全内存实践，避免了一整类内存相关的安全漏洞，这就使他比 C++ 更有吸引力。它能够被编译为本地代码，并有细粒度的内存管理能力，这使 Rust 比 Go 具有更好的性能和内存控制能力。Rust 兼具丰富功能和表现力的语言特性，对我们的 Scala 程序员很有吸引力，零成本抽象模型声明让我们在不牺牲安全性或性能的情况下提高了表达能力。

Rust 的最大问题是（2017 年）：它的生态系统比其它语言来说相对落后。我们知道选择 Rust，就意味着要在网络方面进行深耕。

目标 2：开箱即用

解决了底层平台的决策问题之后，我们就要着手解决下一个设计目标了：开箱即用。对于 Kubernetes 应用，向既有应用中加入 Linkerd 不应破坏原有功能，也不应该依赖复杂的配置。

为了满足这个需要，我们做了很多设计抉择。我们给 Linkerd 的代理加入了协议检测的能力：它能够代理 TCP 流量，与此同时还能自动检测其中的 7 层协议。在 Pod 创建时用 Iptables 设置流量劫持，业务代码中的任何 TCP 连接都会被透明的经过本地的 Linkerd 代理，如果这些连接中使用的是 HTTP、HTTP/2 或者 gRPC，Linkerd 会自动的使用 L7 的方式进行干预——例如报告成功率、重试幂等请求、在请求级进行负载均衡等。这些目标都可以在无需用户配置的情况下完成。

我们还努力提供尽可能多的缺省功能。Linkerd 1.x 中提供了丰富的代理级指标，把聚合和报告留给用户去做。在 Linkerd 2.0 中，我们将 Prometheus 作为控制平面的成员，这样我们就可以在 Grafana 中提供开箱可用的聚合指标视图了。我们使用这套指标构建了一套 UNIX 风格的命令，让运维人员可以在命令行中观察运行中的服务。结合协议检测功能，平台运维人员可以从 Linkerd 获得丰富的服务级的指标，无需进行配置。

进出应用的 TCP 连接都被路由到 Linkerd 的数据平面（Linkerd-proxy），Linkerd 数据平面让这些流量可以被控制平面进行观测和管理。

目标 3：简单易用

这是最重要的目标，简单和易用在某种程度上是矛盾的（感谢 Rich Hickey 的《Simple Made Easy》，让我们茅塞顿开）。我们意识到，Linkerd 是一款面向运维的产品，也就是说，这并不是一个云厂商代你运维的服务网格产品，我们希望你会自己运行自己的 Linkerd。这样的话，减小 Linkerd 的运维面积是一个重点。幸运的是，几年来帮助用户采纳 Linkerd 1.x 的经验，给我们很大帮助：

Linkerd 不应藏在幕后或过于神奇。
Linkerd 的内部状态应该是可观察的。
Linkerd 的组件应该具备良好的定义、充分解耦并具备清晰的边界。

为了这个目标，我们在服务中做了很多的设计决策。我们放弃了把控制平面集成到单一进程中的尝试，而是使用其自然形态进行了边界拆分：一个提供 Web 界面的 Web 服务；一个 Proxy API 服务来和数据平面进行通信等。我们在 Linkerd 的仪表盘上向用户直接公开了这些组件，我们还设计了符合 Kubernetes 生态系统中惯用的仪表盘和命令行客户端的界面：linkerd install 命令会输出一个 Kubernetes 清单文件，使用 kubectl apply 提交之后就能进行安装，Linkerd 仪表盘的观感和 Kubernetes 仪表盘类似。

我们还用加入约束的方式来避免复杂性。我们在 Kubernetes 核心名词，例如 Deployment 和 Pod 的基础上进行工作，尽量少定义自己的名词。我们尽可能的使用 Kubernetes 的自有功能，例如 Secret 和 Admission Controller。我们限制对 CRD 的使用，因为我们深知，CRD 也是重要的复杂性的来源。

最后，我们加入了扩展检测，让运维人员能够观测到 Linkerd 的内部状态并进行校验。我们把控制平面也加入了网格，这样运维人员就可以使用 Linkerd 丰富的遥测数据来观测和了解 Linkerd 的内部状态了。我们还加入了 linkerd endpoints 命令，用于导出 Linkerd 的内部服务发现信息，以及用于验证 Kubernetes 集群和 Linkerd 设置的 linkerd check 命令。

简而言之，我们尽了最大的努力，希望 Linkerd 能够清晰可见，而非简陋或奇幻。

今天的 Linkerd 2.0

在经过了接近一年的内部投入之后，在 2018 年 9 月，我们启动了 Linkerd 2.0。虽然有着基本相同的价值主张，但是我们对易用性、可运维以及降低资源用量的关注，催生了一个和 1.x 看截然不同的产品。六个月后，我们已经得到了回报，许多无法采用 1.x 的用户已经开始采用 2.x。

目前 Linkerd 的用户和贡献者社区正在蓬勃发展，未来一片光明。2.x 分支有 50 多个贡献者，每周都能规律的完成发布，还有积极友好的 Slack 频道可以进行沟通。我们为我们的努力深感自豪，并期待为我们的用户继续解决实际问题，同时也会继续坚持我们的设计理念。

Envoy 和 Istio 的 6.18

Wed, 19 Jun 2019 18:24:32 +0800

地球对面的时间比我们这里晚一点，我们的 618 已经开始返场了，他们还在 618。

服务网格方面，在这一天有了两个发布：

Envoy Mobile

Envoy Mobile 是一个库，目的是可以直接将 Envoy 的功能封装到移动应用之中，

跨平台的底层网络支持：HTTP/2、QUIC、gRPC、推送、流、重试和超时策略等底层网络技术的实现以及跨平台都是需要付出大量努力来完成的事情，Evnoy Mobile 试图在客户端以一致的跨平台的方式提供这所有功能。
xDS 支持：Envoy 的最深套路就是 xDS 了，Envoy 一旦潜入移动应用，就可以通过 xDS 的方式，在服务端对客户端的网络行为作出控制。
API 的高级支持：用注解方式为 API 提供缓存、优先级等支持

这个项目还非常早期，但是我觉得非常有意思，强悍的 Envoy 用这种方式为移动应用提供了一个可控的网络抽象的能力，目前已经提供了 Java、Swift、OC 等支持，这会不会成为一种新的边缘能力？

Istio 1.2

补丁版本，没啥好说。

参考链接

https://docs.google.com/document/d/1N0ZFJktK8m01uqqgfDRVB9mpC1iEn9dqkQaa_yMn_kE/edit#
https://istio.io/about/notes/1.2/
https://eng.lyft.com/announcing-envoy-mobile-5c2067d9ade0

为什么微服务适合我们

Tue, 11 Jun 2019 21:59:30 +0800

最近的爆款文《Segment 放弃了微服务》流传很广，让我想到了 2015 年底，Segment 的一篇关于微服务的文章。似乎目前没有中译文，因此翻译出来，便于对照。

原文：Why Microservices Work For Us

作者：Calvin French-Owen

在 Segment，我们全心拥护微服务理念，但个中原因，可能并不是读者所以为的那样。

微服务和单体的争论已经够多了，我不想再次复盘。微服务的拥趸们说，微服务有更好的伸缩能力，是清晰软件工程师团队责任的的最佳方式。然而单体应用的拥护者则认为，微服务的运维太复杂，难于启动。

但是微服务的主流益处和今天我们要讨论的好处不太相关，我们要讨论的是：可观察。

当周二凌晨 3 点钟收到传呼的时候，如果看到特定的工作单元出了问题，而无需在单体应用的每个函数调用中加入追踪，那这个过程就轻松百倍了。

并不是说紧耦合代码中无法实现良好的可观察性——只是极少有案例能够从第一天开始就具备完善的可观察性支持。

可观察性从何而来？稍作思考，就能列出 htop、sysdig、iftop、ps 等运维工具。

但是这些都不是用来监控单一程序的执行情况的：热门执行路径、堆栈尺寸等。过去 20 年中，我们打磨出来的工具都是围绕主机、进程或设备进行的。

在分布式系统中，我们可以在我们的监控指标中加入请求和网络吞吐，但是多数工具还是会尝试聚合到主机或者服务的级别。

单体应用中，以进程为中心的监控工具很难感知到一个程序的耗时情况。在单体应用中，我们最好的调试方式，要么是用 Profiler 运行程序，或者实现自己的计时指标。

还有更头痛的事情，正因为我们没有能够在函数级别完成监控，才成全了火焰图，令其成为流行工具。

所以在 Segment，我们不再尝试往单体应用中塞进大量功能，而是在微服务方向花大力气。我们打赌，容器调度和编排会变得更简单也更强大，而多数指标和监控会持续以主机和服务为中心。

这里做个提醒，微服务仅在容易创建新服务的情况下才奏效。否则我们只是把可观察性问题替换成了交付问题了。

在另外一篇文章中，我们讲了一下我们服务的大体情况，以及我们是如何使用 Terraform 的。如今我们开始把每个服务拆为模块，所以我们可以在预备和生产环境中复用同样的配置了。

这里有个认证服务的例子，使用 Terraform 来进行资源分配：

/**
 * Task definition.
 */

module "task" {
  source = "../task" # sets up an ECS task

  name = "auth"
  port = 5027
  image = "segment/auth
  image_version = "latest"
}

/**
 * Service implementation.
 */

module "service" {
  source = "../service" # sets up our shared service resources

  # Module variables
  task = "${module.task.arn}"
  name = "${module.task.name}"
  port = "${module.task.port}"

  # Input variables
  iam_role = "${var.iam_role}"
  zone_id = "${var.zone_id}"
  elb_subnets = "${var.elb_subnets}"
  elb_security_group = "${var.elb_security_group}"
  cluster = "${var.cluster}"
  desired_count = "${var.desired_count}"
  environment = "${var.environment}"
}

如果感到好奇，可以看看完整的模块定义的例子。

这里有着显而易见的好处（监控指标）和很低的成本（少量的 Terraform 脚本），因此我们就不再需要将不同的功能挤到一个现存服务之中了。

目前为止，这套方法很有用。

Segment 有点不同寻常：并非微服务们协调工作，我们有大量称为 microworker 的单元。基本上这是同样的概念，不过 Worker 不为客户请求提供服务，而是从队列中读取数据，进行处理之后，然后给消息做一个 ACK。

Worker 没有依赖，因此它比服务简单很多。没有耦合，因此不用担心一个 Worker 中的问题会影响到系统中的其它成员。

实际工作中，有很多因素迫使我们做出了 microworker 的决定。其中最大的因素是我们的团队规模以及我们要尝试构建的产品的规模。

微服务经常的宣传就是，当团队规模变大时，太多人在编写同一套代码。这种情况下，以团队为单位分配代码库的权限是个自然的举措。但是我们认为，对小团队来说，微服务也一样有好处。

很多和我交流的人都吃惊于我们团队的规模之小，列几个数字来证明一下：

400 个私有仓库
70 个不同的服务（Worker）
10 个工程师

我们的产品规模和团队规模形成了鲜明的对比。所以如果我接到告警，告警可能是我编写的代码导致的，这段代码我半年前开发出来之后就再没朋友。

如此情况下，小型的、定义清晰的服务就很有吸引力了。

下面是一个典型场景：因为队列深度导致的告警。

我们可以在队列的监控中检查一下是否是这个原因。

我们可以清楚的知道是哪个 Worker 出了问题（因为每个 Worker 都会订阅单独的队列），也知道去哪里看日志。每个服务日志都有自己的标签，所以我们无需担忧同一应用中不同请求生成不相关的日志造成的干扰。

我们可以在 Datadog 的独立的 Dashboard 上查看这个 Worker 的 CPU、内存，以及 ELB 报告的延迟。一旦我们识别了问题，只要阅读 50-100 行文件就可以获知问题的确切位置（例如内存泄漏）。

在单体应用中，我们也可以为每个端点加入特定的监控。然而如果每个端点都运行在各自的进程中，我们完全可以自由的进行修改，无需担心影响其它部分。

还没有提到的是，微服务让我们有了隔离 CPU、内存和延时（如果是 ELB 代理的服务）的能力。同样是查找一处内存泄漏，在有上百个端点的单体应用的代码中查找，和在一个 Worker 的百多行代码中进行查找，其难度是不可同日而语的。

我理解，这种方式不会适用于所有场合。为了在创建新服务时能够获得所有支持，需要很大的投入。这种投入会受到团队、工作负载以及产品形态等多种因素的影响，可能不那么理想。

但是对任何产品来说，一旦其运行过程存在复杂的运维和负载，我会选择微服务架构。这种架构让基础设施有弹性、可伸缩，并易于监控，无需牺牲开发人员的生产力。

SMI：推动服务网格社区举步前行

Tue, 11 Jun 2019 07:48:13 +0800

原文：Moving the Service-mesh Community Forward

作者：Christian Posta

在运行一个服务式架构的应用时，往往会面临服务间通信的挑战，服务网格技术正是为此而生。Kubernetes 和容器技术对工作负载的在大量服务器上的部署和进行提供了一个漂亮的抽象，服务网格做的也是类似的工作：他对网络进行抽象，让运维和开发人员能够通过请求路由、可观察性以及策略实施等方式对其进行控制。服务网格带来了各种可能。

唯一的问题是，就算 Kubernetes 提供了有力的 API 来对底层基础设施进行抽象，从而进行工作负载的调度，可惜的是这其中没有一点能够落地的 API 能够提供服务网格所需要的能力。

KubeCon EU 2019 上发布的服务网格接口（SMI）正试图填补这一空白。在此声明：我为 Solo.io 工作，它是 SMI 的创建者之一，并是一个原有统一服务网格产品的主导者。

SMI 规范还很稚嫩，目前正在尝试对运行在 Kubernetes 基础之上的服务网格所需的 API 和能力进行统一（这种尝试也有助于为 Kubernetes 之外运行的统一服务网格奠定一个基础）。

这一举措对服务网格社区来说，带来不少直接利益：

服务网格的实现可能很复杂；将独立于实现的 API 暴露出来，让系统整体更易理解。
这一社区充满变化，专注于能力，并通过标准接口来使用服务网格，降低了对特定实现的依赖；对最终用户来说，这是一个很好的启动方式。
服务网格提供了一组强大的功能用来定义和处理规则（对网络进行编程）；需要有些东西来对这些能力进行编排。不管是厂商提供还是自行实现，将网络编程为特定的实现，这会将你绑定到这一实现，某种程度上也让你的实现变得更加复杂。
在底层（像服务网格这样）为稳定性奠定基础，给未来的创新打开了新的可能，也给整个生态带来了新的机会。

最小公分母

社区里有些家伙对这类方法的可行性表示怀疑，反对的声音至关重要。例如我非常尊重的 Tim Hockin，他提到 SMI 方法有可能成为一种最小公分母，对谁都没好处。

服务网格的能力范围还在扩张之中（目前不同的服务网格实现会有不同的特性），但是 Istio、Linkerd、Consul、App Mesh 等产品在某种程度上还是殊途同归的：

流量路由功能（路由权重、在七层上提供请求级匹配等）满足了金丝雀发布等功能需求。这项能力的诉求是减小变更的影响范围
- 目前版本的 Istio 和 App Mesh 都已经提供这一功能，Consule 和 Consul 也会很快跟进。
顶端指标收集，例如延迟分布、吞吐量、出错率等
- Istio、App Mesh 和 Linkerd 都提供这一能力，Consul 会在近期提供易于配置的（指标收集）功能。
基于服务身份的策略功能
- Istio 和 Consol 已有这部分功能，Linkerd 和 App Mesh 会在近期加入。

语义差别不大

目前 Istio 的各种特性最为成熟，但是有很多其他的实现也正在跟进。事实上各种实现都很相似，关键的差异是易用性、用户体验、管理能力、集成能力等。而关键的问题：“服务网格应该有什么功能？”，各家的答案差别不大。如果 Istio、Linkerd、Consul、App Mesh 以及其它有兴趣在这一方向发展的厂商和社区能够提供支持，把这些差别不大的功能，做成一套 API 并不会难于登天。

无处不在的 Envoy proxy

服务网格的讨论中，还有一个很重要的情况就是通用数据平面的同化趋势。4 个著名的服务网格产品中，有 3 个使用的是 Envoy，并且还有其他服务网格供应商看起来也准备在 Envoy 的基础之上构建产品。我发现每个实现的控制面可能有些不同，但是内部的网络 API 都是继承自 Envoy，在同一个数据平面之下，一个跨服务网格的通用抽象也不算是不可思议。正如 Tim 所说，最大的麻烦来自于实现上的分歧。在这种情况下，其实这些产品并非天差地别。即使是控制平面本身，其实现也没有那么大的区别。

基于已有实现

最后，SMI 来自于现存的服务网格产品。它不是凭空想象，也没有财团驱动，更不是由没有经验的团队造出的空中楼阁。恰恰相反，这一社区目前的贡献来自于真实存在的、在生产环境中部署的服务网格实现。从各个发起者的经验来说，做出一套脚踏实地的 API 并不会耸人听闻。

厂商主导的 SMI

另外来自 Zack Butcher 的意见也很醒目：SMI 由卖东西的厂商领导，调性不好。他特别提出：

Here's the next sniff test: who's backing the project? Are they users of service meshes trying to drive a standard, or are they vendors (trying to sell me something)? What are their motives, and do they align with giving me, a user, a more usable mesh? 7 pic.twitter.com/Fch2IfFVCM
— Zack Butcher (@ZackButcher) June 9, 2019

他们的动机是什么？是给我——一个用户，一个更可用的服务网格？

SMI 规范的发起者之一，Brendan Burns 有个有趣的回应：

The current state of the art in service mesh where you have to lock yourself into an implementation is bad.

Further, no one can build shared tools for all service meshes which is worse.

And no one can build Helm charts that include service mesh apis w/o chosing an impl.
— brendandburns (@brendandburns) June 8, 2019

从目前服务网格的情况看来，把自己锁定在单一实现上是不好的。更进一步，没有人能够为所有服务网格构建共享工具。除非选择一个实现，否则没有人能构建一个包含服务网格 API 的 Helm Chart。

我所在的 Solo.io，我们乐于看到单一的服务网格界面的出现，这是因为我们始终尝试为客户解决：

不确定选择哪个网格
想要在网格之上构建产品，但是希望在这一动荡的领域中保护投入
希望服务网格的管理能有更好的用户体验
希望将南北流量和东西向的网格进行集成
希望得到厂商的帮助，但是…
无法确信任何网格厂商的动机

我们的客户和潜在和客户对于 SMI 的聚合是持肯定态度的，这一新生事物能够帮助他们应对上述这些问题。

另外企业们发现，在满足其最终需求的情况下，存在竞争的多个公益炕上是很有价值的。正如我熟悉的 Java 和 Java EE 一样。标准化的 API 让企业能够参与并在这些讨论中获益。

胜者为王

关于 SMI，最后一个要探讨的想法是：类似容器编排战争的结果，单一厂商或者单一网格产品会成为唯一的赢家。如果预期是这种结局，又希望现在就用上服务网格，SMI 就成为一种有效的防御措施，防止踏入错误阵营无法回头。

在我看来，真实情况是我们会面对多网格产品并存的情况，我们需要以某种方式进行统一（能力层次、集成方式或者管理方式，或者几个方法的结合）。

例如我们的客户中的真实用例，他们在自有部署中使用 Istio 提供开发支持，但是其他团队使用的是 AWS，也使用了 AWS 的 App Mesh。他们有切实的需求，想要在这些网格的基础之上进行抽象并构建工具。如果出现了一个社区领导的抽象，他们就会使用并从中获得价值（至少是不用自己做了）。

推动服务网格社区举步前行

目前来说，社区中的健康争论是必要的，以此可以发现问题、机遇和目标，从而帮助我们进一步的探索，为最终用户和平台构建者提供服务网格的强大功能。服务网格展现了有力的应用网络能力，但今时今日，终点还遥遥无期。

类比容器和编排系统，Kubernetes 让容器变无聊了，服务网格最终也会让应用网络变得无聊。服务网格在加高堆栈的同时，会给用户、社区以及相关厂商带来价值。如果服务网格生态系统进入了寡头局面，这也很棒，我们会面向单一 API 来构建系统；如若不然（我认为这更有可能），我们最好一同努力，摒弃实现差异，努力找出服务网格应该提供的重要功能。

介绍一个小工具：Kubeval

Mon, 10 Jun 2019 11:46:24 +0800

这次要介绍的是一个用于验证 Kubernetes 对象文档结构的小工具：kubeval。它能够对一个或多个 Kubernetes 或 OpenShift 的对象文档进行校验。它所依赖的 Schema 数据来自于 Open API 所生成的内容，所以校验过程中无需和 API Server 进行交互，也正因如此，对各种第三方 CRD 的支持也暂时无能为力，另外还需要有 Schema 库的支持。

这个工具在直接和 Kubernetes 交互的环境中有点画蛇添足，但是如果是在 CICD Pipeline 中，或者是没有 Kubernetes 集群可用的情况下，就很趁手了。

安装

Linux

直接下载安装版即可。

wget https://github.com/instrumenta/kubeval/releases/download/0.9.2/kubeval-linux-amd64.tar.gz
tar xf kubeval-linux-amd64.tar.gz
sudo cp kubeval /usr/local/bin

MacOS

可以下载安装：

wget https://github.com/instrumenta/kubeval/releases/download/0.9.2/kubeval-darwin-amd64.tar.gz
tar xf kubeval-darwin-amd64.tar.gz
sudo cp kubeval /usr/local/bin

也可以使用 Homebrew：

brew tap instrumenta/instrumenta
brew install kubeval

Windows

除了在 Release 页面下载 zip 包之外，还可以用 scoop 进行安装：

scoop bucket add instrumenta https://github.com/instrumenta/bucket-instrumenta
scoop install kubeval

Docker

还提供了 Docker 的运行方式，例如：

$ docker run -it -v `pwd`/fixtures:/fixtures garethr/kubeval fixtures/*
Missing a kind key in /fixtures/blank.yaml
The document fixtures/int_or_string.yaml contains a valid Service
The document fixtures/int_or_string_false.yaml contains an invalid Deployment
--> spec.template.spec.containers.0.env.0.value: Invalid type. Expected: string, given: integer
The document fixtures/invalid.yaml contains an invalid ReplicationController
--> spec.replicas: Invalid type. Expected: integer, given: string
Missing a kind key in /fixtures/missing-kind.yaml
The document fixtures/valid.json contains a valid Deployment
The document fixtures/valid.yaml contains a valid ReplicationController

使用

$ kubeval --help
Validate a Kubernetes YAML file against the relevant schema

Usage:
  kubeval <file> [file...] [flags]

Flags:
  -f, --filename string             filename to be displayed when testing manifests read from stdin (default "stdin")
  -h, --help                        help for kubeval
  -v, --kubernetes-version string   Version of Kubernetes to validate against (default "master")
      --openshift                   Use OpenShift schemas instead of upstream Kubernetes
      --schema-location string      Base URL used to download schemas. Can also be specified with the environment variable KUBEVAL_SCHEMA_LOCATION (default "https://kubernetesjsonschema.dev")
      --strict                      Disallow additional properties not in schema
      --version                     version for kubeval

参数很少，但是都比较有用：

-v：指定 Kubernetes 版本，例如 1.14.2。
--openshift：对 Openshift 对象进行校验。
--schema-location：指定 Schema 库的位置，缺省为 https://kubernetesjsonschema.dev，可以使用环境变量 KUBEVAL_SCHEMA_LOCATION。
--strict：禁止出现 Schema 中未规定的字段。

例如：

$ kubeval sleep.yaml
The document sleep.yaml contains a valid ServiceAccount
The document sleep.yaml contains a valid Service
The document sleep.yaml contains a valid Deployment

或者也可以使用管道：

$ cat sleep.yaml|kubeval
The document stdin contains a valid ServiceAccount
The document stdin contains a valid Service
The document stdin contains a valid Deployment

指定版本进行校验：

$ kubeval -v 1.10.0 sleep.yaml
The document sleep.yaml contains a valid ServiceAccount
The document sleep.yaml contains a valid Service
The document sleep.yaml contains a valid Deployment

使用自己的 Schema 库

前面提到过一个参数：--schema-location，推测应该是用于在无法访问缺省模式库的时候的替补方案，要建立自己的模式库也很方便，只要使用 git 获取在线内容，并使用 Web Server 或者本地文件系统提供服务就可以了：

$ cd /doc
$ git clone https://github.com/instrumenta/kubernetes-json-schema
正克隆到 'kubernetes-json-schema'...
...
$ kubeval --schema-location file:///doc/kubernetes-json-schema  test.yaml
The document test.yaml contains a valid Service

问题

似乎目前对 1.8 之前的版本支持还不够好，慎用。

参考

项目地址：https://github.com/instrumenta/kubeval
文档结构库：https://github.com/instrumenta/kubernetes-json-schema
使用说明：https://kubeval.instrumenta.dev/

Segment 微服务反水案的一点思考

Sun, 09 Jun 2019 23:58:26 +0800

2015 年底，Segment 博客刊登了一篇文章，Why Microservices Work For Us（下文简称为《Work》），三年多，又来了一篇更具话题性的新作：Goodbye Microservices: From 100s of problem children to 1 superstar（下文简称为《Bye》），两相比较，感觉还是有一定的代表性的，这里做一点整理和记录。

微服务的动机

《Work》中提到，主要是因为原有架构中，故障处理不力，需要有更快的诊断和处理方法，这里提到了两个途径：

问题的快速定位：借助更细致方便的监控指标，为突发事件提供明确指导。
问题的快速解决：在定位问题之后，能够更好的从源码中获得支持并解决问题。

要针对某个功能加入监控指标，在原有单体架构中可能会造成不必要的影响，范围不易控制；而源码方面，越小的服务，通常也代表着相对易读的代码；这两个主要需求都指向了同样的解决方案：微服务。

微服务带来的好处

将原有单体应用拆分为微服务之后，不但解决了监控和排错的问题，还带来了一些额外的好处：

隔离的消息队列，不同订阅互不干涉
隔离系统资源，如 CPU 和内存。
隔离网络，如 ELB。

这里只是原文中提到的好处，更多的照本宣科内容这里就不赘述了。

改造的隐忧

《Work》一文中提到了两次，新建微服务应该如何如何。作者似乎认为，微服务有必要更快的创建起来。但按照我的理解，微服务仅是通过进程隔离的强制手段使得模块之间的边界更加清晰，事实上，因为缺乏单体应用强大的上下文支持，同一系统内的不同微服务，往往会因为上下文问题，导致更加复杂的开发过程。

《Bye》一文中补充的拆分过程

单代码库阶段

因为缺乏有效的时间说明，这一操作让人很迷惑，不知道是不是在《Work》发表的时候，各个服务还是在共用同一套代码。也在共用同一套测试方案。《Bye》中提到，一个失败的提交会导致整体测试失败，因此我们大致可以说，这一阶段里，CI/CD 过程也没能完成分割，个人认为，这种情况不太应该算作微服务。
多代码库阶段

为微服务独立创建各自的代码库，并享用各自的测试组件。
共享库阶段

我认为这一阶段呼应了前面的隐忧，在微服务落地之处，为了更快的建立微服务，开始出现了跨服务的共享代码库。

败局的开始

《Bye》的共享代码库一节，罗列了不少遇到的问题：

共享库版本出现碎片：因为工程需要，并不敢冒险同时更新的多个服务的共享代码，造成部分服务的共享代码滞后。
伸缩能力：微服务架构经常鼓吹的能力，在这里似乎被狠狠抽了一巴掌。

个人的一点分析

我眼中的微服务，务虚的角度上来说，有两个关键字：妥协，怀疑。

这里所说的妥协指的是，我们的系统是存活于一个非“理想状态”中的，不管是“拥抱变化”，还是“面向故障”，都是对不完美世界的具体应对方式。

而怀疑的设计态度，最简单的证据就是对隔离的强调，系统资源、数据的隔离都如此强调，我想，代码的隔离是不言自明的。

反观 Segement 的重构之路，（可能）在宣称微服务的时候，各个服务还躺在同一个仓库里，还在共享同样的测试过程。

在进行代码分离之后，又出现了两个不太容易理解的纰漏：

暧昧的代码：前面提到，怀疑是微服务的基本态度，从《Bye》文中可以看到，他们在几十个服务之间共享了需要进行频繁重构的代码，抛开微服务和单体之争不谈，这个行为实在是无法理喻。
暧昧的负载：在拆分之后，按照《Work》的说法，每个微服务都有了独立的队列和监控，由此推论，各个微服务的负载模型应该是比较容易做个描述的，很可惜的，这里称之为一种艺术。

回到单体之后

此处内容给人一种感觉：“今天是个好日子”。给我的感觉是，一些原本应该在微服务阶段完成的工作，甚至是在微服务阶段之前的单体阶段完成的工作，终于完成了——例如改进的测试方案，这能算是半渡而击么？

牢骚

流水账写到这里，有两个深刻的印象就是，这个团队从来没想过这些微服务是彼此独立的，也从来没把每个服务作为一个单独的交付物进行完善。从这个印象出发，回到单体形态，可以说是——得其所哉。

介绍一个小工具：Ksniff

Wed, 05 Jun 2019 00:22:15 +0800

对于相当一部分读者来说，在 Kubernetes 环境中，针对 Pod 进行抓包是个常规操作，在 Pod 中、在 Node 中都能够完成，抓出文件之后现场查看或者拷贝回来喂给 Wireshark 也都不难。Ksniff工具的作用是，把这些常规步骤组织起来，用一个简单的 kubectl 插件命令，就能完成这一系列的操作。

Ksniff 有几个很有意思的特色：

可以使用 krew 方便的进行安装。
能够自动把 Pod 的 TCP Dump 数据输出给 Wireshark。
能够方便的处理非特权 Pod 的抓包工作。
无需触碰 Node。

安装

使用 Krew 能够很方便的安装 Ksniff：

$ kubectl krew install sniff
Updated the local copy of plugin index.
Installing plugin: sniff
CAVEATS:
\
 |  This plugin needs the following programs:
 |  * wireshark (optional, used for live capture)
/
Installed plugin: sniff

抓包到 Wireshark

部署一个简单的 httpbin 服务：

apiVersion: v1
kind: Service
metadata:
  name: httpbin
  labels:
    app: httpbin
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: httpbin
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80

服务启动之后，再启动一个客户端：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: sleep
        version: v1
    spec:
      containers:
        - name: sleep
          image: dustise/sleep
          imagePullPolicy: IfNotPresent

然后就可以启动 ksniff 插件来对 httpbin 的 Pod 进行监听了，例如：

$ kubectl sniff httpbin-5fc7cf895d-lr89b
...
INFO[0000] sniffing method: upload static tcpdump
...
INFO[0000] using tcpdump path at: '/Users/dustise/.krew/store/sniff/

。。。INFO[0002] executing command: '[/tmp/static-tcpdump -i any -U -w - ]' on container: 'httpbin', pod: 'httpbin-5fc7cf895d-lr89b', namespace: 'default'

不难看出，ksniff 非常粗暴的将一个 tcpdump 上传到了被抓包的 Pod 上直接运行。并且命令执行后，直接启动了 Wireshark 进行监听。

下面从 sleep Pod 上给被监听 Pod 制造一点流量。

$ kubectl exec -it sleep-69bd44b5bb-tk6vn -- curl http://httpbin:8000/ip
{
  "origin": "10.244.0.19"
}

在 Wireshark 中会看到相应的数据包：

查看一下被监听 Pod 的进程：

$ kubectl exec -it httpbin-5fc7cf895d-lr89b -- ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.6  85980 25100 ?        Ss   15:42   0:01 /usr/bin/python
root         8  0.0  0.8 130364 35164 ?        S    15:42   0:01 /usr/bin/python
root        35  0.0  0.0   6392  3568 ?        Ss   15:50   0:00 /tmp/static-tcp
root        47  0.0  0.0   6392  3564 ?        Ss   15:58   0:00 /tmp/static-tcp
root        70  0.0  0.0   6392  3564 ?        Ss   16:17   0:00 /tmp/static-tcp
root        90  0.0  0.0   6392  3568 ?        Ss   17:01   0:00 /tmp/static-tcp
root       102  0.0  0.0   6392  3568 ?        Ss   17:05   0:00 /tmp/static-tcp

不难看到，多出了几个 /tmp/static-tcp 的进程。

无特权 Pod 怎么办

Ksniff 还提供了 -p 参数，用于针对无特权 Pod 进行监听。带有这一参数之后，查询目标 Pod 所在节点，然后在该节点上利用节点亲和性创建共享节点网络的特权 Pod，然后在新 Pod 上对流量进行监控。

$ kubectl sniff httpbin-5fc7cf895d-lr89b -p                                                                 1.1  ✱
INFO[0000] sniffing method: privileged pod
INFO[0000] using tcpdump path at: '/Users/dustise/.krew/store/sniff/71102253eded8900c8f7b0d0624c65b3c77ecd6bcd28fabc9a200da
ac502282a/static-tcpdump'
INFO[0000] no container specified, taking first container we found in pod.
INFO[0000] selected container: 'httpbin'
...
INFO[0000] creating privileged pod on node: 'vla'
...
INFO[0008] pod: 'ksniff-qpznn' created successfully on node: 'vla'

$ kubectl get pods

flaskapp-v1-5f58cbc685-9v4z9   1/1     Running   0          92m
httpbin-5fc7cf895d-lr89b       1/1     Running   0          93m
ksniff-689sx                   1/1     Running   0          66m
sleep-69bd44b5bb-tk6vn         1/1     Running   0          93m

可以看到，ksniff 创建了新的 Pod。并且也成功的启动了 Wireshark。再次执行：

$ kubectl exec -it sleep-69bd44b5bb-tk6vn -- curl http://httpbin:8000/ip
{
  "origin": "10.244.0.19"
}

可以看到，Wireshark 中出现了新的数据包。

参考链接

https://github.com/kubernetes-sigs/krew
https://github.com/eldadru/ksniff

Istio：503、UC 和 TCP

Tue, 04 Jun 2019 16:53:52 +0800

原文：Istio: 503’s with UC’s and TCP Fun Times

作者：Karlstoney.com

最近 AutoTrader 在调试一个有些复杂的问题，这一过程得到了 Istio 团队的很多帮助。这个问题现在已经基本得到了解决，这一过程中采取的一些措施可能对其他用户有所启发，因此有了本文。

问题

我们注意到有些请求在第一次尝试的时候会失败，Istio 会自动进行重试，然后就成功了。在 Jaeger 中观察可以看到：第一个请求是 503 状态，response_flags 为 UC。

如果你在关注或者正在使用 Istio，你可能会看到很多千奇百怪的 503。目前 503 的主要问题就是，它太模糊了。

看看这个简单的例子：

基本上，应用 2 的 Envoy 和应用通信过程中的任何问题都会被包裹成 503，发送回上游，然后上游就会进行重试。

不管怎样，有了 Istio，重试并不是世界末日。Istio 检测到故障后进行重试，然后给上游返回了成功信息。然而值得注意的是，故障总会发生，我们应该面向故障进行应用的构建。我们的应用跨越多个 AZ，出现这种奇怪的问题，会有很多可能的错误源头。

我们观察到，大概 0.012% 的请求发生了这种问题。我们的应用是一种微服务架构，这一种故障和 5 个应用相关，这样会看到 0.08% 的聚合请求失败率，（稳定的故障率）表明，这并非是偶然情况。

当你开始考虑这一故障时，会注意到 Sidecar 模型增加了应用通信过程的复杂度，这就是网格的代价之一。

回忆一下没有服务网格的世界，consumer-gateway 管理一个通往 sauron-seo-app 的连接池。然而有了服务网格，我们其实有了三个各行其是的连接池，各有各的配置：

consumer-gateway 到 source-envoy ：Java 代码。
source envoy 到 destination envoy：DestinationRule。
destination envoy 到 sauron-seo-app：在 Envoy 中进行配置，Istio 对其配置并无掌控。

这中间有很多出问题的机会，要查找根本原因，也有很大的排查范围。因此我们对真实场景中这一问题的应对方法进行回顾。

指标

Istio

Istio 搜集了很多的指标，能帮我们凸显问题。Istio 提供的这种水平的可观测性很有趣，能能够凸显你之前发现的问题。这很直白，所以打开 Prometheus 并输入：

sort_desc(sum(changes(istio_requests_total{response_flags="UC", response_code="503", reporter="destination"}[24h])) by (source_app, destination_app, reporter) >0)

这段指标的含义是：最近 24 小时内，状态为 503 并且被标记为 UC（上游连接问题），使用 source_app、 destination_app 以及 reporter 进行汇总。

注意：上图中，reporter=source 就是来自于源 Envoy，而 reporter=destination 就是目标 Envoy。

所以看看我得出的结果，{destination_app="sauron-seo-app",reporter="destination",source_app="consumer-gateway"} 58，这代表过去 24 小时里，从 consumer-gateway 到 sauron-seo-app 的请求中有 58 个出了问题，得到了 503UC 的结果，这一情况是由 sauron-seo-app 的 Envoy 汇报而来。

我们知道了，我们在目标一端发生了问题，这也跟前面的跟踪过程中得到的结论是一致的：源服务尝试了一个不同的目标并获得成功。我们来检查一下 Envoy 发生了什么事。

Envoy

我们要做的下一件事就是启用一些指标，帮助我们对 Envoy 进行排查。缺省情况下 istio-proxy 只提供一些核心的 Envoy 指标。我们需要更多信息。在 Deployment 里加入下列注解：

sidecar.istio.io/statsInclusionPrefixes: cluster.outbound,listener,cluster,cluster_manager,listener_manager,http_mixer_filter,tcp_mixer_filter,server,cluster.xds-grpc

注意：这个指标的数据量较大，缺省是关闭的。我只会在进行排错的时候才启用这些指标，并且在完成工作后就会关闭它们。

完成这一操作后，就会看到一些新指标，例如 envoy_cluster_upstream_cx_destroy_local_with_active_rq 和 envoy_cluster_upstream_cx_destroy_remote_with_active_rq。这些指标来自 Envoy 的视角，因此它的本地和远程是这样的：

envoy_cluster_upstream_cx_destroy_local_with_active_rq

本地销毁的产生一个以上活动请求的链接数量。

听起来很恐怖吧？没人希望活动请求被杀掉，我们的目标 Envoy 说，有大量的远程销毁，而我们的源 Envoy 有大量的本地销毁。

这看起来云山雾罩，所以我觉得最简单的排查方法就是把他们列在一起。这样就会看到 local 指标在源 Envoy 中出现，而目标 Envoy 中报告了 remote 指标：

上图说明 sauron-seo-app 的 Envoy 和应用之间的连接关闭了。看起来是 sauron-seo-app 关闭了（远程关闭）。然后 consumer-gateway Envoy 也随即关闭了连接。这就能够解释 consumer-gateway 在 HTTP 1.1 连接中（Envoy 之间的通信）收到的 5xx 响应了。这个连接无法继续发送数据，除了关闭，别无他法（本地关闭）。

注意：这不是 http2.0 的情景，看起来 Istio 1.2 会有能力把 Envoy 之间的连接池切换为 http2.0。

这样我们就决定，要进一步对 sauron-seo-app 进行观察。

istio-proxy debug 日志

istio-proxy 能够在运行时修改日志级别，对排除这类问题很有帮助。所以我们把这些日志设置为 debug 级别：

kubectl exec -n sauron-seo-app sauron-seo-app-7667b9b7dc-jd3vg -c istio-proxy -- curl -XPOST -s -o /dev/null http://localhost:15000/logging?level=debug

看看是否能有所斩获。

修改日志级别后，可以用 tail 来查看一下日志（可能有非常多的输出）。会看到 503 的相关内容：

[2019-05-30 08:24:09.206][34][debug][router] [external/envoy/source/common/router/router.cc:644] [C77][S184434754633764276] upstream reset: reset reason connection termination

[2019-05-30 08:24:09.206][34][debug][filter] [src/envoy/http/mixer/filter.cc:133] Called Mixer::Filter : encodeHeaders 2

[2019-05-30 08:24:09.206][34][debug][http] [external/envoy/source/common/http/conn_manager_impl.cc:1305] [C77][S184434754633764276] encoding headers via codec (end_stream=false):
 ':status', '503'
 'content-length', '95'
 'content-type', 'text/plain'
 'date', 'Thu, 30 May 2019 08:24:08 GMT'
 'server', 'istio-envoy'


[2019-05-30 08:24:09.208][34][debug][connection] [external/envoy/source/common/network/connection_impl.cc:502] [C77] remote close

[2019-05-30 08:24:09.208][34][debug][connection] [external/envoy/source/common/network/connection_impl.cc:183] [C77] closing socket: 0

这里我们看到了 503 出现在连接 [C77] 上。如果我们后退一下，会看到 [C77] 连接上还有一段：upstream reset: reset reason connection termination。 istio-proxy 告诉我们，上游复位了 77 号连接（这里的上游指的就是应用程序）。这进一步证实了，Envoy 认为 sauron-seo-app 关闭了连接。

抓包

目前为止，我们用了很多的 Istio 和 Envoy 提供的功能，我们大概知道，很可能是目标应用断掉了连接。是时候开始抓包来进一步研究了。

为了在 Kubernetes 上完成这个工作。我们使用了一个叫做 ksniff，我得说，这个工具太棒了。因为我们运行的是非特权容器，因此无法在应用中进行 tcpdump。ksniff 可以：

检查你的目标应用运行在哪个节点上。
部署一个和这个节点有亲和的 Pod，绑定到 Host network。
从特权应用对流量进行 TCP Dump，并把流量发送回你笔记本上的 Wireshark。

TCP Dump 很吵，所以我们会做一下过滤：

我们关注的是 TCP 连接相关的事件，所以只需要看 SYN、FIN 和 RST。
我们要观察的是本地 Envoy 和应用之间的流量，我们只想关注 localhost，所以 -i lo 就可以只查看 loopback 适配器了。

kubectl sniff $pod -p -n $namespace -c istio-proxy -f ‘tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0’ -i lo

我们很快就能看到 RST，表明的确是我们的应用关闭了连接。

这就很清楚了，Envoy 应该能够处理上游的关闭连接。然而在极少数情况（0.003%）下，我们发现 Envoy 尝试向被应用关闭的连接中发送数据。Istio 团队还在尝试理解这种情况发生的原因（似乎是在服务端发送 RST 和 Envoy 复用连接池中的连接的过程中发生的争用），并能够更好的处理这种场景（1.1.8 之后）。

Istio 成员发现，在连接开始（SYN）和复位（RST）之间，总有五秒左右的间隔。

我们的服务器是 nodejs，Google 搜索发现了 Nodejs 文档中的一段内容：

以毫秒为单位的超时时间，缺省值 5000（5秒）：服务器在处理完最后一个响应之后，等待新数据进入的时间，如果超过这一时间都未进行活动，就会销毁该 Socket。

由上述文档看来，虽然 Envoy 为应用创建了连接池，但是应用会在发呆 5 秒钟之后销毁 Socket。这个超时太短了。

TCP Socket 超时

我们做了一番挖掘，我们发现不止在 Nodejs 中有这种情况，Python 应用、Java/Tomecat 都有这种问题。缺省设置如下：

nodejs：5 秒
python：10 秒
tomcat：20 秒

所以 Socket 超时越短，RST 就会越多，也就会有越多的 503 问题。

Istio 团队正在积极的寻求改进方法，我们发现可以简单的设置一个更高的 Socket 超时时间来解决这一问题。

Nodejs

const server = app.listen(port, '0.0.0.0', () => {
  logger.info(`App is now running on http://localhost:${port}`)
})
server.keepAliveTimeout = 1000 * (60 * 6) // 6 minutes

Python

global_config = {
  'server.socket_timeout': 6 * 60,
}
cherrypy.config.update(global_config)

Java-Spring

server:
  connect-timeout: 360000

下图就是我们修复问题的结果：

我知道 Istio 团队正在努力改进这方面的 UX 问题，尽可能高效的处理这类场景，让 Istio 为更多用户提供开箱可用的高性能表现。所以我很相信他会越来越好。

感谢 Chris McKean 和 Istio 社区的朋友们，他们在没有经历这种问题的情况下，依然提供了无私的帮助。希望这个排查过程能够对读者的工作有所助益。

介绍一个小工具：Kubedog

Sun, 02 Jun 2019 14:59:25 +0800

Kubedog 是一个开源的 Golang 项目，使用 watch 方式对 Kubernetes 资源进行跟踪，能够方便的用于日常运维和 CI/CD 过程之中，项目中除了一个 CLI 小工具之外，还提供了一组 SDK，用户可以将其中的 Watch 功能集成到自己的系统之中。安装过程非常简单，在项目网页直接下载即可。

Kubedog CLI 有两个功能：rollout track 和 follow。

rollout track

在 Kubernetes 上运行应用时，通常的做法是使用 kubectl apply 提交 YAML 之后，使用 kubectl get -w 或者 watch kubectl get 之类的命令等待 Pod 启动。如果启动成功，则进行测试等后续动作；如果启动失败，就需要用 kubectl logs、kubectl describe 等命令来查看失败原因。kubedog 能在一定程度上简化这一过程。

例如使用 kubectl run 命令创建一个新的 Deployment 资源，并使用 kubedog 跟进创建进程：

$ kubectl run nginx --image=nginx22
...
deployment.apps/nginx created

$ kubedog rollout track deployment nginx
# deploy/nginx added
# deploy/nginx rs/nginx-6cc78cbf64 added
# deploy/nginx po/nginx-6cc78cbf64-8pnjz added
# deploy/nginx po/nginx-6cc78cbf64-8pnjz nginx error: ImagePullBackOff: Back-off pulling image "nginx22"
deploy/nginx po/nginx-6cc78cbf64-8pnjz nginx failed: ImagePullBackOff: Back-off pulling image "nginx22"

$ echo $?
130

很方便的看出，运行失败的状态及其原因，并且可以使用返回码来进行判断，方便在 Pipeline 中的运行。接下来可以使用 kubectl edit 命令编辑 Deployment，修改正确的镜像名称。然后再次进行验证：

$ kubectl edit deployment nginx
deployment.extensions/nginx edited
$ kubedog rollout track deployment nginx
# deploy/nginx added
# deploy/nginx rs/nginx-dbddb74b8 added
# deploy/nginx po/nginx-dbddb74b8-x4nkm added
# deploy/nginx event: po/nginx-dbddb74b8-x4nkm Pulled: Successfully pulled image "nginx"
# deploy/nginx event: po/nginx-dbddb74b8-x4nkm Created: Created container
# deploy/nginx event: po/nginx-dbddb74b8-x4nkm Started: Started container
# deploy/nginx event: ScalingReplicaSet: Scaled down replica set nginx-6cc78cbf64 to 0
# deploy/nginx become READY
$ echo $?
0

修改完成，重新运行 kubedog，会看到成功运行的情况，并且返回值也变成了 0。

follow

follow 命令的功能和 kubetail 的功能有少量重叠，可以用 Deployment/Job/Daemonset 等为单位，查看其中所有 Pod 的日志，例如前面用的 Nginx，如果有访问的话，就会看到如下结果：

$ kubedog follow deployment nginx
# deploy/nginx appears to be ready
# deploy/nginx rs/nginx-6cc78cbf64 added
# deploy/nginx new rs/nginx-dbddb74b8 added
# deploy/nginx rs/nginx-dbddb74b8(new) po/nginx-dbddb74b8-x4nkm added
# deploy/nginx rs/nginx-6cc54845d9 added
# deploy/nginx event: ScalingReplicaSet: Scaled up replica set nginx-6cc54845d9 to 1
# deploy/nginx rs/nginx-6cc54845d9(new) po/nginx-6cc54845d9-nhlvs added
# deploy/nginx event: po/nginx-6cc54845d9-nhlvs Pulling: pulling image "nginx:alpine"
# deploy/nginx event: po/nginx-6cc54845d9-nhlvs Pulled: Successfully pulled image "nginx:alpine"
# deploy/nginx event: po/nginx-6cc54845d9-nhlvs Created: Created container
# deploy/nginx event: po/nginx-6cc54845d9-nhlvs Started: Started container
# deploy/nginx event: ScalingReplicaSet: Scaled down replica set nginx-dbddb74b8 to 0
# deploy/nginx become READY
# deploy/nginx event: po/nginx-dbddb74b8-x4nkm Killing: Killing container with id docker://nginx:Need to kill Pod
>> deploy/nginx rs/nginx-dbddb74b8 po/nginx-dbddb74b8-x4nkm nginx

>> deploy/nginx rs/nginx-6cc54845d9(new) po/nginx-6cc54845d9-nhlvs nginx
127.0.0.1 - - [02/Jun/2019:11:35:08 +0000] "GET / HTTP/1.1" 200 612 "-" "Wget" "-"
127.0.0.1 - - [02/Jun/2019:11:35:11 +0000] "GET / HTTP/1.1" 200 612 "-" "Wget" "-"

项目地址

https://github.com/flant/kubedog

多数 Dockerfile 示例可能都不够严谨

Wed, 29 May 2019 13:22:44 +0800

原文：Broken by default: why you should avoid most Dockerfile examples

作者：Itamar Turner-Trauring

想把 Python 应用打包成 Docker 镜像，很自然的行为就是上网搜个例子。简单的一搜，就能得出大量简单易懂的结果。

不幸的是这些简单方便的例子经常是有一些这样那样的缺陷，有的显而易见，有的可能就不那么明显了。为了发掘这些问题，本文中将要：

用一个在 Google 搜索结果中常见的 Dockerfile 开始。
展示其中的问题。
给出一些修复问题的建议。

本文的 Docerfile 仅用于解决这里发现的问题，不能算作最佳实践。

先天不足

看看下面的 Dockerfile，这是一个网上搜到的 Python 的容器化例子。做了一点点修改，来隐藏其出处，不过主干是一致的：

# DO NOT USE THIS DOCKERFILE AS AN EXAMPLE, IT IS BROKEN
FROM python:3

COPY yourscript.py /

RUN pip install flask

CMD [ "python", "./yourscript.py" ]

这个 Dockerfile 的一些问题

这个镜像中你能看到什么问题？

问题 1：Python 版本的不确定性

这里第一个需要注意的问题是，基础镜像是：python:3。在编写这个文件的时候，会安装 Python 3.7，但是可能未来某一天的重新构建，可能会变成 Python 3.8。这种版本切换，可能会让这一应用完全无法运行，从而打断了产品的交付过程。

建议：使用 python:3.7 作为基镜像。

问题 2：依赖库版本的不确定性

这里的 pip install flask，没有包含版本信息，所以每次重新构建，都可能升级成最新的 flask（或者 flask 的依赖，又或者 flask 的依赖的依赖）。保持兼容自然没问题，否则的话麻烦就大了。

建议：创建 requirements.txt，其中记载所有依赖的版本号，可以用 pip-tools 完成这一任务。

问题 3：代码的变更会让构建缓存失效

Docker 的层缓存对提高构件速度很有帮助。但是如果把 COPY 操作放在 pip install 前面，所有后续的层就都失效了，也就是说这一镜像会完全重新构建。

建议：在合适的时机进行文件复制。

问题 4：用 root 身份运行

缺省情况下，Docker 容器是用 root 身份运行的，这并不安全。

建议：如果不是有特定需要，例如监听 1024 以下的端口或者完成一些必须 root 身份的操作，建议使用非 root 账号。

改良版本

为了解决上面发现的几个问题，对 Dockerfile 做出如下修改：

FROM python:3.7

COPY requirements.txt /tmp/

RUN pip install -r /tmp/requirements.txt

RUN useradd --create-home appuser
WORKDIR /home/appuser
USER appuser

COPY yourscript.py .

CMD [ "python", "./yourscript.py" ]

这样改进了之后，也并不是就适合在生产环境中运行了，这个镜像还有一些不足。

例如，用一种受控的方式来对 requirements.txt 进行常规更新，以便进行安全更新和 Bug 修复，可能还要禁用缓存对镜像进行周期性重建，来获取安全加固。

参考链接

意外：Servicemesh Interface（SMI）

Tue, 21 May 2019 23:08:25 +0800

在今天的 Kubecon（2019.05.21）上，微软宣布了一个新名词：Service Mesh Interface，简称 SMI，是一个运行于 Kubernetes 之上的服务网格规范，定义了一个能够被多个厂商实现的通用标准，其中包含了能够满足绝大多数通用需求的基本特性。

设计重点

Kubernetes 服务网格的标准接口。
实现最通用的服务网格用例支持。
能够支持新晋厂商加入的兼容能力。
建立有创新空间的生态系统，促进服务网格技术的发展。

规范内容

SMI 中定义了一组描述能力很有限的对象，用于进行服务网格的控制。的确如前文所说的设计重点一样，仅考虑了最核心（也就是最少）的功能支持，以兼容目前和未来的可能有的网格产品。

流量规范

这一组 API 对 HTTP 和 TCP 服务自身进行了定义，例如：

apiVersion: specs.smi-spec.io/v1alpha1
kind: HTTPRouteGroup
metadata:
  name: the-routes
matches:
- name: metrics
  pathRegex: "/metrics"
  methods:
  - GET
- name: health
  pathRegex: "/ping"
  methods: ["*"]
---
apiVersion: specs.smi-spec.io/v1alpha1
kind: TCPRoute
metadata:
  name: tcp-route

观察这一段代码样本，其 HTTP 部分，对服务端的路径、动作都做能做出详细的定义。未来这里还将加入对 Header 和 gRPC 的支持，SMI 发起者们认为这是一个很方便利用 OpenAPI 等工具自动生成的部分。它是一个基础，可以用于访问控制、频率限制等高级功能。

访问控制

SMI 提供了一个很简单的访问控制功能，同样是使用 CRD 的方式，例如下面的代码：

kind: TrafficTarget
apiVersion: access.smi-spec.io/v1alpha1
metadata:
 name: path-specific
 namespace: default
destination:
 kind: ServiceAccount
 name: service-a
 namespace: default
 port: 8080
specs:
- kind: HTTPRouteGroup
  name: the-routes
  matches:
    - metrics
sources:
- kind: ServiceAccount
  name: prometheus
  namespace: default

这里可以看到，利用 sources 和 destination，对服务的访问能力进行了限制。这两个定义来看，只能包含网格内调用，尚无对 Ingress/Egress 流量的支持。

流量拆分

前面提到，流量拆分是在流量规范的基础上定义的，因此其定义相对简单：

apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata:
  name: foobar-rollout
spec:
  service: foobar
  backends:
  - service: foobar-v1
    weight: 1
  - service: foobar-v2
    weight: 0m

这里的服务定义和 Istio 不同，这个对象的候选访问目标，是选择条件重叠的一组独立服务。典型工作流：

名为 foobar-v1 的 Deployment，标签为 app: foobar version: v1。
服务 foobar，选择器定义为 app: foobar。
服务 foobar-v1，选择标准为 app:foobar 且 version: v1。
客户端使用 foobar 的 FQDN 来完成访问。

要调整流量分拆，只需调整 backends 中不同后端服务的权重即可。

流量监控

指标数据的核心分为两个对象种类：resource 和 edge，resource 代表 pod、namespace、node 等对象，而 edge 则描述了流量的方向。

apiVersion: metrics.smi-spec.io/v1alpha1
kind: TrafficMetrics
# See ObjectReference v1 core for full spec
resource:
  name: foo-775b9cbd88-ntxsl
  namespace: foobar
  kind: Pod
edge:
  direction: to
  resource:
    name: baz-577db7d977-lsk2q
    namespace: foobar
    kind: Pod
timestamp: 2019-04-08T22:25:55Z
window: 30s
metrics:
- name: p99_response_latency
  unit: seconds
  value: 10m
- name: p90_response_latency
  unit: seconds
  value: 10m
- name: p50_response_latency
  unit: seconds
  value: 10m
- name: success_count
  value: 100
- name: failure_count
  value: 100

监控资源除了满足 Prometheus 等监控系统的使用之外，还能对服务拓扑、集群资源监控以及金丝雀发布等功能提供数据支持。

参与厂商

下图是这一新组织的合作方（没有 Google 好奇怪）：

其中多数厂商大家都非常熟悉了，有几个补充一下：

Solo.io：产品面很广，除了 Service Mesh 方面大有名气的 SuperGloo 和 Service Mesh hub 之外，还有远程调试、混沌工程、unikernels 以及微服务网关等几个产品。
Mesery 和 Kinvolk：近期都发表了 Istio vs Linkerd 的性能测试报告。
Canonical：Ubuntu 母公司。
Kubecost：对 Kubernetes 集群进行成本分析。

Solo.io 的 Service Mesh Hub 和 SuperGloo 已经更新，宣布对 SMI 的支持。

根据 Github 的数据，目前贡献前两名分别是 Buoyant 和 HashiCorp。

读后感

在去年 InfoQ 的《Service Mesh2018年度总结》一文中有这么一段话：

Service Mesh 这一技术的广阔前景，加上 Istio 的疲弱表现，吸引了更多对此技术具有强烈需求或相关技术储备的竞争者出现，除了 AWS 、 F5 这样的公有云方案，以及 Consul、Kong 等同类软件解决方案，还出现了 Solo.io 这样的更加激进的跨云方案加入战团。 Service Mesh技术的浪潮已将业界席卷其中，然而这一年来，角逐者有增无减，2019 年里，Istio 仍是关键——除非 Istio 能够做出符合顶尖项目的水准，否则，Service Mesh 技术很可能会以多极化、市场细分的形式落地。

好像我们猜到了开头，猜错了结局？

参考

Istio 和 Linkerd 的性能测试分析

Sun, 19 May 2019 13:29:38 +0800

原文：Performance Benchmark Analysis of Istio and Linkerd

作者：Thilo Fromm

动机

过去几年里，服务网格在 Kubernetes 生态中迅速成长。Service Mesh 的价值难以抗拒，然而对摩拳擦掌的用户来说，另一个基础问题就是：成本怎样？

成本有很多种，可不仅仅是学习新技术时的投入。在这一篇报告中，我们选择了一个易于量化的方面：在一定规模的服务中的资源消耗和性能影响。要进行这个测量，我们设计一系列测试场景，针对候选产品进行测试。我们的的候选包括 Istio（来自 Google 和 IBM 的 Istio 以及 Linkerd（CNCF 项目）。

Buoyant 是 Linkerd 的首创者，他们和我们取得联系，目的是获得一个 Istio 和 Linkerd 的客观评判。这给我们一个深入服务网格技术的机会，欣然从命。

Kinvolk 目前有客户正在尝试 Istio。我们的使命是在云原生世界中促进开源技术的发展，这也是我们呈现这一对比报告的根本原因。

下面使用的测试方案也已经开放给开源社区，地址是 https://github.com/kinvolk/service-mesh-benchmark。

目标

研究过程中我们有三个目标：

提供一个可重现的测试框架，任何人都可以下载和使用。
识别最能反应服务网格运行成本的场景和指标。
根据业界在性能测试方面的最佳实践，例如控制编译来源，处理 Coordinated Omission（CO），来对流行服务网格进行评估。

场景

我们的目标是在常规大负载集群的操作环境下，理解服务网格的性能表现。这意味着在产生压力的时候，集群应用还有能力在已定时间范围内给出响应。在系统受到压力的时候，用户访问该集群所服务的页面，还能够在一个可忍受的范围内提供服务。在真实世界中，延迟增大到一定程度之后，就会采取措施进行扩容了。

在本文的测试中，测试负载（每秒 HTTP 请求）的水平是这样设置的——在给应用和服务网格施加压力的时候，运行其上的流量还在一个可控范围之内。

指标

RPS、用户体验和 CO

测试中使用一个恒定的请求速率（RPS）发送 hTTP 请求，我们对响应延迟进行测量，来确定服务网格的总体性能。同样的 RPS 也会施加到一个无服务网格的集群上，以此结果来描述集群和应用的性能基线。

我们的测试过程很注重 CO，在以 UX 为中心的视角下的一个重要因素。负载生成器只会在前一个请求完成之后才发起新请求，而不是为了满足 RPS 要求，不顾之前的请求直接按照时间点发起心情求。

比如说如果我们要做一个 10 RPS 的延迟测试，我们每隔 100 毫秒就发出一个新请求，也就是一个 10 Hz 的速率。但是如果负载生成器在等待一个耗时超出 100 毫秒的请求的结束的话，那么这个 RPS 最多只能到 9。单一请求造成了高延迟，后续的请求也会受到拖累——处理的并不慢，只是开始得晚了。这种行为有两个缺点：第一个就是刚提到的，单一的高延迟请求造成后续请求的延迟；第二就是请求的发生过程被暂停，不符合 RPS 要求。在真实情况下，高延迟问题很可能因为用户蜂拥而至，产生大量积压。

我们使用 wrk2 来生成负载并在客户端测量延迟。wrk2（Gil Tene）是流行的 http 压测工具 wrk（Will Glozer）的 Fork。wrk2 提供了 RPS 参数，可以用指定速率来生成负载，它通过在发起请求的时间点上测试延迟的方式来消除 CO 问题，还会尝试在请求迟发的情况下以双倍速率生成请求的方式来追赶进度。wrk2 还包含了 Gil Tene 的 HDR 直方图功能，提供了无损精确性的记录。越长的执行时间会有越高的精确度，这样后几个百分位的数据精度更高，也是我们更感兴趣的区域。

为了完成这个测试，我们对 wrk2 的功能做了扩展，加入了多服务器地址和多 HTTP 资源路径的支持。我们不想将这个功能独立 Fork 出来，而是会和上游合作加入我们的变更。

性能

为了评估性能，我们可以研究一下延迟的分布（直方图），尤其是尾部的最后几个百分位的延迟。这反映了我们本次测试在 UE 上的焦点：一个典型的页面或者服务，需要不止一个请求来完成动作。如果一个请求延迟了，整个动作都会变慢。单一请求的 p99 在更复杂的操作中会有很大影响，例如浏览器访问一个页面，获取页面中的资源并进行顺序渲染——这就是我们看重 p99 的原因。

资源消耗

使用服务网格会让集群消耗更多资源，和业务逻辑发生争用。为了更好地理解这一效果，我们同时衡量了服务网格控制平面和应用 Sidecar 中的 CPU 和内存消耗。在测试期间，会用一个较高频率在容器级别收集 CPU 使用率和内存用量，每次运行中会选择组件的最大资源消耗，得出所有运行中的中位数并用于出具结果。

我们注意到，内存消耗在测试结束时达到高峰。这个情况是合理的，根据上面的讨论，wrk2 用固定频率发起请求，当延迟超过一个阈值时，负载就会开始堆积，所以内存一旦分配就一直要到测试结束才会释放。CPU 使用率也会全程持续走高。

测试环境

集群

我们使用了自动部署的测试集群，方便测试过程的启动和结束，也更加容易进行统计，生成可靠的数据。

在这个服务网格性能测试过程中，我们使用了一个 5 节点的集群，每个节点使用 24核/48线程的 AMD EPYC CPU，主频为 2.4GHz，64G 内存。我们的工具可以使用可配置的节点数量，可以用不同的配置重新运行。

负载的生成和延迟的测量都在集群内完成。为了消除噪音和 Ingress Gateway 的数据污染，我们把测试聚焦在应用之间的服务网格。负载生成器作为一个 Pod 部署在集群中，我们保留一个节点，用于负载生成和指标测量，在其它四个节点运行一定数量的应用实例。为了合理的统计分布，我们每次运行都会随机选择一个节点来运行负载生成器。

每次运行之前，会随机选择一个节点专门用于生成负载。其它节点运行应用负责承担负载。

为了完成这次测试，我们选择 Packet 作为我们的 IaaS 供应商，工作节点我们选择了 c2.medium。Packet 提供了裸金属服务器，这样就让我们避免了虚拟化环境中常见的干扰问题。

应用

根据前面的讨论，我们选择 wrk2 生成负载，并对这一工具进行了定制，可以同时访问多个 HTTP 端点。

我们用来运行测试的目标应用是 Linkerd 的演示应用 Emojivoto，这个应用自身跟 Linkerd/服务网格的功能并无相关，Emojivoto 使用一个名为 web-svc（type: load-balancer）的 HTTP 微服务作为前端。web-svc 使用 gRPC 和 emoji-svc（提供表情符）以及 voting-svc（提供可控的投票）后端进行通信。这个应用简单清晰，包含了测试所需的云原生应用的所有要素，因此我们选择它作为测试应用。

Emojivoto 应用包含了三个微服务。

然而只用一个应用进行服务网格测试，是很不现实的，真实世界中的服务网格，应该有复杂的多应用的部署。为了在保持简单的情况下更加仿真，我们用可部署的份数来部署 Emojivoto 应用，每个应用的名字中都加入序号。例如 web-svc-1、emoji-svc-1、voting-svc-1 以及 web-svc-2、emoji-svc-2、voting-svc-2。我们的负载均衡会将请求分发给所有这些 App，观察固定的 RPS。

循环利用 YAML，并在名字中加入序号，部署多套应用。

运行测试和统计的稳健性

因为我们使用的是 Packet 提供的公共数据中心来运行我们的测试，所以也不能选择特定的服务器来进行部署。服务器的年龄和他的部件（内存、CPU 等），数据中心中的相对位置（同一个机架、房间、安全区），以及节点之间的物理连接，这些情况都会对测试的原始数据产生影响。其它服务器和我们的测试无关，但是在同一个数据中心内，共享同样的物理网络资源，也是可能对测试造成干扰的，最终会产生不可靠的测试数据。我们的每个数据点都有足够的统计分布样本，这样在进行对比的时候就能消除同一网络内外部因素造成的影响——例如 Istio 和 Linkerd 的延迟以及资源消耗方面的对比。我们还使用了不同数据中心的多个集群进行了测试，这也让我们对测试数据的可靠性信心大增。

为了得到足够的统计分布，我们会每个测试都会运行两次，以得出平均值和标准差，我们在两个集群上同时独立部署，防止遭遇低档硬件或者故障网络，或有服务器被放置在数据中心的角落。

典型的性能测试一般有几个步骤，这些步骤会在两个集群上同时运行，来消除上面提到的隐患。

测试之前，重启所有工作节点。
在两个集群的 istio-stock、istio-tuned、linkerd、bare 命名空间中，分别：
1. 安装服务网格（当然，不包含 bare）。
2. 部署 emojivoto 应用。
3. 部署负载生成器 Job。
4. 等 Job 结束，每 30 秒拉取一次资源消耗数据。
5. 拉取测试结果日志，其中包含了延迟指标。
6. 删除敷在生成 Job 以及 emojivoto。
7. 删除服务网格。
8. 回到第一步，测试下一个服务网格（顺序为：Linkerd->Istio->Bare）。
9. 在所有的 4 个测试结束之后，再运行第二次，以满足统计需要。

重现性

w我们使用的是 Kinvolk 最近发布的 Kubernetes 发行版：Lokomotive。用于集群部署以及用于测试的代码都是开源的，保存在 Github 上。允许重新进行测试，也希望能够从其它用户那里得到改进。

测试的运行和观测

我们在 bare（无服务网格）、istio-stock（无微调）、istio-tuned 以及 Linkerd 上，用 500 的 RPS 运行 30 分钟。在两个集群上各运行两次，每种数据就有了 4 个样本。测试集群分布在两个不同地理区域的不同的数据中心，一个是 Packet 的 Sunnyvale 数据中心，另一个是纽约的 Parsippany 数据中心。

服务网格的版本

Istio：stock 和 tuned

我们用 Istio 1.1.6 运行这一测试，stock 运行的是根据安装文档进行部署的版本，tuned 版本则移除了内存限制，禁用了部分 Istio 组件，执行了不少推荐的微调。尤其是我们禁用了 Mixer、Policy、Tracing、Gateways 以及 Prometheus。

Linkerd

我们使用的是 Linkerd 的 Linkerd2-edge-19.5.2。我们使用的是 Linkerd 的标准配置，没有进行任何调整。

测试服务网格的上限

在使用稳定吞吐量开始长期运行之前，我们用一个较短的测试来确定服务网格吞吐量和延迟的范围。我们的目标是找到一个负载点，在这个点上，网格还能够用可接受的性能来处理流量。

为了我们的测试，我们运行了 30 个 Emojivoto 应用，也就是 90 个微服务，平均下来每个节点有 7.5 个应用 22 个微服务。我们用多个 RPS 各运行 10 分钟，来确定前面所说的负载点。

测试运行时间

我们最有兴趣的是尾部的百分位，因此测试的运行时间就很有影响了。越长的运行时间，在 99.9999 百分位和 100 百分位上的延迟就会越高。为了模拟用户涌入造成的高峰、以及新计算资源加入后的恢复，我们决定了 30 分钟的运行时间。注意，我们认为在多数环境里，尤其是自动伸缩的环境中，新资源的加入周期应该远低于 30 分钟；我们还认为，一个健壮的应用环境中，30 分钟足以应对扩容方面的意外。

第一次测试：500 RPS，30 分钟

这次测试运行超过 30 分钟，500 RPS。

延迟分布

我们在对数中观察到裸金属案例运行中，出现了很大的错误——可能是 Packet 的问题。这个情况在 99.9 和 99.999 上尤其明显，然而其他的数据点还是证明了整体趋势。我们看到 Linkerd 在这方面是胜出的，Istio 的缺省配置和微调配置相差不大，接下来看看资源消耗。

内存和 CPU

我们在 4 个独立测试运行的过程中，测量了内存分配和 CPU 使用率，在这 4 个样本中，使用了中位数以及最高最低值。Linkerd 控制平面内存消耗的异常点是由 linkerd-prometheus 容器造成的，它消耗了 Linkerd 平面其他组件内存的两倍。

而 Istio 中，我们看到了几次控制平面容器（Pilot 及其代理）消失的情况。我们不明白其中的原因，也没有深究，也没有把消失的容器计入结果。

第二次测试：600 RPS，30 分钟

这次测试运行超过 30 分钟，600 RPS。

延迟分布

我们再次观测到了裸金属测试中的抖动；然而其影响比 500 RPS 的时候更小。我们逼近了 Linkerd 的可接受响应时间的上限，在 100 百分位上的是 3 秒钟的延迟。

Istio 轻松的把延迟时间推到了分钟级（别忘了 Y 轴是对数），我们还看到了大量的 Socket/HTTP 错误，占了大概 1%-5.2%，中位数在 3.6%。我们要指出，Istio 的 RPS 承受范围在 565 和 571 之间，中位数是 568。Istio 在本次测试中没能达到 600 RPS。

上图的对比不太公平——我们看到的是 Linkerd 在 600 RPS 时候的表现，而 Istio 的是 570 RPS——但我们还是看得出，Istio 这里的资源需求。我们再次观察到 Istio 容器消失的情况，同样做了忽略处理。

结论

与裸金属相比，在常规条件下，Linkerd 和 Istio 的开销都算是可以接受的。当进入高负载状态时，相对于 Istio，Linkerd 能够提供更高的 RPS，并且使用更少的资源。

下一步

基于上面测试的观察，我们认为我们建立了一个良好的测试基础。未来的测试会进行更多的尝试，包括增强现有的测试，以及扩展测试场景。

我们认为把负载生成器限制在一个 Pod 中是一个最大的限制。这限制了负载的生成能力。如果突破了这一限制，我们就有能力进行更多样的测试方法。然而在多个 Pod 中并列运行，又带来了结果合并的问题。

后记

以下内容纯属个人胡言乱语

也不知道为啥，连续冒出几个性能测试来，与性能相比，更重要的是靠谱和有用好吗。Istio 还是 Linkerd，能长点心么。

参考资料

https://linkerd.io/2019/05/18/linkerd-benchmarks/

全面易用的镜像漏洞检测工具：Trivy

Fri, 17 May 2019 20:36:33 +0800

道路千万条，安全第一条；镜像不规范，同事两行泪。

Trivy 是一个面向镜像的漏洞检测工具，具备如下特点：

开源
免费
易用
准确度高
CI 友好

相对于老前辈 Clair，Trivy 的使用非常直观方便，适用于更多的场景。

下面是官方出具的对比表格：

扫描器	操作系统	依赖检测	适用性	准确度	CI 友好
Trivy	◯	◯	◯	◎	◯
Clair	◯	×	△	◯	△
Anchore Engine	◯	△	△	◯	△
Quay	◯	×	◯	◯	×
MicroScanner	◯	×	◯	△	◯
Docker Hub	◯	×	◯	×	×
GCR	◯	×	◯	◯	×

另外还提供了精确度的对比表格，但是追究下来，无非是采用的参考数据的差异。至少这并不是我看重的东西，顺手是第一要务。

安装

MacOS

$ brew tap knqyf263/trivy
$ brew install knqyf263/trivy/trivy

RHEL/CentOS

$ sudo vim /etc/yum.repos.d/trivy.repo
[trivy]
name=Trivy repository
baseurl=https://knqyf263.github.io/trivy-repo/rpm/releases/$releasever/$basearch/
gpgcheck=0
enabled=1
$ sudo yum -y update
$ sudo yum -y install trivy

使用

这个工具的最大闪光点就是提供了很多适合用在自动化场景的用法。

扫描镜像：

$ trivy centos

扫描镜像文件

$ docker save ruby:2.3.0-alpine3.9 -o ruby-2.3.0.tar
$ trivy --input ruby-2.3.0.tar

根据严重程度进行过滤

$ trivy --severity HIGH,CRITICAL ruby:2.3.0

忽略未修复问题

$ trivy --ignore-unfixed ruby:2.3.0

忽略特定问题

使用 .trivyignore：

$ cat .trivyignore
# Accept the risk
CVE-2018-14618

# No impact in our settings
CVE-2019-1543

$ trivy python:3.4-alpine3.9

使用 JSON 输出结果

$ trivy -f json dustise/translat-chatbot:20190428-5

定义返回值

$ trivy --exit-code 0 --severity MEDIUM,HIGH ruby:2.3.0
$ trivy --exit-code 1 --severity CRITICAL ruby:2.3.0

总结

相对于其它同类工具，Trivy 非常适合自动化操作，从 CircleCI 之类的公有服务，到企业内部使用的 Jenkins、Gitlab 等私有工具，或者作为开发运维人员的自测环节，都有 Trivy 的用武之地。

参考链接

https://github.com/aquasecurity/trivy

Rook & Ceph 简介

Fri, 17 May 2019 09:38:33 +0800

原文：The Ultimate Rook and Ceph Survival Guide

在容器世界中，无状态是一个核心原则，然而我们始终需要保存数据，并提供给他人进行访问。所以就需要一个方案用于保持数据，以备重启之需。

在 Kubernetes 中，PVC 是管理有状态应用的一个推荐方案。有了 PVC 的帮助，Pod 可以申请并连接到存储卷，这些存储卷在 Pod 生命周期结束之后，还能独立存在。

PVC 在存储方面让开发和运维的职责得以分离。运维人员负责供应存储，而开发人员则可以在不知后端细节的情况下，申请使用这些存储卷。

PVC 由一系列组件构成：

PVC：是 Pod 对存储的请求。PVC 会被 Pod 动态加载成为一个存储卷。

PV，可以由运维手工分配，也可以使用 StorageClass 动态分配。PV 受 Kubernetes 管理，但并不与特定的 Pod 直接绑定。

StorageClass：由管理员创建，可以用来动态的创建存储卷和 PV。

物理存储：实际连接和加载的存储卷。

分布式存储系统是一个有效的解决有状态工作负载高可用问题的方案。Ceph 就是一个分布式存储系统，近年来其影响主键扩大。Rook 是一个编排器，能够支持包括 Ceph 在内的多种存储方案。Rook 简化了 Ceph 在 Kubernetes 集群中的部署过程。

在生产环境中使用 Rook + Ceph 组合的用户正在日益增加，尤其是自建数据中心的用户，CENGN、Gini、GPR 等很多组织都在进行评估。

Ceph 是什么

Ceph 是一个分布式存储系统，具备大规模、高性能、无单点失败的特点。Ceph 是一个软件定义的系统，也就是说他可以运行在任何符合其要求的硬件之上。

Ceph 包括多个组件：

Ceph Monitors(MON)：负责生成集群票选机制。所有的集群节点都会向 Mon 进行汇报，并在每次状态变更时进行共享信息。

Ceph Object Store Devices(OSD)：负责在本地文件系统保存对象，并通过网络提供访问。通常 OSD 守护进程会绑定在集群的一个物理盘上，Ceph 客户端直接和 OSD 打交道。

Ceph Manager(MGR)：提供额外的监控和界面给外部的监管系统使用。

Reliable Autonomic Distributed Object Stores：Ceph 存储集群的核心。这一层用于为存储数据提供一致性保障，执行数据复制、故障检测以及恢复等任务。

为了在 Ceph 上进行读写，客户端首先要联系 MON，获取最新的集群地图，其中包含了集群拓扑以及数据存储位置的信息。Ceph 客户端使用集群地图来获知需要交互的 OSD，从而和特定 OSD 建立联系。

Rook 是什么

Rook 是一个可以提供 Ceph 集群管理能力的 Operator。Rook 使用 CRD 一个控制器来对 Ceph 之类的资源进行部署和管理。

Rook 包含多个组件：

Rook Operator：Rook 的核心组件，Rook Operator 是一个简单的容器，自动启动存储集群，并监控存储守护进程，来确保存储集群的健康。

Rook Agent：在每个存储节点上运行，并配置一个 FlexVolume 插件，和 Kubernetes 的存储卷控制框架进行集成。Agent 处理所有的存储操作，例如挂接网络存储设备、在主机上加载存储卷以及格式化文件系统等。

Rook Discovers：检测挂接到存储节点上的存储设备。

Rook 还会用 Kubernetes Pod 的形式，部署 Ceph 的 MON、OSD 以及 MGR 守护进程。

Rook Operator 让用户可以通过 CRD 的是用来创建和管理存储集群。每种资源都定义了自己的 CRD.

Rook Cluster：提供了对存储机群的配置能力，用来提供块存储、对象存储以及共享文件系统。每个集群都有多个 Pool。

Pool：为块存储提供支持。Pool 也是给文件和对象存储提供内部支持。

Object Store：用 S3 兼容接口开放存储服务。

File System：为多个 Kubernetes Pod 提供共享存储。

在 Kubernetes 上部署 Rook

下面我们会在 Kubernetes 上分步骤部署 Rook，并在同一集群中作为客户端来使用其存储服务。Ceph 需要额外的驱动来保存数据，因此建议提供一组独立的存储节点。

准备工作

Helm
Kubernetes（启用 RBAC）

磁盘配置

这里假设在存储节点上配有未格式化的磁盘。为了提供最佳性能，你可能需要在单独的设备上启用 WAL（本文就不深入讨论了）。

配置 FlexVolume（如果需要）

Rook agent 使用 FlexVolume 来和 Kubernetes 进行集成，从而进行存储操作。为了达成这一目标，Rook agent 要在每个节点部署 Rook FlexVolume。

在一些情况下，FlexVolume 的缺省目录是只读的，例如 Rancher 和 CoreOS。在这种情况下就需要配置 Kubelet 使用不同的可写入的目录了。

如果使用的是 Rancher Kubernetes Engine（RKE），可以用下面的方式配置 kubelet，然后使用 rke up 应用配置。

kubelet:
  image: ""
  extra_args:
    volume-plugin-dir: /usr/libexec/kubernetes/kubelet-plugins/volume/exec
  extra_binds:
    - /usr/libexec/kubernetes/kubelet-plugins/volume/exec:/usr/libexec/kubernetes/kubelet-plugins/volume/exec

安装 Rook Operator

在 Helm 中加入 Rook Charts。

helm repo add rook-stable https://charts.rook.io/stable

安装 Rook Operator（当前版本为 v0.9.3）

helm install --name rook --namespace rook-ceph-system rook-stable/rook-ceph

$ kubectl get po -n rook-ceph-system -o wide
NAME                                  READY   STATUS    RESTARTS   AGE   IP              NODE                      NOMINATED NODE
rook-ceph-agent-gwl8s                 1/1     Running   0          35d   10.212.144.51   coo-r1-k8s-worker-st-01
rook-ceph-agent-lqkjl                 1/1     Running   0          35d   10.212.144.52   coo-r1-k8s-worker-st-02
rook-ceph-agent-x66sw                 1/1     Running   0          35d   10.212.144.53   coo-r1-k8s-worker-st-03
rook-ceph-operator-7d44ddfdcb-q5chh   1/1     Running   0          35d   10.244.8.3      coo-r1-k8s-worker-st-03
rook-discover-fmqrd                   1/1     Running   0          35d   10.244.7.5      coo-r1-k8s-worker-st-01
rook-discover-jlsv9                   1/1     Running   0          35d   10.244.6.3      coo-r1-k8s-worker-st-02
rook-discover-vt7mk                   1/1     Running   0          35d   10.244.8.4      coo-r1-k8s-worker-st-03

Helm 会部署 Rook 的相关 Pod（rook-operator、rook-discover 以及 rook-agent），以及相关的 CRD。Discover Pod 会运行一个发现脚本，来查找挂接到 Kubernetes 存储节点上的本地存储设备。

请注意，rook-ceph-system 中的所有 Pod 都应该是 Running 或者 Completed 状态，不应存在 restarts 或 error 的情况。

创建受 Root 管理的 Ceph 集群

下一步就是创建 Ceph 集群。在 rook 源码中找到 cluster/examples/kubernetes/ceph/cluster.yaml，进行查看和修改。集群 CRD 中定义了存储集群的内容。下面的命令就能够启动一个 Rook 集群：

kubectl create -f cluster.yaml

要确认我们的 Rook 集群的工作状况，可以检查一下 rook-ceph 命名空间中的 Pod 运行情况：

$ kubectl get po -n rook-ceph -o wide
NAME                                                  READY   STATUS      RESTARTS   AGE   IP              NODE                      NOMINATED NODE
rook-ceph-mgr-a-bf78cdcb8-q4gpz                       1/1     Running     0          35d   10.244.7.7      coo-r1-k8s-worker-st-01
rook-ceph-mon-a-755d985488-72kzh                      1/1     Running     0          35d   10.244.7.6      coo-r1-k8s-worker-st-01
rook-ceph-mon-b-845c97f94b-h5jlp                      1/1     Running     0          35d   10.244.6.4      coo-r1-k8s-worker-st-02
rook-ceph-mon-c-68b495d97d-m524q                      1/1     Running     0          35d   10.244.8.7      coo-r1-k8s-worker-st-03
rook-ceph-osd-0-56b7b86b5b-kz882                      1/1     Running     0          35d   10.244.7.9      coo-r1-k8s-worker-st-01
rook-ceph-osd-1-6d9558b6bd-xlkzf                      1/1     Running     0          35d   10.244.6.6      coo-r1-k8s-worker-st-02
rook-ceph-osd-2-56bf4b6c64-2p9rp                      1/1     Running     0          35d   10.244.8.9      coo-r1-k8s-worker-st-03
rook-ceph-osd-3-86ccf5d69f-xzjmz                      1/1     Running     0          35d   10.244.7.10     coo-r1-k8s-worker-st-01
rook-ceph-osd-4-6f469fc877-bt799                      1/1     Running     0          35d   10.244.6.7      coo-r1-k8s-worker-st-02
rook-ceph-osd-5-6549cdf949-qbvnh                      1/1     Running     0          35d   10.244.7.11     coo-r1-k8s-worker-st-01
rook-ceph-osd-6-7f56d8cf95-qgd8p                      1/1     Running     0          35d   10.244.6.8      coo-r1-k8s-worker-st-02
rook-ceph-osd-7-55b6c5c8df-dnp4p                      1/1     Running     0          35d   10.244.8.11     coo-r1-k8s-worker-st-03
rook-ceph-osd-8-d6df7694-w2psw                        1/1     Running     0          35d   10.244.8.10     coo-r1-k8s-worker-st-03
rook-ceph-osd-prepare-coo-r1-k8s-worker-st-01-zbs6m   0/2     Completed   0          35d   10.244.7.8      coo-r1-k8s-worker-st-01
rook-ceph-osd-prepare-coo-r1-k8s-worker-st-02-sr2dm   0/2     Completed   0          35d   10.244.6.5      coo-r1-k8s-worker-st-02
rook-ceph-osd-prepare-coo-r1-k8s-worker-st-03-zzqmq   0/2     Completed   0          35d   10.244.8.8      coo-r1-k8s-worker-st-03
rook-ceph-tools-cb5655595-vq4vj                       1/1     Running     0          35d   10.212.144.53   coo-r1-k8s-worker-st-03

可以看到 mon、osd-prepare 已经部署。rook-ceph-osd-prepare 格式化了磁盘，准备了 OSD，并把 osd Pod 加入了集群。

Rook 还提供了一个 toolkit 容器，其中包含了全套的 Ceph 客户端，用于测试和排错，运行下列命令即可安装：

kubectl create -f toolkit.yaml

进入工具 Pod，就可以执行下面的内容了。

集群配置

设置 Ceph 组件的资源：

mgr:
    limits:
        cpu: "500m"
        memory: "1024Mi"
    requests:
        cpu: "500m"
        memory: "1024Mi"
mon:
    limits:
        cpu: "1"
        memory: "1024Mi"
    requests:
        cpu: "500m"
        memory: "1024Mi"
osd:
    limits:
        cpu: "1"
        memory: "2048Mi"
    requests:
        cpu: "500m"
        memory: "1024Mi"

建议尽量为所有存储节点分配同样的 CPU、内存和磁盘。这样就可以使用 deviceFilter 了：

storage:
  useAllNodes: true
  useAllDevices: false
  deviceFilter: sd[a-z]

这里使用正则表达式 /dev/sd[a-z] 进行设备匹配。

创建 Ceph 副本池以及 Kubernetes StorageClass

可以用 CRD 来定义 Pool。Rook 提供了两种机制来维持 OSD：

副本：缺省选项，每个对象都会根据 spec.replicated.size 在多个磁盘上进行复制。建议非生产环境至少 2 个副本，生产环境至少 3 个。

Erasure Code：是一种较为节约的方式。EC 把数据拆分 n 段（spec.erasureCoded.dataChunks），再加入 k 个代码段（spec.erasureCoded.codingChunks），用分布的方式把 n+k 段数据保存在磁盘上。这种情况下 Ceph 能够隔离 k 个 OSD 的损失。

# pool with replication enabled
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: replicated-metadata-pool
  namespace: rook-ceph
spec:
  replicated:
    size: 2
---
# pool with EC enabled
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: ec-data-pool
  namespace: rook-ceph
spec:
  erasureCoded:
    dataChunks: 2
    codingChunks: 1

本文中使用副本的方式来保证数据冗余。

Kubernetes 环境里，StorageClass 是动态存储配置的核心。下面的例子定义了一个 Ceph 块存储的 StorageClass：


apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: rook-ceph-block
provisioner: ceph.rook.io/block
parameters:
  # The replicated pool as the `blockPool` parameter
  blockPool: replicated-metadata-pool
  # The erasure coded pool must be set as the `dataBlockPool` parameter below.
  dataBlockPool: ec-data-pool
  clusterNamespace: rook-ceph

使用 kubectl 提交 storageclass.yaml 以及 cluster.yaml，就完成了 Ceph 副本和 StorageClass 的创建。

测试

使用上面创建的 StorageClass，新建一个 PVC，就可以完成测试了：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: wordpress
spec:
  storageClassName: rook-ceph-block
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

检查新建的 PVC，看状态是不是会变成 Bounded：

$ kubectl get pvc
NAMESPACE       NAME                                     STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
default   mysql-pv-claim                                 Bound     pvc-f1af6df6-474a-11e9-8360-02006e76001e   8Gi        RWO            rook-ceph-block   1m

Ceph 常用命令

在工具箱 Pod 中，可以使用命令和 Ceph 集群进行交互。下面是一个例子。

查看集群状态

$ ceph status
  cluster:
    id:     62e69dc1-efb5-42d9-a7bc-1ea6cfbd467f
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum c,a,b
    mgr: a(active)
    osd: 9 osds: 9 up, 9 in

  data:
    pools:   1 pools, 100 pgs
    objects: 236  objects, 406 MiB
    usage:   10 GiB used, 1.7 TiB / 1.8 TiB avail
    pgs:     100 active+clean

  io:
    client:   38 KiB/s wr, 0 op/s rd, 3 op/s wr

健康情况

用来查看是否有物理损坏。

$ ceph health detail
HEALTH_OK

所有 OSD 的状态

$ ceph osd status
+----+-------------------------+-------+-------+--------+---------+--------+---------+-----------+
| id |           host          |  used | avail | wr ops | wr data | rd ops | rd data |   state   |
+----+-------------------------+-------+-------+--------+---------+--------+---------+-----------+
| 0  | coo-r1-k8s-worker-st-01 | 1149M |  198G |    0   |  13.6k  |    0   |     0   | exists,up |
| 1  | coo-r1-k8s-worker-st-02 | 1157M |  198G |    0   |     0   |    0   |     0   | exists,up |
| 2  | coo-r1-k8s-worker-st-03 | 1143M |  198G |    0   |     0   |    0   |     0   | exists,up |
| 3  | coo-r1-k8s-worker-st-01 | 1128M |  198G |    0   |     0   |    0   |     0   | exists,up |
| 4  | coo-r1-k8s-worker-st-02 | 1180M |  198G |    4   |  37.6k  |    0   |     0   | exists,up |
| 5  | coo-r1-k8s-worker-st-01 | 1169M |  198G |    1   |  12.0k  |    0   |     0   | exists,up |
| 6  | coo-r1-k8s-worker-st-02 | 1109M |  198G |    0   |     0   |    0   |     0   | exists,up |
| 7  | coo-r1-k8s-worker-st-03 | 1160M |  198G |    0   |  1638   |    0   |     0   | exists,up |
| 8  | coo-r1-k8s-worker-st-03 | 1143M |  198G |    0   |  3276   |    0   |     0   | exists,up |
+----+-------------------------+-------+-------+--------+---------+--------+---------+-----------+

Ceph Pool 详情

$ ceph osd pool ls detail
pool 1 'replicapool' replicated size 3 min_size 1 crush_rule 1 object_hash rjenkins pg_num 100 pgp_num 100 last_change 37 flags hashpspool,selfmanaged_snaps stripe_width 0 application rbd
removed_snaps [1~3]

显示 Pool 和总体用量

$ rados df
POOL_NAME      USED OBJECTS CLONES COPIES MISSING_ON_PRIMARY UNFOUND DEGRADED RD_OPS      RD  WR_OPS     WR
replicapool 1.4 GiB     575      0   1150                  0       0        0   1224 2.4 MiB 1698291 84 GiB

total_objects    575
total_used       5.6 GiB
total_avail      294 GiB
total_space      300 GiB

重新安装

包括 RKE 的完全重新部署

下面的步骤会擦除数据，不建议在生产集群上使用。

Rook 有很多数据保存在本地存储节点，重新部署比较困难。如果使用的是 RKE，在 Worker 和 Master 节点上清除数据，然后重新安装 RKE。

删除所有 Docker、Rook 和 RKE 及其相关组件：

# remove rke docker and everything
sudo apt -y purge docker-ce \
&& sudo apt -y autoremove \
&& sudo rm -rf /var/lib/docker \
&& sudo rm -rf /opt/* \
&& sudo rm -rf /var/lib/rook \
&& sudo rm -rf /var/lib/etcd \
&& sudo rm -rf /var/lib/cni \
&& sudo rm -rf /var/lib/containerd \
&& sudo rm -rf /var/lib/calico \
&& sudo rm -rf /var/lib/kubelet \
&& sudo rm -rf /var/lib/rancher

如果是一个运行中的服务器，完成这一命令之后建议重新启动，然后重复执行一次，最后再重新安装（包括 Docker）。

还需要格式化 Rook/Ceph 使用的磁盘。

$ sudo fdisk /dev/sdb
Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device /dev/sdb already contains a LVM2_member signature.
The signature will be removed by a write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0xa24124a7.

Command (m for help):

简单的输入 w，然后回车，就会覆盖分区表，让磁盘恢复可用。这一动作完成之后也建议重新启动。

只重装 Rook

删除 rook-ceph 以及 rook-ceph-system 命名空间会造成很大麻烦。要关停 Ceph 集群：

删除 Rook 集群的相关资源（Pool、StorageClass、PVC 等等）

kubectl delete -n rook-ceph cephblockpool replicapool kubectl delete storageclass rook-ceph-block
删除 cluster CRD 和 Helm release

kubectl -n rook-ceph patch clusters.ceph.rook.io rook-ceph -p ‘{“metadata”:{“finalizers”: []}}’ –type=merge kubectl -n rook-ceph delete cephcluster rook-ceph helm delete –purge rook kubectl delete namespace rook-ceph
连接到每个节点上删除 /var/lib/rook 或者 dataDirHostPath 指定的路径。

如果出现任何问题，可以参考 Trouble shooting 页面

检测

Physical Group 修复

Ceph 偶尔会报告 Physical Group 需要修复，可以在工具箱 Pod 中完成：

$ ceph health detail
HEALTH_ERR
1 pgs inconsistent; 2 scrub errors
pg 0.6 is active+clean+inconsistent, acting [0,1,2] 2 scrub errors

上面的输出说明需要进行修复，执行下列命令：

ceph pg repair 0.6

这个命令会启动一个修复过程，几分钟之后，会恢复到 HEALTH_OK 状态。

修改副本数量

如果副本数量设置有误，可以在运行中的副本池中修改设置，在工具箱 Pod 中执行：

ceph osd pool set replicapool size 3
ceph osd pool set replicapool min_size 3

修改 PG 数量

要修改副本池中的 PG 数，可以使用：

ceph osd pool set replicapool pg_num 256
ceph osd pool set replicapool pgp_num 256

参考

用 Sidecar 应用 Configmap 更新

Thu, 16 May 2019 01:52:01 +0800

在 Kubernetes 的使用过程中，很多人会使用 Configmap 资源来进行配置文件的加载。Configmap 对象是支持热更新的，也就是说，对 Configmap 的变更，会同时反应到加载该 Configmap 的 Pod 之中。但美中不足的是，很多应用都不会检测配置文件的更新，因此就算是通过对 Configmap 的变更，完成了配置文件的修改，应用还是无法做出即时的响应的。可以在外部进行滚动更新；或者改写业务容器，监控文件变化之后重新启动业务进程。

在 Kubernetes 1.10 中新增的 Pod 内共享进程命名空间的功能，给这个问题带来了一点新思路：做一个 Sidecar 用于对配置文件进行监控，发现文件变化之后，发送重新载入的信号给业务进程，要求业务进程自行刷新。这样就无需对业务容器所在镜像进行修改了。

这种方法当然也有个局限性，需要业务进程支持这种信号。

下面以 Apache 为例，看看这种方式的用法。

创建 Configmap

用一个简化的 httpd.conf 文件，生成 Configmap，例如：

kubectl create cm apache --from-file httpd.conf

如此就生成了一个名为 apache 的 Configmap。

创建 Sidecar 容器镜像

这个镜像要完成的任务有两个：监控文件变化，如果内容变化，则发送信号给业务进程。文件内容变化的监控，可以用哈希码或者 inotify 调用来完成，这里使用 inotifywait 命令做一个死循环，发现特定事件后，则发出信号：

#!/bin/sh
while :
do
  # 获取文件名称
  REAL=`readlink -f ${FILE}`
  # 监控指定事件
  inotifywait -e delete_self "${REAL}"
  # 获取特定进程名称的 PID
  PID=`pgrep ${PROCESS} | head -1`
  # 发送信号
  kill "-${SIGNAL}" "${PID}"
done

这里没有用监控本地文件的 -m 或者 -e modify 事件，而是用了 delete_self，这是 Configmap 加载生成文件的差异，也可以考虑用环境变量来替换这一事件。

然后构建镜像：

FROM alpine
RUN apk add --update inotify-tools
ENV FILE="/tmp" PROCESS="httpd" SIGNAL="USR1"
COPY entry.sh /usr/local/bin
CMD ["/usr/local/bin/entry.sh"]

这里假设镜像名称为 dustise/inotify:latest。

创建实验负载

我们选择 Apache 作为业务应用的示范，它能够接受 USR1 信号进行重新载入。

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: apache
spec:
  selector:
    matchLabels:
      app: apache
  template:
    metadata:
      labels:
        app: apache
    spec:
      shareProcessNamespace: true
      containers:
      - name: apache
        image: httpd:alpine
        ports:
        - containerPort: 80
        volumeMounts:
          - name: apache
            mountPath: /usr/local/apache2/conf/
      - name: refresh
        image: dustise/inotify
        securityContext:
          capabilities:
            add:
            - SYS_PTRACE
        volumeMounts:
          - name: apache
            mountPath: /etc/httpd
        env:
          - name: FILE
            value: "/etc/httpd/httpd.conf"
          - name: PROCESS
            value: "httpd"
          - name: SIGNAL
            value: "USR1"
      volumes:
        - name: apache
          configMap:
            name: apache
---
apiVersion: v1
kind: Service
...
  type: ClusterIP

这段代码：

在 template.spec 中加入了 shareProcessNamespace: true，表示启用进行命名空间共享功能；
新建了一个伴行的 Sidecar 容器；
Apache 和 Sidecar 共享来自同一个 Configmap 的配置文件，根据加载情况为 Sidecar 定义了环境变量。

测试一下

接下来可以使用 kubectl logs 命令来监控两个容器的日志输出：

$ kubectl logs -f apache-6b8b68c857-dp6xx -c refresh
Setting up watches.
Watches established.

$ kubectl logs -f apache-6b8b68c857-dp6xx -c apache
...
[Wed May 15 18:46:47.795261 2019] [mpm_event:notice] [pid 7:tid 139810635549544] AH00489: Apache/2.4.39 (Unix) configured -- resuming normal operations
[Wed May 15 18:46:47.795330 2019] [core:notice] [pid 7:tid 139810635549544] AH00094: Command line: 'httpd -D FOREGROUND'

然后使用 kubectl edit cm apache，修改配置文件（例如删除点注释）。稍候片刻，发现两个容器的输出都发生了变化：

Sidecar

/etc/httpd/..2019_05_15_18_43_33.773288813/httpd.conf DELETE_SELF
Setting up watches.
Watches established.

脚本检测到了配置文件发生了删除事件，发送信号，并重新启动监控。

Apache

[Wed May 15 18:46:47.775392 2019] [mpm_event:notice] [pid 7:tid 139810635549544] AH00493: SIGUSR1 received.  Doing graceful restart

Apache 收到了 USR1 信号，进行了优雅重启。

结论

对于支持信号控制的第软件，例如 Nginx、Gunicorn、HA-Proxy 等都可以使用这种方式来完成配置刷新工作。能够有效的避免重启或修改业务应用的老大难问题。

Kubernetes 4 序章及目录

Wed, 15 May 2019 14:04:03 +0800

PDF 下载

Kubernetes 存储性能对比

Mon, 13 May 2019 23:10:28 +0800

原文：Kubernetes Storage Performance Comparison

作者：Jakub Pavlík

如果你正在运行 Kubernetes，你可能正在使用，或者准备使用动态供给的块存储卷，而首当其冲的问题就是为集群选择合适的存储技术。这个事情并不能用一个简单的测试来做出简单的回答，告诉你目前市面上最好的技术是什么。存储技术的选择过程中，集群上运行的负载类型是一个重要的输入。对于裸金属集群来说，需要根据实际用例进行选择，并集成到自己的硬件之中。公有云中的托管 K8s，例如 AKS、EKS 或者 GKE，都具有开箱可用的块存储能力，然而这也不见得就是最好的选择。有很多因素需要考虑，比如说公有云的 StorageClass 的故障转移时间太长。例如在一个针对 AWS EBS 的故障测试中，加载了卷的 Pod 用了超过五分钟才成功的在另一个节点上启动。Portworx 或者 OpenEBS 这样的云原生存储产品，正在尝试解决这类问题。

本文的目标是使用最常见的 Kubernetes 存储方案，进行基本的性能对比。我觉得在 Azure AKS 上使用下列后端：

AKS 原生 Storageclass：Azure native premium
使用 cStor 后端的 OpenEBS
Portworx
Heketi 管理的 Gluster
Rook 管理的 Ceph

现在我们来介绍每种存储后端，并交代一下安装过程，然后进入 AKS 测试环境进行测试，最后得出结果。

存储

这一节中介绍测试中用到的存储方案，包含安装过程以及该方案的优缺点。

Azure 原生 StorageClass

我选择这一方案的动机是以此作为所有测试的基线。这个方案应该提供最佳性能。Azure 动态的创建托管磁盘，并把它们映射到 K8s 的虚拟机中，最终成为 Pod 的存储卷。

这个方案很方便，什么多余的步骤都不需要。创建一个新的 AKS 集群之后，就自动提供了两个预定义的 StorageClass，分别是 default 和 managed-premium，premium 使用的是基于 SSD 的高性能低延迟磁盘。

$ kubectl get storageclasses
NAME                PROVISIONER                AGE
default (default)   kubernetes.io/azure-disk   8m
managed-premium     kubernetes.io/azure-disk   8m

$ kubectl get pvc
NAME              STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
dbench-pv-claim   Bound     pvc-e7bd34a4-1dbd-11e9-8726-ae508476e8ad   1000Gi     RWO            managed-premium   10s

$ kubectl get po
NAME           READY     STATUS              RESTARTS   AGE
dbench-w7nqf   0/1       ContainerCreating   0          29s

优点

AKS 开箱即用。

缺点

故障转移非常缓慢，有时需要十分钟以后，存储卷才能重新挂载到不同节点上的 Pod 里。

OpenEBS

对我来说 OpenEBS 是个全新事物，因此我很有兴趣做他的测试。他提出了一个新的 Container Attached Storage（容器挂载存储）概念，这是一个基于微服务的存储控制器，以及多个基于微服务的存储副本。他和 Portworx 同样，属于云原生存储分类的成员。

它是一个完全开源的方案，目前提供两种后端——Jiva 和 cStor。我最开始选择的是 Jiva，后来切换到 cStor。cStor 有很多长处，例如他的控制器和副本被部署到单一的 OpenEBS 所在的命名空间之中，能够管理原始磁盘等。每个 K8s 卷都有自己的存储控制器，能在节点存储容量的许可范围内对存储进行扩展。

在 AKS 上运行

在 AKS 上的安装非常容易。

连接到所有 K8s 节点上，安装 iSCSI，这是因为他需要使用 iSCSI 协议在 K8s 节点之间进行 Pod 和控制器的连接。
```
apt-get update
apt install -y open-iscsi
```

使用一个 YAML 定义在 K8s 集群上完成部署：

kubectl apply -f https://openebs.github.io/charts/openebs-operator-0.8.0.yaml

下一步，OpenEBS 控制器发现了节点中的所有磁盘。但是我必须手工标识出我附加的 AWS 托管磁盘。

$ kubectl get disk
NAME                                      AGE
disk-184d99015253054c48c4aa3f17d137b1     5m
disk-2f6bced7ba9b2be230ca5138fd0b07f1     5m
disk-806d3e77dd2e38f188fdaf9c46020bdc     5m

然后把这些磁盘加入 StoragePoolClaim，这个对象会在 StorageClass 中进行引用：

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-custom
  annotations:
    openebs.io/cas-type: cstor
    cas.openebs.io/config: |
      - name: StoragePoolClaim
        value: "cstor-disk"
provisioner: openebs.io/provisioner-iscsi
---
apiVersion: openebs.io/v1alpha1
kind: StoragePoolClaim
metadata:
  name: cstor-disk
spec:
  name: cstor-disk
  type: disk
  maxPools: 3
  poolSpec:
    poolType: striped
  disks:
    diskList:
    - disk-2f6bced7ba9b2be230ca5138fd0b07f1
    - disk-806d3e77dd2e38f188fdaf9c46020bdc
    - disk-184d99015253054c48c4aa3f17d137b1

完成这些步骤之后，就可以用 K8s 的 PVC 来动态的创建存储卷了。

优点

开源
Maya 在资源使用的可视化方面做得非常好。可以在 K8s 中部署多个服务，方便的为集群的各方面数据设置监控和日志。对于排错工作来说，这十分重要。
CAS 概念：我非常欣赏这一概念，我相信这是未来的趋势。
OpenEBS 社区：在社区中我的任何问题都能在几分钟内得到解决。Slack 上的团队非常有帮助。

缺点

不成熟：OpenEBS 还很年轻，目前还没有发布稳定版。核心团队还在进行后端的优化，未来几个月里会对性能做出很大提升。
Kubelet 和存储控制器之间的 iSCSI 连接是通过 K8s Service 进行的，这在 Tungsten Fabric 之类的 CNI 插件环境中可能会出问题。
需要在 K8s 节点上安装额外的软件（iSCSI），这对于托管集群来说非常不便。

注：OpenEBS 团队对我的案例场景进行了调整：

https://github.com/kmova/openebs/tree/fio-perf-tests/k8s/demo/dbench

Portworx

Portworx 是另一个面向 Kubernetes 的容器原生存储方案，它专注于高度分布式的环境。这是一个主机可寻址的存储，每个卷都直接映射到挂在的主机上。他提供了基于应用 I/O 类型的自动微调能力。官方网站提供了更多信息。不幸的是，它也是本文中唯一的非开源产品。然而它提供了 3 节点的免费试用。

在 AKS 上运行

在 AKS 上的安装同样简单，我用了他们网站提供的生成器。

选择基于 Portworx 的 ETCD，指定 K8s 版本为 1.11.4。
因为我用了 Azure CNI，因此必须把数据网卡设置为 azure0。否则 Portworx 会使用 docker bridge 的 IP 地址，而非 VM 网卡。
最后网站会生成渲染完成的 YAML 文件。

提交后，会看到节点上运行的 Portworx Pod：

$ kubectl get pods -o wide -n kube-system -l name=portworx
NAME             READY     STATUS    RESTARTS   AGE       IP          NODE                       NOMINATED NODE
portworx-g9csq   1/1       Running   0          14m       10.0.1.66   aks-agentpool-20273348-2   <none>
portworx-nt2lq   1/1       Running   0          14m       10.0.1.4    aks-agentpool-20273348-0   <none>
portworx-wcjnx   1/1       Running   0          14m       10.0.1.35   aks-agentpool-20273348-1   <none>

为 PVC 创建一个 StorageClass，定义高优先级，以及三个副本：

root@aks-agentpool-20273348-0:~# kubectl get storageclass -o yaml portworx-sc
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  creationTimestamp: 2019-01-28T21:10:28Z
  name: portworx-sc
  resourceVersion: "55332"
  selfLink: /apis/storage.k8s.io/v1/storageclasses/portworx-sc
  uid: 23455e40-2341-11e9-bfcb-a23b1ec87092
parameters:
  priority_io: high
  repl: "3"
provisioner: kubernetes.io/portworx-volume
reclaimPolicy: Delete
volumeBindingMode: Immediate

优点

部署方便：生成器包含配置细节。
不像 Ceph 和 Glusterfs 那样需要进行额外配置。
云原生存储：公有云和裸金属都可以运行。
存储级别感知和应用感知的 I/O 微调。

缺点

闭源：商业解决方案

GlusterFS Heketi

GlusterFS 是知名的开源存储方案，是由 Redhat 提供的开源存储方案。Heketi 是 GlusterFS 的 RESTful 卷管理界面。它提供了易用的方式为 GlusterFS 卷提供了动态供给的功能。如果没有 Heketi 的辅助，就只能手工创建 GlusterFS 卷并映射到 K8s PV 了。关于 GlusterFS 的更多信息，请阅读官方文档。

在 AKS 上运行

根据 Heketi 的快速入门文档进行部署。

参照样例，创建一个包含磁盘和主机名的拓扑文件。

Heketi 主要的开发和测试都在基于 RHEL 的操作系统上，我在 AKS 上使用 Ubuntu 主机时，出现了内核模块路径错误的问题，我提交了一个 PR 来修正这个问题。

+++ b/deploy/kube-templates/glusterfs-daemonset.yaml
@@ -67,7 +67,7 @@ spec:
           mountPath: "/etc/ssl"
           readOnly: true
         - name: kernel-modules
-          mountPath: "/usr/lib/modules"
+          mountPath: "/lib/modules"
           readOnly: true
         securityContext:
           capabilities: {}
@@ -131,4 +131,4 @@ spec:
           path: "/etc/ssl"
       - name: kernel-modules
         hostPath:
-          path: "/usr/lib/modules"
+          path: "/lib/modules"

我在 AKS 环境中遇到的另一个问题是一个非空磁盘，所以我用 wipefs 为 glusterfs 进行清理。这个磁盘并未用过。

$ wipefs -a /dev/sdc /dev/sdc: 8 bytes were erased at offset 0x00000218 (LVM2_member): 4c 56 4d 32 20 30 30 31

最后运行 gk-deploy -g -t topology.json，会在每个节点上运行 Heketi 控制器管理之下的 GlusterFS Pod。

$ kubectl get po -o wide
NAME                     READY   STATUS    RESTARTS IP        NODE                       NOMINATED NODE
glusterfs-fgc8f          1/1     Running   0       10.0.1.35  aks-agentpool-20273348-1
glusterfs-g8ht6          1/1     Running   0       10.0.1.4   aks-agentpool-20273348-0
glusterfs-wpzzp          1/1     Running   0       10.0.1.66  aks-agentpool-20273348-2
heketi-86f98754c-n8qfb   1/1     Running   0       10.0.1.69  aks-agentpool-20273348-2

然后我遇到了新问题。K8s 控制面无法使用 Heketi 的 restURL。我测试了一下 kube dns 的记录，pod IP 和 svc IP 都没有生效。最后只能手工使用 Heketi CLI 来创建存储卷。

$ export HEKETI_CLI_SERVER=http://10.0.1.69:8080
$ heketi-cli volume create --size=10 --persistent-volume --persistent-volume-endpoint=heketi-storage-endpoints | kubectl create -f -
persistentvolume/glusterfs-efb3b155 created

$ kubectl get pv
NAME                 CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
glusterfs-efb3b155   10Gi       RWX            Retain           Available

然后把现存 PV 映射为 PVC，加载给测试工具进行测试。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: glusterfs-efb3b155
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: 10Gi
  volumeName: glusterfs-efb3b155

$ kubectl get pvc
NAME                 STATUS    VOLUME               CAPACITY   ACCESS MODES   STORAGECLASS   AGE
glusterfs-efb3b155   Bound     glusterfs-efb3b155   10Gi       RWX                           36m

Heketi 的更多输出：

$ gluster volume info vol_efb3b15529aa9aba889d7900f0ce9849

Volume Name: vol_efb3b15529aa9aba889d7900f0ce9849
Type: Replicate
Volume ID: 96fde36b-e389-4dbe-887b-baae32789436
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: 10.0.1.66:/var/lib/heketi/mounts/vg_5413895eade683e1ca035760c1e0ffd0/brick_cd7c419bc4f4ff38bbc100c6d7b93605/brick
Brick2: 10.0.1.35:/var/lib/heketi/mounts/vg_3277c6764dbce56b5a01426088901f6d/brick_6cbd74e9bed4758110c67cfe4d4edb53/brick
Brick3: 10.0.1.4:/var/lib/heketi/mounts/vg_29d6152eeafc57a707bef56f091afe44/brick_4856d63b721d794e7a4cbb4a6f048d96/brick
Options Reconfigured:
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off

$ kubectl get svc
NAME                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
heketi                     ClusterIP   192.168.101.75   <none>        8080/TCP   5h
heketi-storage-endpoints   ClusterIP   192.168.103.66   <none>        1/TCP      5h

$ kubectl get endpoints
NAME                       ENDPOINTS                            AGE
heketi                     10.0.1.69:8080                       5h
heketi-storage-endpoints   10.0.1.35:1,10.0.1.4:1,10.0.1.66:1   5h
kubernetes                 172.31.22.152:443                    1d
root@aks-agentpool-20273348-0:~# kubectl get endpoints heketi-storage-endpoints -o yaml
apiVersion: v1
kind: Endpoints
metadata:
  creationTimestamp: 2019-01-29T15:14:28Z
  name: heketi-storage-endpoints
  namespace: default
  resourceVersion: "142212"
  selfLink: /api/v1/namespaces/default/endpoints/heketi-storage-endpoints
  uid: 91f802eb-23d8-11e9-bfcb-a23b1ec87092
subsets:
- addresses:
  - ip: 10.0.1.35
  - ip: 10.0.1.4
  - ip: 10.0.1.66
  ports:
  - port: 1
    protocol: TCP

优点

久经考验的存储方案。
比 Ceph 轻量。

缺点

Heketi 在公有云上表现不佳。在私有云上表现良好，安装会方便一些。
并非为结构化数据设计，例如 SQL 数据库。然而可以使用 GlusterFS 为数据库提供备份和恢复支持。

Ceph Rook

我在 OpenStack 私有云上尝试过安装和运行 Ceph。它需要为特定硬件定制参数，根据数据类型设计 pg 组、SSD 分区和 CRUSH 图等。所以第一次听说在 3 节点的 K8s 集群上运行 Ceph 的时候，我不太相信它能工作。结果 Rook 的编排工具让我印象深刻，它把所有的步骤和 K8s 的编排能力结合在一起，让安装变得非常简便。

在 AKS 上运行

Rook 的缺省安装无需任何特定步骤，如果没什么高级配置，会非常简单。

我使用的是 Ceph 快速入门指南

为 AKS 配置 FLEXVOLUME_DIR_PATH，这是因为它需要 /etc/kubernetes/volumeplugins/，而不是 Ubuntu 中缺省的 /usr/libexec，没有这个步骤，Kubelet 就无法加载 PVC 了。

diff --git a/cluster/examples/kubernetes/ceph/operator.yaml b/cluster/examples/kubernetes/ceph/operator.yaml
index 73cde2e..33f45c8 100755
--- a/cluster/examples/kubernetes/ceph/operator.yaml
+++ b/cluster/examples/kubernetes/ceph/operator.yaml
@@ -431,8 +431,8 @@ spec:
         # - name: AGENT_MOUNT_SECURITY_MODE
         #   value: "Any"
         # Set the path where the Rook agent can find the flex volumes
-        # - name: FLEXVOLUME_DIR_PATH
-        #  value: "<PathToFlexVolumes>"
+        - name: FLEXVOLUME_DIR_PATH
+          value: "/etc/kubernetes/volumeplugins"
         # Set the path where kernel modules can be found
         # - name: LIB_MODULES_DIR_PATH
         #  value: "<PathToLibModules>"

还要在 deviceFilter 中指定要使用的设备，这里是 /dev/sdc。

diff --git a/cluster/examples/kubernetes/ceph/cluster.yaml b/cluster/examples/kubernetes/ceph/cluster.yaml
index 48cfeeb..0c91c48 100755
--- a/cluster/examples/kubernetes/ceph/cluster.yaml
+++ b/cluster/examples/kubernetes/ceph/cluster.yaml
@@ -227,7 +227,7 @@ spec:
   storage: # cluster level storage configuration and selection
     useAllNodes: true
     useAllDevices: false
-    deviceFilter:
+    deviceFilter: "^sdc"
     location:
     config:

安装之后，创建一个 Ceph block pool，以及 StorageClass，使用如下配置。

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: replicapool
  namespace: rook-ceph
spec:
  failureDomain: host
  replicated:
    size: 3
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: rook-ceph-block
provisioner: ceph.rook.io/block
parameters:
  blockPool: replicapool
  clusterNamespace: rook-ceph
  fstype: xfs
reclaimPolicy: Retain

最后使用部署工具进行检查。

ceph status
cluster:
id:     bee70a10-dce1-4725-9285-b9ec5d0c3a5e
health: HEALTH_OK

services:
mon: 3 daemons, quorum c,b,a
mgr: a(active)
osd: 3 osds: 3 up, 3 in

data:
pools:   0 pools, 0 pgs
objects: 0  objects, 0 B
usage:   3.0 GiB used, 3.0 TiB / 3.0 TiB avail
pgs:

[root@aks-agentpool-27654233-0 /]#
[root@aks-agentpool-27654233-0 /]#
[root@aks-agentpool-27654233-0 /]# ceph osd status
+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+
| id |           host           |  used | avail | wr ops | wr data | rd ops | rd data |   state   |
+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+
| 0  | aks-agentpool-27654233-0 | 1025M | 1021G |    0   |     0   |    0   |     0   | exists,up |
| 1  | aks-agentpool-27654233-1 | 1025M | 1021G |    0   |     0   |    0   |     0   | exists,up |
| 2  | aks-agentpool-27654233-2 | 1025M | 1021G |    0   |     0   |    0   |     0   | exists,up |
+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+

优点

在大型生产环境上的健壮存储系统。
Rook 很好的简化了生命周期管理。

缺点

复杂：更加重量级，也不太适合在公有云上运行。在私有云上的运行可能更加合适。

AKS 测试环境

我用 3 个虚拟机创建了基本的 Azure AKS 集群。为了连接到 Premium SSD 上，我只能使用 type E 以上级别的虚拟机。因此我选择了 Standard_E2s_v3，其上配备了 2 vCPU 以及 16GB 的内存。

在 AKS 集群所在的资源足中，可以看到所有的虚拟机、网络接口等资源。在这里创建 3 个 1TB 的 Premium SSD 存储，并手工挂载到每个虚拟机上。

这样在每个实例上，我都有 1TB 的空磁盘。Azure 的页面上，根据我们选择的虚拟机和磁盘尺寸来看，性能应该有 5000 IOPS 以及 200MB/s 的吞吐量。最后一节会显示我们的真实结果。

性能结果

注意：每种存储的结果并不能作为独立的评估结果，但是其比较情况是可以参考的。有很多种对比测试的方法，这是最简单的一种。

为了运行测试，我决定使用现成的测试工具 Dbench，它是一个 k8s 的 YAML 文件，会使用 FIO 运行 8 个测试用例。可以在 Dockerfile 中指定不同测试：

随机读写带宽。
随机读写 IOPS。
读写延迟。
顺序读写。
混合读写 IOPS。

所有测试的结果可以在 Github 上找到。

随机读写带宽

随机读写测试表明，GlusterFS、Ceph 以及 Portworx 的读取性能比 AWS 本地盘的 hostPath 快了几倍。读缓存是罪魁祸首。GlusterFS 和 Portworx 的写入更快，其效率直逼本地磁盘。

随机读写 IOPS

随机 IOPS 测试中，Portworx 和 Ceph 表现最好。Portworx 在写入方面获得了接近 Azure 原生 PVC 的 IOPS。

读写延迟

延迟测试的结果比较有趣，Azure 原生 PVC 比多数其它存储都差。Portworx 和 Ceph 表现最好。写入方面，GlusterFS 要优于 Ceph。OpenEBS 的延迟相对来说非常的高。

顺序读写

顺序读写的结果和前面的随机测试差不多，然而 Cpeh 在读取方面比 GlusterFS 快了一倍多。写入结果基本一致，只有 OpenEBS 表现奇差。

混合读写 IOPS

最后一个测试用例检查的是混合读写情况下的 IOPS，Portworx 和 Ceph 都给出了优于 Azure 原生 PVC 的结果。

结论

本文展示了一个简单的存储对比，使用未经性能优化的多种存储提供的存储卷进行测试和比较。建议关注本文所述方法，不建议直接采用结果进行判断。

忽略 Azure 的原生 PVC 或 hostPath，我们可以得出如下测试结果：

Portworx 是 AKS 上最快的容器存储。
Ceph 是私有云集群上最快的开源存储后端。对公有云来说，其操作太过复杂，这些多余的复杂性并没有能提供更好的测试表现。
OpenEBS 的概念很棒，但是其后端需要更多优化。

调整性能数据的测试规模应该会很有意思。另外值得关注的对比就是 CPU 和内存的消耗。我会持续关注，并分享更多。

土味微服务

Fri, 10 May 2019 13:06:50 +0800

前段时间有大佬邀请，参加了一个微服务方面的交流，期间大放厥词，回味起来意犹未尽，整理一稿出来，博诸君一哂。

扯一扯定义

单体应用（monolithic application）这个名词，是经常被拿出来和微服务做比较（吊打）的。知己知彼百战不殆，在说微服务之前，似乎蛮有必要了解一下这个老对手的情况。

按照 Google 程序员的常用抄袭手段，我在 Google 搜索 monolithic application，选一点结果摘录如下：

Wikipedia

In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.

Kodelabs

Monolith means composed all in one piece. The Monolithic application describes a single-tiered software application in which different components combined into a single program from a single platform.

根据上面的陈述，会发现很难对单体应用做出一个精准的判断，single program、single-tiered 放到真实世界中，除了单服务器、单进程的小网站之外，这种情况似乎很难看到。在面对几十几百台服务器的时候，我想大概没有架构师会有兴趣让几百台服务器都跑同一个 WAR 吧。

对手身份不太明确，那么会不会是个兔死狗烹呢？微服务的定义又是什么样的呢？下面是 Martin Folwer 给出的定义：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

小有多小，轻有多轻，全自动的范围有多大，去中心化到底有怎样的自治，似乎也都让人摸不到头脑。

虽说概念没有一清二楚，然而从上述的定义来看，微服务是对一些既有的观点进行了强调的：

以业务为中心
多技术栈共存
轻量协议互访
去中心化

据此，我对微服务这个风向的理解，是在传统软件的设计开发体系基础之上的一种变化，相对于翻天覆地的变革，我更愿称之为一种改良。

是谁坑了瀑布流程

人人喊打的瀑布流程，在我看来，面对的是一种类似读书时候经常提到的理想状况：

在理想状况中：

需求是清晰而持久的
基础设施都是稳定的
依赖服务都是靠得住的

过往的开发过程在这种理想状况中，是具备非常多的好处的：

单一的技术栈有利于人才招聘、培养以及技术积累。
少量的业务进程对发布、运维都有较小的压力，并且内部调用效率更高。
集中数据的好处更是车载斗量，安全、事务等方面有极大的优势。

然而世界发生了变化，廉价服务器包打天下，IT 人满坑满谷，业务日新月异，新技术层出不穷，用户漫山遍野，这一切因素叠加起来，都让以前重如千钧的需求变得相当轻浮。

结果现在越来越多的开发过程，变成了这样：

所有的环节，都随时面临变化的冲击：

既有需求尚未完成，已经产生变更。
设计开发过程受到新技术新方法的冲击。
测试标准、交付标准的变化。
运行环境升级和故障响应要求。

种种变化归结起来：

硬件和人力都变得廉价，变更频繁并且范围更大。

快速的变化除了产生需求之外，还让黏连在一起的大进程难于适应：

不同业务之间的信任关系会发生变化。
共享数据容易污染。
多小的代码变更，都可能引发大量的测试和上线动作。
特定业务场景无法使用最优技术栈进行实现。
必须同步进行缩放。

除了上述的外部因素之外，开发团队和交付物自身其实也同样的不理想：

牵一发而动全身的共享代码库。
不严格的组件边界，可能导致不同业务互相干扰。

应对思路也顺理成章：

越长的流程越容易被变化击中，换句话说，越短的流程越容易完成。
缩短的流程，决定了交付物体积缩小，但是并行开发的需求大增。
并行开发的过程，要求有多团队协同工作。
多团队的结果就会导致扩展技术栈、去中心化的要求。

更小的交付物，和更便宜的服务器勾搭起来，产生了大量运行小进程的廉价服务器，自然也就催生了“民用”的分布式计算。

如此一来，各种集群、各层协议、各种分布式框架就成了刚需，产生了空前发展。

从“集中力量干大事”，到“各村有各村的高招”，这种变化自然是为了满足客户需要。

没有 Silver Bullshit

按照前面提到的思路，我们：

把进程内的组件拆成独立服务。
独立的服务运行各自的进程。
原有的进程内调用变成了网络调用。
各个服务可能采用不同的技术栈来实现。
每个服务独占存储自己的存储。

大的有点不好，小的就一定好么？各自放飞的微服务，有了各自的实现、发布、伸缩的弹性，是不是就一定好了？

更多的服务器，和相关设施，代表着更多的故障。所以微服务经常强调的是面向故障进行设计。
分离的数据，相对于原有的单一数据库来说，事务保障变得复杂无比。
大量的进程会给运维工作带来很大压力，急需监控和自动化的大力支持。
单一业务的调用序列大幅延长，调试优化难度也一定是大大增加了。
散乱的技术栈，会大幅提高技术管理的难度，降低知识的复用性。
独立的代码库，很明显会降低代码复用的可能性。

由此看来，这种拆分并非只赚不赔的好买卖。是一个需要权衡的事情。不论微服务的数量有多大，个头有多小，作为一个独立的交付物，都还是需要遵循既有的软件开发技能和规律的。那么问题来了——对于给定的系统，到底应该有多少个微服务，每个服务有多大呢？

前文说道，我更愿意称微服务为一种改良，他是一种应对变化的手段，而非特征。在如今的情况下，不管是对新业务实现的设计，还是对既有系统的重构，任何架构师都不会把明明应该拆分的东西硬性的合并到一起。所以这个分离的标准就比较重要了。

拆还是不拆，这是个问题

很明显的，微服务的设计不是一个靠数量取胜的事情，所以重点不是能拆成多少块，而是什么东西需要拆，下面列出我所知的几个影响因素。

组织机构

利益人的识别，在各种软件开发过程中都是很重要的一个环节，在微服务中也是如此，而且尤其重要。当一份交付物存在多个利益人，并且互相之间不存在管辖关系的时候，就表明当前交付物的边界出现了问题，面临着令出多头、需求干扰的风险。

伸缩需求

同一个进程之内的不同业务功能，有时在业务量方面会出现较大的差异，具体要求的进程数量会有较大差别，这样的模块锁定在同一进程之内，势必会造成资源的浪费。

部署频率

这个很容易理解，同一个交付物内不同的组件有着不同的上线频率，会大大的提高上线流程的发生频率，会造成较大的人员浪费。

修改的相关性

如果同一交付物内的不同组件，经常会被同步修改，这可能说明，如果发生拆分，这两个模块应该是”在一起“的。

技术栈

新技术的爆发，让很多不同的场景有了更好的实现方式，如果有业务急需使用新的技术栈来（重新）实现。这种新技术除了新的语言、新的数据库之外，可能还包括容器、Service Mesh、API 网关等新晋 PaaS 能力。毫无疑问，这种业务也同样有拆分的需要。

结论

微服务虽说不是一个全新的东西，但也绝非是简单的新瓶装旧酒。总体说来，我认为这是在尊重现实，适当妥协的基础上，一种应对变化的好办法。

参考

kube-proxy 模式对比：iptables 还是 IPVS？

Thu, 02 May 2019 18:29:39 +0800

原文：Comparing kube-proxy modes: iptables or IPVS?

作者：Alex Pollitt

kube-proxy 是 Kubernetes 中的关键组件。他的角色就是在服务（ClusterIP 和 NodePort）和其后端 Pod 之间进行负载均衡。kube-proxy 有三种运行模式，每种都有不同的实现技术：userspace、iptables 或者 IPVS。

userspace 模式非常陈旧、缓慢，已经不推荐使用。但是 iptables 和 IPVS 该如何选择呢？本文中我们会对这两种模式进行比较，看看他们在真正的微服务上下文中的表现，并解释在特定情况下的选择方法。

首先我们说一下这两种模式的背景，然后开始测试并查看结果。

背景：iptables 模式

iptables 是一个 Linux 内核功能，是一个高效的防火墙，并提供了大量的数据包处理和过滤方面的能力。它可以在核心数据包处理管线上用 Hook 挂接一系列的规则。iptables 模式中 kube-proxy 在 NAT pre-routing Hook 中实现它的 NAT 和负载均衡功能。这种方法简单有效，依赖于成熟的内核功能，并且能够和其它跟 iptables 协作的应用（例如 Calico）融洽相处。

然而 kube-proxy 的用法是一种 O(n) 算法，其中的 n 随集群规模同步增长，这里的集群规模，更明确的说就是服务和后端 Pod 的数量。

背景：IPVS 模式

IPVS 是一个用于负载均衡的 Linux 内核功能。IPVS 模式下，kube-proxy 使用 IPVS 负载均衡代替了 iptable。这种模式同样有效，IPVS 的设计就是用来为大量服务进行负载均衡的，它有一套优化过的 API，使用优化的查找算法，而不是简单的从列表中查找规则。

这样一来，kube-proxy 在 IPVS 模式下，其连接过程的复杂度为 O(1)。换句话说，多数情况下，他的连接处理效率是和集群规模无关的。

另外作为一个独立的负载均衡器，IPVS 包含了多种不同的负载均衡算法，例如轮询、最短期望延迟、最少连接以及各种哈希方法等。而 iptables 就只有一种随机平等的选择算法。

IPVS 的一个潜在缺点就是，IPVS 处理数据包的路径和通常情况下 iptables 过滤器的路径是不同的。如果计划在有其他程序使用 iptables 的环境中使用 IPVS，需要进行一些研究，看看他们是否能够协调工作。（Calico 已经和 IPVS kube-proxy 兼容）

性能对比

iptables 的连接处理算法复杂度是 O(n)，而 IPVS 模式是 O(1)，但是在微服务环境中，其具体表现如何呢？

在多数场景中，有两个关键属性需要关注：

响应时间：一个微服务向另一个微服务发起调用时，第一个微服务发送请求，并从第二个微服务中得到响应，中间消耗了多少时间？
CPU 消耗：运行微服务的过程中，总体 CPU 使用情况如何？包括用户和核心空间的 CPU 使用，包含所有用于支持微服务的进程（也包括 kube-proxy）。

为了说明问题，我们运行一个微服务作为客户端，这个微服务以 Pod 的形式运行在一个独立的节点上，每秒钟发出 1000 个请求，请求的目标是一个 Kubernetes 服务，这个服务由 10 个 Pod 作为后端，运行在其它的节点上。接下来我们在客户端节点上进行了测量，包括 iptables 以及 IPVS 模式，运行了数量不等的 Kubernetes 服务，每个服务都有 10 个 Pod，最大有 10,000 个服务（也就是 100,000 个 Pod）。我们用 golang 编写了一个简单的测试工具作为客户端，用标准的 NGINX 作为后端服务。

响应时间

响应时间很重要，有助于我们理解连接和请求的差异。典型情况下，多数微服务都会使用持久或者 keepalive 连接，这意味着每个连接都会被多个请求复用，而不是每个请求一次连接。这很重要，因为多数连接的新建过程都需要完成三次 TCP 握手的过程，这需要消耗时间，也需要在 Linux 网络栈中进行更多操作，也就会消耗更多 CPU 和时间。

这张图展示了两个关键点：

iptables 和 IPVS 的平均响应时间在 1000 个服务（10000 个 Pod）以上时，会开始观察到差异。
只有在每次请求都发起新连接的情况下，两种模式的差异才比较明显。

不管是 iptables 还是 IPVS，kube-proxy 的响应时间开销都是和建立连接的数量相关的，而不是数据包或者请求数量，这是因为 Linux 使用了 Conntrack，能够高效地将数据包和现存连接关联起来。如果数据包能够被 Conntrack 成功匹配，那就不需要通过 kube-proxy 的 iptables 或 IPVS 规则来推算去向。Linux conntrack 非常棒！（绝大多数时候）

值得注意的是，例子中的服务端微服务使用 NGINX 提供一个静态小页面。多数微服务要做更多操作，因此会产生更高的响应时间，也就是 kube-proxy 处理过程在总体时间中的占比会减少。

还有个需要解释的古怪问题：既然 IPVS 的连接过程复杂度是 O(1)，为什么在 10,000 服务的情况下，非 Keepalive 的响应时间还是提高了？我们需要深入挖掘更多内容才能解释这一问题，但是其中一个因素就是因为上升的 CPU 用量拖慢了整个系统。这就是下一个主题需要探究的内容。

CPU 用量

为了描述 CPU 用量，下图关注的是最差情况：不使用持久/keepalive 连接的情况下，kube-proxy 会有最大的处理开销。

上图说明了两件事：

在超过 1000 个服务（也就是 10,000 个 Pod）的情况下，CPU 用量差异才开始明显。
在一万个服务的情况下（十万个后端 Pod），iptables 模式增长了 0.35 个核心的占用，而 IPVS 模式仅增长了 8%。

有两个主要因素造成 CPU 用量增长：

第一个因素是，缺省情况下 kube-proxy 每 30 秒会用所有服务对内核重新编程。这也解释了为什么 IPVS 模式下，新建连接的 O(1) 复杂度也仍然会产生更多的 CPU 占用。另外，如果是旧版本内核，重新编程 iptables 的 API 会更慢。所以如果你用的内核较旧，iptables 模式可能会占用更多的 CPU。

另一个因素是，kube-proxy 使用 IPVS 或者 iptables 处理新连接的消耗。对 iptables 来说，通常是 O(n) 的复杂度。在存在大量服务的情况下，会出现显著的 CPU 占用升高。例如在 10,000 服务（100,000 个后端 Pod）的情况下，iptables 会为每个请求的每个连接处理大约 20000 条规则。如果使用 NINGX 缺省每连接 100 请求的 keepalive 设置，kube-proxy 的 iptables 规则执行次数会减少为 1%，会把 iptables 的 CPU 消耗降低到和 IPVS 类似的水平。

客户端微服务会简单的丢弃响应内容。真实世界中自然会进行更多处理，也会造成更多的 CPU 消耗，但是不会影响 CPU 消耗随服务数量增长的事实。

结论

在超过 1000 服务的规模下，kube-proxy 的 IPVS 模式会有更好的性能表现。虽然可能有多种不同情况，但是通常来说，让微服务使用持久连接、运行现代内核，也能取得较好的效果。如果运行的内核较旧，或者无法使用持久连接，那么 IPVS 模式可能是个更好的选择。

抛开性能问题不谈，IPVS 模式还有个好处就是具有更多的负载均衡算法可供选择。

如果你还不确定 IPVS 是否合适，那就继续使用 iptables 模式好了。这种传统模式有大量的生产案例支撑，他是一个不完美的缺省选项。

补充：Calico 和 kube-proxy 的 iptables 比较

本文中我们看到，kube-proxy 中的 iptables 用法在大规模集群中可能会产生性能问题。有人问我 Calico 为什么没有类似的问题。答案是 Calico 中 kube-proxy 的用法是不同的。kube-proxy 使用了一个很长的规则链条，链条长度会随着集群规模而增长，Calico 使用的是一个很短的优化过的规则链，经由 ipsets 的加持，也具备了 O(1) 复杂度的查询能力。

下图证明了这一观点，其中展示了每次连接过程中，kube-proxy 和 Calico 中 iptables 规则数量的平均值。这里假设集群中的节点平均有 30 个 Pod，每个 Pod 具有 3 个网络规则。

即使是使用 10,000 个服务和 100,000 个 Pod 的情况下，Calico 每连接执行的 iptables 规则也只是和 kube-proxy 在 20 服务 200 个 Pod 的情况基本一致。

Linux Conntrack 的短板

Thu, 02 May 2019 16:27:45 +0800

原文：When Linux conntrack is no longer your friend

作者：Alex Pollitt

Linux 内核中，conntrack 的是网络栈的核心功能之一。它使得内核能够跟踪所有逻辑网络连接或者流量，因此能够鉴别构成流量的数据包，从而对每个数据流进行一致的处理。

Conntrack 是一个重要的内核功能，是一些关键用例的基础：

NAT 能够根据 Conntrack 的信息，对构成数据流的所有数据包进行翻译。例如当 Pod 访问 Kubernetes 服务的时候，kube-proxy 的负载均衡功能会使用 NAT 把连接重定向给指定的后端 Pod。Conntrack 负责对指定连接进行记录，发送到 Service IP 的数据包会被发送给同一个后端 Pod，从后端 Pod 返回的数据包会反向送回源 Pod。
Calico 这样的有状态防火墙，依赖 Conntrack 的信息来精确的将响应流量纳入白名单。用户如果编写了一个“允许 Pod 连接所有远端 IP”的策略，无需进行其它工作就能够允许所有的返回流量（如果没有这种功能，就必须加入一个不那么安全的规则：允许所有目标是该 Pod 的流量）。

另外 Conntrack 还能够提高性能（降低 CPU 和延迟），这是因为只有第一个数据包需要完成整个网络栈的处理，参见 Comparing kube-proxy modes 一文，其中包含了这方面的例子。

然而 Conntrack 也有其限制。

那么它哪里不行了？

Conntrack 的存储表有一个可配置的最大容量，如果满了，连接通常会被拒绝和丢弃。在多数负载情况下，这个表的容量是足够的，不会出现这种问题。但是有些场景下，Conntrack 也会不够用：

最常见的情况是，如果你的服务器需要同时处理非常大数量的活动连接。例如你的 Conntrack 表设置为 128k 的容量，但是你的并发连接超过了 128k，这肯定会出问题。
另外一种情况没那么常见——每秒处理极大数量的连接。这些连接就算再短，Linux 还会在超时（通常是 120 秒）期限内对其进行跟踪。例如如果你的 Conntrack 容量设置为 128k，尝试每秒钟处理 1100 个连接，这就会超出 Conntrack 表的限制（128k/120秒 = 1092 连接/秒）。

有个别的负载类型就符合这种条件。另外如果在一个恶劣环境中，用大量的半开连接冲击服务器，就能造成拒绝服务攻击的效果。两种情况下，Conntrack 都会成为系统中的瓶颈。有些情况下，通过提高 Conntrack 数据表容量或者降低 Conntrack 的超时时间（如果调节失误，可能会造成更多痛苦）就能解决问题。别的场景中，可能需要跨过 Conntrack 来处理这种威胁。

一个真实的案例

我们合作的某大型 SaaS 供应商，他们有一组运行于物理机（不是虚拟化，也不是容器化）上的 Memcached 服务器，每台服务器每秒都要处理 50k 以上的短连接。这可不是标准的 Linux 配置能够承受的。

他们曾经使用提高 Conntrack 数据表容量和降低超时时间的方式进行调整，但是这种调整非常脆弱，内存占用增长极大（GB 级），超时时间过短让 Conntrack 的益处（降低 CPU 和数据包延迟）也大为减少。

因此他们转向了 Calico，Calico 的网络策略允许指定部分流量绕过 Conntrack。这一措施让他们得到了期待的性能，并且还得到了 Calico 带来的安全优势。

绕开 Conntrack 的妥协之处

Do-not-track 策略通常是对称的。上面谈到的 SaaS 供应商案例，他们的工作负载是内部的，因此他们可以非常严格的在工作负载和 Memcached 之间进行白名单设置。
Do-not-track 策略是不知道连接的方向的。所以只要 Memcached 服务器知道 Memcached 客户端的源端口，他都可以尝试连接。但是如果为 Memcached 客户端定义了正确的策略，那么还可以在客户端拒绝这些连接。
Do-not-track 对每个数据包生效，而通常的网络策略只对数据流中的第一个数据包生效。这样会提高 CPU 的消耗。但是在短连接环境下，网络策略造成的消耗还是低于 Conntrack 过程的消耗的。例如 SaaS 供应商的例子中，每连接中的数据包都很少，所以使用策略处理每个数据包的过程中造成的多余开销也就可以接受了。

测试一下

我们测试了单一 Memcached 服务器 Pod 以及运行在远程节点上的多个客户端的场景，这种场景能方便的产生大量链接。Memcached Pod 所在的节点有 8 个 CPU 核心，Conntrack 表容量为 512k（主机的标准设置）。我们在几种方案中进行了比较：没有网络策略；Calico 通用网络策略；Calico Do-not-track 策略。

第一个测试中，我们限制每秒 4000 个连接，以此来方便的观察 CPU 方面的差异。无策略和正常策略的测试用例，其结果没有差异，而 Do-not-track 策略降低了 20%。

第二个测试中，我们尽量的提高连接数量，这样就可以观察到 Memcached 能够处理的每秒最大连接数量了。如前所述，无策略和普通策略的情况里，受到 Conntrack 数据表容量的影响，只能达到每秒 4000 多连接的能力（512k / 120s = 4,369 connections/s）。而 Do-not-track 策略下，连接数达到了 60k 每秒，没有出现问题。我们相信，可以通过更多的客户端来产生更高的负载数量，但是这一数字已经证实了我们提到的观点了。

结论

Conntrack 是一个重要的内核功能。大多数场景下，它都能发挥很好的作用。然而有些小众场景中，Conntrack 的开销会大于其收益。在这种情况下，Calico 的网络策略可以通过选择性的绕过 Conntrack，并提高网络安全性。而对其他流量，Conntrack 还是你的好朋友。

Hitler Uses Docker

Wed, 01 May 2019 20:39:58 +0800

克莱勃斯

我们把镜像推送到 Dockerhub，然后使用 docker compose 部署到集群上。

我们在这些节点上加载数据卷。

然后在这里连接到应用容器。

最后，我们更新了 DNS 记录。

希特勒

所以我们在每个节点上运行了 20 个容器。我们什么时候可以去掉多余的服务器？

克莱勃斯

元首，内核。。。

约德尔

有个第三方容器引发了内核恐慌。我们损失了 70% 的集群和数据卷。

希特勒

没在生产环境上使用 Docker 的，出去。

隔离个屁！

你们想什么呢！

谁特么会用 Docker hub 上的公共镜像？

你们该知道那都是俄罗斯黑客做的！

你可能还用 curl | sudo bash！

你觉得公共仓库上的所有东西都是安全的？就因为是开源软件？

你们这群赶 Node.js 时髦的人，只会看着 Hacker news 啥都装上去！

克莱勃斯

但是 Docker 让我们能够在任何地方运行我们的应用！

希特勒

为了在你的笔记本上运行 Docker，你还得用个虚拟机！

克莱勃斯

元首，docker-machine 用的是轻量级虚拟机！

希特勒

你知道自己在说什么？我们都用了虚拟机了，为什么还需要 Docker？

容器里的容器！

就为了部署一个 10 MB 的 Go 程序，你们压缩了一整个 Linux 操作系统，然后因为太大了，又用上 CoW 存储。

别跟我说什么资源限制。cgroups 的黑魔法连简单的 fork 炸弹都挡不住！

如果数据库需要服务器上的所有资源，Docker 还让你在上面运行更多程序！

Docker 之前，我只要选择个合适尺寸的虚拟机。

突然人们告诉我什么数据中心效能什么超融合。

所有人都觉得自己是 Google！

你都不用运行自己的机器了！

大家都在 GCE 上运行 Docker，在 Borg 虚拟机实例上运行 Linux 容器！

还有人觉得 Docker 能做配置管理，他们觉得 Docker 解决了所有问题！

连微软都有容器了！

我正在把所有东西都转移到 Windows！

容格夫人

别哭了，现在可以在 Windows 10 里运行 Bash 了。

希特勒

Docker 本该有更好的性能。

但是 userland 代理比 28.8k 的猫还慢。

现在连企业都想跑 Docker 了，但他们还在运行 Red Hat 5。

你们这些白痴认为 Docker 能帮你们的应用进行伸缩。

关键业务用 Openstack 吧。

如何参与 Kubernetes 文档的本地化工作

Sun, 28 Apr 2019 08:05:15 +0800

原文：How You Can Help Localize Kubernetes Docs

作者：Zach Corleissen

去年我们对 Kubernetes 网站进行了优化，加入了多语言内容的支持。贡献者们踊跃响应，加入了多种新的本地化内容：截至 2019 年 4 月，Kubernetes 文档有了 9 个不同语言的未完成版本，其中有 6 个是 2019 年加入的。在每个 Kubernetes 文档页面的上方，读者都可以看到一个语言选择器，其中列出了所有可用语言。

不论是完成度最高的中文版 v1.12，还是最新加入的葡萄牙文版 v1.14，各语言的本地化内容还未完成，这是一个进行中的项目。如果读者有兴趣对现有本地化工作提供支持，请继续阅读。

什么是本地化

翻译是以词表意的问题。而本地化在此基础之上，还包含了过程和设计方面的工作。

本地化和翻译很像，但是包含更多内容。除了进行翻译之外，本地化还要为编写和发布过程的框架进行优化。例如，Kubernetes.io 多数的站点浏览功能（按钮文字）都保存在单独的文件之中。所以启动新本地化的过程中，需要包含加入对特定文件中字符串进行翻译的工作。

本地化很重要，能够有效的降低 Kubernetes 的采纳和支持门槛。如果能用母语阅读 Kubernetes 文档，就能更轻松的开始使用 Kubernetes，并对其发展作出贡献。

如何启动本地化工作

不同语言的本地化工作都是单独的功能——和其它 Kubernetes 功能一致，贡献者们在一个 SIG 中进行本地化工作，分享出来进行评审，并加入项目。

贡献者们在团队中进行内容的本地化工作。因为自己不能批准自己的 PR，所以一个本地化团队至少应该有两个人——例如意大利文的本地化团队有两个人。这个团队规模可能很大：中文团队有几十个成员。

每个团队都有自己的工作流。有些团队手工完成所有的内容翻译；有些会使用带有翻译插件的编译器，并使用评审机来提供正确性的保障。SIG Docs 专注于输出的标准；这就给了本地化团队采用适合自己工作情况的工作流。这样一来，团队可以根据最佳实践进行协作，并以 Kubernetes 的社区精神进行分享。

为本地化工作添砖加瓦

如果你有兴趣为 Kubernetes 文档加入新语种的本地化内容，Kubernetes contribution guide 中包含了这方面的相关内容。

已经启动的的本地化工作同样需要支持。如果有兴趣为现存项目做出贡献，可以加入本地化团队的 Slack 频道，去做个自我介绍。各团队的成员会帮助你开始工作。

语种	Slack 频道
中文	#kubernetes-docs-zh
英文	#sig-docs
法文	#kubernetes-docs-fr
德文	#kubernetes-docs-de
印地	#kubernetes-docs-hi
印度尼西亚文	#kubernetes-docs-id
意大利文	#kubernetes-docs-it
日文	#kubernetes-docs-ja
韩文	#kubernetes-docs-ko
葡萄牙文	#kubernetes-docs-pt
西班牙文	#kubernetes-docs-es

下一步？

最新的印地文本地化工作正在启动。为什么不加入你的语言？

身为 SIG Docs 的主席，我甚至希望本地化工作跳出文档范畴，直接为 Kubernetes 组件提供本地化支持。有什么组件是你希望支持不同语言的么？可以提交一个 Kubernetes Enhancement Proposal 来促成这一进步。

我参加了一次笔会

Sun, 21 Apr 2019 15:14:04 +0800

博文视点的张国霞编辑，跟我说杭州有个作者会的时候，我刚听完马未都的段子：

一堆作家都在一块。要怎么办呢，要互相恭维，挖坑。我原来说过啊，刘震云最会挖坑，挖王朔的坑：王老师，小说写得非常不错，王朔说不行，写不好写不好，过去了。每天吃中饭，因为吃饭都在，那时候做笔会嘛，都在那个食堂里吃，那时候食堂也没说像现在都是摆上席，就是一人一份端在一起。第二天同样的话还说，王老师确实我觉得你小说写得好，王朔说真的写得不好。第三天还这样夸，王老师我是真心的话，你的小说写得是真好。然后王朔第三天就是说，我是觉得我小说写得不错。你瞧，我在桌子上呢，刘震云当场就把脸翻过来对我说，一般人最多就扛住三天。

我想，大概是“某老师您好，久仰久仰”、“不不，您老师”之类的大型互拍现场吧，周末出来转转，社交一下也是很好的，和国霞商量了一些活动安排之后，419 这天就奔赴机场了：令人印象深刻的一次延误，十个小时，并没有持续整夜，成功刷新了某次从广州飞武汉的 8 小时纪录。

轻车熟路的打车、入住、睡觉。主办方安排的住宿相当不错，感谢。早六点就醒了过来，吸着晨雾，沿钱塘江北岸打了个跑步卡，江边步道是倾斜的，对膝盖造成很大压力。

早晨开场，按惯例是领导致辞，套话不多，数字不少，并没有想象中的沉闷。接下来是由潘爱民、苏杰和余晟三个大牌协作完成的杀威棒环节。潘爱民老师自然是我这一代 IT 工作者耳熟能详的明星了，不疾不徐的讲述了其工作和创作的过程和方法。而接下来苏杰的一问：在座各位有谁的作品销量超过百万千万？正式开始展示了这一活动的不同之处，今天我先后两次说到，这一活动的含金量远超我的预期。返回途中，我时不时的在想，给我造成这一印象的原因，大概有如下三点：

读者背书：参会作者，都有获得较大范围内读者认可的作品，懂技术、懂读者、有条理、会表达，几个优点，这样的一群人的碰撞，火花四溅是个必然结果。
氛围轻松：主办方在完成必要的组织活动之外，并没有过多的对分享内容进行干预，对时间也没有进行很严格的控制，让分享者都能够较为自由的完成表演。
本色出演：同其它活动不同的是，这一次大家并没有背着传递价值观或宣传产品的包袱，大家都可以选择擅长的内容、习惯的方式来进行表达，其效果自然不可同日而语。

下面摘录目前还能想得起的一些金句（全靠印象，并不精准）：

苏杰：
- 有人说我毁了一个行业。
- 把你的书当成产品来进行运营。
- 要不是炒股。。
余晟：
- 做翻译的收入。。不谈也罢。
- 但是我不炒股，所以还能剩点。
褚霸：
- 有的书能让你百倍千倍的赚回来，比如潘老师的。
小马哥：
- 我只看二十五史、论文、和 RFC。
- 我不看电影，我看新闻联播。
- 根据当地法律法规，该内容未能显示
- 根据当地法律法规，该内容未能显示
- 根据当地法律法规，该内容未能显示

另外大家还在活动间隙对 996 等热门话题交换了毫无意义的看法，极大的增进了了解，加深了友谊。阿里的兵强马壮，也给与会者留下了深刻的印象。

活动中还看到了另一本 Istio 书的作者，高大帅气一表人才的周遥同学，目前看来 Istio 相关书籍的作者，头发都很茂盛，证明这一技术相当安全，大家可以放手研究。

返程航班上，一路颠簸，一路闪电，大饱眼福。

开始降落。感谢博文视点，你们很棒：）

关于 Anthos- Google 的混合多云平台

Tue, 16 Apr 2019 16:17:22 +0800

原文：Everything You Want To Know About Anthos - Google’s Hybrid And Multi-Cloud Platform

作者：Janakiram MSV

最近结束的 Cloud Next 会议上，Google 宣布企业级混合多云平台 Anthos 进入 GA 阶段。

虽说会上有超过一百个发布，Anthos 依旧醒目。它标志着 Google 官方开始涉足企业数据中心。这是主流公有云厂商第一次以官方身份踏入多云平台的市场。

从 Sundar Pichai 到 Thomas Kurian 再到 Urs Hölzle，Anthos 被描述为下一代技术。很明显，Google 的高层团队为该项目深感自豪。

Anthos 和其它公有云服务不同。它不仅是一个产品，而是一个覆盖应用程序现代化、云迁移、混合云和多云管理等主题的家族品牌。

虽然 Anthos 及其 GA 级别的成熟度被广泛报道，但是这一发布活动还是令人困惑的。文档非常稀少，相关服务并未完全集成到自助工作台之中。除了混合云的连接以及多云应用部署之外，Google 的这一新技术的更多细节并不为人所知。

基础构成

Anthos 的核心是目前最流行的开源项目：Kubernetes。GKE 是 Google 云提供的容器即服务技术，Anthos正是构建于 GKE 的坚实基础之上。当然还有一些其它的重要技术为 Kubernetes 提供了必要的补充。

镜头拉近，看看 Anthos 的核心组件：

GKE：Anthos 的命令和控制核心。用户通过 GKE 的控制平面来对分散在 Google 云、私有数据中心一级其它云平台上的基础设施进行管理。
GKE On-Prem：Google 推出了一个基于 Kubernetes 的和 GKE 一致的软件平台。用户能够在任何的兼容硬件上部署这一产品，而 Google 将会对其进行管理。从升级 Kubernetes 版本到应用最新补丁，Google 都视其为 GKE 的逻辑扩展。尤其需要注意的是 GKE On-Prem 运行在 VMWare vSphere 6.5 的虚拟化基础上，Hyper-V 和 KVM 等其它虚拟化技术的支持还在开发之中。
Istio：这一技术让跨平台的联邦网络管理成为可能。Anthos 需要为部署在不同数据中心、GCP 以及其它云上的多种应用程序的组件建立服务网格，Istio 自然是首选。它会和 VMWare NSX、Cisco ACI 以及 Google 自己的 Andromeda 等 SDN 进行无缝集成。已经在网络设施上（例如 F5）进行投资的客户，可以将 Istio 和负载均衡及防火墙集成起来。
Velostrata：Google 在 2018 年收购了这一云迁移技术，来增强 Kubernetes 的竞争力。Velostrata 的主要功能——在 GCE 实例中复制物理机/虚拟机，并把现有虚拟机转换为 Kubernetes 应用（Pod）。这是业界首个物理机到 Kubernetes 的迁移工具，由 Google 提供。这一技术以 Anthos Migrate 的面目出现，目前是 Beta 阶段。
Anthos 配置管理：Kubernetes 是一个可扩展的策略驱动的平台。Anthos 的客户必须面对运行在不同环境中的多个 Kubernetes，因此 Google 尝试利用 Anthos 来简化配置管理工作。从发布工件、配置项目、网络策略、密文和密码等类型的配置，Anthos 配置管理都能够进行管理并将配置应用到一或多个集群之中。
Stackdriver：Stackdriver 为 Anthos 基础设施和应用提供了可观察性的支持。客户能够使用这一组件跟踪运行在 Anthos集群状态，以及部署在各个托管集群上的应用的健康情况。该组件负责集中地提供监控、日志、跟踪以及观察的支持。
GCP Cloud Interconnect：在企业数据中心以及云基础设施之间的高速互联，是混合云平台的必要条件。Cloud Interconnect 能够在数据中心和云间交付高达 100Gbps 的高速网络。客户也可以使用 Equinix、NTT Communications、Softbanck 等电信厂商的网络将其数据中心延伸到 GCP。
GCP Marketplace：Google 为能够在 Kubernetes 上运行的（来自 ISV 和开源的）软件列表。用户能够在 Anthos 中一键部署 Cassandra 数据库或者 GitLab 等软件。最终 Google 可能还会为内部 IT 提供一个私有的 Catalog 服务。

应用程序：Greenfield vs Brownfield

Anthos 的核心场景就是应用的现代化进程。Google 所展望的未来世界中，所有企业都运行在 Kubernetes 上。为了达成这一目标，Google 在 Velostrata 这样的技术上进行投资，从而完成从虚拟机到容器的就地升级。

Google 为 VMware 的 vRealize 构建了一个插件，可以把现有虚拟机转换为 Kubernetes Pod。即使是 PostgreSQL 和 MySQL 这样的有状态应用，都能够转换为 StatefulSet 在 Kubernetes 中运行。

在从自有虚拟机向云端虚拟机的迁移问题上，Google 表现得轻描淡写。但是 Velostrata 的原始服务都是基于 VM 的。客户的业务线应用程序，例如 SAP、Oracle Finacials 以及 Peoplesoft 都可以持续的运行在自家数据中心的虚拟机中，或者也可以选择迁移到 GCE 的虚拟机上。Anthos 在技术上提供虚拟机和 Kubernetes 容器化应用之间的互操作性。

有了 Anthos，Google 想要拥有所有运行在 Kubernetes 之上现代微服务应用（Greenfield），同时也想将现有虚拟机（Brownfield）转换为容器。非 x86 架构中的存量应用会持续运行在物理或者虚拟机上。

广泛的行业合作

因为缺乏与业内其它厂商的合作和伙伴关系，Google 经常受到批评。为了对抗微软和 Amazon，Google 准备和行业中的其它老牌企业进行合作。毫无疑问，这一举措会帮助 Google 在企业市场获得一席之地。

为了让 Anthos 走向成功，Google 将不得不依靠现有的企业市场玩家进行推动。它要寻求的是和微软以及 Amazon 的合作伙伴，来一起推进混合云进程。

Cisco 将 HyperFlex、ACI、SD-WAN 以及 Stealthwatch Cloud 扩展到 Anthos 之上，为其提供 SDN 能力。VMware 正在为 Pivotal Kubernetes Service（PKS）加入 Anthos 支持，另外还有 VeloCloud 提供的 SD-WAN 能力；它还将它的流行 SDN 方案 NSX 集成到了 Istio 之中。

大量 ISV 正在启动对 Anthos 的支持。从 Citrix 到 NetApp 到 MongoDB，众多的平台供应商正在尝试将其软件集成到 Anthos 之中。

Google 的 Kubernetes 攻势

作为 Kubernetes 的创始人，毫无疑问的，Google 是很擅长管理容器的。在 Docker 开始展现出对开发者的吸引力之后，Google 意识到这是放养 Kubernetes 的绝佳机会。Google 也是业内第一个提供托管 Kubernetes 的公有云厂商。虽然有为数众多的竞争者，GKE 仍然是运行微服务的最佳平台。

基于对 Kubernetes 的深入理解，以及在这方面的持续投入，Google 希望在容器和微服务的新世界之中占据主导地位。它希望企业能够跳出虚拟机，在 Kubernetes 上运行他们的现代应用。

Anthos 是 Google 的重要一步。它正在冒险摆脱其对手用于吸引企业客户的混合云玩法。Anthos 对标的是微软的 Azure Stack 以及 AWS 提出的 VMware 结合 Outpost 的混合云方案。Google 和竞争对手的明显差别在于，它的方案根植于容器和 Kubernetes 技术。

Google 希望利用在 Kubernetes 和云原生领域的领先地位。它迅速地围绕 Kubernetes 构建了企业战略。Google 意图通过 Anthos 成为容器生态系统中的 VMware。VMware 在企业中推动其 hypervisor 以及软件定义的基础设施的手段，正是现在 Google 的行为方式。

但是微软同样在容器和 Kubernetes 方面下了重注。它通过将公有云中的旗舰级能力下放到私有云的方式，模糊了 Azure 和 Azure Stack 之间的界线。微软能够用 Azure Kubernetes 服务来复制 Anthos 的战术。Redmond 将如何使用 Azure Stack 玩转 Kubernetes，是个令人感兴趣的问题。

如果一切如 Google 所愿，Anthos 最终会成为运行企业负载的首选平台。

企业就绪

让来自 Cisco 和 VMware 的高管和 Thomas Kurian 一起登台，这是来自 Google 的声明：已经为企业市场做好准备。这一表现当然会增强企业客户在 Anthos 和 GCP 上进行投入的信心。

Kubernetes 被认为是一个高技术的、具有极客气息的平台，因此吸引了开发和运营人员。而有了 Anthos 的帮助，Google 将会改变客户对 Kubernetes 的刻板印象。它将 Kubernetes 变成一个可用的、可靠的企业级混合云平台。

Thomas Kurian 掌舵之后，Google 开始关注企业市场。如果它能够用好合作伙伴关系，并持续和关键的行业参与者进行合作，Google 和 Anthos 将会给企业基础设施市场带来巨大冲击。

云原生生态的巨大机会

Anthos 提振了对云原生生态系统的信心。前面提到过，Google 希望成为 Kubernetes 世界中的 VMware。但是和 VMware 登上企业宝座的时候相比，世界已经不同了。

最大的区别就是开源软件。Google 现在面临的环境中，软件已经不再是关键区别。

为了 Anthos 的成功，Google 必须依赖社区和生态系统。为云原生环境提供利基产品的创业公司（例如 Tigera、Portworx、Robin、Confluent、Cloudbees）将会得到更好的机会，Anthos 的推出，会让其受益匪浅。

从小型的本地供应商到埃森哲、高知特这样的全球 SI，供应商和集成商正在为 Anthos 做准备。Google 的混合云战略将转化为价值数百万没有的的服务机会。

随着 Google 向企业宣传和销售 Kubernetes 的举措，创业公司将借势将其触角伸向企业。

Google 在 Anthos 上的豪赌对行业大有裨益，开源社区和云原生生态系统将加速 Kubernetes 的采用过程。

Google Cloud Run 一瞥

Tue, 16 Apr 2019 03:38:07 +0800

原文：A First Look at Google Cloud Run

作者：Marko Anastasov

Google 在 Cloud Next’19 上发布了基于 Docker 容器的的 Serverless 新方案。目前可以肯定的是，这是 Serverless 的重要进步——在 Cloud Run 上进行部署比在 Kubernetes 上运行容器简单多了。而且和 Lambda 不同，这一方案没有语言绑定的问题。

什么是 Google Cloud Run

Google Cloud Run 是一个全托管平台，它以无状态、自动伸缩的 HTTP 服务的形式运行 Docker 容器镜像。

Cloud Run 和第一代 Serverless 平台（例如 AWS Lambda、Google Cloud functions 或 Azure Functions）不同，它允许你运行任意的应用，提供多个端点；而无需使用特定接口来运行小规模的函数。

Cloud Run 的基础来自于 Knative，因此这一方案有可能被移植到其它的托管 Kubernetes 平台。

我的项目能够在 Google Cloud Run 上运行么？

Google 发表了容器运行时契约，其中说明了对容器的要求：

容器是 64 位 Linux 平台；
在 8080 端口监听 HTTP 请求；
最多使用 2G 内存；
容器实例必须在收到请求之后的 4 分钟内启动 HTTP 服务器；
应用应该能够适应自动从 0 到多个运行实例的容器环境；
所有的运算都应该是无状态的，限制在一个请求之内。

只要你的项目能够符合上面的条件，不论使用什么语言开发，都能够在 Cloud Run 上面运行。

Cloud Run 目前还在 Beta 阶段，因此这些需求可能会发生变动。

上手流程

对于熟悉 Docker 或者 Heroku 传统 PaaS 解决方案的人来说，Cloud Run 应该很易上手。

应用打包成 Docker 之后，剩下的任务包括：

把镜像推送到 Google 镜像库。
运行 gcloud beta run deploy

只要几分钟，Cloud Run 就会使用一个可定制、可开放的域名启动新应用了。

示例：使用 Semaphore 进行持续部署

下面的例子中，我们使用 Semaphore 要为一个微服务配置 Serverless CI/CD Pipeline，其中包含如下环节：

运行自动测试；
构建 Docker 容器；
将容器镜像推入 Google 镜像库；
提供到 Cloud Run 预备环境的一键部署；
在对 Master 分支的构建成功之后；自动部署到 Cloud Run 生产环境。

可以在 Github 上找到相关的全部代码。

启用 Cloud Run

官方的快速启动指南提供了一个 Cloud Run 的上手教程。

第一步是：

在你的账号中启用 Cloud Run API；
安装 Google Cloud SDK；
使用 gcloud components install beta 安装 Beta 组件。

应用容器化

下面的 Dockerfile 将一个简单的 Sinatra 应用打包：

FROM ruby:2.5
RUN apt-get update -qq &amp;&amp; apt-get install -y build-essential
ENV APP_HOME /app
RUN mkdir $APP_HOME
WORKDIR $APP_HOME
ADD Gemfile* $APP_HOME/
RUN bundle install --without development test
ADD . $APP_HOME
EXPOSE 8080
CMD ["bundle", "exec", "rackup", "--host", "0.0.0.0", "-p", "8080"]

注意如果使用你自己的 Dockerfile，必须开放 8080 端口，否则可能会看到如下错误：

登录 Google Cloud 和 GCR

要在 CI/CD Pipeline 中自动地将镜像推送到 GCR，需要在 Semaphore 中登录到 Google Cloud。为了安全起见，需要在 Semaphore 中根据 Google Cloud Service account 的认证密钥创建一个 Secret。

获取认证密钥之后，在 Semaphore 中用 Secret 的形式上传到 Semaphore。假设文件名是 .secrets.gcp.json：

sem create secret google-cloud-stg --file ~/Downloads/account-name-27f3a5bcea2d.json:.secrets.gcp.json

定义分发管线

接下来就可以编写一个 Pipeline 来构建、标记并推送镜像到 GCR 了：

# .semaphore/docker-build.yml
# This pipeline runs after semaphore.yml
version: v1.0
name: Docker build
agent:
  machine:
    # Use a machine type with more RAM and CPU power for faster container
    # builds:
    type: e1-standard-4
    os_image: ubuntu1804
blocks:
  - name: Build
    task:
      # Mount a secret which defines an authentication key file.
      # For info on creating secrets, see:
      # - https://docs.semaphoreci.com/article/66-environment-variables-and-secrets
      # - https://docs.semaphoreci.com/article/72-google-container-registry-gcr
      secrets:
        - name: google-cloud-stg
      jobs:
      - name: Docker build
        commands:
          # Authenticate using the file injected from the secret
          - gcloud auth activate-service-account --key-file=.secrets.gcp.json
          # Configure access to container registry, silence confirmation prompts with -q
          - gcloud auth configure-docker -q

          - checkout

          # Tag your images with gcr.io/ACCOUNT_PROJECT_NAME/SERVICE_NAME pattern
          # Use Git SHA to produce unique artifacts
          - docker build -t "gcr.io/semaphore2-stg/semaphore-demo-cloud-run:${SEMAPHORE_GIT_SHA:0:7}" .
          - docker push "gcr.io/semaphore2-stg/semaphore-demo-cloud-run:${SEMAPHORE_GIT_SHA:0:7}"

promotions:
  # Deployment to staging can be trigger manually:
  - name: Deploy to staging
    pipeline_file: deploy-staging.yml

  # Automatically deploy to production on successful builds on master branch:
  - name: Deploy to production
    pipeline_file: deploy-production.yml
    auto_promote_on:
      - result: passed
        branch:
          - master

在 deploy-staging.yml 和 deploy-production.yml 中包含了同样的步骤，区别只是服务的名称。

# .semaphore/deploy-production.yml
# This pipeline runs after docker-build.yml
version: v1.0
name: Deploy to production
agent:
  machine:
    type: e1-standard-2
    os_image: ubuntu1804
blocks:
  - name: Deploy to production
    task:
      secrets:
        - name: google-cloud-stg
      jobs:
      - name: run deploy
        commands:
          - gcloud auth activate-service-account --key-file=.secrets.gcp.json
          - gcloud auth configure-docker -q
          
          # Deploy to Cloud Run, using flags to avoid interactive prompt
          # See https://cloud.google.com/sdk/gcloud/reference/beta/run/deploy
          - gcloud beta run deploy markoci-demo-cloud-run --project semaphore2-stg --image gcr.io/semaphore2-stg/markoci-demo-cloud-run:${SEMAPHORE_GIT_SHA:0:7} --region us-central1

上线运行

在本地终端或者 Semaphore 作业的日志中，最后一行会包含一个应用运行的网址：

https://semaphore-demo-cloud-run-ud2bmvsmda-uc.a.run.app.

用浏览器打开这个网址会看到：

这是因为还没有完成最后一步：在 Google Cloud Run 控制台中开放服务

完成之后的浏览页面：

整装待发

希望本文能够引起你使用 CI/CD Pipeline 在 Google Cloud Run 上构建和发布应用的兴趣。

Knative 0.5 发布

Thu, 11 Apr 2019 22:37:55 +0800

原文：Announcing Knative v0.5 Release

作者：Mark Chmarny

再一次激动地宣布 Knative 的新版本发布了。Knative 是一个能帮助开发者在 Kubernetes 基础之上，构建、部署和管理现代 Serverless 工作负载的平台。

更加频繁和符合预期的发布节奏，让我们有机会能够从真实世界中获得更快的反馈，这种节奏当然也意味着更小的、更多的功能进展。也不全是这样，Knative v0.5 中，Eventing 系统有了长足的进步。其中的 Trigger 和 Broker 对象的引入，让开发者基于 Knative 构建事件驱动系统时能够得到更好更强的开发体验。

除了 Eventing，这个版本的 Knative 还增加了监控指标，提高了自动伸缩、队列代理以及 Istio 遥测的可观察性，下面做一个介绍，并对部分变更做出一点深入讲解。

Eventing

在 Eventing 架构中加入了 Trigger 和 Broker 对象，开发者能够轻松的构建出复杂且健壮的事件驱动应用。通过对 Producing 和 Consuming 服务的解耦，对路由配置的需求大大降低。我们相信，社区将会使用这一新能力构建出新的事件和创新的解决方案。

Trigger：开发者不再需要手工的对事件进行转换并路由给下游的 Knative 服务。只要定义一个简单的事件触发器，选择源事件（可以使用任何方式进行过滤），然后发送到消费方服务即可。这一对象会给开发者的体验带来很大简化。

Broker：事件 Broker 充当了事件 Hub 的角色，所有的消息都会发送给它。开发者和用户简单的编写服务或者配置事件源发送时间给 Broker，Broker 会处理其它工作。消费方服务只需要创建一个触发器，从 Broker 中接收它们感兴趣的事件即可。

新的事件源：Kanative 中加入了 Kafka 的事件源，将 Kafka 生态系统的丰富功能带给了 Knative 和 Kubernetes。

自动伸缩

自动伸缩功能增强，在重度工作负载的情况下，能够更平顺、更高效的完成伸缩动作。加入了更多的自动伸缩指标，增强了可观察性。

核心 API

新版本中，具名子路由的 URL 暴露在 Service 和 Route 资源的状态之中，就不用再猜测如何标记流量的分配状况了。这是 v1beta1 task force 中的第一个变化。后续版本中将会看到更多这方面的更新。

另外我们的 Webhook 中，很多缺省值都可以使用名为 config-defaults 的 Configmap 进行配置了。另外，在我们的控制器遇到内部错误时，会通过 Kubernetes 事件系统提供更好的可见性。最后，我们还扩展了我们的一致性测试，其中包含了对 securityContext 和 metadata.generateName 的支持。

网络

这一版本中，针对 gRPC 服务的冷启动和客户端的认证头处理有了很大提升。

Knative 0.5 的完整发布公告中包含了新功能和问题修复的完整列表，分别在 Serving、Build 和 Eventing 代码库中。

Istio 1.1 中的 Sidecar 资源

Wed, 10 Apr 2019 01:18:07 +0800

缺省情况下，Istio 在 Pod 创建之前将 istio-init 和 istio-proxy 注入到 Pod 之中，使用 istio-init 对 iptables 进行初始化，将业务容器的流量拦截到 istio-proxy，从而完成通信控制权的移交工作——应用容器的自发 Ingress 和 Egress 通信，都从 Envoy 中留过，Envoy 作为数据平面，需要接受来自控制面的 xDS 指令，据此作出通信决策。

在 Istio 1.1 中引入了 Sidecar 资源对象，为这一拦截转发过程加入了一定的控制能力，可能给 Istio 的生产应用带来很好的效率提升。

基本结构

Sidecar 资源的一级结构很简单，由三个成员构成：

workloadSelector：标签选择器，用来对 Pod 进行选择。这一字段是可选字段，如果忽略这一字段，则会对命名空间内的所有 Pod 生效。需要注意的是，一个命名空间之内，只允许存在一个不设置此字段的 Sidecar 对象。
ingress：一个数组，用于处理进入 Pod 的流量，如果省略这一字段，Istio 会根据业务应用的工作负载定义来设置监听过程。
- port：必要字段，监听的端口，如果使用 Unix domain socket，则设置为 0。
  - number
  - protocal
  - name
- bind：监听器的绑定设置，可以是 ip，也可以是 unix:///path/to/uds，如果省略这一字段，Istio 会根据工作负载服务来自动填充。
- captureMode：如果 bind 指定的是 IP 地址，这个字段可以指定是否拦截通信，如果绑定到 Unix domain socket，这一字段必须是 DEFAULT 或者 NONE。
- defaultEndpoint：必要字段，Envoy 接收进入 Pod 的流量之后的转发目标。目标可以是 127.0.0.1:PORT 或者 unix:///path/to/socket
egress：一个处理 Egress 流量的定义数组。
- port：监听器的端口，如果使用 Unix domain socket，则设为 0。
- bind：绑定到地址或 socket。
- captureMode：同 ingress。
- hosts：必要字段，用 命名空间/服务 FQDN 组合而成，可以是 VirtualService 或者 ServiceEntry 或者原始 Kubernetes 服务的名称，支持通配符。

开始之前

安装 Kubernetes 集群和 Istio，这里采用 1.1.2 的 demo-auth 配置。创建新命名空间 other，并打标签开启自动注入：

$ helm template install/kubernetes/helm/istio-init \
    --name istio-init --namespace istio-system | kubectl apply -f -
...
$ helm template install/kubernetes/helm/istio \
    --name istio --namespace istio-system \
    --values install/kubernetes/helm/istio/values-istio-demo-auth.yaml | kubectl apply -f -
...
$ kubectl create ns other
namespace/other created

$ kubectl label namespaces other istio-injection=enabled --overwrite
namespace/other labeled

$ kubectl label namespaces default istio-injection=enabled --overwrite
namespace/default labeled

分别在 default 和 other 中启动 flaskapp 和 sleep 应用。

$ kubectl apply -f sleep/sleep.yaml -n default
service/sleep created
deployment.extensions/sleep created
$ kubectl apply -f sleep/sleep.yaml -n other
service/sleep created
deployment.extensions/sleep created
$ kubectl apply -f httpbin/httpbin.yaml -n default
service/httpbin created
deployment.extensions/httpbin created
$ kubectl apply -f httpbin/httpbin.yaml -n other
service/httpbin created
deployment.extensions/httpbin created

检查一下调用关系：

$ kubectl exec -c sleep -it sleep-69bd44b5bb-vwpzf -- curl http://httpbin:8000/ip
{
  "origin": "127.0.0.1"
}

$ kubectl exec -c sleep -it sleep-69bd44b5bb-vwpzf -- curl http://httpbin.other:8000/ip
{
  "origin": "127.0.0.1"
}

服务的可见性

缺省情况下，注入了 Istio 的工作负载会进行全网格的传播，假设 default 和 other 两个不相干的命名空间，other 中有大量的服务，而 default 中只有几个，因为路由传播的关系，default 命名空间中的工作负载，其 Sidecar 也会带上 other 命名空间中的路由信息。例如：

$ istioctl proxy-config clusters sleep-69bd44b5bb-vwpzf | grep other
httpbin.other.svc.cluster.local 8000    -   outbound    &{EDS}
sleep.other.svc.cluster.local   80      -   outbound    &{EDS}

可以看到，在 default 命名空间中的 Pod，保存了其它命名空间中的路由信息。这不管是对内存消耗还是路由控制来说，都会造成一定浪费，我们可以定义一个 Sidecar 资源，限制 sleep 服务只访问同一命名空间的其他服务：

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: sleep
spec:
  workloadSelector:
    labels:
      app: sleep  
  egress:
  - hosts:
    - "default/*"

提交到集群，看看效果：

$ kubectl apply -f sleep-egress.yaml
sidecar.networking.istio.io/sleep created

$ istioctl proxy-config clusters sleep-69bd44b5bb-vwpzf | grep httpbin
httpbin.default.svc.cluster.local   8000    -   outbound    &{EDS}

可以看到，httpbin 的路由只剩下了本命名空间之内的服务。再次尝试访问：

$ kubectl exec -c sleep -it sleep-69bd44b5bb-vwpzf -- curl http://httpbin:8000/ip
{
  "origin": "127.0.0.1"
}

$ kubectl exec -c sleep -it sleep-69bd44b5bb-vwpzf -- curl -v http://httpbin.other:8000/ip
*   Trying 10.245.156.252...
* TCP_NODELAY set
* Connected to httpbin.other (10.245.156.252) port 8000 (#0)
> GET /ip HTTP/1.1
> Host: httpbin.other:8000
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< date: Wed, 10 Apr 2019 04:50:15 GMT
< server: envoy
< content-length: 0
<
* Connection #0 to host httpbin.other left intact

这样一来，已经无法访问 httpbin.other 的服务了，但是如果尝试从 other 到 default 访问的话，还是可以继续的。

Sidecar 的 Ingress 和 Egress

除了上面的小功能之外，Sidecar 的 IstioEgressListener 和 IstioIngressListener 都提供了很强大的功能，例如：

Envoy 可以为应用容器所监听的 Unix socket 提供反向代理服务。
在没有 iptables 支持的情况下，可以使用 bind 结合 port 的方式，直接指定代理方案。
可以在容器内部为 egress 服务提供基于 Unix socket 的反向代理。

详情可以参考官方参考文档：https://istio.io/docs/reference/config/networking/v1alpha3/sidecar/#IstioIngressListener

中文版：https://skyao.io/learning-istio/crd/network/sidecar.html

这些功能都非常有用，上面的文档中都提供了很好的应用场景，但是这些特性我只有可见性部分测试成功了(╬￣皿￣)=○，目前正在讨说法，非常希望是我错了。。

Istio 负载均衡的区域感知

Mon, 08 Apr 2019 13:45:32 +0800

Envoy/Istio 1.1 中有个有趣的新特性：负载均衡提供了区域感知的能力。简单说来，就是在分区部署的较大规模的集群，或者公有云上，Istio 负载均衡可以根据节点的区域标签，对调用目标做出就近选择。在跨区部署的应用中，原始的 Kubernetes 负载均衡可能会把来自 A 区的请求发送给远在 B 区的服务，造成高成本的跨区调用。要缩减这种损耗，通常都需要实现更多的逻辑，Istio 的区域感知特性在某种程度上提供了一种解决办法。

准备工作

接下来首先做一些琐碎的安装工作，这里选择了常见的 GCP 作为测试环境，Istio 版本为 1.1.2。

在 GCP 的 us-central1 创建一个区域集群：

$ gcloud beta container clusters create "standard-cluster-1" \
...
 --no-enable-basic-auth \
 --cluster-version "1.12.6-gke.10" \
 --machine-type "n1-standard-1" --image-type "COS" \
...
 --num-nodes "2" \
 --no-enable-cloud-logging --no-enable-cloud-monitoring \
...--no-enable-ip-alias \
 --addons HorizontalPodAutoscaling \
 --enable-autoupgrade --enable-autorepair

获取本地认证，为 kubectl 生成 context：

$ gcloud beta container clusters get-credentials \
standard-cluster-1 --region us-central1 \
--project dustise-mesh-lab

查看节点标签，这里会看到不同的节点会使用区域标签进行标识：

$ kubectl get nodes --show-labels

...
failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
...
failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-c
...

为 Istio 准备 RBAC：

$ kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole=cluster-admin \
    --user=$(gcloud config get-value core/account)

初始化 Istio CRD：

$ kubectl create namespace istio-system
$ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f -

configmap/istio-crd-10 created
configmap/istio-crd-11 created
serviceaccount/istio-init-service-account created
clusterrole.rbac.authorization.k8s.io/istio-init-istio-system created
clusterrolebinding.rbac.authorization.k8s.io/istio-init-admin-role-binding-istio-system created
job.batch/istio-init-crd-10 created
job.batch/istio-init-crd-11 created

安装 Isto：

$ helm template install/kubernetes/helm/istio \
    --name istio --namespace istio-system \
    --values install/kubernetes/helm/istio/values-istio-demo-auth.yaml | kubectl apply -f -
......
handler.config.istio.io/kubernetesenv created
rule.config.istio.io/kubeattrgenrulerule created
rule.config.istio.io/tcpkubeattrgenrulerule created
kubernetes.config.istio.io/attributes created
destinationrule.networking.istio.io/istio-policy created
destinationrule.networking.istio.io/istio-telemetry created

标记 default 命名空间，启动自动注入：

$ kubectl label namespaces default istio-injection=enabled --overwrite
kubectl namespace/default labeled

部署应用

为了方便演示，我们给惯用的 flaskapp 和 sleep 加上 NodeSelector，要求按照版本分布到不同区域的节点上，例如：

nodeSelector:
        failure-domain.beta.kubernetes.io/zone: us-central1-f

标签内容可以参照上文 kubectl get nodes --show-labels 的显示结果。

修改了部署清单之后，就可以部署了：

$ kubectl apply -f flaskapp/flaskapp.istio.yaml
service/flaskapp created
deployment.extensions/flaskapp-v1 created
deployment.extensions/flaskapp-v2 created
$ kubectl apply -f sleep/sleep.istio.yaml
service/sleep created
deployment.extensions/sleep-v1 created
deployment.extensions/sleep-v2 created
deployment.extensions/sleep-v3 created

稍候片刻，查看部署结果：

$ kubectl get pods -o wide
NAME                          READY   STATUS    RESTARTS   AGE   IP          NODE                                                NOMINATED NODE
flaskapp-v1-b9644bd75-g82nj   2/2     Running   0          92m   10.40.4.9   gke-standard-cluster-1-default-pool-0570ecb1-lm7q   <none>
flaskapp-v2-77d648fbd-cvfql   2/2     Running   0          92m   10.40.3.5   gke-standard-cluster-1-default-pool-f2347d89-q79k   <none>
sleep-v1-84c85c8946-c7bvc     2/2     Running   0          91m   10.40.1.3   gke-standard-cluster-1-default-pool-0570ecb1-1qnq   <none>
sleep-v2-57cf55db78-vrvtc     2/2     Running   0          92m   10.40.3.7   gke-standard-cluster-1-default-pool-f2347d89-q79k   <none>

和上文比较，可以看到，sleep 和 flaskapp 的 v1、v2 两个版本，分别运行在 us-central1-a 和 us-central1-f 中。

验证路由的区域感知功能

接下来分别从网格内部和 Ingress Gateway 来验证这一功能。

服务网格内部请求

$ kubectl exec -it -c sleep sleep-v1-84c85c8946-c7bvc bash
# for i in {1..10}; do http --body  http://flaskapp/env/version ; done
v1
v2
v2
v1
...

可以看到，请求被随机分配到不同的版本，也就是说，此时的调用是无视分区的。接下来我们设置 Pilot 的环境变量，启用区域感知功能，过程很简单，给它的 Pod 加入环境变量 PILOT_ENABLE_LOCALITY_LOAD_BALANCING，并任意赋值即可，例如：

- name: PILOT_TRACE_SAMPLING
  value: "100"
...
- name: PILOT_ENABLE_LOCALITY_LOAD_BALANCING
  value: "1"
...

再次进入 Pod 访问 flaskapp 服务：

$ kubectl exec -it -c sleep sleep-v1-84c85c8946-c7bvc bash
# for i in {1..10}; do http --body  http://flaskapp/env/version ; done
v1
v1
v1
...
# exit
$ kubectl exec -it -c sleep sleep-v2-57cf55db78-vrvtc bash
# for i in {1..10}; do http --body  http://flaskapp/env/version ; done
v2
v2
v2
...

可以看到，果然按照我们预想的情况，不同区域的请求，会交由不同区域的服务来进行响应。如果此时删除同区的目标负载，会发现开始平均访问其它区的服务。

Ingress 网关

Ingress 网关控制器在网格内同样也会分配到不同的节点上，因此也同样会受到区域的影响。例如我们为 flaskapp 创建一个 VirtualService + Gateway 的组合，引入外部流量：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: flaskapp-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "flaskapp.example.com"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - "flaskapp.example.com"
  gateways:
  - flaskapp-gateway
  http:
  - route:
    - destination:
        port:
          number: 80
        host: flaskapp

提交后，可以在外使用 curl --resolve 来验证：

$ export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
$ for i in {1..10}; do curl --resolve flaskapp.example.com:80:$INGRESS_HOST http://flaskapp.example.com/env/version ; done
v3v3v3v3v3v3v3v3v3v3

可以看到，对 Ingress Gateway 进入的流量，区域感知功能也是同样生效的。

区域间分流

如果只是简单的就近原则，虽然方便，但也难免有些枯燥，例如我的集群中的三个分区之间存在优先次序，或者强行指派一个区的请求需要由指定的其它分区的服务进行处理，又该怎样呢？

istio-system 中有个叫做 istio 的 configmap，其中包含了 Istio 的一些核心配置，里面的 LocalityLoadBalancerSetting，包含了对区域感知负载均衡的一些行为配置。例如我们分配所有分区的流量，都分配到前面两个区域：

    localityLbSetting:
      distribute:
      - from: us-central1/us-central1-a/*
        to:
          us-central1/us-central1-a/*: 90
          us-central1/us-central1-b/*: 10
      - from: us-central1/us-central1-b/*
        to:
          us-central1/us-central1-a/*: 90
          us-central1/us-central1-b/*: 10
      - from: us-central1/us-central1-f/*
        to:
          us-central1/us-central1-a/*: 90
          us-central1/us-central1-b/*: 10

应用之后，重启 Galley、Pilot、Injector，并重新注入应用，再次在不同分区的 sleep 容器中进行测试。会发现其中的请求呈现了符合配置要求的分配，并且没有发送到 us-central1-b 区。

事实上本次测试，并没有发现比率生效，仅达到有或无的区别。

结论

目前的分区域分流功能似乎还有些问题，但是不失为一个新的服务亲和思路。分区是基于 Kubernetes Node 标签完成的，通过对标签的调整（例如机柜、楼层），能够比较方便的在无侵入的情况下，实现就近调用，对服务的跨区 HA，有一定的辅助作用。

参考链接

Istio 负载均衡的区域感知：https://istio.io/help/ops/traffic-management/locality-load-balancing/
使用 Helm 安装 Istio：https://istio.io/docs/setup/kubernetes/install/helm/
Kubernetes 区域标签：https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domain-beta-kubernetes-io-region

混合微服务模式

Thu, 04 Apr 2019 01:23:56 +0800

原作者：Sonya Koptyev

原标题：Why a Microservices Hybrid Model Is What You Probably Need Instead

在听到别人谈及微服务的时候，你会注意到他们讨论的是一个非此即彼的问题：重构成微服务？还是固守单体形态？这种想法很合情理：微服务是个复杂的话题，把这个复杂性简化成一个二选一问题，就轻松了。

然而微服务实际上并不是一个非黑即白的概念。在应用中部分使用微服务，其它组件仍然保持单体应用的状态，这是一种完全有可能的情况。

这就成了一种混合模式的微服务。本文中我希望能解释一下混合微服务的具体含义，为什么会用到这种模式以及如何构建混合模式的微服务。

混合微服务的概念和来由

简单来说，混合微服务应用意味着应用的一部分是用微服务的方式来进行开发和部署，其它部分则还是单体形式。

可以将其与混合云相类比，混合云中包含了公有云、私有云，可能还有其它的自有基础设施。目前来看，混合云是一种流行的实践方式；实际上，可能很难找到一个完全单一云模式的组织。

如果我们能和混合云共处，那么也应该能够应对混合微服务架构。这种做法能够比较简单的获得微服务在弹性、容量和安全方面的好处，又无需使用微服务架构将传统应用完全重构。

对多数组织来说，将一个单体应用完全重构为微服务的过程中，对开发资源的调动是一个很严峻的问题；采用混合微服务策略是一个较好的方式，对开发团队来说，这种方式让微服务架构触手可及；否则的话，开发团队可能会因为时间、经验等方面的欠缺，无法接受对单体应用的重构工作。

构建混合微服务架构的最佳实践

混合微服务架构的基本概念很容易理解，但是实现起来就颇值得玩味了。首先面临的问题就是，需要对你的应用进行鉴别——哪些部分需要微服务改造，哪些部分需要保持单体形态。这里给出一些提示。

最大化收益的部分优先重构

最醒目也是最重要的事情就是，应用的哪些部分重构为微服务会获得最大收益。

哪些部分需要重构？要解答这个问题很明显根据实际情况来进行判断，但是还是存在一些指导性的微服务改造原则的：

伸缩性：你的应用中，可能有些部分需要比其它部分更多的实例数量。例如一个系统的首次访问可能需要登录，这就可能使得认证模块在某一时间出现峰值，而其它模块则不存在这种波动。这种情况下，将认证模块拆分出来形成独立的微服务，就能让你用更少资源来满足认证的峰值需要。
安全性：应用中哪一部分最多暴露在安全威胁之下？哪一部分最有可能被入侵从而影响到其它部分的安全？这些组件应该优先转换为微服务，这样有利于进行有效的隔离，降低安全风险。
更新：微服务的一个重要优势就是能够在不打扰其它微服务的情况下进行独立更新。有时一个应用中的不同组件会有不同的更新频率。有时候你会在很少更新后端的情况下，频繁的变更接口。这种情况下，可以把前端重构为一个或多个微服务，从而能够更容易的进行这部分的更新工作，让原有的后端继续以单体应用的形式进行。

正视微服务的复杂性

微服务有很多优势，但是也有其固有的缺陷：把系统变得更复杂。这种额外的复杂性，直接提升了开发和运维工作的难度。

正因如此，混合微服务的方式就很有意义了，可以尽可能的降低微服务引入的复杂性。例如哪一部分的 API 调用更少，或者哪一部分可以打包为独立的容器。如果优先对这些组件进行重构，就能够有效的减少 API 调用，降低容器化的难度。

面向未来

和混合云一样，混合微服务策略不是一蹴而就的。这是个持续的过程。可能起初只有一小部分的组件被独立出来成为了微服务，从而形成了混合微服务架构，但是不必止步于此，随着时间的推移和环境的变化，可能会有更多的重构需求。

所以在踏上混合微服务之路的时候，应该设计一个微服务的路线图。就算不具体到时间，至少也应该对你的混合微服务应用有一个基本的演进设想。

结论

我们都希望改善我们的单体应用，但实际情况是，多数情况下我们不会有足够的开发资源把单体应用迅速的重构为微服务架构。与其全盘放弃，不如考虑一下这种混合微服务架构。可以参考上面提出的标准，来决定需要进行微服务改造的模块，需求不够迫切的其它部分，继续以单体应用的模式提供服务。

Istio 1.1 中的限流问题

Sat, 23 Mar 2019 01:55:47 +0800

在 Istio 1.1 发布之后，对《深入浅出 Istio》一书中的例子进行了一遍快速的检查，发现限流功能已经无法使用了。

在解决了 Prometheus 的 Handler 问题之后，开始查看限流的问题。

Mixer 日志控制的两个小技巧

Mixer 策略相关内容比较多，经常需要查看 Policy 和 Telemetry 的日志，然而这两种进程的缺省日志都是很多的，可以用一点小技巧来进行清理。

GODEBUG

首先，Mixer 的两个 Deployment 中都会带有 GODEBUG 环境变量，用于开启调试信息，可以使用 kubectl edit 命令删除环境变量。

ControlZ

Istio 组件都带有 ControlZ 接口，可以用于控制和查看核心组件的一些配置信息，其端口都开放在 9876，可以用端口转发的方式打开进行调整，例如：

$ kubectl port-forward -n istio-system \
> istio-telemetry-c545bb9bd-x7jpz 9876:9876
Forwarding from 127.0.0.1:9876 -> 9876
Forwarding from [::1]:9876 -> 9876

然后就可以用浏览器打开 http://127.0.0.1:9876 进行调整了。

言归正传

应用书中的 YAML 代码的同时，可以打开 Mixer 的日志，会发现其中有几行错误：

error  failed to evaluate expression for field 'Dimensions[destination]'; unknown attribute destination.service
error  Instance not found: instance='dest-quota.quota'
error  No valid instances found                                                error  No valid actions found in rule

这里发现了一个无法识别的属性：destination.service。翻查文档发现，该属性在 Istio 1.0 的 Reference 中声明即将过期;在 1.1 中已经停用，因此将其改为 destination.service.host 即可正常使用。更新代码已经上传到随书代码库的 1.1 分支中的第八章内容里。

Istio 1.1 中的 Handler

Fri, 22 Mar 2019 19:18:15 +0800

一直觉得 Mixer 的功能会比较不稳定，这次在《深入浅出 Istio》一书的的验证过程中发现，Prometheus 的部分无法工作了，因此今天排查一下，也因此有了些收获，这里做一个简单的记录。

首先我发现，istio-system 中系统默认安装的 Prometheus 资源不见了：

$ kubectl get prometheus --all-namespaces
No resources found.

但是好在相关的 Rule 还在，写法有了一些变化，例如 istio-system 中的 promtcp 的定义：

apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
...
  name: promtcp
  namespace: istio-system
spec:
  actions:
  - handler: prometheus
    instances:
    - tcpbytesent.metric
    - tcpbytereceived.metric
  match: context.protocol == "tcp"

过去我们习惯的 Handler 填写一般会是 handler.prometheus，也就是名为 handler 的 prometheus 资源。例如官方文档中的写法：

# Rule to send metric instances to a Prometheus handler
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: doubleprom
  namespace: istio-system
spec:
  actions:
  - handler: doublehandler.prometheus
    instances:
    - doublerequestcount.metric

很明显的，1.1 的用法发生了变更，这个新用法中并没有提及对象名称，只知道名字是 prometheus。在 Istio 1.1 的 Helm 源码中搜索一下 name: prometheus 就会看到，在 helm/istio/charts/mixer/templates/config.yaml 中定义了一个对象，一个 handler 类型的对象：

apiVersion: "config.istio.io/v1alpha2"
kind: handler
metadata:
  name: prometheus

这样就可以查查他的定义了，运行 kubectl get -n istio-system handler prometheus -o yaml：

apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
...
  name: prometheus
  namespace: istio-system
...
spec:
  compiledAdapter: prometheus
  params:
    metrics:
    - instance_name: requestcount.metric.istio-system
...

是的，这个名为 prometheus 的 handler 对象和以前几乎一毛一样。现在有两种定义 Prometheus 的 Handler 了，对此开发给出的解释是，并非所有 Adapter 都会创建自己的 CRD，因此推荐共用的 Handler 类型来进行定义。

在 Reference 中对这一对象做了个大概的讲解。需要注意其中的 compiledAdapter: prometheus，用于指定 Adapter 类型。其中使用 compiledAdapter 和 adapter 两个字段分别用于描述进程内外的两种适配器类型。

因此在 1.1 中，Handler 真正的成为了 Handler，下面给出一个简单的定义，来讲解一下自定义指标中，新 Handler 的定义方法，其中给指标定义名称为 cxl_counter：

apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
  labels:
    app: mixer
    chart: mixer
    heritage: Tiller
    release: istio
  name: prometheus
spec:
  compiledAdapter: prometheus
  params:
    metrics:
      - instance_name: cxl.metric.default
        kind: COUNTER
        label_names:
          - source_app
          - source_workload
          - source_workload_namespace
          - source_version
          - destination_app
          - destination_workload
          - destination_workload_namespace
          - destination_version
          - destination_service
          - destination_service_name
          - destination_service_namespace
          - reporter
          - response_code
        name: cxl_counter
    metricsExpirationPolicy:
      metricsExpiryDuration: 10m

原有 Handler 的定义方式，同样的指标，定义为 double_counter：

apiVersion: config.istio.io/v1alpha2
kind: prometheus
metadata:
  name: handler
spec:
  metrics:
    - instance_name: cxl.metric.default
      kind: COUNTER
      label_names:
        - source_app
        - source_workload
        - source_workload_namespace
        - source_version
        - destination_app
        - destination_workload
        - destination_workload_namespace
        - destination_version
        - destination_service
        - destination_service_name
        - destination_service_namespace
        - reporter
        - response_code
      name: double_counter
  metricsExpirationPolicy:
    metricsExpiryDuration: 10m

用一个 Rule，将同样的指标分别输出到两个 Handler 之中：

apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: prom-http
spec:
  actions:
    - handler: prometheus
      instances:
        - cxl.metric
    - handler: handler.prometheus
      instances:
        - cxl.metric
  match: context.protocol == "http" || context.protocol == "grpc"

而指标的定义不变：

apiVersion: config.istio.io/v1alpha2
kind: metric
metadata:
  name: cxl
spec:
  dimensions:
    destination_app: destination.labels["app"] | "unknown"
    destination_service: destination.service.host | "unknown"
    destination_service_name: destination.service.name | "unknown"
    destination_service_namespace: destination.service.namespace | "unknown"
    destination_version: destination.labels["version"] | "unknown"
    destination_workload: destination.workload.name | "unknown"
    destination_workload_namespace: destination.workload.namespace | "unknown"
    source_app: source.labels["app"] | "unknown"
    source_version: source.labels["version"] | "unknown"
    source_workload: source.workload.name | "unknown"
    source_workload_namespace: source.workload.namespace | "unknown"
    reporter:
      conditional((context.reporter.kind | "inbound") == "outbound", "source",
      "destination")
    response_code: response.code | 200
  monitored_resource_type: '"UNSPECIFIED"'
  value: "2"

制造请求之后，会发现新旧 Handler 同时工作，并用各自的名字写入了指标。在 Prometheus 中即可查看。

这里真的要吐槽一句，Metric 定义中的所有 Label 需要照抄到 Handler 定义中，映射关系出错的时候，出的不是 Warning，而是 Panic。

涉及到的代码已经更新到版本库的 1.1 分支的第八章内容里。

《深入浅出 Istio》在 Istio 1.1 中的一些已知情况

Wed, 20 Mar 2019 23:51:05 +0800

《深入浅出 Istio》在编写之初，我大致估算了成书可能所需的工作量和完成时间，也预计了一下 Istio 1.1 可能的发布时间以及大略的变动范围，因此定下了入门书的调性。

Istio 1.1 推出后，就在第一时间进行了安装部署，对书中所涉代码进行了验证，一来是给读者一个交代，二来也是做个准备，根据 Istio 1.1 的变动，对本书进行更新。

验证结果如下：

章节	问题	备注
7.8	重试无法工作	HTTPRetry 结构发生变更。加入 `retryOn: 5xx` 即可。
7.11	1.11 中的 Helm chart 结构已经改变，不再适用。
8.4、8.5	限流不可用	正在排查中
8.6	Prometheus 监控指标定义失败	1.1 中的指标定义发生部分变化
9	RBAC 等相关对象发生大量变更，部分对象失效

如上表所示，除 7.8 节的问题很明确之外，其它问题的解决过程也会尽快的逐步更新出来。

随书代码已经新建 1.1 分支。

鸿沟前的服务网格—Istio 1.1 新特性预览

Wed, 13 Mar 2019 17:35:21 +0800

引子

这几天拜读了灵雀云出品的一篇文章：《从“鸿沟理论”看云原生》，其中有两段关于 Istio 的陈述，我深感赞同：

在 Control Plane，Istio 是最具光环的明星级项目。它正在引领 Service Mesh 创造出一个全新的市场，不过从传播周期看现在还没有跨过技术鸿沟，处于 Early adopters 阶段。
在开源领域，并不存在对Istio有实质性威胁的竞品。可能在经历了 Kubernetes 之后，以及 Istio 早期迅猛的发展和在社区中巨大的影响力之下，很少有开源项目愿意在 Control Plane 和 Istio 正面交锋。

按照我对 Istio 的理解，正如该文所说，正处于鸿沟一侧，正是从早期采用者到早期大众之间关键阶段。然而这一系统的情况又比较特殊，Service Mesh 的饼，虽说是 Linkerd 画出来的，然而真正把饼变大的，正是 Istio。Istio 画了硕大无朋的饼之后，就步步泥潭，功能薄弱、进度拖沓，让包括我在内的众多用户大摇其头。然而，画饼的另一面，就是挖坑——Istio 放出的漫天卫星，极大的吊起了各种用户的胃口，可以说是用先声夺人的方式，强行提高了门槛，要想赶超 Istio，首先就要接班，完成 Istio 的各种承诺，才能满足用户心目中对 Service Mesh 的“基本”期待。

Istio 1.1

Istio 自然还是在努力的完成满足早期用户要求的基础上，加强对早期大众的吸引。自 2018 年 7 月发布 1.0 之后，经过近 8 个月的漫长等待，千呼万唤的 1.1 又做出了什么样的变化，来帮助 Istio 来达成这样的目标呢？下面会介绍一些我所关注的 Istio 1.1 新特性。

缺省关闭 Mixer 策略检查

从 Istio 的早期版本开始，关于如何关闭 Mixer 策略检查的讨论就没有停止过，现在社区已经达成共识，绝大多数场景中，对性能的需求，其重要性是大于对预检功能的需求的，因此 1.1 版本中，缺省安装会关闭 Mixer 的这一功能。

缺省开放 Egress 通信

新增 global.outboundTrafficPolicy.mode 参数，用于定制 Egress 通信的缺省行为，目前的缺省值为 ALLOW_ANY，即允许全部 Egress 通信。

新增 Sidecar 资源

目前版本中，Sidecar 会包含整个网格内的服务信息，在 1.1 中，新建了 Sidecar 资源，通过对这一 CRD 的配置，不但能够限制 Sidecar 的相关服务的数量，从而降低资源占用，提高传播效率；还能方便的对 Sidecar 的代理行为做出更多的精细控制——例如对 Ingress 场景中的被代理端点的配置能力。

ExportTo

多个路由管理对象加入了这一字段，用于指定该资源的生效范围。

路由的区域感知能力

新增了对 AZ/Region 等的区域感知能力，降低跨区请求造成的性能损耗。

对 TCP 服务提供鉴权支持

在既有的 HTTP/gRPC 之外，又为 TCP 服务提供了 RBAC 功能。

引入 SDS 完成证书流程

弃用原有的 Citadel->Secret->Sidecar 的证书流程，改用 Secret Discovery Service 完成。从而降低了安全风险，并且更新证书也无需重新启动了。

硬广

拙作《深入浅出 Istio》是基于 1.0.x 版本编写，目前已经将绝大多数 YAML 源码上传至 Github，目测绝大多数功能在 1.1 上是可用的；预备在 Istio 1.1 正式发布后，逐章进行校验。在征得出版方同意之后，会以补充文档的方式，在 Github 上，进行勘误以及增补，以保障本书相关内容的及时性。

购买链接

代码仓库链接

从 Metric Server 到 Kubelet 服务证书

Wed, 27 Feb 2019 21:30:31 +0800

很少用 Kubeadm，一直用自有 CA 签发证书，所以 TLS Bootstrap 也极少接触，然后乐子就来了。

$ git clone https://github.com/kubernetes-incubator/metrics-server.git
$ cd metrics-server/deploy/1.8+
$ kubectl apply -f .
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
...

使用 kubectl top nodes，返回的永远都是 error: metrics not available yet。kubectl logs metrics-server-fc6d4999b-58xtc 查看日志，其中大量的：

unable to fetch metrics from Kubelet node-standard-3 (node-standard-3): Get https://node-standard-3:10250/stats/summary/: x509: certificate signed by unknown authority]

检查一下，很明显，kubelet 提供的 https 服务使用了未经认可的 CA：

$ openssl s_client -showcerts -connect node-standard-3:10250
...
    Verify return code: 19 (self signed certificate in certificate chain)
...

Metric Server 支持一个参数 --kubelet-insecure-tls，可以跳过这一检查，然而官方也明确说了，这种方式不推荐生产使用。

这时候我又想到个问题，那 API Server 是怎么访问 Kubelet 的？最后我看到，API Server 中有一行注释：

// Proxying to pods and services is IP-based... don't expect to be able to verify the hostname
proxyTLSClientConfig := &tls.Config{InsecureSkipVerify: true}

那么问题来了，如何让 Kubelet 具备一个“正式”的证书，让各种组件可以放心的使用 TLS 进行访问呢？查阅资料发现，目前的 kubeadm 流程中，kubelet 的 Bootstrap 因为节点动态的原因，已经不再自动完成 Kubelet 服务端点的证书签发了，使用统一 CA 自行签署，或者恢复 Bootstrap 中的服务证书申请流程，也就能完成任务了。

Kubelet 的 config.yaml 中加入一行：serverTLSBootstrap: true，即可启动这一过程。重启 Kubelet，会发现出现了新的 CSR：

$ kubectl get csr
NAME        AGE     REQUESTOR                     CONDITION
csr-f29hk   5s      system:node:node-standard-2   Pending
csr-n9pvr   3m31s   system:node:node-standard-3   Pending

如果使用 base64 -d 对 csr 的 request 字段做解码，并查看其请求内容的话，会发现：

$ openssl req -in csr.pem -noout -text
...
X509v3 Subject Alternative Name:
                DNS:node-standard-2, IP Address:10.211.55.28
...

证书请求中已经带有了 SAN 记录。

$ kubectl certificate approve csr-n9pvr
certificatesigningrequest.certificates.k8s.io/csr-n9pvr approved

通过之后，Kubelet 就有了使用 API Server 的 CA 签发的证书了。

稍等片刻，再次执行 kubectl top nodes：

$ kubectl top nodes
NAME              CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
node-standard-1   213m         10%    1220Mi          70%
node-standard-2   71m          3%     361Mi           20%
node-standard-3   61m          3%     355Mi           20%

VirtualService 的校验脚本

Fri, 22 Feb 2019 20:59:42 +0800

Istio 的流量控制功能中，VirtualService 和 DestinationRule 对象之间具有很强的关联性；另外这些规则需要用标签的形式落地到 Kubernetes 中的 Service 和 Pod 中，很多时候因为操作不慎导致的一点小错误，例如标签错误、缺少 subset 定义、选择器冲突等，都会导致功能完全失效，因此就写了这个小脚本，从头到尾检查一遍相关配置。用法很简单：

./virtual-service-scanner.py flaskapp-default-v2
Validating VirtualService: flaskapp-default-v2
Destinations referenced: {'flaskapp.default.svc.cluster.local': ['v2', 'v3']}
Fetching all destination rules in current namespace.
Validating subsets of host flaskapp.default.svc.cluster.local
Service label is: {'app': 'flaskapp'}
Subset label is: {'version': 'v2'}
Pod selector: app=flaskapp,version=v2
1 pods found
Traceback (most recent call last):
  File "./virtual-service-scanner.py", line 148, in <module>
    main()
  File "./virtual-service-scanner.py", line 88, in main
    verify_virtualservice(args.object_name, kubectl_command)
  File "./virtual-service-scanner.py", line 117, in verify_virtualservice
    "Subset {} isn't defined.".format(subset_name)
AssertionError: Subset v3 isn't defined.

virtual-service-scanner.py [VirtualService]

会根据其中引用的 host、subset 对其依赖的 DestinationRule、Service 以及 Pod 进行逐一检查，如果其中有环节无法通过，脚本会出错退出，例如上面的例子中，VirtualService 引用了不存在的 subset： v3。

项目地址：Github

Calico 3.5：根据节点标签分配 IP 地址

Fri, 08 Feb 2019 11:15:50 +0800

原文：Assigning IP addresses based on topology

关于 IP 地址的分配

Calico 能够进行配置，为不同拓扑指定 IP 地址池。例如可能希望某些机架、地区、或者区域能够从同一个 IP 池中获取地址。这对于降低路由数量或者配合防火墙策略的要求会很有帮助。

cni 插件配置参考中的 IP 地址管理章节中包含了三种分配 IP 地址的方式。Kubernetes 注解方式只能用于 Namespace 或者 Pod 一级。剩下的只有两个办法，CNI 配置或者是基于节点选择器的 IP 池，相对于 CNI 配置的方式来说，节点选择器方案省去了修改本地文件的麻烦。

在更高层次上，基于节点选择器的 IP 地址分配方法就是给节点设置标签，然后用节点选择器选择对应的 IP 地址池进行分配。后面的内容中将给出一个详细的例子，用这种方式来设置一种机架亲和方式的 IP 地址分配方案。

如果 Calico 无法根据上述顺序来决定一个 IP 地址池，或者在选定的地址池中找不到可用的 IP 地址，那么这一工作负载就不会分到 IP 地址，无法启动。为了防止这种情况的发生，我们建议所有节点至少有一个合适的地址池。

先决条件

这一功能需要 Calico 在 ETCD 模式下工作。

示例：Kubernetes

本例中，我们会创建一个集群，其中包含四个节点，分布在两个机架上，每个机架各两台。示意如下：

       -------------------
       |    router       |
       -------------------
       |                 |
---------------   ---------------
| rack-0      |   | rack-1      |
---------------   ---------------
| kube-node-0 |   | kube-node-2 |
- - - - - - - -   - - - - - - - -
| kube-node-1 |   | kube-node-3 |
- - - - - - - -   - - - - - - - -

Pod IP 地址范围为 192.168.0.0/16，我们进行如下设计：保留 192.168.0.0/24 给 rack-0, 192.168.1.0/24 给 rack-1。

要设置一个没有缺省地址池的的 Calico，首先运行 calicoctl get ippool -o wide，会看到已经创建了一个 192.168.0.0/16 的地址池：

NAME                  CIDR             NAT    IPIPMODE   DISABLED   SELECTOR
default-ipv4-ippool   192.168.0.0/16   true   Always     false      all()

删除缺省地址池

default-ipv4-ippool 地址池已经存在，并占据了整个 /16 块，因此必须删除：calicoctl delete ippools default-ipv4-ippool

给 Node 打标签。

要给特定节点分配地址池，节点必须用标签进行标识：

kubectl label nodes kube-node-0 rack=0
kubectl label nodes kube-node-1 rack=0
kubectl label nodes kube-node-2 rack=1
kubectl label nodes kube-node-3 rack=1

为每个机架创建地址池

calicoctl create -f -<<EOF
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: rack-0-ippool
spec:
  cidr: 192.168.0.0/24
  ipipMode: Always
  natOutgoing: true
  nodeSelector: rack == "0"
EOF

calicoctl create -f -<<EOF
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: rack-1-ippool
spec:
  cidr: 192.168.1.0/24
  ipipMode: Always
  natOutgoing: true
  nodeSelector: rack == "1"
EOF

现在就创建了两个地址池，使用 calicoctl get ippool -o wide 进行查看：

NAME                  CIDR             NAT    IPIPMODE   DISABLED   SELECTOR
rack-1-ippool         192.168.0.0/24   true   Always     false      rack == "0"
rack-2-ippool         192.168.1.0/24   true   Always     false      rack == "1"

检查地址池的工作状态

创建一个 Nginx 的 Deployment，其中包含五个副本，保证分配到每一个节点上。

kubectl run nginx --image nginx --replicas 5

检查新的 Pod 是否已经根据所在机架获得了应有的 IP 地址。

NAME                   READY   STATUS    RESTARTS   AGE    IP             NODE          NOMINATED NODE   READINESS GATES
nginx-5c7588df-prx4z   1/1     Running   0          6m3s   192.168.0.64   kube-node-0   <none>           <none>
nginx-5c7588df-s7qw6   1/1     Running   0          6m7s   192.168.0.129  kube-node-1   <none>           <none>
nginx-5c7588df-w7r7g   1/1     Running   0          6m3s   192.168.1.65   kube-node-2   <none>           <none>
nginx-5c7588df-62lnf   1/1     Running   0          6m3s   192.168.1.1    kube-node-3   <none>           <none>
nginx-5c7588df-pnsvv   1/1     Running   0          6m3s   192.168.1.64   kube-node-2   <none>           <none>

可以看到，IP 地址的是根据节点（所在的机架）来选择了对应的地址池进行分配的。