一、背景
1、从开发角度
(1)服务通过容器化部署的方式运行在云环境的Pod中,然而在 Kubernetes 中,Pod 中的服务不能直接通过 client-go
访问 Kubernetes 资源,而是需要通过 Kubernetes API Server 来进行访问。client-go
库实际上是通过与 Kubernetes API Server 的交互来完成对 Kubernetes 资源的操作。
(2)在使用 client-go
时,通常需要提供 Kubernetes API Server 的地址、认证信息(如服务账号的凭证),以及所需的 API 访问权限(通过 RBAC 角色授权)。这些信息将帮助 client-go
库正确地建立与 Kubernetes API Server 的连接,并确保操作的安全性和正确性。
2、从调库角度
(1)在使用 Kubernetes API 客户端——client-go 的过程中,我们通常需要获取 *rest.Config 配置对象来与 Kubernetes API 服务器进行交互。
(2)通常有四种获取 *rest.Config 的方法
-
使用 kubeconfig 文件
-
kubeconfig 文件是一个 YAML 文件,用于指定 Kubernetes 集群的访问凭证、上下文和集群信息等。
-
-
使用 Kubernetes 集群内的 Service Account
-
在 Kubernetes 中,每个 Namespace 都有一个默认的 Service Account。ServiceAccount仅局限它所在的namespace,每个namespace创建时都会自动创建一个default service account。
-
ServiceAccount是给运行在Pod的程序使用的身份认证,Pod容器的进程需要访问API Server时用的就是ServiceAccount账户。
-
创建Pod时,如果没有指定Service Account,Pod则会使用default Service Account。
-
-
直接指定 API Server 的地址和认证信息
-
我们可以直接指定 API Server 的地址和认证信息来获取 *rest.Config 对象。直接将api地址和认证token配置到代码中,但实际开发中一般不用。
-
-
从环境变量、默认配置文件等多个来源获取配置信息
-
`genericclioptions.NewConfigFlags()` 方法可以从环境变量、命令行参数、默认配置文件等多个来源中获取 Kubernetes 集群的配置信息,并生成对应的 *rest.Config 对象。
-
二、在pod中调用自定义资源
1、pod绑定服务账号
(1)创建serviceAccount
apiVersion: v1 kind: ServiceAccount metadata: name: test-sa namespace: test |
(2)创建相关的角色/rbac
-
Role 只能用来给某个特定 namespace 中的资源作鉴权,对多 namespace 和集群级的资源或者是非资源类的 API(如 /healthz)使用 ClusterRole
-
ClusterRole用于所有namespace下的资源,例如需要具备操作