配置 Kubernetes 集成
配置 Kubernetes 集成包括两个步骤:
1.启用后端从 Kubernetes 集群收集对象 2.在目录实体中显示 Kubernetes 对象
配置 Kubernetes 集群
下面是app-config.yaml
:
kubernetes:
serviceLocatorMethod:
type: 'multiTenant'
clusterLocatorMethods:
- type: 'config'
clusters:
- url: http://127.0.0.1:9999
name: minikube
authProvider: 'serviceAccount'
skipTLSVerify: false
skipMetricsLookup: true
serviceAccountToken: ${K8S_MINIKUBE_TOKEN}
dashboardUrl: http://127.0.0.1:64713 # url copied from running the command: minikube service kubernetes-dashboard -n kubernetes-dashboard
dashboardApp: standard
caData: ${K8S_CONFIG_CA_DATA}
caFile: '' # local path to CA file
customResources:
- group: 'argoproj.io'
apiVersion: 'v1alpha1'
plural: 'rollouts'
- url: http://127.0.0.2:9999
name: aws-cluster-1
authProvider: 'aws'
- type: 'gke'
projectId: 'gke-clusters'
region: 'europe-west1'
skipTLSVerify: true
skipMetricsLookup: true
exposeDashboard: true
`服务定位器方法
这将配置如何确定组件在哪个集群中运行。
有效值为
multiTenant
- 该配置假定所有组件都在提供的所有集群上运行。singleTenant
- 该配置假定当前组件在提供的集群中的一个集群上运行。
clusterLocatorMethods
`集群定位器方法
这是一个数组,用于确定从何处检索群集配置。
有效的群组定位方法有
catalog
这种群集定位方法将收集资源的类型kubernetes-cluster
要使用这种方法检测到资源,该资源还必须具备以下条件注释(如这里在代码中):
kubernetes.io/api-server
,表示 Kubernetes 控制平面的基本 URL *kubernetes.io/api-server-certificate-authority
,包含一个 PEM 格式的 base64 编码证书授权包;Backstage将检查控制平面是否出示了由该授权机构签署的证书。 *kubernetes.io/auth-provider
,表示用于与控制平面进行身份验证的策略。
还有许多其他注释可应用于集群资源,以配置 Backstage 的通信方式,记录如下这里下面是一个 YAML 代码段,以目录中的集群为例进行说明:
apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
name: my-cluster
annotations:
kubernetes.io/api-server: 'https://127.0.0.1:53725'
kubernetes.io/api-server-certificate-authority: # base64-encoded CA
kubernetes.io/auth-provider: 'oidc'
kubernetes.io/oidc-token-provider: 'microsoft'
kubernetes.io/skip-metrics-lookup: 'true'
spec:
type: kubernetes-cluster
owner: user:guest
请注意,在目录实体的注解中存储 Kubernetes 服务账户令牌是不安全的(很容易被目录 API 意外泄露),因此没有与服务帐户令牌使用的配置因此,目录群定位器不支持服务帐户认证策略。
如果将这种方法与摄取程序(如实体提供者(安装文件这里)或集群处理器来自动更新由 Backstage 跟踪的群集集群。
config
此集群定位器方法将从应用程序配置中读取集群信息(见下文)。
clusters
用于config
集群定位器方法来构建 Kubernetes 客户端。
clusters.\*.url
Kubernetes 控制平面的基本 URL,可通过运行kubectl cluster-info
指挥。
clusters.\*.name
代表该群集的名称,该名称在clusters
用户将在软件目录 Kubernetes 插件中看到此值。
clusters.\*.authProvider
这决定了 Kubernetes 客户端与 Kubernetes 集群的验证方式。 有效值为
| Value | Description | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |aks
| 这将使用用户的 AKS 访问令牌。微软认证提供商访问 AKS 集群上的 Kubernetes API。aws
| 这将使用 AWS 凭据访问 EKS 群集中的资源。azure
| 这将使用Azure 身份识别以访问集群中的资源 | |google
| 这将使用用户的 Google 访问令牌。谷歌认证提供商访问 GKE 集群上的 Kubernetes API。googleServiceAccount
| 这将使用 Google 云服务帐户凭据访问群集中的资源。oidc
| 这将使用Oidc 代币来验证 Kubernetes API。oidcTokenProvider
请注意,集群必须支持 OIDC,在撰写本文时,AKS 集群不支持 OIDC。serviceAccount
| 这将使用 Kubernetes服务账户访问 Kubernetes API。serviceAccountToken
字段也应设置,否则 Backstage 应在集群内运行。
检查Kubernetes 验证部分进行补充说明。
clusters.\*.skipTLSVerify
.
这决定了 Kubernetes 客户端是否验证 API 服务器提供的 TLS 证书。 默认为false
.
clusters.\*.skipMetricsLookup
.
这将决定 Kubernetes 客户端是否查找 API 服务器返回的 pod 的 CPU/内存资源指标。 默认为false
.
clusters.\*.serviceAccountToken
(可选)
时使用的服务帐户令牌。serviceAccount
请注意,除非你有一个有效的凭证轮换程序,或者有一个同时运行 Backstage 和所有服务的 Kubernetes 集群 ,否则这个认证提供程序可能不是生产的理想选择。
假设您已经创建了一个名为SERVICE_ACCOUNT_NAME
名称空间NAMESPACE
并有足够的权限下面是一些示例程序,用于获取与该提供程序一起使用的长期服务帐户令牌:
- On versions of Kubernetes prior to 1.24, you could get an (automatically-generated) token for a service account with:
sh kubectl -n <NAMESPACE> get secret $(kubectl -n <NAMESPACE> get sa <SERVICE_ACCOUNT_NAME> -o=json \ | jq -r '.secrets[0].name') -o=json \ | jq -r '.data["token"]' \ | base64 --decode
* For Kubernetes 1.24+, as described in this guide, you can obtain a long-lived token by creating a secret:sh kubectl apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: <SECRET_NAME> namespace: <NAMESPACE> annotations: kubernetes.io/service-account.name: <SERVICE_ACCOUNT_NAME> type: kubernetes.io/service-account-token EOF
waiting for the token controller to populate a token, and retrieving it with:```sh kubectl -nget secret <SECRET_NAME> -o go-template=
如果群组有authProvider: serviceAccount
和serviceAccountToken
字段被省略时,backstage 将忽略配置的 URL 和证书数据,而是尝试通过集群内客户端访问 Kubernetes API,如以下所示本例.
clusters.\*.oidcTokenProvider
(可选)
该字段在使用oidc
它将使用配置的Backstage授权提供者所选的oidcTokenProvider
需要在auth
才能正常工作。
kubernetes:
clusterLocatorMethods:
- type: 'config'
clusters:
- name: test-cluster
url: http://localhost:8080
authProvider: oidc
oidcTokenProvider: okta # This value needs to match a config under auth.providers
auth:
providers:
okta:
development:
clientId: ${AUTH_OKTA_CLIENT_ID}
clientSecret: ${AUTH_OKTA_CLIENT_SECRET}
audience: ${AUTH_OKTA_AUDIENCE}
前台支持以下开箱即用的值:gitlab
(的应用程序clientId
授权提供程序所使用的openid
范围)、google
,microsoft
,okta
,onelogin
.
请注意oidcTokenProvider
只是令牌的发行者,您可以在启用了 OIDC 的集群中使用其中任何一种,例如使用microsoft
作为 EKS 群集的签发器。
clusters.\*.dashboardUrl
(可选)
指定指向管理该群集的 Kubernetes 面板的链接。
请注意,应使用dashboardApp
属性,以便正确格式化指向 kubernetes 资源的链接,否则它会认为你运行的是标准的。
还请注意,对于某些类型的仪表盘(如 GKE),该属性是可选的,因为 GKE 需要在dashboardParameters
选择。