在K8s上运行GitHub Actions的自托管运行器

1：添加Actions Runner Controller的Helm仓库

helm repo add actions-runner-controller https://actions-runner-controller.github.io/actions-runner-controller
helm repo update

2：创建GitHub Personal Access Token (PAT)

1. 登录到你的GitHub账户。
2. 访问设置页面，找到“Developer settings”部分。
3. 在“Personal access tokens”中生成一个新的访问令牌，赋予它repo和admin:org的权限。

3：创建Kubernetes Secret

使用你的GitHub PAT创建一个Kubernetes Secret，以便Actions Runner Controller可以访问GitHub API。

# 创建命名空间
kubectl create namespace actions-runner-system

kubectl create secret generic actions-runner-controller-manager   -n actions-runner-system   --from-literal=github_token=<YOUR_GITHUB_TOKEN>

kubectl create secret generic controller-manager \
  -n actions-runner-system \
  --from-literal=github_token=<YOUR_GITHUB_TOKEN> # <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>

4：配置Helm values

下载Actions Runner Controller的默认配置文件，并根据需要进行修改，特别是添加Docker Pull Secret。

helm show values actions-runner-controller/actions-runner-controller --version 0.23.7 > values.yaml
vi values.yaml
# 目前只查看了下不知道配啥

5：安装Actions Runner Controller

使用Helm安装Actions Runner Controller到你的Kubernetes集群。

helm upgrade -i actions-runner-controller actions-runner-controller/actions-runner-controller \
  --version 0.23.7 \
  -n actions-runner-system

输出：

Release "actions-runner-controller" does not exist. Installing it now.
NAME: actions-runner-controller
LAST DEPLOYED: Mon Aug 26 16:14:06 2024
NAMESPACE: actions-runner-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace actions-runner-system -l "app.kubernetes.io/name=actions-runner-controller,app.kubernetes.io/instance=actions-runner-controller" -o jsonpath="{.items[0].metadata.name}")
  export CONTAINER_PORT=$(kubectl get pod --namespace actions-runner-system $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace actions-runner-system port-forward $POD_NAME 8080:$CONTAINER_PORT

(X) 6：创建 Runner（不推荐）

不推荐原因：使用下面这种方式创建的runner，一次作业后就会销毁。我在Rancher中发现deploy-web-dev-runner的状态是notReady并找了很久的原因，因此最好不要用这种方式创建Runner。需要创建可以去看看步骤8

执行下面的命令，创建一个名为 deploy-web-dev-runner 的 Runner CR。

kubectl apply -f - <<EOF                 
apiVersion: actions.summerwind.dev/v1alpha1
kind: Runner
metadata:
  name: deploy-web-dev-runner
  namespace: actions-runner-system
spec:
  repository: mingchangge/deployWeb
  env: []
EOF

查看Runner

kubectl get runner -n actions-runner-system deploy-web-dev-runner

输出：

NAME                    ENTERPRISE   ORGANIZATION   REPOSITORY              GROUP   LABELS   STATUS    MESSAGE   WF REPO   WF RUN   AGE
deploy-web-dev-runner                               mingchangge/deployWeb                    Running                                15s

在项目仓库的 Settings/Actions/Runners 中可以看到同名的 Runner，处于 idle 状态。

deploy-web-dev-runner没有指定namespace，则Runner建立在默认命名空间即default。
删除建立在默认命名空间资源的命令： kubectl delete runner deploy-web-dev-runner

7：项目推送

在你的GitHub Actions workflow中，将 runs-on 指定为 [self-hosted, linux, X64]后推送项目，Runner运行。

最后runner运行成功
只是作业运行结果结果失败，报错如下：（Runner执行的机器中缺少node不识别npm命令，简单的处理办法就是在 Workflow 中使用 actions/setup-node。）

...
Run echo "npm install"
npm install
/runner/_work/_temp/aadcc564-e286-4996-8f54-5e0824cc9863.sh: line 3: npm: command not found
Error: Process completed with exit code 127.

在 Workflow 中使用 actions/setup-node

7.1：排错

runner运行完2天后再次修改前端项目，推送github后，忽然发现作业找不到机器执行，github settings/Actions的Runner列表也没有之前部署的Runner了，截图如下：
Runner执行作业：

github项目settings/Actions/runners：

查看pod状态
kubectl get pods -n actions-runner-system
输出：

NAME                                         READY   STATUS     RESTARTS   AGE
actions-runner-controller-5c996cd9c7-gqm5g   2/2     Running    0          2d19h
deploy-web-dev-runner                        1/2     NotReady   0          2d1h

kubectl describe pod deploy-web-dev-runner -n actions-runner-system
kubectl logs deploy-web-dev-runner -n actions-runner-system
kubectl get pods deploy-web-dev-runner -n actions-runner-system -o jsonpath='{.status.containerStatuses[*].ready}'
get pods deploy-web-dev-runner -n actions-runner-system -o jsonpath='{.status.containerStatuses[*].name}'
kubectl get pods deploy-web-dev-runner -n actions-runner-system -o yaml
以上命令均没有输出什么有价值的错误信息导致的Runner notReady，再根据 kubectl describe pod 命令的输出，deploy-web-dev-runner Pod 中的 runner 容器已经终止，状态为 Terminated，并且其退出状态是 Completed 退出码为 0。这表明容器已经成功执行并正常退出。但是，由于容器已经终止，它不会对 Ready 探针做出响应，因此 Kubernetes 报告该容器状态为 NotReady。从执行上来看runner 容器是个一次性任务执行器，NotReady 状态可能不是一个问题，而只是容器生命周期的一个正常部分。

8：创建可重用 Runner

根据网上的参考资料进行下一步创建可重用 Runner

kubectl apply -f - <<EOF
apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
  name: deploy-web-dev-runner
  namespace: actions-runner-system
spec:
  template:
    spec:
      repository: mingchangge/deployWeb
      env: []
EOF

参考文章有言在先，怪我自己没有耐心看完。

actions-runner-controller 提供了三种 CRD：

• Runner：可以理解为 Pod，该 Runner 只能执行一次作业。
• RunnerDeployments：可以理解为Deployment，可以设置要创建的 Runner 数量。Runner 在执行完作业后会销毁，然后 Controller 会创建新的Runner 等待作业调度。
• RunnerSets：可以理解为 StatefulSet，也是基于 StatefulSet 来创建 Pod（即Runner），提供 StatefulSet 的特性。
  更多用法，可以参考 actions-runner-controller 官方文档。

创建完可重用Runner，推送项目，发现创建的runner比之前多了一些后缀。

之前的推送处理完成后，本次推送才开始进行处理。

多个请求推送去 Actions 列表会发现，只有一个作业在运行，其他都是 queued 的等待状态。只有等前面的作业执行完成后，后一个作业才会被执行。

由上图可知执行多个任务时，任务需要排队等候不支持并发。但是actions-runner-controller 在 3 个 Runner 的 CRD 之外，还提供了类似 HPA（水平 pod 自动扩缩容） 的 CRD HorizontalRunnerAutoscaler，简称 HRA。
HRA 可以根据指标 PercentageRunnersBusy 或者 TotalNumberOfQueuedAndInProgressWorkflowRuns 来对 runner 进行扩缩容，或者基于 GitHub Events（webhook）来进行扩缩容。这两种都各有优缺点，前者指标是通过 GitHub API 轮训等待的作业数，实现简单，但时效性差；后者基于事件触发时效性更佳，但是实现复杂，需要对外暴露访问端点接收 GitHub Event。
下面的参考的文章是使用前一项的，所以我准备试试Webhook 驱动扩展，成不成功的先做个记录。

(X)9：Webhook 驱动扩展

失败原因：转来转去又回到了原点，我的服务器连接不了外网，webhook timeout。目前两种解决方式可行：一、使用内网穿透工具如Ngrok，将内网的服务暴露到公网上，从而允许外部访问，不太好的方案；二、开个ssh隧道连接，但又一时找不到可用的服务器，此操作搁置。暂时不扩容了已经卡了很久很久，还是继续往下进行吧。

使用自定义 Kubernetes 入口控制器：

在actions-runner-system命名空间上创建一个新的部署和一个用于接收 Github Webhooks 的服务

helm upgrade --install --namespace actions-runner-system --create-namespace \
             --wait actions-runner-controller actions-runner-controller/actions-runner-controller \
             --set "githubWebhookServer.enabled=true"

输出：

Release "actions-runner-controller" has been upgraded. Happy Helming!
NAME: actions-runner-controller
LAST DEPLOYED: Fri Aug 30 10:48:23 2024
NAMESPACE: actions-runner-system
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace actions-runner-system -l "app.kubernetes.io/name=actions-runner-controller,app.kubernetes.io/instance=actions-runner-controller" -o jsonpath="{.items[0].metadata.name}")
  export CONTAINER_PORT=$(kubectl get pod --namespace actions-runner-system $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace actions-runner-system port-forward $POD_NAME 8080:$CONTAINER_PORT

创建名为arc-webhook-server.yaml的Ingress 文件

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: actions-runner-controller-github-webhook-server
  namespace: actions-runner-system
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
spec:
  ingressClassName: nginx # 使用这个字段来指定Ingress控制器
  tls:
  - hosts:
    - rancher.lxq.com
    secretName: tls-rancher-ingress
  rules:
    - http:
        paths:
          - path: /actions-runner-controller-github-webhook-server
            pathType: Prefix
            backend:
              service:
                name: actions-runner-controller-github-webhook-server
                port:
                  number: 8090

kubectl apply -n actions-runner-system -f arc-webhook-server.yaml

GitHub新增webhook

1. 配置 GitHub 开始向您发送 webhook，请转到您的存储库或组织的设置（Settings）页面，单击Webhooks后单击Add webhook。
2. 使用您刚刚创建的 webhook URL 设置“Payload URL”字段，如果您遵循上面的示例，则 URL ：
   https://${您自己的域名}/actions-runner-controller-github-webhook-server
3. 点击“内容类型”并选择application/json。
4. 点击“让我选择单个事件”并选择Workflow Jobs（我还选了几个其他的）。
5. 点击Add Webhook。
   
   创建完成后发现webhooke不能正常工作
   
   无效尝试
   创建一个针对节点端口的外部负载均衡器,该service一直是Pending状态。

• vi webhook-service.yaml

  apiVersion: v1
  kind: Service
  metadata:
    name: webhook-service
    namespace: actions-runner-system # 或者是你的命名空间
  spec:
    type: LoadBalancer
    externalIPs:
  	- 192.168.XX.XXX
    selector:
       app.kubernetes.io/instance: actions-runner-controller-github-webhook-server
       app.kubernetes.io/name: actions-runner-controller
       pod-template-hash: 6b4f5cf858
    ports:
      - appProtocol: http
        name: http
        nodePort: 30080
        port: 8090
        protocol: TCP
        targetPort: http
  

• kubectl apply -f webhook-service.yaml

  kubectl get service webhook-service -n actions-runner-system
  # 输出：
  NAME              TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)          AGE
  webhook-service   LoadBalancer   10.96.127.64   <pending>   8090:30080/TCP   95m
  

参考

在 Kubernetes 上运行 GitHub Actions Self-hosted Runner
在 Kubernetes 上执行 GitHub Actions 流水线作业
automatically-scaling-runners.md

补充内容：

k8s小白使用命令记录：

查看 ingress配置

kubectl describe ingress -n cattle-system

查看secret

kubectl get secret tls-rancher-ingress -n cattle-system -o yaml

查看使用kubectl apply -f 命令创建Kubernetes资源的命名空间

当你使用kubectl apply -f命令创建Kubernetes资源时，资源的命名空间通常在YAML文件中指定。要查看或确认通过这种方式创建的资源的命名空间，你可以：

1. 直接查看YAML文件：
   在YAML文件中查找metadata部分，看是否有namespace字段。例如：

   metadata:
     name: my-resource
     namespace: my-namespace
   

   如果namespace字段存在，那么资源就被创建在了这个命名空间内。如果namespace字段不存在，那么资源将被创建在当前的kubectl上下文中所设置的命名空间内，通常这会是default命名空间。

2. 使用kubectl get命令：
   你也可以使用kubectl get命令并指定-A或--all-namespaces参数来查看所有命名空间中的资源。例如，要查看所有命名空间中的所有资源，可以运行：

   kubectl get all --all-namespaces
   

   从输出中，你可以找到你创建的资源，并看到它所在的命名空间。

3. 使用kubectl config命令：
   如果你想要知道当前kubectl上下文的命名空间，可以使用：

   kubectl config current-context
   

   然后查看你的.kube/config文件中当前上下文的namespace字段。但是，这方法只能确认当前默认的命名空间，对于直接在YAML文件中指定的命名空间，还是需要查看YAML文件。

删除使用`kubectl apply -f 命令创建Kubernetes资源

使用kubectl apply -f命令创建的Kubernetes资源，可以通过kubectl delete命令或者再次使用apply命令来删除。下面是两种删除资源的方法：

1. 使用kubectl delete

如果已知资源类型和名称，可以直接使用delete命令：

kubectl delete <resource-type> <resource-name> --namespace=<namespace>

这里，你需要将<resource-type>替换为资源的类型（如deployment, service, pod等），<resource-name>替换为资源的名称，<namespace>替换为资源所在的命名空间。如果资源在默认命名空间中，可以省略--namespace=<namespace>部分。

例如，删除名为my-service的服务：

kubectl delete service my-service

如果删除的是由YAML文件创建的资源，而你不知道资源的确切类型或名称，可以通过YAML文件来删除：

kubectl delete -f <path-to-file>

将<path-to-file>替换为YAML文件的路径。

2. 使用kubectl apply和--delete-collection

如果你使用的是kubectl apply，并且你的YAML文件中包含多个资源定义，你可以通过添加--delete-collection标志来删除由该文件创建的所有资源。但要注意，这通常用于清理整个资源集合，并且可能不保留状态数据，所以在生产环境中使用时要格外小心。

kubectl apply -f <path-to-file> --delete-collection --force

这里，--delete-collection选项告诉kubectl删除与YAML文件匹配的所有资源，--force则确保即使有运行中的Pod也会被强制删除。

但--delete-collection并不是kubectl apply的标准行为，它用于清理不再存在的资源。如果你的YAML文件只定义了一个资源，或者你只是想要删除一个特定的资源，使用kubectl delete会更直接和安全。

示例

假设你有一个名为deployment.yaml的文件，其中定义了一个名为web的deployment和一个名为web-service的服务。

要删除由这个文件创建的所有资源，可以使用：

kubectl delete -f deployment.yaml

或者，如果你想使用apply来删除：

kubectl apply -f deployment.yaml --delete-collection --force

但请注意，--delete-collection和--force的使用要谨慎，确保你理解其行为和可能的后果。