第100回 雲勉【オンライン：中級者向け】EKSのアップデートを安全に行う

Transcript

1. EKSクラスターを安全にアップデートする⽅法
2. ０．講師⾃⼰紹介 2 茅根 涼平(Ryohei Chinone) クラウドインテグレーション事業部 構築チーム グループリーダー アイレット歴5年⽬ AWS環境のインフラ設計、構築、運⽤ NewRelicを使⽤した監視設計・設定 TerraformやAnsibleなどのInfrastructure as Code対応
3. アジェンダ 3 0.⾃⼰紹介 1.前提知識 2.安全なバージョンアップ⽅法 3.検証 4.最後に 5.質疑応答
4. １. 前提知識 4
5. 5 EKSカレンダー Kubernetesクラスタを運⽤していると、 必ずバージョンアップ作業に直⾯する • 新しいバージョンは、およそ 4か⽉ごとにリリースされます • 各マイナーバージョンは、最初にリリースされてから約 12 か⽉間サポートされます • ⽉と年のみの⽇付はおおよその⽇付であり、確定後に正確な⽇付で更新されます • Kubernetes における規定のマイナーバージョンのサポート終了⽇については、 サポート終了⽇の少なくとも 60 ⽇前に発表されます https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar 1. 前提知識
6. 1. 前提知識 6 更新⽅法(ローリングアップデート) 1. 変更内容の確認 新しい Kubernetes バージョンでは、⼤幅な変更が加えられている場合があります。 そのため、更新前に Kubernetes バージョン の前提条件 にリストされている変更を適⽤することが必要です。 (例)変更点 EKS はバージョン 1.24 で Dockershim のサポートを終了 Amazon EKS 1.24 リリースでサポートが最終的に削除される前に、ユーザーは containerd に移⾏する必要があります。 など https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/update-cluster.html https://aws.amazon.com/jp/blogs/news/amazon-eks-now-supports-kubernetes-1-23/
7. 7 IUUQTEPDTBXTBNB[PODPNKB@KQFLTMBUFTUVTFSHVJEFVQEBUFDMVTUFSIUNM 1. バージョンの確認 コントロールプレーンを新しい Kubernetes バージョンに更新する前に、クラスター内のノードと Kubernetes マイナーバージョンが、コントロールプレーンのバージョンと同じであることを確認します。 異なる場合どうなるのか 更新⽅法(ローリングアップデート) 1. 前提知識
8. 8 IUUQTEPDTBXTBNB[PODPNKB@KQFLTMBUFTUVTFSHVJEFVQEBUFDMVTUFSIUNM コンソール画⾯やeksctl, Terraformなど、各⾃が管理している⽅法でアップデートを実⾏します。 ※クラスターを更新する前に 対象のクラスターに Kubernetes Cluster Autoscaler をデプロイしている場合は、更新後のKubernetes のメジャーバージョンと マイナーバージョンに⼀致するように、 事前にKubernetes Cluster Autoscaler を最新バージョンに更新します。 2.クラスターを更新 更新⽅法(ローリングアップデート) 3.ノードを更新 マネージド型ノードグループ セルフマネージド型ノード キャパシティ管理は⾃分で ⾏う(ASGなど利⽤) AWSがユーザーアカウントにASGを作成し、 キャパシティを管理します。 1. 前提知識
9. 9 作業前の状態と同じにするには再構築する必要があります。 この再構築作業には⻑時間を要するため、万が⼀を想定してシステム稼働・運⽤に影響を与えずに作業完了できるように仕組みを考えます。 問題点 AWSの仕様上、クラスターを前のバージョンに戻すことはできない ステータス上は問題ないけどサービス影響が出た ↓ 対策前進に時間がかかりそう ↓ 作業前の状態と同じにする • EKSクラスター/ノードの作成 • Helmfike(k8s マニフェスト)の作成 • 動作確認 1. 前提知識
10. 2. 安全なバージョンアップ⽅法 10
11. 11 • ローリングアップデート ソフトウェアの更新、⼊れ替えの⽅法の⼀つで、稼働中のシステムに直接ソフトウェアの更新や⼊れ替えを⾏うこと • Blue/Greenデプロイ 新旧の環境を⽤意して接続先を切り替えて公開する • カナリアリリース ⼀部のユーザに対して徐々に公開していく※Blue/Greenの⼀種 2. 安全なバージョンアップ⽅法 ⽅法 ⼯数 安全性 ローリングアップデート ワンクリックだから簡単 クラスターの切り戻し不可 Blue/Greenデプロイ 準備・切り替え・削除に時間がかかる 切り戻し可能 カナリアリリース 準備・切り替え・削除に時間がかかる 切り戻し可能
12. 12 ⽅法 クラスター ノード ClusterAutoscaler / アドオン Helmfike(k8s マニフェスト)の適⽤ 切替え ローリング ダウンタイムなしに 更新する仕様 ダウンタイムなしに 更新する仕様 アップデート実⾏ ダウンタイムが発⽣する 可能性があるので対策が必要 - Blue/Green カナリアリリース 新クラスターの構築 新ノードの構築 新しく構築 新しく構築 ALB/TGを更新する 2. 安全なバージョンアップ⽅法
13. 13 2. 安全なバージョンアップ⽅法 Blue/Greenとは 意図した動作になるように変更される 意図しない動作が発⽣したら影響を最⼩限にできる [デプロイの実施] Blue環境のトラフィックをGreen環境に切替える [ロールバックの実施] Green環境のトラフィックをBlue環境に切替える
14. 14 解決策その1 (LBのDNSを切替える) 作業⼿順 1. (切替前) EKSクラスタ/ノード/Podリソース等を構築 2. (当⽇)DNSを現ALBから新ALBに更新するように加重を更新する 3. (当⽇)問題なければ更新完了/問題があれば加重を戻す Route53の加重ルーティング機能は、同⼀レコード名で登録し、重み (Weight) を 各レコードに設定することでその重みに応じた割合でリクエストを振り分けることができます。 Route53の加重ルーティング 切替え前はアクセス先の加重を0/1(新0%/現100%)、加重を徐々に変更し、切替え完了時に1/0(新1０0%/現0%)にすることができます。 切替え 2. 安全なバージョンアップ⽅法
15. 15 2. 安全なバージョンアップ⽅法 解決策その1 (LBのDNSを切替える)
16. 16 解決策その2(Weighted Target Groups) 作業⼿順 1. (切替前) EKSクラスタ/ノード/Podリソース等を構築 2. (切替前) リスナールールに⼀致した場合は、 新環境にトラフィックが流れるようにする 3. (当⽇) ターゲットグループへ流す加重を変更する 4. (当⽇)問題なければ更新完了/問題があれば加重を戻す 2. 安全なバージョンアップ⽅法 加重ターゲットグループ機能は、転送先に複数のターゲットグループを設定し、重み (Weight) を ALBに設定することでその重みに応じた割合でリクエストを振り分けることができます。 Weighted Target Groups 切替え 切替え前はアクセス先の加重を0/1(新0%/現100%)、加重を徐々に変更し、切替え完了時に1/0(新1０0%/現0%)にすることができます。 また、リスナールールの追加で送信元IPを絞って新環境で動作確認することも可能です。
17. 17 解決策その2(Weighted Target Groups) 2. 安全なバージョンアップ⽅法
18. 18 更新時は並⾏して環境があるため、誤認識防⽌のためNameはEKSバージョンをプレフィックスにする 命名規則 2. 安全なバージョンアップ⽅法
19. 3. 検証 19
20. 20 EKSクラスター、ノード等を作成するのは時間がかかるため事前に⽤意した結果で解説します。 なお、実際に検証する際は「eksctl」などを使⽤すると便利です。 3. 検証 eksctlとはAmazon EKS の公式 CLI EC2 向けの Amazon マネージド Kubernetes サービスである EKS でクラスターを作成 および管理するためのシンプルな CLI ツールです。 ## 使⽤中とするEKSを準備 eksctl create cluster ﹨ --name chinone-kumoben ﹨ --version 1.22 ﹨ --region ap-northeast-1 ﹨ --node-type t3.small ﹨ --nodes 2 ﹨ --nodes-min 2 ﹨ --nodes-max 2 ##新クラスタを準備 eksctl create cluster ﹨ --name chinone-kumoben-124 ﹨ --version 1.24 ﹨ --region ap-northeast-1 ﹨ --node-type t3.small ﹨ --nodes 2 ﹨ --nodes-min 2 ﹨ --nodes-max 2 ﹨ --vpc-public-subnets=subnet-xxx,subnet-xxx,subnet-xxx ﹨ --vpc-private-subnets=subnet-xxx,subnet-xxx,subnet-xxx EKSの起動
21. 21 AWS Load Balancer Controllerのインストール ドキュメントの⼿順に沿って、AWS Load Balancer Controllerをインストールします。 AWS Load Balancer Controller は、Kubernetes クラスターで実⾏されているアプリケーションに トラフィックをルーティングする Elastic Load Balancing を構成および管理します。 3. 検証
22. 22 アプリケーションをデプロイ 3. 検証 各⾃アプリを⽤意 または サンプルアプリケーションなどを使⽤ https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/sample-deployment.html IUUQTBSDIJWFFLTXPSLTIPQDPNCFHJOOFS@FYQPTJOHTFSWJDF apiVersion: apps/v1 kind: Deployment … containers: - name: nginx image: public.ecr.aws/nginx/nginx:1.21 … apiVersion: apps/v1 kind: Deployment … containers: - name: app-2048 image: public.ecr.aws/l6m2t8p7/docker-2048:latest … コンテナーイメージ変更するなどして、 アクセス時の動作をわかりやすくします EKS1.22 EKS1.24
23. 23 解決策その1 (LBのDNSを切替える) 3. 検証
24. 24 解決策その1 (LBのDNSを切替える) % dig chinone-kumoben.xxxxx.xxx +short A 54.65.174.92 3.113.176.133 % dig chinone-kumoben.xxxxx.xxx +short A 3.113.176.133 54.65.174.92 % dig chinone-kumoben.xxxxx.xxx +short A 54.65.209.143 52.199.59.200 54.64.206.221 % dig chinone-kumoben.xxxxx.xxx +short A 54.64.206.221 54.65.209.143 52.199.59.200 % dig chinone-kumoben.xxxxx.xxx +short A 3.113.176.133 54.65.174.92 digコマンドでALBのIPアドレスが変わるがわかります 動作確認 3. 検証
25. 25 3. 検証 解決策その1 (LBのDNSを切替える) 動作確認 2つの環境にアクセス可能な状態
26. 26 3. 検証 解決策その2(Weighted Target Groups)
27. 27 3. 検証 解決策その2(Weighted Target Groups) ALB Weighted Target Groups とリスナールール(送信元IPで振り分け)を組み合わせて切り替えできる
28. 28 動作確認 解決策その2(Weighted Target Groups) 3. 検証 リスナールールを使⽤することで、実際にトラフィックを流してから動作確認することができます。 ※ネイティブアプリでスマホやタブレット等でhosts設定が難しい場合 送信元IPの対象外 送信元IPの対象
29. 29 3. 検証 無停⽌かつ数回の設定更新で移⾏可能
30. 4. 最後に 30
31. 31 4. 最後に 精神的負担が⼤きい サービス影響発⽣によるエンドユーザへの影響 αʔϏεதஅɺError Rate্ঢͳͲ ҰൃͰ੒ޭ͢Ε͹͍͍͚Ͳɺ੾Γ໭͕͠ඞཁʹͳͬͨΒΛߟ͑Δͱԯ߷ʹͳΔ ʮӡ༻ͰͳΜͱ͔͢Δʯɺʮτϥϒϧ͕ى͖͔ͯΒରԠ͢Δʯͱ͔ݴͱɺ਺ϲ݄ޙɺ਺೥ʹ௧͍ࢥ͍Λ͠·͢ɻ ໰୊͕ൃੜ͢ΔલʹɺͲͷΑ͏ʹEKSΛΞοϓσʔτ͢Δ͔͔ͬ͠Γߟ͑·͠ΐ͏ どのバージョンアップ⽅法があっているか考える
32. Thank you