在 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)
- 登录到你的GitHub账户。
- 访问设置页面,找到“Developer settings”部分。
- 在“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 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 驱动扩展,成不成功的先做个记录。
补充一(GitHub 的自动清理机制)
GitHub 会自动清理长时间未连接的 self-hosted runner。如果 runner 在 14 天内没有连接到 GitHub Actions,它将被自动删除。
所以,在我半年多后再看这个项目,我的 self-hosted runner 木有了!(不过14天好像也不是很准确,在本次修改之后我又隔了一个多月没有使用,这次runner没有被清除掉!)
没有就没有吧,再整一个就是了,最大的问题就是k8s pod配置里面的镜像拉取不下来。本次又花了很大力气找国内镜像源,最后成功将k8s的 pod 跑了起来,github的runner也再次成功出现了。
题外话:最近提供docker hub的国内镜像网站一个接一个的不能访问,有条件的话,还是自建一个docker代理镜像(仅我可见文章,勿点链接)比较好。 我最后还是用了公司搭建的docker代理镜像地址,希望一直好用吧。
最后,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
-
编写 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
-
构建镜像
docker build -f runner-install-nodejs -t custom-actions-runner:nodejs .
-
验证node是否安装
docker run -it custom-actions-runner:nodejs node -v
-
创建或更新 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
-
应用RunnerDeployment 配置
kubectl apply -f deploy-web-dev-runner.yaml
输出:
runnerdeployment.actions.summerwind.dev/deploy-web-dev-runner configured
-
验证安装
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 "…
-
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镜像
-
将本地镜像加载到集群中
- 在本地机器上保存镜像为一个文件:
docker save -o custom-actions-runner.tar custom-actions-runner:nodejs
- 将保存的镜像文件传输到 Kubernetes 节点上
scp custom-actions-runner.tar root@<your-server-ip>:/root/k8s-user-images
,如节点服务器上没有/root/k8s-user-images
路径,需要新建。(这一步只是给镜像文件挪了个位置,如果是在本机上打包镜像且后续操作也都是在本机,完全可以省略。) - 在 Kubernetes 节点上加载镜像
ctr -n k8s.io images import /root/k8s-user-images/custom-actions-runner.tar
或ctr -n k8s.io images import 本机镜像位置
- 验证镜像是否加载成功
crictl images
输出:IMAGE TAG IMAGE ID SIZE ... docker.io/library/custom-actions-runner nodejs eb73026102c4b 1.31GB ...
- 在本地机器上保存镜像为一个文件:
-
重复步骤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的
代理端口
写在上面的环境变量就可以啦! 代理端口在更多设置-通用里查看。另外需要注意开启允许局域网连接。
补充五 查看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
- 配置 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
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文件中指定。要查看或确认通过这种方式创建的资源的命名空间,你可以:
-
直接查看YAML文件:
在YAML文件中查找metadata
部分,看是否有namespace
字段。例如:metadata: name: my-resource namespace: my-namespace
如果
namespace
字段存在,那么资源就被创建在了这个命名空间内。如果namespace
字段不存在,那么资源将被创建在当前的kubectl
上下文中所设置的命名空间内,通常这会是default
命名空间。 -
使用
kubectl get
命令:
你也可以使用kubectl get
命令并指定-A
或--all-namespaces
参数来查看所有命名空间中的资源。例如,要查看所有命名空间中的所有资源,可以运行:kubectl get all --all-namespaces
从输出中,你可以找到你创建的资源,并看到它所在的命名空间。
-
使用
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
的使用要谨慎,确保你理解其行为和可能的后果。