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

1：添加Actions Runner Controller的Helm堆栈

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

复制代码

2：创建GitHub Personal Access Token (PAT)

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

3：创建Kubernetes Secret

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

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

复制代码

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

复制代码

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

复制代码

4：配置Helm values

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

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

复制代码

5：安装Actions Runner Controller

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

1. helm upgrade -i actions-runner-controller actions-runner-controller/actions-runner-controller \
2.   --version 0.23.7 \
3.   -n actions-runner-system

复制代码

输出：

1. Release "actions-runner-controller" does not exist. Installing it now.
2. NAME: actions-runner-controller
3. LAST DEPLOYED: Mon Aug 26 16:14:06 2024
4. NAMESPACE: actions-runner-system
5. STATUS: deployed
6. REVISION: 1
7. TEST SUITE: None
8. NOTES:
9. 1. Get the application URL by running these commands:
10.   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}")
11.   export CONTAINER_PORT=$(kubectl get pod --namespace actions-runner-system $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
12.   echo "Visit http://127.0.0.1:8080 to use your application"
13.   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。

1. kubectl apply -f - <<EOF                 
2. apiVersion: actions.summerwind.dev/v1alpha1
3. kind: Runner
4. metadata:
5.   name: deploy-web-dev-runner
6.   namespace: actions-runner-system
7. spec:
8.   repository: mingchangge/deployWeb
9.   env: []
10. EOF

复制代码

查看Runner

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

复制代码

输出：

1. NAME                    ENTERPRISE   ORGANIZATION   REPOSITORY              GROUP   LABELS   STATUS    MESSAGE   WF REPO   WF RUN   AGE
2. 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下令，整个docker私有镜像安装node或允许以办理，现在不想直接在服务器中安装node。这个问题我现在一脑门子浆糊，往后稍稍。）

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

复制代码

7.1：排错

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

github项目settings/Actions/runners：

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

1. NAME                                         READY   STATUS     RESTARTS   AGE
2. actions-runner-controller-5c996cd9c7-gqm5g   2/2     Running    0          2d19h
3. 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

1. kubectl apply -f - <<EOF
2. apiVersion: actions.summerwind.dev/v1alpha1
3. kind: RunnerDeployment
4. metadata:
5.   name: deploy-web-dev-runner
6.   namespace: actions-runner-system
7. spec:
8.   template:
9.     spec:
10.       repository: mingchangge/deployWeb
11.       env: []
12. 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 的服务

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

复制代码

输出：

1. Release "actions-runner-controller" has been upgraded. Happy Helming!
2. NAME: actions-runner-controller
3. LAST DEPLOYED: Fri Aug 30 10:48:23 2024
4. NAMESPACE: actions-runner-system
5. STATUS: deployed
6. REVISION: 2
7. TEST SUITE: None
8. NOTES:
9. 1. Get the application URL by running these commands:
10.   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}")
11.   export CONTAINER_PORT=$(kubectl get pod --namespace actions-runner-system $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
12.   echo "Visit http://127.0.0.1:8080 to use your application"
13.   kubectl --namespace actions-runner-system port-forward $POD_NAME 8080:$CONTAINER_PORT

复制代码

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

1. apiVersion: networking.k8s.io/v1
2. kind: Ingress
3. metadata:
4.   name: actions-runner-controller-github-webhook-server
5.   namespace: actions-runner-system
6.   annotations:
7.     nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
8. spec:
9.   ingressClassName: nginx # 使用这个字段来指定Ingress控制器
10.   tls:
11.   - hosts:
12.     - rancher.lxq.com
13.     secretName: tls-rancher-ingress
14.   rules:
15.     - http:
16.         paths:
17.           - path: /actions-runner-controller-github-webhook-server
18.             pathType: Prefix
19.             backend:
20.               service:
21.                 name: actions-runner-controller-github-webhook-server
22.                 port:
23.                   number: 8090

复制代码

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

复制代码

GitHub新增webhook

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

• vi webhook-service.yaml
  1. apiVersion: v1
  2. kind: Service
  3. metadata:
  4.   name: webhook-service
  5.   namespace: actions-runner-system # 或者是你的命名空间
  6. spec:
  7.   type: LoadBalancer
  8.   externalIPs:
  9.         - 192.168.XX.XXX
  10.   selector:
  11.      app.kubernetes.io/instance: actions-runner-controller-github-webhook-server
  12.      app.kubernetes.io/name: actions-runner-controller
  13.      pod-template-hash: 6b4f5cf858
  14.   ports:
  15.     - appProtocol: http
  16.       name: http
  17.       nodePort: 30080
  18.       port: 8090
  19.       protocol: TCP
  20.       targetPort: http

  复制代码
• kubectl apply -f webhook-service.yaml
  1. kubectl get service webhook-service -n actions-runner-system
  2. # 输出：
  3. NAME              TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)          AGE
  4. 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文件中指定。要查看或确认通过这种方式创建的资源的命名空间，你可以：

• 直接查看YAML文件：
  在YAML文件中查找metadata部分，看是否有namespace字段。例如：
  
  1. metadata:
  2.   name: my-resource
  3.   namespace: my-namespace

  复制代码
  如果namespace字段存在，那么资源就被创建在了这个命名空间内。如果namespace字段不存在，那么资源将被创建在当前的kubectl上下文中所设置的命名空间内，通常这会是default命名空间。
  
• 使用kubectl get下令：
  你也可以使用kubectl get下令并指定-A或--all-namespaces参数来查看全部命名空间中的资源。例如，要查看全部命名空间中的全部资源，可以运行：
  
  1. kubectl get all --all-namespaces

  复制代码
  从输出中，你可以找到你创建的资源，并看到它地点的命名空间。
  
• 使用kubectl config下令：
  如果你想要知道当前kubectl上下文的命名空间，可以使用：
  
  1. kubectl config current-context

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

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

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

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

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

复制代码

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

1. kubectl delete service my-service

复制代码

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

1. kubectl delete -f <path-to-file>

复制代码

将<path-to-file>替换为YAML文件的路径。
2. 使用kubectl apply和--delete-collection

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

1. 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的服务。
要删除由这个文件创建的全部资源，可以使用：

1. kubectl delete -f deployment.yaml

复制代码

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

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

复制代码

但请注意，--delete-collection和--force的使用要谨慎，确保你理解其举动和大概的后果。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。