APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

Backstage Kubernetes PluginでAKS 上のアプリケーション情報を表示しよう

5月4日

5月4日といえばスターウォーズの日。実はここ2年、(特に内容はスターウォーズとは関係ありませんが)この日を記念してBlog記事を投稿させて頂いていました。

2022年 techblog.ap-com.co.jp

2023年 techblog.ap-com.co.jp

2年も続けたのだから今年も頑張って記事をひねり出したいと思います。

Backstage Kubernetes Plugin

もう1年も前になりますが、以前BackstageのKubernetes Pluginをご紹介していました。

techblog.ap-com.co.jp

このときはBackstage上でどういった内容が表示されるのか、といったものはご紹介しましたが、実際にどうすればその内容を表示できるのかまではご紹介しませんでした。

そこで今回は1年ぶりにAKS利用時のkubernetes plugin設定方法についてご紹介します。

Kubernetes Plugin設定方法

なにはともあれ、 Kubernetes Pluginをインストールします。ここは基本的にはBackstage公式ドキュメントに従って作業を行えばOKです。

backstage.io

ポイントはこの作業のあとにあります。

Kubernetes PluginでAKSの情報を表示する際のポイントは2つ。アクセスする先の「Kubernetes Clusterの指定方法」とBackstageから Kubernetes Clusterへアクセスする際の「アクセス時の認証方式」の指定です。

Cluster情報の指定方法

Cluster接続先の指定方法はclusterLocatorMethodsに記載された内容にしたがい、 app-config.yaml に記載します。

kubernetes:
  enabled: true
  serviceLocatorMethod:
    type: 'multiTenant'
  clusterLocatorMethods:
    - type: 'catalog'
    - type: 'config'
      clusters:
        - name: another-cluster-name
          url: https://your-cluste.hcp.region.azmk8s.io
          authProvider: aks
          skipTLSVerify: true

AKSを利用する場合、一般的にはつぎの2通りをCatalog Cluster Locator として利用することになると思います。

上記の例を見て分かる通りconfigで指定する場合、app-config.yaml にその接続先を指定します。設定としては簡単ですが、Clusterが増加した場合、app-config.yaml を更新してBackstageを再起動しなければなりません。 これに対して catalog の場合は app-config.yaml には catalogを使ったCluster情報の登録を宣言するのみで、Backstageのカタログ情報としてCluster接続先を登録します。カタログ情報はBackstageのデータベースに格納するものであり、更新も比較的容易です。もし可能であればこちらの方式を採用するほうがよいのではないかと思います。 今回はcatalogのみを利用するため、config の指定はコメントアウトしましょう。

kubernetes:
  enabled: true
  serviceLocatorMethod:
    type: 'multiTenant'
  clusterLocatorMethods:
    - type: 'catalog'
    # - type: 'config'
    #   clusters:
    #     - name: another-cluster-name
    #       url: https://your-cluste.hcp.region.azmk8s.io
    #       authProvider: aks
    #       skipTLSVerify: true

カタログ情報としてCluster情報を登録するには Resouceというkindを利用します。

apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
  name: <cluster name>
  annotations:
    'kubernetes.io/api-server': 'https://<aks-cluster-fqdn>.hcp.<region>.azmk8s.io'   # AKSの 「APIサーバーのアドレス」を指定します
    'kubernetes.io/auth-provider': 'aks'   # 以下で説明するアクセス時の認証方式の内容
    'kubernetes.io/api-server-certificate-authority': ''   # ここは空白文字を指定してください
    'kubernetes.io/skip-tls-verify': 'true'
    'kubernetes.io/skip-metrics-lookup': 'true'
spec:
  type: kubernetes-cluster                       # kubernetes cluster情報のTypeである  `kubernetes-cluster` を指定します。
  owner: group:guests

アクセス時の認証方法

Kubernetes Clusterにアクセスする際の認証方式は使用方法に応じて複数用意されています。

  • Server side : azure
    Backstage BackendにEntraID の認証情報を登録しておき、そのトークンを利用してAKS Clusterにアクセスします。
  • Server side : serviceAccount
    Backstage BackendにKubernetes Service Account情報を登録しておき、そのトークンを利用してAKS Clusterにアクセスします。
  • Client side: aks
    Backstage frontendでユーザーのEntraIDでサインインし、そのトークンを利用してAKS Clusterにアクセスします。

Servier sideで認証する場合は、(ユーザーの権限とは関係なく)Backstageにアクセスできるユーザーが閲覧することができます。 それに対してClient sideで認証する場合、Entra IDでサインインし、ユーザーが保持している権限でAKSにアクセスするようになるため、閲覧権限に沿ったアクセスができるようになります。

今回はClient sideで認証する方式(aks)をご紹介します。

aks を利用する場合は認証方式としてBackstage側に microsoft を指定する必要があります。

bacend側に、以下のようにpluginを追加します。

    backend.add(import('@backstage/plugin-kubernetes-backend/alpha'));

続いてEntra IDにアプリケーションを登録し、「email、ofline_access、openid、profile、User.Read」権限を割り当て、以下のようにBackstageのapp-config.yaml に情報を追加します。

auth:
  environment: production
  providers:
    github:
      production:
        clientId: <github-client-id>
        clientSecret: <github-client-secret>
        signIn:
          resolvers:
            - resolver: usernameMatchingUserEntityName
    microsoft:    # ここ以降を追加
      production:
        clientId: <entra-id-app-registratoin-client-id>
        clientSecret: <entra-id-app-registration-client-secret>
        tenantId: <entra-id-tenant-id>

Azure(AKS Cluster)へのアクセスのみ行う場合はBackstage SignInPageの修正は不要です。

これでBackstage側の修正は完了です。
最後に連携したいComponentにkubernetes pluginの連携情報を埋め込みます。

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  namespace: default
  annotations:
    backstage.io/kubernetes-label-selector: app=your-app    # Clusterでアプリケーションを検索する際のlabel selector
    backstage.io/kubernetes-namespace: your-nns
    backstage.io/kubernetes-cluster: cluster-name 
  name: app-name
spec:
  type: service
  owner: group:guests
  lifecycle: experimental
  dependsOn:
    - resource:your-cluster-name                                               # Resourceで指定した名前

アプリケーションを特定する方法はいくつかありますが、ここではlabel selectorを用いています。

まとめ

Kubernetesという外部システムと連携するにあたって、単にPluginを導入するだけではなく、いくつかの選択肢の中から連携方法を選択し、その内容に基づいてコンフィグレーションやカタログ情報を登録しなければならないということで、Kubernetes Pluginは少し面倒な部分があったように思います。実際この記事に至るまでに1年の時間が必要でした。今回とあることをきっかけに再整理して、「こうすればいい感じになる」ということを掴んだように思いましたので皆さんに共有させていただきました。

こうした情報の共有が皆さんの「フォース」となれば幸いです。

ということで、最後はこの言葉で締めたいと思います。

May (the) fourth(4th) be wit you!!

それではまた来年。