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

已于 2025-06-12 15:56:10 修改
阅读量1.1k 收藏 25
点赞数 21
CC 4.0 BY-SA版权
分类专栏： CI/CD 文章标签： kubernetes github 容器
于 2024-08-29 17:29:12 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/u012761510/article/details/141567154

在 Kubernetes 上运行的 GitHub Actions 的自托管 runner 是运行在 Kubernetes pod 的容器里，每个 runner 容器都是独立的，并且可以根据需要动态创建和销毁。这些 runner 容器由 Actions Runner Controller 管理，该控制器是一个 Kubernetes 自定义资源定义（CRD），用于自动化 runner 的生命周期管理。

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的权限。GitHub Personal Access Token

3：创建Kubernetes Secret

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

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

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
Rancher deploy-web-dev-runner截图
执行下面的命令，创建一个名为 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 状态。
github项目Runner截图

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运行。
runs-on修改截图
最后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
actions/setup-node

7.1：排错

runner运行完2天后再次修改前端项目，推送github后，忽然发现作业找不到机器执行，github settings/Actions的Runner列表也没有之前部署的Runner了，截图如下：
Runner执行作业：
Runner执行作业
github项目settings/Actions/runners：
github项目settings/Actions
查看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比之前多了一些后缀。
可重用Runner
之前的推送处理完成后，本次推送才开始进行处理。
runner运行情况
多个请求推送去 Actions 列表会发现，只有一个作业在运行，其他都是 queued 的等待状态。只有等前面的作业执行完成后，后一个作业才会被执行。
Actions 作业列表
由上图可知执行多个任务时，任务需要排队等候不支持并发。但是actions-runner-controller 在 3 个 Runner 的 CRD 之外，还提供了类似 HPA（水平 pod 自动扩缩容） 的 CRD HorizontalRunnerAutoscaler，简称 HRA。
HRA 可以根据指标 PercentageRunnersBusy 或者 TotalNumberOfQueuedAndInProgressWorkflowRuns 来对 runner 进行扩缩容，或者基于 GitHub Events（webhook）来进行扩缩容。这两种都各有优缺点，前者指标是通过 GitHub API 轮训等待的作业数，实现简单，但时效性差；后者基于事件触发时效性更佳，但是实现复杂，需要对外暴露访问端点接收 GitHub Event。
下面的参考的文章是使用前一项的，所以我准备试试Webhook 驱动扩展，成不成功的先做个记录。

补充一（GitHub 的自动清理机制）

GitHub 会自动清理长时间未连接的 self-hosted runner。如果 runner 在 14 天内没有连接到 GitHub Actions，它将被自动删除。

所以，在我半年多后再看这个项目，我的 self-hosted runner 木有了！（不过14天好像也不是很准确，在本次修改之后我又隔了一个多月没有使用，这次runner没有被清除掉！）
没有就没有吧，再整一个就是了，最大的问题就是k8s pod配置里面的镜像拉取不下来。本次又花了很大力气找国内镜像源，最后成功将k8s的 pod 跑了起来，github的runner也再次成功出现了。
题外话：最近提供docker hub的国内镜像网站一个接一个的不能访问，有条件的话，还是自建一个docker代理镜像(仅我可见文章，勿点链接)比较好。 我最后还是用了公司搭建的docker代理镜像地址，希望一直好用吧。
self-hosted runner
最后，k8s pod的配置修改是在Rancher里面修改完成的，不得不说界面化是真好啊。
…
还是直接覆盖原有配置吧，因为我新建的pod会在执行完任务后被销毁，重建时会读取原配置，只在rancher修改一个pod配置是不行的。

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: []
      containers:
      - name: runner
        image: docker.xxxx.com/summerwind/actions-runner:latest
EOF

补充二（创建自定义的 runner 镜像）

npm install失败后就在工作流中增加了actions/setup-node@v2，但是自托管runner机器执行node下载任务时，耗费了大量的时间，从昨天下午到今天上午执行一次任务耗时短则7m 23s长则1h 18m 45s。为了可以快速拿到结果，尝试使用自定义runner镜像。自定义runner镜像里安装了nodejs。

name: 设置 Node.js
      uses: actions/setup-node@v2
      with:
        node-version: "18"

name: 安装依赖
  run: |
    echo "npm install"
    if [ "${{ steps.npm-cache.outputs.cache-hit }}" != "true" ]; then
      npm i --registry=https://registry.npmmirror.com
    fi
  shell: bash

  1. 编写 Dockerfile

    #在服务器的根目录下新建文件夹完成此项工作
mkdir dockerFile
cd dockerFile
# 新建Dockerfile文件
vim runner-install-nodejs

    runner-install-nodejs：

    FROM docker.xxxxx.com/summerwind/actions-runner:latest
# 下载安装 Node.js
RUN curl -fsSL https://deb.nodesource.com/setup_20.x |sudo -E bash -
RUN sudo apt-get install -y nodejs

  2. 构建镜像

    docker build -f runner-install-nodejs -t custom-actions-runner:nodejs .

  3. 验证node是否安装

    docker run -it custom-actions-runner:nodejs node -v

    验证node安装

  4. 创建或更新 RunnerDeployment 配置

    vim deploy-web-dev-runner.yaml

    deploy-web-dev-runner.yaml:

    apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
  name: deploy-web-dev-runner
  namespace: actions-runner-system
spec:
  template:
    spec:
      repository: mingchangge/deployWeb
      env: []
      containers:
      - name: runner
        image: custom-actions-runner:nodejs
        imagePullPolicy: Never

  5. 应用RunnerDeployment 配置

    kubectl apply -f deploy-web-dev-runner.yaml

    输出：
    runnerdeployment.actions.summerwind.dev/deploy-web-dev-runner configured

  6. 验证安装

    kubectl get pods -n actions-runner-system

    输出：

    NAME                                                              READY   STATUS              RESTARTS   AGE
...
deploy-web-dev-runner-5mr8s-nhltg                                 1/2     ErrImageNeverPull   0          22s
...

    Rancher pod输出报错：Failed to pull image “custom-actions-runner:nodejs”: rpc error: code = DeadlineExceeded desc = failed to pull and unpack image “docker.io/library/custom-actions-runner:nodejs”: failed to resolve reference “docker.io/library/custom-actions-runner:nodejs”: failed to do request: Head "https://registry-1.docker.io/v2/library/custom-actions-runner/manifests/nodejs "…

  7. docker images命令查看custom-actions-runner镜像存在，继续查看镜像是否已经被正确加载到 Kubernetes 节点上。
    通过kubectl get nodes -o wide 查看节点信息,确定使用的是哪种容器运行时。
    k8s集群使用的是 CRI（Container Runtime Interface）兼容的容器运行时（ containerd），可以使用 crictl 命令检查镜像：

    # 查看custom-actions-runner镜像是否已被正确加载到 Kubernetes 节点上
crictl images

    输出结果无custom-actions-runner镜像

  8. 将本地镜像加载到集群中

    1. 在本地机器上保存镜像为一个文件：docker save -o custom-actions-runner.tar custom-actions-runner:nodejs
    2. 将保存的镜像文件传输到 Kubernetes 节点上scp custom-actions-runner.tar root@<your-server-ip>:/root/k8s-user-images，如节点服务器上没有/root/k8s-user-images路径，需要新建。（这一步只是给镜像文件挪了个位置，如果是在本机上打包镜像且后续操作也都是在本机，完全可以省略。）
    3. 在 Kubernetes 节点上加载镜像ctr -n k8s.io images import /root/k8s-user-images/custom-actions-runner.tar 或ctr -n k8s.io images import 本机镜像位置
    4. 验证镜像是否加载成功crictl images
      输出：
      IMAGE                                                                                         TAG                 IMAGE ID            SIZE
...
docker.io/library/custom-actions-runner                                                       nodejs              eb73026102c4b       1.31GB
...

  9. 重复步骤5和步骤6（ 应用RunnerDeployment 配置和验证安装）

    kubectl apply -f deploy-web-dev-runner.yaml

kubectl get pods -n actions-runner-system

    输出：

    NAME                                                              READY   STATUS             RESTARTS   AGE
...
deploy-web-dev-runner-5mr8s-l7dlh                                 2/2     Running            0          3m51s

推送测试项目，执行工作流，速度迅速提升。

补充三 crictl images 报错 validate service connection…

crictl images输出警告报错如下：

WARN[0000] image connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead. 
ERRO[0000] validate service connection: validate CRI v1 image API for endpoint "unix:///var/run/dockershim.sock": rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial unix /var/run/dockershim.sock: connect: no such file or directory"

解决：

sudo tee /etc/crictl.yaml <<EOF
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 0
debug: false
pull-image-on-create: false
EOF

补充四 自定义镜像配置代理

在执行任务时偶尔会有因为runner连不上github导致任务失败，一次两次或许可以忍受，但次数多了，难免叫人焦躁。于是决定在dockerfile中设置网络代理使其可以访问github网站。操作如下：

  • 修改dockerfile文件，self-runner-image（runner-install-nodejs改名为self-runner-image）

    FROM summerwind/actions-runner@sha256:8af42...
# 添加 ENV 指令来设置代理环境变量
ENV RUNNER_UPDATE_DISABLED=true \ 
    http_proxy=http://192.168.xx.xxxx:xxxx \
    https_proxy=http://192.168.xx.xxxx:xxxx \
    no_proxy=localhost,127.0.0.1,xxx.com # xxx.com是我名字缩写的一个域名，之前尝试过*.xxx.com但是会匹配失败。

RUN curl -v https://github.com/ # 必须，去掉此句，执行到安装nodejs会报错
# 自定义证书
COPY registry.crt /usr/local/share/ca-certificates/registry.crt
RUN sudo update-ca-certificates
# 下载安装 Node.js
RUN curl -fsSL https://deb.nodesource.com/setup_20.x |sudo -E bash -
RUN sudo apt-get install -y nodejs

    打包镜像命令：docker build -f /root/k8s_rancher/dockerFile/self-runner-image -t self-runner-image:v0.0.1 /root/k8s_rancher/ssl/
    将镜像保存为tar文件：docker save -o self-runner-image.tar self-runner-image:v0.0.1
    将本地镜像加载到集群：ctr -n k8s.io images import self-runner-image.tar

  • 代理服务器设置：我的代理服务器使用clash代理上网。所以，找到代理服务器的ip地址加上clash的代理端口写在上面的环境变量就可以啦! 代理端口在更多设置-通用里查看。另外需要注意开启允许局域网连接。
    clash允许局域网连接

补充五 查看runnerDeployment命令

kubectl get runnerdeployment -n actions-runner-system
输出：

NAME                    ENTERPRISE   ORGANIZATION   REPOSITORY              GROUP   LABELS   DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deploy-web-dev-runner                               mingchangge/deployWeb                              2         1            1           213d

kubectl describe runnerdeployments -n actions-runner-system
输出：

Name:         deploy-web-dev-runner
Namespace:    actions-runner-system
Labels:       <none>
Annotations:  <none>
API Version:  actions.summerwind.dev/v1alpha1
Kind:         RunnerDeployment
Metadata:
  Creation Timestamp:  2024-08-29T05:51:26Z
  Generation:          50
  Resource Version:    114473563
  UID:                 71f02e3a-03da-4354-8520-6728dbe82bba
Spec:
  Effective Time:  <nil>
  Selector:        <nil>
  Template:
    Metadata:
    Spec:
      Containers:
        Image:              custom-actions-runner:nodejs
        Image Pull Policy:  Never
        Name:               runner
        Resources:
      Dockerd Container Resources:
      Image:       
      Repository:  mingchangge/deployWeb
      Resources:
Status:
  Available Replicas:  1
  Desired Replicas:    1
  Ready Replicas:      1
  Replicas:            2
  Updated Replicas:    1
Events:                <none>

kubectl get runners -n actions-runner-system
输出：

NAME                                ENTERPRISE   ORGANIZATION   REPOSITORY              GROUP   LABELS   STATUS    MESSAGE   WF REPO   WF RUN   AGE
deploy-web-dev-runner                                           mingchangge/deployWeb                    Running                                216d                              4d
deploy-web-dev-runner-nt7tf-5hpnn                               mingchangge/deployWeb                    Running                                4d

kubectl get pod deploy-web-dev-runner-nt7tf-5hpnn -n actions-runner-system -o yaml
输出：

apiVersion: v1
kind: Pod
    ...
    securityContext:
      privileged: true
    ...

Docker In Docker (dind) 允许开发人员在已经运行的 Docker 容器中运行 Docker 容器，以支持 CI/CD
管道并创建沙盒容器环境,是 ARC 中的默认容器模式。ARC 允许用户将 dind 作为带有运行器容器的 docker
sidecar 容器运行，或在一个容器中运行整个运行器容器。在这种情况下，任何时候 ARC 运行器需要运行 docker
映像，它都会将其作为 dind 容器内的嵌套容器运行。它还可以像典型的虚拟机主机一样发出“docker build”命令，以使用
docker 守护程序构建容器映像。 这种方法的主要安全问题是它需要 Kubernetes 中的特权模式。Docker
守护程序可以访问主机的底层内核。特权模式允许 Kubernetes 容器逃离其命名空间并访问整个 Kubernetes
主机。这可能会危及整个 Kubernetes 集群。有几种众所周知的攻击媒介可以滥用特权模式来获取 Kubernetes
中的主机访问权限。由于 GitHub Actions 主要在此特权环境中运行第三方代码，因此恶意依赖项或构建工具可以利用特权模式突破运行器
pod 并持久存在于 Kubernetes 节点上。这是 ARC 中最不安全的容器模式。

(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。
    GitHub新增webhook
    创建完成后发现webhooke不能正常工作
    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
如何在 Actions Runner Controller (ARC) Runner 中安全地使用 Docker

补充内容：

k8s小白使用命令记录：

查看 ingress配置

kubectl describe ingress -n cattle-system

查看secret

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

修改secret

kubectl patch secret controller-manager -n actions-runner-system --type=merge -p '{"data":{"github_token":"QUdJQVEzUVpSNEU3QlRLVzdRUFYyV0xIMk9XRk8="}}'

注意：Secret 中的值需要是 Base64 编码的！

echo -n "AGIAQ3QZR4E7BTKW7QPV2WLH2OWFO" | base64
QUdJQVEzUVpSNEU3QlRLVzdRUFYyV0xIMk9XRk8=

查看使用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的使用要谨慎，确保你理解其行为和可能的后果。

在 Linux 上设置自托管的 GitHub Actions Runner教程
代码简单说 Vue、JAVA、PHP、Node.js 熟练运用，接口、架构、性能全搞定。
12-06 179
在本指南中，我们将介绍如何在 Linux 服务器上设置自托管的 GitHub Actions runner。设置步骤包括创建一个专用用户、下载并配置 runner 包，以及将其配置为在后台自动启动的 systemd 服务。
厉害了!GitHub大神的K8S+SpringCloud笔记，从基础到进阶都很细致
weixin_50666791的博客
09-09 392
我们都知道Docker 虽好用，但面对强大的集群，成千上万的容器，突然感觉不香了。 这时候就需要我们的主角 Kubernetes 上场了，先来了解一下 K8s 的基本概念，后面再介绍实践，由浅入深步步为营。 关于 K8s 的基本概念我们将会围绕如下七点展开： Docker 的管理痛点 什么是 K8s？ 云架构 & 云原生 K8s 架构原理 K8s 核心组件 K8s 的服务注册与发现 关键问题 Docker 的管理痛点 如果想要将 Docker 应用于庞大的业务实现，是存...
使用Github Action搭建k8s测试环境
u012803274的博客
04-18 1247
前言 好久没有写博客了，因为测试的还没弄好，所以没啥好写的，不过现在第一版测试已经做好了， 所以这里简单分享一下使用Github Action做发布测试的经验 简介 项目托管在Github上，已经做了构建镜像的操作，也就是使用Github Action workflow做了构建镜像的操作， 但是测试还没做。而我最近刚转到这个项目组，所以就开始做简单的测试工作啦。项目的主要语言是Go，主要是开发一个云原生工具， 协助开发者更快的进行代码反馈，举个栗子????，比如你的项目部署在远端kubernetes clu
k8s常用github网站
weixin_30692143的博客
04-15 5045
1、集群安装地址 https://github.com/gjmzj/kubeasz 2、harbor安装地址 https://github.com/goharbor/harbor-helm 3、chart网站地址 https://hub.kubeapps.com/ 4、安装fluentd网站地址 https://github.com/cuishuaig...
在GitHub标星120k的阿里K8s源码笔记，真就无敌了呗
JavaJIAMIN的博客
01-11 430
Kubernetes是发展最快的基础设施项目之一。在短短五年的时间里，它已经成熟，成为现代基础设施的基础。从公有云中的托管容器即服务（CaaS）到数据中心中的企业平台即服务（PaaS），Kubernetes正变得无处不在。 在Kubernetes早期，它主要被认为是运行web级无状态服务的平台。有状态的服务（如数据库和分析工作负载）要么在虚拟机中运行，要么作为基于云的托管服务运行。但随着Kubernetes成为最受欢迎的基础设施层，其生态系统努力使有状态应用程序成为Kubernetes领域的重要一份子。
使用Nginx在 Linux 上托管 ASP.NET Core 6.0应用：GitHub Actions自动部署
henntai的博客
08-14 868
本文完整介绍了如何使用Github Actions做CI&CD，将ASP.NET Core 6.0 程序部署到阿里云Ubantu服务器，并使用Nginx作为web服务器，systemd做守护进程。
使用 GitHub Action 自动更新 K8s 集群的应用镜像
云原生实验室
10-13 933
在现代软件开发中，持续集成 (CI) 和持续部署/交付 (CD) 是至关重要的环节。它们可以帮助开发团队高效地验证代码的质量并确保其准确无误地交付到生产环境中。GitHub Action 正是在这个背景下诞生的 CI/CD 工具，致力于为开发者提供一种简洁且高效的自动化工具。简单来说，GitHub Action 是一个 CI/CD 工具，它允许开发者在 GitHub 仓库中自动执行多种任务，从而极大地提高了工作效率。
GitHub Actions Runner Operator：高效管理Kubernetes上的GitHub动作
自托管GitHub Actions运行器可以为用户带来以下优势：提升工作流程的安全性，因为敏感数据和代码不会离开用户控制的环境；能够访问私有资源，例如私有仓库或内部服务；可以更好地控制运行器资源，包括硬件规格和网络...
使用GitHub Actions实现前后端CI/CD到云服务器
最新发布
weixin_62799021的博客
09-17 1376
如果你要部署到github pages或者你不用SSR（服务端渲染），那就构建（SSG）静态站点。
GitHub自托管Action跑步者精选比较矩阵
自托管的GitHub Action Runner 是指在用户自己控制的环境中运行的GitHub Actions任务，而不是在GitHub提供的公共环境中。这种方式对于需要特殊配置、更严格的权限管理或更高的运行器资源的场景特别有用。 接下来，...
gcr-sync:通过github action自动从k8s.gcr.io同步同步到dockerhub
03-11
gcr同步 通过github action自动从k8s.gcr.io同步同步到dockerhub
Kubernetes源码，2018.07.18从GitHub上下载
07-20
Kubernetes源码，2018.07.18从GitHub上下载的。Kubernetes 已成为在私有云、公有云和混合云环境中大规模部署容器化应用的事实标准。AWS、Google Cloud、Azure、IBM Cloud 和 Oracle Cloud 等几个最大的公有云平台都可以为 Kubernetes 提供托管服务。
厉害了!GitHub 大神的 K8S+SpringCloud 笔记，从基础到进阶都很细致
weixin_70730532的博客
07-27 565
K8s是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。K8s拥有一个庞大且快速增长的生态系统。K8s的服务、支持和工具广泛可用。快速部署应用快速扩展应用无缝对接新的应用功能节省资源，优化硬件资源的使用但是在小编学习k8s和Docker发现没有能将两个技术点整合并运用的学习资料，我翻阅了各大平台网站都没有发现真正能把k8s和Docker讲解的十分透彻，最终在一位大佬的指点下，我拿到了这份Docker+Kubernetes笔记，k8s。...
膜拜大佬！阿里内部都在强推的K8S(kubernetes)学习指南，不能再详细了
资料免费分享，点击名片
07-10 1417
过去几年，以 docker、kubernetes 为代表的容器技术已发展为一项通用技术，BAT、滴滴、京东、头条等大厂，都争相把容器和 k8s 项目作为技术重心，试图“放长线钓大鱼”。 就说阿里吧，目前基本所有业务都跑在云上，其中有一半已迁移到自己定制 kubernetes 集群上。据说，今年计划完成 100% 基于 k8s 集群的业务部署。而服务网格这块儿，在阿里的一些部门（比如蚂蚁金服），已经有线上业务在用了。 这充分说明了容器在当今软件研发领域的地位。所以，掌握容器技术自然成为很多公司在招聘时的重要选
膜拜，GitHub大佬手码K8S+Jenkins笔记，太强了
公众号：该用户快成仙了
08-08 308
软件开发生命周期软件开发瀑布模型软件的敏捷开发什么是持续集成持续集成的组成要素持续集成的好处Jenkins介绍。
kubeadm 搭建 kubernetes 集群
moonpure的专栏
11-29 8828
一、环境准备 首先环境还是三台虚拟机，虚拟机地址如下 IP 地址 节点 192.168.1.167 master 192.168.1.189 node1 192.168.1.176 node2 然后每台机器安装好 docker，至于 rpm 安装包版本下面介绍 二、说点正经事 2.1、安装包从哪
k8s镜像下载不下来？利用 github Action 自己动手一次性解决难题，丰衣足食
热门推荐
LoveSummer
12-13 5万+
无论是在学习k8s还是正式环境部署k8s中,第一步安装k8难倒了各大英雄好汉。原因是k8s 各种组件镜像在谷歌服务器上(k8s.gcr.io)，而我们有墙的存在，所以会经常性的下载失败。解决办法是搭梯子，或者是使用其他镜像源。本仓库使用配合 github action 同步 k8s docker镜像(k8s.gcr.io) 到 dockerhub。提高k8s docker镜像(k8s.gcr.io)成功率，解决云原生第一大难题。docker-image-syncer 运行原理下拉所需镜像。
厉害了！GitHub大神的K8S+SpringCloud笔记，从基础到进阶都很细致
公众号：该用户快成仙了
08-17 186
我们都知道Docker 虽好用，但面对强大的集群，成千上万的容器，突然感觉不香了。这时候就需要我们的主角 Kubernetes 上场了。但是在小编学习k8s和Docker发现没有能将两个技术点整合并运用的学习资料，我翻阅了各大平台网站都没有发现真正能把k8s和Docker讲解的十分透彻，最终在一位大佬的指点下，我拿到了这份Docker+Kubernetes笔记，笔记中全面的讲解了Docker相关知识。
基于k8s搭建gitlab
い末路伤徊
09-29 920
基于k8s安装gitlab
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值