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

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值