この記事は はてなエンジニア Advent Calendar 2023 の 26 日目の記事です。 本日からはてなエンジニア Advent Calendar 2023 はオーバーランに突入します。昨日は id:d-haru さん明日は id:chaya2z さんとなっています。

私が所属するチームでは EKS を利用してサービスを運用しています。

developer.hatenastaff.com

今年の AWS re:Invent 2023 内でも EKS 関連のアップデートがありましたが、特に EKS Pod Identity という便利な機能に注目したので利用してみました。

EKS Pod Identity とは

EKS を利用者にとって嬉しい機能が発表されました。これまで Pod への IAM 権限の割り振りは IRSA ( IAM Roles for Service Accounts ) を利用するのが一般的でした。Pod に権限を与えるという結果は両者変わらないのですがリソースの管理方法が異なります。

IRSA を利用した場合は以下のような manifest を書くことで kubernetes の ServiceAccount と IAM Role を紐づけていました。

 apiVersion: v1
 kind: ServiceAccount
 metadata:
   name: sample
   annotations:
     eks.amazonaws.com/role-arn: arn:aws:iam::XXXXXXXXXXXX:role/sample-role-arn

ServiceAccount リソースの annotation に IAM Role の Arn を記述しています。manifest に Arn を埋め込むのって面倒ですよね。特に IaC などしている場合、IaC で作成したリソースの Arn をなんとかして埋め込みたくなると思います。

今回、発表された EKS Pod Identity は IAM Role と ServiceAccount の紐づけを kubernetes 側ではなく EKS 側の設定で行うことができるため、IaC との親和性も高く権限管理が簡素化されます。

使い方と解説

アドオンのインストール

コンソールを使った方法は以下のリンクを参照するのが良いと思います。

aws.amazon.com

今回は Terraform を利用した方法で試してみます。

まず、EKS Pod Identity を利用するには eks-auth:AssumeRoleForPodIdentity のポリシーが必要です。事前に Node の Role に AmazonEKSWorkerNodePolicy を利用するかカスタムポリシーでを作成してアタッチしておく必要があります。

EKS Pod Identity は EKS アドオンで追加できるようになっています。 EKS の Terraform module を利用した場合、以下のようにしてアドオンを追加することができます。

module "eks" {
  source  = "terraform-aws-modules/eks/aws"


  cluster_name    = var.cluster_name
  cluster_version = var.cluster_version


  ...
  
  cluster_addons = {
    kube-proxy             = {}
    eks-pod-identity-agent = {}
  } 
}

余談ですが上記に記述しているアドオンの name は以下のコマンドを叩くことで確認することができます。

• aws eks describe-addon-versions | grep addonName

さらにアドオンのバージョンやconfigのオプションについても以下のコマンドで確認することができます。

• aws eks describe-addon-versions --addon-name eks-pod-identity-agent

• aws eks describe-addon-configuration --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1

EKS Pod Identity のアドオンを有効にすると kuberntes クラスターの kube-system Namespace に eks-pod-identity-agent が Daemonset としてインストールされエージェントの Pod が起動します。

$ kubectl get daemonset -n kube-system eks-pod-identity-agent
NAME                     DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
eks-pod-identity-agent   1         1         1       1            1           <none>          3d1h

このエージェントは Node に付与した AssumeRoleForPodIdentity のアクションを利用して、一時的な認証情報を取得し、コンテナ内の SDK がその認証情報を利用できるようにします。 Node 側でまとめて認証してくれるので各 Pod 毎に認証をすることがなくなっています。

docs.aws.amazon.com

IAM Role の信頼ポリシー

IRSA ではクラスター毎に OIDC プロバイダーを作成する必要があり、OIDC プロバイダーが EKS と IAM の信頼関係を確率していました。 そのためIAM Role に以下のような信頼ポリシーを設定する必要がありました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:SERVICE_ACCOUNT_NAME",
          "oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

クラスター固有の情報が含まれているため、クラスターが増える度に全ての IAM Role の信頼ポリシーを更新する手間が発生していました。

EKS Pod Identity を利用するとその手間は無くなり、OIDC プロバイダーも作成する必要もありません。 IAM Roleの信頼ポリシーは以下を追加すればよくて、固有のクラスター情報を含まないシンプルなものになりました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:TagSession",
                "sts:AssumeRole"
            ]
        }
    ]
}

クラスターの BlueGreen アップグレード時の IAM Role の更新の手間が減り作業もシンプルになります。

ServiceAccount と IAM Roleの関連付け

kubernetes の ServiceAccount と IAM Role の関連付けについてですが、マネコンから紐づけることもできますが以下の Terraform リソースを利用することで IaC 管理できます。

registry.terraform.io

resource "aws_eks_pod_identity_association" "example" {
  cluster_name    = aws_eks_cluster.example.name
  namespace       = "example"
  service_account = "example-sa"
  role_arn        = aws_iam_role.example.arn
}

Terraform で IAM Role を作成していれば Arn の Attribute を参照することができるので ServiceAccount と IAM Role の関連付けが Terraform 内だけで完結します。もう manifest に Arn を記述する必要はありません。

まとめ

まとめると以下のような設定が必要です。

• Node の IAM Role に eks-auth:AssumeRoleForPodIdentity を付与する
• EKS Pod Identity アドオンをインストール
• IAM Role の信頼ポリシーを EKS Pod Identity に対応したものに設定する
• IAM Role と ServiceAccount を関連付ける

上記4点を全て IaC で管理できるので EKS と kubernetes のリソースを独立して管理できます。必要なリソースと内部的な処理も簡略化されているため導入・運用の観点からもこれまでよりも良くなっていると感じました。

2024/01/05 追記

利用しているサービスによっては SDK のバージョンが古く利用できない場合があるため注意が必要でした。secrets-store-csi-driver-provider-aws で利用している SDK のバージョンが v1.47.10 と古いため直近での EKS Pod Identity の利用は見送るつもりです。今後、利用できることを楽しみにしています。

github.com

docs.aws.amazon.com

参考

• Amazon EKS が EKS Pod Identity を導入
• Amazon EKS Pod Identity simplifies IAM permissions for applications on Amazon EKS clusters | AWS News Blog
• EKS Pod Identities - Amazon EKS

• 🆕 EKS で、Pod に IAM Role を割り当てる新機能として EKS Pod Identity がリリースされました！IAM roles for service accounts (IRSA) と比較して、シンプルに設定することが可能です。 (1/6)https://t.co/WQz4kQVN0m

  — Kyosuke Ochimizu (@otty246) 2023年11月28日

この記事ははてなエンジニアのカレンダー | Advent Calendar 2022 - Qiitaの14日目のエントリです。

背景

私のチームで運用しているEKSクラスターですが、アップグレードはBlueGreenアップグレードする方針をとっています。 B/Gアップグレードを採用している主な理由は切り替え時に問題が発生した場合に素早く切り戻しを行いたいためです。

詳細は以下のブログを参照ください。

developer.hatenastaff.com

B/Gアップグレードのおおまかな流れは以下の通りです。

1. 新バージョンのEKSクラスターを構築する
2. ArgoCDに新クラスター用のデプロイ設定を手動で作成してアプリケーションをデプロイする
3. Route53やAWS Global Acceleratorの設定を変更して旧クラスタから新クラスタにリクエストを切り替える

上記の2と3の工程には以下のような課題を感じています。

• サービスが増えることで新クラスターに対するデプロイ設定の作業負荷が高くなってきている
• より手軽にすばやく切り替え、切り戻しを行えるようにしたい

上記について改善を行ってきたので紹介したいと思います。

実現したいこと

上記の課題より私達が実現したいことは以下の通りです。

• クラスタのバージョンアップ時など、デプロイ先のクラスタが増えた場合でも、アプリケーションを効率よくデプロイできるようにする
• 旧クラスターから新クラスターにリクエストを手軽に素早く切り替えられるようにする

解決へのアプローチ

ArgoCDのApplicationSetを利用する

ArgoCDはデプロイ設定をApplicationというカスタムリソースで管理しています。Applicationに主に定義している内容は以下の通りです。

• Manifestを取得するリポジトリとブランチやリビジョン
• デプロイ先のクラスター
• Namespace

B/Gアップグレード時にはデプロイ先のクラスターが異なる、2つのApplicationを作成する必要があります。デプロイするアプリケーションが多いほど管理が煩雑になっていきます。

ApplicationSetはApplicationの管理をまとめることができます。 これを利用することで複数のクラスター分のApplicationリソースを自動的に作成することができます。

さらにGeneratorというパラメータを利用することで、ArgoCDに登録されているクラスターや指定したクラスターのリスト分だけApplicationを作成することが可能です。

argo-cd.readthedocs.io

ApplicationSetを利用することで新旧クラスター用のデプロイ設定を、効率よく管理できるようになると考えています。

AWS Loadbalancer ControllerのTargetGroupBindingを利用する

AWS Loadbalancer ControllerはKubernetesのアドオンです。 KubernetesのIngressリソースを作成するとALBがプロビジョニングされます。

つまり以下の図のようにクラスター毎にALBが作成されます。

この方法だと基本的にはDNSの切り替えでクラスター移行することになります。これでも問題はないのですが、DNSをキャッシュしているクライアントがあった場合に完全に切り替わるのを待つ必要があります。

AWS Loadbalancer ControllerにはTargetGroupBindingというカスタムリソースがあります。これを利用すると既存のTargetGroupを利用してPodを公開することができます。

つまりIngressを作成しないためALBはIaCなどKubernetesのライフサイクルの外で管理できます。

TargetGroupBindingを利用すると以下の図のように、新旧クラスターで同じALBを利用して、異なるTargetGroupにぶら下がる構成となります。

これによりALBのWeightedRoutingをが利用でき、新クラスターにリクエストを少しずつ移行することが可能となります。

クラスタ別のリソース定義の書き換えをどうするか

ここまで紹介した内容の改善を行って来た結果、一部問題が生じました。 TargetGroupBindingを利用すると、クラスター別で異なるTargetGroupのARNをManifestに記述する必要があります。 このARNをどのようにして書き換えるかという問題が生じました。

私達はKustomizeを利用して環境毎(Dev/Stg/Prd)のManifestの管理を行っています。そのため新旧クラスター毎にディレクトリを分けてkustomization.yamlを作成しました。ApplicationSet においては、クラスター別にロードするパスを分けることで対応しました。具体的なファイル構成を以下に記述します。

ディレクトリツリー

├── production
│   ├── kustomization.yaml
│   ├── ...
├── production-blue-cluster
│   ├── kustomization.yaml
│   └── patches
│       └── targetgroupbinding.yaml
└── production-green-cluster
    ├── kustomization.yaml
    └── patches
        └── targetgroupbinding.yaml

上記の./production配下のファイル群はこれまでデプロイに利用していた既存のファイルです。 production-[blue|green]-clusterが新規追加したディレクトリとkustomization.yamlになります。

production-[blue|green]-cluster/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- ../production

patches:
  - patches/targetgroupbinding.yml

既存のkustomizeの構成には手を入れずTargetGroupBindingに関する記述のみpatchをあてるような構成にしています。

patches

---
apiVersion: elbv2.k8s.aws/v1alpha1
kind: TargetGroupBinding
metadata:
  name: my-tgb
spec:
  targetGroupARN: 'arn://hogefugapiyo'
  networking:
    ingress:
      - from:
        - securityGroup:
            groupID: 'sg-hogefugapiyo'

patchには新旧クラスターで異なるTargetGroupのARNとALBのセキュリティグループIDを記述します。

ArgoCD ApplicationSet

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-app
  namespace: my-service
spec:
  generators:
  - clusters: {} # Automatically use all clusters defined within Argo CD
  template:
    spec:
      source:
        path: k8s-manifest/project/production-{{cluster}} 
      ...

ArgoCDのApplicationSetではGeneratorを利用して{{cluster}}部分を変数化することで、自動的にB/Gクラスター用のデプロイ設定(Applicationリソース)を作成することができます。

さいごに

EKSクラスターのバージョンアップ作業を効率化するための取り組みについて紹介しました。 TargetGroupBindingを利用したクラスターのB/Gアップグレードはよく耳にしますが実際に私達の環境で実践してみると課題があり様々な解決方法があることを知りました。

今回、私達はこのブログに書いた方針で対応をとりましたが、今後運用を進めるとよりよい方法やツールを知ることになると思うので、このような改善は継続してどこかで公開できればと思います。

明日のはてなエンジニアAdvent Calendarは id:kouki_dan さんです。

背景

先日、Amazon Aurora MySQL version 1 ( MySQL 5.6 互換 ) のEOLが2023/02/28に予定されました ( 以降、Aurora MySQL v1と記述 )。 2022/09/27 からAurora MySQL v1の作成ができなくなります。 Aurora MySQL v1で動作しているクラスターをAurora MySQL v2 ( MySQL 5.7 互換 ) or Aurora MySQL v3 ( MySQL8.0 互換 )にバージョンアップする必要があります。

docs.aws.amazon.com

アップグレードの方法

アップグレードの方法は主にインプレースアップグレードとBlue/Greenアップグレードの2種類の方法があります。

インプレースアップグレード

docs.aws.amazon.com

利用中のクラスタでアップグレード処理を実施します。インスタンスのシャットダウンが発生しますが手順はシンプルです。エンドポイントはそのまま保持されるため変更の手間もありません。

Blue/Greenアップグレード

aws.amazon.com (英語ドキュメントしか無さそう)

新しくMySQL5.7のクラスタを構築して、MySQL5.6のクラスタからデータをレプリケーションすることで2つのクラスタが同じデータを保持している状態を作ります。最終的にエンドポイントの切り替えによってバージョンアップを実施します。インプレースアップグレードよりもダウンタイムを少なくすることができます。

インプレースアップグレードを実施して分かった問題

インプレースアップグレードはとてもざっくりですが↓の図のような流れでアップグレード処理が走ります。

問題なのは↑の赤いPending Reboot (再起動保留中) の状態で、再起動を待ちながらDBインスタンスは起動しています。 このPending Reboot (再起動保留中) の状態ではデフォルトのパラメータグループ( default.aurora-mysql5.7 )でAurora が動作している状態です。そしてカスタムパラメータ設定を適用するには手動で再起動を実施する必要があります。 これはドキュメントにも下記のように書いてあります。

アップグレードプロセス中にカスタムパラメータグループを指定した場合は、アップグレード終了後にクラスターを手動で再起動する必要があります。再起動すると、クラスターがカスタムパラメータ設定の使用を開始できます。

つまりアプリケーションを起動した状態でインプレースアップグレードを実施した場合、カスタムパラメータグループの内容によってはサービス影響が発生する可能性があります。

対策

アップグレードの前後でアプリケーションを停止する

インプレースアップグレードの所要時間はデータ量やクラスターのビジー状態によって変わってくるのでアプリケーションの停止時間が読みにくいというところはあります。

Blue/Greenアップグレードを採用する

Blue/Greenアップグレードはクラスタを新しく構築するためエンドポイントを参照している箇所を変更する必要があります。参照している箇所が把握できていなかったり、変更箇所が多かったりすると結構大変な作業になりそうです。

まとめ

• 2023/02/28 に Aurora MySQL v1 が EOL を迎えます
• アップグレードの方法はインプレースアップグレードとBlue/Greenアップグレードの2種類
• カスタムパラメータを利用してインプレースアップグレードを行う場合には注意が必要