kubernetes | 伪架构师

不用 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 之类的东西的话，勉强也算各擅胜场。

持续监控集群中的镜像漏洞——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 写了一点代码

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 为 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 的版图。

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 都不好做了？

介绍一个小工具：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 装上马鞍之后，丢的不只是风阻和车顶，至少车友群是不太容易混了。

用 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，这个方案可能就难于落地了，方案的复杂部分主要是由这两个项目完成的，也正因为此，我们对我们的方案充满信心，这里对他们致以崇高敬意。

用 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>

借助 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 环境中检查镜像签名的一种方法

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 来强制实施）。

介绍一个小工具：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"
    },

送容器下乡

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 还是真香的。

介绍一个不太小的工具：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，对我们编写的规则作出很多支持。

伸手党的容器镜像加固流程

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 把官方镜像中的应用文件复制出来即可。

复测

在完成修复步骤之后，可以针对性地进行复测，查看修复情况，循环往复直到完成目标为止。

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，所有写入需求应该使用存储卷来完成；
避免特权逃逸。

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/

在 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 即可。

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

简介：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

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

应用未迁，资源先行

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 是你的好朋友。

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 对象，猜测这个模型在公有云、多云以及混合云下，可能会有相当大的想象空间。

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

可能是最适合自定义的 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 了。。

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/

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 中。

介绍一个小工具：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/

介绍一个小工具：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

介绍一个小工具：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

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 和内存的消耗。我会持续关注，并分享更多。

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 还是你的好朋友。

如何参与 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 来促成这一进步。

关于 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 的采用过程。

从 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%

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 地址的是根据节点（所在的机架）来选择了对应的地址池进行分配的。

开发和 Kubernetes 之间的鸿沟

Tue, 05 Feb 2019 22:01:13 +0800

原文：There’s a Gap Between Devs and Kubernetes

作者：Kent Rancourt

我用 Kubernetes 谋生，多数时间里，我都在为 Kubernetes 开发开源软件平台、中间件以及工具。我经常会问我自己以及我的同事：“我们要解决的问题是什么？”以及“我们要为谁解决问题？”。这种提问让我们能够保持对目标的专注，明确产品的价值。我也会把类似的问题抛给前同事们以及本地 Meetup 的参与者——他们各自的公司都在 “Kubernetes 之旅”的途中。如果他们正在构建或准备采用的是一个新的 Kubernetes 的相关工具，我通常会询问要解决的问题以及为谁解决问题。更多情况下，我会询问他们在采用 Kubernetes 的过程中遇到的问题。

不管采用 Kubernetes 的进度如何，两个回应是最常见的。第一个是“Kubernetes 太难了”，另一个是“Kubernetes 的抽象是错的”。第二个问题经常会用设问的方式提出：“Kubernetes 的抽象对么？”。

这种陈述缺乏了重要的上下文。其中没有澄清 Kubernetes 对谁来说太难了？对谁来说抽象有问题？在进一步的探求中，我得到的答案基本上来说是一致的：“开发者”。那么前面的陈述就可以修正为：Kubernetes 对开发者来说太难了，对开发者来说，Kubernetes 的抽象是不对的。

“对开发者来说，Kubernetes 的抽象是错误的”，这个陈述通常的意思就是，Kubernetes 只提供了用于声明应用部署和服务的原语，而开发者更多关注的是商业价值的交付过程，而非 Kubernetes 细枝末节的学习，Kubernetes 没有提供更符合开发者期待的抽象模型。它没有提供部署应用的直接选项。两个问题合二为一——对于开发者来说，Kubernetes 的抽象是错误的，因此就太难了。

对此，我的观点是，Kubernetes 不是为开发者而生的。很多人会同意我的观点，但是令人惊奇的是，很多人压根没想过这个问题。

更少就是更多？对开发者来说，正确的抽象就是完全不抽象？毕竟在 Kubernetes 甚至是 Docker 诞生之前的几十年里，开发者一直使用自己惯用的技术栈进行开发和测试，所谓的应用抽象（或者 Kubernetes）的缺失，并不会让这些工作无法进行。我对开发者的建议是，开发者可以不关注 Kubernetes。

Kubernetes 是谁的？

在 Kubernetes 之前，组织中会存在一个角色，可以称其为部署专家，这个角色的职责是构建并部署应用和服务。他们需要对平台或相应的技术堆栈有着相当详细的认识，还可能需要一些复杂的、深奥的知识背景，有些自制的部署工具，以及大量的脚本。其工作可能是：部署 Ruby 应用、Python 应用、Tomcat 上的 Java 应用、WebSphere 应用等等不同的任务。这些人才是 Kubernetes 的目标用户——他们熟知应用部署的知识。Kubernetes 为这些用户提提供了能描述所有（容器化）应用的一致的部署模型，能够很好地提高其生产力并降低其学习成本。

经常有一个对 Kubernetes 的误解就是平台（“平台即服务”中的平台），其实它不是。即使是清楚这一点的人也往往对此视而不见，这样就会忽视掉部署专家这一角色的存在。潜意识中，对开发人员产生了一种不切实际的期望：他们应该能够自己使用 Kubernetes，从而可以取代部署专家这一角色。

知道了这些，也就成功了一半了。Kubernetes 并非为开发人员而生，更进一步思考，有三个可能的办法。

我认为最好将开发专家的角色重新加入组织。要完成这一过程，部署专家必须融入到开发团队中，或至少与开发团队紧密合作——和过去一样。我倾向于这种方法的原因是一个称职的部署专家能够优化部署并完成复杂的场景，其他方法难于做到这一点。不幸的是，这种办法可能最难落地。这种方式要对组织进行改进而非技术，从而弥合开发者和 Kubernetes 之间的鸿沟，但是大多数组织缺乏这样的自觉和进取心。
可能你是一个初创企业，只有五个开发者，没人想再承担一个部署专家的角色；又可能你是一个有几千开发者的企业，无法将部署专家的角色扩展到支持整个开发团队，资源限制之下，第一个办法无法实施。这种情况下，就只能靠工具或者平台之类的技术手段来拉近开发者和 Kubernetes 了。坦率的说，这就是我和很多人的饭碗。然而不要低估识别和构建合适方案的成本（自建平台正在大行其道），其所需成本可能轻松地超越第一种方法。另外也不应忽视的一点是，平台和工具也都有自己的侧重点，可能会让用户陷入新的困境。用两个新问题解决一个旧问题可能不是个好办法。
最后一点，可能你的组织还没有准备好采用 Kubernetes——甚至可能并不需要它。如果一个 Heroku 这样的 PaaS 甚至一个非 Kubernetes 的自建平台能够满足组织的需求，为什么还要给 Kubernetes 缴税？这种情况下，消灭开发人员和 Kubernetes 之间鸿沟的最好方法就是——不要使用 Kubernetes。再次提醒：准备好受到限制，并清楚认识未来走向。

结论

Kubernetes 并非为开发者而生，不要太快的认为，技术是唯一填补这一鸿沟的方法。强烈建议考虑，首先在组织层面做出改变。

Google 宣布 Kubernetes Operator for Spark

Fri, 01 Feb 2019 18:29:25 +0800

作者：Andrew Brust

原文：Google announces Kubernetes Operator for Apache Spark

“Spark Operator” 的 Beta 版本，可以用来在 Kubernetes 上执行原生 Spark 应用，无需 Hadoop 或 Mesos。

Apache Spark是一个流行的执行框架，用于执行数据工程和机器学习方面的工作负载。他提供 Databricks 平台的支持，可用于内部部署的或者公有云的 Hadoop 服务，例如 Azure HDInsight、Amazon EMR、以及 Google Cloud Dataproc，也可以在 Mesos 集群上运行。

但是如果只是想在 Kubernetes(k8s) 而非 Mesos 上运行 Spark 工作负载，也不想使用 YARN，这可行么？Spark 在 2.3 版本中首次加入了针对 Kubernetes 的功能，并在 2.4 中进行了进一步增强，然而让 Spark 用全集成的方式原生运行在 Kubernetes 上，仍然是非常有挑战的。

Kube Operator

Kubernetes 的始作俑者 Google，宣布了 Kubernetes Operator for Apache Spark 的 Beta 版本，简称 Spark Operator。Spark Operator 让 Spark 可以原生运行在 Kubernetes 集群上。 Spark 应用（这些应用用于分析、数据工程或者机器学习）可以部署在这些集群上运行，像在其它集群上一样。

Google 声明，Spark Operator 是一个 Kubernetes 自定义控制器，其中使用自定义资源来声明 Spark 应用的元数据；它还支持自动重启动以及基于 cron 的计划任务。今后，开发者、数据工程师以及数据科学家可以创建声明式的规范，来描述他们的 Spark 应用，并使用原生的 Kubernetes 工具（例如 Kubectl）来管理他们的应用。

现在就试试

Spark Operator 目前在 GCP 的 Kubernetes 市场中已经可用，可以方便的部署到 Google Kubernetes Engine(GKE)。另外 Spark Operator 是一个开源项目，能够部署在任何 Kubernetes 环境中，项目的 Github 页面提供了基于 Helm Chart 的安装指南。

如果 Amazon 和微软这样的厂商任何并在自家的 Kubernetes 服务上（微软的 AKS 以及 Amazon 的 ECS）提供 Spark Operator 的部署方式，会是个有意思的局面。这对他们的客户来说会是一个很棒的服务，客户并不想要在 EMR、HDInsight 或者 Daabricks 的工作空间和集群上付出开销。

Hadoop 怎么办

很多非 Databricks 的 Spark 集群是运行在 Hadoop 上的。Spark Operators 的出现，是否意味着 Hadoop 的影响被削弱了？Hadoop 团队也并非游手好闲之辈，例如开放混合架构草案就聚焦于 Hadoop 的容器化。另外上周发布的 Hadoop 3.2，其功能就包括了对 Tensorflow 的支持，Azure Data Lake Storage Gen2 的链接支持以及增强的Amazon S3 的增强支持。

消费者和往常一样，将在激烈的竞争中获益。

在 Knative 中进行应用程序的构建和部署

Tue, 13 Nov 2018 00:10:38 +0800

原文：Building and deploying applications to Knative

作者：Dr Nic Williams

Knative 有三个高级子系统：Serving 用来协调服务 Pod 的自动伸缩以及路由；Build 提供了将代码转换为镜像的工具链；Eventing 则会使用事件的发布订阅来触发松耦合服务。

前一篇文章中我们将一个构件好的容器镜像发布到了 Knative Serving 中。

本篇文章将使用 Knative Build 把我们的应用通过 Dockerfile 以及 Cloud Foundry buildpack 在发布过程中转化为容器镜像。我们还会尝试从本地文件系统以及远程 Git 仓库中进行部署的方式。

前面的操作都很简单，看得出在 Kubernetes 环境中安装 Knative、运行现有容器镜像、使用 curl 与应用进行交互都不难。总结一下就是：

knctl install [--node-ports] [--exclude-monitoring]
knctl deploy --service <service-name> --image <image-name>
knctl curl --service <service-name>

后面的两步 - 把镜像部署为 Kubernetes 并运行，为每个部署进行版本化处理，使用 HTTP 路由进行交互，都是 Serving 子系统的功劳。

Knative 还支持用于构建容器镜像的弹性子系统，构建生成的镜像将会以 Kubernetes Pod 的形式运行。

Knative Build 子系统非常有弹性。我们会探讨集中用例：

上传一个本地目录，使用 Dockerfile 进行构建。
上传一个本地目录，使用 Buildpack 进行构建。
用上面两种方式来构建来自于远程 Git 仓库的代码。

命名空间

前一篇文章中我们在每个 knctl 命令中使用了 --namespace helloworld 参数来显式的指定命名空间。对我来说这样显得更清晰。可能有别的用户希望设置一个缺省命名空间，从而能够缩短命令。

可以给 knctl 配置一个当前命名空间：

kubectl create ns my-simple-app
export KNCTL_NAMESPACE=my-simple-app

所有的 knctl 命令都会使用这一命名空间。

$ knctl service list
Services in namespace 'my-simple-app'

Name  Domain  Annotations  Age

0 services

可以在 kubectl 命令中复用 $KNCTL_NAMESPACE：

kubectl get pods -n $KNCTL_NAMESPACE

上传一个带有 Dockerfile 的本地目录

在所有 Knative Build 的示例中，都会产生一个副产品——容器镜像。这些镜像必须放在什么地方，例如 Docker Hub、GCP 容器库、Azure 容器库，或者借助 Harbor 之类的软件自建的私库。

我们需要在每个应用所在的 Kubernetes 命名空间中给 Knative 配置一个镜像库，然后 knctl basic-auth-secret create 给 Knative 配置一个 Secret。

以 Docker Hub 为例，使用 --docker-hub：

knctl basic-auth-secret create -s registry --docker-hub -u <username> -p <password>

GCP 容器仓库可以使用 --gcr 选项：

knctl basic-auth-secret create -s registry --gcr -u <username> -p <password>

其它私库可以使用 --type 和 --url：

knctl basic-auth-secret create -s registry --type docker --url https://registry.domain.com/ -u <username> -p <password>

下一步把镜像库 Secret 映射到 Kubernetes Service account，它会在 Knative Build 的 Pod 中提供上面的登录信息。

knctl service-account create --service-account build -s registry

这个操作会体现在 Kubernetes 的 Service account 中：

$ kubectl get serviceaccount -n $KNCTL_NAMESPACE
NAME      SECRETS   AGE
build     2         37s
default   1         3h

这样我们就准备好使用 Knative Build 创建新容器镜像所需的认证凭据了。

Clone 一个 Go 应用作为样例，并从它的本地目录推送到 Docker hub：

git clone https://github.com/cppforlife/simple-app
cd simple-app

DOCKER_IMAGE=index.docker.io/<your hub.docker.com org or user>/knative-simple-app

knctl deploy \
    --service simple-app \
    --directory=$PWD \
    --service-account build \
    --image ${DOCKER_IMAGE:?required} \
    --env SIMPLE_MSG="Built from local directory using Dockerfile"

容器的显式命名事实上只是从 Build 到 Serve 的工作过程中的一个中间步骤的副产品，但是必须提供。

knctl deploy 的输出大概是这样的：

Name  simple-app

Waiting for new revision to be created...

Tagging new revision 'simple-app-00001' as 'latest'

Tagging new revision 'simple-app-00001' as 'previous'

[2018-10-15T13:18:31+10:00] Uploading source code...

[2018-10-15T13:19:59+10:00] Finished uploading source code...

Watching build logs...

build-step-build-and-push | INFO[0000] Downloading base image golang:1.10.1
build-step-build-and-push | ERROR: logging before flag.Parse: E1015 03:20:01.547607       1 metadata.go:142] while reading 'google-dockercfg' metadata: http status code: 404 while fetching url http://metadata.google.internal./computeMetadata/v1/instance/attributes/google-dockercfg
build-step-build-and-push | ERROR: logging before flag.Parse: E1015 03:20:01.550268       1 metadata.go:159] while reading 'google-dockercfg-url' metadata: http status code: 404 while fetching url http://metadata.google.internal./computeMetadata/v1/instance/attributes/google-dockercfg-url
build-step-build-and-push | INFO[0001] Executing 0 build triggers
build-step-build-and-push | INFO[0001] Extracting layer 0
build-step-build-and-push | INFO[0003] Extracting layer 1
build-step-build-and-push | INFO[0004] Extracting layer 2
build-step-build-and-push | INFO[0004] Extracting layer 3
build-step-build-and-push | INFO[0007] Extracting layer 4
build-step-build-and-push | INFO[0010] Extracting layer 5
build-step-build-and-push | INFO[0015] Extracting layer 6
build-step-build-and-push | INFO[0015] Taking snapshot of full filesystem...
build-step-build-and-push | INFO[0027] WORKDIR /go/src/github.com/mchmarny/simple-app/
build-step-build-and-push | INFO[0027] cmd: workdir
build-step-build-and-push | INFO[0027] Changed working directory to /go/src/github.com/mchmarny/simple-app/
build-step-build-and-push | INFO[0027] Creating directory /go/src/github.com/mchmarny/simple-app/
build-step-build-and-push | INFO[0027] COPY . .
build-step-build-and-push | INFO[0027] RUN CGO_ENABLED=0 GOOS=linux go build -v -o app
build-step-build-and-push | INFO[0027] cmd: /bin/sh
build-step-build-and-push | INFO[0027] args: [-c CGO_ENABLED=0 GOOS=linux go build -v -o app]
build-step-build-and-push | net
build-step-build-and-push | vendor/golang_org/x/net/lex/httplex
build-step-build-and-push | vendor/golang_org/x/net/proxy
build-step-build-and-push | net/textproto
build-step-build-and-push | crypto/x509
build-step-build-and-push | crypto/tls
build-step-build-and-push | net/http/httptrace
build-step-build-and-push | net/http
build-step-build-and-push | github.com/mchmarny/simple-app
build-step-build-and-push | INFO[0030] Taking snapshot of full filesystem...
build-step-build-and-push | INFO[0034] Storing source image from stage 0 at path /kaniko/stages/0
build-step-build-and-push | INFO[0038] trying to extract to /kaniko/0
build-step-build-and-push | INFO[0038] Extracting layer 0
build-step-build-and-push | INFO[0040] Extracting layer 1
build-step-build-and-push | INFO[0041] Extracting layer 2
build-step-build-and-push | INFO[0041] Extracting layer 3
build-step-build-and-push | INFO[0043] Extracting layer 4
build-step-build-and-push | INFO[0046] Extracting layer 5
build-step-build-and-push | INFO[0051] Extracting layer 6
build-step-build-and-push | INFO[0051] Extracting layer 7
build-step-build-and-push | INFO[0051] Deleting filesystem...
build-step-build-and-push | INFO[0053] No base image, nothing to extract
build-step-build-and-push | INFO[0053] Taking snapshot of full filesystem...
build-step-build-and-push | INFO[0062] COPY --from=0 /go/src/github.com/mchmarny/simple-app/app .
build-step-build-and-push | INFO[0063] Taking snapshot of files...
build-step-build-and-push | INFO[0063] EXPOSE 8080
build-step-build-and-push | INFO[0063] cmd: EXPOSE
build-step-build-and-push | INFO[0063] Adding exposed port: 8080/tcp
build-step-build-and-push | INFO[0063] ENTRYPOINT ["/app"]
build-step-build-and-push | ERROR: logging before flag.Parse: E1015 03:21:04.751338       1 metadata.go:142] while reading 'google-dockercfg' metadata: http status code: 404 while fetching url http://metadata.google.internal./computeMetadata/v1/instance/attributes/google-dockercfg
build-step-build-and-push | ERROR: logging before flag.Parse: E1015 03:21:04.753927       1 metadata.go:159] while reading 'google-dockercfg-url' metadata: http status code: 404 while fetching url http://metadata.google.internal./computeMetadata/v1/instance/attributes/google-dockercfg-url
build-step-build-and-push | 2018/10/15 03:21:06 pushed blob sha256:72a682eea3309941d5e8e6f993a07ae4d33a413b8b7fa2762f8e969310b5996a
build-step-build-and-push | 2018/10/15 03:21:07 pushed blob sha256:9c24aa788ba416c5e1e631d8af3e3115519ad7ca0f659ac10f40682524c6d9cd
build-step-build-and-push | 2018/10/15 03:21:07 index.docker.io/drnic/knative-simple-app:latest: digest: sha256:b5823ead77d9544998b5bc844f049d1a7dfb0aefe7461b74b3e4f67fb5481fa1 size: 428
nop | Nothing to push

Succeeded

Knative Build 的调试

目前 knctl deploy 没有显示任何来自 Knative Build 系统的内部错误或者警告。只需要看着 Waiting for new revision to be created... 坐享其成就可以了。

一个调试方法就是使用 kail 工具处理来自 Knative Build 子系统的消息：

kail -n knative-build

这样就会看到大量的日志，可以再其中查找错误信息，例如 "msg":"Failed the resource specific validation{error 25 0 serviceaccounts \"build\" not found}"。

使用 Buildpack 进行构建

我本人很喜欢 Cloud Foundry 和 Heroku 的镜像构建方式，幸运的是，Knative Build 通过自定义构建模板的方式提供了这种支持。

首先用 buildpack 这个名字在活动命名空间中注册一个构建模板：

kubectl -n $KNCTL_NAMESPACE apply -f \
https://raw.githubusercontent.com/knative/build-templates/master/buildpack/buildpack.yaml

加入 --template buildpack 就可以使用这一自定义模板了。构建模板所需的附加环境变量都可以用 --template-env NAME=value 的方式进行植入。

例如 Cloud Foundry Go Buildpack 需要 $GOPACKNAME（参考文档）：

knctl deploy \
    --service simple-app \
    --directory=$PWD \
    --service-account build \
    --image ${DOCKER_IMAGE:?required} \
    --env SIMPLE_MSG="Built from local directory using Buildpack template" \
    --template buildpack \
    --template-env GOPACKAGENAME=main

输出内容和 Cloud Foundry buildpack 是一致的：

Name  simple-app

Waiting for new revision (after revision 'simple-app-00001') to be created...

Tagging new revision 'simple-app-00002' as 'latest'

Tagging older revision 'simple-app-00001' as 'previous'

[2018-10-15T13:40:41+10:00] Uploading source code...

[2018-10-15T13:42:08+10:00] Finished uploading source code...

Watching build logs...

build-step-build | -----> Go Buildpack version 1.8.26
build-step-build | -----> Installing godep 80
build-step-build |        Download [https://buildpacks.cloudfoundry.org/dependencies/godep/godep-v80-linux-x64-cflinuxfs2-06cdb761.tgz]
build-step-build | -----> Installing glide 0.13.1
build-step-build |        Download [https://buildpacks.cloudfoundry.org/dependencies/glide/glide-v0.13.1-linux-x64-cflinuxfs2-aab48c6b.tgz]
build-step-build | -----> Installing dep 0.5.0
build-step-build |        Download [https://buildpacks.cloudfoundry.org/dependencies/dep/dep-v0.5.0-linux-x64-cflinuxfs2-52c14116.tgz]
build-step-build | -----> Installing go 1.8.7
build-step-build |        Download [https://buildpacks.cloudfoundry.org/dependencies/go/go1.8.7.linux-amd64-cflinuxfs2-fff10274.tar.gz]
build-step-build |        **WARNING** Installing package '.' (default)
build-step-build | -----> Running: go install -tags cloudfoundry -buildmode pie .
build-step-export | 2018/10/15 03:47:58 mounted blob: sha256:1124eb40dd68654b8ca8f5d9ec7e439988a4be752a58c8f4e06d60ab1589abdb
build-step-export | 2018/10/15 03:47:58 mounted blob: sha256:6be38da025345ffb57d1ddfcdc5a2bc052be5b9491825f648b49913d51e41acb
build-step-export | 2018/10/15 03:47:58 mounted blob: sha256:a5733e6358eec8957e81b1eb93d48ef94d649d65c69a6b1ac49f616a34a74ac1
build-step-export | 2018/10/15 03:47:58 mounted blob: sha256:21324a9f04e76c93078f3a782e3198d2dded46e4ec77958ddd64f701aecb69c0
build-step-export | 2018/10/15 03:47:59 pushed blob sha256:efa2d34b82bc07588a1a8fd4526322257408109547ee089a792b3f51c383f8e6
build-step-export | 2018/10/15 03:47:59 pushed blob sha256:d495696b33936c79216ec8178726b9fbe915fafbffdd0911a7fdabce4297d9a4
build-step-export | 2018/10/15 03:48:00 index.docker.io/drnic/knative-simple-app:latest: digest: sha256:e5ef1d4d255b4bcbb38d4b43bb6302423c33e6eeabd0e20d5fda4e5ce4c46668 size: 1082
nop | Nothing to push

现在就能看到应用已经部署成功：

$ knctl curl -s simple-app
<h1>Built from local directory using Buildpack template</h1>

私有 Git Secret

前面两节我们从本地上传了源码然后构建了 Docker 镜像（使用 Dockerfile 或 Cloud Foundry buildpack），最后运行应用。

Knative 还能从 Git 仓库获取源码（正式的说法是，Knative Build 只支持从 Git 仓库获取源码，本地代码的支持是 knctl 提供的）。

让 Knative Build 获取 Git 仓库中的代码，需要用 --git-url 和 --git-revision 来取代 --directory=$PWD。

如果你的 Git 仓库是私有的，那就还需要在 Service account（在上面的例子中的 build）里包含 Git ssh 凭据。knctl ssh-auth-secret create 能够协助用户创建一个 kubernetes.io/ssh-auth secret。

$ knctl ssh-auth-secret create --secret git --github --private-key "$(cat ~/.ssh/id_rsa)"
Name  git
Type  kubernetes.io/ssh-auth

$ kubectl get secrets -n $KNCTL_NAMESPACE
NAME                  TYPE                                  DATA   AGE
...
git                   kubernetes.io/ssh-auth                1      5m
registry              kubernetes.io/basic-auth              2      3h

现在需要把 git secret 加入到我们的 build Service account 之中了。

在成文之时，knctl 还没有提供 knctl serviceaccounts update 这样的命令，所以需要删除重新创建：

kubectl delete serviceaccounts -n $KNCTL_NAMESPACE build
knctl service-account create --service-account build -s registry -s git

从 Git 部署

用 --git-url 和 --git-revision 替代 --directory 来进行 Git 部署：

knctl deploy \
    --service simple-app \
    --git-url git@github.com:cppforlife/simple-app.git \
    --git-revision master \
    --service-account build \
    --image ${DOCKER_IMAGE:?required} \
    --env SIMPLE_MSG="Built from Git repo using Buildpack template" \
    --template buildpack \
    --template-env GOPACKAGENAME=main

总结

knctl deploy 命令在 Knative 的基础上提供了创建新镜像的良好体验，可以从本地目录或者 Git 仓库开始，使用 Dockerfile 或 Cloud Foundry buildpack 进行构建，并支持不同的镜像仓库。

在 Knative 上部署 12 要素应用程序

Mon, 12 Nov 2018 00:35:24 +0800

原文：Deploying 12 Factor Apps to Knative

作者：Dr Nic Williams

我尝试按照本文内容在 Azure 上使用 ACS-Engine 部署的 Kubernetes 上进行了测试，版本部分的案例得到了相反结果，不过还是按照原文发了出来，作为一个获取感性认识的入门还是不错的。

Google Next18 活动中，Google 宣称将会把 GKE 上的无服务器插件以 Knative 的名称进行开源。当时它被描述为无服务器平台的构建块，由此推断，Knative 可能需要 Google、Pivotal 或者 RedHat 的协助才能使用。这可能是开源的古怪时机。从我最初的摸索来看，Knative 能工作；当我把 Heroku/Cloud Foundry buildpacks 加入进来之后，整个系统变得越来越像 Heroku/Cloud Foundry，相对于原始 Kubernetes，我更加了解和喜爱这一系统。

本文中我们会将 Knative 安装到你自己的 Kubernetes 集群中（knctl install），然后用 Knative 做些有趣的事情（knctl deploy）。

Knative 能够为在 Kubernetes 集群上运行无状态应用的运维人员带来很多惊喜。对我来说，最引人入胜的一点就是伸缩性：在高负载时候进行扩容，没人喜欢你的应用了，就会一直缩容到 0。

下载和安装 Knative 客户端工具 knctl，然后就可以在你的 Kubernetes 上部署 Knative，然后发布你的应用了。

在 MacOS 中，可以利用我们的 Homebrew tap 进行安装：

brew install starkandwayne/kubernetes/knctl

这里我假设你再使用 Minikube。在 Minikube 中，可以使用 Node Port 代替 Load balancer：

minikube start --memory=8192 --cpus=3 \
  --kubernetes-version=v1.11.3 \
  --vm-driver=hyperkit \
  --bootstrapper=kubeadm

knctl install --node-ports --exclude-monitoring

可以参考 Knative 文档来获取在其它类型 Kubernetes 集群上进行部署的要点。

knctl install 命令可能要花上几分钟，甚至是十分钟或者更多。这个过程中需要下载大概一打镜像。不管是互联网带宽还是镜像尺寸都可能有变化，所以坐下放松一会，或者出去走走也好。

如果 knctl install 失败了，可能是你的 Internet 比较慢，Docker 镜像在命令超时之前还没能完成下载。运行 kubectl get pods --all-namespaces 直到所有 Pod 都在运行，然后再次运行 knctl install 命令继续完成安装过程。

现在你的 Kubernetes 就是无服务器架构了，不错吧。

可以运行 kubectl get pods --all-namespaces 看看原始的 Knative 的 Pod 们。

$ kubectl get pods --all-namespaces
NAMESPACE         NAME                                        READY   STATUS      RESTARTS   AGE
istio-system      istio-citadel-7d8f9748c5-zgm9x              1/1     Running     0          21m
istio-system      istio-cleanup-secrets-j4pkx                 0/1     Completed   0          21m
istio-system      istio-egressgateway-676c8546c5-dnwsd        1/1     Running     0          21m
istio-system      istio-galley-5669f7c9b-g774b                1/1     Running     0          21m
istio-system      istio-ingressgateway-5475685bbb-q5f2x       1/1     Running     0          21m
istio-system      istio-pilot-5795d6d695-9klrz                2/2     Running     0          21m
istio-system      istio-policy-7f945bf487-2wh88               2/2     Running     0          21m
istio-system      istio-sidecar-injector-d96cd9459-7knkm      1/1     Running     0          21m
istio-system      istio-statsd-prom-bridge-549d687fd9-lcmb7   1/1     Running     0          21m
istio-system      istio-telemetry-6c587bdbc4-t4jql            2/2     Running     0          21m
istio-system      knative-ingressgateway-7f4477dd99-n9wz2     1/1     Running     0          4m
knative-build     build-controller-7dcc4b7544-rkgwb           1/1     Running     0          4m
knative-build     build-webhook-fb6484576-sr4fk               1/1     Running     0          4m
knative-serving   activator-77d46b585d-b6g8n                  2/2     Running     0          4m
knative-serving   controller-85768cfd45-t8ktc                 1/1     Running     0          4m
knative-serving   webhook-56dd548f8-hjw44                     1/1     Running     0          4m
...

部署预构建的应用

接下来我们试试用一个现有的 Docker 镜像来作为自动伸缩的无状态应用运行到 Knative 上，在当前 Kubernetes 命令空间中：

kubectl create ns helloworld

knctl deploy \
      --namespace helloworld \
      --service hello \
      --image gcr.io/knative-samples/helloworld-go \
      --env TARGET=Rev1

命令执行后会输出一些信息，表明 hello 服务已经创建，它的第一个版本 hello-00001 已经创建，并且被标记为 latest 和 previous（第一个版本）。

Name  hello

Waiting for new revision to be created...

Tagging new revision 'hello-00001' as 'latest'

Tagging new revision 'hello-00001' as 'previous'

Succeeded

我们可以用一个 curl 请求，发送到 Knative 的路由层，来调用我们的 hello 服务：

$ knctl curl --namespace helloworld --service hello
Running: curl '-H' 'Host: hello.helloworld.example.com' 'http://192.168.64.8:32380'

Hello World: Rev1!

Succeeded

如果没有马上显示 Hello World: Rev1!，可能是因为你的系统还在下载应用镜像、可以稍后重试。

我使用的是 Minikube 中的 NodePort Ingress，这意味着我不能设置漂亮的 DNS 路由。以后我会讨论一下公共负载均衡、DNS、Knative 路由以及 https://github.com/cppforlife/kwt。

knctl deploy 之后，我们的 Kubernetes 用单 Pod 的形式运行这一服务：

$ kubectl get pods --namespace helloworld
NAME                                      READY   STATUS    RESTARTS   AGE
hello-00001-deployment-5864685cbc-v8r7n   3/3     Running   0          15s

Knative 中，服务的版本是一个重要特性。我们可以看到我们的唯一版本的服务正在处理 100% 的流量：

$ knctl revisions list --namespace helloworld --service hello
Revisions for service 'hello'

Name         Tags      Allocated Traffic %  Serving State  Annotations  Age
hello-00001  latest    100%                 Active         -            3m
             previous

1 revisions

下一步我们使用 knctl deploy 创建一个新的版本，然后把所有流量分配到新版本：

$ knctl deploy \
      --namespace helloworld \
      --service hello \
      --image gcr.io/knative-samples/helloworld-go \
      --env TARGET=Rev2

Name  hello

Waiting for new revision (after revision 'hello-00001') to be created...

Tagging new revision 'hello-00002' as 'latest'

Tagging older revision 'hello-00001' as 'previous'

Succeeded

现在请求被发送到了我们的新版本：

$ knctl revisions list --namespace helloworld --service hello
Revisions for service 'hello'

Name         Tags      Allocated Traffic %  Serving State  Annotations  Age
hello-00002  latest    100%                 Active         -            1m
hello-00001  previous  0%                   Active         -            10m

$ knctl curl --namespace helloworld --service hello
Running: curl '-H' 'Host: hello.helloworld.example.com' 'http://192.168.64.8:32380'

Hello World: Rev2!

部署第二个版本之后，起初两个版本的 Pod 都会持续运行：

$ kubectl get pods --namespace helloworld
NAME                                      READY   STATUS    RESTARTS   AGE
hello-00001-deployment-5864685cbc-v8r7n   3/3     Running   0          1m
hello-00002-deployment-7874bf89b8-4b4k5   3/3     Running   0          29s

我们会看到 Knative 自动将没有路由指向的版本缩容到 0。

路由

下图展示了路由到服务某版本的过程中所涉及到的 Knative Serving 模块：

版本是代码、依赖和配置的的只读快照。没有被路由引用的版本会被放弃，其中的 Kubernetes 资源会被删除。

我们可以看到当前的路由：

$ knctl routes list --namespace helloworld
Routes in namespace 'helloworld'

Name   Traffic         All Traffic Assigned  Ready  Domain                        Age
hello  100% -> hello:  true                  true   hello.helloworld.example.com  2h

缩容至 0

如果离开五分钟再回来，你会发现 hello-00002 Pod 正在被终结或者已经不见了：

$ kubectl get pods --namespace helloworld
NAME                                      READY   STATUS        RESTARTS   AGE
hello-00001-deployment-5864685cbc-v8r7n   3/3     Running       0          6m
hello-00002-deployment-7874bf89b8-4b4k5   2/3     Terminating   0          5m

下一次 knctl curl，Knative 会动态的启动一个 Pod 来满足这一请求。

$ knctl curl --namespace helloworld --service hello
$ kubectl get pods --namespace helloworld
NAME                                      READY   STATUS    RESTARTS   AGE
hello-00001-deployment-5864685cbc-v8r7n   3/3     Running   0          8m
hello-00002-deployment-7874bf89b8-kfbm2   3/3     Running   0          10s

我还不太清楚为什么 hello-00001-deployment-... Pod 没有被缩容和终结。

未完待续

后续文章中将会尝试：

Knative Build 组件：使用 Dockerfile 或者 Cloud Foundry buildpack 自动从定制代码构建容器镜像（代码可以保存本地或者 Git 仓库之中）。
为 Kubernetes 的负载均衡设置 DNS，从而为 Knative 路由和服务提供公共 URL。
在不同版本之间进行流量分割（例如 10% 到最新版本，90% 到前一版本；然后将 100% 分配给新版本，老版本流量降低到 0%）。
Knative Eventing：在应用中进行 CloudEvents的绑定和分发。让你的服务更加“无服务器”。

社区

Knative 核心团队有自己的 Knative Slack，可以在 https://slack.knative.dev 申请加入。

knative-dev Group 中包含了总结和提议。

鸣谢

感谢 Google 的 Mark Chmarny，在 2018 Spring One 上首先回应了我的问题。

感谢 Pivotal 的 Dmitriy Kalinin 花时间帮助我将 Knative 运行起来，并给我展示了他的 knctl Knative CLI，以及 kwt Kubernetes Workstation Tools。相对于 YAML + kubectl 组合来说，一个好用的客户端工具更能够帮助 Knative 走向实用。

在 Kubernetes 和 Istio 环境下进行蓝绿部署

Sat, 20 Oct 2018 00:46:47 +0800

原文：Tutorial: Blue/Green Deployments with Kubernetes and Istio

作者：Janakiram MSV

作为一个服务网格系统，Istio 为服务间通信提供稳定性、透明性和安全性方面的保障。不论集群内外的服务，只要其访问目标是网格内的服务，就都会被 Istio 所拦截并进行处理。

Istio 有很多功能，例如服务间通信的加密、自动的指标记录、访问控制策略、频率限制以及配额等，这里我们仅着眼于最常用的流量管理能力。

Istio 让 DevOps 团队有能力为内部服务创建智能的路由规则。断路器、超时和重试之类的服务级属性非常容易配置，配置包含蓝绿部署及金丝雀发布的过程也很轻松。

本文教程用于帮助读者理解配置 Kubernetes + Istio 环境下的蓝绿部署过程。无需很多知识背景，只要理解一些在 Kubernetes 中部署 Pod 和服务的基础概念就好。我们会在 Minikube 和 Istio 中完成示例。

教程包含四个步骤：安装 Minikube、安装 Istio 并进行验证、安装一个应用的两个版本，最后配置服务的蓝绿部署。我们会使用两个简单的构建好了的镜像，分别作为蓝（v1）、绿（v2）两个版本。

步骤 1：安装 Minikube

为了降低依赖，我们会使用 Minikube 作为测试平台。因为需要自定义配置，所以要删除已经存在的配置，并使用额外参数重新启动集群：

minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.10.0 \
--extra-config=controller-manager.cluster-signing-cert-file="/var/lib/localkube/certs/ca.crt" \
--extra-config=controller-manager.cluster-signing-key-file="/var/lib/localkube/certs/ca.key" \
--vm-driver=virtualbox

要在 Minikube 上运行 Istio，需要至少 8G 内存和 4 个 CPU 核心。等集群启动：

步骤 2：安装 Istio

Kubernetes 集群成功启动之后，就可以安装 Istio 了。用下面的步骤完成：

curl -L https://git.io/getLatestIstio | sh -

在运行上述命令的目录中会发现一个 istio-1.0.2 目录，可以把 istio-1.0.2/bin 目录加入 PATH 变量，方便后面的命令执行过程。

由于我们在 Minikube 环境下运行的 Istio，所以我们要在下一步进行之前，要把 Ingress Gateway 服务从 LoadBalancer 改为 NodePort。

打开文件 istio-1.0.2/install/kubernetes/istio-demo.yaml，查找并替换：

Istio 中包含了很多 CRD，可以帮用户来进行虚拟服务、规则、网关以及其他对象的管理。在部署服务网格之前首先要部署一下这些 CRD：

kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml

最后，在 Kubernetes 中安装 Istio：

kubectl apply -f install/kubernetes/istio-demo.yaml

上面的步骤会创建新的命名空间（istio-system）：

会看到这里还有很多服务：

稍候片刻，会看到很多 Pod：

Istio 如果成功部署，所有这些 Pod 只能是 Running 或者 Completed 状态。

下一步就要准备用于蓝绿部署的应用了。

步骤 3：安装同一应用的两个版本

为了展示应用的不同版本，我构建了基于 Nginx 的简单镜像 - janakiramm/myapp:v1 和 janakiramm/myapp:v2。部署之后，会展示蓝色或者绿色的背景。

apiVersion: v1
kind: Service
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  type: ClusterIP
  ports:
  - port: 80
    name: http
  selector:
    app: myapp
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myapp-v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myapp-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: myapp
        version: v2
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

也可以在 Github 上看到这些代码。

接着就要创建 YAML 文件来定义 v1 和 v2 服务了。注意 Pod 标签的差异代表了不同的版本 —— app 保持一致，但 version 是不同的。这样一来，Istio 就会认为这是同一应用的不同版本。

而服务中的选择器定义只针对 app 标签进行设置，也就是说不同版本的 Pod 都会参与这一服务。

用 kubectl 创建 Service 和 Deployment。注意这个简单的应用对 Istio 一无所知。Istio 和应用的唯一可见的连接就是标签：

kubectl apply -f myapp.yaml

配置 Istio 路由之前，首先检查一下应用的版本。可以使用端口转发的方式来访问 Pod。

要访问应用的 v1 版本，可以运行下面的命令，然后访问 localhost:8080，验证完成之后，按 CTRL+C 结束端口映射命令。

kubectl port-forward deployment/myapp-v1 8080:80

要访问应用的 v2 版本，可以运行下面的命令，然后访问 localhost:8081，验证完成之后，按 CTRL+C 结束端口映射命令。

kubectl port-forward deployment/myapp-v2 8081:80

步骤 4：配置蓝绿部署

我们的目标是在不停机的情况下，让流量选择性的进入某一版本。为了完成这一目的，就需要告知 Istio 根据权重进行路由。完成这一任务需要三个对象：

Gateway

Istio Gateway 描述了网格边缘的负载均衡组件，用于 HTTP/TCP 连接的接收和发出。定义中包含一组要开放的端口、使用的协议、负载均衡的 SNI 等。下面的定义中我们将 Gateway 指向 Istio 部署过程中建立的缺省的 Ingress Gategeway。

用 Kubernetes 的方式创建 Gateway 对象：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: app-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

目标规则

Istio DestinationRule 定义了在一个服务成为路由目标之后的行为。注意一下这一规则中是如何通过标签来对 Kubernetes 的原生 Deployment 进行区分的：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: myapp
spec:
  host: myapp
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

虚拟服务

虚拟服务中定义了一组流量路由规则，在其中的 host 被访问时就会触发。每个路由规则中都定义了对某一协议进行匹配的标准。如果流量匹配这一标准，那么就发送给对应的区分了版本的目标服务。

下面的定义中我们定义两个版本的服务权重都是 50，也就是说流量会在版本间进行平均分配：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - "*"
  gateways:
  - app-gateway
  http:
    - route:
      - destination:
          host: myapp
          subset: v1
        weight: 50
      - destination:
          host: myapp
          subset: v2
        weight: 50

所有这些都可以定义在同一个 YAML 文件中，然后用 kubectl 提交给集群，同样可以在 Gtihub 中获取这一文件。

kubectl apply -f app-gateway.yaml

接下来就可以尝试访问这一服务了。因为我们使用的是 NodePort 模式的服务，所以就需要首先判断一下 Ingress Gateway 所在的端口。

运行下面的命令来访问 MiniKube 的 Ingress 端口。

$ export INGRESS_HOST=$(minikube ip)

$ export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')

从浏览器访问这个 URL，会看到流量被均等的在蓝色和绿色版本之间进行分配。

也可以在终端里面查看命令结果。运行下面的命令会看到 V1 和 V2 的响应：

while : ;do export GREP_COLOR='1;33';curl -s  192.168.99.100:31380 \
 |  grep --color=always "V1" ; export GREP_COLOR='1;36';\
 curl -s  192.168.99.100:31380 \
 | grep --color=always "vNext" ; sleep 1; done

上面的命令会循环运行，我们可以返回编辑 gateway.yaml，修改其中的权重分配。把 V1 的权重设置为 0，V2 的权重设置为 100.

把新的定义提交到 Istio。

$ istioctl replace -f app-gateway.yaml

更新权重之后，V2 的响应比例会提升到 100%。这一结果会体现在输出之中：

可以继续对权重进行修改，查看路由的动态变化过程。

流量管理只是 Istio 的一个功能，后续文章中尝试更多其他特性。

Kubernetes 1.12 中的 RuntimeClass

Thu, 11 Oct 2018 10:49:46 +0800

原文：Kubernetes v1.12: Introducing RuntimeClass

起初，Kubernetes 只支持运行于 Docker 容器中的 Linux 本地应用。Kubernetes 1.3 中，rtk 为首的其他运行时支持开始逐步浮现，促成了容器运行时（CRI）的诞生，更多的项目也因此加入了这一行列：Kata Container 和 gVisor 实现了更好的工作负载隔离；Kubernetes 的 Windows 支持也一直在稳步发展。

不同的容器运行时面向不同的使用场景，也就产生了在同一集群中使用混合运行时的需要。但是这所有不同的运行容器的方式都带来了一些亟待处理的问题：

用户如何列出、并为工作负载选定合适的运行时？
如何保证让 Pod 被调度到支持指定运行时的节点上？
各种运行时都支持什么样的特性？如何让用户了解到这其中的兼容问题？
多种运行时的不同资源开销如何应对？

RuntimeClass 为此而来。

Kubernetes 1.12 中的 RuntimeClass

RuntimeClass 在 Kubernetes 1.12 中实现，目前为 Alpha 阶段。初始阶段的焦点是提供一个对运行时进行选择的 API，并且为解决其它多运行时方面的问题进行了一些尝试。

RuntimeClass 资源对 Kubernetes 集群上的容器运行时进行了描述。集群安装程序用 RuntimeClass 对运行时进行安装、设置和定义。目前 RuntimeClassSpec 包含一个字段 RuntimeHandler。运行于节点上的 CRI 会对 RuntimeHandler 进行解释，将其映射为实际的运行时配置。PodSpec 也随之进行了扩展，加入了一个 RuntimeClassName 字段，这个字段的值代表运行该 Pod 所需的 RuntimeClass 的名称。

为什么 RuntimeClass 是个 Pod 级的概念？Kubernetes 资源模型能够在 Pod 中的不同容器之间共享某些资源。如果组成 Pod 的不同容器具有不同的资源模型，会对资源共享造成很大的挑战。例如在不同虚拟机之间共享 loopback 适配器是极其困难的，但是在同一 Pod 中的两个容器之间进行通信时，这是个非常普遍的需要。

下一步？

要向控制面呈现运行时属性，RuntimeClass 资源是个很重要的基础。例如要在多种不同运行时 Node 组成的集群中实现调度支持，我们可能需要在 RuntimeClass 定义中实现 NodeAffinity。Pod Overhead proposal 在这方面做出了一些早期尝试，和 RuntimeClass 非常匹配，未来会逐步进行跟进。

目前还提出了很多其它的 RuntimeClass 扩展，会逐步进行进一步的研究和开发。正在考虑的扩展包括：

呈现容器运行时所支持的可选特性，并为不兼容功能引发的错误提供更好的展示。
将运行时的功能发现过程进行自动化，从而为自动的调度决策提供支持。
提供运行时的自动注册功能，这样用户就可以在不停机的情况下为现有集群中安装新的运行时。
为 Pod 的需求提供合适的 RuntimeClass。例如指定运行时属性，让系统自行对 RuntimeClass 进行匹配，从而避免显式指定 RuntimeClass。

至少到 2019 年。RuntimeClass 的开发工作都会保持活跃，我们很高兴，从 Kubernetes 1.12 开始，这一功能以 Alpha 的形态成功面世。

还有更多

作为一个 Alpha 功能，还需要一些额外的设置步骤才能够使用 RuntimeClass。详情请参考 RuntimeClass 文档。

RuntimeClass Kubernetes ENhancement Proposal 之中包含了更多的设计细节。

Sandbox Isolation Level Decision 一文介绍了将此方案落地到 Pod 级的思考过程。

Kubespy：实时查看 Kubernetes 资源

Wed, 10 Oct 2018 17:00:41 +0800

原文：kubespy: tools for observing Kubernetes resources in real time

一个 Pod 启动时会发生些什么？一个 Service 拿到公共 IP 之前又会干点啥？Deployment 的状态是怎么切换的？

kubespy 是个小工具，能够轻松的实时查看 Kubernetes 集群里的资源变化。这一工具源自于 Pulumi CLI ，其中对 Kubernetes Deployment 的预测做出了一些常识。可以在任何时机运行 kubespy，它会持续对 Kubernetes 资源进行监控和报告，直到杀掉进程为止。

例如

kubespy trace deployment nginx 会对集群中名为 nginx 的 Deployment 对象进行跟踪，并将状态信息进行聚合，生成较高级的概要，并且进行实时更新。

kubespy status v1 Pod nginx 会等待创建一个叫做 nginx 的 Pod，然后持续刷新其状态，并用高亮语法的 JSON 形式展现出来。

安装

获取最新版本，重命名为 kubespy，chmod -x kubespy 并将其拷贝到可执行路径之中（例如 /usr/local/bin）。

或者

安装 Go 1.11 以上版本，然后运行：

export GO111MODULE=on

# If $GOBIN is not on your path, you'll need to install the library elsewhere.
go install github.com/pulumi/kubespy

两种方式都能够完成安装。

用法

kubespy 有三个子命令：

status <apiVersion> <kind> [<namespace>/]<name>：实时跟踪任意 Kubernetes 对象的 .status 字段，并用 JSON Diff 的方式进行展示。

changes <apiVersion> <kind> [<namespace>/]<name>：实时获取一个 Kubernetes 资源的所有字段的所有变化，用 JSON Diff 进行展示。

trace <kind> [<namespace>/]<name>：对复杂 Kubernetes 资源进行跟踪，在整个集群范围内进行聚合，生成汇总信息，并保持实时更新。

Knative：在 Kubernetes 上构建可移植 Serverless 平台

Thu, 20 Sep 2018 17:13:03 +0800

原文：Knative Enables Portable Serverless Platforms on Kubernetes, for Any Cloud

作者：Dan Baskette

Kubernetes 目前如日中天，这一项目不仅在容器编排方面独占鳌头，还给基础设施自动化进程提供了可实践的原语。

但是我们注意到，开发团队在进行基于 Kubernetes 的应用部署时常有困扰。Kubernetes 毕竟只会推送容器——要想推送应用代码或者 Function，很明显就不是 Kubernetes 的能力所在了。

这样一来，就有不少厂商以 K8S 作为基础设施，展开了高级抽象方面的竞争。这也是 Knative 的着眼点。

Kelsey Hightower：Kubernetes 是一个用来构建平台的平台。它是起跑线，不是目的地。

Function 是值得注意的下一次抽象

读者可能已经注意到分布式系统世界的新晋成员：FaaS（Functions/Serverless）。Function 是一种新的抽象方式，让开发人员能够轻松的运行部署代码片段，并具备根据事件进行伸缩的能力。

这对开发人员来说是非常有吸引力的。为什么？把所有的基础设施和应用启动之前的事件处理都抽象之后，开发人员能够完全专注于解决如何使用 Function 的代码处理事件的问题。

天下自然是没有免费的午餐了，FaaS 的问题在哪里呢？

市场上有很多 FaaS 方案，每个都是独一无二的，他们有自己的 Function 触发方式，自己的可接受事件格式范围，独特的伸缩功能以及从各自角度触发，为开发人员作出的各种抽象。

如果有要用到的抽象，可以寄希望于云供应商将其打包并为你提供服务。Azure Functions、Lambda 以及 Google Cloud Function 就是这样工作的：根据事件运行 Function 代码，按需伸缩。这类产品按照用量进行计费——根据调用量收取费用。

开源社区的开发者们也加入了 FaaS 的盛宴，OpenFaaS、Fission、Kubeless 以及 Project Riff 这些项目都是构建在 Kubernetes 之上的 FaaS。这一共同的基础，也有了大同小异的产品。

在三个核心领域，每个项目都有些许差异：

都有自己的构建服务，也就是把 Function 进行容器式构建和部署的功能。
都有一种按调用需要进行扩容（或者缩容）的实现。
都提供了根据事件调用 Function 的能力，事件可能是 HTTP 或者是事件中间件的发布、订阅方式。

这些细微差异会造成平台采用的巨大障碍。在企业开发者眼里，这一领域功能破碎，竞品众多。所以只能静观其变。

Knative 适时出现

Google 看到这种碎片化的现状，也注意到了开发人员在 Kubernetes 上进行 Function 开发的过程中对通用工具集的需求。Knative 就是基于这种需求产生的。

Knative 是一个开源软件层，帮助云服务供应商和企业平台在任意云上为开发者提供 Serverless 体验。

Pivotal 也身在其中，不但向 Knative 贡献了来自 riff 项目的事件模型，还和 Google 一起，在其它方面贡献了开发人员和代码。我们为这一项目的未来欢欣鼓舞，将 riff 和 Knative 结合在一起，酝酿成我们的新项目 Pivotal Function Service。

所以对于 Knative 来说，还需要知道点什么呢？这个项目使用 Kubernetes 作为容器编排层。它使用大家熟知的 Kubernetes 对象（Pod、Replica Set 以及 Deployment）构建应用。Istio？是的，Knative 使用 Istio 来进行网格内的路由以及 Ingress 入口管理。

但是仅仅有 Kubernetes 和 Istio 还是不够的。因此 Knative 同时还引入了三个松耦合的组件，协同对外提供一个完整的 Serverless 平台：Build、Eventing 以及 Serving。

Build：提供了一个可插入模型，用于从源码构建容器。
Eventing：让应用或者 Function 发布到或订阅事件流，事件流包括 Google Cloud Pub/Sub 以及 Apache Kafka。
Serving：为应用或 Function 提供运行和扩容以及缩容至 0 的能力。

上述元素融合形成的 Knative 又有何神通？它提供了一种较为简化的部署和运行 function 的方式，包括这些模式：

从源码构建应用和 Function。
包含多种构建方法（Cloud Foundry Buildpacks、Bazel、Kaniko、Dockerfiles，并可以扩展支持其他方式）。
开发者能够轻松部署新的（可路由的）应用和 Function。
允许应用的不间断升级。
应用实例的自动伸缩。
把事件绑定到 Function、应用或者容器上。
当发生 HTTP 请求时触发 Function。

稍微深入一点看看这几个组件。

Build：源码到容器的弹性和可扩展过程

开发人员编写源码。Kubernetes 操作容器。如何完成联动？Cloud Foundry 使用 buildpack 来完成这一场景。Knative 提供一个插件模型来完成从代码到容器的构建过程。这一模型通过 CRD 实现，也就是一组 Kubernetes API 对象。这种方式提供了一个构建块，能够作为一个 CI/CD 之类的更大系统的一部分，完成源码的构建。

Knative 的 Build 组件包含 4 个主要组成部分。

描述如何获取待构建的源码。位置在 /workspace 卷中存储，这个内容会在后面的步骤中沿用。通常情况下，源码会保存在 git gcs 之类的版本控制系统中，也可以用自定义容器来访问源码。
步骤或模板：这是构建容器的实际工作。这个过程简单说来就是根据 Build 规范完成一系列步骤。换句话说，这一过程由一组可插接构建器组成，被设计用来从源码构建容器，目前这个模型支持五种构建模板，提供了可共享的构建过程：Cloud Foundry Buildpacks、Google Container Builder、Bazel、Kaniko 以及 Jib。
Service Account：用来运行构建过程的账号。
存储卷：可以定义多个卷，来提供对构建步骤的支持。这些卷可以有很多用途，例如共享 Secret 或者在多个步骤间提供缓存。

Serving：按需伸缩以及版本为基础的高级运维

自动化升级了开发者的工作流。Serving 的自动化范围覆盖了从容器到运行中的 Function 部分。它还提供了容器的快速部署，以及根据进入请求完成扩容到 N 或缩容到 0 的能力支持。Istio 在版本之间进行路由，这使得不间断升级、蓝绿部署、金丝雀测试以及回滚都成为了可能。

Serving 包含了四个 CRD：

管理应用和 Function 的生命周期以及提供控制点。它可以处理对象的生成，来保障应用或者 Function 的任何版本更新都具备网络路由、配置以及版本支持。
代码和配置的固定快照。一个版本会引用一个容器以及创建这个容器所需的内容。历史中可以包含多个版本，这样就能够支持一些蓝绿部署或者回退之类的高级运维工作。
网络端点到一或多个应用版本的映射。
定义了部署的最新版本以及各版本的状态。

Eventing：把订阅/发布操作进行抽象，简化开发人员工作

Function 的基本存在价值就是用来响应事件。FaaS 项目和受管服务的区别就是事件的接收以及消费方式。Knative Eventing 组件用来对事件系统的后端进行抽象，从而解放开发人员。开发人员无需了解消息平台、不用关注数据复制等问题。

Knative 提供了 CRD 用于事件的生产和消费。Eventing 组件由两类 CRD 组成：

Channel
- 发布/订阅模型中发布者发送消息的目标。一般来说，Channel 是一组位置用于获取或存储事件。
- Bus：Channel 的后端。这是为事件提供消息平台支持的底层，可以是 Google Cloud PubSub、Apache Kafka 以及 RabbitMQ 等。
- 这些结合起来告知 Knative 服务，特定 Channel 的消息会被哪个应用或者 Function 消费。这是应用和 Function 的入口地址。
Feeds：事件携带的附件。

试用你能掌控的最高级抽象

Knative 是一个全新事物，但是已经有了很多资源可供学习和参考。企业开发软件数量暴涨，意味着典型情况下，公司都会谋求试用应用平台、容器编排以及 Function。Pivotal 希望在所有不同抽象中驱动开源软件的发展。Cloud Foundry、Kubernetes 以及 Knative 会成为大公司的软件构建和运行过程中的主要推手。

Knative 文档是该项目的主要信息源。每个组件都在仓库中有自己的一席之地，让用户可以跟进最新进展。
可以阅读 Pivotal 博客，Ryan Morgan 在其中发布了关于 Pivotal 在 Knative 项目中贡献的相关内容，会涉及企业应用 Serverless 的更多案例。
在 Google Cloud 也有很多资料：
- Knative 概览页面
- Knative 博客
如果想要知道 riff 项目的信息，官方网站是最好的起步地点。其中包含了所有的文档和对 riff 仓库的引用。
想要了解更多？SpringOne 平台有一套 Serverless 课程。

Kubernetes 如何走向统一调度之路

Tue, 18 Sep 2018 22:04:06 +0800

原文：How Kubernetes Is Transforming into a Universal Scheduler

作者：Janakiram MSV

计算机科学里，调度指的是一种能够为作业分配满足其执行所需资源的方法。IBM 在 60 年代的 S/360 中首次提出这一概念，可以说是年代久远了。

对所有存在资源需求的作业来说，调度都是至关重要的。在操作系统的上下文中，作业可能是个简单的程序，资源可能是 CPU 核心。类似的，操作系统中的调度器可能就只是一些用于操作线程或信号的代码。

分布式计算将调度器的疆土从内部的进程和线程扩展到了物理机集群之中。90 年代中，Corba、DCOM 以及 J2EE 等分布式平台应运而生，在应用服务器集群内发展了各自的调度组件。

再后来，出现了 Amazon EC2、Azure Fabric 以及 OpenStack Nova 这样的 IaaS 平台，这些平台的控制平面完成了对运行于物理机基础之上的虚拟机的调度工作。根据资源需求将虚拟机实例安置在合适的物理机上。

基于 Apache Hadoop 和 MapReduce 算法的大数据工作负载对调度算法非常依赖。Hadoop 的文件系统 HDFS 就用于保障集群上的节点能够访问到数据集。这一架构聚焦于资源的的稳定性和可用性保障。

Cloud Foundry 和 Heroku 这样的 PaaS 实现中包含了设计精密的调度逻辑，用来为服务提供隔离的环境。每个服务都被打包，部署在虚拟或物理服务器的执行环境之中。

横空出世的容器，强迫业界重新审视资源调度器的设计。新一代调度器的设计理念更加重视简单性和伸缩性。传统应用服务器面对的是少量服务器，而容器管理平台要管理的容器工作节点数量可能从几台到几千台。

Kubernetes 和 Mesosphere 是当代资源调度器的代表。它们的设计对底层基础设施进行了抽象，用透明的方式为用户提供调度服务。

Kubernetes 中的调度

Kubernetes 平台中，调度器是一个关键组件。它在主节点上运行，和 API Server 以及 Controller 紧密合作。调度器的核心任务就是对 Pod 和 Node 进行撮合。可以在 Kubernetes architecture 一文中透彻的了解其架构。

调度器会在多个方面对可用资源进行评估，从而为 Pod 分配合适的节点。另外还可以通过对节点亲和性的设置，为 Pod 分配指定特性的节点。例如一个一个高 IO 的数据库 Pod 可能需要调度到配有 SSD 存储的节点上。还有可能为了降低延迟，将一系列的 Pod 调度到同一节点上，这一操作称为 Pod 亲和性。Kubernetes 还支持自定义调度器，完全由第三方实现分配逻辑。

Kubernetes 调度器的最大亮点就是其简单性。前面描述的多数策略都能很轻松的实现。只要通过一点注解和标签，就能完成 Pod 和节点之间的亲和或排斥的定义。通过对 Pod 和节点的键值对设置就能够实现成熟的调度逻辑。

超越 Pod 和节点的 Kubernetes 调度器

Kubernetes 可能是目前最好的资源调度器之一。兼顾简单和扩展能力的调度器让用户能够解决很多传统分布式系统中的调度问题。

在高度分布的环境中，Kubernetes 正在成为首选的作业调度和管理工具。这些作业包括在物理服务器上部署虚拟机、在边缘设备上运行容器，甚至还具有将控制平面扩展到 Serverless 环境这样的其他调度器上的能力。

KuberVirt 就是一个 Kubernetes 上的虚拟机管理插件，它让用户能够像 Pod 一样在 Kubernetes 或 OpenShift 集群上运行虚拟机。这一系统用 CRD 的形式来进行虚拟机的设置，完成了对 Kubernetes 的扩展。KubeVirt 虚拟机运行在普通的 Kubernetes Pod 之内，从而具有了访问标准 Pod 网络和存储的能力，并且可以使用标准的 kubectl 或者类似的 Kubernetes 工具来进行管理。

来自 Mirantis 的 Virtlet 项目让虚拟机可以在 Kubernetes 集群中像普通 Pod 一样运行。运维人员可以用 kubectl 命令管理虚拟机，并且将虚拟机以一等公民的身份纳入集群网络。有了 Virtlet 就可以构建高级的 Kubernetes 对象，例如 Deployment、Statefulset 或者 DaemonSet。

微软的 Virtual Kubelet 是最有趣的一个调度器。Virtual Kubelet 是一个 Agent，运行在注册为 Kubernetes 集群节点的外部环境之中。这个 Agent 会通过 Kubernetes API 创建节点资源。通过对污染和隔离功能的使用，会通过本地 API 来进行外部环境中的 Pod 调度。

Virtual Kubelet 可以在 Azure Container Instance、Azure IoT Edge 以及 AWS Fargate 上运行。

另外，我还写过其他文章，介绍了 Virtual Kubelet 的架构和部署指南，可供读者参考。

更进一步——自定义调度器和 CRD

上面讨论的例子只是冰山一角。Kubernetes 正在成为当代基础设施的基础，正在迈入传统业务应用领域——例如 ERP 和 CRM。

应用提供商们将会越来越重的依赖 Kubernetes 的两个功能：自定义调度器和 CRD。

正如前文所说，Kubernetes 的自定义调度器让开发者可以实现自己的调度逻辑。Pod 的声明中就可以通知控制面跳过缺省调度器，转而采用自定义调度。这一机制能够保障集群内的 Pod 得到正确安置。

Portworx 是一个云原生生存储公司，它使用自定义调度器来创建 STORK（Kubernetes 存储编排运行时：STorage Orchestrator Runtime for Kubernetes）。从而保障它的 Stateful Pod 只会在安装了 Portworx 驱动和存储的节点上运行。这一功能对于运行其上的数据库负载的可用性保障很有帮助。

Kubernetes 中的 CRD 为自定义对象提供了简单且强大的生命周期支持。自定义资源是一种对象，对 Kubernetes API 进行了扩展，开发人员可以利用这一机制将自己的 API 引入 Kubernetes。CRD 文件声明了自定义对象的定义，让 API Server 能够处理整个生命周期。在 Kubernetes 中部署 CRD，就是让 Kubernetes API Server 开始支持某种自定义资源。

CRD 创建之后，运维人员可以使用 kubectl 或者第三方工具来进行管理，这一过程和 Pod 等内置对象并无二致。ISV 可以利用 CRD 的方式将自己的软件进行打包和部署。

Kubernetes 的扩展性，使其具备了成为统一调度管理工具的潜质。

换马甲：十分钟 Helm 变 Operator

Thu, 30 Aug 2018 10:41:42 +0800

Operator 是一种将传统运维思路转换为 Kubernetes CRD 控制的方法，利用 CRD 对软件部署和配置进行定义，整个部署和管理过程在 Kubernetes 角度上来看，都是一个可见、可审计的行为，这无疑对运维工作是大有裨益的。CoreOS 也提供了 Operator Framwork 用于进行 Operator 的开发，不过门槛还是稍高的。如果放低要求，是否能有一个折衷方案？

CoreOS 为最近加入 CNCF 的 Helm 提供了一个小工具，可以无需编程操作，较为方便的将 Helm Chart 转换为 Operator，并将原有的 values.yaml 更替为 CR 资源进行操作，对于无状态应用的部署流程，可以说是比较便利了。下面就随便举个例子，看看这马甲是怎么换的。

目前版本相当幼稚，看看就好了。

准备工作

首先是一个可操作的 Kubernetes 集群，要求版本为 1.9+。接下来要有一个可操作的 Helm 客户端（无需 Tiller 部署），用于下载 Chart。

使用 git 获取 Helm app operator kit：

$ git clone https://github.com/operator-framework/helm-app-operator-kit.git
Cloning into 'helm-app-operator-kit'...
...
Resolving deltas: 100% (58/58), done.

镜像构建

下载一个实验 Chart 并解压：

$ helm fetch stable/memcached
$ tar xf memcached-2.2.0.tgz
$ ls -la
...
-rw-r--r--   1 dustise  wheel    680  8 30 11:50 Dockerfile
...
drwxr-xr-x  10 dustise  wheel    320  8 30 11:50 helm-app-operator
drwxr-xr-x   7 dustise  wheel    224  8 30 11:52 memcached
...

这里的 Dockerfile 可以略微关注一下：

FROM golang:1.10 as builder
...
RUN curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh
...
RUN CGO_ENABLED=0 GOOS=linux go build -o bin/operator cmd/helm-app-operator/main.go
...
FROM alpine:3.6
...
COPY --from=builder /go/src/github.com/operator-framework/helm-app-operator-kit/helm-app-operator/bin/operator /operator
...
CMD ["/operator"]

一个典型的分段构建过程。在 Go 环境中生成可执行文件用于最终镜像的执行。

使用 Dockerfile 进行构建：

docker build -t your-repo:25000/helm/memcached-operator \
    --build-arg HELM_CHART=memcached \
    --build-arg API_VERSION=anywhere.io/v1alpha1 \
    --build-arg KIND=memcached .

HELM_CHART：我们之前解压的 Chart 目录。
API_VERSION：即将用到的自定义资源的 API 组和版本。
KIND：自定义资源名称。

Docker 构建完成之后，将新镜像 Push 到 Kubernetes 可访问的镜像库中。

Operator 部署

构建成功之后，进入 helm-app-operator/deploy 目录，要部署 Operator，首先要修改几个文件。

rbac.yaml

这是 Operator 运行所需的权限设置文件，根据前面的配置，我们需要给他加入两个权限：namespace 以及新建的 CRD 的操作权限。

这里的 RoleBinding 只是绑定到了 default 命名空间的 default ServiceAccount，如果要给 Operator Pod 单独赋权，就要对 subject 进行修改。

文件编辑结束后，就可以使用 kubectl apply 提交到集群运行。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: helm-app-operator
rules:
...
  - secrets
  - namespaces
  verbs:
  - "*"
- apiGroups:
  - apps
  resources:
  - deployments
  - daemonsets
  - replicasets
  - statefulsets
  verbs:
  - "*"
...
- apiGroups:
  - anywhere.io
  resources:
  - "*"
  verbs:
  - "*"

crd.yaml

接下来就是自定义资源的定义了。这里需要和前面我们制定的 API 结构相吻合

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: memcacheds.anywhere.io # 资源名 + 组名
spec:
  group: anywhere.io # 组
  names:
    kind: memcached # 对象
    listKind: memcachedList #列表
    plural: memcacheds # 复数形式
    singular: memcached # 单数形式
  scope: Namespaced
  version: v1alpha1 # 版本

同样的，使用 kubectl apply 提交这一定义给 Kubernetes 集群。

operator.yaml

这个文件很简单，是一个 Deployment 对象定义，修改一下镜像名即可，如果 rbac.yaml 中修改了绑定账号，这里也需要修改 Operator 的运行账号。

最后，用 kubectl apply deploy/operator.yaml，即可启动 Operator 的运行了。可以使用 kubectl get po -w 获取运行状况。

创建应用实例

deploy 目录中还有另外一个文件：cr.yaml，就是我们的自定义资源实例文件。过去需要在 Chart 的 values.yaml 中编写的内容，现在需要在这里完成了。通过 helm inspect stable/memcached 命令，可以看到其中支持的参数列表。这里我们可以设置一下，用来创建一个 3 实例的集群：

apiVersion: anywhere.io/v1alpha1
kind: memcached
metadata:
  name: memcached-yy
  labels:
    app: example-app
spec:
  replicaCount: 3

使用 kubectl apply 提交之后，可以看到集群上开始创建这一实例：

$ kubectl get po
...
helm-app-operator-memcached-yy-0      1/1       Running            0          10h
helm-app-operator-memcached-yy-1      1/1       Running            0          10h
helm-app-operator-memcached-yy-2      1/1       Running            0          10h
...

这里 Operator Pod 可能会崩溃，删除即可正常工作😄。

查询实例情况：

$ kubectl get memcached
NAME           CREATED AT
memcached-r    10h
memcached-yy   10h

删除实例

$ kubectl delete memcached memcached-yy
memcached.anywhere.io "memcached-yy" deleted

再次使用 kubectl get po，会发现对应 Pod 已经删除。

结语

CoreOS 再次提供了一个有趣的方向，有效的降低了 Operator 的入门门槛。但是这一方案除了成熟度相当不足之外，Helm 本身对运维的支持其实也是非常弱的，对有状态应用是无论如何不能使用这种方式来进行运维的。——马甲，只是马甲。

小技巧：外部域名挂接 Azure 中的 K8S 负载均衡

Wed, 25 Jul 2018 09:13:35 +0800

使用 ACS Engine 在 Azure 上安装好了 Kubernetes 之后，就可以使用 Loadbalancer 类型的服务了。测试条件下，一般会使用不同域名通过同一个 Ingress Controller 访问不同服务的方式。

例如我们创建一个 Nginx Ingress Controller，服务启动之后会看到大概这样的信息：

$ kubectl describe svc ingress-nginx
Name:                     ingress-nginx
Namespace:                ingress-nginx
...
Type:                     LoadBalancer
IP:                       10.0.22.78
LoadBalancer Ingress:     104.216.145.198
...

接下来可以使用 az 命令查询我们 Azure 中已经生效的外部 IP 所对应的记录内容：

az network public-ip list \
--query "[?ipAddress=='104.216.145.198']"

会得到一条 JSON 记录：

{
"dnsSettings": {
    "domainNameLabel": "k8s-5b",
    "fqdn": "k8s-5b.cloudapp.azure.com",
    "reverseFqdn": null
},
...
"name": "...",
"idleTimeoutInMinutes": 4,
"ipAddress": "104.216.145.198",
"ipConfiguration": {
...

接下来，我们可以给这个 Ip 设置一个 AZURE 的内部域名，同样使用 az 客户端：

az network public-ip update
--name=k8s-master-ip-k8s-5b55d212-28708154 \
--set dnsSettings.domainN
ameLabel='awesome-name-fcsaqz87d' \
--resource-group=k8s

命令执行后，会返回一长串的描述信息，跟上述的 List 结果类似，节选我们的变更部分：

"dnsSettings": {
    "domainNameLabel": "awesome-name-fcsaqz87d",
    "fqdn": "awesome-name-fcsaqz87d.southeastasia.cloudapp.azure.com",
    "reverseFqdn": null
  },

这里可以看到，这个外部 IP 有了一个域名，接下来，我们可以在我们的域名提供商控制台上，为域名设置 CNAME 记录，指到这个 fqdn 上，然后可以用 nslookup 上进行验证，例如：

nslookup prom.abc.xyz
canonical name = awesome-name-fcsaqz87d.southeastasia.cloudapp.azure.com.
Name:   awesome-name-fcsaqz87d.southeastasia.cloudapp.azure.com

就可以用外部域名来访问我们 Kubernetes 上的 Ingress 资源了。

更进一步的，可以将泛域名设置到这一 IP 上，同时使用 Let’s Encrypt 的泛域名证书来完成对服务的 HTTPS 加固过程。

Metallb - 贫苦 K8S 用户的负载均衡支持

Tue, 24 Jul 2018 00:09:48 +0800

简介

在私有网络上运行 Kubernetes，和御三家相比，对 LoadBalancer 类型的服务的支持应该是众多表面差异中最醒目的一个了。类型为 LoadBalancer 的服务在 Kubernetes 中并没有直接支持，NodePort 和 ExternalIP 方案让很多私有云用户成为了 K8S 世界中的二等公民。接下来介绍的 Metallb，就给私有 Kubernetes 用户带来了一个方便、可用（而且不太成熟）的软件解决方案。

该项目发布于 2017 年底，当前处于 Beta 阶段。

Metallb 会在 Kubernetes 内运行，监控服务对象的变化，一旦察觉有新的 LoadBalancer 服务运行，并且没有可申请的负载均衡器之后，就会完成两部分的工作：

地址分配

用户需要在配置中提供一个地址池，Metallb 将会在其中选取地址分配给服务。

地址广播

根据不同配置，Metallb 会以二层（ARP/NDP）或者 BGP 的方式进行地址的广播。

支持范围

不支持 IPVS

网络插件	兼容性
Calico	部分支持（有附加文档）
Flannel	支持
Kube-router	不支持（正在跟进）
Romana	支持（有附加文档）
Weave Net	支持

一个小测试

安装

Metallb 支持 Helm 和 YAML 两种安装方法，这里我们使用第二种：

kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.7.1/manifests/metallb.yaml

很简单，Metallb 就会开始安装，会生成自己的命名空间以及 RBAC 配置。

$ kubectl get pods -n metallb-system
NAME                         READY     STATUS    RESTARTS   AGE
controller-b7896bf94-g449l   1/1       Running   0          51m
speaker-mt6kd                1/1       Running   0          51m
speaker-sqbn4                1/1       Running   0          51m

配置

接下来我们要生成一个 Configmap 文件，为 Metallb 设置网址范围以及协议相关的选择和配置，这里以一个简单的二层配置为例：

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: my-ip-space
      protocol: layer2
      addresses:
      - 10.211.55.240/28

注意：这里的 IP 地址范围需要跟集群实际情况相对应。

使用 kubectl apply 命令应用之后，使用 kubectl logs -f [metallb-controller-pod] 会看到配置更新过程。

测试

创建一个 Nginx 的服务，服务类型为 LoadBalancer：

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1
        ports:
        - name: http
          containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer

服务创建运行之后，可以列出服务信息：

kubectl get svc
NAME       TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)         AGE
kube-dns   ClusterIP      10.96.0.10      <none>          53/UDP,53/TCP   7d
nginx      LoadBalancer   10.96.245.212   10.211.55.240   80:32207/TCP    54m

这里就发现，LoadBalancer 类型的服务，分配到了我们地址池中的第一个 IP。

用 curl http://10.211.55.240 验证，就会发现返回了 Nginx 的欢迎信息。

补充

除了这里提到的一点点简单配置之外，Metallb 的配置能力还是比较强大的，这点可以参考官网，其中谈及了不少较为务实的案例，另外还提到了部分 Issue 供用户参考。

实验手记：Kubernetes 中进行 PVC 的扩容

Sun, 15 Jul 2018 00:11:28 +0800

Kubernetes 1.11 版本中，PVC 的扩容功能进入了 Beta 阶段，一般来说，Kubernetes 功能进入 Beta 阶段就意味着基本可以用于生产了。这里就做几个小测试，看看这一功能的使用方法。

开始之前

首先当然是要有一个 Kubernetes 1.11 版本的集群。并且提供了支持 Auto provision 的存储。下面的实验是基于 Azure 的 ACS-Engine 集群。

创建 StorageClass

接下来准备两个 Storage Class 对象，分别命名为 common 和 expend，二者主体基本一致，文件名分别为 sc-common.yaml 以及 sc-exp.yaml：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: exp  # sc-common.yaml 中这里的值为 common
parameters:
  cachingmode: None
  kind: Managed
  storageaccounttype: Standard_LRS
provisioner: kubernetes.io/azure-disk
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true # sc-common.yaml 中删掉这一行

$ kubectl apply -f common.yaml
storageclass.storage.k8s.io/common created
$ kubectl apply -f exp.yaml
storageclass.storage.k8s.io/exp created

创建一个 PVC

我们接下来创建一个 PVC，初始首先测试一下 common 这个 Storageclass，后续的 PVC 操作都从这一个 YAML 中修改而来。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 2Gi
  storageClassName: common

同样使用 kubectl 创建这个 PVC：

$ kubectl apply -f pvc.yaml
persistentvolumeclaim/myclaim created
$ kubectl get pvc -w
NAME      STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
myclaim   Pending                                       common         9s
myclaim   Pending                                 common    10s
myclaim   Pending   pvc-e3f8e886-8776-11e8-b82d-000d3aa2ebc3   0                   common    11s
myclaim   Bound     pvc-e3f8e886-8776-11e8-b82d-000d3aa2ebc3   2Gi       RWO       common    11s

第一次扩容尝试

PVC 进入 Bound 状态之后，我们编辑 pvc.yaml，将容量改成 3Gi，并重新 Apply：

$ cat pvc.yaml | sed  "s/2Gi/3Gi/" | kubectl apply -f -
Error from server (Forbidden): error when applying patch:
...
for: "STDIN": persistentvolumeclaims "myclaim" is forbidden: only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize

结果表明，这次扩容失败了，失败的原因是 Storageclass 不支持扩容

使用新的 Storageclass 创建 PVC

接下来我们将这个 PVC 删除，使用 exp 这个 Storageclass 重建 PVC：

$ kubectl delete -f pvc.yaml
persistentvolumeclaim "myclaim" deleted
$ sed -i .bak s/common/exp/ pvc.yaml
$ kubectl apply -f pvc.yaml
persistentvolumeclaim/myclaim created
$ kubectl get pvc -w
NAME      STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
myclaim   Bound     pvc-37eb6014-8778-11e8-b82d-000d3aa2ebc3   2Gi        RWO            exp            11s

创建之后，我们可以再次尝试对 PVC 进行扩容：

$ cat pvc.yaml | sed  "s/2Gi/1Gi/" | kubectl apply -f -
The PersistentVolumeClaim "myclaim" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value
$ cat pvc.yaml | sed  "s/2Gi/3Gi/" | kubectl apply -f -
persistentvolumeclaim/myclaim configured

这里两次执行命令：

缩容是不允许的
扩容成功

接下来我们再次获取 PVC 信息：

$ kubectl describe pvc myclaim
Name:          myclaim
Namespace:     default
StorageClass:  exp
Status:        Bound
Volume:        pvc-37eb6014-8778-11e8-b82d-000d3aa2ebc3
...
Capacity:      2Gi
Access Modes:  RWO
Conditions:
...
FileSystemResizePending
...
Waiting for user to (re-)start a pod to finish file system resize of volume on node.

这里会看到，虽然没出错，但是容量还是原有的 2G，他的 Condition 中提示，需要进行一个 Pod 绑定才能真正生效。

绑定 Pod

新建一个 Deployment 来使用前面创建的 PVC：

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:v0.5
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: data
          mountPath: "/data"
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: myclaim

再次查看 PVC 的情况：

$ kubectl describe pvc myclaim
...
Capacity:      3Gi

容量的修改的确生效了。

绑定之后的 PVC 扩容

再次对这个 PVC 进行扩容，我们这次从 3Gi 扩容到 4Gi：

$ cat pvc.yaml | sed  "s/2Gi/4Gi/" | kubectl apply -f -
persistentvolumeclaim/myclaim configured

然后获取一下 PVC 的情况：

$ kubectl describe pvc myclaim
...
Capacity:      3Gi
...
Events:
  Warning  VolumeResizeFailed     31s (x2 over 56s)  volume_expand
  Original Error: failed request: autorest/azure: Service returned an error. Status=<nil> Code="OperationNotAllowed" Message="Cannot resize disk k8s-5b49c85f-dynamic-pvc-37eb6014-8778-11e8-b82d-000d3aa2ebc3 while it is attached to running VM /subscriptions/6d9be255-d214-4502-a51d-08e1d9c4a7fb/resourceGroups/k8s/providers/Microsoft.Compute/virtualMachines/k8s-agentpool1-17067717-0."

这一情况看来，这次扩容仍然没有生效，错误信息中有提示，无法在已经成功挂载的卷上进行扩容，因此我们清除所有 Pod：

$ kubectl scale deployment sleep --replicas 0
deployment.extensions/sleep scaled

在相关 Pod 消失之后，我们可以再次 describe pvc myclaim，发现这个 PVC 又一次处于等待绑定的状态中。使用 scale 指令恢复 Deployment 运行：

$ kubectl scale deployment sleep --replicas 1
deployment.extensions/sleep scaled
$ kubectl describe pvc myclaim
...
Capacity:      4Gi
...

PVC 的扩容再次成功了。

Kubernetes 中对持久卷进行扩容

Sun, 15 Jul 2018 00:08:31 +0800

原文：Resizing Persistent Volumes using Kubernetes

作者：Hemant Kumar

Kubernetes v1.11 中，持久卷扩容能力升级为 Beta 阶段。这个功能让用户可以轻松的通过编辑 PVC 对象的方式修改现有卷的容量。没有这一功能之前，要对卷容量进行修改，需要要和存储后端进行手工交互，或者对 PV 以及 PVC 进行删除重建操作。持久卷不支持缩容操作。

v1.8 中卷扩展功能就已经进入 Alpha 阶段，v1.11 之前需要在 feature gate 中开启 ExpandPersistentVolumes，以及 admission 控制器 PersistentVolumeClaimResize（防止在底层存储不支持扩容的情况下对 PVC 进行扩容）。在 Kubernetes v1.11 中，这两个项目都会被缺省激活。

虽然功能已经被激活，但是集群管理员还是需要进行操作，让用户能够对自己的卷进行扩容。Kubernetes 1.11 内置了对部分卷插件的扩容支持：AWS-EBS、GCE-PD、Azure Disk、Azure File、Glusterfs、Cinder、Portworx、以及 Ceph RBD。管理员确定底层存储能够支持卷扩展之后，就可以在 StorageClass 对象中设置 allowVolumeExpansion 为 true 来启用这一功能了。只有从 StorageClass 中创建的 PVC 才允许使用卷扩展：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
parameters:
  type: pd-standard
provisioner: kubernetes.io/gce-pd
allowVolumeExpansion: true
reclaimPolicy: Delete

任何从这一 StorageClass 中创建的 PVC 都能够通过编辑的方式来申请更多空间。Kubernetes 会处理 Storage 字段的变更，据此申请空间，触发卷的扩容。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi #更新这一字段，修改 PVC 容量

文件系统扩展

GCE-PD、AWS-EBS、Azure Disk、Cinder 以及 Ceph RBD 这些块存储卷通常需要首先进行文件系统的扩展，然后被扩展的卷的额外空间才能为 Pod 所用。引用这些卷的 Pod 重启时，Kubernetes 会自动完成这些任务。

网络挂载的文件系统，例如 Glusterfs 和 Azure File，因为不需要进行文件系统扩展，因此可以在不重启 Pod 的情况下直接进行扩展。

只有终止引用卷的 Pod，才会触发对应文件系统的扩展，更确切地说：

编辑 PVC，申请更多空间。
底层存储对底层卷进行了扩展之后，PV 对象就会响应这一变化，PVC 会进入 FileSystemResizePending 状态。

可以运行 kubectl get pvc <pvc_name> -o yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
  namespace: default
  uid: 02d4aa83-83cd-11e8-909d-42010af00004
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 14Gi
  storageClassName: standard
  volumeName: pvc-xxx
status:
  capacity:
    storage: 9G
  conditions:
  - lastProbeTime: null
    lastTransitionTime: 2018-07-11T14:51:10Z
    message: Waiting for user to (re-)start a pod to finish file system resize of
      volume on node.
    status: "True"
    type: FileSystemResizePending
  phase: Bound

PVC 进入 FileSystemResizePending 状态，引用 PVC 的 Pod 就可以重新启动来结束文件系统在 Node 上的扩展过程了。可以通过删除和重建 Pod 的方式进行重启，也可以通过对 Deployment 的伸缩来完成这一过程。
文件系统的扩展操作完成之后，PVC 会自动更新，设置为新的容量。

文件系统扩展过程中遇到任何错误，都会在 Pod 中以 Event 的形式表现出来。

在线文件系统扩展

Kubernetes v1.11 还引入了一个 Alpha 功能，叫做在线文件系统扩展。这个功能可以对一个正在被 Pod 使用的卷进行文件系统的扩展。这个功能还处于 Alpha 阶段，因此需要通过 Feature gate 启用 ExpandInUsePersistentVolumes。目前支持的有 GCE-PD、AWS-EBS、Cinder 以及 Ceph RBD。当激活这个功能后，引用被扩展的卷的 Pod 无需重启。文件系统会随着卷扩展的步骤进行扩展。文件系统的扩展只有在 Pod 引用被扩展的卷的时候才会发生，所以如果没有 Pod 引用这个卷，那么就不会进行文件系统扩展。

Draft vs Gitkube vs Helm vs Ksonnet vs Metaparticle vs Skaffold

Tue, 26 Jun 2018 11:29:18 +0800

原文：Draft vs Gitkube vs Helm vs Ksonnet vs Metaparticle vs Skaffold

作者：Shahidh K Muhammed

TL;DR

Draft

向 K8S 集群部署代码（自动“构建-推送-部署”）。
使用 Draft 打包支持的语言的代码可以不编写 Dockerfile 或者 K8S 元数据文件直接进行部署。
需要 draft 以及 helm 客户端，集群要部署 tiller，本地 Docker，Docker 仓库。

Gitkube

向 K8S 集群部署代码（自动“构建-推送-部署”）。
Git 推送触发部署，本机无依赖。
Git 仓库中需要提供 Dockerfile 以及 K8S 元数据文件，集群中需部署 gitkube。

Helm

在 K8S 集群上对 Chart（其中包含一个应用的所有 K8S 资源定义文件）进行部署和管理。
提供了很多通用应用（例如 MySQL、Mediawiki 等）的 Chart。
客户端需要 Helm，服务端需要 Tiller，Chart 定义可以在本地也可以在仓库中保存。

Ksonnet

在 jsonnet 上定义 K8S 元数据文件，然后进行部署。
可以对通用模式（例如 Deployment + Service）和应用栈（例如 Redis）进行复用。
需要 jsonnet 知识，安装 ksonnet 客户端。

Metaparticle

使用 Metaparticle 支持的语言编写代码，然后部署到 K8S 集群（自动“构建-推送-部署”）
在应用的代码中直接定义容器化和 K8S 相关内容，傻瓜化的编写过程，无需编写 Dockerfile 或者 Yaml。
需要本地 Docker 部署，需要相关语言的库。

Skaffold

向 K8S 集群部署代码（自动“构建-推送-部署”）。
监控源代码变更，变更发生后就会触发“构建-推送-部署”过程，Pipeline 可配置。
需要 Skaffold 客户端、Dockerfile、K8S 元数据文件、Skaffold 元数据文件，本地 Docker 以及私库。

下面进入一点细节。

当今的 Kubernetes 炙手可热，用户们寻求更多的方式和流程来进行 Kubernetes 集群上的应用部署。kubectl 已经成为底层工具，用户需要更易用的流程。Draft、Gitkube、Helm、Ksonnet、MetaParticle 以及 Skaffold 都是用来帮助开发人员在 Kubernetes 上进行应用构建和部署的工具。

Draft、Gitkube 和 Skaffold 减轻了开发人员的负担，在构建应用的过程中，能够更快的在 Kubernetes 上运行起来。Helm 和 Ksonnet 提供了定义应用、更新版本、选择不同集群等功能，在应用构建完成，进入发布就绪状态之后，这两个工具可以提高部署能力。Metaparticle 是比较独特的一个，他把包含 yaml、dockerfile 这些东西集成到业务代码之中。

所以用户自身的用例中如何进行选择？

正文

Draft

在任何 Kubernetes 集群上简化应用的开发和部署。

顾名思义，Draft 让面向 Kubernetes 的应用开发变得简单。官方宣称，对于运行在 Kubernetes 上的应用，Draft 这一工具是帮助开发过程而非部署的。Draft 文档中推荐使用 Helm 进行应用部署。

他的目标是：开发人员还在开发调试之中的本地的代码，不经提交到版本控制系统，直接运行到 Kubernetes 集群上。开发人员对 Draft 发布的应用变更满意之后，才提交给版本控制系统。

Draft 不是用来在生产环境上进行部署的，他的用意就是在于快速推进面向 Kubernetes 环境的开发过程。他内部使用 Helm 来进行变更，因此他和 Helm 的集成是非常紧密的。

架构

如上图所示，Draft 客户端是一个关键组件。它感知代码的变化，然后从 Repo 中获取对应的 Pack。Pack 是一个 Dockerfile 和 Helm chart 的合体，他们一起定义了应用的运行环境。Pack 定义之后保存在 Repo 中。用户可以定义自己的 Pack 和 Repo，这两个对象可以保存在本地，也可以在 Git 仓库之中。

只要有对应的 Pack，任何一个包含源码的目录都可以进行部署。使用 draft create 处理目录之后，会在目录中添加 Dockerfile、Helm chart 以及 draft.toml 文件，draft up 能够构建 Docker 镜像，推送到私库，然后使用 Helm Chart 部署应用。每次代码变更之后，再次执行这一命令，就会产生一个新的部署。

draft connect 命令能够进行端口转发，以此在本地获取容器的日志。他还能够和 nginx-ingress 集成，为上面部署的应用提供域名。

从 0 到 Kubernetes

下面是一个用 Draft 把 Python 应用运行到 K8S 集群上的步骤。可以从官方文档获得更详细的指导。

先决条件

Kubernetes 集群（包括 kubectl）
Helm 客户端
Draft 客户端
Docker

Docker 镜像库

$ helm init
$ draft init
$ draft config set registry docker.io/myusername
$ git clone https://github.com/Azure/draft
$ cd draft/examples/example-python
$ draft create
$ draft up
## 代码修改
$ draft up

用例

开发运行在 Kubernetes 上的应用。
用于在提交到版本控制之前的“内部流程”。
预 CI：应用完成 Draft 过程之后，可以由 CI/CD 接管。
不应该用在生产环境部署环节。

Gitkube

使用 git push 构建 Docker 镜像并在 Kubernetes 上进行部署。

Gitkube 是一个用来构建 Docker 镜像并向 Kubernetes 上部署的工具，他的起点就是 git push，不像 Draft，他不需要客户端，只需在集群上独立运行。

任何带有 Dockerfile 的代码仓库，都可以使用 gitkube 进行部署。Gitkube 安装和部署在集群之上，开发人员可以获取一个包含 git URL 的 CRD。开发人员推送到仓库的代码，会触发集群一端的 Docker Build 以及 Kubectl 发布流程。可以使用 kubectl 或 helm 等类似工具给应用创建应用元数据。

Gitkube 的重点是即插即用的安装过程，以及沿用既有的知名工具（git 以及 kubectl）。对需要部署的仓库没有什么假设。Docker build 的上下文以及 Dockerfile 所在路径，都可以进行配置。Git 连接认证是通过 SSH 公钥进行的。任何时候代码发生变更、提交和推送，都会触发后面的构建和部署过程。

架构

集群侧有三个组件，一个远程 CRD 可以定义针对一个远端 URL 发生 Push 的时候如何应对，gitkubed 构建 Docker 镜像并更新部署，gitkube-controller 会监控 CRD，随变化更新 gitkubed。

在集群上创建这些对象之后，开发者就可以使用 kubectl 来创建应用的定义了。创建一个 remote 对象，告诉 gitkube，当 git push 发生时该做什么。Gitkube 把远程 url 写回到 remote 对象的状态字段中。

从 0 到 Kubernetes

先决条件
- Kubernetes 集群（包括 kubectl）。
- git。
- 集群上安装好 gitkube （kubectl create）。

下面是将应用提交到 Kubernetes 的步骤，也包含了 gitkube 的安装过程。

已经过时

$ git clone https://github.com/hasura/gitkube-example
$ cd gitkube-example
$ kubectl create -f k8s.yaml
$ cat ~/.ssh/id_rsa.pub | awk '$0="  - "$0' >> "remote.yaml"
$ kubectl create -f remote.yaml
$ kubectl get remote example -o json | jq -r '.status.remoteUrl'
$ git remote add example [remoteUrl]
$ git push example master
## 编辑代码
## 提交和推送

用例

使用 Git 进行简单的部署，无需 Docker Build。
在 Kubernetes 上开发应用。
开发过程中，WIP 分支可以多次提交，迅速反馈。

Helm

Kubernetes 的包管理系统。

Helm 使用一种称为 Chart 的形式，来管理 Kubernetes 上的应用。Helm 为应用创建 YAML 并进行版本化操作，这样可以对包含 Deployment 在内的所有对象进行回滚。Chart 可以包含 Deployment、Service 以及 Configmap 等。Chart 的模板允许用户方便的修改部署细节，另外还支持带有依赖关系的复杂应用。

Helm 的主要目标是在生产环境中部署和管理应用程序。对比 Draft 和 Gitkube，Helm 不是用来开发的，而是用来部署的。另外现在有大量的预构建 Chart 可以供 Helm 使用。

架构

首先看看 Chart。我们之前说过，Chart 之中包含一系列的信息，这些信息是部署应用到 Kubernetes 中的必要条件。其中可能包含 Deployment、Service、Configmap、Secret 以及 Ingress 等。所有的定义都是以 Yaml 文件模板的形式出现，另外还包含嵌套的依赖 Chart。Chart 可以在 Chart 仓库中发布。

Helm 有两个主要组件，分别是 Helm 客户端和 Tiller 服务器。客户端用于管理 Chart 和仓库，并且和 Tiller 服务器进行通信，来完成对 Chart 的部署和管理。

Tiller 组件运行在集群上，和 Kubernetes API 服务器打交道，进行对象的实际操作。

Helm 不处理源码，用户需要使用 CI/CD 系统来构建镜像，然后用 Helm 来部署合适的镜像。

从 0 到 Kubernetes

先决条件
- Kubernetes 集群
- Helm 客户端

接下来是一个在 Kubernetes 集群上使用 Helm 部署 Wordpress 博客的例子：

$ helm init
$ helm repo update
$ helm install stable/wordpress
## 更新版本
$ helm upgrade [release-name] [chart-name]

用例

打包：包含多个 Kubernetes 对象的复杂应用可以集中在一起。
可复用的 Chart 仓库。
可以轻易部署在多个环境上。
可嵌套的结构，能够解决依赖关系。
参数化的模板。
容易复用。
持续交付的最后一公里。
只能部署已经构建完成的镜像。
具备生命周期管理能力，可以管理多个 Kubernetes 对象的升级和回滚。

Ksonnet

一个支持客户按操作的框架，提供可扩展的 Kubernetes 配置。

Ksonnet 是为 Kubernetes 定义应用配置的另一种方法。它并没有使用 Kubernetes 世界中常用的 YAML 语言，改用一种称为 Jsonnet 的 JSON 模板语言。Ksonnet 客户端最终会渲染出 YAML 文件并提交给集群。

这一系统的主要功能就是定义可复用的组件，并利用该工具渐进式的进行程序构建。

架构

基础的构建单位被称为 part，part 可以协作构成 prototype。一个 prototype 配合参数之后，就成为了一个 component，component 可以聚合在一起，成为一个 application。application 可以部署到多个 environment 之中。

最基础的流程就是使用 ks init 命令创建一个应用目录，使用 ks generate 生成（或者也可以自行编写）component 的元数据文件，使用 ks apply <env> 命令可以把应用部署到集群/环境之中。可以用 ks env 命令来管理不同的环境。

简而言之，Ksonnet 帮助用户定义和管理应用，他把应用视作一系列使用 Jsonnet 的组件进行管理，并部署在不同的 Kubernetes 集群上。

跟 Helm 类似，Ksonnet 不和源码发生关系，他是一个使用 Jsonnet 为 Kubernetes 定义应用的工具。

从 0 到 Kubernetes

先决条件
- Kubernetes 集群
- ksonnet 客户端

接下来是一个留言板例子：

$ ks init
$ ks generate deployed-service guestbook-ui \
     --image gcr.io/heptio-images/ks-guestbook-demo:0.1 \
     --type ClusterIP
$ ks apply default
## 变更
$ ks apply default

用例

使用 Jsonnet 编写配置很有弹性。
打包：复杂配置可以用匹配组件的方式集成起来。
可复用的组件和原型库：避免重复。
方便的多环境部署。
CD 的最后一步。

Metaparticle

为容器和 Kubernetes 而生的云原生标准库。

Metaparticle 将自己定位于云原生应用的标准库，他内置了经过验证的分布式系统模式，而开发人员可以用习惯的编程语言通过原语的方式方便的采用这些先进模式。

他提供了简易的语言接口，帮助用户构建可以容器化并部署到 Kubernetes 上的应用，这些应用会直接兼容负载均衡等基础设施。无需自行编写 Dockerfile 或者 Kubernetes 元数据文件，所有相关内容都在代码中的用原语来体现。

例如一个 Python Web 应用，可以给 main 函数加入一个叫做 containerize 的 Decorator（从 metaparticle 中 import）。当执行这段 Python 代码的时候，会构建 Docker 镜像并部署到 Decorator 参数中提到的 Kubernetes 集群上。缺省集群定义来自 kubectl 上下文。所以切换环境就和切换当前上下文是等价的。

在 NodeJS、Java 以及 .NET 上也提供了类似的原语。另外还正在开发更多的语言支持。

架构

各种语言的 metaparticle 库都包含所需的原语，绑定了构建 Docker 镜像、推送到私库、创建 Kubenretes yaml 文件并在集群上部署的代码。

Metaparticle 包中内置了各种语言用来构建容器的支持。而 Metaparticle Sync 则包含了在不同机器上运行的不同容器进行同步的能力。

目前支持的语言包括：JavaScript/NodeJS、Python、Java 以及 .NET。

从 0 到 Kubernetes

先决条件
- Kubernetes 集群。
- 特定语言的 Metaparticle 库。
- Docker。
- Docker 私库。

一个只包含相关内容的 Python 例子，可以使用这些代码构建 Docker 镜像，并在 Kubernetes 上进行部署。

@containerize(
    'docker.io/your-docker-user-goes-here',
    options={
        'ports': [8080],
        'replicas': 4,
        'runner': 'metaparticle',
        'name': 'my-image',
        'publish': True
    })
def main():
    Handler = MyHandler
    httpd = SocketServer.TCPServer(("", port), Handler)
    httpd.serve_forever()

用例

只想开发应用，不想担心 Kubernetes YAML 或者 Dockerfile。
不想掌握多种工具和文件格式，又想搭上容器和 Kubernetes 快车的开发人员。
快速开发可复制可负载均衡的服务。
在多个分布式副本之间进行同步，例如加锁、或者选举操作。
简单开发云原生模式的应用，例如分片系统。

Skaffold

简单可重复的 Kubernetes 开发。

Skaffold 能够处理构建镜像、推送镜像以及在 Kubernetes 上进行部署。跟 Gitkube 类似，任何包含 Dockerfile 的目录都可以用 Skaffold 部署到 kubernetes 集群上。

Skaffold 会在本地构建 Docker 镜像，推送到私库，然后使用 skaffold 客户端进行部署。他还会监测目录，如此一来，目录中的代码一旦发生变化，就会触发重新构建和部署。这个过程还会从容器中获取日志。

可以使用 YAML 文件来构建、推送、部署的 Pipeline，所以开发者可以混合使用合适的工具，例如 Docker build 和 Google Container Builder，Kubectl 和 Helm 等。

架构

Skaffold 客户端做了所有的工作。他会查找一个叫做 skaffold.yaml 的文件，其中包含了必须完成的任务。一个典型的例子就是在 skaffold dev 运行的目录中查找 Dockerfile 构建 Docker 镜像，并使用 sha256 进行标记，推送镜像，把镜像设置到 Kubernetes 元数据文件之中，最后发布到集群上。这一系列动作会被目录中的变更所触发。来自部署容器的日志会出现在同一个 Watch 窗口中。

Skaffold 和 Draft 和 Gitkube 很像，但是更具弹性，如上图所示，他能管理不同的“构建-推送-部署”流程。

从 0 到 Kubernetes

先决条件
- Kubernetes 集群
- Skaffold 客户端
- Docker
- Docker 镜像库

下面的步骤，部署一个 Go 编写的 Hello World 应用：

$ git clone https://github.com/GoogleCloudPlatform/skaffold
$ cd examples/getting-started
## 编辑 skaffold.yaml，加入 Docker 仓库
$ skaffold dev
## 打开新终端: 编辑代码

用例

方便部署。
迭代构建——持续的构建-发布流程。
为 Kubernetes 开发应用。
在 CICD 流程中定义“构建-推送-部署”流程。

Containerd 1.1.0 尝鲜记

Wed, 30 May 2018 00:41:44 +0800

Containerd 1.1.0 的 Kubernetes 支持已经进入可用阶段，Kubernetes 1.10 和未来的的 Docker 版本都会以此为基础，作为一个熟练软件安装工，自然是要先睹为快了。

这里使用 Kubeadm 进行测试。

环境准备

首先进行 Kubeadm 的环境准备：

安装 libseccomp, conntrack
关闭防火墙服务
开启 sysctl：ip_forward、net.bridge.bridge-nf-call-iptables
参考官方指南，安装 kubeadm、kubelet 以及 kubectl，此处暂时不启动 kubelet 服务。

安装 contaierd

下载 cri-containerd 1.1.0，并解压，其中包含 /usr、/etc 以及 opt 三个目录，这里我们只是用前两个目录的内容，目录结构如下，直接复制即可：

├── etc
│   ├── crictl.yaml
│   └── systemd
│       └── system
│           └── containerd.service
└── usr
    └── local
        ├── bin
        │   ├── containerd
        │   ├── containerd-release
        │   ├── containerd-shim
        │   ├── containerd-stress
        │   ├── crictl
        │   ├── critest
        │   └── ctr
        └── sbin
            └── runc

crictl.yaml：crictl 的配置文件，缺省包含一行 runtime-endpoint: unix:///run/containerd/containerd.sock，指定运行时的连接方式。
containerd.service：服务文件，设置自动启动即可。
ctr：containerd 客户端
crictl：cri 客户端
runc：运行时，contaienrd 依赖项

这里可以发现，并没有包含 containerd 自己的配置文件，可以使用 containerd config default > /etc/containerd/config.toml 命令，来生成缺省配置文件，然后自行变更。例如可以修改仓库镜像地址。

另外对国内用户比较重要的一点是，仍然是可以使用环境变量方式的配置来设置 HTTP_PROXY 以及 NO_PROXY 的内容。

配置完成后，使用 systemctl 启动服务。

载入镜像

docker.io/coredns/coredns:1.0.6
k8s.gcr.io/kube-proxy-amd64:v1.10.3
k8s.gcr.io/etcd-amd64
k8s.gcr.io/kube-apiserver-amd64:v1.10.3
k8s.gcr.io/kube-controller-manager-amd64:v1.10.3
k8s.gcr.io/kube-proxy-amd64:v1.10.3
k8s.gcr.io/kube-scheduler-amd64:v1.10.3
k8s.gcr.io/pause:3.1

ctr 的镜像载入命令：ctr cri load image.tar，似乎不支持 gz。

配置 Kubelet 使用 containerd

简单的在 Kubelet 的环境变量上加入如下内容，再启动 Kubelet 服务：

[Service]
Environment="KUBELET_EXTRA_ARGS=--runtime-cgroups=/system.slice/containerd.service --container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock"

Kubeadm 集群安装

这里提供一个简单的初始化命令：

kubeadm init \
--pod-network-cidr=192.168.0.0/16 \
--feature-gates CoreDNS=true \
--ignore-preflight-errors=Service-Docker \
--ignore-preflight-errors=SystemVerification \
--kubernetes-version=v1.10.3 # 防止 kubeadm 向服务器查询镜像列表。

Kubeadm 缺省情况下依旧是需要检查 Docker 的运行情况的，因此这里我们使用 --ignore-preflight-errors 开关关闭这项检查。

Master 初始化结束之后，就可以跟随 kubeadm 指示，进入其他节点，运行 kubeadm join 命令来加入集群了，加入命令同样需要设置 --ignore-preflight-errors=all 来规避 Docker 检查。

接下来可以按照自己喜好安装网络插件了。

可以使用 kubectl describe nodes [node name] 来检查节点信息：

...
Container Runtime Version:  containerd://1.1.0
Kubelet Version:            v1.10.3
Kube-Proxy Version:         v1.10.3
PodCIDR:                     192.168.0.0/24
...

这里可以看到，运行时已经更新为 containerd://1.1.0

后记

正如在前面文章提到的，containerd 并非 Docker 的替代品，只是一个子集，独立使用是很困难的，因此还是比较适合用于 Kubelet 控制之下的容器运行支持。

下载链接以及参考链接

cri-containerd 1.1.0：https://storage.googleapis.com/cri-containerd-release/cri-containerd-1.1.0.linux-amd64.tar.gz
kubeadm 安装指南：https://kubernetes.io/docs/tasks/tools/install-kubeadm/
containerd 安装指南：https://github.com/containerd/containerd/releases
Containerd 1.1.0 的 Kubernetes 支持已经进入可用阶段： https://blog.fleeto.us/post/kubernetes-containerd-integration-goes-ga/

Kubernetes Containerd 集成进入 GA 阶段

Fri, 25 May 2018 02:09:22 +0800

原文：Kubernetes Containerd Integration Goes GA

作者：

在之前的博客（Containerd Brings More Container Runtime Options for Kubernetes）中，我们介绍了 Kubernetes Containerd 集成的 Alpha 版本。经过六个月的开发，Containerd 的集成现在进入了 GA 阶段，现在可以将 Containerd 1.1 作为容器运行时为生产环境的 Kubernetes 提供支撑了。

Containerd 1.1 支持 Kubernetes 1.10 及以上版本，支持 Kubernetes 的所有特性。目前在 Kubernetes 的测试设施中，Containerd 在 Google 云平台上的测试覆盖已经和 Docker 集成持平了。（参见：Test Dashboard）。

很高兴看到 Containerd 快速成长到今天的这一重要里程碑。阿里云从 Containerd 诞生之初就开始积极的采用 Containerd，开发团队对于简单和健壮的重视，使其完美的运行在我们的无服务器 Kubernetes 产品之中，提供了很好的性能和稳定性。Containerd 无疑将会成为容器世界的核心引擎，并持续创新前行。

Xinwei，阿里云工程师。

架构提升

Kubernetes 的 Containerd 集成架构有两次重大改进，每一次都让整个体系更加稳定和高效。

Containerd 1.0 - CRI-Containerd（已终止）

Containerd 1.0 中，需要一个叫做 cri-containerd 的守护进程，他的功能是提供 Kubelet 和 Containerd 之间的互操作支持。Cri-Containerd 处理来自 Kubelet 的容器运行时接口（CRI）服务请求，并使用 containerd 来管理容器和容器的镜像。对比之前的 Docker CRI 实现（Dockershim），他清理了整个体系中的一些多余部分。

然而 Cri-containerd 和 Containerd 1.0 还是两个不同的守护进程，相互之间使用 gRPC 进行通信。额外进程给用户的理解和部署都造成了麻烦，并引入了不必要的通信开支。

Containerd 1.1 - CRI 插件（目前）

在 Containerd 1.1 中，Cri-containerd 守护进程进行了重构，成为了 Containerd 的 CRI 插件。CRI 插件处于 Containerd 1.1 内部，缺省启用。和 Cri-containerd 不同，CRI 插件和 Containerd 之间通过直接的程序调用来协同工作。新架构让这一产品更加稳定高效，去除了过程中的 gRPC 开销。用户现在可以直接使用 Containerd 1.1 来支撑 Kubernetes，不再需要 Cri-containerd 守护进程。

性能

Containerd 1.1 的一个主要目标就是提高性能。这里的性能主要指的是 Pod 启动延迟以及守护进程的资源使用情况。

下面的结果是 Containerd 1.1 和 Docker 18.03 CE 之间的对比。Containerd 1.1 集成使用了内置其中的 CRI 插件；Docker 18.03 CE 集成使用的是 Dockershim。

下面的结果是使用 Kubernetes 节点性能 Benchmark 生成的，这个 Benchmark 工具是 Kubernetes 节点端到端测试的一部分。绝大多数的 Containerd 测试结果都是可以在节点性能 Dashboard 上进行公开访问的。

Pod 启动延迟

“105 pod batch startup benchmark” 结果显示，相对 Docker 18.03 CE 的 dochershim 集成来说，Containerd 1.1 的集成的延迟时间更短（越低越好）。

CPU 和内存

在 105 个 Pod 的稳定状态下，Containerd 1.1 集成消耗的 CPU 和内存都比 Docker 18.03 CE 的 Dockershim 集成要少。这个结果和节点上运行的 Pod 数量关系紧密，之所以选择 105 这个数字，是因为这是目前每节点上运行 Pod 的缺省数量上限。

如下图所示，对比 Docker 18.03 CE 的 Dockershim 集成，Containerd 1.1 集成的 Kubelet CPU 占用降低了 30.89%，容器运行时 CPU 消耗降低了 68.13%，Kubelet 实际使用内存（RSS）降低了 11.30%，容器运行时 RSS 降低了 12.78%。

crictl

容器运行时命令行接口（CLI）对系统和应用的排错来说是个有用的工具。如果用 Docker 作为 Kubernetes 的容器运行时，系统管理员有时候需要登录到 Kubernetes 节点上去运行 Docker 命令，以便收集系统和应用的信息。例如使用 docker ps 和 docker inspect 检查应用的进程情况，docker images 列出节点上的镜像，或者 docker info 来检查容器运行时的配置等。

对 Containerd 和所有其他的 CRI 兼容的容器运行时，尤其是 Dockershim 来说，我们推荐使用 crictl 作为 Docker CRI 的继任者，用于 Kubernetes 节点上 pod、容器以及镜像的除错工具。

crictl 在 Kubernetes 节点除错方面，提供了类似 Docker CLI 的使用体验，并且 crictl 能够支持所有 CRI 兼容的容器运行时。这一项目存放于 kubernetes-incubator/cri-tools，目前版本是 v1.0.0-beta.1。crictl 的设计目的是理顺 Docker CLI 的功能，为用户提供更好的过渡体验，但是和 Docker CLI 又不尽相同。下面讲讲两者之间的一些重要区别。

适用范围：crictl 是一个排错工具

crictl 的设计目的是排错，并非 Docker 或者 kubectl 的替代品。Docker 的 CLI 提供了大量的命令，使之成为重要的开发工具，但是在 Kubernetes 节点排错方面，就不尽人意了。有些 Docker 命令在 Kubernetes 上没什么用，例如 docker network 和 docker build；有些甚至会损害系统，比如说 docker rename，crictl 提供了刚好够用的命令来进行节点方面的除错工作，对于生产节点来说，明显会有更好的安全性。

Kubernetes 特性

crictl 提供了一个对 Kubernetes 来说更加友好的容器视角。Docker CLI 并不了解 Kubernetes 的概念，例如 pod 和 namespace，所以他无法提供容器和 Pod 的清晰视图。一个例子就是 docker ps 的混乱输出：过长的 Docker 容器名称、Pause 容器和应用容器混杂在一起：

Pause 容器是一个 Pod 的实现手段，每个 Pod 都会有一个 Pause 容器，所以列出 Pod 中包含的容器的时候，没必要把 Pause 容器显示出来。

而 crictl 是为 Kubernetes 设计的，他有不同的一组命令来和 Pod 以及容器进行交互。例如 crictl pods 会列出 Pod 信息，而 crictl ps 只会列出应用容器的信息。所有的信息都以表格形式进行展示。

关于 crictl 在 containerd 方面的细节，可以参看：

Docker 怎么办？

“切换到 Containerd 是不是说我不能再用 Docker Engine 了？”我们经常听到这个问题，简单的答案就是：NO。

Docker Engine 是在 Containerd 之上构建的。下个版本的 Docker CE 就会使用 Containerd 1.1。当然，也就会有内置的缺省激活的 CRI 插件。这样一来，用户可以选择继续使用 Docker Engine 来做一些 Docker 的事情，也可以配置 Kubernetes 来使用其中的 Containerd，同时 Containerd 还会同时给同一节点上的 Docker Engine 提供支撑。下面的架构图就描述了 Docker Engine 和 Kubelet 共用 Containerd 的情况：

既然 Containerd 同时能够给 Kubelet 和 Docker Engine 提供支持，选择了使用 Containerd 集成的用户，得到的不仅仅是新的 Kubernetes 特性、性能和稳定性的增强，他们还会得到保留 Docker Engine 以便用于其他用例的选择。

Containerd 的命名空间机制，让 Kubelet 和 Docker Engine 之间无法互相访问对方的容器和镜像。这样就保证了他们无法互相影响，这样的后果：

用 docker ps 命令无法看到 Kubernetes 创建的容器；而应该使用 crictl ps。反之亦然，用 crictl ps 也是无法看到 Docker CLI 创建的容器。crictl create 以及 crictl runp 命令只用于出错。不推荐在生产节点上手动使用 crictl 启动 Pod 或者容器。
docker images 不会看到 Kubernetes 拉回的镜像。同样需要使用 crictl images 命令。反过来用 docker pull、docker load 或者 docker build 生成的镜像，Kubernetes 也是无法看到的。可以使用 crictl pull 命令来替代，可以使用 [ctr](https://github.com/containerd/containerd/blob/master/docs/man/ctr.1.md) cri load 来载入镜像。

总结

Containerd 1.1 天然支持 CRI，可以直接给 Kubernetes 使用。
Containerd 1.1 满足生产要求。
Containerd 1.1 在 Pod 启动延迟和系统资源占用方面具有良好的性能表现。
crictl 是用于和 Containerd 1.1 以及其他 cri 兼容的容器运行时进行操作和节点除错的 CLI 工具。
下一个 Docker CE 版本会包含 Containerd 1.1。用户有选择继续使用 Docker 来满足 Kubernetes 之外的容器需求，同时让 Kubernetes 使用来自 Docker 的同样的底层容器运行时。

这里要感谢来自 Google、IBM、Docker、ZTE、ZJU 以及很多其他的个人，让这一产品发展至今。

可以阅读 Release Notes，来了解 Containerd 1.1 详细的变更情况。

尝鲜

要使用 Containerd 作为 Kubernetes 的容器运行时来搭建集群：

在 GCE 上用 kube-up.sh 来启动一个生产级别的集群
使用 Ansible 和 Kubeadm 搭建多节点集群
在 Google 云从头搭建集群，可以看看 Kubernetes the Hard Way
从发布压缩包开始自定义安装
使用 LinuxKit 在本地虚拟机上安装

贡献

Container CRI 插件是一个开源的 Github 项目，在 Containerd 之内：https://github.com/containerd/cri。我们欢迎任何建议、问题、代码方面的贡献。开发者起步指南提供了如何成为贡献者方面的入门知识。

社区

这个项目的开发和维护是由 Kubernetes SIG-Node 社区和 Containerd 社区联合负责的。我们希望能听到用户的反馈，要加入集群：

SIG-Node 社区网站
Slack：
- #sig-node，kubernetes.slack.com
- #containerd, https://dockr.ly/community
邮件列表：https://groups.google.com/forum/#!forum/kubernetes-sig-node

在 K8S 集群中分布构建 Docker 镜像

Fri, 18 May 2018 18:48:12 +0800

镜像更新

最近给我的 Jenkins 镜像做了一些更新：

加入了基于 RunC 的镜像操作工具：IMG。在特权模式下，可以方便的使用命令行创建和操作 Docker 镜像。
更新 Jenkins 以及 Remoting 版本。
修复一些初始化问题。

下面根据这一版本的镜像简单说说分布式构建过程中的一些要点。

Jenkins 镜像的一些值得注意的东西

Jenkins 在启动 Slave 节点时，会设置下面三个环境变量，所以在 run.sh 就可以引用这几个环境变量启动 Worker 节点：
- JENKINS_URL：MASTER 服务的地址。
- JENKINS_NAME：为 Worker 节点分配的名称
- JENKINS_SECRET：Worker 节点和 Master 节点通信时所使用的认证密钥。
```
java \
-cp /usr/share/jenkins/slave.jar hudson.remoting.jnlp.Main \
-headless -url $JENKINS_URL $JENKINS_SECRET $JENKINS_NAME
```
img 工具依赖于 runc，因此也需要把 runc 加入到镜像之中。
config.xml 中：
- 直接设置了 8081 作为 jnlp 端口，因此在 Dockerfile 中也进行了 EXPOSE 声明。
- 开启 CSRF 选项，并设置代理服务器兼容，防止在 Kube-Proxy 的情况下无法提供服务。

Jenkins 在 Kubernetes 中的启动：

RBAC：因为要启动 Worker 节点，因此在开启了 RBAC 的集群上，要给 Jenkins 的 Service Account 进行授权，允许进行 Pod 的操作。
Service：需要暴露 jnlp 端口到集群内部，无需为其提供 loadbalancer 以及 nodePort 等形式的外网接入能力。
可以根据需要提供加载卷，用于保存配置等。

分布式构建的配置

首先需要安装 Kubernetes 插件。
插件安装后，就可以在 Jenkins 的 credentials 中加入 Kubernetes ServiceAccount 类型的凭据，用于连接和操作 Kubernetes 集群。
容器模板设置中，系统缺省会提供一个名为 jnlp 的容器模板，要想使用自己的镜像，需要进行同名覆盖。
- 容器模板中可以按需设置加载卷等，例如要进行镜像的 PUSH 操作，就需要将 CA 证书通过一定方法加入到容器的信任列表之中。
- 如果要进行 IMG 的操作，需要选中容器的 Run in privileged mode 选项，开启特权模式。

任务的设置

要进行镜像的构建，就非常的容易，加入几行简单的 Shell 命令，例如：

mkdir tmp
# 生成一个 Dokerfile
echo "FROM registry.docker-cn.com/library/alpine" > tmp/Dockerfile
# 构建镜像
img build -t 10.211.55.19:5000/alpine:163 tmp
# 更新证书信任列表
update-ca-certificates
# 把镜像推送到私库
img push 10.211.55.19:5000/alpine:163

来自骷髅岛的 Ingress Controller：Kong

Fri, 11 May 2018 12:26:22 +0800

Kong，是一个在 Nginx 反向代理基础上发展而来的 API 网关产品。我之前一直在推动的 Service Mesh，主要关注的是集群（Mesh）内微服务之间的关系，而 API 网关所管理的则是微服务集群边缘，对外服务的管理。（据我观测，Istio 近期的文档已经出现了 Gateway 等说法，似乎也对这方面的问题颇有兴趣的样子）。

传统的 API：

API Gateway：

5 月 8 日，Kong 发布了 Ingress Controller，对 Kubernetes 和对 Kong 自身来说都是个有意思的事情。

首先，Ingress Controller 本来应该负责集群的对外通信，有些 Ingress Controller，例如 haproxy 和 Traefik 已经初步具备了这方面的能力。其次，Kong 之前使用 API 调用的方式来进行管理，在 Ingress Controller 的上下文中，改用 CRD 方式进行管理，对于我等 YAML 程序员来说，无疑是个大大的利好消息。

Kong 使用插件的方式提供了一些常见功能，这些现在也可以用 CRD 方式进行使用，其中包括日志、限流、认证、鉴权几大类。

Kong 同时提供商业和社区两个版本，目前有部分插件也是商业版独占的。

今天这一篇，就会对 Kong Ingress Controller 从部署到应用的介绍。

安装

官方提供了一个简易的 Kubernetes 环境中的安装文件；另外在 Ingress Controller 出现之前，Kong 也有一个相对更丰富的 Kubernetes 下的安装文档。

全部组件都运行在 kong 命名空间。

数据库

安装过程中会创建一个 Postgres 的 StatefulSet，前面提到，这一版本对 Kubernetes 集群的最低版本要求是 1.8，如果是 1.8 版本，需要将这一个 StatefulSet API 版本改为 apps/v1beta2。另外这一部分需要用 PVC 的形式给数据提供存储空间，所以集群中应该设置缺省 StorageClass。完整的 Kubernetes 安装文档中，还介绍了 Cassandra 的存储方式。

CRD

安装过程中创建了如下的自定义资源：

凭据：用于身份认证。
服务消费者：给不同的 API 用户提供不同的消费者身份，以便实施不同的治理方式。
插件：将过去使用 HTTP API 管理的插件系统，以 CRD 的形式在 Kubernetes 环境下统一管理。
KongIngress：对反向代理行为本身进行定义。

服务

其中提供了两组服务：

kong-ingress-controller：暴露 8001 端口，用于对 Kong 进行管理。这里建议将服务类型改为 ClusterIP，而不是直接暴露于公网。
kong-proxy：Ingress 服务，对其承载的接口调用都从此经过，可以根据集群情况酌情使用 NodePort 或者 ClusterIP -> Ingress 的方式对外提供服务。

提供服务

安装结束后，就可以使用网关来对外提供服务了。

官方提供了一个简单的例子应用，我们当然也可以选择别的应用来试用。为他编写一个 Ingress 资源：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: dummy
  annotations:
    kubernetes.io/ingress.class: nginx # 这里仍然是 nginx
spec:
  rules:
  - host: dummy.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: http-svc
          servicePort: 89

如果没有公网 Loadbalancer 条件，可以使用 /etc/hosts、dnsmasq、或者 curl host 几种方式来模拟。

ingress 资源创建成功之后，就可以使用域名来访问这一服务了。

TLS 加密

作为 Ingress Controller，添加证书提供 https 服务也是基本要求之一。这方面 Kong Ingress Controller 使用的是 tls secret 的方式：

首先获取证书，可以自行签名，或者使用已有证书文件。
kubectl create secret tls rocks --key privkey.pem --cert fullchain.pem：创建一个名为 rocks 的 Secret，其中包含我们的证书和私钥。
在 Ingress 资源定义中加入下列内容，引用刚才创建的 Secret：
```
tls:
- hosts:
- dummy.example.com
secretName: rocks
```

这样就可以使用 https 进行访问了。

试用限流插件

前面提到，Kong Ingress Controller 使用 CRD 方式来实现插件的应用。下面我们创建一个限流插件的 CRD：

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: one-per-second-ten-per-hour
config:
  hour: 10
  limit_by: ip
  second: 1

目前并没有很完善的插件 CRD 规范的文档，因此其中的具体字段需要去该插件的文档页面去查找，例如这里引用的 Ratelimit。在这一个 YAML 中我们会发现，其中并没有表明具体使用的插件以及对应的服务，通过对 controller 管理端口的 /plugins 进行查询，也会看到其中并没有定义活动的插件。

要把它应用到具体服务上，还需要修改我们要控制的 Ingress 资源，在其中加入注解，来引用这一 CRD：

kubernetes.io/ingress.class: nginx
rate-limiting.plugin.konghq.com: one-per-second-ten-per-hour

提交新的 Ingress 之后，再次访问管理端口的 plugins 路径，会得到以下响应：

{
    "total": 1,
    "data": [
        {
            "created_at": 1525966801000,
            "config": {
                "redis_database": 0,
                "policy": "cluster",
                "redis_timeout": 2000,
                "hide_client_headers": false,
                "hour": 20,
                "limit_by": "ip",
                "redis_port": 6379,
                "second": 10,
                "fault_tolerant": true
            },
            "id": "8539eb6f-5467-11e8-a92e-000d3a07d45d",
            "name": "rate-limiting",
            "enabled": true,
            "route_id": "f2961715-11fd-410a-a934-dbd6822e5fac"
        }
    ]
}

可以使用 siege 或者 curl/wrk 等其他工具来访问 API，会发现超过限度之后，服务器返回 429 的状态码：

HTTP/1.1 200     0.20 secs:     727 bytes ==> GET  /
HTTP/1.1 200     0.22 secs:     729 bytes ==> GET  /
HTTP/1.1 429     0.20 secs:      38 bytes ==> GET  /
HTTP/1.1 429     0.21 secs:      38 bytes ==> GET  /
HTTP/1.1 429     0.20 secs:      38 bytes ==> GET  /
HTTP/1.1 200     0.20 secs:     729 bytes ==> GET  /
HTTP/1.1 200     0.20 secs:     727 bytes ==> GET  /
HTTP/1.1 429     0.20 secs:      38 bytes ==> GET  /

证明限流功能已经生效。

试用消费者

前面提到，可以使用消费者这一概念，对微服务的用户身份加以甄别，从而提供不同的管控方式。在前面的基础上，我们希望为部分用户修改一下响应内容。

首先创建一个 KongConsumer 对象：

apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: rich
username: boss

接下来，为这个用户创建凭据，凭据是需要认证的，所以还要启用一个插件：key-auth，官方文档中并没有提及这一点：

apiVersion: configuration.konghq.com/v1
kind: KongCredential
metadata:
  name: rich-login
consumerRef: rich # 如果删除这一字段，就代表面向所有消费者。
type: key-auth
config:
  key: 62eb165c070a41d5c1b58d9d3d725ca1

然后，为这个用户创建一个插件配置

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rich-response
consumerRef: rich
config:
  hour: 100
  limit_by: ip
  second: 10

最后，在 Ingress 资源中启用两个插件，分别是 key-auth 和 response-transformer

response-transformer.plugin.konghq.com: boss
key-auth.plugin.konghq.com: auth

重新配置 Ingress 之后，可以使用 curl 进行校验：

curl --header "apikey: aasome_key_data" -s -i https://dummy.example.com
HTTP/1.1 403 Forbidden
Date: Fri, 11 May 2018 04:17:57 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: kong/0.13.1

{"message":"Invalid authentication credentials"}

可以看到上面的认证没能通过。

curl --header "apikey: some_key_data" -s -i https://dummy.example.com | grep boss
boss:  true
    x-consumer-username=boss2

Key Auth 认证插件根据 APIKey 取得了用户名，并且激活了 Response Transformer 插件，在 Header 中加入了我们配置的内容。

Kong 原有的 API 在这里还是可以使用的，例如： 1. curl http://[api-url]/plugins 查询生效插件 2. curl http://[api-url] 返回 JSON 中的 /plugins/available_on_server 列出所有可用插件。 3. curl ttp://[api-url]/consumers 列出所有消费者。

Kubernetes 中用 Sidecar 为应用添加 Oauth 功能

Mon, 09 Apr 2018 18:27:46 +0800

Kubernetes 的 Pod 中可以同时运行共享网络栈的多个容器，使得 Sidecar 这种服务协作方式更加易于实施。这里我们就使用 Sidecar 方式，将 Keycloak 集成到 httpbin 服务上去，为没有认证的 httpbin 服务添加认证功能。

概要

Keycloak（链接 1）是 JBoss 的一个认证服务软件，使用代理的方式，为其他应用提供认证能力，除了本文说到的 Oauth 之外，还提供二次认证、LDAP 等丰富的相关功能。

在 Kubernetes 上部署 Keycloak 服务，对其进行初始化，建立用户和认证系统，然后将 Keycloak-Proxy 和 Httpbin 集成在同一个 Pod 中进行部署运行，测试集成效果。

集成后的访问路径如图所示：

Keycloak 服务的初始化

Keycloak 支持多种数据库存储，这里为了方便，就直接使用内置的 H2 数据库了。这里选用的镜像是jboss/keycloak:3.4.2.Final，开放服务端口 8080，并设置了三个环境变量：

KEYCLOAK_USER：KeyCloak 初始管理员账号
KEYCLOAK_PASSWORD：KeyCloak 初始管理员密码
PROXY_ADDRESS_FORWARDING：KeyCloak 部署在反向代理之后（Kubernetes 部署方式就在此列），就必须设置此变量为true

接下来部署相关的 Service，如果有必要，还需要部署相关的 Ingress。

设置 Keycloak 服务器

启动 Keycloak Server 之后，我们访问https://[keycloak service url]/auth/admin/，使用环境变量中设置的用户名密码登录，进行后续的安全设置，界面如图所示：

创建登录域

鼠标在左上角的Master字样上悬停，在弹出的菜单中选择Add Realm。
在左侧菜单Configure下面，打开Clients项，点击Create设置httpbin作为 Client ID 并保存。
设置Access Type为confidential，Valid Redirect URIs设置为*，并保存。

打开Installation标签，选择Keycloak OIDC JSON，并拷贝显示出来的 JSON 代码，其中的部分内容可能不一致。

{
"realm": "httpbin",
"auth-server-url": "https://[keycloak-server]/auth",
"ssl-required": "external",
"resource": "httpbin",
"credentials": {
  "secret": "d97cfa70-8eb1-443a-8320-4cde9da34de6"
},
"confidential-port": 0
}

创建用户

在左侧的Configure菜单上打开Roles页面，点击Add role。
设置角色名称为httpbin-role，保存。
在左手的Manage菜单中，打开Users页面，点击Add user。
填写表单，设置Email verified为ON，保存内容。
打开这一用户的Role mappings标签，在Available Roles列表中选择角色httpbin-role，点击Add selected。

这样我们就完成了登录域的创建，并为后面将要启动的 httpbin 应用创建了相关的角色和用户。

部署应用

根据前面的流程图，我们需要把 keycloak-proxy 组件用 sidecar 的方式和 httpbin 集成在一起，用反向代理的形式拦截请求，完成登录任务。

创建 proxy 配置

Proxy 配置文件内容可以参考官方文档（链接 2）

keycloak-proxy 需要一个配置文件/opt/jboss/conf，这里我们使用 configmap 的形式将其加载进来，配置文件的内容如下：

{
    "target-url": "http://localhost:8000",
    "send-access-token": true,
    "bind-address": "0.0.0.0",
    "http-port": "8080",
    "applications": [
        {
            "base-path": "/",
            "adapter-config": {
                "realm": "httpbin",
                "auth-server-url": "https://[keycloak-server]/auth",
                "ssl-required": "external",
                "resource": "httpbin",
                "credentials": {
                "secret": "d97cfa70-8eb1-443a-8320-4cde9da34de6"
                }
            }
        ,
        "constraints": [
                {
                    "pattern": "/*",
                    "roles-allowed": [
                        "httpbin-role"
                    ]
                }
            ]
        }
    ]
}

这一配置要求 Proxy 代理本机 8000 端口（httpbin 的服务端口）的通信，并以 0.0.0.0:8080 对外提供服务，secret 字段内容来自于上面Keycloak OIDC JSON的输出。

创建 httpbin deployment

在原有的应用部署的基础上，需要加入两个内容：

加载 ConfigMap
加入 Sidecar

节选 yaml 代码：

containers:
- image: citizenstig/httpbin
imagePullPolicy: IfNotPresent
name: httpd
ports:
- containerPort: 8000
    name: http-httpbin
- image: jboss/keycloak-proxy:3.4.2.Final
name: httpbin-proxy
volumeMounts:
- mountPath: /opt/jboss/conf
    name: config
ports:
- containerPort: 8080
    name: http-proxy
volumes:
- name: config
configMap:
    name: httpbin-proxy

这里完成了上述的任务。

创建服务

上面创建的 Deployment 之中有了两个端口，8080 是 keycloak 端口；8000 是 httpbin 端口，为了达到认证目的，服务应该指向 keycloak proxy 所在的 8080 端口。

测试

依次完成业务应用部署之后，就可以进行测试了。

在浏览器打开 httpbin 服务，会看到对这一服务的访问会被转向 Keycloak 的登录页面。如果输入的是管理员的账号密码，是无法成功访问服务的；而输入我们新建账号的登录凭据，则可以顺利返回。

所有 yaml 代码（链接 3）

链接

https://www.keycloak.org/
http://www.keycloak.org/docs/3.0/server_installation/topics/proxy.html
https://gist.github.com/fleeto/e4d2996b3c0dba41831504747974cf0a

Kubeadm 离线安装器 1.10

Mon, 02 Apr 2018 05:30:37 +0800

项目地址：https://github.com/fleeto/kubeadm-offline-installer

更新内容

升级到了 Kubernetes 1.10。
使用 CoreDNS 代替了原来的 KubeDNS。
升级 Calico 网络插件为 3.0.4 版。

仅在 centos 7 minimal 测试通过。

使用方法：

需要 2.4.0 以上版本的 ansible。
从 Releases 页下载和解压所需版本。
编写 Host 文件，分组方式可以参考 hosts/hosts.sample。
group_vars/all 中有部分可以修改的变量。
运行脚本。
/usr/local/bin 目录下会生成初始化和加入集群的脚本。
/etc/kubernetes 目录中包含证书和配置文件。

Kubernetes 1.10 的秘宝

Wed, 28 Mar 2018 20:22:26 +0800

原文：Kubernetes 1.10: Hidden Gems

Kubernetes 发布了 1.10 版本。这是各位贡献者和发布团队的的又一次胜利。

在 Jetstack，无论是为客户服务的 K8S 项目、或是为各级别的用户提供 K8S 培训，又或者向 K8S 社区贡献我们开发的代码，都有着同样的目的，就是将 Kubernetes 推向巅峰。我们一直在跟进这一杰出项目，并保持对其开发过程密切关注。

官方博客（注 1）中介绍了 1.10 版本中的关键特性，按照以往惯例，我们请我们的工程师分享一下他们在新版本中发现的令人激动、期待的新功能。

设备插件

Matt Turner

设备插件系统现在进入了 Beta 阶段。这一能力可以用附加的任意维度来定义节点的容量，不再只限于 CPU 和内存容量。例如一个节点可能会申明其装有三块 GPU 以及一块高性能网卡；Pod 通过标准的resources方式来申请 1 块 GPU，因此该 Pod 必须调度到一个具有空闲 GPU 的节点上。这一插件及其 API 会在为 Pod 提供使用之前，会对这些资源进行初始化和广播。

nVidia 已经提供了一个用于管理自家 GPU 的插件。请求两块 GPU 的语句如下：

resources:
    limits:
      nvidia.com/gpu: 2

CoreDNS

Charlie Egan

1.10 把 KubeDNS 变成了一个可插接组件。这样就能够更方便的使用其他工具来进行服务发现。其中的一个选项就是 CoreDNS，CoreDNS 使用一个原生插件实现了 Kubernetes 服务发现规范。他是一个单进程应用，支持缓存和健康检查（这样就无需在 DNS Pod 中使用 dnsmasq 或者是 healthz 容器了）。CoreDNS 插件在 1.10 中提升到了 Beta 阶段，最终会成为 Kubernetes 的缺省选项。

每 Pod 中的 Pid 数量限制

1.10 中的一个新的 Alpha 特性（注 2）就是控制每 Pod 中 Pid 总数的能力。Linux 核心提供了进程数控制器，可以附着在 cgroup 上，在超出特定限制时停止所有新建任务。现在这一核心功能暴露给了集群运维，能够有效的避免一些恶意的或者意外造成的 Fork 炸弹对集群产生不良影响。

在 kubelet 的--feature-gates=参数中加入SupportPodPidsLimit=true，就激活了这一功能。目前只允许运维通过 kubelet 的--pod-max-pids参数来给每节点定义一个简单的上限数量。可能这种硬性限制并不适用于所有场景，在一些情况下会需要超过这一限制。未来也许会让这一选项更具弹性；一个可能的扩展方式就是制定一个上限和下限，让用户在 Pod 中使用一个布尔字段来选择限制。

这一功能为工作负载提供了一种新的重要的隔离机制，他的后续发展让人非常期待。

Louis Taylor

1.10 加入了共享进程命名空间的 Alpha 支持。要试用这一特性，需要在 apiserver 以及 kubelet 中启用PodShareProcessNamespace。启用之后就可以在 Pod 中设置shareProcessNamespace：

apiVersion: v1
kind: Pod
metadata:
  name: shared-pid
spec:
  shareProcessNamespace: true
...

在 Pod 内共享 PID 命名空间有一些后果。最重要的是，在容器内的进程，对同一 Pod 内的其他所有容器是可见的，并且可以跨越容器边界向进程发送信号。这使得 Sidecar 容器更加强大（例如发送一个SIGHUP来重新载入配置）。

Josh Van Leeuwen

1.10 中多出一些 Alpha 特性，其中包含了 CRD 的子资源（注 4），分别是/status和/scale。和其他资源一样，他们提供了独立的 API 端点来修改内容。不但你的资源现在可以和HorizontalPodAutoscaler这样的系统进行交互，而且还给用户和控制器状态数据提供了更好的访问控制能力。例如控制器具备的对资源状态的变更和销毁能力就可以不分配给用户。

为 CRD 加入/status和/scale，只要加入如下代码：

subresources:
  status: {}
  scale:
    specReplicasPath: .spec.replicas
    statusReplicasPath: .status.replicas
    labelSelectorPath: .status.labelSelector

外部自定义指标

Matt Bates

第一个版本的 HPA（v1）只能基于对 CPU 使用率的监控进行。虽然有用，但是 CPU 并不总是应用伸缩的唯一标准。Kubernetes 1.6 中加入的 HPA v2，可以用自定义指标进行伸缩。我们在 Kubernetes 1.8 的博客（注 5）中介绍了关于资源指标 API、自定义指标 API、以及 HPA v2 的相关内容。

自定义指标能够描述来自受 HPA 关注的 Pod 的指标，包括资源（CPU、内存）或者对象（服务或者 Ingress）。但是这些选项对于集群之外的基础设施层面是不适用的。最近的客户接触中，就收到了根据 Google 云发布/订阅队列长度进行伸缩的需要。

1.10 中，现在有了一个 Alpha 阶段的 HPA v2 API，用于支持外部指标。例如上述的根据发布/订阅队列长度进行伸缩的需求大概可以这样实现：

kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2beta2
spec:
  scaleTargetRef:
    kind: ReplicationController
    name: Worker
  minReplicas: 2
  maxReplicas: 10
  metrics:
   - type: External
     external:
       metricName: queue_messages_ready
       metricSelector:
         matchLabels:
           queue: worker_tasks
       targetAverageValue: 30

HPA 需要一个附加的 API Server，注册为APIService，并通过查询发布订阅队列，实现自定义指标 API。

kubectl `get`和`describe`输出的自定义

James Munnelly

Kubernetes 1.10 的kubectl get和kubectl describe的输出生成过程有了一个很小很重要的变化。

过去，Cert-Manager（注 6）或者 Navigator（注 7）这样的第三方 Kubernetes 扩展总会显示一些这样的信息：

$ kubectl get certificates
NAME        AGE
prod-tls    4h

然而现在的版本中，可以通过对扩展的配置来展示更多有用的信息，例如：

$ kubectl get certificates
NAME        STATUS    EXPIRY        ISSUER
prod-tls    Valid     2018-05-03    letsencrypt-prod

$ kubectl get elasticsearchclusters
NAME       HEALTH    LEADERS    DATA    INGEST
logging    Green     3/3        4/4     2/2

这样给 API 扩展带来一种原生的风格，让用户能够快速的获取有意义的数据。

卷调度和本地存储

Richard Wall

新版本中，我们很高兴地看到本地存储升级到 Beta 阶段（注 8），并且缺省启用了卷调度（注 8）。

Kubernetes 网络策略指南

Wed, 28 Feb 2018 22:57:14 +0800

有了网络策略，你也做得到！

这里包含一系列的 Kubernetes 网络策略的相关用例以及相关的 YAML 文件。想要知道如何在 Kubernetes 中对某一应用的流量进行阻拦或者限制，请继续阅读。

尝试网络策略的最简单方法就是创建一个新的 Google Container Engine 集群。在现有集群上应用网络策略，可能会造成网络中断。在成文期间，多数云供应商尚未提供内置的网络策略支持。

如果你对网络策略一窍不通，建议首先阅读我的文章：Securing Kubernetes Cluster Networking。

开始之前

创建集群

基础

拦截到一个应用的所有流量
限制到一个应用的流量
允许所有目标为某个应用的流量

命名空间

拦截当前命名空间中，所有白名单之外的流量
拦截所有来自于其他命名空间的流量
允许来自所有命名空间的，目标为某应用的流量
允许所有来自于某命名空间的流量
允许来自某命名空间某些 Pod 的流量
限制当前命名空间内到某应用的流量

控制外部客户端流量

允许外部客户端的流量

进阶

只允许目标为指定端口的流量
用多个选择器选择允许通过的流量

控制外发流量（Egress）

拦截来自某应用的外发流量
拦截命名空间内所有白名单之外的 Egress 流量
限制来从指定应用到某些 Pod 的 egress 流量。
只允许目标是命名空间内某 Pod 的流量。
拦截外部的 egress 流量

作者

Ahmet Alp Balkan (@ahmetb).

声明: 这并非 Google 官方文档。

在 Azure 上运行 Istio 的注意事项

Fri, 02 Feb 2018 23:04:20 +0800

ACS Engine: v0.12.4
Istio: v0.5.0
Kubernetes: v1.8.7

在 Istio 注入之后，生成的 Init 容器中会有 RunAs 的 SecurityContext，而 ACS Engine 的缺省 admission 包含了SecurityContextDeny，会拒绝这一选项，造成 Istio Workload 无法运行，

解决方法很简单，只要在定义文件中修改 api server 配置：

"properties": {
  "orchestratorProfile": {
    "kubernetesConfig": {
        "apiServerConfig": {
            "--request-timeout": "30s",
            "--admission-control": "NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota,DenyEscalatingExec,AlwaysPullImages"
        }

Node 重伤之后

Wed, 20 Dec 2017 01:58:49 +0800

很多人都知道 Kubernetes 能自动维护失效 Pod、防止服务中断、剔除故障节点 BLABLA 的一堆高大上功能。但节点故障之后，会对运行在故障节点上的容器、以及依赖容器的服务造成什么影响，是应该了解的，这样才能有针对性的进行监控设置、部署安排、故障处理等工作。

水平有限，这里不谈原理，只说说症状和一些相关的调整。

测试环境

Kubernetes 1.7.10，三节点，其中 Master 节点被 Taint.
- 10.211.55.11(Master)
- 10.211.55.12
- 10.211.55.13
CentOS 7
Docker 1.12.3

实验设计

Docker、Kubelet 以及 Kube-Proxy 是 Node 的标准组件，我们准备一个 2 Replicas 的 Deployment 作为测试目标，使用 NodePort 方式暴露 HTTP 端口。具体代码见附录。

使用 systemctl 关停目标服务，使用 watch -n5 kubectl get pods,nodes,deploy 以及 watch -n5 kubectl "describe svc httpbin | grep -i endp" 命令持续检查相关工作负载的情况。同时可以使用 curl 命令检查服务是否存活。

Kube-Proxy

选择登录一个节点，例如 10.211.55.12，使用 kubectl stop kube-proxy 关闭之后可以看到，各个 kubectl get 命令返回结果都正常，似乎未受影响；然而使用 curl 进行逐个节点的 NodePort 进行验证的时候，会发现停掉 Proxy 的地址是无法提供服务的。

监控

除了监控进程/服务之外，Kube-Proxy 还提供了几个可以用于监控的参数

--healthz-bind-address：健康检测地址和端口，缺省为 0.0.0.0:10256
--healthz-port：健康检测端口，缺省 10256，设置为 0 则关闭。

curl http://127.0.0.1:10256/healthz | jq 会看到返回的健康数据：

{
  "lastUpdated": "2017-12-19 16:05:27.333531431 +0800 CST",
  "currentTime": "2017-12-19 16:05:33.73732624 +0800 CST"
}

— --metrics-bind-address 用于提供监控指标的地址和端口，缺省为 127.0.0.1:10249，返回内容可用于 Prometheus。例如：curl -s http://127.0.0.1:10249/metrics | more会看到：

......
# HELP http_request_size_bytes The HTTP request sizes in bytes.
# TYPE http_request_size_bytes summary
http_request_size_bytes{handler="prometheus",quantile="0.5"} 64
http_request_size_bytes{handler="prometheus",quantile="0.9"} 64
http_request_size_bytes{handler="prometheus",quantile="0.99"} 64
http_request_size_bytes_sum{handler="prometheus"} 192
http_request_size_bytes_count{handler="prometheus"} 3
......

Kubelet

Kubelet 情况比 kube-proxy 复杂一些。

首先使用kubectl get po -o wide，确认 Pod 所在节点。
使用systemctl stop kubelet停止 kubelet 服务。
观察

首先我们会看到，经过约半分钟以后，该节点变为NotReady状态。Deploy 对象的 Available 字段数字会减 1，服务的Endpoints列表减少一个。；但是 Pod 状态保持在Running，

五分钟左右，Pod 进入Unknown状态，开始尝试启动新 Pod。

存活检测和就绪检测

测试中我们使用的 yaml 中并没有设置这两个内容，事实上，这两个检测是由 kubelet 执行的，对上述行为并无影响。

参数调整

真正影响上面的行为的是kube-controller-manager的两个参数：

--pod-eviction-timeout：缺省为 5m，五分钟，在 Pod 驱逐行为的超时时间。
--node-monitor-grace-period：缺省为 40s，也就是 40 秒，无响应 Node 在标记为 NotReady 之前的等候时间。

监控

--healthz-bind-address：健康监测地址，缺省为127.0.0.1。
--healthz-port：健康检测端口，缺省为 10248。

curl 访问该地址，会得到响应：ok。

另外如果使用kube-metrics exporter进行集群监控，可以关注 RC、Deploy 等对象的可用实例数量。

Docker

Docker 的情况其实跟 Kubelet 类似，但是结果会更严重：在 Endpoint 被排除之前，路由到故障节点的流量会发生故障。

测试之外

多 Pod 不仅对性能有好处，在极端情况下能降低故障节点对服务整体效果的影响。
建议采用节点互斥的方式进行部署。
对关键组件的监控，应该建立从进程到指标的多级监控，减小服务故障的时间窗口。
Pod 的存活和健康监测，对于容器内的应用是有效的，应该推荐。

附录

workload.yaml


apiVersion: v1
kind: Service
metadata:
  name: httpbin
  labels:
    app: httpbin
spec:
  ports:
  - name: http
    port: 80
    nodePort: 30080
  selector:
    app: httpbin
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: httpbin-v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      containers:
      - image: httpd
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80

Operator：固化到软件中的运维技能

Wed, 13 Dec 2017 18:24:52 +0800

原文：Introducing Operators: Putting Operational Knowledge into Software

SRE 是用开发软件的方式来进行应用运维的人。他们是工程师、开发者，通晓如何进行软件开发，尤其是特定应用域的开发。他们做出的东西，就是包含这一应用的运维领域技能的软件。

我们的团队正在 Kubernetes 社区进行一个概念的设计和实现，这一概念就是：在 Kubernetes 基础之上，可靠的创建、配置和管理复杂应用的方法。

我们把这种软件称为 Operator。一个 Operator 指的是一个面向特定应用的控制器，这一控制器对 Kubernetes API 进行了扩展，使用 Kubernetes 用户的行为方式，创建、配置和管理复杂的有状态应用的实例。他构建在基础的 Kubernetes 资源和控制器概念的基础上，但是包含了具体应用领域的运维知识，实现了日常任务的自动化。

无状态容易，有状态难

在 Kubernetes 的支持下，管理和伸缩 Web 应用、移动应用后端以及 API 服务都变得比较简单了。其原因是这些应用一般都是无状态的，所以 Deployment 这样的基础 Kubernetes API 对象就可以在无需附加操作的情况下，对应用进行伸缩和故障恢复了。

而对于数据库、缓存或者监控系统等有状态应用的管理，就是个挑战了。这些系统需要应用领域的知识，来正确的进行伸缩和升级，当数据丢失或不可用的时候，要进行有效的重新配置。我们希望这些应用相关的运维技能可以编码到软件之中，从而借助 Kubernetes 的能力，正确的运行和管理复杂应用。

Operator 这种软件，使用 TPR(第三方资源，现在已经升级为 CRD) 机制对 Kubernetes API 进行扩展，将特定应用的知识融入其中，让用户可以创建、配置和管理应用。和 Kubernetes 的内置资源一样，Operator 操作的不是一个单实例应用，而是集群范围内的多实例。

为了展示 Operator 的概念，我们有两个实际的例子开放了源代码：

etcd Operator，创建、配置和管理 etcd 集群。etcd 是一个可靠的分布式键值库，由 CoreOS 出品，用于分布式系统中的关键数据存储，Kubernetes 就是用户之一。
Prometheus Operator，创建配置和管理 Prometheus 监控实例。Prometheus 是一个强大的监控、指标和告警工具，也是 CoreOS 团队支持的 CNCF 项目。

Operator 如何构建？

Operator 基于两个 Kubernetes 的核心概念：资源和控制器。例如内置的 ReplicaSet 资源让用户能够设置指定数量的 Pod 来运行，Kubernetes 内置的控制器会通过创建或移除 Pod 的方式，来确保 ReplicaSet 资源的状态合乎期望。Kubernetes 中有很多基础的控制器和资源用这种方式进行工作，包括 Service，Deployment 以及 DaemonSet。

用户将一个 Pod 的 RS 扩展到三个

一段时间之后，Kubernetes 的控制器按照用户意愿创建新的 Pod。

Operator 在基础的 Kubernetes 资源和控制器之上，加入了相关的知识和配置，让 Operator 能够执行特定软件的常用任务。例如当手动对 etcd 集群进行伸缩的时候，用户必须执行几个步骤：为新的 etcd 示例创建 DNS 名称，加载新的 etcd 示例，使用 etcd 管理工具(etcdctl member add)来告知现有集群加入新成员。etcd Operator 的用户就只需要简单的把 etcd 的集群规模字段加一而已。

> 用户使用 kubectl 触发了一次备份

复杂的管理任务还有很多，包括应用升级、配置备份、原生 Kubernetes API 的服务发现，应用的 TLS 认证配置以及灾难恢复等。

如何创建一个 Operator

根据前面的陈述，我们知道 Operator 是跟应用紧密相关的，所以其中最重要的工作就是把应用自身的运维方法编码成为资源和控制逻辑。在创建 Operator 的过程中，我们发现了一些适用于各种应用的通用模式：

Operator 应该以单一 Deployment 的形式进行安装。kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml，不应进行其他额外操作。
Operator 在安装到 Kubernetes 中时，应该创建新的 TPR 类型。用户会使用这一类型来创建新的应用实例。
Operator 应该尽量利用 Kubernetes 内置的 Service 以及 ReplicaSet 这些经过良好的测试并易于理解的原生对象。
Operator 应该向后兼容，并且保持对过去版本资源的理解能力。
在 Operator 出现故障或者被移除的时候，相关应用应该持续运行不受影响。
用户应该从 Operator 中获得声明特定版本以及编排应用版本升级的能力。无法更新的软件应该是一种运维缺陷，也可能造成安全问题，Operator 应该给用户更多信心和辅助，完成升级操作。
Operator 应该用“Chaos Monkey”这样的测试套件来模拟 Pod、配置或者网络故障的情况下的运行情况。

Operators 的未来

CoreOS 所发布的 etcd 和 Prometheus 的 Operator，展示了 Kubernetes 平台的能力。过去一年中，我们和 Kubernetes 社区紧密合作，聚焦于 Kubernetes 的稳定性、安全性、以及管理和安装的方便性方面的工作。

现在 Kubernetes 的基础已经奠定，我们新的工作重点转移到了上层建筑：用软件来对 Kubernetes 进行扩展，为其赋予新的能力。我们想象，未来用户在各自的 Kubernetes 集群上安装 Postgress Operator、Cassandra Operator 或者 Redis Operator，像对普通 Web 应用一样对这些应用进行伸缩。

要了解更多内容，可以浏览 Github 仓库，在我们的社区中讨论。

FAQ

Q：和 StatefulSet（从前的 PetSet）有什么区别？

A：有的应用需要集群提供“有状态资源”，例如静态 IP 或者存储，StatefulSet 让 Kubernetes 有了支持这种应用的能力。然而有的应用需要更多的有状态部署模型的支持，例如故障的告警和应对、备份、重新配置等。所以 Operator 应用可以根据部署特性需求来选择 StatefulSets 或者 ReplicaSets 以及 Deployments。

Q：和 Chef、Puppet 这样的配置管理系统相比呢？

A：容器和 Kubernetes 的给了 Operator 生存基础。这两个技术让新软件的部署、分布式配置的协调、检查多主机系统状态等工作变得轻而易举。Operator 把这种种优势聚合在一起，为应用的用户提供方便；他提供的不仅仅是配置，还包括上线、状态等全部内容。

Q：和 Helm 的区别？

A：Helm 是一个把多个 Kubernetes 资源包装为一个单独软件包的工具。把多个应用集成在一起的概念，可以和 Operator 的活动管理进行互补。例如 Traefik 是一个负载均衡，他可以使用 ETCD 作为后端数据库。可以创建一个 Helm Chart ，同时部署 Traefik 的 Deployment 对象以及 etcd 集群。也可以使用 etcd Operator 进行 etcd 集群的部署和管理。

Q：这对于 Kubernetes 的新用户来说意味着什么？

A：这对新用户没什么影响，而且可以更简便的部署 etcd、Prometheus 这样的复杂应用，并且以后会有更多软件支持。我们推荐的试水方式是 minikube 以及 kubectl run，然后可以用 kubectl run启动 Prometheus Operator 来监控部署的应用。

Q：etcd 和 Prometheus Operator 的代码开放了么？

A：是的，分别位于 https://github.com/coreos/etcd-operator 以及 https://github.com/coreos/prometheus-operator

Q：是否有计划开发其他的 Operator？

A：未来会的。我们还希望社区能够更多参与，让我们也知道用户需要什么样的 Operator。

Q：Operator 能够让集群更安全么？

A：无法更新的软件是一个常见的问题原因和安全隐患，Operator 能让用户更自信的进行升级，打破这一限制。

Q：Operator 能够帮助进行灾难恢复么？

A：Operator 能够轻松地对应用进行阶段性备份以及恢复。我们还希望开发一个功能，让用户可以从备份开始安装新的实例。

SoundCloud 如何使用 HAProxy 和 Kubernetes 处理用户流量

Tue, 12 Dec 2017 09:03:37 +0800

原文：How SoundCloud uses HAProxy with Kubernetes for user-facing traffic

两年前 SoundCloud 开始了将我们的自研部署平台 Bazooka 迁移到 Kubernetes 的尝试。Kubernetes 将容器化应用的部署、伸缩和管理都进行了自动化。

问题

用户流量的路由，是这类动态平台需要面对的一个重大挑战：把来自用户的 API 和网站访问路由到运行在 Kubernetes 的 Pod 上。

多数 SoundCloud 运行在一个物理机环境下，所以我们无法享受 Kubernetes Loadblancer 的福利。在基础设施的边际，有一组 HAProxy 服务器使用简单的规则，承担着 SSL 端点的角色，把流量转发给各种内部服务。这些服务器的配置在运行之前是分别进行生成和测试的。有很多内置的保护措施的存在，这一过程会相当耗时，无法跟上 Kubernetes 集群中 Pod 的漂移速度。这样就导致我们的静态 SSL 端点和 Kubernetes 中的动态变化之间的矛盾。

过程

起初，我们把端点层配置为转发 HTTP 请求到 HAProxy 为基础的 Ingress Controller 之中，但是这一方案对我们不太合适，Ingress 控制器设计预期是低流量的内部服务，并不可靠。我们的用户生成了很多流量，每一个问题都会导致部分用户无法使用 SoundCloud。在 Kubernetes Ingress 和端点之间，我们有了两层 L7 要相互配对，而且经常无法配对。这对我们的开发人员造成很大困扰，增加了不少工作。

我们还知道 Ingress Controller 无法处理我们部分客户端使用的长连接。

当 SoundCloud 工程师构建应用时，我们使用一个自定义命令行界面来生成 Namespace、Service、Deployment 和可选的 Ingress Kubernetes 对象。我们添加了一个参数，来把服务改成 NodePort 类型，

Kubernetes 在集群中找一个没被占用的端口分配给服务，并在集群每个节点上开放这个端口。到任意一个节点的该端口的访问都会被转发给这一服务的某一个实例。(我们生成的 Kubernetes 对象在 Deployment 和 Service 之间有着一对一的关系)。为简便起见，这里就不深入谈论 ReplicaSet、Pod、以及 Endpoint 等 Kubernetes 对象了。

对服务的这种改变（Ingress 到 NodePort）是不可逆的。Kubernetes 不允许移除服务定义中的 NodePort 字段。我们还在寻求解决办法 —— 这种情况虽然可以通过删除再重建服务的方式来解决，但是这一方式会导致服务中断。

应用开发者为应用声明集群、命名空间、服务和端口名，生成一个特定的主机名和路径。系统根据这一配置，将来自 SSL 端点、CDN 分发以及 DNS 等的流量转发给应用。

实现

当端点配置声成以后，脚本向 Kubernetes 集群查询每个服务的 Node Port，以及 Kubernetes 的节点列表。起初我们把所有节点都加入到端点的配置之中，不过后来证明这是一个问题。

每个端点会独立的检查每个节点的每个端口的健康状况。几十个端点，几百个 Kubernetes 节点，导致每秒钟上万次的健康检查。这种检查是通过节点进行的，跟服务规模无关，所以即使是很低流量的服务，也需要大量的资源来应对这些健康检查。

我们因此减少了配置给每个服务的节点数量，不过我们也不希望这个节点数量太少，免得造成性能瓶颈。一个简单的方案就是随机从列表中选择一些节点，但这样的话，这一列表的每次生成，都会发生很大的变化，会跟真正的部署调整造成混淆。所以我们决定使用服务名称和节点地址来进行哈希，为每个服务选择一组固定数量的服务器，但是这个选择在节点不变的情况下也会保持不变。

我们选择足够多的节点，这样就不必担心一两台节点发生当机，或节点被多个高流量服务重叠使用。

要替换一个节点，只需要重启 Pipeline，生成并部署新的端点配置。这会花费几个小时，好在是全自动的。因为每个服务都通过有限数量的节点进行路由，因此不能一次性的从同一个服务中移除太多节点。这意味着，我们只能每天从 Kubernetes 集群中替换有限数量的节点，不过目前为止这还没有造成什么问题。

Node Agent

在短期维护中，例如内核更新需要重启节点，我们需要一种将节点优雅排空的能力。我们为 HAProxy 的 agent-check 协议开发了一个 Agent，监听每个节点的固定端口。为了简单起见，我们希望能够同时移除流量和 Pod，当节点从 Kubernetes 进行隔离之后，新的 Pod 不会被调度在这一节点上，Agent 更新 HAProxy 状态，将流量从这一节点上移除。

有时我们还要把流量在一个服务的不同 Deployment 之间进行切换，还包括同一集群和不同集群的情况。为了支持这种切换，我们对这个 Agent 进行了扩展。我们在 Kubernetes 的 Service 对象上增加了一些注解(annotations)，以此指示监听新的端口，扩展的 Agent 不仅检查节点的维护状态，还会检查这一服务的优先级。端点配置过程会获取这一信息并据此配置 Agent 的检查行为。应用开发者可以添加多个 Kubernetes 后端到任意的公开主机和路径。每个后端我们都像之前一样利用哈希选择一组节点提供服务。修改服务注解，就能在几秒钟改变各个后端服务的权重。

未来

这种基于 NodePort 的路由方式工作的不错，但是也有一些隐忧。一个应用实例之间的负载分配并不均等，我们的应对方式是为应用分配稍多的资源。这一问题上，多分配资源的成本远低于由工程师开发新的负载均衡机制所需要的花费。

在物理机组成的数据中心运维 Kubernetes 是一个挑战。在公有云服务中，都会提供标准方案；而每个数据中心都会有些不同——尤其是并非从头开始，而是将 Kubernetes 向现有基础设施进行融合的情况下。本文中，我们主要阐述的就是我们应对部分问题的部分解决方法.

下一步？我们目前考虑的是在不同位置的多个 Kubernetes 集群，为不同用户选择不同集群来达到优化体验的目的。

Kube-Node：让 Kubernetes 自行管理节点

Sun, 26 Nov 2017 18:37:58 +0800

原文：Kube-Node: Let Your Kubernetes Cluster Auto-Manage Its Nodes

本文是一个系列中的一篇，来自于 CNCF 成员，为奥斯汀 12.6-12.8 的 KubeCon/CloudNativeCon 而做。

Michelle Noorali 在今年三月份的欧洲 KubeCon 上的 KeyNote中说到：Kubernetes 对开发人员来说还是太难了。原则上来说，开发人员对 Kubernetes 和容器技术是非常热爱的，这一系列的技术让开发人员编写的应用能够到处运行，却无需担心基础设施的差异。但事实上，这一技术体系还是有很多依赖的，这些依赖很大程度上磨灭了用户的热情。

对开发人员来说，Kubernetes 有个主要的障碍就是他无法对其服务器进行自动管理和伸缩，因此一个工作节点的部署或移除都少不了运维工程师的参与。当然目前有很多节点部署方案，例如 Terraform、Chef 以及 Puppet，这些技术让运维人员的日子好过了点。然而上述技术都需要一些特定领域的知识；目前还不存在一种无须运维接入的通用的跨平台方法。

Kubernetes 节点的生命周期，同其他的 Kubernetes 资源的生命周期是不一致的，这是 Kubernetes 节点部署和管理的一个主要问题。当下的节点管理生命周期里，节点是在一台服务器加入集群之后创建的。然而一般的 Kubernetes 资源并不是这样的：首先创建资源，然后才加入服务器。

这种情况是不合理的。为了解决这一问题，来让节点的管理工作纳入正轨，我们决定启动 kube-node 这一社区项目。我们的目标是为 Kubernetes 开发一个类似持久卷系统的原生节点整合方案。

持久卷系统从各种云中抽象出了存储的供给和使用的功能。这种抽象把存储卷的生命期从环境中独立出来，令其可以被动态的分配和管理。

如何设置 Kube-Node

类似持久卷的设置，Kube-Node 是一个高级别的抽象系统：

管理员进行配置的定义
开发人员可以使用简单的kubectl create node -f node1.yaml来对集群进行扩容
Kubernetes 控制节点的生命周期

为了达成这一目标，我们引入了两个新的 API 资源：NodeClass 和 NodeSet，这些资源由 NodeController 和 NodeSetController 来进行管理。

NodeSet 保证任意时间内都有指定数量的节点正在运行。跟 ReplicaSet 类似，NodeSet 要保障一个节点或者一系列的同质化节点的运行和可用状态。 NodeSet 来自于 NodeClass，其细节定义在 Node 模板中。
NodeClass 让管理员有了为新节点设置配置的可能性。NodeClass 包括了云供应商和操作系统特定的细节，例如认证信息、机器类型等数据。另外管理员还可以定义服务质量水平和策略。Kubernetes 不能干涉 NodeClass 的定义。
NodeSetController 会关注 NodeSet，负责节点的创建和删除工作。在目前的实现中，他管理节点资源的创建，并跟 GKE 的节点池进行同步。
NodeController 关注节点对象并在云端进行服务器的供应。服务器加入集群之后，kubelet 会更新节点资源；类似的，在节点对象被删除的时候，NodeController 会从云端删除这一服务器。

概述和路线

kube-node 是一个社区项目，用于提供通用的 Kubernetes 节点管理手段。目标是为开发者提供一个无需运维介入的、基础设施无关的简单方式，来对集群进行伸缩。其中包含了基于 CustomResourceDefinition 的类型、client-go 为基础的客户端以及 NodeController 和 NodeSetController。

首先会实现 NodeSetController 和 NodeController 的联动，接下来会和 GKE 节点池进行集成。上面的两个步骤会针对各种不同用例来进行概念的验证。NodeController 的第一步会复用 docker-machine 的一部分代码，称为 kube-machine，用于和多个不同的云供应商中加载服务器。

下一步，我们计划把 NodeSet 和 Kubernetes 的自动伸缩功能进行集成，让 NodeController 根据集群负载，能够自动对 NodeSet 的实例数进行设置。这一集成能够让 Kubernetes 在多种不同的平台上实现集群的自动伸缩。另外我们会实现更多的 NodeController，包括 Terraform、Python 或者 AWS。

搭建高可用 Kubernetes 集群

Wed, 22 Nov 2017 11:19:59 +0800

领导说，只要机器够多，故障是个很平常的事情。

Kubernetes 能很好的管理容器和节点，所以正常的节点故障或者个别应用的故障是不会影响集群运作的。一旦 apiserver 或者所依赖的 etcd 出现问题，情况就不再乐观了。幸好这两个核心服务都提供了高可用相关能力。同时 controller-manager 以及 scheduler 也都具备通过选举产生 leadership 的机制，这就提供了高可用的基础。下面讲讲 Master 组件的高可用部署方式。

部署目标

每个 apiserver 都使用不同的负载均衡端点访问整个 etcd 集群。
每个 controller-manager 和 scheduler 使用各自的 apiserver 进行工作。
客户端通过负载均衡机访问 apiserver。

前提条件

这里我们假设，ETCD 集群已经成功建立，包含三个节点，采用 https 访问进行访问；Master 节点只有一个。也同样的使用 https 进行访问，集群能够正常工作。

另外准备若干台服务器安装 haproxy 充当负载均衡。

ETCD

众所周知的是，apiserver 的 --etcd-servers 参数是可以输入一整个 etcd 集群的，然而在使用中我们发现，一些特定版本的 apiserver 在第一台 etcd 服务所在节点的特殊故障情况下，虽然 etcd 本身已经能够发现集群健康状态异常，却依然会陷入假死状态，，具体症状是多数 kubectl 的 Workload 相关操作都能完成，然而却不会真正生效。因此我们需要更可靠的对 etcd 集群的访问方式，降低 apiserver 缺陷造成的集群不可用的风险。

因为采用了 https 方式进行访问，所以这里我们 haproxy 的配置需要使用 tcp 方式。

不用 https 端点（也就是对外 https 对内 http 的部署）的方式，纯属个人习惯。在启用 haproxy 之前，注意要把服务端证书的 IP 进行扩展，令其支持新增的负载均衡地址。

简单粗暴上代码：

...
frontend  in-etcd
    bind *:12379
    mode tcp
    default_backend etcd-cluster

backend etcd-cluster
    mode tcp
    balance     roundrobin
    option httpchk GET /health
    http-check expect string true
    server app1 10.211.55.9:2379 check check-ssl verify none
    server app2 10.211.55.10:2379 check check-ssl verify none
    server app3 10.211.55.11:2379 check check-ssl verify none
...

使用负载均衡节点的 12379 端口对外提供服务。
前后端均使用 tcp 方式。
利用 etcd 节点的 /health 端点进行健康检查，健康标准是返回字符串 true。
不校验 etcd 服务端证书。

启用 haproxy 之后，访问 haproxy 的状态页面，可以看到 etcd 集群的代理已经建立。

任意停止其中一台，会看到在检测窗口过后，对应的服务器状态切换为 DOWN。

用同样的方式部署其他两台 haproxy 服务器。

Master 组件

和 etcd 情况一样，apiserver 的服务证书，也需要更新，加入新的 Master 节点以及前端负载均衡的地址。

首先更改 apiserver 的 etcd 参数，从原来的三台 etcd 变更为单一的 haproxy 地址，例如 https://haproxy1:12379。修改之后，重新启动服务，可以看到服务正常启动成功。

接下来，我们将 apiserver、controller-manager 以及 scheduler 的可执行文件、服务定义、相关证书以及配置文件复制到新加入的服务器中，并启用服务。

每个 apiserver 需要配置各自的 etcd haproxy。
每个 scheduler 和 controller-manager 都访问各自的 apiserver 服务，并使用参数--leader-elect启用选举（这一参数是缺省启用的）。

和 etcd 类似，为 apiserver 配置 haproxy：

frontend in-apiserver
    bind *:16443
    mode tcp
    default_backend apiserver-cluster

backend apiserver-cluster
    mode tcp
    balance     roundrobin
    option httpchk GET /healthz
    http-check expect string ok
    server app1 10.211.55.9:6443 check check-ssl verify none
    server app2 10.211.55.10:6443 check check-ssl verify none
    server app3 10.211.55.11:6443 check check-ssl verify none

这里我们访问 apiserver 的 /healthz 端点，如果得到返回内容为 ok，则判断集群为健康。

配置后启动 haproxy，查看状态页面，可以看到 apiserver 集群也已经就绪。

最后可以修改 kubectl 以及各个 Node 的 kubelet/kube-proxy apiserver 参数到负载均衡地址。

测试

停止任意一台 Master 的服务，包括 apiserver/controller-manager/scheduler，会看到 controller-manager 或 scheduler 的选举过程。如果停掉的是 apiserver，则可以在 haproxy 状态页上看到集群可用性的变化。

在 Kubernetes 上使用 Jmeter 运行压力测试

Thu, 16 Nov 2017 23:31:55 +0800

Kubernetes 的资源和任务调度能力，能给自动化测试提供相当大力的支持，这里以 Jmeter 为例，讲讲如何在 Kubernetes 中使用 Jmeter 进行简单的性能测试。

开始之前

录制任务：本文所用镜像为 Jmeter 3.x 版本，建议提前录制一个简单的测试任务进行下面的操作。
支持 Jobs 的 Kubernetes 集群，以及缺省的 StorageClass 支持，能够实现 PVC 的动态供应。
互联网连接。

试验内容

搭建一个 Web DAV 服务，用于提供给 Jmeter 输入输出场所，也便于日后 CI/CD 工具的案例输入或结果输出。
运行单实例的 Jmeter 测试任务。
运行集群形式的 Jmeter 测试任务。

预备存储

这一步骤并非强制，完全可以通过 scp 或者 mount 等其他方式来实现

这里我们做一个 Web DAV 服务，挂载一个 PVC，在其中分为 input 和 output 两个目录，实际使用过程中，可以进一步按照任务或者 Job 对目录进行更详尽的规划。

首先创建名为jmeter-task的存储卷：

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: jmeter-task
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

存储卷创建之后，可以使用 cadaver 或者 WinSCP 等工具去建立目录。

接下来上传 *.jmx 文件，到 input 目录之中，这里我录制的一个持续访问京东首页的任务，命名为 jd.jmx。

单实例测试

单实例测试很容易，使用 Kubernetes 的 Job 方式即可：

apiVersion: batch/v1
kind: Job
metadata:
  name: jmeter
spec:
  template:
    metadata:
      name: jmeter
    spec:
      restartPolicy: Never
      containers:
      - name: jmeter
        image: dustise/jmeter-server
        command:
          - "/jmeter/bin/jmeter"
          - "-n"
          - "-t"
          - "/jmeter/input/jd.jmx"
          - "-l"
          - "/jmeter/output/log"
          - "-j"
          - "/jmeter/output/joker"
        volumeMounts:
        - name: data
          mountPath: /jmeter/input
          subPath: input
        - name: data
          mountPath: /jmeter/output
          subPath: output
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: jmeter-task

上面的定义中：

任务 Pod 加载了存储卷 jmeter-task。使用 subPath 指令，分别挂载了输入和输出目录。
使用 -n -t 的方式运行测试任务，并把输出文件定位到 output 目录中。

接下来就可以使用 kubectl create -f jobs1.yaml 来运行这一任务。

任务启动之后，可以：

使用 kubectl get jobs 来查看任务运行状况。
kubectl get pods --show-all 查看任务 Pod。
kubectl logs -f [pod name 查看任务输出。

最后任务会变成完成状态，就可以在 Web DAV 中查看任务报告了。

集群测试

Jmeter 可以使用控制台+负载机的形式，使用多个节点进行压力测试，这里需要解决的一个最重要问题就是，在指派任务给负载机时，Jmeter 需要使用 -R host:port 的参数，来指定任务要调用的负载机。这一通信是无法通过 Kubernetes 方式的 Service 来完成的。必须建立 Pod 之间的通信，而 Pod 的主机名地址是很飘逸的，同时，我们还是希望负载节点的数量能够实现较为自由的伸缩，因此解决方法就只有 StatefulSet 了。

这个 YAML 很长，所以放在最后了，说说其中的要点：

注解中的 security.alpha.kubernetes.io/sysctls：实际运行中，jmeter 负载机是需要对内核参数进行一点调整的，Pod 中可以用这一方式进行调整，https://kubernetes.io/docs/concepts/cluster-administration/sysctl-cluster/ 中有更详细的关于这方面的内容讲解。
spec.affinity：这里设置 Jmeter Pod 尽量分布在不同节点上。
RMI_HOST环境变量：使用每个 Pod 的 IP 为这一变量赋值。
Service：利用这个 Headless 服务，为每个 Pod 提供主机名支持。

启动这个 Statefulset 之后，会看到规律创建的 Pod 名称：

jnode-0                   1/1       Running   0          1h
jnode-1                   1/1       Running   0          1h

对应的主机名称就应该是 jnode-0.jfarm，jnode-1.jfarm。所以上面的 job.yaml 可以新增 -R jnode-0.jfarm:1099,jnode-1.jfarm:1099 即可。

使用 kubectl create 启动任务之后，查看该任务 Pod 的日志，会出现大致这样的内容：

Creating summariser <summary>
Created the tree successfully using /jmeter/input/jd.jmx
Configuring remote engine: jnode-0.jfarm:1099
Configuring remote engine: jnode-1.jfarm:1099
Starting remote engines
Starting the test @ Thu Nov 16 07:24:14 GMT 2017 (1510817054558)
Remote engines have been started
Waiting for possible Shutdown/StopTestNow/Heapdump message on port 4445
summary +    302 in 00:01:16 =    4.0/s Avg:  2967 Min:  2627 Max:  5457 Err:     0 (0.00%) Active: 0 Started: 20 Finished: 20
summary +     98 in 00:00:00 = 3062.5/s Avg:  3270 Min:  2635 Max:  7192 Err:     0 (0.00%) Active: 0 Started: 20 Finished: 20
summary =    400 in 00:01:16 =    5.3/s Avg:  3041 Min:  2627 Max:  7192 Err:     0 (0.00%)
Tidying up remote @ Thu Nov 16 07:25:31 GMT 2017 (1510817131966)
... end of run

可以看到，成功配置远程负载服务器之后，测试开始，最后成功完成。

Statefulset 源码

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: jnode
  labels:
    app: jmeter
    component: node
spec:
  serviceName: jfarm
  replicas: 2
  selector:
    matchLabels:
      app: jmeter
      component: node
  template:
    metadata:
      labels:
        app: jmeter
        component: node
      annotations:
        security.alpha.kubernetes.io/sysctls: net.ipv4.ip_local_port_range=10000 65000,net.ipv4.tcp_syncookies=1
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              topologyKey: kubernetes.io/hostname
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - jmeter
                - key: component
                  operator: In
                  values:
                  - node
      restartPolicy: Always
      containers:
      - name: jmeter
        image: dustise/jmeter-server
        ports:
        - name: server
          containerPort: 1099
        - name: rmi
          containerPort: 20000
        env:
        - name: RMI_HOST
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
---
apiVersion: v1
kind: Service
metadata:
  name: jfarm
  labels:
    app: jmeter
spec:
  clusterIP: None
  ports:
  - port: 1099
    name: server
  selector:
    app: jmeter
    component: node

CI/CD 工具链的分分合合

Fri, 03 Nov 2017 04:49:29 +0800

作案动机

一种对 ci/cd 工具的轻量化和解耦的尝试？

Jenkins 的传统集群方式，是使用不同环境的服务器构成不同能力的 Jenkins 节点，由主节点根据任务环节的需要，调度不同能力的子节点来完成构建或部署任务。

进入容器云时代，情况发生了变化，我们可以使用不同能力的 Jenkins 镜像，使用 Kubernetes 插件来完成这种任务的拆分和调度，为此，我构建了一个包含所有我们平时用到的工具的 Jenkins 镜像，简化了节点的扩展和选择过程。

然而随着学习和应用的深入，我意识到这种做法有几个问题：

DevOps 中隐含着发挥个人能力的愿景，工具链的所谓大而全，只不过是在画一个比较大的圈，使用这样的一套 Jenkins，还是要被其中所包含的仅有的工具中进行选择，对身陷其中的技术人员绝不能说是友好，也绝不是鼓励各展所长的态度。
现有的功能测试、接口测试、压力测试等工具，越来越专业化，往往会有各自的工作集群调度甚至是托管方案，例如 selenium grid、JMeter 集群等。
同样的测试工作，可能有多种工具都可以完成，例如一个 Restful 的接口测试，不管是 JMeter 还是Postman，或者 SoapUI 以及五花八门的自有工具，都可以完成这样的工作。
各种 DevOps 以及微服务管控和治理平台会有各自的工具链构成以及扩展方案。
让各种工具自成镜像，无疑对镜像尺寸和更新速度都会有更好的支持。

这样就让我产生一个新的思路：能不能让 Jenkins 回归到一个原始状态，只负责问题的定义、任务的分发和结果的归集呢？于是就有了这样的一点尝试。

这一尝试的思路是，Jenkins 镜像/容器只使用插件和一些 Shell 脚本，同外部的调度能力（例如 Docker 的容器或者 Kubernetes 的任务等）进行交互，利用网络和共享存储，来实现任务的分发和协调以及最后的结果汇聚。

下面以 JMeter 为例，进行一个简单的压力测试，测试环境为了节省起见，使用的是 Docker 加本地目录共享的方式，这种方式也可以很方便的扩展为 Kubernetes 的 Job + PV/PVC 方式。

镜像

Jenkins: dustise/jenkins
JMeter: hauptmedia/jmeter

注意此处随意的选择了一个 2.x 版本的 JMeter。

Jenkins 插件

docker_build_step：用于执行 Docker 指令，类似功能的 Docker Common 插件，其参数不支持环境变量，因此淘汰。
Performance Plugin：一个用于搜集和展示多种测试结果报告的插件。

存储

这里我们需要为 Jenkins 和各种工具（这里是 JMeter）提供一个可以共享访问的文件交换区域：

单机 Docker 下，可以是共享的主机目录。
Kubernetes 环境可以使用共享的分布式存储卷。

例如我们创建名为/var/cicd/exchange/jmeter的目录，进行文件交换。

输入

使用 JMeter GUI 录制 jmx 文件，为任务生成汇总日志（保存到/root/summary.log）。将 jmx 上传到上面所说的目录之中，这样就保证了 Docker 和 Jenkins 都能通过 -v 来进行加载。

这里我们启动 Jenkins 的时候，使用 -v /var/cicd/exchange/jmeter:/exchange/jmeter 参数让 Jenkins 加载这一目录。

Jenkins 任务

准备工作

首先的环节是，为后面要开工的 JMeter 准备工作环境。

# 创建当前 Build 目录
mkdir -p /exchange/jmeter/$BUID_TAG
# 复制 jmx 到当前 Build 目录
cp /exchange/jmeter/jd.jmx /exchange/jmeter/$BUID_TAG

设置容器

准备好文件之后，我们需要添加下一个环节就是设置一个容器：

这里添加的环节是docker_build_step的Execute Docker Command环节。

Image name: hauptmedia/jmeter
Command：bin/jmeter -n -t /root/jd2.jmx -l /root/result.log -j /root/process.log
Bind Mounts：/var/cicd/kube/$BUILD_TAG /root

注意绑定卷这里就使用了 $BUILD_TAG 变量

这样就完成了 Jenkins 和 JMeter 的文件共享：

Jenkins 的 /exchange/jmeter/$BUILD_TAG，对应的是新创建容器的/root目录。

启动容器

使用Execute Docker Command的start container(s)环节，Container ID(s)填写变量 $DOCKER_CONTAINER_IDS，代表启动我们刚才创建的容器。

等待任务

如果我们需要使用 Jenkins 进行结果的汇聚，那么这里就需要进行阻塞——等到 JMeter 执行完毕后，才能进行下面的搜集结果、清理现场等操作。

RESULT="/exchange/jmeter/$BUILD_TAG/summary.log"
while [ ! -f $RESULT ]
do
  sleep 30
done


while [[ `lsof | grep summary.log` ]]
do
    sleep 10
done

上面的脚本利用 lsof 来检测 summary.log 的占用情况，一旦该文件关闭，说明压力测试已经结束。

清理容器

使用 Execute Docker Command 的 remove container(s) 环节，Container ID(s) 填写变量 $DOCKER_CONTAINER_IDS，代表清理我们刚才创建的容器。

结果展示

Performance Plugin 能够识别 JMeter、SoapUI 以及 Parrot 生成的报告文件，这里我们只设置一个选项，就是 Source data files (autodetects format):，这里填写 /exchange/jmeter/$BUILD_TAG/summary.log。

插件会把这一文件拷贝到 Workspace，进行解析和显示。

Kubernetes Job

上述过程可以很方便的改造成为 Kubernetes Job：

Docker 相关内容，改为使用 kubectl 进行的 job 文件的生成和操作。
阻塞过程可以查询任务节点的状态
文件存储可以使用 PVC 来共享

K8S 上 Elastic Search 集群的通信加密、认证和清理

Fri, 03 Nov 2017 04:49:29 +0800

Kubernetes 的 Release 文件包中，一直包含了使用 Elastic Search 方案进行日志处理的简单例子，这个例子非常简陋外加版本较旧，处于“能用”的状态而已。

而近期的版本中这一情况发生了变化，原来的 elasticsearch 中新增了一个子目录： production_cluster，README.md中的介绍是：

A more robust example that follows Elasticsearch best-practices of separating nodes concern is also available.

这个听起来就厉害了，关键字：robuts，best-practice。

顺藤摸瓜找到了作者的 github 地址：https://github.com/pires/

这一集群的特点是：

ES 集群分为 Master/Client/Data 三组，各司其职，各自可以设置自己的资源使用，参数配置等。
提供了 StatefulSet 形式的数据节点，便于数据持久化的支持。
采用 Curator 的 CronJob，用于数据的清理。
自定义的 Elastic Search 镜像。

这一些功能自然是极好的，然而因为 X-Pack 的授权问题，使得两个重要的功能： https 通信和认证落了空，还好发现了一个替代方案：Search Guard，简单说来，这一方案提供了免费的认证和 https 通信方案，并且提供了更多的商业支持特性。具体能力范围可以参看官网，下面基于 Pries 的 ES 5.6.3 版本，来把假设在 Kubernetes 集群上的 ES 集群进行加固。

环境准备

Kubernetes 集群：1.7.x
- kube-apiserver启动参数中加入--runtime-config=batch/v2alpha1=true用于支持后面的 CronJob 对象
- 集群存储，用于满足 PVC 需求（可选）
Docker：用于自定义镜像的构建
源代码：
- https://github.com/pires/kubernetes-elasticsearch-cluster
- https://github.com/fluent/fluentd-kubernetes-daemonset.git

镜像的构建

Search Guard 的安装分为插件安装、初始化和集群设置三个步骤，Pries 镜像中推荐的插件安装方式仅能完成第一步骤，因此这里做一些定制，将前两个步骤在镜像中直接完成。

这里我们使用 Pries 镜像为基础：

Dockerfile

FROM quay.io/pires/docker-elasticsearch-kubernetes:5.6.3
COPY prepare.sh /tmp
RUN sh /tmp/prepare.sh

prepare.sh

#!/bin/sh
set -xe
export NODE_NAME="MASTER" # 占位符
# 插件安装
bin/elasticsearch-plugin install -b com.floragunn:search-guard-5:5.6.3-16

# 初始化
chmod a+x plugins/search-guard-5/tools/install_demo_configuration.sh
plugins/search-guard-5/tools/install_demo_configuration.sh -y

# 清理不必要的配置
sed -i  's/network.host.*0$//' config/elasticsearch.yml
sed -i  's/cluster.name.*demo$//' config/elasticsearch.yml

运行 ES 集群

运行集群之前，注意三处需要修改：

镜像名称。
环境变量加入：
```
- name: "NETWORK_HOST"
value: "_eth0_"
```

因为 Search Guard 的加入，Client 的可用检测是失效的，因此需要删除。

kubectl apply -f es-discovery-svc.yaml
kubectl apply -f es-svc.yaml
kubectl apply -f es-master.yaml
kubectl apply -f es-client.yaml
kubectl apply -f es-data.yaml

集群启动之后会处于不可用状态，需要进行 Search guard 设置，使用 kubectl 命令进入任意一个 Master 节点的 Shell，编辑如下文件：

#!/bin/bash
/elasticsearch/plugins/search-guard-5/tools/sgadmin.sh \
-cd /elasticsearch/plugins/search-guard-5/sgconfig \
-ks /elasticsearch/config/kirk.jks  -arc \
-ts /elasticsearch/config/truststore.jks -nhnv -icl \
-h 172.200.62.7

-icl 参数用于禁止证书 CN 的检查。
-h 指定该 Pod 的地址。
-arc 接受状态为 RED 的集群操作。

这样就完成了 ES 集群的初始化设置，并且开始运行。这时我们如果访问其服务，例如：https://node.port:9200，如果弹出安全警告，在选择不检查证书之后，会弹出验证窗口，输入预置的：admin/admin 就能看到正常的 API 页面了。

Fluentd

因为我们的 Fluentd 需要访问 https 协议的有认证要求的 ES 集群，所以这里使用 ConfigMap 的方式，为 Fluentd 加载修改好的配置文件。

首先使用 docker cp 命令，或者直接从源码中获取 fluent.conf 和 kubernetes.conf 两个文件。

在 fluent.conf 的 es 配置中加入 ssl_verify false 一行。

--from-file 开关将上文中的两个配置文件加入 ConfigMap。

修改 DaemonSet 的源码：

...
# 接入配置
- name: FLUENT_ELASTICSEARCH_SCHEME
  value: "https"
- name: FLUENT_ELASTICSEARCH_USER
  value: "admin"
- name: FLUENT_ELASTICSEARCH_PASSWORD
  value: "admin"
...
# 配置文件

volumeMounts:
...
- name: etc
  mountPath: /fluentd/etc
terminationGracePeriodSeconds: 30
volumes:
...
- name: etc
configMap:
  name: fluentd-config

这样，Fluentd 就能成功连接 es 并发送日志了。

Kibana

和 Fluentd 的情况类似，也需要创建他的配置文件，并在 kibana.yml 原有内容基础上增加几行：

elasticsearch.username: "admin"
elasticsearch.password: "admin"
elasticsearch.ssl.verificationMode: none

另外在他的 Deployment 描述中，需要将 ES 集群接口地址改为 https 协议。

启用后，打开 Kibana 页面，就会弹出认证要求。

Curator

编辑 es-curator-config.yml，修改：

use_ssl: True
ssl_no_validate: True
http_auth: admin:admin

然后创建 ConfigMap 和 Cronjob 对象即可。

补充

sgadmin 及其配置有着相当丰富的功能，例如用户和角色的管理等。
证书也是可以使用合法证书进行替代的，不一定需要使用自这个过程中生成的自签名证书。

Kubernetes + Blackbox 实现对 Web 和 DNS 的简单监控

Tue, 19 Sep 2017 23:26:45 +0800

其实都在这里了： https://github.com/prometheus/blackbox_exporter/blob/master/CONFIGURATION.md

Prometheus 带有很多有针对性的 Exporter，能够对 MySQL、Apache 或者 ElasticSearch 等服务器进行监控，另外还有 Blackbox Exporter 用于对 http dns tcp 等零散目标进行简单监控。

DNS 的监控

首先需要运行一个 Blackbox 的 Deployment，并利用 Configmap 来为 Blackbox 提供配置文件：

apiVersion: v1
data:
  config.yml: |
    modules:
      http_2xx:  # http 检测模块
        prober: http
        http:
      http_post_2xx: # http post 模块
        prober: http
        http:
          method: POST
      tcp_connect: # tcp 检测模块
        prober: tcp
      dns:  # dns 检测模块
        prober: dns
        dns:
          transport_protocol: "tcp"
          preferred_ip_protocol: "ip4"
          query_name: "kubernetes.default.svc.cloud.ctrm"  # 利用这个域名来检查 dns 服务器
          query_type: "A"  # 如果是 kube-dns ，一定要加入这个
kind: ConfigMap
metadata:
  name: blackbox
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: blackbox
spec:
  template:
    metadata:
      labels:
        name: blackbox
    spec:
      containers:
      - image: prom/blackbox-exporter:v0.8.1
        name: blackbox
        ports:
        - containerPort: 9115
        volumeMounts:
        - name: config
          mountPath: /etc/blackbox_exporter
        args:
        - --config.file=/etc/blackbox_exporter/config.yml # Configmap 中的配置文件
        - --log.level=error  # 错误级别控制
      volumes:
      - name: config
        configMap:
          name: blackbox
---
apiVersion: v1
kind: Service
metadata:
  name: blackbox
spec:
  selector:
    name: blackbox
  ports:
  - port: 80
    targetPort: 9115

使用 kubectl apply 命令运行起来。

接下来需要在 Prometheus 的配置文件中加入对 BlackBox 的抓取设置：

- job_name: "kubernetes-service-dns"
  metrics_path: /probe # 不是 metrics，是 probe
  params:
    module: [dns] # DNS 模块
  static_configs:
  - targets:
    - kube-dns:53 # 不要省略端口号
  relabel_configs:
  - source_labels: [__address__]
    target_label: __param_target
  - source_labels: [__param_target]
    target_label: instance
  - target_label: __address__
    replacement: blackbox # 服务地址，和上面的 Service 定义保持一致

重启 Prometheus，或者利用 curl Post 更新配置。打开 Prometheus 的 Target 页面，就会看到上面定义的 kubernetes-service-dns 任务了，回到 Graph 页面，可以使用 probe_success{job="kubernetes-service-dns"} 来查看检测历史结果。

HTTP 监控

上面的配置文件中提到有一个 http_2xx 的模块，这里我们可以使用他对 http 服务进行检测。

这里主要是对不受我们控制的外部服务的快速检测。内部的方法就丰富多了。

因为前面已经给 Blackbox 配置了 http_2xx 模块，所以这里只需要在 Prometheus 中加入抓取任务：

- job_name: "business-service-liveness"
  metrics_path: /probe
  params:
    module: [http_2xx]
  static_configs:
  - targets:
    - http://192.168.51.129:30001 # 要检查的网址
    - http://192.168.51.129:30004
    - http://192.168.51.129:30003
  relabel_configs:
  - source_labels: [__address__]
    target_label: __param_target
  - source_labels: [__param_target]
    target_label: instance
  - target_label: __address__
    replacement: blackbox-exporter:9115

同样的，重新载入之后，可以使用 probe_success 和 probe_duration_seconds 等来检查历史结果。

自带 metrics 端点的服务

有的服务，例如 prometheus 或者 blackbox，以及 kube-dns、etcd 等，都是自有 /metrics 提供指标输出的，这种服务对 Blackbox + Prometheus 组合是非常方便的。

只要给服务的注解部分加入几个标签：

prometheus.io/host: calico-etcd # 服务名称
prometheus.io/port: "6666" # metrics 端口
prometheus.io/scrape: "true" # 抓取开关

上面是 calico 的 etcd 服务加入的注解，服务中有了上述注解之后，Prometheus 的示例配置中，已经有了针对这一配置的监控方法，直接刷新 Target 页面，就会看到新的监控目标，可以进行使用了。而无需为每个服务分别定制 Target。

https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml

Kubernetes 应用故障的一些定位方法

Tue, 05 Sep 2017 06:03:04 +0800

常备工作

准备一个工具镜像

其中包含 nslookup, ping, curl, 甚至是 ab、siege 等常用工具以及一个顺手的 Shell。一言不合就可以用静态 Pod 的方式将其运行到 Kubernetes 之中进行内部诊断。

sysctl -a | grep forwarding

你猜这是干啥的？

服务状态查询

各个 Kubernetes 组件的状态检查。可以使用 Ansible 之类的工具进行快速查询。

Service 不通

这里我们首先假设 Pod 工作正常

目前我们的应用均采用的是 NodePort 模式对外提供服务：

逻辑：Service 将 符合其选择器的 Pod 暴露的端口 从 各个 Node 的同一端口暴露出来对外进行监听。
技术：Kube-proxy 通过网络插件，一般利用 Iptables vxLan 等乌七八糟的蜜汁技术，完成对外服务负载均衡，并分发给各个 Pod 的内部 IP 的相应端口。

前面我们假设 Pod 是正常工作的，因此，这里只考虑 Service 的情况。

通过上面的陈述我们能看到大致的一些要素，下面从内向外进行列表：

Pod 能够正常工作

见后文

Service 的选择器能够正确的找到 Pod

这里我们可以使用kubectl describe svc panic-service命令，查看输出内容的endpoint一节内容，如果其中有 Pod 地址，也就说明选择器和 Pod 的标签是匹配的。如果为空，则需要对服务或者 Pod Controller 的定义进行排查。

Proxy 的工作状态

首先可以使用systemctl -l Kube-proxy来查看服务状况。
还可以使用其他 Node 的同一端口测试访问，看是否单一节点的故障。

DNS 工作状态

Kubectl 查看 DNS 各个 Pod 的存活状态。

利用上面提到的工具 Pod 尝试解析服务。失败了其实也没啥办法，删 DNS Pod 重启吧。

端口是否定义正确

看 Pod 的端口是否能够正确侦听，是否符合服务定义。例如 Service 定义了到 Pod 8080 端口的访问，而 Pod 开放的却是 80，这样的情况跟标签无法匹配一样，是很常见的问题。

说完了服务，我们来说说 Pod

两个顺手的命令：

kubectl get po -o wide | grep -v Running kubectl describe po unhealthy

一般来说，一个行为端正的 Pod，应该是以 Running 状态持续运行的。在进入 Running 之前，大致有调度、创建、初始化等几个环节，如果正常运行之后出了故障，会发生重启。如果在启动容器内进程时出现问题，则会进入 CrashLoopBackOff 的状态。

除了 Running/Complet 以及 CrashLoopBackOff：

这几种情况其实不同，不过随性写到这，就不深究了，首先是 describe 一下。

Pod 启动有几个条件：

有符合要求的节点供其运行
- Taint 隔离的节点，要求 Pod 有显式声明对该种 Taint 的容错能力，才可以在其上运行。
- 节点和 Pod 的亲和性定义
- Node Selector 的定义
符合其需求的资源
- CPU 和内存的 request limit 定义
- 可能存在的第三方资源需求定义
- 加载卷（nfs gluster ceph 等）/Secret/Configmap 的定义
镜像必须存在，可 Pull

调度部分一般来说查看 Pod 定义，和节点的 Describe 进行匹配即可，Describe 内容中也会明确说出无合适 Pod。

资源部分 CPU 和内存的 Describe 结果也会很明显。

存储部分，往往就需要更复杂的排查：

首先看看是不是每个 Node 都如此。
是否安装了对应的客户端驱动。
对分布式存储的访问网络是否可用。
存储服务容量是否足够分配。
是否能够成功的手工 Mount。

至于对 ConfigMap 和 Secret 的依赖，很简单，Kubectl 查询即可。

CrashLoopBackOff 以及 Restart 大于 1

这种情况一般来说属于业务内部的问题，可以通过 kubectl logs -f ... 命令进行查看，目前经验比较多的非业务情况是：

对于 Kubernetes API 进行访问的应用，经常会是因为 RBAC 权限不足导致无法启动
依赖的 Service 无法访问。

Kubernetes 的审计日志和采集

Thu, 31 Aug 2017 01:35:22 +0800

基础操作

一个正常运行的 Kubernetes 集群，除了利用访问控制对集群操作的许可进行限制之外，对于操作过程的跟踪审计也是比不可少的，围绕不同的实体，例如用户、节点以及各种工作负载进行观测是很有必要的。Kubernetes 的 API Server 提供了审计日志支持，利用审计日志的方式对系统内的操作进行记录，这里我们可以沿用推荐的 Elastic Search + Fluentd 对审计日志进行采集存储，最终使用 Kibana 或者其他支持 ES 查询的工具对关键资源或用户进行访问跟踪。

首先要启用 API Server 的审计功能。Kubernetes 提供了四个基础参数来定义审计功能：

audit-log-path 启用审计日志，并将日志内容写入指定文件，“-” 代表 stdout。
audit-log-maxage 日志文件的最大保存天数，根据文件名中的日期进行确定。
audit-log-maxbackup 最多保存日志文件的数量。
audit-log-maxsize 最大文件尺寸，超过尺寸会被翻转。单位是 MB，缺省为 100MB。

例如：

--audit-log-path=/var/log/kubernetes/kubernetes.audit \
--audit-log-maxage=7 \
--audit-log-maxbackup=4 \
--audit-log-maxsize=10

在 Kubernetes API Server 的启动参数中加入这些开关之后，重新启动服务。

这时我们就可以看到文件/var/log/kubernetes/kubernetes.audit已经生成。利用 tail 命令看看他的结构和内容，例如请求内容是这样的：

2017-08-30T16:28:35.485818099+08:00 AUDIT: id="ebc47b7b-c4fe-4a9a-861c-d9686903cec4" ip="127.0.0.1" method="GET" user="system:apiserver" groups="\"system:masters\"" as="<self>" asgroups="<lookup>" namespace="<none>" uri="/apis/admissionregistration.k8s.io/v1alpha1/initializerconfigurations"

而响应内容格式如下：

2017-08-30T16:28:35.486131325+08:00 AUDIT: id="ebc47b7b-c4fe-4a9a-861c-d9686903cec4" response="404"

我们本文中暂时只对请求内容进行进一步解析，响应内容可以通过加入第二格式的方式进行采集。内容中的id字段，可以看作是会话 id，用于连接请求和响应。

根据上述文本内容，可以开始 Fluentd 文件的编写。请求和响应的内容都很规则，简单的正则表达式即可完成解析，例如我写的是这样的：

<source>
  type tail
  format /^(?<time>\d.*?)\s+(?<action>\w+).\s+id=\"(?<id>.*?)\"\s+ip=\"(?<ip>.*?)\"\s+method=\"(?<method>.*?)\"\s+user=\"(?<user>.*?)\"\s+groups=(?<groups>.*?)\s+as=\"(?<as>.*?)\"\s+asgroups=\"(?<asgroups>.*?)\"\s+namespace=\"(?<namespace>.*?)\"\s+uri=\"(?<uri>.*?)\"$/
  path /var/log/kubernetes/kubernetes.audit
  pos_file /var/log/audit.pos
  time_format %Y-%m-%dT%H:%M:%S.%N%z
  tag audit.response
</source>

将这一部分内容加入到 Fluentd 配置之中去，启动抓取。日志入库之后，我们就可以对指定用户或者资源进行查询，获知他的黑历史了，例如我们要查找用户admin的操作历史：

{
  "query": {
    "match": {
      "user": {
        "query": "admin",
        "type": "phrase"
      }
    }
  }
}

在 Kibana 中执行查询，会看到类似内容（如果所在集群没有该用户，可以替换为 system:apiserver等内置用户进行测试）：

利用解析出的各个字段，可以比较清楚的看到什么人，在什么时间，对什么对象进行了什么操作。

高级审计

在 Kubernetes 1.7 中新增了 Advanced audit 特性（Alpha），可以对审计内容、以及后续处理进行定义。

首先加入了审计策略的支持，可以使用行为，动作等条件进行限制，过滤掉无需考虑的审计内容。
存储后端在日志之外，还增加了 Web Hook 的支持，可以直接将审计内容发布到指定的 Web 服务中。

Kubernetes 1.7 下的 Prometheus 监控

Mon, 28 Aug 2017 01:59:06 +0800

在 Kubernetes 的标准 Heapster + InfluxDB 的监控方案之外，还有一个监控工具就是 Prometheus 了，相比 InfluxDB 来说，Prometheus 有更集中的检测能力，更多的 Exporter（数据源）支持（不过好像还是打不过 Zabbix？），以及更新潮。。

另外不少新的软件方案缺省开始支持 Prometheus 的数据抓取，所以，早上早填坑。下面是日前在一个 Kubernetes 1.7.3 集群中部署 Prometheus 监控遇到的两个坑，分享一下：

cAdvisor

官方示例解释如下：

This is required for Kubernetes 1.7.3 and later, where cAdvisor metrics (those whose names begin with ‘container_‘) have been removed from the Kubelet metrics endpoint. This job scrapes the cAdvisor endpoint to retrieve those metrics.

In Kubernetes 1.7.0-1.7.2, these metrics are only exposed on the cAdvisor HTTP endpoint; use “replacement: /api/v1/nodes/${1}:4194/proxy/metrics” in that case (and ensure cAdvisor’s HTTP server hasn’t been disabled with the –cadvisor-port=0 Kubelet flag).

在 Kubernetes 1.7.3 和后续版本中，命名前缀为container_ 的 cAdvisor 指标被从 Kubelet 中移除，这一个 Job 从 cAdvisor 端点中抓取数据。

在 Kubernetes 1.7.0 - 1.7.2 中，这些指标只暴露在 cAdvisor 的 http 端点中，需要使用 eplacement: /api/v1/nodes/${1}:4194/proxy/metrics。（注意保证 cAdvisor 的 http 服务没有被--cadvisor-port=0禁用）。

- job_name: 'kubernetes-cadvisor'
  scheme: https
  tls_config:
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
  kubernetes_sd_configs:
  - role: node
  relabel_configs:
  - action: labelmap
    regex: __meta_kubernetes_node_label_(.+)
  - target_label: __address__
    replacement: kubernetes.default.svc:443
  - source_labels: [__meta_kubernetes_node_name]
    regex: (.+)
    target_label: __metrics_path__
    replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor

kube-state-metrics

https://github.com/kubernetes/kube-state-metrics

网址就能看出，这一服务和 Kubernetes 有点亲密。运行之后，能够为 Prometheus 提供大量详细指标，而且这一服务的指标相对来说更具逻辑性，更方便从服务/应用的角度进行监控。

目前容器地址为(不过能 pull 到最新的 v1.0.0，可能是 README 没有同步)：

gcr.io/google_containers/kube-state-metrics:v0.5.0

Kubernetes 的证书认证

Wed, 16 Aug 2017 04:28:26 +0800

原文：How Kubernetes certificate authorities work

今天让我们聊聊 Kubernetes 的公私钥和证书认证。

本文内容会提及如何根据需要对 CA、公私钥进行组织并对集群进行设置。

Kubernetes 的组件中有很多不同的地方可以放置证书之类的东西。在进行集群安装的时候，我感觉有一百多亿个不同的命令参数是用来设置证书、密钥的，真不明白是怎么弄到一起工作的。

当然了，没有一百亿那么多的参数，不过的确很多的。比如 API Server 的参数吧，有大概 16 个参数是跟这些东西有关的（下面是节选）：

--cert-dir string                           The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/run/kubernetes")
--client-ca-file string                     If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
--etcd-certfile string                      SSL certification file used to secure etcd communication.
--etcd-keyfile string                       SSL key file used to secure etcd communication.
--kubelet-certificate-authority string      Path to a cert file for the certificate authority.
--kubelet-client-certificate string         Path to a client cert file for TLS.
--kubelet-client-key string                 Path to a client key file for TLS.
--proxy-client-cert-file string             Client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins. It is expected that this cert includes a signature from the CA in the --requestheader-client-ca-file flag. That CA is published in the 'extension-apiserver-authentication' configmap in the kube-system namespace. Components recieving calls from kube-aggregator should use that CA to perform their half of the mutual TLS verification.
--proxy-client-key-file string              Private key for the client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins.
--requestheader-allowed-names stringSlice   List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed.
--requestheader-client-ca-file string       Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers
--service-account-key-file stringArray      File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. If unspecified, --tls-private-key-file is used. The specified file can contain multiple keys, and the flag can be specified multiple times with different files.
--ssh-keyfile string                        If non-empty, use secure SSH proxy to the nodes, using this user keyfile
--tls-ca-file string                        If set, this certificate authority will used for secure access from Admission Controllers. This must be a valid PEM-encoded CA bundle. Alternatively, the certificate authority can be appended to the certificate provided by --tls-cert-file.
--tls-cert-file string                      File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to /var/run/kubernetes.
--tls-private-key-file string               File containing the default x509 private key matching --tls-cert-file.
--tls-sni-cert-key namedCertKey             A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". (default [])

接下来是 Controller Manager 的：

--cluster-signing-cert-file string          Filename containing a PEM-encoded X509 CA certificate used to issue cluster-scoped certificates (default "/etc/kubernetes/ca/ca.pem")
--cluster-signing-key-file string           Filename containing a PEM-encoded RSA or ECDSA private key used to sign cluster-scoped certificates (default "/etc/kubernetes/ca/ca.key")
--root-ca-file string                       If set, this root certificate authority will be included in service account's token secret. This must be a valid PEM-encoded CA bundle.
--service-account-private-key-file string   Filename containing a PEM-encoded private RSA or ECDSA key used to sign service account tokens.

再来个 Kubelet：

--client-ca-file string                   If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
--tls-cert-file string                    File containing x509 Certificate used for serving HTTPS (with intermediate certs, if any, concatenated after server cert). If --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to --cert-dir.
--tls-private-key-file string             File containing x509 private key matching --tls-cert-file.

本文假设读者：

对 TLS 认证和 CA 有一些了解。
能把这些东西跑起来，但是不知道为啥。

下面还会说明在 Kubernetes 中的不同 CA，以及不同 CA 的协同工作。

另外有些我在工作中学到的一些：

不要用 CA 来检查 Service Account Key。Service Account key 有点古怪，他跟其他的 Key 不是一同处理的。
如果 kubernetes 建立用户和组的方式不适合需求，可以（应该）设置一个认证代理。
API Server 如果设置了太多 CA，会显得有点乱。

这个题目有点复杂，如果阅读中发现任何问题请通知我。

PKI 和 Kubernetes

在阅读 Kubernetes 材料的过程中，我注意到一个词出现了很多次：“PKI”，我不很清楚这是个什么。

如果你有个在运行的 Kubernetes 集群，其中可能有几百上千个公钥私钥（客户端认证、服务认证等等）。

如果这几百个 Key 是独立的互不相关的，就会让安全性堕入泥潭。因此我们需要个 CA，CA 的职责就是签发证书，并告诉用户“这个公钥是我发的，靠谱”。

PKI 就是组织 Key 的方式 —— 什么 Key 是用什么 CA 签发的。

例如：

可以为每个集群准备一个 CA，集群所有的私钥都从这个 CA 签发（Kubernetes 文档中多数是这个情况）。
可以准备一个全局 CA，所有的私钥都从此而来。
单独给服务使用一个 CA，对外可见；内部另外使用一个 CA 作为专门用途。
还有其他。

我不是安全专家，所以不想说如何管理私钥和 CA 才更好。但是不管你用的什么样的模型，其实都可以跟 Kubernetes 协调工作。

下面根据需求来确认管理 PKI 的方式，以及如何在 Kubernetes 中实现。

Kubernetes 集群需要一个单根结构的 CA 么？不

如果你读了不少 Kubernetes 集群的安装文档，会注意到总有一步：设置一个 CA。Kelsey Hightower 的大作 “Kubernetes the hard way” 中是第二步，“在集群中信任 TLS ”中说：

每个 Kubernetes 集群都有一个集群根 CA。CA 一般用于集群中的组件验证 API Server 的合法性，在 API Serverl 来说，就是验证 kubelet 客户端的证书，诸如此类的。

基本上来说：

设置一个 CA
用这个 CA 生成不同的证书，给 Kubernetes 集群的不同组件使用。

如果不想为每个集群设置一个新的 CA 呢？可能有很多理由。但是我担心，最终还是需要提供一个根 CA。

这好像说上面的话是假的，其实可以使用很多不同的 CA 签发的证书来管理 Kubernetes。总的说来，还是要结合具体场景的需求。

接下来我们来探讨一下证书相关的参数，以及互相之间的关系。每一节都会包含一个可以定义的 CA。每一个都是独立的，并不需要一致。不过在实际操作中，可能你并不想管理 6 个不同的 CA。

API Server 的 TLS 证书（以及 CA）

--tls-cert-file string

包含缺省的 x509 https 认证的文件（可以包含 CA 证书），如果启用了 HTTPS 服务，又没有指定--tls-cert-file和--tls-private-key-file参数，就会在 /var/run/kubernetes生成一个自签名证书以及 Key

--tls-private-key-file

--tls-cert-file证书的 x509 私钥。

如果用 TLS 连接 API Server，就需要这两个参数来选择 API Server 使用的证书。

证书设置了之后，还需要给各个组件的 kubeconfig 文件进行相关设置。

current-context: my-context
apiVersion: v1
clusters:
- cluster:
    certificate-authority: /path/to/my/ca.crt # 签发 API Server 证书的 CA 证书
    server: https://horse.org:4443
  name: my-cluster
kind: Config
users:
- name: green-user
  user:
    client-certificate: path/to/my/client/cert # 后面会讲
    client-key: path/to/my/client/key # 后面会讲

有个让我惊奇的事情就是——这个宇宙里面的几乎所有其他使用 TLS 的系统都会去 /etc/ssl 查找一个本机信任的 CA 列表，但是 Kubernetes 很傲娇，他不会去找，必须显式的进行告知签发 CA。

可以使用参数--kubeconfig /path/to/kubeconfig.yaml将配置文件分配给各个组件进行使用。

这样我们完成了第一个 CA 的设置：签发 API Server 证书的 CA。这个 CA 跟其他的 CA 可以不一致。

API Server 客户证书认证

--client-ca-file**

如果设置了这一参数，所有的请求都应该使用该文件中所包含的 CA 签发的证书进行签署，证书中的 Common Name 会作为用户名进行使用。

Kubernetes 组件获得 API Server 认证的方法之一就是使用这一参数。

所有客户端证书都应该由这一 CA 签发（不需要和 API Server 的 CA 一致）。

当使用 kubeconfig 文件的时候，可以按照如下方式设置使用证书：

kind: Config
users:
- name: green-user
  user:
    client-certificate: path/to/my/client/cert
    client-key: path/to/my/client/key

Kubernetes 做了很多用户证书方面的假设（用户名就是 Common Name，Group 就是 Organization）。如果这些假设不符合需求，那么就应该停用客户端证书认证，改用认证代理。

API server 参数

--requestheader-allowed-names stringSlice

--requestheader-username-headers 中指定的 Header 中包含用户名，这一参数的列表确定了允许有效的 Common Name，如果这一参数的列表为空，则所有通过--requestheader-client-ca-file校验的都允许通过。

--requestheader-client-ca-file string

针对收到的请求，在信任--requestheader-username-headers中指定的 Header 里面包含的用户名之前，首先会用这一 CA 对客户证书进行验证。

另外一个设置 Kubernetes 认证的方式就是认证代理。如果你对如何向 API Server 发送用户名和组有很多想法，可以设置一个代理，这一代理会使用 HTTP Header 将用户名和组发送给 API Server。

文档中简单的解释了一下工作方式。代理使用一个客户端证书表明身份，--requestheader-client-ca-file告知 API Server，该证书所属的 CA。

我觉得——API Server 有太多认证方式了（客户端认证、认证代理、Token 等等），让人很迷惑。建议用户尽量少的同时使用认证方式，便于管理、使用和除错。

service account 私钥（不是 CA 签发的）

API Server 参数

--service-account-key-file

PEM 编码的 X509 RSA 或者 ECDSA 的私钥或者公钥，用于检验 ServiceAccount 的 token。如果没指定的话，会使用--tls-private-key-file替代。文件中可以包含多个 Key，这一参数可以重复指定多个文件。

Controller Manager 参数

--service-account-private-key-file

PEM 编码的 X509 RSA 或者 ECDSA Key，用于签署 Service Account Token。

Controller Manager 使用私钥签署 Service Account Token。跟 Kubernetes 中使用的其他私钥不同的是，这个私钥是不支持同一 CA 验证的，因此上，需要给每个 Controller Manager 指定一致的私钥文件。

这个 Key 也不需要什么 CA 来做签署，生成很容易：

openssl genrsa -out private.key 4096

然后分发给每个 Controller Manager 和 API Server 就可以了。

使用和 --tls-private-key-file 一致的文件是可以工作的——只要你给每个 API Server 用的都是同一个 TLS Key（一般都这么做的吧？）。（这里我假设你运行的一个有高可用支持的，多个 API Server 和多个 Controller Manager同时运行的集群）

如果两个不同的 Controller Manager 用了两个不同的 Key，那就杯具了，他们会用各自的 Key 来生成 Token，最终导致无效判定。我觉得这点不太合理，Kubernetes 应该和其他方面一样，使用 CA 进行管理。通过对源码的月度，我觉得原因可能是 jwt-go 不支持 CA。

Kubelet 证书认证

总算到了 Kubelet 环节了，下面是 API Server 和 Kubelet 相关的内容：

API Server 参数

--kubelet-certificate-authority： CA 证书的路径。
--kubelet-client-certificate： TLS 证书文件
--kubelet-client-key** TLS Key：文件

Kubelet 参数

--client-ca-file

请求中的客户端证书如果是由文件中的 CA 签署的，那么他的 Common Name 就会被用作 ID 进行认证。

--tls-cert-file

用来提供 HTTPS 服务的 x509 证书（其中也可包含中间人证书）。如果不提供 --tls-cert-file 和--tls-private-key-file，就会为主机地址生成一个自签名的证书和对应的 Key，并保存到 --cert-dir 目录里。

--tls-private-key-file：--tls-cert-file 对应的 Key

校验 kubelet 的请求是有用的，因为 Kubelet 的职责就是在主机上执行代码。

这里实际上有两个 CA，这里不准备深入描述，情况和 API Server 是一样的，Kubelet 用 TLS 来进行认证，也支持客户证书认证。

另外还要告知 API Server，用什么 CA 检查 Kubelet 的 TLS，另外用什么证书来跟 Kubelet 通信。

再说一次，这两个 CA 是可以不同的。

太多 CA 了

现在我们找到了五个不同的 CA，他们各自独立的为 Kubernetes 提供支持。

其实还有一些没讨论到的证书，不过希望本文能给你阅读官方文档提供一点帮助。

当然了，每个 CA 独立设置可能不是必要的，我是希望帮助读者理解这些东西如何设置使之符合各种需求，而不是简单的面向文档照本宣科。

Kubernetes 中的几种存储

Sat, 12 Aug 2017 00:07:43 +0800

参考：https://kubernetes.io/docs/concepts/storage/volumes/

一个运行中的容器，缺省情况下，对文件系统的写入，都是发生在其分层文件系统的可写层的，一旦容器运行结束，所有写入都会被丢弃。因此需要对持久化支持。

Kubernetes 中通过 Volume 的方式提供对存储的支持。下面对一些常见的存储概念进行一点简要的说明。

EmptyDir

顾名思义，EmptyDir是一个空目录，他的生命周期和所属的 Pod 是完全一致的，可能读者会奇怪，那还要他做什么？EmptyDir的用处是，可以在同一 Pod 内的不同容器之间共享工作过程中产生的文件。

缺省情况下，EmptyDir 是使用主机磁盘进行存储的，也可以设置emptyDir.medium 字段的值为Memory，来提高运行速度，但是这种设置，对该卷的占用会消耗容器的内存份额。

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

HostPath

这种会把宿主机上的指定卷加载到容器之中，当然，如果 Pod 发生跨主机的重建，其内容就难保证了。

这种卷一般和DaemonSet搭配使用，用来操作主机文件，例如进行日志采集的 FLK 中的 FluentD 就采用这种方式，加载主机的容器日志目录，达到收集本主机所有日志的目的。

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # directory location on host
      path: /data

NFS/GlusterFS/CephFS/AWS/GCE 等等

作为一个容器集群，支持网络存储自然是重中之重了，Kubernetes 支持为数众多的云提供商和网络存储方案。

各种支持的方式不尽相同，例如 GlusterFS 需要创建 Endpoint，Ceph/NFS 之流就没这么麻烦了。

各种个性配置可移步参考文档。

ConfigMap 和 Secret

镜像使用的过程中，经常需要利用配置文件、启动脚本等方式来影响容器的运行方式，如果仅有少量配置，我们可以使用环境变量的方式来进行配置。然而对于一些较为复杂的配置，例如 Apache 之类，就很难用这种方式进行控制了。另外一些敏感信息暴露在 YAML 中也是不合适的。

ConfigMap 和 Secret 除了使用文件方式进行应用之外，还有其他的应用方式；这里仅就文件方式做一点说明。

例如下面的 ConfigMap，将一个存储在 ConfigMap 中的配置目录加载到卷中。

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "ls /etc/config/" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        # Provide the name of the ConfigMap containing the files you want
        # to add to the container
        name: special-config
  restartPolicy: Never

注意，这里的 ConfigMap 会映射为一个目录，ConfigMap 的 Key 就是文件名，每个 Value 就是文件内容，比如下面命令用一个目录创建一个 ConfigMap：

kubectl create configmap \
game-config \
--from-file=docs/user-guide/configmap/kubectl

创建一个 Secret：

kubectl create secret generic \
db-user-pass --from-file=./username.txt \
--from-file=./password.txt

使用 Volume 加载 Secret：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: myns
spec:
  containers:
    - name: mypod
      image: redis
      volumeMounts:
        - name: foo
          mountPath: /etc/foo
          readOnly: true
  volumes:
    - name: foo
      secret:
        secretName: mysecret

可以看到 Secret 和 ConfigMap 的创建和使用是很相似的。在 RBAC 中，Secret 和 ConfigMap 可以进行分别赋权，以此限定操作人员的可见、可控权限。

PV & PVC

PersistentVolume 和 PersistentVolumeClaim 提供了对存储支持的抽象，也提供了基础设施和应用之间的分界，管理员创建一系列的 PV 提供存储，然后为应用提供 PVC，应用程序仅需要加载一个 PVC，就可以进行访问。

而 1.5 之后又提供了 PV 的动态供应。可以不经 PV 步骤直接创建 PVC。

参考：http://blog.fleeto.us/translation/dynamic-provisioning-and-storage-classes-kubernetes-0

Istio，Kubernetes 的微服务支持

Sun, 16 Jul 2017 17:17:08 +0800

参考资料： https://developer.ibm.com/dwblog/2017/istio/ http://blog.kubernetes.io/2017/05/managing-microservices-with-istio-service-mesh.html https://istio.io/docs/

简介

Istio 是一个由 IBM、Google 以及 Lyft 联合推出的开源软件，以无痛方式为运行在 Kubernetes 上的微服务提供流量管理，访问策略管理以及监控等功能。这一软件目前仅在 Kubernetes 上运行，今后可能会扩展到其他平台。本文会结合官方例子，完成安装和基础的监控内容。

架构和组件

总体架构如图所示。

Envoy

一个 C++ 编写的高性能代理服务器，这里做了扩展，在 Istio 中会以 Sidecar 方式跟应用运行在同一 Pod 内，一方面可以接收并执行关于规则、流量拆分等方面的指令，另一方面能够产生各种指标用于监控和跟踪。

Mixer

Mixer 组件，主要进行访问控制以及策略控制，同时也负责从 Envoy 中获取各项指标。

Pilot

Pilot 是用户和 Isito 之间的桥梁，负责接收各种配置，并发送给各个组件。

Istio auth

内置认证和凭证管理，利用 TLS 提供服务之间、用户和服务之间的认证。可以用来将没有加密支持的服务升级为加密版本，并且在网络策略之外，提供服务级别的策略控制，今后还会增加更多的鉴权和审计方面的能力。

功能 & 特性

无需对现有服务进行变更
支持 http 1.1/2、gRPC 以及 TCP 流量的负载均衡和故障转移
可替换的组件
流量监控
可提供身份认证功能
可定制的路由规则
错误处理，例如超时、重试、访问量控制、健康检查和熔断器等。

安装

先决条件

Kubernetes
互联网连接

准备工作

首先去https://github.com/istio/istio/releases下载最新版本（目前为 0.1.6），解压并设置 istioctl 命令的执行路径。下面命令中描述的相对目录就是基于此目录

执行命令kubectl api-versions | grep rbac查看当前集群的 RBAC 设置：

如果返回内容为空则无需理会。
如果返回内容中包含beta，则需要运行kubectl apply -f install/kubernetes/istio-rbac-beta.yaml来进行授权
如果返回内容中只有alpha ，就要kubectl apply -f install/kubernetes/istio-rbac-beta.yaml创建相应的角色和绑定了。

运行

最后，运行kubectl create -f install/kubernetes/istio.yaml创建一系列的 Deployment 以及 Services。

注1：其实上面的内容照做并不一定能成功，反正我的 1.6.6 上面是没能成功，Pilot Pod 中的 API Server 容器会出错，错误信息大概是“system:serviceaccount:default:istio-pilot-service-account” cannot get thirdpartyresources.extensions at the cluster scope.”，也就证明了 beta.yaml 中的 RBAC 设置是不够的，这里我把几个 RoleBinding 都改成为 ClusterRoleBinding，运行就成功了。

注2：istio.yaml 中的 Ingress 服务是 Loadbalancer 类型的，如果测试集群不具备这样的条件，还请自行修改成其他合适内容。

至此，基础的 istio 组件就已经运行完毕了。

运行应用

安装包内包含了一个叫 bookinfo 的小应用，由 Product（入口页）、Detail 和 Review 三部分组成，具体应用 YAML 在安装目录的samples/apps/bookinfo/bookinfo-v1.yaml文件中。打开文件我们会发现这是个很简单的小应用，无非是几个 Deployment 和 Service 的组合。

该应用的微服务相互关系大致如下图所示，这个例子很好的展示了 istio 的一大特性——不拘泥于某种语言。

istio 提供了一个工具叫 istioctl，这个工具的功能之一，就是把普通的应用 YAML 注入为 istio 支持的应用模式，例如：istioctl kube-inject -f bookinfo-v1.yaml > bookinfo-istio-v1.yaml，比较新旧两个文件不难发现，这一工具为每个 Pod 新增了一个名为 proxy 的容器，以此接管流量，给监控和管理打下基础。

接下来我们运行这一应用： - kubectl create -f bookinfo-istio-v1.yaml：运行注入后的应用 - kubectl create -f bookinfo-ingress.yaml：创建 Ingress 资源

监控

istio 内置了对 ServiceGraph、Prometheus 以及 Zipkin 的支持，简单的运行一下kubectl create -f install/kubernetes/addons，就会启用这几个服务。注意这几个服务使用的也都是 Loadbalancer 模式，读者应根据集群情况自行修改。

各个服务启动之后，可以使用负载工具例如 wrk 对 Productpage 页面进行一段时间的访问，来模拟工作情况。

Grafana

Grafana 启动后，我们可以使用服务暴露的地址进行访问，在其中可以看到如下图所示的 Dashboard，展示了我们应用中的几个服务的各种监控数据。

Service Graph

这一个服务提供了两个入口，一个是 /dotvz，以图形的方式供服务关系展示，而/graph则提供了 JSON 格式的文档供结构化使用。例如：

{
    "nodes": {
        "details": {},
        "productpage": {},
        "reviews": {},
        "unknown": {}
    },
    "edges": [
        {
            "source": "productpage",
            "target": "reviews",
            "labels": {
                "qps": "0.030416",
                "version": "v1"
            }
        },
        {
            "source": "unknown",
            "target": "productpage",
            "labels": {
                "qps": "0.030416",
                "version": "v1"
            }
        },
        {
            "source": "productpage",
            "target": "details",
            "labels": {
                "qps": "0.030416",
                "version": "v1"
            }
        }
    ]
}

Zipkin

Istio 提供了开箱即用的 Zipkin 跟踪支持，打开页面之后，我们会看到 Zipkin 的查找页面，并无特殊内容，就不展开细谈了。

文中介绍内容只是很粗浅的入门操作，后续会进一步跟进、挖掘和学习这一系统的其他强大功能。

在 Kubernetes 中使用 Fluent Bit 进行日志采集

Mon, 10 Jul 2017 08:51:52 +0800

Fluent Bit 和 Fluentd 一样，是 Treasure Data 资助的采集工具，二者对比如下：

	Fluentd	FluentBit
范围	服务器	嵌入设备和 IoT 设备
内存	约 20 MB	约 150 KB
语言	C 和 Ruby	C
性能	高	高
依赖	以 Ruby Gem 构建，依赖一系列的 Gem	零依赖，可能有些插件会有依赖。
插件	超过三百个	目前15个左右
授权	Apache License v2.0	Apache License v2.0

从上表可以看出，Fluentd 具有众多插件，随之而来的是很好的弹性。而 Fluent Bit 则更适用于嵌入设备等资源受限的场景。另外二者并非互斥关系，Fluent Bit 提供了输出插件，可以把数据发给 Fluentd，因此他们可以在系统中作为独立服务互相协作。

Fluent Bit 也提供了 Kubernetes Filter 插件，用于将采集到的日志结合对 Kubernetes API 的查询，为日志加入 Kubernetes 的相关数据，例如 Pod 信息、容器信息、命名空间以及标签和注解等内容。

仅就此来说，Fluent Bit 是可以替代 Kubernetes 缺省推荐的 Fluentd 进行日志采集工作的，经过笔者测试，可以直接使用他替代原有的 Fluentd，使用 DaemonSet 运行，结合 Elastic Search 进行日志归集工作。

详情参见：http://fluentbit.io/documentation/0.11/filter/kubernetes.html

简单的使用如下命令就可以运行：

    kubectl create -f https://raw.githubusercontent.com/fluent/fluent-bit-kubernetes-daemonset/master/fluent-bit-daemonset-elasticsearch.yaml

这一 YAML 文件中的镜像版本为 0.11，具体版本更新可以到 Docker Hub 进行查询，其中包含的缺省 elasticsearch 地址为 elasticsearch-logging，端口为 9200，如上配置如果不符，可以下载文件自行修改运行。

另外目前 RBAC 的访问控制模式已经成为缺省，在启用了 RBAC 模式的集群中，该 Pod 的运行是无法成功的，具体表现是日志中出现无法获取 Pod 元数据的信息，这是因为缺省情况下，这一 YAML 中使用的是 kube-system 中的 default Service Account，这一服务账号并不具备获取 Pod 信息的授权，要成功运行，就必须按照 RBAC 的规矩，让 Fluent Bit 的 Service Account 能够获取 Pod 信息，可以用如下方式来解决：

首先为 Fluent bit 创建专门的 Service Account：

    kubectl create sa logging -n kube-system

然后为日志收集器创建角色，让该角色可以读取 Pod 信息。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

接下来创建 ClusterRoleBinding，把新建的角色和 Service Account 绑定在一起：

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods-global
subjects:
- kind: ServiceAccount
  name: logging
  namespace: kube-system
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

最后在 Fluent Bit 的 yaml 中加入 Service Account 的指派：

# 省略若干
spec:
  template:
    metadata:
      labels:
        k8s-app: fluent-bit-logging
        version: v1
        kubernetes.io/cluster-service: "true"
    spec:
      serviceAccountName: logging
# 省略若干

经过这一番折腾之后，Fluent Bit 就可以在开启 RBAC 的 1.⁶⁄₁.7 集群上运行了。打开相应的 Kibana 页面，会看到和标配 Fluentd 一致的日志搜集结果。

好吧，今天讲的其实是 RBAC。

Kubeadm offline installer 升级到 1.7.0 版本

Thu, 06 Jul 2017 23:19:51 +0800

仓库地址

本来做这玩意的初衷就是，Kubeadm 和 Kubernetes 是一家人，升级比较方便跟得住。未曾想第一次大版本升级，就遇到了个不大不小的坑，导致安装无法完成。这个 Issue 会在 1.7.1 修补，下面介绍一下曲线救国的安装方式。

这一问题的似乎是 kubeadm 的更新破坏了 TLS 自动授权过程造成的，具体症状是：主节点的 kubeadm init 完成之后，在其他节点上使用 kubeadm join --token=xxxx host_ip:host_port 命令加入集群时，集群会反复输出错误信息，大意是 kube-public 命名空间中名为 cluster-info 的 ConfigMap 中没有对应 token 的签署记录。

使用 kubectl 查看该 ConfigMap，和 1.6.6 的集群作对照（是的，安装的够快，想要什么版本都容易），发现 1.7.0 里面这个 ConfigMap 的元素列表确缺少这一块内容。

既然如此，看样子手工签署也是要不少工夫，干脆转头使用上一版本（1.6.6）的 kubeadm，使用指定版本的方式来安装 1.7.0 的集群。

kubeadm init 过程会顺利完成，然而在 kubeadm join 过程中，会卡在 CSR 阶段，经过翻查文档，1.7.0 的自动授权方式有变化，废弃了原有的根据 Group 自动通过的开关，一不做二不休，在 Playbook 的 Master Role 中新建一个 Cron Job，每分钟执行一次如下命令：

#!/bin/sh
TOKEN=`kubectl get csr | grep csr | grep -i pending | cut -f1 -d " " | head -n 1`
if [[ -n "$TOKEN" ]]; then
  kubectl certificate approve $TOKEN
  echo "CSR: $TOKEN had been approved." >> /var/log/auto_approval.log
else
  echo "CSR not found." >> /var/log/auto_approval.log
fi

简单说就是获取在途的 CSR，进行 Approve。这样在后面的节点进行加入的时候，主节点会每分钟进行一次 Approve，在所有节点成功加入之后，调用 Cleanup 角色，禁用这一功能即可。

最后，Github 不建议在版本库中存放二进制文件，这里我将所有二进制文件集中到了根目录的 files 目录下，要顺利使用这一脚本，一定要在 Release 页面中下载相应的压缩包来使用。

kubeadm 踩坑记

Tue, 27 Jun 2017 08:14:05 +0800

Kubeadm 是个让我爱恨交加的东西，一方面，我不认为一个生产集群应该使用这样一个第三方工具进行在线安装，尤其是在目前这种网络环境之下；而另外一方面，Kubeadm 这一工具是随 Kubernetes 同步更新的，其中包含了大量的集群配置方面的最佳实践，是追新的最佳参考，所以这个讨厌的东西的运行是必须需要得到保障的。kubeadm 的执行过程沉默到令人发指，因此下面分享几个使用过程中遇到的一些问题和解决的思路和方法，希望对同行们有所帮助。

下面的例子是基于 kubeadm 1.6.6 + Centos 7 的执行过程记录的。

写入 yum repo 并进行安装之后，利用 systemctl enable kubelet 启用 kubelet 服务之后，只要运行一下 systemctl daemon-reload即可，这一服务的启动需要 kubeadm 生成的证书和配置文件等的支持，因此无需进行启动。
kubeadm init过程首先会检查代理服务器，确定跟 kube-apiserver 的 https 连接方式，如果有代理设置，会提出警告。
接下来会对 sysctl 进行检查，我这里需要执行 sysctl net.bridge.bridge-nf-call-iptables=1 ，对这一参数进行调整，解决他的警告。
接下来进入最抓狂的一个等待时间，屏幕显示为[apiclient] Created API client, waiting for the control plane to become ready，这一过程中会遇到大多数的坑，我一般会另外启动一个连接或者 tmux 窗口，进行观察和除错：
- 这里已经做好运行 kubelet 服务的准备，因此这一时间内，我们可以利用systemctl statusl -l kubelet对服务的启动状况进行检查，目前比较容易遇到的是 kubectl 和 docker 两个服务的cgroup-driver不一致的问题，这里编辑文件/etc/systemd/system/kubelet.service.d/10-kubeadm.conf，修改这一参数值为跟 docker 一致的cgroupfs即可。这一步可以在 kubeadm init 之前执行完成
- kubelet 启动之后，会尝试运行系统组件的 Pod，这里我们可以通过观察docker images的镜像列表来观察是否能够顺利进行下载。
- 镜像下载完成之后就会开始运行各个系统组件，因此也是事故最为集中的阶段，我们可以使用docker ps、docker logs、docker inspect几个命令，逐个查看组件的运行情况，对失败组件的原因进行排除，之前提过的resolv.conf的故障就是在这一阶段发现并排除的。

实测：Kubernetes 1.6 中的混合 DNS

Sat, 03 Jun 2017 08:39:03 +0800

在之前的文章中提到过，Kubernetes 1.6 新增的混合 DNS 功能。这一功能不大，但是在企业私有云环境下有着非常重要的衔接作用，能够有效的将 Kubernetes 内的应用和集群外甚至互联网上的的 Consual 或者类似系统管理的服务连接起来，形成更好的协同效果。

上篇文章主要侧重点是概念和一些 YAML 例子，本文则会从操作出发，用一个例子从头到尾的逐步操作这一功能的具体操作。

DNS Server

我们使用一个 Ubuntu Server 运行 dnsmasq 来担任 Kubernetes 集群外的 DNS 服务器角色，只为了满足测试需要的话，就不需要太复杂的配置了。

安装

具体安装步骤如下：

#!/bin/sh
# 安装 dnsmasq
apt install dnsmasq
# 停止自动启动的 dnsmasq 服务
systemctl stop dnsmasq
# 生成一个 Host 文件并写入一条记录
echo " 114.114.114.114 server.out-of.kubernetes" > /tmp/hosts
# 显示 IP
ifconfig
# 启动 DNS 服务
# -d 用 debug 模式启动，在前台运行
# -q 输出查询记录
# -h 不使用 /etc/hosts
# -R 不使用 /etc/resolve.conf
# -H 使用刚才生成的文件作为 dns 记录
dnsmasq -q -d -h -q -R -H /tmp/hosts

这样，我们就启动了一个 DNS 服务器，并且可以直观的看到其工作状况如下：

dnsmasq: started, version 2.76 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC lo
op-detect inotify
dnsmasq: warning: no upstream servers configured
dnsmasq: bad address at /tmp/hosts line 1
dnsmasq: read /tmp/hosts - 0 addresses

Kubernetes 配置

前文说过，我们需要用一个 Configmap 对象来让 Kubernetes 应用新的 DNS 解析配置，这里我们简单的新建一个存根域，就是上文提到的 out-of.kubernetes 域名，让其使用我们前面安装的 DNS 服务器进行解析，其他域名则使用 8.8.8.8 和 8.8.4.4 这一公共 DNS 解析。配置情况如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {"out-of.kubernetes": ["10.140.0.5"]}
  upstreamNameservers: |
    ["8.8.8.8", "8.8.4.4"]

利用 kubectl apply -f 命令使之生效。

注意：系统可能缺省带有这一 configmap，因此需要用 apply 进行操作，建议使用 kubectl get configmap kube-dns -o yaml --namespace kube-system 进行复查。

测试 Pod

这里使用一个 Alpine Linux 的镜像作为测试工具：

apiVersion: v1
kind: Pod
metadata:
  name: tester
spec:
  containers:
  - name: alpine
    image: alpine
    imagePullPolicy: IfNotPresent
    command: ["sleep"]
    args: ["3600"]

测试

测试 Pod 运行之后，可以使用kubectl exec -it tester sh命令进入 Pod开始测试。

在 Pod 的 Shell 中我们可以尝试执行 ping server.out-of.kubernetes，会看到返回了我们写入在 Hosts 中的地址，在 DNS 服务器端，也会看到相关的查询记录。
如果 ping 其他的主机名，则会返回正常的结果。

针对资源紧缺处理方式的配置

Thu, 01 Jun 2017 19:25:48 +0800

原文：Configure Out Of Resource Handling

如何在资源紧缺的情况下，保证 Node 的稳定性，是 Kubelet 需要面对的一个重要的问题。尤其对于内存和磁盘这种不可压缩的资源，紧缺就相当于不稳定。

驱逐策略

Kubelet 能够监控资源消耗，来防止计算资源被耗尽。一旦出现资源紧缺的迹象，Kubelet 就会主动终止一或多个 Pod 的运行，以回收紧俏资源。当一个 Pod 被终止时，其中的容器会全部停止，Pod 状态会被置为 Failed。

驱逐信号

下文中提到了一些信号，kubelet 能够利用这些信号作为决策依据来触发驱逐行为。描述列中的内容来自于 Kubelet summary API。

驱逐信号	描述
memory.available	memory.available := node.status.capacity[memory] - node.stats.memory.workingSet
nodefs.available	nodefs.available := node.stats.fs.available
nodefs.inodesFree	nodefs.inodesFree := node.stats.fs.inodesFree
imagefs.available	imagefs.available := node.stats.runtime.imagefs.available
imagefs.inodesFree	imagefs.inodesFree := node.stats.runtime.imagefs.inodesFree

上面的每个信号都支持整数值或者百分比。百分比的分母部分就是各个信号的总量。kubelet 支持两种文件系统分区。

nodefs：保存 kubelet 的卷和守护进程日志等。
imagefs：在容器运行时，用于保存镜像以及可写入层。

imagefs 是可选的。Kubelet 能够利用 cAdvisor 自动发现这些文件系统。Kubelet 不关注其他的文件系统。所有其他类型的配置，例如保存在独立文件系统的卷和日志，都不被支持。

因为磁盘压力已经被驱逐策略接管，因此未来将会停止对现有垃圾收集方式的支持。

驱逐阈（yù，音同“预”）值：

一旦超出阈值，就会触发 kubelet 进行资源回收的动作。阈值的定义方式如下：

<eviction-signal><operator><quantity>

上面的表格中列出了可用的 eviction-signal.
仅有一个 operator 可用：<
quantity 需要符合 Kubernetes 中的描述方式。

例如如果一个 Node 有 10Gi 内存，我们希望在可用内存不足 1Gi 时进行驱逐，就可以选取下面的一种方式来定义驱逐阈值：

memory.available<10%
memory.available<1Gi

驱逐软阈值

软阈值需要和一个宽限期参数协同工作。当系统资源消耗达到软阈值时，这一状况的持续时间超过了宽限期之前，Kubelet 不会触发任何动作。如果没有定义宽限期，Kubelet 会拒绝启动。

另外还可以定义一个 Pod 结束的宽限期。如果定义了这一宽限期，那么 Kubelet 会使用 pod.Spec.TerminationGracePeriodSeconds 和最大宽限期这两个值之间较小的那个（进行宽限），如果没有指定的话，kubelet 会不留宽限立即杀死 Pod。

软阈值的定义包括以下几个参数：

eviction-soft：描述一套驱逐阈值（例如 memory.available<1.5Gi ），如果满足这一条件的持续时间超过宽限期，就会触发对 Pod 的驱逐动作。
eviction-soft-grace-period：包含一套驱逐宽限期（例如 memory.available=1m30s），用于定义达到软阈值之后，持续时间超过多久才进行驱逐。
eviction-max-pod-grace-period：在因为达到软阈值之后，到驱逐一个 Pod 之前的最大宽限时间（单位是秒），

驱逐硬阈值

硬阈值没有宽限期，如果达到了硬阈值，kubelet 会立即杀掉 Pod 并进行资源回收。

硬阈值的定义：

eviction-hard：描述一系列的驱逐阈值（比如说 memory.available<1Gi），一旦达到这一阈值，就会触发对 Pod 的驱逐，缺省的硬阈值定义是：

–eviction-hard=memory.available<100Mi

驱逐监控频率

Housekeeping interval 参数定义一个时间间隔，Kubelet 每隔这一段就会对驱逐阈值进行评估。

housekeeping-interval：容器检查的时间间隔。

节点状况

Kubelet 会把驱逐信号跟节点状况对应起来。

如果触发了硬阈值，或者符合软阈值的时间持续了与其对应的宽限期，Kubelet 就会认为当前节点压力太大，下面的节点状态定义描述了这种对应关系。

节点状况	驱逐信号	描述
MemoryPressure	memory.available	节点的可用内存达到了驱逐阈值
DiskPressure	nodefs.available, nodefs.inodesFree, imagefs.available, imagefs.inodesFree	节点的 root 文件系统或者镜像文件系统的可用空间达到了驱逐阈值

Kubelet 会持续报告节点状态的更新过程，这一频率由参数 –node-status-update-frequency 指定，缺省情况下取值为 10s。

节点状况的波动

如果一个节点的状况在软阈值的上下波动，但是又不会超过他的宽限期，将会导致该节点的状态持续的在是否之间徘徊，最终会影响降低调度的决策过程。

要防止这种状况，下面的标志可以用来通知 Kubelet，在脱离压力状态之前，必须等待。

eviction-pressure-transition-period 定义了在跳出压力状态之前要等待的时间。

Kubelet 在把压力状态设置为 False 之前，会确认在周期之内，该节点没有达到逐出阈值。

回收节点级别的资源

如果达到了驱逐阈值，并且超出了宽限期，那么 Kubelet 会开始回收超出限量的资源，直到驱逐信号量回到阈值以内。

Kubelet 在驱逐用户 Pod 之前，会尝试回收节点级别的资源。如果服务器为容器定义了独立的 imagefs，他的回收过程会有所不同。

有 Imagefs

如果 nodefs 文件系统到达了驱逐阈值，kubelet 会按照下面的顺序来清理空间。

删除死掉的 Pod/容器

如果 imagefs 文件系统到达了驱逐阈值，kubelet 会按照下面的顺序来清理空间。

删掉所有无用镜像

没有 Imagefs

如果 nodefs 文件系统到达了驱逐阈值，kubelet 会按照下面的顺序来清理空间。

删除死掉的 Pod/容器
删掉所有无用镜像

驱逐用户 Pod

如果 Kubelet 无法获取到足够的资源，就会开始驱逐 Pod。

Kubelet 会按照下面的标准对 Pod 的驱逐行为进行评判：

根据服务质量
根据 Pod 调度请求的被耗尽资源的消耗量

接下来，Pod 按照下面的顺序进行驱逐：

BestEffort：消耗最多紧缺资源的 Pod 最先失败。
Burstable：相对请求（request）最多紧缺资源的 Pod 最先被驱逐，如果没有 Pod 超出他们的请求，策略会瞄准紧缺资源消耗量最大的 Pod。
Guaranteed：相对请求（request）最多紧缺资源的 Pod 最先被驱逐，如果没有 Pod 超出他们的请求，策略会瞄准紧缺资源消耗量最大的 Pod。

Guaranteed Pod 绝不会因为其他 Pod 的资源消费被驱逐。如果系统进程（例如 kubelet、docker、journald 等）消耗了超出 system-reserved 或者 kube-reserved 的资源，而且这一节点上只运行了 Guaranteed Pod，那么为了保证节点的稳定性并降低异常消费对其他 Guaranteed Pod 的影响，必须选择一个 Guaranteed Pod 进行驱逐。

本地磁盘是一个 BestEffort 资源。如有必要，kubelet 会在 DiskPressure 的情况下，kubelet 会按照 QoS 进行评估。如果 Kubelet 判定缺乏 inode 资源，就会通过驱逐最低 QoS 的 Pod 的方式来回收 inodes。如果 kubelet 判定缺乏磁盘空间，就会通过在相同 QoS 的 Pods 中，选择消耗最多磁盘空间的 Pod 进行驱逐。

有 Imagefs

如果 nodefs 触发了驱逐，Kubelet 会用 nodefs 的使用对 Pod 进行排序 - Pod 中所有容器的本地卷和日志。

如果 imagefs 触发了驱逐，Kubelet 会根据 Pod 中所有容器的消耗的可写入层进行排序。

没有 Imagefs

如果 nodefs 触发了驱逐，Kubelet 会对各个 Pod 的所有容器的总体磁盘消耗进行排序 —— 本地卷 + 日志 + 写入层。

在某些场景下，驱逐 Pod 可能只回收了很少的资源。这就导致了 kubelet 反复触发驱逐阈值。另外回收资源例如磁盘资源，是需要消耗时间的。

要缓和这种状况，Kubelet 能够对每种资源定义 minimum-reclaim。kubelet 一旦发现了资源压力，就会试着回收至少 minimum-reclaim 的资源，使得资源消耗量回到期望范围。

例如下面的配置：

--eviction-hard=memory.available<500Mi,nodefs.available<1Gi,imagefs.available<100Gi
--eviction-minimum-reclaim="memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi"`

如果 memory.available 被触发，Kubelet 会启动回收，让 memory.available 至少有 500Mi。
如果是 nodefs.available，Kubelet 就要想法子让 nodefs.available 回到至少 1.5Gi。
而对于 imagefs.available， kubelet 就要回收到最少 102Gi。

缺省情况下，所有资源的 eviction-minimum-reclaim 为 0。

调度器

在节点资源紧缺的情况下，节点会报告这一状况。调度器以此为信号，不再继续向此节点部署新的 Pod。

节点状况	调度行为
`MemoryPressure`	不再分配新的 `BestEffort Pod` 到这个节点
`DiskPressure`	不再向这一节点分配 Pod

节点的 OOM 行为

如果节点在 Kubelet 能够回收内存之前，遭遇到了系统的 OOM (内存不足)，节点就依赖 oom_killer 进行响应了。

kubelet 根据 Pod 的 QoS 为每个容器设置了一个 oom_score_adj 值。

QoS	`oom_score_adj`
Guaranteed	-998
BestEffort	1000
Burstable	`min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)`

如果 kubelet 无法在系统 OOM 之前回收足够的内存，oom_killer 就会根据根据内存使用比率来计算 oom_score，得出结果和 oom_score_adj 相加，最后得分最高的 Pod 会被首先驱逐。

这一行为的思路是，QoS 最低，相对于调度的 Reqeust 来说又消耗最多内存的 Pod 会被首先清除，来保障内存的回收。

跟 Pod 驱逐不同，如果一个 Pod 的容器被 OOM 杀掉，他是可能被 kubelet 根据 RestartPolicy 重启的。

最佳时间

可调度的资源和驱逐策略

我们想象如下的场景：

节点内存容量：10Gi
保留 10% 的内存容量给系统服务（内核，kubelet 等）。
在 95% 内存使用率的时候驱逐 Pod，来降低系统 OOM 的发生率。

所以我们用这样的参数启动 Kubelet：

--eviction-hard=memory.available<500Mi
--system-reserved=memory=1.5Gi

这个配置中隐含了一个设定就是，系统保留涵盖了驱逐标准。

要达到这一容量，可能是有的 Pod 使用了超出其请求的数量，或者系统占用了超过 500Mi。

这样的配置保证了调度器不会向即将发生内存压力的节点分配 Pod，避免触发驱逐。

DaemonSet

因为 DaemonSet 中的 Pod 会立即重建到同一个节点，所以 Kubelet 不应驱逐 DaemonSet 中的 Pod。

但是目前 Kubelet 无法分辨一个 Pod 是否由 DaemonSet 创建。如果/当 Kubelet 能够识别这一点，那么就可以先从驱逐候选列表中过滤掉 DaemonSet 的 Pod。

一般来说，强烈建议 DaemonSet 不要创建 BestEffort Pod，而是使用 Guaranteed Pod，来避免进入驱逐候选列表。

弃用的现存回收磁盘的选项

为了保证节点的稳定性，Kubelet 已经尝试来释放磁盘空间了。

因为基于磁盘的驱逐方式已经成熟，下列的 Kubelet 参数会被标记为弃用。

现有参数	新参数
–image-gc-high-threshold	–eviction-hard or eviction-soft
–image-gc-low-threshold	–eviction-minimum-reclaim
–maximum-dead-containers	弃用
–maximum-dead-containers-per-container	弃用
–minimum-container-ttl-duration	弃用
–low-diskspace-threshold-mb	–eviction-hard or eviction-soft
–outofdisk-transition-frequency	–eviction-pressure-transition-period

已知问题

Kubelet 无法及时观测到内存压力

Kubelet 目前从 cAdvisor 定时获取内存使用状况统计。如果内存使用在这个时间段内发生了快速增长，Kubelet 就无法观察到 MemoryPressure，可能会触发 OOMKiller。我们正在尝试将这一过程集成到 memcg 通知 API 中，来降低这一延迟，而不是让内核首先发现这一情况。

如果用户不是希望获得终极使用率，而是作为一个过量使用的衡量方式，对付这一个问题的较为可靠的方式就是设置驱逐阈值为 75% 容量。这样就提高了避开 OOM 的能力，提高了驱逐的标准，有助于集群状态的平衡。

Kubelet 可能驱逐超出需要的更多 Pod

这也是因为状态搜集的时间差导致的。未来会加入功能，让根容器的统计频率和其他容器分别开来（https://github.com/google/cadvisor/issues/1247）。

Kubelet 如何在 inode 耗尽的时候评价 Pod 的驱逐

目前不可能知道一个容器消耗了多少 inode。如果 Kubelet 觉察到了 inode 耗尽，他会利用 QoS 对 Pod 进行驱逐评估。在 cadvisor 中有一个 issue，来跟踪容器的 inode 消耗，这样我们就能利用 inode 进行评估了。例如如果我们知道一个容器创建了大量的 0 字节文件，就会优先驱逐这一 Pod

在 kubectl 中使用 Service Account Token

Thu, 11 May 2017 23:27:37 +0800

在运行基于 K8S 的 CI/CD 过程中，经常有需求在容器中对 Kubernetes 的资源进行操作，其中隐藏的安全问题，目前推荐的最佳实践也就是使用 Service Account 了。而调试账号能力的最好方法，必须是 kubectl 了。下面就讲讲如何利用 kubectl 引用 Servie Account 凭据进行 K8S 操作的方法。

这里用 default Service Account 为例。

假设

目前已经能对目标集群进行操作，文中需要的权限主要就是读取命名空间中的 Secret 和 Service Account。

准备配置文件

新建一个 Yaml 文件，命名请随意，例如 kubectl.yaml。内容：


apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: {ca data}
    server: https://{server}
  name: awesome-cluster
users:
- user:
    token: {token}
  name: account
- context:
    cluster: awesome-cluster
    user: account
  name: sa
current-context: sa

其中的 {ca data} 可以从现有连接凭据中获取。

{server}：服务器地址
{token}：将在后面设置

获取数据

首先查看 Service Account 的 Token 在哪里：

kubectl get serviceaccount default -o yaml

返回内容如下：

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2017-05-07T10:41:50Z
  name: default
  namespace: default
  resourceVersion: "26"
  selfLink: /api/v1/namespaces/default/serviceaccounts/default
  uid: c715217d-3311-11e7-a4ae-42010a8c0095
secrets:
- name: default-token-7h4bd

这里我们看到他包含了 secret: “default-token-7h4bd”，获取其中的内容：

kubectl get secret default-token-7h4bd -o yaml

apiVersion: v1
data:
  ca.crt: [ca data]
  namespace: ZGVmYXVsdA==
  token: [token data]
  kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: default
    kubernetes.io/service-account.uid: c715217d-3311-11e7-a4ae-42010a8c0095
  creationTimestamp: 2017-05-07T10:41:50Z
  name: default-token-7h4bd
  namespace: default
  resourceVersion: "24"
  selfLink: /api/v1/namespaces/default/secrets/default-token-7h4bd
  uid: c71cc72d-3311-11e7-a4ae-42010a8c0095
type: kubernetes.io/service-account-token

上面 Token Data 内容就是我们需要的认证 Token 了

export my_token="[tokendata]"
kubectl --kubeconfig=kubectl.yaml \
config set-credentials account \
--token=`echo ${tokendata} | base64 -D`

这样就把 Service Account 的 Token 取出来，并保存在 kubectl.yaml 中。利用这一配置文件就可以凭 Service Account 的身份来执行 kubectl 指令了。

kubeadm 安装 Kubernetes 1.6.2

Mon, 08 May 2017 19:20:39 +0800

因为一些莫可名状的原因，国内网络使用 Kubeadm 颇有难度，这里大概说一下过程中的一些坑。

主体流程遵循官网指南：https://kubernetes.io/docs/getting-started-guides/kubeadm/

¹⁄₄ 准备工作

这里用包管理的方式安装 kubeadm、Docker 等组件。需要注意一点点的是，如果用的非 Root 用户，要注意 sudo 的时候的环境代理设置问题。或者干脆在 apt/yum 的配置文件中写入代理服务器。

另外这里安装 Docker 之后，注意给 Docker 配置代理。或者可以直接想法子搞到下面列表中的镜像，并导入 Docker 之中：

镜像准备

下面提到的镜像基于目前的 1.6.2 版本，每次更新都会有不同。

Image	Ver	Component
gcr.io/google_containers/kube-proxy-amd64	v1.6.2	Kubernetes
gcr.io/google_containers/kube-controller-manager-amd64	v1.6.2	Kubernetes
gcr.io/google_containers/kube-apiserver-amd64	v1.6.2	Kubernetes
gcr.io/google_containers/kube-scheduler-amd64	v1.6.2	Kubernetes
gcr.io/google_containers/etcd-amd64	3.0.17	Kubernetes
gcr.io/google_containers/pause-amd64	3.0	Kubernetes
gcr.io/google_containers/k8s-dns-sidecar-amd64	1.14.1	DNS
gcr.io/google_containers/k8s-dns-kube-dns-amd64	1.14.1	DNS
gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64	1.14.1	DNS
gcr.io/google_containers/etcd	2.2.1	Calico
quay.io/calico/node	v1.1.3	Calico
quay.io/calico/cni	v1.8.0	Calico
quay.io/calico/kube-policy-controller	v0.5.4	Calico

²⁄₄ Master 初始化

kubeadm init

这里的几个问题：

如果准备采用 flannel 插件，需要 -pod-network-cidr 10.244.0.0/16 参数
Ubuntu 下可能会出现无限等待 Node 加入的情况，可能的原因是 /etc/resolv.conf 中有关于 localhost 的 search 记录，删掉这行就能解决。
如果准备采用 Calico 插件，那么要注意 Calico 的 YAML 中的 ip pool 跟集群设置一致。
如果不是预先准备好的备份，过程会比较长，耐心。。

Init 成功之后会出一堆文本信息，其中包含几点内容，最好保存下来：

自动生成的 kubectl config 文件，可以复制到 ~/.kube/config 中作为缺省 kubectl 使用。
把新节点加入集群的方法。

另外这里还有个提示——没有安装 Pod Network。

³⁄₄ 安装 Pod Network

这一步很重要，所有的应用包括 Kube DNS 在内，都依赖于此。

如上文所示，准备使用的是 Calico，这里值得注意的一坑是，不同版本的 Kubernetes 会有不同的 Calico 安装，1.6 版本应该使用的是：kubectl apply -f http://docs.projectcalico.org/v2.1/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml

http://docs.projectcalico.org/v2.1/getting-started/kubernetes/installation/hosted/kubeadm/ 还有一些其他的安装方式可以参考。

Calico 的注意事项

他的 ETCD 服务器要求装在 Master 所在的 Node 上，使用的是 nodeSelector 的方式，选择标签：node-role.kubernetes.io/master: ""。
上文提到的 pod network cidr 和 ip pool 的一致性问题
--service-cidr 和 IP Pool 不能重叠

⁴⁄₄ 加入节点

在其他 Node 上做好准备工作之后，用kubeadm init命令中提到的kubeadmin join方法加入集群。

Kubernetes 的高级调度

Sat, 06 May 2017 09:33:47 +0800

原文：Advanced Scheduling in Kubernetes

Kubernetes 的调度器能够满足绝大多数要求，例如保证 Pod 只在资源足够的节点上运行，会尝试把同一个集合的 Pod 分散在不同的节点上，还会尝试平衡不同节点的资源使用率等。

不过有时候你希望控制 Pod 的调度。例如你希望确认某个 Pod 只运行在有特定硬件的节点上；或者想要让频繁互相通信的服务能就近部署；又或者你希望用独立的节点给部分用户提供服务。而且最终，用户总是比 Kubernetes 更了解自己的应用。

所以 Kubernetes 1.6 提供了四个高级调度功能：

节点亲和/互斥
Taint（污染、变质）和 Tolerations（容忍、耐受）
Pod 的亲和/互斥
以及自定义调度

上述功能在 Kubernetes 1.6 中还属于 Beta 阶段。

节点亲和/互斥

节点的亲和和互斥是一种设置调度器选择节点的规则。这个规则是 nodeSelector（1.0 开始就有的功能）的衍生物。这一规则使用类似给 Node 添加自定义标签，在 Pod 中定义选择器的方式。规则在调度器中可以有必要和推荐两种级别。

必要的规则要求 Pod 必须调度到某指定节点上。如果没有符合条件（当然也包括通用的调度要求，例如节点必须有足够的资源）。如果没有符合要求的节点，Pod 就不会被调度，必要规则在 nodeAffinity 的 requiredDuringSchedulingIgnoredDuringExecution 字段中定义。

例如在一个 GCE 上的多区域 Kubernetes 集群中，我们希望把 Pod 运行在一个 us-central1-a 的区域中，我们可以在 Pod 中使用如下的亲和规则：


affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
          - key: "failure-domain.beta.kubernetes.io/zone"
            operator: In
            values: ["us-central1-a"]

IgnoredDuringExecution 表示在 Pod 已经成功运行后，如果 Node 的标签发生了变化导致其不再符合 Pod 的调度要求，Pod 依然会继续运行；requiredDuringSchedulingRequiredDuringExecution 则相反，一旦出现这种变化，他会立即从 Node 上驱逐 Pod。

推荐级别的规则表示优先选择符合规则要求的节点，如果找不到，则降级选择普通节点。我们可以用优先规则代替必要规则，选择us-central1-a进行 Pod 的运行，只要修改成preferredDuringSchedulingIgnoredDuringExecution：


affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
          - key: "failure-domain.beta.kubernetes.io/zone"
            operator: In
            values: ["us-central1-a"]

节点的互斥可以利用否定操作符来实现。所以如果让 Pod 避免运行在us-central1-a，可以这样实现：


affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
          - key: "failure-domain.beta.kubernetes.io/zone"
            operator: NotIn
            values: ["us-central1-a"]

可用的操作符包括：

In
NotIn
Exists
DoesNotExist
Gt
Lt

需要这一功能的场景还包括节点的硬件结构、操作系统版本或者特殊硬件等。节点的亲和与互斥在 Kubernetes 1.6 之中处于 Beta 阶段。

Taint（污染、变质）和 Tolerations（容忍、耐受）

这俩名词让我非常挠头，不好下嘴。

另外这里的阐述比起 Kubectl help taint 来说，清晰程度差了太多。

这一功能让用户可以把一个节点标记为 taint 的话，除非 Pod 被标识为可以耐受污染节点，否则不会有任何 Pod 被调度到该节点上。之所以把 taint 标记到节点而不是像亲和性一样标记在 Pod 上，是因为在这种情况下，绝大多数的 Pod 都不应该部署到 Taint 的节点上。例如用户可能希望把主节点保留给 Kubernetes 系统组件使用，或者把一部分节点保留给一组用户，或者把一组具有特殊硬件的服务器保留给有需求的 Pod。

可以用 kubectl 命令对节点进行 taint 操作：

kubectl taint nodes node1 key=value:NoSchedule

在节点上创建了一个 tiant，一个 Pod 必须在 Spec 中做出这样的 Toleration 定义，才能调度到该节点：


tolerations: 
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"

effect 除了 NoSchedule 这个值之外，还有一个 Prefer 版本的 PreferNoSchedule，另外还有一个 NoExecute 选项，这个选项意味着这一 Taint 生效之时，如果该节点内正在运行的 Pod 没有对应的 Tolerate 设置，会被直接逐出。

目前这一特性在 Kubernetes 1.6 升级为 Beta，我们加入了一个 Alpha 特性，可以指定在节点遇到问题的时候，该节点之上的 Pod 可以保持该绑定的时间长度（缺省五分钟）。

参考： https://kubernetes.io/docs/user-guide/node-selection/#per-pod-configurable-eviction-behavior-when-there-are-node-problems-alpha-feature

Pod 的亲和与互斥

Node 的亲和与互斥特性允许用户通过对 Pod 的定义来选择运行的 Node。但是还有一种需求就是，Pod 的相互关系，例如对同一个服务里面的 Pod 进行分布或者集中，或者和其他服务的 Pod 如何相处？Pod 的亲和与互斥就应运而生，这一特性在 Kubernetes 1.6 中也处于 Beta 阶段。

看一个例子。假设有一个叫 S1 的前端服务，会经常和一个叫 S2 的后端服务进行通信（南北通信模式），所以我们希望这两个服务能够被安排在同一个云服务区域，但是我们也不想做手工选择——一旦某个区域出了问题，我们希望这些 Pod 能够再次迁移到同一个区域。这里就可以定义 Pod 亲和性来达成这一目的了（假设我们给两组服务都设置 Label，service=s1/s2）：


affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: service
            operator: In
            values: ["S1"]
        topologyKey: failure-domain.beta.kubernetes.io/zone

和节点的亲和性类似，这里也有一个变量：preferredDuringSchedulingIgnoredDuringExecution。

Pod 的亲和性弹性很大。设想在性能测试的过程中，发现两个服务的容器处于同一个节点时，S1 的容器会干扰 S2 的容器的性能，这可能会是由缓存或者网络的拥堵造成的。或者出于安全考虑，我们不想两个服务共享同一个节点。要实现这种互斥操作，只要稍微改动一下哎上面的代码：

podAffinity 改为 podAntiAffinity
topologyKey 改为 kubernetes.io/hostname

自定义调度

如果 Kubernetes 调度器的众多特性还没能满足你的控制欲，可以用自己独立运行的调度器来对指定的 Pod 进行调度。在 Kubernetes 1.6 中，多调度器特性也进入了 Beta 阶段。

一般情况下，每个新 Pod 都会由缺省调度器进行调度。但是如果 Pod 中提供了自定义的调度器名称，那么缺省调度器就会忽略该 Pod，转由指定的调度器把该 Pod 分配给节点。下面举例说明。

代码中的 Pod 指定了schedulerName字段：


apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  schedulerName: my-scheduler
  containers:
  - name: nginx
    image: nginx:1.10

如果我们在不部署自定义调度器的情况下，创建这个 Pod，缺省调度器会忽略这个 Pod，后果是他会在Pending状态下停滞不前。所以我们需要为他创建一个schedulerName值为my-scheduler的调度器。

可以用任何语言来实现简单或复杂的调度器。下面的简单例子是用 Bash 实现的——随机指派一个节点。注意首先要运行kubectl proxy来支持这一脚本的运行。

#!/bin/bash
SERVER='localhost:8001'
while true;
do
    for PODNAME in $(kubectl --server $SERVER get pods -o json | jq '.items[] | select(.spec.schedulerName == "my-scheduler") | select(.spec.nodeName == null) | .metadata.name' | tr -d '"')
;
    do
        NODES=($(kubectl --server $SERVER get nodes -o json | jq '.items[].metadata.name' | tr -d '"'))
        NUMNODES=${#NODES[@]}
        CHOSEN=${NODES[$[ $RANDOM % $NUMNODES ]]}
        curl --header "Content-Type:application/json" --request POST --data '{"apiVersion":"v1", "kind": "Binding", "metadata": {"name": "'$PODNAME'"}, "target": {"apiVersion": "v1", "kind"
: "Node", "name": "'$CHOSEN'"}}' http://$SERVER/api/v1/namespaces/default/pods/$PODNAME/binding/
        echo "Assigned $PODNAME to $CHOSEN"
    done
    sleep 1
done

Kubernetes 1.6 的 release notes 中提供了更多的这些特性的相关信息，其中尤其包括了如果已经使用了 Alpha 版本如何进行升级的问题。

鸣谢

文中描写的功能，包括 Alpha 和 Beta 阶段的功能，都是社区中来自 Google、华为、IBM 以及 Red Hat 等公司的工程师的努力成果。

GlusterFS + Heketi 入门（非容器）

Wed, 19 Apr 2017 19:05:50 +0800

GlusterFS 是个开源的分布式文件系统，而 Heketi 在其上提供了 REST 形式的 API，二者协同为 Kubernetes 提供了存储卷的自动供给能力。

一般对这个系统的介绍，都是基于 Docker 的容器内完成的，个人爱好原因，还不太习惯把这个事情放到集群里面，所以介绍一下用 Yum 方式的安装过程。

我们使用三台服务器作为存储集群，操作系统为 CentOS 7。另外假设每台 Gluster FS 服务器挂在有名为 /dev/sdc 的裸设备，安装过程需要有互联网连接。

Heketi 服务器：10.211.55.31
Gluster 服务器：
- 10.211.55.31
- 10.211.55.32
- 10.211.55.33

Heketi 的安装和初始设置

这个很简单，CentOS 的 EPEL Repository 中就提供了他的安装包。

yum install -y heketi heketi-client

安装之后，会生成 Heketi 的 Service，建立 /etc/heketi，并在其中生成一个叫 heketi.json 的配置文件。这里提供一个样本：

{
  "port": "7070",
  "use_auth": false,
  "jwt": {
    "admin": {
      "key": "My Secret"
    },
    "user": {
      "key": "My Secret"
    }
  },
  "glusterfs": {
    "executor": "ssh",
    "sshexec": {
      "keyfile": "/etc/heketi/heketi_key",
      "user": "root",
      "port": "22",
      "fstab": "/etc/fstab"
    },
    "executor": "ssh",
    "db": "/var/lib/heketi/heketi.db",
    "loglevel": "debug"
  }
}

这个简单的配置文件说明：

在 7070 提供服务。
数据库保存在 /var/lib/heketi/heketi.db
关闭认证
利用 ssh 和 GlusterFS 集群成员进行通信
ssh 证书保存在 /etc/heketi/heketi_key

既然提到证书，就用 ssh-keygen 来生成一套：

ssh-keygen -t rsa -q -f /etc/heketi/heketi_key -N ''

后面将会使用这套证书来完成对 GlusterFS 的控制。

注意，这里要保证上面提到的数据库、配置以及证书文件，一定要确认 Heketi 用户有权进行访问。

GlusterFS 安装

启用仓库：yum install -y centos-release-gluster
安装软件：yum install -y glusterfs-server
启用服务：systemctl enable glusterfs-server
启动服务：systemctl start glusterfs-server

注意这里要把上个步骤生成的公钥（heketi_key.pub）加入到本机的信任列表中，例如

cat /tmp/heketi_key.pub >> /root/.ssh/authorized_key

集群初始化

Heketi 对存储的拓扑结构是这样的：

- Topology
    - Cluster a
        - Node a1
            - Device a11
            - Device a12
        - Node a2
    - Cluster b

所以初始化过程就按照从上到下的方式来进行：

建立集群

heketi-cli create cluster

创建成功后，会显示一个集群 ID。

加入 Node

heketi-cli node add --cluster=[clusterid] \
--management-host-name=[node-host] \
--storage-host-name=[node-host] \
--zone=1

运行成功会显示新加入的 Node 的 Node ID。

Add Node 过程失败可能需要查看一下防火墙

加入 Device

heketi device add \
--name=/dev/sdc
--host=[host-id]

自动一点

下面的脚本会把运行参数中指定的第一参数作为主机地址，第二参数作为设备名称加入第一个集群

#!/bin/sh
export HEKETI_CLI_SERVER=http://127.0.0.1:7070
CLUSTER_ID=`heketi-cli cluster list | tail -n 1 | xargs `
CLUSTER="--cluster=$CLUSTER_ID"
HOST="--management-host-name=$1 --storage-host-name=$1"
ZONE="--zone=1"
NODE_ID=`heketi-cli node add $CLUSTER $HOST $ZONE | grep -v -i "Cluster" | grep -i "id" | cut -d : -f 2 | xargs`
heketi-cli device add --name=$2 --node=$NODE_ID

命令需要用 ‘-s’ 开关指定操作的 Heketi 服务地址。可以用环境变量来简化一下： export HEKETI_CLI_SERVER=“http://127.0.0.1:7070"。

Topology

利用 heketi-cli topology info，会输出当前的集群结构。而且也可以用 JSON 格式导入和导出整个 Topology。下面的例子供参考：

{
    "volumes": [],
    "nodes": [{
      "zone": 1,
      "hostnames": {
        "manage": ["10.211.55.19"],
        "storage": ["10.211.55.19"]
      },
      "cluster": "f6e6de7dc99ca3ed627e2ab3ae68f9ac",
      "id": "95d3d4fec82be4d2a55ae0aa17344af5",
      "state": "online",
      "devices": [{
        "name": "/dev/sdc",
        "storage": {
          "total": 33419264,
          "free": 33419264,
          "used": 0
        },
        "id": "e4e1b97d38ed5ae70323458c1b8e57b5",
        "state": "online",
        "bricks": []
      }]
    }, {
      "zone": 1,
      "hostnames": {
        "manage": ["10.211.55.21"],
        "storage": ["10.211.55.21"]
      },
      "cluster": "f6e6de7dc99ca3ed627e2ab3ae68f9ac",
      "id": "ab36d04dbface40904a05c33f3fd9800",
      "state": "online",
      "devices": [{
        "name": "/dev/sdc",
        "storage": {
          "total": 33419264,
          "free": 33419264,
          "used": 0
        },
        "id": "a33dee6fd8355c6aa9ff5e2783ecef49",
        "state": "online",
        "bricks": []
      }]
    }, {
      "zone": 1,
      "hostnames": {
        "manage": ["10.211.55.20"],
        "storage": ["10.211.55.20"]
      },
      "cluster": "f6e6de7dc99ca3ed627e2ab3ae68f9ac",
      "id": "bfd478cb0a0a562386c06967fb2b31bc",
      "state": "online",
      "devices": [{
        "name": "/dev/sdc",
        "storage": {
          "total": 33419264,
          "free": 33419264,
          "used": 0
        },
        "id": "24c5a97ccad5b3fc35977bc7419c27ee",
        "state": "online",
        "bricks": []
      }]
    }],
    "id": "f6e6de7dc99ca3ed627e2ab3ae68f9ac"
  }]
}

Kubernetes 中的 RBAC 支持

Sun, 09 Apr 2017 08:29:17 +0800

原文：RBAC Support in Kubernetes

RBAC vs ABAC

目前 Kubernetes 中有一系列的鉴权机制

鉴权的作用是，决定一个用户是否有权使用 Kubernetes API 做某些事情。它除了会影响 kubectl 等组件之外，还会对一些运行在集群内部并对集群进行操作的软件产生作用，例如使用了 Kubernetes 插件的 Jenkins，或者是利用 Kubernetes API 进行软件部署的 Helm。ABAC 和 RBAC 都能够对访问策略进行配置。

ABAC（Attribute Based Access Control）本来是不错的概念，但是在 Kubernetes 中的实现比较难于管理和理解（怪我咯），而且需要对 Master 所在节点的 SSH 和文件系统权限，而且要使得对授权的变更成功生效，还需要重新启动 API Server。

而 RBAC 的授权策略可以利用 kubectl 或者 Kubernetes API 直接进行配置。RBAC 可以授权给用户，让用户有权进行授权管理，这样就可以无需接触节点，直接进行授权管理。RBAC 在 Kubernetes 中被映射为 API 资源和操作。

因为 Kubernetes 社区的投入和偏好，相对于 ABAC 而言，RBAC 是更好的选择。

基础概念

需要理解 RBAC 一些基础的概念和思路，RBAC 是让用户能够访问 Kubernetes API 资源的授权方式。

在 RBAC 中定义了两个对象，用于描述在用户和资源之间的连接权限。

角色

角色是一系列的权限的集合，例如一个角色可以包含读取 Pod 的权限和列出 Pod 的权限， ClusterRole 跟 Role 类似，但是可以在集群中到处使用（ Role 是 namespace 一级的）。

角色绑定

RoleBinding 把角色映射到用户，从而让这些用户继承角色在 namespace 中的权限。ClusterRoleBinding 让用户继承 ClusterRole 在整个集群中的权限。

关于 RoleBinding 和 ClusterRoleBinding

Kubernetes 中的 RBAC

RBAC 现在被 Kubernetes 深度集成，并使用他给系统组件进行授权。系统角色 (System Roles) 一般具有前缀system:，很容易识别：

➜  kubectl get clusterroles --namespace=kube-system
NAME                    KIND
admin                   ClusterRole.v1beta1.rbac.authorization.k8s.io
cluster-admin           ClusterRole.v1beta1.rbac.authorization.k8s.io
edit                    ClusterRole.v1beta1.rbac.authorization.k8s.io
kubelet-api-admin       ClusterRole.v1beta1.rbac.authorization.k8s.io
system:auth-delegator   ClusterRole.v1beta1.rbac.authorization.k8s.io
system:basic-user       ClusterRole.v1beta1.rbac.authorization.k8s.io
system:controller:attachdetach-controller ClusterRole.v1beta1.rbac.authorization.k8s.io
system:controller:certificate-controller ClusterRole.v1beta1.rbac.authorization.k8s.io
...

RBAC 系统角色已经完成足够的覆盖，让集群可以完全在 RBAC 的管理下运行。

在 ABAC 到 RBAC 进行迁移的过程中，有些在 ABAC 集群中缺省开放的权限，在 RBAC 中会被视为不必要的授权，会对其进行降级。这种情况会影响到使用 Service Account 的负载。ABAC 配置中，从 Pod 中发出的请求会使用 Pod Token，API Server 会为其授予较高权限。例如下面的命令在 APAC 集群中会返回 JSON 结果，而在 RBAC 的情况下则会返回错误。

➜  kubectl run nginx --image=nginx:latest
➜  kubectl exec -it $(kubectl get pods -o jsonpath='{.items[0].metadata.name}') bash
➜  apt-get update && apt-get install -y curl
➜  curl -ik \
-H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
https://kubernetes/api/v1/namespaces/default/pods

降级过程的说明

所有在 Kubernetes 集群中运行的应用，一旦和 API Server 进行通信，都会有可能受到迁移的影响。

要平滑的从 ABAC 升级到 RBAC，在创建 1.6 集群的时候，可以同时启用 ABAC 和 RBAC。当他们同时启用的时候，对一个资源的权限请求，在任何一方获得放行都会获得批准。然而在这种配置下的权限太过粗放，很可能无法在单纯的 RBAC 环境下工作。

RBAC 和 ABAC 同时运行

在 Google Cloud Next 上的两次讲话提到了 Kubernetes 1.6 中的 RBAC。要获得更详细的信息，请阅读 RBAC 文档。

https://www.youtube.com/watch?v=Cd4JU7qzYbE#t=8m01s

https://www.youtube.com/watch?v=18P7cFc6nTU#t=41m06s

https://kubernetes.io/docs/admin/authorization/rbac/

编写易移植的 PVC

Fri, 31 Mar 2017 06:33:10 +0800

原文：Writing Portable Configuration

如果你在编写配置模板或者是一个可能在很多不同集群下运行的配置，要在其中包含持久存储，我们提供一些建议：

在配置包含 PVC 对象（和 Deployments、COnfigMap 等并列）。
考虑到可能的权限限制，建议不要包含 PV 对象
编写模板的话，建议给用户指定 Storage Class 的选项：
- 如果用户提供了一个 Storage Class，并且集群版本在 1.4 以上，把这个 Storage Class Name 放入 PVC 的 volume.beta.kubernetes.io/storage-class 标注之中，如果集群中启用了指定的 Storage Class，PVC 就会成功匹配到相应资源。
- 如果用户没有提供 Storage Class，或者集群版本为 1.3，那么就在 PVC 中添加 volume.alpha.kubernetes.io/storage-class: default 标注。
- PV 会自动在集群中为用户提供平台指定的缺省 PV。
- 虽然字面上是 alpha，但实际上提供的是 beta 级别的支持。
- 不要使用volume.beta.kubernetes.io/storage-class，任何值包括空字符串，都会阻止 DefaultStorageClass 控制的运行。
如果 PVC 创建一段时间之后，还没能绑定，需要把这一信息呈现给用户，因为这可能是因为这个集群没有动态存储供给的支持（这种情况下，需要创建符合 PVC 要求的 PV），或者个集群没有存储系统（这种情况下就无法运行指定的 PVC 了）。
未来我们希望让多数集群具备 DefaultStorageClass，并有提供某种可用的存储。然而，让一种 Storage Class 适应所有的集群是很难的，所以还是不建议直接在 PVC 中设置缺省的 Storage Class。Alpha 标注会在未来失效，但那时候未进行设置的 storageClass 字段就会实现期望的功能了（1.6）。

Helm 简介

Thu, 30 Mar 2017 08:47:48 +0800

概念

Chart：一个 Helm 包，其中包含了运行一个应用所需要的工具、资源定义等，还可能包含 Kubernetes 集群中的服务定义，类似 Homebrew 中的 formula，APT 的 dpkg 或者 Yum 的 RPM 文件，
Release: 在 Kubernetes 集群上运行的 Chart 的一个实例。在同一个集群上，一个 Chart 可以安装很多次。每次安装都会创建一个新的 release。例如一个 MySQL Chart，如果想在服务器上运行两个数据库，就可以把这个 Chart 安装两次。每次安装都会生成自己的 Release，会有自己的 Release 名称。
Repository：用于存放和共享 Chart 的仓库。

简单说来，Helm 整个系统的主要任务就是，在仓库中查找需要的 Chart，然后把 Chart 以 Release 的形式安装到 Kubernetes 之中

组件

Helm Client：客户端，具有对 Repository、Chart、Release 等对象的管理能力。
Tiller Server：负责客户端指令和 Kubernetes 集群之间的沟通，根据 Chart 定义，生成和管理各种相对应的 API Object。
Repository：Chart 的仓库，基本上就是索引文件 + Chart 压缩包的一个存储托管。

安装

环境要求

可用的 Kubernetes 集群
正确的可用的 kubectl config

简单做法

只要一个简单的 helm init 命令，就可以自动完成 Tiller 的安装，以及 Helm 本地设置。

手工做法

在一个网络不通，或者受控网络里面，init 可能无法正常工作，所以我们需要手工完成 Init 工作。

客户端：helm init -c，会跳过 Tiller 部分，仅进行客户端的安装。
- ~/.helm 中保存了对 Repository 的定义，各个 Repository 的索引的缓存，以及 Chart 压缩包的缓存。

Tiller：下面是 Tiller 的运行 YML：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
generation: 1
labels:
app: helm
name: tiller
name: tiller-deploy
namespace: kube-system
spec:
replicas: 1
selector:
matchLabels:
  app: helm
  name: tiller
strategy:
rollingUpdate:
  maxSurge: 1
  maxUnavailable: 1
type: RollingUpdate
template:
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
spec:
  containers:
  - env:
    - name: TILLER_NAMESPACE
      value: kube-system
    image: gcr.io/kubernetes-helm/tiller:v2.2.3
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 3
      httpGet:
        path: /liveness
        port: 44135
        scheme: HTTP
      initialDelaySeconds: 1
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 1
    name: tiller
    ports:
    - containerPort: 44134
      name: tiller
      protocol: TCP
    readinessProbe:
      failureThreshold: 3
      httpGet:
        path: /readiness
        port: 44135
        scheme: HTTP
      initialDelaySeconds: 1
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 1
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  securityContext: {}
  terminationGracePeriodSeconds: 30

Service

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: 2017-03-27T15:06:49Z
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  clusterIP: 10.3.251.197
  ports:
  - name: tiller
    port: 44134
    protocol: TCP
    targetPort: tiller
  selector:
    app: helm
    name: tiller
  sessionAffinity: None
  type: ClusterIP

注意楼上的 Service 代码表明 Tiller 并没有用 NodePort 或者 Ingress/Loadbalancer 等方式暴露端口，因此这里推测 Helm 同 Tiller 的通信可能是利用 kubectl proxy 完成的。

常用操作

下面列举了一个简单的安装数据库的操作过程：

helm search mysql #搜索
helm inspect stable/mariadb #查看
helm install stable/mariadb #安装

很明显，上面的命令没有对 Chart 的而运行做任何指导，实际上没什么用，我们可以利用 --set 或者 --value 参数，来指定在我们 Inspect 命令中看到的变量的值，就可以完成对变量的设置了。

除了利用简单的模板功能来生成和控制 pvc/secret 等各种对象之外， Chart 还具有很重要的依赖管理功能。

自建 Chart

简单的一个 helm create 命令就可以初始化一个 chart。

├── Chart.yaml # Chart 的文件主要信息
├── charts # 依赖的 Chart
├── templates # 模板目录，用 gotpl 编写 Kubernetes 运行 App 所需的各种对象定义
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml # 缺省值定义

编写完成之后，使用 helm package 命令可以将 chart 打包为 tgz 格式。

最后可以运行 helm install ./some.chart.tgz 来运行本地的 Chart。

自建 Repository

很明显的，我们需要一个自建仓库，不过幸运的是，Helm 仓库并不像 Docker Image Registry 之类的东西那么麻烦。只要一个能相应 GET 请求并提供 YAML 和 TAR 文件的 HTTP 服务器就可以了。

最简单的，可以用 helm serve 命令就可以了：

首先创建一个文件夹用于保存 Chart
把上面我们 helm package 生成的压缩包复制进去
helm serve --repo-path repo 就会运行一个简单的 HTTP Server 提供 Helm chart 仓库的服务了。
运行helm repo add some-repo http://repo-url 命令，添加仓库到系统中。

另外可以利用 github 以及各种 HTTP 服务器来提供这一服务。

简单的 Kubernetes Pod 日志查看工具 Kubetail

Sat, 11 Mar 2017 01:47:52 +0800

传统来说，Kubernetes 环境下的日志都是靠 FluentD + ElasticSearch + Kibana 的组合实现的，这一组合的功能和强大，所以成为一个事实标准来使用，但是在一些比较简陋的测试集群中，或者不具备浏览器条件的自动化/控制台环境下，归并多个 Pod 的日志进行集中的查看和处理还是很有用的。

Kubetail 是一个 Bash 脚本，功能类似 kubectl -f logs pod-name，但是不同的是，他同时对多个 Pod 工作，并把日志合并到一个流中。

项目网址：github

安装

只是个脚本，可以直接下载安装。

Mac 用户：

brew tap johanhaleby/kubetail && brew install kubetail

使用

kubetail [-h] [-c] [-n] [-t] [-l] [-s] pod-name-prefix

-c：多容器 Pod 中，指定容器名称
-t：指定 kube config 文件中的 context
-l：标签过滤器，使用 -l 参数之后，会忽略后面的 pod 名称
-n：namespace
-s：只返回一个相对时间之后的日志，例如 5s，2m 或者 3h，缺省是 10s
-b：是否使用 line-buffered。缺省为 false
-k：输出的着色
pod：只给 pod 名称上色
line：整行上色（缺省）
false：不上色

借助 Calico，管窥 Kubernetes 网络策略

Thu, 09 Mar 2017 20:37:41 +0800

Kubernetes 提出了一系列 CXI 的标准容器接口，其中的 CNI 以插件方式支持多种网络。新增的 networkpolicy API 对象，提供了对网络策略的支持，本文以 Calico 为例，实际操作一个网络策略的创建和测试。

环境准备

一个 Kubernetes 集群
Kubelet 和 API Server 都开启了 --allow_privileged=true
Kubelet 指定使用 CNI ：--network-plugin=cni
为了避免某些不可描述的网络设施的影响，建议下载几个镜像
- quay.io/calico/node:v1.0.2
- calico/cni:v1.5.6
- calico/kube-policy-controller:v0.5.2
- calico/ctl:v1.0.2

运行 Calico

下载 http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/calico.yaml
如果用私库镜像，需要修改其中的几个镜像地址
修改 data/etcd_endpoints 的数据为可访问的 etcd 的地址。

kubectl create -f calico.yaml

这里在 kube-system 中创建了一个 DaemonSet 和一个 Deployment，分别用于提供 CNI 支持和网络策略支持。

$ kubectl get deployment,daemonset,svc --all-namespaces                                          [9:55:14]
NAMESPACE     NAME                              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kube-system   deploy/calico-policy-controller   1         1         1            1           10h

NAMESPACE     NAME             DESIRED   CURRENT   READY     NODE-SELECTOR   AGE
kube-system   ds/calico-node   2         2         2         <none>          10h

NAMESPACE   NAME             CLUSTER-IP        EXTERNAL-IP   PORT(S)   AGE
default     svc/kubernetes   172.200.0.1       <none>        443/TCP   19h
default     svc/nginx        172.200.183.204   <none>        80/TCP    9h

网络策略

为测试效果，我们首先创建一个 Namespace

kubectl create ns policy

然后是 Nginx 部署和服务：

---
kind: ReplicationController
apiVersion: v1
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  replicas: 1
  selector:
    name: nginx
  template:
    metadata:
      labels:
        name: nginx
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          protocol: TCP

---
kind: Service
apiVersion: v1
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  selector:
    name: nginx

然后我们用 alpine 镜像测试一下对这一服务进行访问：

kubectl run alpine --rm -it --image=alpine sh

运行成功后，在 Alpine 的 Shell 中输入：

wget -O - -T 5 http://nginx

会出现 Nginx 的缺省页面的代码。

接下来我们给 Default Namespace 加一个缺省拒绝访问的注解：

$ kubectl annotate ns default "net.beta.kubernetes.io/network-policy={\"ingress\": {\"isolation\": \"DefaultDeny\"}}"

重复测试过程，会发现超时错误。

我们来创建一条策略：

kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      run: nginx
  ingress:
    - from:
      - podSelector:
          matchLabels:
            access: "true"

很容易理解，对于符合 “run=nginx” 的 Pod，只有 “access=true” 的 Pod 能够访问

给 Alpine 带上标签重新运行：

kubectl run alp --image=alpine --labels="access=true" --rm -ti sh

重新 wget，会发现访问能力已经恢复。

本文主要线索来自官方示例：https://kubernetes.io/docs/getting-started-guides/network-policy/walkthrough/

安装方法来自 Calico 官网。

这只是一个很入门的介绍，后续会有更多进一步的尝试。

Jenkins：乘着 Kubernetes 的翅膀

Thu, 09 Mar 2017 07:38:10 +0800

前言

Kubernetes + Docker 是一对有意思的组合，为微服务架构的落地，扫清了最后一公里的障碍，在符合企业 IT 治理需求的前提之下，为传统企业应用的平滑过渡提供了有效条件和方法。

作为软件生产环节中重要组成部分的持续构建和发布过程，自然也要随势而动，这方面的老将 Jenkins 不但提供了用于构建、推送 Docker 镜像的插件，更提供了利用 Kubernetes 运行构建集群的能力。本文将利用一个简单的 Hello world 项目，来展示 Jenkins 的这一特性。

准备工作

Kubernetes 集群安装

要在 Kubernetes 集群完成下面所有的工作，因此首先进行集群的安装和配置，这方面可以参考官方入门文档，如果英语不灵但动手排错能力强的话，也可以参考已经过时的拙作。

集群安装后，应该具有以下能力：

集群具有受 DNS 支持的服务寻址能力；
能够利用 Kubectl 或者其他方法发布容器应用的能力；
私有镜像库，或者到 Docker Hub 的网络连接；
Pause 镜像也自然是 Kubernetes 中运行应用的必须条件。

Jenkins 镜像

本文例子采用自制的一个集成镜像为基础工具，该镜像集成了众多常用的 CI/CD 工具，另外同时还包含了 Jenkins 的 Master 和 Slave 两种模式，镜像托管在 Docker Hub，源码可在 Github 浏览和下载。

如果具有直接连接 Docker Hub 的网络连接，则可无需理会；否则就需要下载镜像，并上传至私库。为行文方便，这里假设采用私库方式，镜像地址为 10.211.55.5:5000/jenkins:2.7.4.5

共享存储

因容器在集群中的运行状况未知，一般来说是需要为容器化应用提供共享存储服务的，本文中采用最简单的 NFS 方式，当然也可以使用官方支持的其他方式，例如 GlusterFS、Flocker 以及 Ceph 等等，具体支持能力可以参看官方说明，当然，如果只是学习测试，使用缺省的 Empty 格式亦可，或者偷懒使用 HostPath 方式结合限定 Node 运行的方式也能够完成任务。

本文中的卷挂载方式很是粗糙，目前推荐的共享存储方式是持久卷（PV & PVC）方式，以提供更好的管控能力，中文可参考：Kubernetes 中的 Persistent Volumes。

Jenkins Master

YAML

首先要为我们的 Jenkins 镜像编写一个 Yaml ，用于提交到集群中运行：

kind: ReplicationController
apiVersion: v1
metadata:
  name: jenkins
  labels:
    name: jenkins
spec:
  replicas: 1
  selector:
    name: jenkins
  template:
    metadata:
      labels:
        name: jenkins
    spec:
      containers:
      - name: jenkins
        image: 10.211.55.5:5000/jenkins:2.7.4.5
        ports:
        - containerPort: 8080
          protocol: TCP
        - containerPort: 8081
          protocol: TCP
        volumeMounts:
          - name: jenkins
            mountPath: /data/jenkins
      volumes:
      - name: jenkins
        nfs:
          server: 10.211.55.5
          path: /var/data/nfs/ci/jenkins
          readOnly: false
---
kind: Service
apiVersion: v1
metadata:
  name: jenkins
  labels:
    name: jenkins
spec:
  type: NodePort
  ports:
  - protocol: TCP
    nodePort: 32502
    targetPort: 8080
    port: 8080
    name: web
  - protocol: TCP
    targetPort: 8081
    port: 8081
    name: service
  selector:
    name: jenkins

上面的 YML 文件有几点需要注意

挂载：Jenkins 的所有插件、配置和工作文件都处于环境变量 JENKINS_HOME 所示的路径中，因此我们这里利用 NFS 把位于 10.211.55.5 上的 /var/data/nfs/ci/jenkins 目录映射到容器的 /data/jenkins 之中，让 Jenkins 获得持久化存储。
端口：Jenkins 缺省运行需要 8080 端口对外提供 Web 界面。这里我们另外声明了一个 8081 端口，为集群内新建的 Slave 提供通信能力，可以看到，下面的 Service 定义中，仅仅使用 NodePort 方式暴露了一个 Web 端口
时区：镜像提供了 TIMEZONE 环境变量，这一变量将会在运行时影响容器操作系统以及 Jenkins 的 JVM 的时区设置。这一变量缺省使用 Asia/Shanghai。
JENKINS_MODE：用于指示 Jenkins 的运行模式，可选值为 MASTER 或者 SLAVE，缺省运行在 MASTER 模式下。

运行和配置

接下来就可以使用 kubectl create -f jenkins.yaml 来运行镜像了。执行之后可以刷 kubectl get pods 来查看启动情况。

这一 RC 的启动需要加载 NFS 卷，因此如果启动时间过长，可以使用 kubectl get events 命令查看是否加载出了问题。

Pod 变为 Running 状态之后，就可以尝试采用上面 YAML 中定义的 Node Port 来访问 Jenkins 界面了，经过一段时间的 "Jenkins正在启动，请稍后....."，系统要求输入 /data/jenkins/secrets/initialAdminPassword 文件中保存的初始密码，假设前面 get pods 命令得到的 Pod 名称是 jenkins-7nmka，这里就可以使用 kubectl exec jenkins-7nmka cat /data/jenkins/secrets/initialAdminPassword 来查看，获取结果后即可复制黏贴到录入框中继续安装。

接下来的插件安装，为节省时间直接 Select None。接下来设置管理员用户名密码，保存后，安装结束。

安装和配置 Kubernetes 插件

安装

接下来就是进入 pluginManager/available 页面安装插件。

如果网络需要代理，可以进入网址 /pluginManager/advanced，设置代理服务器。如果可选插件页面为空，可以在 /pluginManager/advanced 页面里面点击 “立即获取” 按钮进行刷新。

过滤框中输入 “kubernetes” 会看到列表中的 “Kubernetes plugin”，选择安装。

配置 Jenkins

安装成功后，进入配置页面（/configure）。

首先为了测试方便，我们把 “执行者数量” 设置为 0，也就是说只使用 Jenkins Slave 进行构建。

配置 Kubernetes

可以看到，页面下方有一个按钮 “新增一个云”，点击后出现 Kubernetes 配置项目。

这里我们用无认证的 http 方式进行连接，Kubernetes URL 中填入 API Server 的 http 地址，例如：http://10.211.55.5:8080。

Jenkins URL 中，这里要注意我们不应该使用浏览器地址栏中的 Node 地址，而是应该使用集群内部的服务地址，根据上文中 Service 的定义，这里使用 http://jenkins:8080。

最后是 ”Add Pod Template“ 按钮，来定义 Slave 的 Pod 模板：

这里的 “Docker Image” 项目跟上面使用的是同一个地址，也就是 10.211.55.5:5000/jenkins:2.7.4.5；
根据前文说道的环境变量，这里我们新增一个环境变量：JENKINS_MODE=SLAVE，
“Jenkins slave root directory” 这一项填写 /data/jenkins，
“Command to run slave agent ” 这里填写镜像中的启动命令 /usr/local/bin/run.sh

填写完成后，保存。

配置端口

最后需要到安全配置页面（/configureSecurity），TCP port for JNLP agents 一项填写固定端口 8081。

Hello world

创建

新建一个 Free Style 项目。构建步骤中新增 “Execute shell script” 环节，并保存，内容为

echo "Hello World"

构建

点击该任务的 “立即构建” 按钮，即可触发构建动作。

因为前面我们设置 Master 不执行构建工作，所以在构建启动之后，会在构建执行状态中看到有节点被动态新建，来执行我们的构建过程。这一过程中如果使用 kubectl get events 或者 kubectl get pods 命令，能看到 Jenkins Slave Pod 的创建、执行和销毁过程。

尾声

上面只是一个最为基础的构建过程，甚至都无法称为是一个完整过程，Kubernetes 插件还提供了很多其他选项，结合自定义的 Slave 镜像，能够完成更多更复杂的任务，用于配合实际的生产过程。

Kubernetes 集群资源的那些事

Wed, 08 Mar 2017 05:38:56 +0800

大多数时候，我们在跟 K8S 玩耍的时候，主要目的就是：“把 XXX 打个镜像，在集群上跑起来 ——— 诶快看，真的跑起来了嘿！”。

Kubernetes 和 Docker 的缺省配置，就能够帮我们省却很多麻烦。不过大家都很清楚，资源问题是无法回避的，我们在传统 IT 环境下遇到的各种资源相关问题，在容器集群环境下一样要得到解决，多租户动态分配环境下，这些问题会更加复杂。

本文仅是一个索引，不准备也没能力做过多的深入，只是将一些需要注意的内容罗列出来做一些大致介绍。有些内容称作资源可能并不是很恰当，暂时存在资源这个筐里吧。

磁盘

Volume

一般我们会用存储卷的方式来给 Pod 提供存储资源。

起初的存储卷，在用量的控制方面，只能借存储的实际提供者的能力来进行。例如可以限制 GlusterFS 中 Volume 的大小。

接下来出现了 Persistent Volume (PV) 和 Persistent Volume Claim (PVC) 这一组对象，完成了 “生产——消费” 关系，这就可以通过 Provision -> Claim 的方式，来对存储资源进行控制。

而最新版本中还出现了动态卷供给的功能，能够对这一部分功能进行简化，无需首先建立 PV，直接建立 PVC 即可。

有了 PVC 这一能力之后，Kubernetes 就借用这一对象对 Namespace 的存储访问进行了限制：

对象名称	解释
requests.storage	所有的 PVC 申请容量之和不能超过此数值
persistentvolumeclaims	一个 Namespace 中 PVC 的总数（Count）
`<storage-class-name>.storageclass.storage.k8s.io/requests.storage`	所有针对该 StorageClass 的 PVC 所申请的存储总容量不得超出这一数值
`<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims`	所有针对该 StorageClass 最多能创建的 PVC 数量

日志

目前我们在实际使用中，爆磁盘的原因，除了对存储卷的控制不够之外，还有一个重要的点就是容器的日志，缺省情况下 Docker 使用的日志驱动是 json-file，这一驱动有个附加参数 --log-opt max-size=[size] 可以用来限制日志的最大占用空间。

Docker 官方文档还提供了很多其他的日志选项供选择。

Node

除了上面讲到的集群层面的问题之外，磁盘空间还对 Node(Kubelet) 的健康有重大影响。Kubelet 有几个参数用于对存储使用进行控制：

--low-diskspace-threshold-mb：如果剩余空间低于这一限制，则拒绝在这一 Node 上新建 Pod（目前建议用新的驱逐规则来代替这一参数）。
--image-gc-high-threshold：高于该值则启动 GC。
--image-gc-low-threshold：低于该值拒绝启动 GC。

在驱逐策略中，提供了如下几个磁盘相关的参数：

nodefs.available
nodefs.inodesFree
imagefs.available
imagefs.inodesFree

这里把 Node 磁盘分为 node 和 image 两种分别度量其 available 和 inodes，应该说比上面的 threshold 更加精确了

CPU 和内存

这一对资源应该算是 Kubernetes 中的 “经典” 资源了。Kubernetes 对 CPU 和内存提供了 requests/limits 两种度量，可以在 Container 的 Spec 中进行指定。

在 namespace 一级中，提供了如下的总量限制：

limits.cpu：所有非结束状态的 Pod 的 CPU limit 总数。
limits.memory：所有非结束状态的 Pod 的内存 limit 总数。
requests.cpu：所有非结束状态的 Pod 的 CPU request 总数。
requests.memory：所有非结束状态的 Pod 的 CPU request 总数。

Node

和前面的磁盘的情况类似，Kubelet 中对 CPU 和内存也有新旧两套切换中的体系来进行限制：

--kube-reserved

驱逐策略中提供了如下参数：

memory.available

quota 和 limitrange

这是两个不同的 API Object，分别对应 namespace 的配额，和运行应用(Pod/Container)的资源限制。

GPU

这方面基本没有接触，但是随着深度学习之类名词的迅速炒热，相信 Kubernetes 会快速跟进的。

将在 1.6 中推出多 GPU 支持的 Alpha 版本。

网络

在 1.5 中，网络策略已经成为 Beta 版本，利用这一对象，横向可以实现 namespace 之间的隔离；纵向可以定义 namespace 内不同职责应用的网络访问能力。这就有效的阻断了不同租户之间利用 dns 进行授权之外的访问的途径。

参考资料：

网络策略：https://kubernetes.io/docs/user-guide/networkpolicies/
驱逐策略：http://blog.fleeto.us/translation/configuring-out-resource-handling
存储：
- http://blog.fleeto.us/translation/dynamic-provisioning-and-storage-classes-kubernetes
- http://blog.fleeto.us/translation/persistent-volumes

Linkerd + Namerd，实现 Kubernetes 集群的灰度发布

Tue, 14 Feb 2017 06:42:02 +0800

主要内容源于 https://blog.buoyant.io/2016/11/04/a-service-mesh-for-kubernetes-part-iv-continuous-deployment-via-traffic-shifting/ ，砍掉了 Jenkins 等附加部分，更换了更加易于理解的示例应用，以保证主干突出。

Kubernetes 所提供的 rolling-update 功能提供了一种渐进式的更新过程，然而其滚动过程并不容易控制，对于灰度发布的需要来说，仍稍显不足，这里介绍一种利用 Linkerd 方案进行流量切换的思路。

官网介绍：linker∙d is a transparent proxy that adds service discovery, routing, failure handling, and visibility to modern software applications。

本文从实际操作入手，上线两个版本的简单应用，利用这一组合完成流量的切换和测试过程。

测试目标

同时上线两个版本的应用。两个应用均可工作，利用不同输出进行区分。
动态调整分配给两个版本的流量。
利用 CURL 进行流量分配的测试。

准备工作

这里利用一个 1.2 以上版本的 Kubernetes 集群进行演示：

API Server / Registry：10.211.55.62
Node：10.211.66.63

另外因某些原因，需要有能力获取 Dockerhub 的镜像。

例子程序很简单，用一个 PHP 文件显示环境变量中的内容：

<?php
echo getenv("VAR_LABEL");

Docker file 继承自 dustise/lamp:latest，文件内容如下：

FROM dustise/lamp
COPY index.php /web/codebase

利用 Docker build 创建镜像，这里命名为 lamp:gray，备用。

创建工作负载

做一个简单的 yaml 文件来加载蓝绿两组应用，名字、环境变量和端口三个位置需要更改：

---
kind: ReplicationController
apiVersion: v1
metadata:
  name: green
# 此处省略若干
        env:
        - name: VAR_LABEL
          value: 'green'
---
kind: Service
apiVersion: v1

# 此处省略若干

  type: NodePort
  ports:
  - protocol: TCP
    nodePort: 32001
    port: 80
    targetPort: 80
    name: http
  selector:
    name: green

利用 kubectl create -f green.yaml （以及 blue.yaml ）之后，可以利用 curl 或者浏览器检查运行情况，如果正常，两个端口的访问应该分别会返回 green 和 blue ，这里的端口命名很重要，这一名称会被后面的规则引用到。

注意，这里 NodePort 并非必须，仅为测试方便。

运行 Namerd

此处 yaml 主要来自于官网 https://raw.githubusercontent.com/BuoyantIO/linkerd-examples/master/k8s-daemonset/k8s/namerd.yml 为适应本地环境，将原有 Loadbalancer 类型的服务改为 NodePort

略微做一下讲解。

整个 yaml 由四部分组成：

ThirdPartyResource

这部分被用于做 Namerd 的存储后端。

Configmap

作为 Namerd 的配置，其中定义了这样几个内容（详情可参见 https://linkerd.io/config/0.8.5/namerd/index.html#introduction）：

管理端口 9990
storage：存储定义，通过 8001 端口同 Kube Api Server 通信，完成在 ThrdPartyResource 中的访问（8001 端口由 kubectl proxy 指令开通）
namer：定义服务发现能力由 Kubernetes 提供。
interface 部分则是定义了两种支持协议。其中 HTTP Controller 可以接收 namerctl 的控制指令。

RC

这部分不新鲜，除了 namerd 之外，还利用 kubectl proxy 提供通信端口给 namerd，颇有蛇足之嫌。正确的打开方式应该是直接和 Kube API Server 进行通信。

Service

这里注意服务类型的变更（ LoadBalancer -> NodePort ），需要暴露 4180 和 9990 两个端口，分别作为控制端口和界面端口。

利用 kubectl 启用之后，就可以在指定的端口查看管理界面了。此时的管理界面没有做任何配置，因此比较单薄。

添加规则

下面来安装 namerd 的控制工具，namerctl

go get -u github.com/buoyantio/namerctl
go install github.com/buoyantio/namerctl

接下来创建一条规则：

/host=>/#/io.l5d.k8s/default/http;
/http/*/*/*=>8*/host/blue&2*/host/green;

这段代码表示该服务同时连接 blue 和 green 两个后端服务，按照 ⁸⁰⁄₂₀ 的比例进行流量分配。

namerctl dtab create [file name] --base-url，这里 base-url 取值就是我们给 namerd 设置的 Nodeport。

接下来就能够看到管理界面上显示出新的规则了。

运行 Linkerd

这里同样基于官方的 https://raw.githubusercontent.com/BuoyantIO/linkerd-examples/master/k8s-daemonset/k8s/linkerd-namerd.yml

需要注意的是，官方给出的 yaml 文件中有一处 bug，使得这个 yaml 只能在缺省的 namespace 和 domain suffix 下运行。需要纠正对 namerd 的访问方式，删除 Namerd 后面的 default.svc.cloud.local 即可。

同样的，他的服务端口和管理端口都应该改用 NodePort 方式进行暴露。

运行后，同样可以看到 Linkerd 的管理界面。

测试

下面可以做一个简单的测试，来证明流量分配的有效性：

for ((i=1;i<=300;i++)); do curl -s "http://10.211.55.63:30001/";echo ""; done | grep -i blue| wc -l

可以看到，随着循环次数的增加，其结果越来越趋近于 ⁸⁰⁄₂₀ 的分配比例。

接下来，我们修改上面的 dtab 为如下内容：

/host=>/#/io.l5d.k8s/default/http;
/http/*/*/*=>8*/host/blue&8*/host/green;

重新进行测试，就可以看到，流量分配已经发生了变化。另外，还可以在 Linkerd 的管理界面上看到网络流量的变化情况。

结语

这一组合基本能够满足流量渐变分配的功能需求，同时也有如豆瓣这样的大厂使用，但他的 dtab 还是个相对复杂的东西，如果在生产上进行使用，还是需要进一步的学习。

另外，按照其文档中所陈述的功能范围内容来看，仅用来做流量分配还是颇有点大材小用的味道，从个人来说，我倾向于一些更轻量级的解决方法。

Kubernetes 支持 OpenAPI

Sun, 25 Dec 2016 04:22:42 +0800

原文：Kubernetes supports OpenAPI

Open API 让 API 提供者可以定义自己的操作和模型，并让开发者可以自动化的生成喜欢语言的客户端，用以和 API 服务器通信。Kubernetes 已经支持 Swagger 1.2（OpenAPI 规范的前身）有一段时间了，但是这一标准不够完整和有效，凭借这一支持，非常难生成工具或客户端。

在 Kubernetes 1.4，我们对目前的模型和操作进行了升级，引入了 Open API 规范（在没被捐献给 Open API 之前被称作 Swagger 2.0）支持的 Alpha 版本。从 Kubernetes 1.5 开始，OpenAPI 规范的支持已经完备，能够直接从 Kubernetes 源码生成规范，对于模型和方法的任何变更，都会保障文档和规范的完全同步。

新规范让我们有了更好的 API 文档，甚至还有了一个 Python 客户端。

这一模块化的规范用 GroupVersion 进行分隔，这一做法属于未雨绸缪，我们想要让不同的 API Server 使用不同的 GroupVersion。

规范的结构在 Open API spec definition 中有解释。我们用 operation 标记来拆分每个 GroupVersion 并尽可能的丰富其中的模型、路径、操作等信息。操作的参数、调用方法以及响应都有文档描述。

例如，获取 Pod 信息的 OpenAPI 规范

{
...
  "paths": {
"/api/v1/namespaces/{namespace}/pods/{name}": {
    "get": {
     "description": "read the specified Pod",
     "consumes": [
      "*/*"
     ],
     "produces": [
      "application/json",
      "application/yaml",
      "application/vnd.kubernetes.protobuf"
     ],
     "schemes": [
      "https"
     ],
     "tags": [
      "core_v1"
     ],
     "operationId": "readCoreV1NamespacedPod",
     "parameters": [
      {
       "uniqueItems": true,
       "type": "boolean",
       "description": "Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'.",
       "name": "exact",
       "in": "query"
      },
      {
       "uniqueItems": true,
       "type": "boolean",
       "description": "Should this value be exported.  Export strips fields that a user can not specify.",
       "name": "export",
       "in": "query"
      }
     ],
     "responses": {
      "200": {
       "description": "OK",
       "schema": {
        "$ref": "#/definitions/v1.Pod"
       }
      },
      "401": {
       "description": "Unauthorized"
      }
     }
    },
…
}
…

有了这些信息，以及 kube-apiserver 的 URL，就可以据此来调用接口了（/api/v1/namespaces/{namespace}/pods/{name}），参数包括 name、exact 以及 export 等，调用结果会返回 Pod 信息。客户库生成器也会使用这些信息来创建一个 API 函数调用来读取 Pod 信息。例如 Python 客户端能够很简单的进行如下调用：

from kubernetes import client
ret = client.CoreV1Api().read_namespaced_pod(name="pods_name", namespace="default")

https://gist.github.com/mbohlool/d5ec1dace27ef90cf742555c05480146

一个简化版的 read_namespaced_pod。

Python Client：https://github.com/kubernetes-incubator/client-python

还可以使用 Swagger-codegen 文档生成器来根据这些信息生成文档：

GET /api/v1/namespaces/{namespace}/pods/{name}
(readCoreV1NamespacedPod)
read the specified Pod
Path parameters
name (required)
Path Parameter — name of the Pod
namespace (required)
Path Parameter — object name and auth scope, such as for teams and projects
Consumes
This API call consumes the following media types via the Content-Type request header:
*/*

Query parameters
pretty (optional)
Query Parameter — If 'true', then the output is pretty printed.
exact (optional)
Query Parameter — Should the export be exact. Exact export maintains cluster-specific fields like 'Namespace'.
export (optional)
Query Parameter — Should this value be exported. Export strips fields that a user can not specify.
Return type
v1.Pod

Produces
This API call produces the following media types according to the Accept request header; the media type will be conveyed by the Content-Type response header.
application/json
application/yaml
application/vnd.kubernetes.protobuf
Responses
200
OK v1.Pod
401
Unauthorized

有两种方式访问 OpenAPI ：

从 kube-apiserver/swagger.json。这个文件会包含所有启用的 GroupVersion 方法和模型，其中的内容会是该 API Server 所对应的最新版本。
Kubernetes 的 Github 仓库，可以访问 master 或者其他指定的 Release。

有很多工具能和这些 API 协同工作，例如可以用 swagger editor 来打开规范文件并渲染文档，或者生成客户端；还可以直接利用 swagger codegen 来生成文档和客户端。自动生成的客户端多数时候是开箱即用的。不过可能需要做一些登录和 Kubernetes 相关的设置。可以使用 Python 客户端作为模板来开发自己的客户端。

Kubernetes 的 Windows Server 支持

Thu, 22 Dec 2016 23:20:49 +0800

响应群众呼声，Kubernetes 1.5 包含了对 Windows Servern 的支持。80% 的企业应用运行于 Linux + Java 或 .Net + Windows 平台上。Kubernetes 正在 Preview 阶段的这一功能，是贴近企业需求的一次努力。

Kubernetes Windows Server 2016 以及 Windows 容器支持包含了下列功能的预览版本：

容器化的多平台应用

使用操作系统原生语言，例如 Go 和 .NET 核心开发的应用，在以前是不可能再 Linux 和 Windows 之间进行编排的。现在 Kubernetes 有了 windows Server 2016 支持，这些应用就能够同时部署在 Windows 和 Linux 之下了，开发者可以自行选择操作系统运行时。这一功能，消费者已经等了 20 年了。

同时支持 Windows Server 容器和 Hyper-V 容器

Windows Server 2016 有两种类型的容器。Windows 容器会共享内核，比较像 Linux 的 Docker 容器。Hyper-V 容器比虚拟机轻量，同时还提供了更好的隔离。他具有独立的内核，直接的内存访问。Kubernetes 对这两种容器都有编排能力。

扩展应用生态

为 Kubernetes 添加 Windows Server 支持的一个好处就是扩展了 Kuberntes 应用的生态环境：IIS，.NET，Windows 服务，ASP.NET，.NET 核心，以及一些其他类型的应用现在可以以 Windows Server 容器的形式被 Kubernetes 调度了。

支持更多数据中心

包含全球 2000 以及财富 500 的很多企业采用了 Kubernetes，托管了几万个应用。加入 Windows 支持之后，这些组织就可以更近一步的将 Windows 应用纳入 Kubernetes 进行管理了。

将 Windows Server 支持加入 Kubernetes 的过程由 Windows Special Interest Group(SIG) 牵头完成，其中包含了 Apprenda、Google、Red Hat 以及微软等众多厂商。微软的首席项目经理 Taylor Brown 表示：社区工作进一步推动了 Kubernetes 的 windows 容器支持，落实了微软对 Windows 和 Linux 两个生态系统的支持承诺。

使用指南

在哪里使用？

现在就可以开始进行测试，并提供反馈。未来的几个月里，这一功能将会进入 GA 状态，可以在这段时间差进行生产环境的设置。

能怎么用？

多数的 Kuberntes 对象，比如 Pods，Services，Labels 都和 Windows Container 兼容。

还有什么没完善？

因为网络命名空间的问题导致的 Pod 抽象差异。同一个 Pod 内的 Windows 容器无法利用 localhost 进行通信。Linux 容器就可以利用网络命名空间来共享网络栈。 - DNS 能力实现不完整 - 容器内不支持 UDP

什么时候可用？

需要再等几个发布周期。在 GA 之前，要理顺网络和一些其他的事情，包含 Windows Nano 和 Windows Server Core 的支持。

技术演示

Roadmap

在 Kuberntes 1.5 中，Windows Server 容器支持正处于 Alpha 阶段，当然并不会止步于此。客户希望获得企业级的稳定的容器调度和管理功能，来支撑整个技术路线。这要求我们对 Windows 和 Linux 一视同仁。Windows Server SIG 将在未来的发布中做出以下增强：

网络 SIG 会持续同微软的合作来增强 Windows Server 容器的网络核心，尤其是容器模式的网络，以及本地叠加网络的支持。
OOBE 增强 Windows Server Node 的设置部署和检测功能，包括在任何云上部署的能力。
运行时操作定义 CRI 监控的过程中，SIG 将在其中扮演重要角色，将为 Windows Server 容器提供深入的监控能力。

起步

请查看 Github 获取更多细节信息，以便尝试 Windows Server 2016 上的 Kubernetes。如果读者愿意帮助促进 Windows Server 支持，请联系 Windows Server SIG，或者联系 SIG Lead Michael Michael。

StatefulSet: Kubernetes 中对有状态应用的运行和伸缩

Thu, 22 Dec 2016 03:43:00 +0800

原文：StatefulSet: Run and Scale Stateful Applications Easily in Kubernetes

在最新发布的 Kubernetes 1.5 我们将过去的 PetSet 功能升级到了 Beta 版本，并重新命名为 StatefulSet。除了依照社区民意改了名字之外，这一 API 对象并没有太大变化，不过我们在向集合里部署 Pod 的过程中加入了“每索引最多一个”的语义。有了顺序部署、顺序终结、唯一网络名称以及持久稳定的存储，我们认为，对于大量的有状态容器化负载，我们已经具备了一定的支持能力。我们并不是宣称这一功能已经完全完成，但是我们相信他已经处于一个可用状态，并且我们会在推动其正式发布的过程中保持其兼容性。

StatefulSet 的采用时机

在 Kubernetes 中，Deployment 和 ReplicaSets 都是运行无状态应用的有效手段。但这两种方式对于有状态应用来说就不太合适了。StatefulSet 的目的就是给为数众多的有状态负载提供正确的控制器支持。然而需要注意的是，不一定所有的有存储应用都是适合移植到 Kubernetes 上的，在移植存储层和编排框架之前，需要回答以下几个问题。

应用是否可以使用远程存储？

目前，我们推荐用远程存储来使用 StatefulSets，就要对因为网络造成的存储性能损失有一个准备：即使是专门优化的实例，也无法同本地加载的 SSD 相提并论。你的云中的网络存储，能够满足 SLA 要求么？如果答案是肯定的，那么利用 StatefulSet 运行这些应用，就能够获得自动化的优势。如果应用所在的 Node 发生故障，包含应用的 Pod 会调度到其他 Node 上，在这之后会重新加载他的网络存储以及其中的数据。

这些应用是否有伸缩需求？

用 StatefulSet 运行应用会带来什么好处呢？你的整个组织是否只需要一个应用实例？对该应用的伸缩是否会引起问题？如果你只需要较少的应用实例数量，这些实例能够满足组织现有的需要，而且可以预见的是，应用的负载不会很快增长，那么你的本地应用可能无需移植。

然而，如果你的系统是微服务所构成的生态系统，就会比较频繁的交付新服务，如果更近一步，服务是有状态的，那么 Kubernetes 的自动化和健壮性特性会对你的系统有很大帮助。如果你已经在使用 Kubernetes 来管理你的无状态服务，你可能会想要在同一个体系中管理你的有状态应用。

预期性能增长的重要性？

Kubernetes 还不支持网络或存储在 Pod 之间的隔离。如果你的应用不巧和嘈杂的邻居共享同一个节点，会导致你的 QPS 下降。解决方式是把 Pod 调度为该 Node 的唯一租户（独占服务器），或者使用互斥规则来隔离会争用网络和磁盘的 Pod，但是这就意味着用户必须鉴别和处置（竞争）热点。

如果榨干有状态应用的最大 QPS 不是你的首要目标，而且你愿意也有能力处理竞争问题，似的有状态应用能够达到 SLA 需要，又如果对服务的移植、伸缩和重新调度是你的主要需求，Kubernetes 和 StatefulSet 可能就是解决问题的好方案了。

你的应用是否需要特定的硬件或者实例类型

如果你的有状态应用在高端硬件或高规格实例上运行，而其他应用在通用硬件或者低规格实例上运行，你可能不想部署一个异构的集群。如果可以把所有应用都部署到统一实例规格的实例上，那么你就能够从 Kubernetes 获得动态资源调度和健壮性的好处。

实践环节 - ZooKeeper

有两个原因让 [ZooKeeper] 成为 StatefulSet 的好例子。首先，StatefulSet 在其中演示了运行分布式、强一致性存储的应用的能力；其次，ZooKeeper 也是 Apache Hadoop 和 Apache Kafka 在 Kubernetes 上运行的前置条件。在 Kubernetes 文档中有一个深度教程说明了在 Kubernetes 集群上部署 ZooKeeper Ensemble 的过程，这里会简要描述一下其中的关键特性。

创建 ZooKeeper 的 Ensemble

创建 Ensemble 很容易，只要用 kubectl create 来根据定义来创建对象就可以了。

$ kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/master/docs/tutorials/stateful-application/zookeeper.yaml
service "zk-headless" created
configmap "zk-config" created
poddisruptionbudget "zk-budget" created
statefulset "zk" created

接下来 StatefulSet 控制器开始顺序创建各个 Pod，在创建后续 Pod 之前，首先要等前面的 Pod 运行成功并进入到就绪状态。

$ kubectl get -w -l app=zk
NAME      READY     STATUS    RESTARTS   AGE
zk-0      0/1       Pending   0          0s
zk-0      0/1       Pending   0         0s
zk-0      0/1       Pending   0         7s
zk-0      0/1       ContainerCreating   0         7s
zk-0      0/1       Running   0         38s
zk-0      1/1       Running   0         58s
zk-1      0/1       Pending   0         1s
zk-1      0/1       Pending   0         1s
zk-1      0/1       ContainerCreating   0         1s
zk-1      0/1       Running   0         33s
zk-1      1/1       Running   0         51s
zk-2      0/1       Pending   0         0s
zk-2      0/1       Pending   0         0s
zk-2      0/1       ContainerCreating   0         0s
zk-2      0/1       Running   0         25s
zk-2      1/1       Running   0         40s

检查一下 StatefulSet 中每个 Pod 的主机名称，你会发现 Pod 的主机名也包含了 Pod 的顺序：

$ for i in 0 1 2; do kubectl exec zk-$i -- hostname; done
zk-0
zk-1
zk-2

ZooKeeper 在一个名为 “myid” 的文件中保存了每个服务器的唯一标识符。这个标识符只是自然数。在 Ensemble 的服务器中，”myid” 文件中保存的数字就是 Pod 主机名中的顺序号加一。

$ for i in 0 1 2; do echo "myid zk-$i";kubectl exec zk-$i -- cat /var/lib/zookeeper/data/myid; done
myid zk-0
1
myid zk-1
2
myid zk-2
3

基于主机名，每个 Pod 都有独立的网络地址，这个网域由 zk-headless 这一 Headless 服务所控制。

$  for i in 0 1 2; do kubectl exec zk-$i -- hostname -f; done
zk-0.zk-headless.default.svc.cluster.local
zk-1.zk-headless.default.svc.cluster.local
zk-2.zk-headless.default.svc.cluster.local

Pod 具有了唯一的序号和网络地址，就可以用来在 ZooKeeper 的配置文件中设置 Ensemble 成员了。

kubectl exec zk-0 -- cat /opt/zookeeper/conf/zoo.cfg
clientPort=2181
dataDir=/var/lib/zookeeper/data
dataLogDir=/var/lib/zookeeper/log
tickTime=2000
initLimit=10
syncLimit=2000
maxClientCnxns=60
minSessionTimeout= 4000
maxSessionTimeout= 40000
autopurge.snapRetainCount=3
autopurge.purgeInteval=1
server.1=zk-0.zk-headless.default.svc.cluster.local:2888:3888
server.2=zk-1.zk-headless.default.svc.cluster.local:2888:3888
server.3=zk-2.zk-headless.default.svc.cluster.local:2888:3888

StatefulSet 让用户可以用稳定、可重复的方式来部署 ZooKeeper。不会创建具有重复 ID 的服务器，服务器之间可以通过稳定的网络地址互相通信，因为 Ensemble 具有稳定的成员关系，因此 Leader 选拔和写入复制能力也得到了保障。

检查 Ensemble 工作状况的最简单方式就是向一台服务器写入一个值，然后从另一台服务器中读取。可以利用 ZooKeeper 自带的 “zkCli.sh” 脚本来创建包含数据的 ZNode。

$  kubectl exec zk-0 zkCli.sh create /hello world
...

WATCHER::

WatchedEvent state:SyncConnected type:None path:null
Created /hello

使用同一脚本，可以从 Ensemble 另外一台服务器中读取数据。

$  kubectl exec zk-1 zkCli.sh get /hello
...

WATCHER::

WatchedEvent state:SyncConnected type:None path:null
world
...

可以用删除 zk StatefulSet 的方式停掉 Ensemble。

$  kubectl delete statefulset zk
statefulset "zk" deleted

级联删除会销毁 StatefulSet 中的每个 Pod，并且按照创建顺序的反序来执行，只有在成功终结后面一个之后，才会继续下一个删除操作。

$  kubectl get pods -w -l app=zk
NAME      READY     STATUS    RESTARTS   AGE
zk-0      1/1       Running   0          14m
zk-1      1/1       Running   0          13m
zk-2      1/1       Running   0          12m
NAME      READY     STATUS        RESTARTS   AGE
zk-2      1/1       Terminating   0          12m
zk-1      1/1       Terminating   0         13m
zk-0      1/1       Terminating   0         14m
zk-2      0/1       Terminating   0         13m
zk-2      0/1       Terminating   0         13m
zk-2      0/1       Terminating   0         13m
zk-1      0/1       Terminating   0         14m
zk-1      0/1       Terminating   0         14m
zk-1      0/1       Terminating   0         14m
zk-0      0/1       Terminating   0         15m
zk-0      0/1       Terminating   0         15m
zk-0      0/1       Terminating   0         15m

可以使用 kubectl apply 命令来重建 zk StatefulSet，并重新部署 Ensemble。

$  kubectl apply -f http://k8s.io/docs/tutorials/stateful-application/zookeeper.yaml
service "zk-headless" configured
configmap "zk-config" configured
statefulset "zk" created

如果使用 “zkCli.sh” 脚本来尝试获取删除 StatefulSet 之前写入的数据，会发现数据依然存在。

$  kubectl exec zk-2 zkCli.sh get /hello
...

WATCHER::

WatchedEvent state:SyncConnected type:None path:null
world
...

所有的 Pod 都被销毁，他们一旦被重新调度，StatefulSet 也能保证 Ensemble 能够选拔新的 Leader 并继续提供服务。

Node 故障的容错

ZooKeeper 会在 Ensmble 的服务器中复制他的状态机，用于应对 Node 故障。缺省情况下 Kubernetes 调度器可以在同一个 Node 上部署属于 zk StatefulSet 的多个 Pod，假设 zk-0 和 zk-1 两个 Pod 被部署在同一个 Node 上，如果这一 Node 出现故障，ZooKeepers Ensemble 会因为数量不足造成无法提交写入，ZooKeeper 会出现服务中断，直到 Pod 被重新调度。

在集群中，建议为关键进程预留更多资源，这样就能保证故障情况发生的时候能够迅速重新调度 Pod，缩短故障时间。

如果这样无法 SLA 规定的停机时间，那么就应该使用 PodAntiAffinity( Pod 互斥性)注解。用来创建 Ensemble 的定义文件中就包含了这样的注解，他会要求 Kubernetes 调度器不要把 zk StatefulSet 中的多个 Pod 部署在同一 Node 上。

计划内维护的容错

用于创建 ZooKeeper Ensemble 的描述文件还创建了一个 PodDistruptionBudget( Pod 中断预算 ) 对象：zk-budget。zk-budget 用于指示 Kubernetes，这一服务能够容忍的中断 Pod （不健康 Pod）的上限。

{
  "podAntiAffinity": {
    "requiredDuringSchedulingRequiredDuringExecution": [
      {
        "labelSelector": {
          "matchExpressions": [
            {
              "key": "app",
              "operator": "In",
              "values": [
                "zk-headless"
              ]
            }
          ]
        },
        "topologyKey": "kubernetes.io/hostname"
      }
    ]
  }
}

$ kubectl get poddisruptionbudget zk-budget
NAME        MIN-AVAILABLE   ALLOWED-DISRUPTIONS   AGE
zk-budget   2               1                     2h

zk-budget 定义，至少要有两个处于可用状态的成员才能保障 Ensemble 的健康。如果在离线之前对 Node 进行 Drain 操作，如果这一操作过程中终止的 Pod 会违反预算，Drain 操作就会失败。如果使用 kubectl drain，来对 Node 进行 cordon 操作并驱逐所有其中运行的 Node，PodDistruption 让你可以确认这一操作不会中断有状态应用的服务。

更进一步

因为 Kubernetes 的开发工作目标是可用，我们希望获得更多来自用户的设想。如果你想要帮我们处理问题，可以看看 GitHub 上关于 statful 的 Issues。然而为了 API 的易于理解，我们并不准备实现所有的功能请求。我们会优先实现一些能够对所有有状态应用产生改善的功能，例如滚动更新支持、Node 升级的集成、使用高速的本地存储等。StatefulSet 的目的在于支持尽可能多而不是全部的有状态应用。基于这些考虑，我们会避免依赖隐藏特性或者技术的方式来充实 StatefulSet。每个人都可以开发一个想 StatefulSets 的控制器。我们称之为 “making it forkable”。明年，我们希望更多的流行的有状态应用能够有自己的社区支持的独立控制器或 “操作器”。我们已经听说了 etcd、Redis 和 ZooKeeper 的自定义控制器的开发工作。我们期待更多类似案例不断涌现。

ETCD 和 Prometheus 的 Operator 来自 CoreOS，演示了一种超出 StatefulSet 能力的自动化和集成能力。另一方面，使用 Deployment 和 StatefulSet 这样的通用控制器能够用同一种对象管理大量有状态应用。Kubernetes 用户有了运行有状态应用的能力，而且可以自行在两种方式之中进行选择。

Kubernetes 中的容器运行时接口

Tue, 20 Dec 2016 22:13:18 +0800

原文：Introducing Container Runtime Interface (CRI) in Kubernetes

文中多次出现了个单词 shim，胡翻成代理了，虽然垫片还是比鲁棒啥的好听。。

归根结底，Kubernetes Node 的最底层就是启动和停止容器的组件了，这一部分我们称之为容器运行时（ Container Runtim ），这其中最知名的也就是 Docker 了，这一领域正在快速成长，他并不孤独。为了让 Kubernetes 更具扩展性，我们投入了不少精力，在 Kubernetes 中加入了容器运行时插件 API，我们称之为 “CRI”。

CRI 是什么？Kubernetes 需要他么？

每一种容器运行时都有其长处，因此不少用户希望 Kubernetes 能够支持更多的运行时。在 Kubernetes 1.5 中，我们引入了 CRI，这一插件接口让 Kubernetes 无需重新编译就可以使用更多的容器运行时。CRI 包含 Protocol Buffers、gRPC API、以及运行库支持，还有尚在开发的标准规范和工具。 CRI 在 Kubernetes 1.5 中发布了 Alpha 版本。

可替代的容器运行时支持是 Kubernetes 中的新概念。在 1.3 时，我们发布了 rktnetes 项目，让 rkt 容器引擎成为 Docker 之外的又一选择。然而不管是 Docker 还是 rkt，都是用的 Kubelet 的内部接口，同 Kubelet 源码纠缠不清。这种程度的集成，需要对 Kubelet 内部机制有非常深入的了解，还会给社区带来管理压力。这样就给新生代容器运行时造成了难于跨越的集成壁垒。我们用清晰定义的抽象层清除了这一壁垒，让开发者能够专注于容器运行时本身。在通向插件式容器支持以及建设健康生态环境的路上，这是一小步，也是重要的一步。

CRI 概览

Kubelet 使用 gRPC 框架利用 Unix socket 同容器运行时（或者是 CRI 代理）进行通信，这一过程中 Kubelet 是客户端，CRI 代理是服务端。

Protocol Buffers API 包含两个 gRPC 服务，ImageService 和 RuntimeService。ImageService 提供从仓库拉取镜像、查看和移除镜像的功能。RuntimeService 包含了对 Pod 和容器的生命周期管理、和容器的交互（ exec/attach/port-forward ）。rtk 和 Docker 这样的容器运行时可以利用一个 Socket 同时提供两个服务。在 Kubelet 中可以用 --container-runtime-endpoint 和 --image-service-endpoint 参数设置这个 socket。

Pod 和容器的生命周期管理

service RuntimeService {
    // Sandbox operations.
    rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandboxResponse) {}
    rpc StopPodSandbox(StopPodSandboxRequest) returns (StopPodSandboxResponse) {}
    rpc RemovePodSandbox(RemovePodSandboxRequest) returns (RemovePodSandboxResponse) {}
    rpc PodSandboxStatus(PodSandboxStatusRequest) returns (PodSandboxStatusResponse) {}
    rpc ListPodSandbox(ListPodSandboxRequest) returns (ListPodSandboxResponse) {}
    // Container operations.
    rpc CreateContainer(CreateContainerRequest) returns (CreateContainerResponse) {}
    rpc StartContainer(StartContainerRequest) returns (StartContainerResponse) {}
    rpc StopContainer(StopContainerRequest) returns (StopContainerResponse) {}
    rpc RemoveContainer(RemoveContainerRequest) returns (RemoveContainerResponse) {}
    rpc ListContainers(ListContainersRequest) returns (ListContainersResponse) {}
    rpc ContainerStatus(ContainerStatusRequest) returns (ContainerStatusResponse) {}
    ...
}

Pod 由一组应用容器组成，其中包含了共有的环境和资源约束。在 CRI 里，这个环境被称为 PodSandbox。我们有意的给容器运行时留下了一些发挥空间，他们可以根据自己的内部实现来解释 PodSandbox。对于 Hypervisor 类的运行时，PodSandbox 会具体化为一个虚拟机。其他的例如 Docker，会是一个 Linux 命名空间。在 v1alpha1 API 中，Kubelet 会创建 Pod 级别的 cgroup 传递给容器运行时，并以此运行所有进程来保障 PodSandbox 对 Pod 的资源保障。

在启动 Pod 之前，Kubelet 调用 RuntimeService.RunPodSandbox 来创建环境。这一过程包括为 Pod 设置网络（分配 IP）。PodSandbox 激活之后，就可以独立的创建、启动、停止和删除不同的容器了。Kubelet 会在停止和删除 PodSandbox 之前首先停止和删除其中的容器。

Kubelet 的职责在于通过 RPC 管理容器的生命周期，实现容器生命周期的钩子，以及存活和健康监测，执行 Pod 的重启策略等。

为什么 CRI 是围绕容器进行的？

Kubernetes 有一个 Pod 资源的接口。我们曾经可能采用的一个 CRI 的设计就是抽象复用 Pod 对象，容器运行时就可以自行实现自己的控制逻辑和状态转换，这样一来，就能极大地简化 API，让 CRI 能够更广泛的适用于多种容器运行时。但是经过深入讨论之后，我们放弃了这一想法。

首先，Kubelet 有很多的 Pod 级功能和机制（例如循环崩溃的处理），交给容器运行时实现的话，会造成很重的负担；第二，更重要的是，Pod 标准还在高速前进。很多的新功能（例如容器初始化）是由 Kubelet 直接管理容器的，而无需容器运行时进行变更。

CRI 选择了围绕容器进行实现，这样容器运行时能够共享这些通用特性，获得更好的开发进度。这并不意味着我们设计哲学的改变 —— Kubelet 要负责保证实际状态和声明状态的一致性。

Exec/attach/port-forward 请求

service RuntimeService {
    ...
    // ExecSync runs a command in a container synchronously.
    rpc ExecSync(ExecSyncRequest) returns (ExecSyncResponse) {}
    // Exec prepares a streaming endpoint to execute a command in the container.
    rpc Exec(ExecRequest) returns (ExecResponse) {}
    // Attach prepares a streaming endpoint to attach to a running container.
    rpc Attach(AttachRequest) returns (AttachResponse) {}
    // PortForward prepares a streaming endpoint to forward ports from a PodSandbox.
    rpc PortForward(PortForwardRequest) returns (PortForwardResponse) {}
    ...
}

Kubernetes 为用户提供了和 Pod 以及其中的容器进行交互的能力（kubectl exec/attach/port-forward）。Kubelet 目前支持两种方式来支持这些功能：调用容器的本地方法，或者使用 Node 上的工具（例如 nsenter 以及 socat）。因为多数工具假设 Pod 利用 Linux namespace 做了隔离，因此使用 Node 上的工具并不是一个可移植的方案。在 CRI 中，我们显式的定义这些调用，让运行时可以做特定实现。

当下还有一个潜在问题是，Kubelet 处理所有的请求连接，所以他有成为 Node 通信瓶颈的可能。在设计 CRI 的时候，我们采纳了一些反馈，让运行时能够排除中间人。容器运行时可以启动一个单独的流服务器处理请求（还能为 Pod 的资源使用进行记录），并把服务器地址返回给 Kubelet。这样 Kubelet 就能反馈信息给 API Server，使之可以直接连接到容器运行时的服务，并连接到客户端。

CRI 还有很多本文没有提及的内容，可以参考设计文档来获得更多内容。

当前状态

虽然 CRI 还比较初级，但也已经有了很多项目在尝试把各种容器运行时纳入 CRI：

cri-o：OCI 兼容运行时
rktlet：rkt 容器运行时。
frakti：基于 hypervisor 的容器运行时。
Docker CRI 代理

如果对这些运行时感兴趣，可以浏览一下他们的仓库，获取最新的进展情况和相关资料。

开发者如果有兴趣集成新的容器运行时，需要阅读开发者指南，会在这里得到 API 中已知的限制和问题。我们乐于从早期开发者这里获取反馈，加以改进来促进项目成长。开发者需要有对突发故障的心理准备，谁让我们还在 Alpha 呢。

尝试新的 CRI Docker

Kubelet 还没有把 CRI 作为缺省选项，我们正在积极促成这一转变。第一步就是用 CRI 的方式重新对 Docker 进行 Kubelet 的集成。在 1.5 中，我们让 Kubelet 开始支持 CRI，还给 Kubelet 加入了内嵌的 Docker CRI 代理。这样 Kubelet 就可以启动 Docker 的 gRPC 服务了。要尝试新的 Kubelet-CRI-Docker 集成，只需要简单的给 API-Server 参数加上 --feature-gates=StreamingProxyRedirects=true 开关，就启用了新的请求重定向特性，然后用 --experimental-cri=true 开关来启动 Kubelet。

虽说现在的实现还有少量功能缺失，不过已经通过了主要的端到端测试，我们计划扩展测试覆盖范围，也再次邀请社区多多提供反馈来促进我们的工作。

Minikube 和 CRI

如果想要测试新功能，却没时间部署新的测试集群。Minikube 让你能够快速的启动一个本地集群。

检查可用的 Kubernetes 版本，选择最新的 1.5.x，这里使用的是 v1.5.9-beta.1：minikube get-k8s-versions

启动一个带有内置 Docker CRI 集成的 Minikube 集群：

$ minikube start --kubernetes-version=v1.5.0-beta.1  \
--extra-config=kubelet.EnableCRI=true \
--network-plugin=kubenet \
--extra-config=kubelet.PodCIDR=10.180.1.0/24 \
--iso-url=http://storage.googleapis.com/minikube/iso/buildroot/minikube-v0.0.6.iso

--extra-config=kubelet.EnableCRI=true 启用 Kubelet 的 CRI 实现，--network-plugin=kubenet 和 --extra-config=kubelet.PodCIDR=10.180.1.0/24 为网络插件提供了网络设置，分配 PodCIDR 给 Node。这里也可以使用 cni 插件，就无需依赖 PodCIDR 了。--iso-url 给 Minikube 指定一个例子中使用的 ISO 镜像。

检查 Minikube 日志，确认 CRI 的启用

$ minikube logs | grep EnableCRI
I1209 01:48:51.150789    3226 localkube.go:116] Setting EnableCRI to true on kubelet.

创建一个 Pod 并检查状态，应该会看到 “SandboxReceived” 事件，这表明 Kubelet 正在使用 CRI

$ kubectl run foo --image=gcr.io/google_containers/pause-amd64:3.0
deployment "foo" created
$ kubectl describe pod foo
...
... From                Type   Reason          Message
... -----------------   -----  --------------- -----------------------------
...{default-scheduler } Normal Scheduled       Successfully assigned foo-141968229-v1op9 to minikube
...{kubelet minikube}   Normal SandboxReceived Pod sandbox received, it will be created.
...

注意 kubectl attach/exec/port-forward 目前还不能对启用 CRI 模式的 Miniqube 生效，新版本将会加入支持。

Kompose: Docker-compose 到 Kubernetes 的迁移工具

Wed, 23 Nov 2016 09:26:57 +0800

原文：Kompose: a tool to go from Docker-compose to Kubernetes

在 skippbox，我们开发了 Kompose 这一工具，他能够自动把 Docker Compose 应用转换为 Kubernetes 描述文件。利用一个简单的 kompose up 命令，就可以在 Kubernetes 集群上启动 Compose 应用。我们非常乐于将其捐献给 Kubernetes Incubator。下面介绍一下这一工具的开发动机和用法。

Docker 给了开发者以巨大的帮助。让每个人都能够从 Docker Registry 启动一个打包好的 Docker 应用。为了对付多容器应用， Docker 开发了 Docker-compose （也就是 Compose）。Compose 借助 yaml 格式的描述文件来定义一个多容器应用，然后就可以用一个简单的 docker-compose up 来启动这一应用中的多个容器。然而，Compose 只能够在本地或者 Docker Swarm 集群中运行。

那如果我们需要在 Swarm 之外运行怎么办？比如 Kubernetes？

Compose 格式并非为分布式而诞生的。所以，你只能为你选择的容器编排工具重新编写应用描述文件。

我们利用 Kompose，能够简单的完成将应用从 Docker Swarm 到 Kubernetes 的转换过程，这样就为 Docker 用户敞开了 Kubernetes 的大门。

今年夏天，来自红帽子的 Tomas Kral 和 Suraj Deshmukh，以及来自 Google 的 Janet Kuo，他们和 Kompose 的主要开发者 Nguyen An-Tu 一起为 Kompose 锦上添花。我们把 Kompose 提交给 Kubernets Incubator，得到了 Kubernetes 社区的支持，现在可以在 Kubernetes Incubator 找到 Kompose。

Kompose 目前支持 Docker-compose v2 格式，最近还加入了持久卷所有权（PVC）、以及多容器 Pod 的支持。除了缺省的 Kubernetes 之外，我们还支持 Openshift 的发布能力。Kompose 现在还出现在了 Fedora 包中，未来也会进入 CentOS 中去。

Kompose 是一个 Golang 应用，可以从 Github 上获取。下面让我们跳过 Build 环节直接进入实例。

Docker 的留言板应用

留言板应用是 Kubernetes 的权威示例。如果要用 Docker Compose 来实现留言板，可以用下面的代码：

version: "2"

services:
  redis-master:
    image: gcr.io/google_containers/redis:e2e
    ports:
      - "6379"
  redis-slave:
    image: gcr.io/google_samples/gb-redisslave:v1
    ports:
      - "6379"
    environment:
      - GET_HOSTS_FROM=dns
  frontend:
    image: gcr.io/google-samples/gb-frontend:v4
    ports:
      - "80:80"
    environment:
      - GET_HOSTS_FROM=dns

其中包含了三个服务：

一个 Redis 主节点；
一组能够横向扩展并借助 DNS 找到 Master 的 Redis 从节点；
暴露于 80 端口的 PHP 前端。

这些组合在一起，让用户可以发表留言，并保存在 Redis 集群中。

要启动这个应用：

$ docker-compose -f docker-guestbook.yml up -d
Creating network "examples_default" with the default driver
Creating examples_redis-slave_1
Creating examples_frontend_1
Creating examples_redis-master_1

这就是一个简单的 Docker 用法，下面我肯看看如何在不重写任何东西的情况下，让这些工作在 Kubernetes 上完成。

Kompose 的留言板应用

Kompose 目前有三个主要的命令：up、down 以及 convert。为了行文方便，我们只简单说一下留言吧应用的启动。

跟 docker-compose 类似，我们可以用 kompose up 命令处理 Docker compose 文件，来启动应用：

$ kompose -f ./examples/docker-guestbook.yml up
We are going to create Kubernetes deployment and service for your dockerized application.
If you need more kind of controllers, use 'kompose convert' and 'kubectl create -f' instead.

INFO[0000] Successfully created service: redis-master
INFO[0000] Successfully created service: redis-slave
INFO[0000] Successfully created service: frontend
INFO[0000] Successfully created deployment: redis-master
INFO[0000] Successfully created deployment: redis-slave
INFO[0000] Successfully created deployment: frontend

Application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc' for details.

Kompose 自动把 Docker-compose 文件转为 Kuberntes 对象。缺省情况下，他会为一个 Compose 服务创建一个 Deployment 以及一个服务。另外还能自动检测当前的 Kuberntes 端点，并在上面创建对象。可以通过一系列的选项来创建 Replication Controller、Replica Set 或者 Daemon Set。

就这样完成了自动转换，如果你了解一些 Kubernetes 的话，可以用 kubectl 命令来看看集群上运行的留言板。

$ kubectl get pods,svc,deployments
NAME                             READY        STATUS        RESTARTS     AGE
frontend-3780173733-0ayyx        1/1          Running       0            1m
redis-master-3028862641-8miqn    1/1          Running       0            1m
redis-slave-3788432149-t3ejp     1/1          Running       0            1m
NAME                             CLUSTER-IP   EXTERNAL-IP   PORT(S)      AGE
frontend                         10.0.0.34    <none>        80/TCP       1m
redis-master                     10.0.0.219   <none>        6379/TCP     1m
redis-slave                      10.0.0.84    <none>        6379/TCP     1m
NAME                             DESIRED      CURRENT       UP-TO-DATE 

AVAILABLE   AGE
frontend                         1            1             1            1           1m
redis-master                     1            1             1            1           1m
redis-slave                      1            1             1            1           1m

看到了三个服务、三个 Deployment 以及三个 Pod。可以通过 frontend 服务来访问留言板应用。只不过这次的留言板，是从 Docker-Compose 文件启动的。

以上给读者快速的介绍了一下 kompose。还有很多激动人心的特性，例如创建不同类型的资源、创建 Helm Chars，甚至可以使用试验性的 Docker bundle 格式进行输入（Lachlan Evenson 的博客：using a Docker bundle with Kubernetes）。可以在我们的 KubeCon 上的视频中看到完整的演示。

前往 Kubernetes incubator 获取 Kompose，可以帮助你轻松地把应用从 Docker Compose 迁移为 Kubernetes 集群应用。

Kubernetes 中的 StorageClass 和动态卷供给

Thu, 13 Oct 2016 02:36:21 +0800

原文：Dynamic Provisioning and Storage Classes in Kubernetes

存储是容器运行环境的重要一环，Kubernetes 提供了一些用于存储管理的基础能力。动态卷供给是一个 Kubernetes 独有的功能，这一功能允许按需创建存储卷。在没有这种能力之前，集群管理员需要打电话给他们的云或者存储提供者来创建新的存储卷，成功以后再创建 PersistentVolume 对象，才能够在 Kubernetes 中使用。动态卷供给能力让管理员不必进行预先创建存储卷，而是随用户需求进行创建。这一特性在 1.2 版本中处于 α 阶段，在版本 1.4 中提升为 β。这一版本提高了动态卷的弹性和可用性。

新特性

Alpha 版本的动态卷，一个集群同时只能允许单独的、被硬编码的提供者。也就是说，如果 Kubernetes 要提供动态卷的时候，即使集群中可以使用多个存储系统，Kubernetes 也只会使用同一个存储卷插件。存储提供者的选型是基于云环境类型决定的 —— AWS 的 EBS，Google Cloud 的 Persistent Disk 或者是 OpenStack 的 Cinder，以及 vSphere 的 vSphere Volume。另外只有容量参数可以配置。这就意味着，即使有其他参数可用，所有的动态卷除了尺寸大小，其他都是一样的。

因为只有容量是大家都有的吧。。。

虽说这一功能的 Alpha 版本实用性有限，这毕竟是迈出了一步，有助于确定今后的发展方向。

Kubernetes 1.4 中中加入了一个新的 API 对象 StorageClass，可以定义多个 StorageClass 对象，并可以分别指定存储插件、设置参数，用于提供不同的存储卷。这样的设计让集群管理员能够在同一个集群内，定义和提供不同类型的、不同参数的卷（相同或者不同的存储系统）。这样的设计还确保了最终用户在无需了解太多的情况下，有能力选择不同的存储选项。

如何使用

下面是一个例子，管理员提供了两种存储，用户可以选择其中一个使用。细节可以查看手册以及示例文档。

管理员配置

集群管理员定义并发布了两个 StorageClass 对象

kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
  name: slow
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard

这一段创建了一个名为 “slow” 的 StorageClass，用于提供标准的持久存储。

kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd

这一段创建了一个名为 “fast” 的 StorageClass，用于提供类似 SSD 的持久存储。

用户请求

用户在 PersistentVolumeClaim 中可以包含一个 StorageClass 申请动态提供存储。这一任务需要使用 volume.beta.kubernetes.io/storage-class 注解来完成。这一注解的值必须符合管理员配置的 StorageClass 名称。

要选择 “fast” 存储类，用户需要创建如下的 PVC：

 {
  "kind": "PersistentVolumeClaim",
  "apiVersion": "v1",
  "metadata": {
    "name": "claim1",
    "annotations": {
        "volume.beta.kubernetes.io/storage-class": "fast"
    }
  },
  "spec": {
    "accessModes": [
      "ReadWriteOnce"
    ],
    "resources": {
      "requests": {
        "storage": "30Gi"
      }
    }
  }
}

上述报文会提供一个等效于 SSD 的持久盘，当这个 PVC 被删除，这个卷也随之销毁。

缺省行为

所有的 PVC 都可以在不使用 StorageClass 注解的情况下，直接使用某个动态存储。把一个 StorageClass 对象标记为 “default” 就可以了。StorageClass 用注解 storageclass.beta.kubernetes.io/is-default-class 就可以成为缺省存储。

有了缺省的 StorageClass，用户创建 PVC 就不用 storage-class 的注解了，1.4 中新加入的 DefaultStorageClass 准入控制器会自动把这个标注指向缺省存储类。

我还能使用 Alpha 版本么？

Kubernetes 1.4 兼容 alpha 版本的动态卷特性，让用户能够平滑过渡到 beta 版本。用 volume.alpha.kubernetes.io/storage-class 注解来标注 alpha 版本。

在未来版本中将会弃用 Alpha 版本。

下一步？

动态卷功能会持续发展，下面是一些要点。

标准云支持

如果 Kubernetes 集群部署在云服务商，我们考虑自动使用云的本地存储系统创建一个动态卷供给者。例如在 AWS 上的标准部署会得到一个 EBS 的动态卷供给，而 Google Cloud 的部署则会提供一个 GCE PD 动态卷供应者。我们还在讨论是否应该把这种卷作为缺省卷。

Kubernetes 部署安全最佳实践

Tue, 27 Sep 2016 06:56:57 +0800

原文：Security Best Practices for Kubernetes Deployment

本文作者是来自 Aqua Security 的 Amir Jerbi 和 Michael Cherny，他们以大量的案例和经验为基础，总结并描述了 Kubernetes 部署中的最佳安全实践。

Kubernetes 提供了很多能够提高应用安全的方法。要进行这些配置，就要掌握 Kubernetes 的相关知识，同时也要清楚的了解安全需求。这里我们关注的安全内容集中在容器的生命周期上：构建、传输以及运行，并且针对 Kubernetes 进行了特别的裁剪。我们自己的 SaaS 就是运行在 Google Cloud Platform 上的 Kubernetes 中，已经采用了这些最佳实践。

下面是我们对于安全部署 Kubernetes 应用的一些建议。

确保镜像无漏洞

运行带有漏洞的容器会让你的环境身处险境。只要运行中的系统的所有组件都不存在已知漏洞，就能够避免很多被攻击的机会。

安全漏洞的持续扫描

容器中可能有一些过期组件，这些过期组件往往会包含已知漏洞（CVE）。新的漏洞层出不穷，因此对安全漏洞的扫描工作必须持续进行。

适时应用安全更新

一旦在运行的容器中发现了安全漏洞，就该对源镜像进行更新并部署。为了避免破坏镜像和容器的继承性，尽量不要在容器中直接进行更新（例如 apt-update）。 Kubernetes 的滚动更新功能可以渐进式的为运行中的应用更新镜像，这一功能让应用更新变得简单优雅。

只使用可靠的镜像

要避免受到有漏洞甚至恶意的容器的威胁，镜像的准入就需要受到有效管理。和随意下载运行软件一样，下载运行不可靠的镜像也是高危行为，必须杜绝。

使用私库来保存你的镜像，并保证只向其推送可靠镜像。这样就缩小了战场面积，避免大量不确认的公开镜像涌入你的环境。另外建议在持续构建流程中加入漏洞扫描之类的安全环节。

持续集成管线要控制门槛，只允许使用受确认的代码进行镜像构建。镜像构建成功后，应该进行漏洞扫描，排除问题后才能推入私库，进行下一步的部署。过程中发现问题，应该终端构建过程，阻止安全质量低下的镜像进入私库。

目前 Kubernetes 正在开发镜像认证插件（将在 1.4 推出），用以阻挡未认证镜像的进入，相关信息请参看 pull request。

限制对 Kubernetes Node 的直接访问

对 Kubernetes Node 的 SSH 访问会降低主机的安全性。应该让用户尽量使用 kubectl exec，这一命令提供了对容器环境的直接访问，而不需要接触宿主机。

还可以使用 Kubernetes 的 Authorization Plugins 来对用户的资源访问进行进一步控制。这一插件允许定义对命名空间、容器以及操作的基于角色的访问控制。

在资源之间建立管理边界

限制用户权限能够降低出错和入侵造成的危害。Kubernetes 命名空间让你可以把资源分割为不同名称的群组之中。一个命名空间中创建的资源对其他命名空间是不可见的。缺省情况下，Kubernetes 用户创建的资源都存在于 default 命名空间中。可以创建其他的命名空间，并把资源和用户绑定上去。可以使用 Kubernetes Authorization 插件来创建策略，让不同用户分别访问各自的命名空间和对应的资源。

例如下面的策略让 “Alice” 能够从命名空间 “fronto” 中读取 Pod：

{
  "apiVersion": "abac.authorization.kubernetes.io/v1beta1", 
  "kind": "Policy", 
  "spec": {
    "user": "alice",
    "namespace": "fronto",
    "resource": "pods",
    "readonly": true
  }
}

设定资源配额

容器运行中如果没有资源限制，那么系统就可能处于 DoS 或邻里不和的情境之中。要降低或阻止这一风险，就需要设定资源配额。缺省情况下，所有的 Kubernetes 集群资源都可以不受限的访问 CPU 和内存。可以为命名空间创建配额策略，来限制 Pod 的 CPU 和内存消费。

下面的例子是一个命名空间的资源配额定义，限制运行 Pod 数量为 4，CPU 的使用限制在 1-2 之间，内存使用在 1-2 G 之间：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4"
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

将资源配额指派给命名空间：

kubectl create -f ./compute-resources.yaml --namespace=myspace

规划网络分区

在同一个 Kubernetes 集群上运行不同的应用，引入了一个风险就是应用之间的互相访问。要确保容器只能访问允许访问的范围，网络分区是很重要的。Kubernetes 中的一大挑战就是在 Pod、Service 以及容器之间的网络划分，造成这一问题的根本在于容器网络的动态分配过程，让容器可以跨越 Node 进行网络互访。

Google Cloud Platform 用户收益于自动防火墙规则功能，能够阻止跨集群的通信。使用 SDN 或者防火墙能够达到类似的效果。Kuberntes Network SIG 正在进行这方面的努力，目的是增强 Pod 之间的通信策略。新的网络策略 API 将会用于创建 Pod 之间的防火墙规则，限制容器应用的网络访问。

下面的例子是一条网络策略，用于控制 “backend” Pod，只允许来自于 “frontend” Pod 的访问。

POST /apis/net.alpha.kubernetes.io/v1alpha1/namespaces/tenant-a/networkpolicys
{
  "kind": "NetworkPolicy",
  "metadata": {
    "name": "pol1"
  },
  "spec": {
    "allowIncoming": {
      "from": [{
        "pods": { "segment": "frontend" } 
      }],
      "toPorts": [{
        "port": 80,
        "protocol": "TCP" 
      }]
    },
    "podSelector": { 
      "segment": "backend" 
    }
  }
}

网络策略的更多信息可以阅读 SIG-Networking: Kubernetes Network Policy APIs Coming in 1.3。

Pod 和容器的安全上下文

设计容器和 Pod 的时候，一定要配置 Pod、容器以及卷的安全上下文。安全上下文是部署 Yaml 中的一个属性，他控制了 pod/container/volume 的安全参数，下面列出一些重要的参数：

安全上下文设置	描述
SecurityContext->runAsNonRoot	容器应该用非 root 用户运行
SecurityContext->Capabilities	设置 Linux 分配给容器的性能
SecurityContext->readOnlyRootFilesystem	容器是否可以写入 root 文件系统
PodSecurityContext->runAsNonRoot	阻止 Pod 中的容器以 root 用户运行

下面是一个带有安全上下文的 Pod 定义：

apiVersion: v1
kind: Pod
metadata:
  name: hello-world
spec:
  containers:
  # specification of the pod’s containers
  # ...
  securityContext:
    readOnlyRootFilesystem: true
    runAsNonRoot: true

参考

如果用特权形式（--privileged）运行容器，可以用 DenyEscalatingExec 控制。这一开关拒绝在特权容器上使用 Exec 和 Attach 命令。具体情况可以参考 Admission 文档

记录日志

Kubernetes 支持集群级别的日志，集中收集日志到中央服务。当集群创建之后，STDOUT 和 STDERR 就能够被 Node 中的 Fluent 搜集起来，并汇总到 Google Stackdriver Logging 或者 Elasticsearch，并用 Kibana 进行查看。

总结

Kubernetes 为安全提供了很多特性。对这些特性进行学习和了解，才能够制定出符合应用需求的安全方案。

我们建议实施文中提到的最佳实践，使用 Kubernetes 的动态配置能力，结合持续集成，无缝提高安全保障能力。

Minikube：轻松运行本地 Kuberntes 集群

Thu, 14 Jul 2016 15:49:24 +0800

原文：Minikube: easily run Kubernetes locally

Kubernetes 已经是目前最佳的应用容器化工具之一。在投入实际使用之后的一年来，Kubernetes（社区）需要一个本地开发平台。

在过去的几个月中，Kubernetes 社区中的很多成员在为 Github 的 Minikube 仓库奋战。我们要建立一个可以一键运行的版本，这个版本要易用和准确兼顾，并且能够兼容 Mac、 Linux 以及 Windows 的工作站和笔记本电脑。

感谢社区成员的贡献，我们自豪的宣告 Minikube 的诞生，并与 Kubernetes 1.3 一起发布，新的命令能够更好的跟本地集群通信，并且加入了试验性的对 xhyve（OS X）以及 KVM（Linux）的支持。

使用 Minikube

Minitube 是一个独立的 Go 应用，所以只要下载运行就可以了：

Minikube 目前要求安装 VirtualBox

# 这是针对 Mac， 如果是 Linux 的话，用 minikube-linux-amd64 代替 minikube-darwin-amd64 即可

curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/

要启动 Kubernetes 集群，要使用minikube start命令：

$ minikube start
Starting local Kubernetes cluster...
Kubernetes is available at https://192.168.99.100:443
Kubectl is now configured to use the cluster

这样，就在你的电脑上启动了一个单节点的 Kubernetes 集群。Minikube 会给你配置 kubectl，所以你现在就可以运行容器了。

Minikube 创建了一个 Host-Only 的网络界面来和 Node 通信。要和其中的 Pod 或者 Service 通信，就需要跟这个地址进行交互。可以使用 minikube ip 命令：

Minikube 还自带了 Kubernetes Dashboard。要浏览这个界面，可以使用内置的 minikube dashboard命令。

一般来说，Minikube 支持 Kubernetes 集群的所有内容。你可以使用 kubectl exec 来在 pod 内获取一个 bash shell。还可以使用 kubectl port-forward 以及 kubectl proxy 命令来把通信从本地转发到一个 pod 或者 API server。

Minikube 是运行在本地而不是云供应商，因此特定的 LoadBalancer 以及 PersistentVolume 也就无法使用了；当然，还是可以使用 NodePort 以及 HostPath 作为替代方案。

架构

Minikube 构建于 Docker 的 libmachine，利用他的驱动模型来创建、管理本地运行的虚拟机，并与其交互。

慷慨的 RedSpread向 Minikube 贡献了他们的 localkube 代码，得到这一帮助，我们有了在虚拟机中创建单进程 Kubernetes 集群的能力。Localkube 把 etcd、DNS、Kubelet 以及所有的 Kubernetes Master 组件都集成到了一个单独的 Go Lib 中并使用不同的 goroutine 执行。

后续发展

Minikube 现在已经颇具可玩性了，为了改善 Kubernetes 开发体验，我们会持续对 Minikube 进行增强。如果你有任何设想，请移步 issue tracker 畅所欲言。

我们希望尽快把下面列表中的内容加入 Minikube：

为 OSX 以及 Windows 提供本地的 Native hypervisor 支持。
- 我们计划去掉对 Virtualbox 的依赖，转向 OSX 和 Windows 的本地 Hypervisor。
增强对 Kubernetes 特性的支持
- 希望能够进一步缩小功能差异，以便于引入 Ingress 之类的内容。
可配置的 Kubernetes 版本
- 目前 Minikube 只支持 Kubernetes 1.3。我们计划提供用户可控的 Kubernetes 版本支持，这样就能够让开发与生产环境更加贴近。

社区

我们乐于听取 Minikube 的反馈，可以用下面的方式参与社区：

在 GitHub 中提出 Issue 或者提出功能要求。
加入 Slack 的 #minikube 频道

请给 Minikube 一个机会，并让我们能够获知 Minikube 的运行情况。

Kubernetes 中使用 Gluster FS

Wed, 01 Jun 2016 22:57:51 +0800

以 RC 形式运行在 Kubernetes 集群中的 Pod，会因为 Scale 等需要在不同的 Node 之间发生迁移，因此需要有独立于 Node 文件系统的共享存储服务，同时这一存储服务也应该符合集群的运行需要，简单的 NFS 不管是效率上还是可靠性上，都是不具备这一能力的。这里以 Gluster FS 作为存储引擎，为容器集群提供云存储服务。

K8S 的存储卷使用稍有点古怪，Gluster FS 的使用，需要首先定义一个 Endpoint + Service 形式的代理，来定义 Gluster FS 集群，然后就可以通过持久卷或者用 Pod 直接加载了。

定义 Service

首先用一个 YML 文件来定义 Endpoint 和 Service：

---
kind: List
apiVersion: v1
items:
- kind: Endpoints
  apiVersion: v1
  metadata:
    name: service_name
  subsets:
  - addresses:
    - ip: 12.34.56.78
    ports:
    - port: 111
- kind: Service
  apiVersion: v1
  metadata:
    name: service_name
  spec:
    ports:
      - port: 111

Port 可随意填写
Service Name 需要一致，这个值将会用到后面的引用中
ip：Gluster FS 的 IP 地址

定义文件生成结束后，利用 kubectl create -f xx.yaml 的方式加载到集群之中。可以用 kubectl get svc,endpoints 来验证结果。

接下来有两种加载方式可以选择：持久卷和 Pod 直接加载。

Pod 直接加载

可以在 Pod 中直接定义一个 Gluster FS 格式的卷来进行加载：

spec:
containers:
- name: nginx-docker-images
  image: nginx:latest
  volumeMounts:
    - mountPath: /glusterfs
      name: test-volume
volumes:
  - name: test-volume
    glusterfs:
      endpoints: glusterfs-cluster
      path: gv0
      readOnly: false

endpoints: 这里指定的就是上一届中定义的服务名称
path: gluster fs 中的卷名称
readOnly: 是否只读加载

持久卷加载

首先定义一个持久卷：

kind: PersistentVolume
apiVersion: v1
metadata:
  name: gluster-volumen-gv01
spec:
  capacity:
    storage: 1Mi
  accessModes:
    - ReadWriteMany
  glusterfs:
    endpoints: glusterfs-svc
    path: gv0

内容同上面的 Pod 卷定义大同小异，具体参数可以参考持久卷的相关文档。

然后定义一个 PVC

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim2m
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Mi

最后，在 Pod 中利用 PVC 来进行卷加载

volumes:
  - name: test-volume
    persistentVolumeClaim:
      # 上面定义的 PVC 名称
      claimName: myclaim1m

Kubernetes 中的 Persistent Volumes

Wed, 01 Jun 2016 09:30:18 +0800

经过一番实验，证明，这东西除了抽象，没啥鸟用，直接挂 Volume 应该是目前最佳选择。

持久卷 PersistentVolumes

本文描述了 Kubernetes 中的 PersistentVolumes。要求读者有对卷 (volumes) 所有了解。

简介

存储管理跟计算管理是两个不同的问题。PersistentVolume 子系统，对存储的供应和使用做了抽象，以 API 形式提供给管理员和用户使用。要完成这一任务，我们引入了两个新的 API 资源：PersistentVolume（持久卷） 和 PersistentVolumeClaim（持久卷申请）。

PersistentVolume（PV）是集群之中的一块网络存储。跟 Node 一样，也是集群的资源。PV 跟 Volume (卷) 类似，不过会有独立于 Pod 的生命周期。这一 API 对象包含了存储的实现细节，例如 NFS、iSCSI 或者其他的云提供商的存储系统。

PersistentVolumeClaim (PVC) 是用户的一个请求。他跟 Pod 类似。Pod 消费 Node 的资源，PVCs 消费 PV 的资源。Pod 能够申请特定的资源（CPU 和内存）；Claim 能够请求特定的尺寸和访问模式（例如可以加载一个读写，以及多个只读实例）

PV 和 PVC 的生命周期

PV 是集群的资源。PVC 是对这一资源的请求，也是对资源的所有权的检验。PV 和 PVC 之间的互动遵循如下的生命周期。

供应

集群管理员会创建一系列的 PV。这些 PV 包含了为集群用户提供的真实存储资源。他们可利用 Kubernetes API 来消费。

绑定

用户创建一个包含了容量和访问模式的持久卷申请。Master 会监听 PVC 的产生，并尝试根据请求内容查找匹配的 PV，并把 PV 和 PVC 进行绑定。用户能够获取满足需要的资源，并且在使用过程中可能超出请求数量。

如果找不到合适的卷，这一申请就会持续处于非绑定状态，一直到出现合适的 PV。例如一个集群准备了很多的 50G 大小的持久卷，（虽然总量足够）也是无法响应 100G 的申请的，除非把 100G 的 PV 加入集群。

使用

Pod 把申请作为卷来使用。集群会通过 PVC 查找绑定的 PV，并 Mount 给 Pod。对于支持多种访问方式的卷，用户在使用 PVC 作为卷的时候，可以指定需要的访问方式。

一旦用户拥有了一个已经绑定的 PVC，被绑定的 PV 就归该用户所有了。用户的 Pods 能够通过在 Pod 的卷中包含的 PVC 来访问他们占有的 PV。

释放

当用户完成对卷的使用时，就可以利用 API 删除 PVC 对象了，而且他还可以重新申请。删除 PVC 后，对应的卷被视为 “被释放”，但是这时还不能给其他的 PVC 使用。之前的 PVC 数据还保存在卷中，要根据策略来进行后续处理。

回收

PV 的回收策略向集群阐述了在 PVC 释放卷的时候，应如何进行后续工作。目前可以采用三种策略：保留，回收或者删除。保留策略允许重新申请这一资源。在持久卷能够支持的情况下，删除策略会同时删除持久卷以及 AWS EBS/GCE PD 或者 Cinder 卷中的存储内容。如果插件能够支持，回收策略会执行基础的擦除操作（rm -rf /thevolume/*），这一卷就能被重新申请了。

持久卷的类型

持久卷是以插件方式实现的，目前支持如下插件：

GCEPersistentDisk
AWSElasticBlockStore
NFS
iSCSI
RBD (Ceph Block Device)
Glusterfs
HostPath (单节点测试使用)

持久卷

每个 PV 包含一个 spec 以及 status ，用于描述该卷的规格和状态。

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv0003
  spec:
    capacity:
      storage: 5Gi
    accessModes:
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Recycle
    nfs:
      path: /tmp
      server: 172.17.0.2

Capacity（容量）

一般来说，PV 会指定存储容量。这里需要使用 PV 的 capcity 属性。参见 Kubernetes 的 Resource Model 一文，来获取这一属性的计量单位 (Mi/Gi….)。

目前存储大小是唯一一个能够被申请的指标，今后会加入更多属性，例如 IOPS，吞吐能力等。

Access Modes（访问模式）

只要资源提供者支持，持久卷能够被用任何方式加载到主机上。每种存储都会有不同的能力，每个 PV 的访问模式也会被设置成为该卷所支持的特定模式。例如 NFS 能够支持多个读写客户端，但是某个 NFS PV 可能会在服务器上以只读方式使用。每个 PV 都有自己的一系列的访问模式，这些访问模式取决于 PV 的能力。

访问模式的可选范围如下：

ReadWriteOnce：该卷能够以读写模式被加载到一个节点上。
ReadOnlyMany：该卷能够以只读模式加载到多个节点上。
ReadWriteMany：该卷能够以读写模式被多个节点同时加载。

在 CLI 下，访问模式缩写为：

RWO：ReadWriteOnce
ROX：ReadOnlyMany
RWX：ReadWriteMany

重要！一个卷不论支持多少种访问模式，同时只能以一种访问模式加载。例如一个 GCEPersistentDisk 既能支持 ReadWriteOnce ，也能支持 ReadOnlyMany。

Recycling Policy（回收策略）

当前的回收策略可选值包括：

Retain - 人工重新申请
Recycle - 基础擦除（“rm -rf /thevolume/*”）
Delete - 相关的存储资产例如 AWS EBS，GCE PD 或者 OpenStack Cinder 卷一并删除。

目前，只有 NFS 和 HostPath 支持 Recycle 策略，AWS EBS、GCE PD 以及 Cinder 卷支持 Delete 策略（*其他的都是 Retain 是吧。。*）。

阶段（Phase）

一个卷会处于如下阶段之一：

Available：可用资源，尚未被绑定到 PVC 上
Bound：该卷已经被绑定
Released：PVC 已经被删除，但该资源尚未被集群回收
Failed：该卷的自动回收过程失败。

CLI 会显示绑定到该 PV 的 PVC。

PersistentVolumeClaims（持久卷申请）

每个 PVC 包含一个 spec 以及 status，用以表达其规格和状态。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

访问模式

PVC 使用跟 PV 一致的访问模式。

资源

PVC 跟 Pod 一样可以请求特定数量的资源。在这里的请求内容就是存储（storage）。Resource Model 文中提到的内容对 PV 和 PVC 同样适用。

PVC 卷

Pod 能够借助 PVC 来访问存储。PVC 必须跟 Pod 处于同一个命名空间。集群找到 Pod 命名空间中的 PVC，然后利用 PVC 获取到背后的 PV。这个卷就会被加载到主机上，让 Pod 可以使用。

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

kubectl config 文件示例

Wed, 18 May 2016 01:48:04 +0800

apiVersion: v1
kind: Config
# Clusters 一节用于存储对多个 Master 的定义，大致包含证书，服务器地址等信息
clusters:
- cluster:
    certificate-authority: certs/pd/ca.crt
    server: https://10.211.55.87:6443
  name: pd-secure
# Users 一节用于存储用户凭据，可对应 Token, Basic 等验证方法
users:
- name: fake-user
  user:
    password: password
    username: admin  
# Contexts 这里会用上面的集群和用户信息，来形成完整的连接信息
contexts:
- context:
    cluster: pd-secure
    namespace: kube-system
    user: fake-user
  name: pd-local
# 当前生效的 Context，可以利用 kubectl config use-context 来切换
current-context: pd-local
preferences: {}

在 Kubernetes 1.2 中使用部署（Deployment）对象

Thu, 07 Apr 2016 05:43:14 +0800

原文：Using Deployment objects with Kubernetes 1.2

Kubernetes 简化了应用的部署管理，大多数操作都可以用一个 API 或者命令行搞定，例如应用生成、金丝雀测试以及升级。我们为什么还需要部署对象？

部署对象把部署和滚动更新进行了自动化。跟 kubectl 的 rolling-update 相比，部署 API 更加清晰快速，在服务端实现，有更多的功能（例如即使滚动更新已经完成，你还是可以回滚到之前的版本）。

在今天的文章中，我们会讲讲如何使用部署对象：

部署应用
在不中断服务的情况下，逐步更新应用
在部署/更新过程中，如果发现问题，回滚到前一版本。

预备

要完成本文的内容，需要三个条件：

一个运行的 Kuberntes 集群：：如果还没有，参考 Getting Started Guides，其中包含针对笔记本电脑、云提供商以及物理服务器的各种方案。
Kubectl，Kubernetes 客户端：如果运行 kubectl cluster-info 之后看到一个 URL，那么就可以了。否则的话，需要安装和配置 kubectl；如果使用的 Google 容器云，需要参考 Instrctions for hosted solutions
配置文件

如果你懒得自己做，可以观看视频。

运行

配置文件中包含一个静态网站，我们希望用它提供服务。从 Kubernetes 仓库的根，执行

$ kubectl proxy --www=docs/user-guide/update-demo/local/ &

Starting to serve on …

这会在端口 8001 运行一个代理服务器。现在可以由 http://localhost:8001 来访问示例网站（目前还是个空白页面），接下来我们想要运行一个 App，并在网站上显示：

$ kubectl run update-demo
--image=gcr.io/google_containers/update-demo:nautilus --port=80 -l  name=update-demo
deployment “update-demo” created

这一操作会部署一个单实例的应用，应用的镜像是 “update-demo:nautilus”，你可以在 http://localhost:8001/static/ 看到结果：

kubectl run 会输出被创建资源的类型和名字。在 1.2 中变成了创建一个部署资源。后续操作中可以利用这一部署资源，例如 kubectl get deployment 或者 kubectl explose deployment。如果你希望编写一个向前兼容的自动化脚本，可以使用 -o name 来运行 kubectl run 命令，这样就会生成一个简短的输出 “deployment/“，可以用于后续命令。--generator 标记也能用于 kubernetes run 命令来生成其他类型的资源，例如设置为 “run/v1”，可以生成一个 Replication Controller，这是 1.1 和 1.0 的缺省行为，如果设置为 “run-pod/v1”，会创建一个 Pod，例如 --restart=Never 的 Pod。

上面的卡片显示了 Kuberntes 的 Pod，包含 Pod 的名字（ID）、状态、镜像以及标签。

扩展

现在我们来把这个应用集群扩大一点。

$ kubectl scale deployment/update-demo --replicas=4
deployment "update-demo" scaled

更新

更新一下应用：

$ kubectl edit deployment/update-demo

他会打开你的缺省编辑器，你可以立即更新这一部署。查找 .spec.template.spec.containers[0].image，把 “nautilus” 换成 “kitty”，保存文件，你会看到：deployment "update-demo" edited

现在你把应用的镜像从 “update-demo:nautilus” 换成了 “update-demo:kitty”。部署对象允许在不停机的情况下进行渐进式的更新。

等待一段时间，就会发现，更新好像卡住了。

排错

如果仔细看看，你会发现使用 “kitty” 镜像的 Pod 在持续的 Pending 状态。因为这种失败，部署过程自动停止。我们可以观察一下新的 Pod，看看发生了什么问题：

$ kubectl describe pod/update-demo-1326485872-a4key

查看 Pod 的事件，会看到 Kubernetes 无法获取这个不存在的镜像。

Failed to pull image "gcr.io/google_containers/update-demo:kitty": Tag kitty not found in repository gcr.io/google_containers/update-demo

回滚

那么我们就要撤销之前的更新，花时间来找找我们需要的镜像名称。

$ kubectl rollout undo deployment/update-demo deployment "update-demo" rolled back

这样就一切恢复如初了。

rolling back a Deployment 一文，介绍了更多的回滚有关的内容。

再更新

过一会，我们知道我们应该使用的镜像是 “kitten”，现在把 .spec.template.spec.containers[0].image 标记从 “nautilus” 替换为 “kitten”。

$ kubectl edit deployment/update-demo
deployment "update-demo" edited

现在看到，4 只小猫都在运行了，这意味着我们成功的更新了应用，幕后细节可以从下面的命令获知：

$ kubectl describe deployment/update-demo

这里可以看到，部署对象管理着另外一个名为 Replica Set 的资源，控制着 Pod 的实例数量。部署对象具有利用扩展和收缩来对 Replica Set 进行渐进升级的能力。

结语

现在我们讲了部署对象的一些基础：

利用部署对象和 kubectl run 来部署应用。
kubectl edit 命令更新部署对象，从而更新应用。
使用 kubectl rollout undo 来回滚到之前的部署。

注意：Kubernetes 1.2 中，部署对象（Beta 版本）具有完整的功能，是缺省启用的。如果之前用过了 Kubernetes 1.1 中的部署对象，因为这一次升级是向后不兼容的，所以在使用 1.2 之前，请删除所有的 1.1 的部署资源（包括 Replication Controller 以及下属的 Pod）。

在 Kubernetes 1.2 中使用 Spark 和 Zeppelin 处理大数据

Thu, 07 Apr 2016 05:41:13 +0800

原文：Using Spark and Zeppelin to process big data on Kubernetes 1.2

大数据应用与日俱增，很多 Kubernetes 用户希望利用 Kubernetes 集群来运行 Apache Spark，借助容器的能力来获得弹性和移植性。在 Kubernetes 1.2 中，为 Spark、Zeppelin 以及其他应用提供了协同工作的平台。

Zeppelin 是什么？

Apache Zeppelin 是一个基于 Web 的交互式数据分析工具。Spark 也是 Zeppelin 所支持的后台之一。在命令行交互以及 Scala 之外，Zeppelin 为用户提供了一种较为简易的和 Spark 集群交互的能力。

为什么用 Kubernetes？

有很多无需 Kubernetes 运行 Spark 的方式：

独立服务器来运行
可以在 YARN 集群上，和 Hadoop 以及 HDFS 协同工作
可以在 Mesos 集群上跟其他 Mesos 应用一起运行。

那么为什么在 Kubernetes 上运行 Spark ？

一个单纯的、统一的集群接口：Kubernetes 能够支撑多种负载；无需为 YARN/HDFS 和其他应用进行不同的编排。
提高服务器的利用率：在 Spark 和其他应用之间共享节点。你可以用一个串流应用来为 Spark 管线提供数据，也可以运行一个 Nginx Pod 来提供 Web 服务，无需对节点进行静态分区。
不同负载之间的隔离：Kubernetes 的服务质量 (Quality of Service) 机制让用户能够安全的同时调度批处理应用（类似 Spark）以及延迟敏感的其他应用。

Spark 加载

这里使用 Google 容器引擎（GKE）来进行演示，不过这些过程也适用于其他的 Kubernetes 集群。首先创建一个容器引擎的集群，并指定其 scope 为 storage-full。这样的设置允许该集群写入到私有的 Google 云存储中（我们会在后面解释这一选择的理由）：

gcloud container clusters create spark --scopes storage-full --machine-type n1-standard-4

注意我们使用的类型是 n1-standard-4（比缺省的节点类型稍大），用来演示 Pod 的纵向扩展能力。然而 Spark 在缺省的 n1-standard-1 上也能够运行。

集群建立之后，就可以利用 Kubernetes Github 仓库中的配置文件来在集群中启动 Spark 了：

git clone https://github.com/kubernetes/kubernetes.git kubectl create -f kubernetes/examples/spark

kubernetes/examples/spark 是一个目录，这一命令告诉 kubectl 创建这一目录下所有的 YAML 文件所定义的 Kubernetes 对象。

Pod（尤其是 Apache Zeppelin）很大，所以需要一些时间让 Docker 来拉取镜像，一旦运行成功，你会看到类似以下的输出：

$ kubectl get pods
NAME                            READY     STATUS    RESTARTS   AGE
spark-master-controller-v4v4y   1/1       Running   0          21h
spark-worker-controller-7phix   1/1       Running   0          21h
spark-worker-controller-hq9l9   1/1       Running   0          21h
spark-worker-controller-vwei5   1/1       Running   0          21h
zeppelin-controller-t1njl       1/1       Running   0          21h

可以看出 Kubernetes 正在运行一个 Zeppelin 实例，一个 Spark Master 以及三个 Spark worker。

设置 Zeppelin 的安全代理

接下来要设置一个从本机到 Zeppelin 的安全代理，以便从你的机器访问 Zeppelin 实例。（注意这里需要根据你集群中的 Zeppelin Pod 的实际名称修改这个命令）

$ kubectl port-forward zeppelin-controller-t1njl 8080:8080

这就建立了一个从 Kubernetes 集群到 Pod ( zeppelin-controller-t1njl ) 的安全连接，并把这个端口映射到本地的 8080 端口，让你可以安全的使用 Zeppelin。

对正在运行的 Zeppelin 做点什么？

例如我们将要演示如何创建一个简单的电影推荐模型。这一演示基于 Spark 网站提供的代码，为了演示 Kubernetes 的特性，做了一点修改。

现在安全代理启动了，浏览 http://localhost:8080/ 应该会看到下面的页面：

点击 “Import note”，设置一个随便什么名字（比如 “Movies”），点击 “Add from URL”，网址输入：

https://gist.githubusercontent.com/zmerlynn/875fed0f587d12b08ec9/raw/6 eac83e99caf712482a4937800b17bbd2e7b33c4/movies.json

然后点击 “Import Note”，就会获取到这个 Demo 所需的 Zeppelin note。现在我们就有了一个 Notebook，如果点击这个 Note，会看到下面的内容：

接下来可以点击右上角的 Play 按钮，就会创建一个新的电影推荐模型。在 Spark 应用模型中，Zeppelin 扮演 Spark Driver Program，他负责同 Spark 集群交互，并令集群完成任务。在这里 Zeppelin Pod 中的应用获取数据，并发送给 Spark Master，Master 将其分发给 Worker，这些 Worker 会利用 Zeppelin 提供的代码来生成一个电影推荐模型。在下一节中，我们将会讲讲向 GCS 存储数据的问题。

使用 Google 云存储（可选）

在这个演示中，我们将使用 Google 云存储来保存我们的模型数据，这样就可以避免 Pod 生命周期的限制了。Kubernetes 版本的 Spark 内置了 Google 云存储的连接器。只要能够从运行着这个 Kubernetes 节点的 Google 容器引擎项目中能够访问到数据，那么同样的，你的 Spark 镜像也能利用 GCS 连接器访问数据。

还可以在 Note 中修改例子中的变量，就可以保存和恢复电影推荐引擎的模型了，只要把这些变量指向你有权访问的 GCS Bucket 就可以了。如果要创建一个 GCS Bucket，需要执行下面类似的命令：

gsutil mb gs://my-spark-models

URL 部分可以按照用户自己的需要来指定，执行后会生成相应的 Bucket 供应用来使用。

注意：运行这一模型，然后保存，这一过程远比运行后丢弃要慢。这很正常，但是如果要复用一个模型，那么计算后保存，复用时恢复就要比每次重新运算要快了。

使用 Pod 的纵向扩展（可选）

Spark 的 Works 有一些弹性功能，这让我们有机会：用 Kubernetes Pod 纵向扩展能力来对 Spark worker 池自动扩展，为 Work 设置一个目标 CPU 阈值以及最大最小规模即可。这样就不需手工配置 Worker 集群了。

下面就是创建自动伸缩的指令

注意：如果没有改变这一集群的机器类型，你可能需要把 –max 参数设置的小一点。

kubectl autoscale --min=1 --cpu-percent=80 --max=10 rc/spark-worker-controller

可以看到 Replication Controller 把实例数降低到 1，证明了自动伸缩的效果。使用 bubectl get rc，会看到 spark-worker-controller 的 “replicas” 这一列会落回到 1。

之前我们运行的负载太低。为了让任务运行更久一点，我们把 “rank = 100” 改成 “rank = 200”。这样在点击 “Play” 按钮后，Spark worker 会迅速增加到 20 pod，在工作完成后，最多需要五分钟，Work 池开始回落到单一实例。

结论

本文中我们展示了如何在 Kubernetes 中运行 Spark 和 Zeppelin，以及如何使用 Google 云存储来保存 Spark Model，还介绍了利用 Kubernetes 自动伸缩特性来动态设置 Spark worker 池。

Kubernetes 1.2 中利用 Ingress 简化复杂网络

Wed, 06 Apr 2016 07:50:05 +0800

原文：Kubernetes 1.2 and simplifying advanced networking with Ingress

在 Kubernetes 中，服务和 Pod 的 IP 地址缺省只能被集群网络路由。所有边缘路由器传来的流量要么被丢弃，要么被转向。在 Kubernetes 中，我们对 Ingress 对象做了改进，用于简化传入连接进入集群服务的过程。对其进行配置，能够给服务外部可达的 URL，负载均衡，Terminate SSL，提供具名虚拟主机等大量功能。

Ingress Controller

如今，受容器或者虚拟机的影响，对 Web 服务器或者负载均衡的配置变得麻烦了。多数的 Web 服务器配置文件很像。虽说有些应用有些古怪，但是总的说来还是可以通过一些逻辑来达到目的的。在 Kuberntes 1.2 中，Ingress 实现了这些想法，Ingress 控制器就是用于处理这些特别的 Ingress “类” （可能是负载均衡的一个实例，或者复杂一些的提供 GSLB、CDN、DDoS 保护等功能的前端）中的这些个性的东西。Ingress Controller 是一个守护进程，以 Kuberntes Pod 的形式进行部署，他会监控 API 服务的 /ingress 终结点来获取对 Ingress 资源的更新。他的任务就是实现 Ingress 请求。

为了运行下面的例子，你的 Kubternetes 集群必须仅有一个支持 TLS 的 Ingress 控制器。如果你的集群运行在云提供商环境中，首先查找一下 “kube-system” 命名空间，查找 Ingress 控制器的 RC。如果没有的话，需要部署一个 nginx 控制器或者用不到 100 行代码自行实现。

务必花费少许时间来了解一下现存控制器的限制（ GCE, nginx ）。

TLS termination 和 HTTP 负载均衡

Ingress 用于承接服务，所以很适合做负载均衡以及中心化的安全配置。如果你熟悉 Go 语言，Ingress 在集群中扮演了 net/http’s “Server” 的角色。下面的例子示范了如何配置 TLS termination。负载均衡是 Ingress 的必选项目，所以只要创建了这一对象，就有了负载均衡能力。

首先创建一个测试服务。我们会运行一个简单的 Echo 服务器，用来告知我们正在运行的内容（源代码）：

$ kubectl run echoheaders 
--image=gcr.io/google_containers/echoserver:1.3 --port=8080
$ kubectl expose deployment echoheaders --target-port=8080 
--type=NodePort

如果你是在云服务提供商提供的集群上运行，确认你可以由外网通过 Nodeport 访问到这一服务。

$ NODE_IP=$(kubectl get node `kubectl get po -l run=echoheaders 
--template '{{range .items}}{{.spec.nodeName}}{{end}}'` --template
'{{range $i, $n := .status.addresses}}{{if eq $n.type 
"ExternalIP"}}{{$n.address}}{{end}}{{end}}')
$ NODE_PORT=$(kubectl get svc echoheaders --template '{{range $i, $e 
:= .spec.ports}}{{$e.nodePort}}{{end}}')
$ curl $NODE_IP:$NODE_PORT

这是一个简单的检查，如果最后一步失败了，可能需要设置一下防火墙规则。

接下来创建我们的 TLS secret：

$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout 
/tmp/tls.key -out /tmp/tls.crt -subj "/CN=echoheaders/O=echoheaders"
$ echo "
apiVersion: v1
kind: Secret
metadata:
name: tls
data:
tls.crt: `base64 -w 0 /tmp/tls.crt`
tls.key: `base64 -w 0 /tmp/tls.key`
" | kubectl create -f

配置 Ingress：

$ echo "
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: test
spec:
tls:
- secretName: tls
backend:
    serviceName: echoheaders
    servicePort: 8080
" | kubectl create -f -

这样就得到了一个负载均衡 IP：

$ kubectl get ing 
NAME      RULE      BACKEND            ADDRESS         AGE
test      -         echoheaders:8080   130.X.X.X      4m

如果等到 Ingress 控制器把你的后端设置为健康，会看到访问该 IP 80 端口的请求会被重定向到 443 端口，并会使用指定的 TLS 进行验证。

未来

可以在 Ingress API 获得更多的信息。Ingress 还在 Beta 阶段，我们期待你的反馈。你也可以贡献控制器或者 API 代码。所有跟 “Ingress” 的内容都可以，包含 DNS、不同的 TLS 模式、SNI、4 层负载均衡、内容缓存、更多的算法和健康检查等。

Pod 的一生

Wed, 02 Mar 2016 05:09:02 +0800

原文：Pod Lifecycle

本文阐述了 Pod 的生命周期，这并不是一篇全面的文档，仅是这一话题的简介。

Pod 的阶段（Phase）

按照《API 公约》的描述，Pod 阶段是对生命周期的一个阶段的概括。他不是一个对 Pod 或者容器层次的状态的详尽结论，也不是一个全面的状态机。

PodPhase 很封闭。除了本文提到的内容，不应该对一个 Pod 的 PodPhase 做出任何假设。

Pending：Pod 被系统接收，但是其中的一个或者多个容器镜像尚未创建。这一过程包括下载镜像的时间，以及被计划运行之前的时间。
Running：该 Pod 被分派给一个 Node，并且已经创建了所有容器。至少一个容器还在运行，或者正在被启动以及重启。
Succeeded：Pod 中的所有容器都已经成功结束，并且不会重新启动。
Failed：Pod 里所有的容器都已经结束运行，且至少一个容器的退出结果是失败的（被系统结束，或非 0 的退出状态）。
Unknown：因为某些原因无法获得 Pod 状态，一般来说是 Pod 所处主机的通信出了故障。

Pod 状态（Condition）

Pod 中容器的就绪检测会报告就绪状况，其取值可能是 True、False 或者 Unknown。

容器检测

Kubelet 会周期性的对容器进行检测。这一过程是如下三种方法之一：

ExecAction：执行一个容器内的指定命令，如果命令返回码为 0 ，则代表成功。
TCPSocketAction：对目标容器的 IP 地址执行 TCP 操作，如果指定端口开放，则代表成功。
HTTPGetAction：对目标容器的 IP 地址、端口号以及路径进行 HTTP Get 操作，如果返回码在 200 和 400 之间，则检测成功。

检测过程可能会有三种结果之一：

Success：容器成功通过检测。
Failure：容器检测失败。
Unknown：检测未能完成。

目前 Kubelet 能够有两种独立的检测可以被触发：

LivenessProbe：用于检查当前容器是否存活，也就是正在运行。LivenessProbe 会告知 Kubelete 容器的健康状况。如果 LinenessProbe 失败，Kubelete 会杀掉这个容器，接下来，容器会根据 RestartPolicy（重启动策略）进行后续动作。容器在没进行这一检测之前的状态被标记为 Success。
ReadinessProbe：当前容器是否已经就绪，可以对外提供服务。如果这一检测失败的话，即使这一Pod 还在运行，Endpoint 控制器也会把这个 Pod 的 IP 地址从相关服务中移除，这样他就不会从 Proxy 获取流量（例如容器在提供服务之前会有一个较长的启动时间，或者容器正在关机维护）。在初始化完成之前，缺省的就绪状态是 Failure。当没有进行检测的时候，容器的就绪状态缺省假设为 Success。

容器状态（Statuses）

对容器状态的详细信息可以参考ContainerStatuses。

重启策略

RestartPolicy 有几个可能的取值：Always，OnFailure 以及 Never。他的缺省值是 Always。RestartPolicy 作用于一个 Pod 中的所有容器。RestartPolicy 适用于同一 Node 的 Kubelet 的重启动操作。失败的容器会被 Kubelet 重启，重启之前会有一个渐进的延迟，延迟时长是同步频率的 0、1、2、4、8…倍，上限是五分钟，成功执行 10 分钟后会复位（延迟时间）。在 [Pod 文档中] 提到，Pod 一旦绑定到了一个 Node 上，就不会再绑定到其他 Node 了。这意味着即便是只有一个 Pod，也需要有控制器来进行操作，这样在 Node 失败的时候，才能保证 Pod 的存活。

目前有三种可用的控制器：

Job：用来执行会结束的 Pod (例如批处理运算)。
ReplicationController：不需要结束的 Pod (例如 Web Server)。
DaemonSet：每台（物理）机只能运行一个的 Pod，这种 Pod 提供机器相关的系统服务。如果在 ReplicationController 或者 Daemon 之间举棋不定，可以参考 Daemon Set vs Replication Controller。

ReplicationController 是唯一符合 RestartPolicy = Always 需要的。Job 就适合另外两种。

所有三种控制器都有对应的 PodTemplate，跟 Pod 的字段一致。建议创建控制器，让控制器创建 Pod，而不是自行直接创建 Pod。这是因为 Pod 不具备适应服务器失败的能力，而控制器可以。

Pod 的生命期

一般来说， Pod 创建之后就不会消失，除非被手工销毁。销毁手段可能是人工、ReplicationController 或者其他控制器。唯一的例外是处于 Succeeded 或者 Failed 阶段一定时间的 Pod 会因过期（由 Master 决定）而被自动销毁。

如果一个 Node 崩溃或者从集群断开，系统内的实体（目前称为 NodeController ）会负责执行策略（例如超时）并把丢失的 Node 中的所有 Pod 标记为 Failed。

例子

Pod 在 Running 状态，1 个容器，该容器成功退出
- 记录结束事件
- RestartPolicy 如果是
- Always：重启容器，Pod 保持 Running 状态
- OnFailure：Pod 转为 Succeeded 状态
- Never：Pod 转为 Succeeded 状态
Pod 在 Running 状态，一个容器，容器失败退出
- 记录失败事件
- 如果 RestartPolicy 是：
- Always：重启容器，Pod 保持 Running 状态
- OnFailure：重启容器，Pod 保持 Running 状态
- Never：Pod 进入 Failed 状态
Pod 在 Running 状态，两个容器，容器 1 失败退出
- 记录失败事件
- 如果 RestartPolicy 是：
- Always：重启容器， Pod 保持 Running 状态
- OnFailure：重启容器，Pod 保持 Running 状态
- Never：Pod 保持 Running 状态
- 容器 2 退出…
- 记录失败事件
- 如果 Restart Policy 是：
  - Always：重启容器，Pod 保持 Running 状态
  - OnFailure：重启容器，Pod 保持 running 状态
  - Never：Pod 进入 Failed 状态
Pod 在 Running 状态，容器内存不足
- 容器失败退出
- 记录 OOM 事件
- 如果 RestartPolicy 是：
- Always：重启容器，Pod 保持 Running
- OnFailure：重启容器，Pod 保持 Running - Never：记录失败事件，Pod 进入 Failed 状态
Pod 在 Running 状态，一个磁盘坏掉。
- 所有容器被 Kill
- 记录事件
- Pod 进入失败状态
- 如果在控制器之下运行，则 Pod 会在其他位置被创建

Pod 在 Running 状态，所在 Node 被断开

NodeController 等待超时长
NodeController 标记 Pod 为 Failed 状态

如果在控制器之下运行，则 Pod 会在其他位置被创建

type PodStatus struct {
// Current condition of the pod.
// More info: http://releases.k8s.io/HEAD/docs/user-guide/pod-states.md#pod-phase
Phase PodPhase `json:"phase,omitempty"`
// Current service state of pod.
// More info: http://releases.k8s.io/HEAD/docs/user-guide/pod-states.md#pod-conditions
Conditions []PodCondition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type"`
// A human readable message indicating details about why the pod is in this condition.
Message string `json:"message,omitempty"`
// A brief CamelCase message indicating details about why the pod is in this state.
// e.g. 'OutOfDisk'
Reason string `json:"reason,omitempty"`

// IP address of the host to which the pod is assigned. Empty if not yet scheduled.
HostIP string `json:"hostIP,omitempty"`
// IP address allocated to the pod. Routable at least within the cluster.
// Empty if not yet allocated.
PodIP string `json:"podIP,omitempty"`

// RFC 3339 date and time at which the object was acknowledged by the Kubelet.
// This is before the Kubelet pulled the container image(s) for the pod.
StartTime *unversioned.Time `json:"startTime,omitempty"`

// The list has one entry per container in the manifest. Each entry is currently the output
// of `docker inspect`.
// More info: http://releases.k8s.io/HEAD/docs/user-guide/pod-states.md#container-statuses
ContainerStatuses []ContainerStatus `json:"containerStatuses,omitempty"`
}

type ContainerState struct {
// Details about a waiting container
Waiting *ContainerStateWaiting `json:"waiting,omitempty"`
// Details about a running container
Running *ContainerStateRunning `json:"running,omitempty"`
// Details about a terminated container
Terminated *ContainerStateTerminated `json:"terminated,omitempty"`
}

CentOS 7 + Kubernetes 1.1.x + Docker 1.9.x 安装指南

Thu, 24 Dec 2015 00:17:17 +0800

前言

Docker 和 Kubernates最近可以说红的发紫，各种大部头和高深研究也层出不穷。

学习过程中看了官网和社区提供的不少起步文档，但是手工半手工这一块，总感觉语焉不详，操作性不很好，因此就边学边记，整理成这么一篇东西，本文只涉及操作，理论、架构、前景等内容，还请读者自行翻阅相关材料。

注意这里按照我的个人习惯，会把所有可执行文件复制到 /usr/local/share，并链接到 /usr/local/bin；环境配置文件统一放置到 /etc/sysconfig/kubernetes 中，这个做法跟手工安装一样，纯属个人恶趣味，没什么具体理由。

环境准备

这里我们使用的是 CentOS 7 为例子。

接下来内容里面会使用 A, B 两台服务器：

服务器 A
- IP: 10.211.55.12
- 职责
- Kubernate Master
- Docker Private Registry
- Kubernate Master UI
- Kubernate Node
- ETCD
服务器 B
- IP: 10.211.55.13
- 职责
- Kubernate Node

ETCD （仅 Master 需要）

可以简单理解为，用来管理容器 IP 的数据库。

Github 地址

使用 Yum 直接安装：

yum install -y etcd;

注意：安装后需要修改 /etc/etcd/etcd.conf，将其中的监听地址由 127.0.0.1 改为 0.0.0.0 或者其他 Node 可以访问的地址。

# 启动服务
systemctl daemon-reload
systemctl enable etcd
systemctl start etcd

# 为后续服务提供初始值
etcdctl mk /docker.intranet/network/config '{"Network":"192.168.0.0/16"}'

Flannel (所有服务器都需要)

对前面的 ETCD 有依赖，这里利用这一服务来为 Docker 提供网络分配和部分网络参数生成的任务。

yum install -y flannel

接下来编辑配置文件 /etc/sysconfig/flanneld，将其中的 FLANNEL_ETCD 地址修改为之前我们配置的地址，并修改 FLANNEL_ETCD_KEY 为我们使用 etcdctl 设置的值，上文中是 “docker.intranet”

# 启动服务
systemctl daemon-reload
systemctl enable flanneld
systemctl start flanneld

Kubernates Master

下载和安装

首先下载压缩包，并复制其中需要的文件，然后做符号链接到习惯位置。

wget https://github.com/kubernetes/kubernetes/releases/download/v1.1.3/kubernetes.tar.gz
cd kubernetes/server
tar xf kubernetes-server-linux-amd64.tar.gz
cp -Rf kubernetes/ /usr/local/share
cp kubernetes/cluster/centos/node/scripts/remove-docker0.sh /usr/local/share/kubernetes/server/bin
cd /usr/local/bin
ln -s /usr/local/share/kubernetes/server/bin/hyperkube
ln -s /usr/local/share/kubernetes/server/bin/kube-apiserver
ln -s /usr/local/share/kubernetes/server/bin/kube-controller-manager
ln -s /usr/local/share/kubernetes/server/bin/kubectl
ln -s /usr/local/share/kubernetes/server/bin/kubelet
ln -s /usr/local/share/kubernetes/server/bin/kube-proxy
ln -s /usr/local/share/kubernetes/server/bin/kube-scheduler
ln -s /usr/local/share/kubernetes/server/bin/linkcheck
ln -s /usr/local/share/kubernetes/server/bin/remove-docker0.sh

主控服务器 A 除去前面提到的 ETCD 和 FlannelD 两个服务之外，需要三个服务

API Server
Controller Manager
Scheduler

前面下载的包解压之后，kubernetes/cluster/centos/master/scripts 中有以下脚本分别对应上面三个必要的服务：

apiserver.sh
controller-manager.sh
scheduler.sh

这几个脚本大概看了一下，是自动安装过程的一部分，这里拿来进行修改，以适应我们自己的环境，方便应用，也有利于学习，并最终生成一个符合自己洁癖的环境:D

apiserver.sh

MASTER_ADDRESS 取值为服务器 A 的地址
ETCD_SERVERS 取值为ETCD的完整网址
SERVICE_CLUSTER_IP_RANGE 中的内容，按照之前我们给 ETCD 初始化的 IP 范围来设置。
修改过时用法：KUBE_API_ADDRESS="--insecure-bind-address=${MASTER_ADDRESS}"
修改过时用法：KUBE_API_PORT="--insecure-port=8080"
cat <<EOF 所在行涉及的文件名，按照个人习惯更改
用于服务定义的 service 文件，其中的 ExecStart 要注意修改为我们之前生成连接的位置。

最后把涉及证书的一块删掉，这部分内容比较繁杂，先砍掉为好

KUBE_APISERVER_OPTS="   \${KUBE_LOGTOSTDERR}         \\
                        \${KUBE_LOG_LEVEL}           \\
                        \${KUBE_ETCD_SERVERS}        \\
                        \${KUBE_API_ADDRESS}         \\
                        \${KUBE_API_PORT}            \\
                        \${MINION_PORT}              \\
                        \${KUBE_ALLOW_PRIV}          \\
                        \${KUBE_SERVICE_ADDRESSES}   \\"

编辑结束之后，运行该脚本，也就完成了 API SERVER 的配置。

语法错误等情况是在所难免的，可以使用 systemctl status -l [服务名称] 来检查出错信息，如果信息不够详尽，可以把所生成的环境文件中的 loglevel 设置为 0。

另外还可以直接把 ExecStart 中的最终内容直接在命令行执行进行除错。

controller-manager.sh 和 scheduler.sh

修改 MASTER_ADDRESS
修改文件位置
执行

走到这里，就可以使用 kubectl get nodes 之类的命令来跟 Master 互动了，浏览器也可以在服务器的 8080 端口获得一点没用的基本信息了。

Docker

本不想在 Master 机安装 Docker，但是后面的 Kubernates UI，如果不涉及网络操作的话，似乎必须在 Master 上运行，所以只能如此处理了。

Docker 这里我们使用 Docker.io 提供的官方源进行安装：

# !bin/sh
tee /etc/yum.repos.d/docker.repo <<-'EOF'
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF

yum update -y
yum install -y docker-engine
systemctl daemon-reload
systemctl enable docker

这个配置就不准备使用脚本生成了，会稍微麻烦一些，简单粗暴上代码：

首先创建文件 /etc/systemd/system/docker.service.d/custom.conf 这个文件会覆盖 docker.service 中的部分内容

[Service]
Environment="HTTP_PROXY=10.211.55.2:8016" "NO_PROXY=localhost,center.docker.local,16.158.51.247"
EnvironmentFile=-/run/flannel/docker
EnvironmentFile=-/etc/sysconfig/kubernetes/docker
ExecStartPre=/usr/local/bin/remove-docker0.sh

上面文件中包含了代理的设置，用于在公司内网环境下，使用代理服务器获取外部仓库的内容。两行EnvironmentFile，其中一个是我们自行编写的 Docker 环境文件，另一个则是 flannel 运行生成的配置文件，而 ExecStartPre 则是从 Kubernetes 压缩包中的 Docker 配置内容中抄来的，修改了文件位置而已。

上面看出，Docker 服务对 Flanneld 服务是有依赖的，经过对 systemctl status docker 的观察，可以看到这一服务在 /usr/lib/systemd/system/docker.service.d 生成了一份文件，用于声明这一依赖关系。

编辑这个文件：/etc/systemd/system/multi-user.target.wants/docker.service 如果位置不同，可以使用 find /etc -name 'docker.service'，ExecStart 一行改为 ExecStart=/usr/bin/docker daemon $DOCKER_OPT_BIP $DOCKER_OPT_MTU $DOCKER_OPTS

systemctl daemon-reload
systemctl enable docker
systemctl start docker

Node

同样的，可以在 kubernetes/cluster/centos/node/scripts 找到两个 Node 服务的配置脚本，这里先后修改运行 kubelet.sh 以及 proxy.sh 即可。

Kubeletes UI

Kubeletes UI 的安装很简单：

kubectl create -f cluster/addons/kube-ui/kube-ui-rc.yaml --namespace=kube-system
kubectl create -f cluster/addons/kube-ui/kube-ui-svc.yaml --namespace=kube-system

运行之后，可以使用 kubectl get pods --all-namespace 查看进展状况，第一次创建，会到 Google 仓库下载基础镜像，前面介绍的代理使用技巧可能就派上用场了。等到状态从 Pending 变为 Running 之后，就可以用浏览器访问 http://master:8080/ui 来查看控制台了。

kubernetes | 伪架构师

不用 API Server 也能运行 Pod？

静态 Pod

测试

限制

Podman Play Kube

启动 Pod

Configmap

结论

持续监控集群中的镜像漏洞——Trivy Operator 简介

引言

简介

安装

YAML

Helm

Operator Lifecycle Manager

配置

漏洞扫描和呈现

补充

用 ChatGPT 写了一点代码

也算总结吧

用 SPIRE 为 Pod 提供身份

开始之前

Kubernetes 相关插件

配置和启动 SPIRE Server

创建 Agent

启动客户端

To be continued

Prometheus 和 Pod 标签

用标签聚合内存用量

用 Pod 标签 对 CPU 和 IO 指标进行聚合

CPU

磁盘 IO

网络

Kubernetes 中的用户和工作负载身份

使用 curl 访问 Kubernetes API

Kubernetes API 的内外部用户区别

授权外部用户访问集群

用 ServiceAccount 管理 Kubernetes 内部认证

为 Service Account 生成临时认证

AWS 如何将 IaM 集成到 Kubernetes

使用 Token Review API 校验 Projected Service Account

用 Kubernetes 1.24 或者更高版本生成 Service Account 的 Secret

认证插件的选择

总结

介绍一个小工具：Inspektor Gadget

部署

Network Policy Advise

Seccomp Profile Advise

Profile

Snapshot

Top

Trace

然后

介绍一个小工具：Security Profiles Operator

部署

借助 SPO 传递 Seccomp

录制 Profile

牢骚

用 Karmada 和 Pipy 搭建野生多集群

部署 Karmada 集群

纳管集群

操作成员集群

部署应用

用 Pipy 做负载均衡

其实没这么简单

相关链接

Pod 对象也能被淘汰么

长话短说

分而治之

REST 对象

客户端和参数

Feature Gate

指标

结论

Kubernetes Semaphore：模块化、无侵入的跨集群通信框架

问题

依赖项

现有方案

设计

用 Pod 标签对 CPU 和 IO 指标进行聚合

使用 `curl` 访问 Kubernetes API