Kubernetes - 如何在容器内运行kubectl命令？

Question

在pod中的容器中,如何使用kubectl运行命令？例如,如果我需要在容器内执行类似的操作:

kubectl获得pods

我试过这个:在我的dockerfile中,我有这些命令:

RUN curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
RUN chmod +x ./kubectl
RUN sudo mv ./kubectl /usr/local/bin/kubectl

编辑:我正在尝试OSX文件,我已将其更正为Linux二进制文件.(由@svenwltr更正

在创建docker文件时,这很成功,但是当我在容器内运行kubectl get pods时,

kubectl get pods

我收到此错误:

与服务器的连接:被拒绝 - 您是否指定了正确的主机或端口？

当我在本地部署时,如果我的docker-machine没有运行,我遇到了这个错误,但是在容器内部如何运行docker-machine？

在本地,我通过运行以下命令来解决此错误:(dev是docker-machine的名称)

docker-machine env dev
eval $(docker-machine env dev)

有人可以告诉我,我需要做什么？

Answer 1

我会使用kubernetes api,你只需要安装curl,而不是kubectl其余的是休息.

curl http://localhost:8080/api/v1/namespaces/default/pods

我在我的一个apiservers上运行命令.将localhost更改为apiserver ip address/dns名称.

根据您的配置,您可能需要使用ssl或提供客户端证书.

为了找到API端点,可以使用--v=8同kubectl.

例:

kubectl get pods --v=8

资源:

Kubernetes API文档

RBAC更新:

我假设您已经配置了rbac,为您的pod创建了一个服务帐户并使用它运行.此服务帐户应具有所需命名空间中的pod的列表权限.为此,您需要为该服务帐户创建角色和角色绑定.

群集中的每个容器都填充有可用于向API服务器进行身份验证的令牌.要验证,在容器内运行:

cat /var/run/secrets/kubernetes.io/serviceaccount/token

要向apiserver发出请求,请在容器内运行:

curl -ik \
     -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
     https://kubernetes.default.svc.cluster.local/api/v1/namespaces/default/pods

Answer 2

在这里聚会迟到了,但这是我的两分钱:

我发现kubectl在容器中使用比调用集群的api容易得多

(为什么？自动验证!)

假设您正在部署需要kubectl使用的Node.js项目.

1. kubectl在容器内下载和构建
2. 构建应用程序,复制kubectl到容器
3. 瞧! kubectl为管理您的kubernetes集群提供了丰富的cli

有用的文档

---编辑---

kubectl在我的群集窗格中工作后,我找到了一种更有效的方法来验证pod,以便能够进行k8s API调用.此方法提供更严格的身份验证.

1. ServiceAccount为您的pod 创建一个,并配置您的pod以使用该帐户.k8s服务帐户文档
2. 配置RoleBinding或ClusterRoleBinding允许服务具有与k8s API通信的授权.k8s角色绑定文档
3. 直接调用API,或使用k8s-client为您管理API调用.我强烈建议使用客户端,它具有pod的自动配置,删除正常请求所需的身份验证令牌步骤.

当你做,你将有以下几点: ServiceAccount,ClusterRoleBinding,Deployment(你的豆荚)

如果你需要一些更明确的方向,请随意发表评论,我会尽力帮助:)

Answer 3

第一个问题

/usr/local/bin/kubectl: cannot execute binary file

看起来你下载了OSX二进制文件kubectl.在Docker中运行时,您可能需要Linux:

https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl

第二个问题

如果您kubectl在正确配置的Kubernetes群集中运行,它应该能够连接到apiserver.

kubectl基本上使用此代码来查找apiserver并进行身份验证:github.com/kubernetes/client-go/rest.InClusterConfig

这意味着:

• apiserver的主机和端口存储在环境变量KUBERNETES_SERVICE_HOST和KUBERNETES_SERVICE_PORT.
• 访问令牌已安装到var/run/secrets/kubernetes.io/serviceaccount/token.
• 服务器证书已安装到/var/run/secrets/kubernetes.io/serviceaccount/ca.crt.

这是kubectl连接到apiserver时需要知道的所有数据.

一些想法为什么这可能不起作用:

• 容器不在Kubernetes中运行.
  • 使用相同的Docker主机是不够的; 容器需要作为pod定义的一部分运行.
• 使用授权插件限制访问(这不是默认设置).
• pod定义(spec.serviceAccountName)将覆盖服务帐户凭据.

Answer 4

I just faced this concept again. It is absolutely possible but let's don't give "cluster-admin privileges in with ClusterRole that container for security reasons.

Let's say we want to deploy a pod in the cluster with access to view and create pods only in a specific namespace in the cluster. In this case, a ServiceAccount could look like:

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: spinupcontainers
subjects:
- kind: ServiceAccount
  name: spinupcontainers
  namespace: <YOUR_NAMESPACE>
roleRef:
  kind: Role
  name: spinupcontainers
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: spinupcontainers
  # "namespace" omitted if was ClusterRoles because are not namespaced
  namespace: <YOUR_NAMESPACE>
  labels:
    k8s-app: <YOUR_APP_LABEL>
rules:
#
# Give here only the privileges you need
#
- apiGroups: [""]
  resources:
  - pods
  verbs:
  - create
  - update
  - patch
  - delete
  - get
  - watch
  - list
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: spinupcontainers
  namespace: <MY_NAMESPACE>
  labels:
    k8s-app: <MY_APP_LABEL>
---

If you apply the service account in your deployment with serviceAccountName: spinupcontainers in the container specs you don't need to mount any additional volumes secrets or attach manually certifications. kubectl client will get the required tokens from /var/run/secrets/kubernetes.io/serviceaccount. Then you can test if is working with something like:

$ kubectl exec -it <your-container-with-the-attached-privs> -- /kubectl get pods -n <YOUR_NAMESPACE>
NAME.        READY   STATUS    RESTARTS   AGE
pod1-0       1/1     Running   0          6d17h
pod2-0       1/1     Running   0          6d16h
pod3-0       1/1     Running   0          6d17h
pod3-2       1/1     Running   0          67s

or permission denied:

$ kubectl exec -it <your-container-with-the-attached-privs> -- /kubectl get pods -n kube-system
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:spinupcontainers" cannot list resource "pods" in API group "" in the namespace "kube-system"
command terminated with exit code 1

Tested on:

$ kubectl exec -it <your-container-with-the-attached-privs> -- /kubectl versionClient Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:20:10Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:12:17Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}