
### **Prow** | praʊ |

_noun_. _the pointed front part of a ship; the bow. 船首._

了解 Prow 可以参考这篇知乎专栏：[Kubernetes 原生 CI/CD 系统 Prow 简介](https://zhuanlan.zhihu.com/p/65545774)。

本文重点参考了以下文章，并做了一些问题的修复：

- [Prow Tutorial - KubeSphere‘s Github Repo](https://github.com/kubesphere/prow-tutorial)
- [DevOps 工具链之 Prow](https://www.chenshaowen.com/blog/prow-of-devops-tool-chain.html)

我们并不一定需要使用 Bazel 来构建配置。笔者使用的 Kubernetes 版本为 2020 年发布的 1.19.3。一切的前提是拥有一个 Kubernetes 集群，最好在里面也部署一个 Ingress Controller
用来暴露我们的 WebHook 以及 Prow Deck 前端 Dashboard 服务。

在 K8s 集群中部署 Prow 的具体步骤如下：

首先注册一个 GitHub 账号专门用于作为机器人账号，用此账号前往 [GitHub Developer 页面](https://github.com/settings/tokens)创建一个 Token，权限参考上文，并邀请此账号作为
Collaborators 管理仓库。

随机生成 H-MAC 作为 WebHook 密码安全验证。

```yaml
openssl rand -hex 20 > hmac
```

将他们保存在 `/etc/github/oauth` 和 `/etc/webhook/hmac` 文件下。路径不能错误，因为此处和下面的 Prow manifest 字段匹配。

纳入集群对象：

```bash
kubectl create secret generic hmac-token --from-file=hmac=/etc/webhook/hmac
kubectl create secret generic oauth-token --from-file=oauth=/etc/github/oauth
```

将[以下 Prow 的 manifest](https://gist.github.com/la3rence/79ba7d87cb8a3a44916162d4dece0c66) 做简单修改，注意 Ingress 的域名，namespace 为 `default`：

`gist:la3rence/79ba7d87cb8a3a44916162d4dece0c66`

apply 上述 manifest。过程可能持续几分钟。上面用到的镜像都来自 DockerHub，国内可以直接访问。出现问题尝试打印 Pod 日志或者 describe，用好 Google 和 GitHub 能解决几乎 99% 的技术问题。

```bash
curl -L https://bit.ly/prow -o prow.yaml
vi prow.yaml
kubectl apply -f prow.yaml
```

### **Deck** | dɛk |

_noun._ 甲板

等 Pod 全都 Running 后，项目就成功了一半！现在直接访问 Prow 的 Ingress 地址，可以看到 Prow 的 Deck 前端
Dashboard，类似于：[https://prow.k8s.io/](https://prow.k8s.io/) 。

这时，可以在 GitHub 的项目设置里去添加 WebHook:

1. Payload URL 是你的 Prow Ingress 域名后面直接加 `/hook`
2. Content Type 选择 `application/json`
3. Secrets 是上面随机生成的 HMAC
4. 勾选 `Send me everything`

激活并保存。

接着在集群机器上创建一个 `plugins.yaml` 文件和 `config.yaml` 文件来配置 Prow。

插件的声明：

```yaml
plugins:
  GitHub账号/项目名:
    - size
    - cat
    - dog
    - pony
    - shrug
    - yuks
    - label
    - trigger
    - approve
    - lgtm
    - welcome
    - help
    - assign
    - branchcleaner
    - lifecycle
    - wip
    - heart
    - milestone
    - milestonestatus
    - project
    - stage
    - skip
    - blockade
```

Tide 的配置：

```yaml
prowjob_namespace: "default"
tide:
  merge_method:
    kubeflow/community: squash

  target_url: http://你的域名/tide
  queries:
    - repos:
        - GitHub账号/项目名
      labels:
        - lgtm
        - approved
      missingLabels:
        - do-not-merge
        - do-not-merge/hold
        - do-not-merge/work-in-progress
        - needs-ok-to-test
        - needs-rebase

  context_options:
    from-branch-protection: true
    skip-unknown-contexts: true
    orgs:
      org:
        required-contexts:
          - "check-required-for-all-repos"
        repos:
          repo:
            required-contexts:
              - "check-required-for-all-branches"
            branches:
              branch:
                from-branch-protection: false
                required-contexts:
                  - "required_test"
                optional-contexts:
                  - "optional_test"
```

应用更改：

```bash
kubectl create configmap plugins \
--from-file=plugins.yaml=/root/cluster/prow/plugins.yaml --dry-run -o yaml \
| kubectl replace configmap plugins -f -

kubectl create configmap config \
--from-file=config.yaml=/root/cluster/prow/config.yaml --dry-run -o yaml \
| kubectl replace configmap config -f -
```

可能需要两分钟生效。等一切就绪后，就可以创建 Pull Request 来测试了。效果可以参考 [Kubernetes 的官方仓库](http://github.com/kubernetes/kubernetes)或[我的这个 node
命令行翻译项目](https://github.com/la3rence/Tranclite/pull/5)。

### 使用 Prow

在 GitHub 的 Issue 或 Pull Request 页面下你可以用一个简单的 `/meow` 命令让机器人随机发送一张 🐱 的图片。无需任何刷新，GitHub 页面会自动地更新此页面（后来发现是基于 WebSocket）：

![cat-in-issue](/images/prow/1.png)

我们注意到， Kubernetes 维护人员会使用 `/test` 命令来让集群内的 Pod 执行测试并将结果告诉 GitHub，这就是 ProwJob 实现的了。

ProwJob 主要用于 PR 流程的 CI 测试，而国内网络原因无法使用 Google 的 GCS 服务，ProwJob 中 plank
依赖的 [Pod Utilities](https://github.com/kubernetes/test-infra/blob/master/prow/jobs.md#pod-utilities)，其中定义 GCS Bucket
用于存放构建产物、日志等内容，因此，我们似乎只能自己用自定义的镜像来跑临时 CI 任务了。注意定义 presubmit 字段下的 decorate 为
false，并利用好 [Prow 提供的一些环境变量](https://github.com/kubernetes/test-infra/blob/master/prow/jobs.md#job-environment-variables)。

下面是我的一个简单的 Spring Boot 项目利用 [Maven 镜像（配合阿里云的 Maven Repo）](https://hub.docker.com/r/lawrence2018/aliyun-maven)来做的
presubmits，同样在 config.yaml 中添加：

```yaml
presubmits:
  la3rence/kubernetes-springboot-demo:
    - name: spring
      decorate: false
      always_run: false
      spec:
        containers:
          - image: lawrence2018/maven:3.6-jdk-8
            command: ["/bin/sh", "-c"]
            args:
              - |
                mkdir -p /${REPO_NAME}
                cd /${REPO_NAME}
                git init
                git remote add origin https://github.com/${REPO_OWNER}/${REPO_NAME}.git
                git fetch origin pull/${PULL_NUMBER}/head:pr-${PULL_NUMBER}
                git checkout pr-${PULL_NUMBER}
                mvn test
            resources:
              requests:
                cpu: "2000m"
                memory: "1536Mi"
```

重新配置 config 后并应用更改，在 Pull Request 下评论 `/test all` 或者 `/test spring`
来触发测试。[参考此 PR](https://github.com/la3rence/kubernetes-springboot-demo/pull/4)。

`/test` 后面加 presubmits 的 name 名可触发指定的测试 Pod，all 则测试全部。测试若失败，可使用 `/retest` 来重新测试。

![Prow-in-Pull-Request-Test.png](/images/prow/2.png)

如果测试通过，可使用 `/lgtm` 触发 tide 让机器人合并代码（注意自己不能 `/lgtm`）。

### 自研 Issue/PR Bot

GitHub 大规模使用 WebSocket 来动态修改 Issue 或 PR 页面的 DOM，在视觉上非常令人享受。笔者后来也参考 Prow 用 Go
写了一个简单了 [OpsBot](https://github.com/la3rence/OpsBot) 帮助自己的仓库做一些简单的 PR、Issue 的管理，现已开源，欢迎任何 Issue / PR！

<div>
  <github user="la3rence" repo="OpsBot"></github>
</div>


Kubernetes 原生 CI/CD 系统 `Prow`。GitHub CI 🤖️ by Kubernetes. @k8s-ci-bot

在 Kubernetes 中部署 Prow


Kubernetes [中文概述](https://kubernetes.io/zh/docs/concepts/overview/what-is-kubernetes/#%E4%B8%BA%E4%BB%80%E4%B9%88%E9%9C%80%E8%A6%81-kubernetes-%E5%AE%83%E8%83%BD%E5%81%9A%E4%BB%80%E4%B9%88)（是什么以及不是什么）。

实践时建议使用 [kubectl 自动补全](https://kubernetes.io/zh/docs/reference/kubectl/cheatsheet/#kubectl-%E8%87%AA%E5%8A%A8%E8%A1%A5%E5%85%A8)，极大提升交互效率。

### Pod

Pod 是比容器更高一层次的抽象，同一 Pod 中的所有容器共享

- 同一网络 namespace
- 存储

### Controller

- Deployment
- ReplicaSet
- DaemonSet
- StatefulSet
- Job

### Service

是一个[四层负载均衡器](https://lawrenceli.me/blog/load-balancing)，为 Pod 提供负载均衡。

### MiniKube

国内建议自定义镜像仓库，默认是 [gcr.io](http://gcr.io) ，似乎自带了 PV。

```bash
minikube start --vm-driver=none --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers --cpus 4 --memory 6144
```

感觉 Docker Desktop 内置的 Kubernetes 有点类似这个 minikube （master 可以直接运行 Pod，也就是单节点集群）。当然了，它们都只能用于开发/测试环境。

### Demo

[用 Spring Boot 创建了一个 HTTP 服务端](https://github.com/la3rence/kubernetes-springboot-demo)，可以尝试用 Kubernetes 部署它。

### 公网服务器集群初始化常用脚本

```sh
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF
```

```sh
yum install -y kubeadm-1.19.13-0 kubelet-1.19.13-0 kubectl-1.19.13-0
```

```sh
kubeadm config images pull --image-repository registry.aliyuncs.com/google_containers --kubernetes-version v1.19.3
```

```sh
kubeadm init --image-repository registry.aliyuncs.com/google_containers --kubernetes-version v1.19.13 --apiserver-advertise-address $(hostname -i) --pod-network-cidr=10.96.0.0/16 --service-cidr=10.97.0.0/16
```

```sh
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config
```

Flannel:

```bash
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml](https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml)
```

```bash
kubectl apply -f kube-flannel.yaml
```

运行 Master 作为 Node:

```bash
kubectl taint node $HOSTNAME node-role.kubernetes.io/master-
```

恢复 Master 不可调度：

```bash
kubectl taint node $HOSTNAME node-role.kubernetes.io/master="":NoSchedule
```

重置：

```bash
kubeadm reset
systemctl stop kubelet
rm -rf /var/lib/cni/
rm -rf /var/lib/etcd/
rm -rf /var/lib/kubelet/
rm -rf /etc/cni/
rm -rf $HOME/.kube
ifconfig cni0 down
ifconfig flannel.1 down
ifconfig docker0 down
ip link delete cni0
ip link delete flannel.1
systemctl restart kubelet
systemctl stop docker
systemctl restart docker
```

Pod 无法访问外网，尝试：

```bash
iptables -P FORWARD ACCEPT
iptables --flush
iptables -tnat --flush

iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X
// POD 无法访问外网络，但是可以互相 ping 或 ping 宿主。CIDR 为 POD CIDR
// 有可能是 SNAT 时出了问题，使用动态 SNAT （即 MASQUERADE） 来配置 nat 表路由规则：
iptables -t nat -I POSTROUTING -s 10.96.0.0/16 -j MASQUERADE
// 再尝试重新运行 core dns 服务
```

[https://github.com/rancher/rancher/issues/6139](https://github.com/rancher/rancher/issues/6139)

[https://github.com/coredns/coredns/issues/2693](https://github.com/coredns/coredns/issues/2693)

网络调试：使用 BusyBox:1.28.3，不建议使用 latest 镜像.

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: default
  labels:
    app: busybox
spec:
  selector:
    matchLabels:
      app: busybox
  replicas: 1
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
        - name: busybox
          image: busybox:1.28.3
          command:
            - sleep
            - "3600"
          imagePullPolicy: IfNotPresent
      restartPolicy: Always
```

基于 DNS 的服务发现： Kubernetes Service / Pod 对象资源可以使用集群内部 FQDN 来访问，而不需要在意其扁平空间中的 Cluster IP。
Core DNS 会将 FQDN 动态地指向最新的 Cluster IP。参考 [Pod 与 Service 的 DNS](https://kubernetes.io/zh/docs/concepts/services-networking/dns-pod-service):

```bash
kubectl exec busybox -it -- nslookup kubernetes
```

返回内容：

```bash
Server:    10.97.0.10
Address 1: 10.97.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes
Address 1: 10.97.0.1 kubernetes.default.svc.cluster.local
```


◳Lawrence Li

Tagged with `kubernetes`

Tagged with kubernetes

Tagged with `kubernetes`