Upgrade to Pro — share decks privately, control downloads, hide ads and more …

EKSの運用あれこれ バージョンアップ編

 EKSの運用あれこれ バージョンアップ編

2022/6/27(月) AWS好きエンジニア LT会 vol.2 #5

B379fea91de26a078727b50e89c91b60?s=128

tetsunosato

June 27, 2022
Tweet

Other Decks in Technology

Transcript

  1. EKSの運用あれこれ バージョンアップ編

  2. 自己紹介 • 宮國 哲生 • ビッグツリーテクノロジー&コンサルティング (2017~) • DX事業部/クラウド CoE

    • Kubernetes歴:約3年 • 2021 APN AWS Top Engineer
  3. このLTの目標 • LTに慣れる(デビュー戦) • EKSのバージョンアップについて思うところを述べる →みなさんのEKSのバージョンアップ作業に関するヒントになったらうれしい

  4. EKS考える事いっぱい • Kubernetesの概念もAWSのベストプラクティスも分かったうえで、適切に組み合わせる必要性 →の割に設計や構築のノウハウがあまり転がってなくて苦労してきた。 • クラスタ構成: シングルクラスタ/マルチクラスタ • データプレーン:EKS on

    EC2 or Fargate • クラスタ(&ネットワーク)構築方法:eksctl、CFn、Terraform etc • バージョンアップ: インプレース/ブルーグリーン • 各種アドオン: どれを採用…? • セキュリティ: マネージドサービスを組み合わせつつどこまでやる…?
  5. EKS考える事いっぱい うわあ

  6. EKS考える事いっぱい • EKSに関わる各種技術要素で、どういう考えで採用して、実際に構築・運用してみてどう 思ったかをつらつらと述べていく活動をやっていきたい。 →今日のLTはその練習

  7. バージョンアップ: 無視できない作業です • EKSを採用し、運用していく中で避けられない作業 • 1年で3回のリリース →バージョンアップノウハウの確立は大事 https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html

  8. バージョンアップ: インプレース or ブルーグリーン インプレースバージョンアップ <メリット> • アップデートの作業が少なくすむ →クラスタが変わらないので、CI/CDツールの設定や 監視ツールのダッシュボードを直さなくてすむ

    <デメリット> • 問題が発生した際にバージョンを戻すことができない • EKSがデフォルトで適用している各種アドオン(KubeProxy等)のバージョンアップを自分たちでやる 必要がある Cluster v1.21 nodegroup v1.22 nodegroup node node node node
  9. バージョンアップ: インプレース or ブルーグリーン ブルーグリーンバージョンアップ <メリット> • 新バージョンの検証を行った上で切り替えることができる • 上手くいかなかった場合に戻せる保険がある

    <デメリット> • 切替手順が複雑 • 旧環境と新環境向けの資材を正しく管理しておく必要がある • クラスタが2つあることによるオペミスが起こりうる Green Cluster Blue Cluster v1.21 nodegroup v1.22 nodegroup node node node node
  10. バージョンアップ: ブルーグリーンってどうなんだい • ブルーグリーンバージョンアップデメリット多すぎ…? →上手くいかなかった場合にバージョンを戻せる →各種アドオンのバージョンアップグレード検証、アプリケーションの動作確認などをゆっくり行える →心理的に安全な分ブルーグリーンの方がうれしい • 旧環境と同等の環境をいかに素早く簡単にコピーできるか、がカギ →veleroやargocdの利用を合わせて検討した方がよい

    →argocdのエクスポート/インポート機能を利用中
  11. バージョンアップ: 準備 • バージョンアップ作業でまずやるのが、事前の影響調査&スケジュール検討 <影響調査> • Kubernetes自体のバージョンアップの影響 • 各種機能のα、β、GA、非推奨、廃止の状況を確認。 •

    EKS、eksctl特有の変更要素 • 1.22時点ではまだdocker→containerdへは設定変更が必要。 • 各種アドオンのバージョンアップ要否 • 各種アドオンのインストール手順、リリースノート、変更履歴を漁って、バージョンアップ要否を決める。 →結構インストール手順はころころかわる →入れるアドオンが多ければ多いほどタイヘン • アプリケーションへの影響 • 二重稼働ができないジョブ等が動かない期間に実施(もしくは止める)
  12. バージョンアップ: ブルーグリーン切替手順 正直詳細な手順を書いてもすぐに陳腐化するので、作業者が「バージョンアップ慣れ」することが大事。大体の流れは以下。 • ArgoCD設定エクスポート • Green Cluster向け資材修正 • Green

    Cluster接続環境セットアップ • Cluster&NodeGroup作成 • ArgoCD設定インポート • 必要に応じてアドオン最新バージョンインストール • CI/CD設定変更 • CloudFrontビヘイビア変更 • 監視設定変更
  13. バージョンアップ: 頻度 • バージョンアップは毎回必ずやる必要はある? →必須ではないが、できる限り毎回やった方がいいと思う まとめてバージョンアップすると、 変更要素が多い分追従が大変 作業者もバージョンアップのノウハウがたまっていかない • 問題が発生するリスクが増えると思う

  14. バージョンアップ: まとめ • EKSのバージョンアップ戦略について、思うところをつらつらと • インプレースの方が作業量は少ない、ブルーグリーンの方が安心。ブルーグリーン大好き。 • ブルーグリーンの場合、旧環境と同等の環境をいかに素早く簡単にコピーできるか、がカギ • バージョンアップの影響調査はKubernetes自体、EKS特有、各種アドオン、アプリケーション等多

    角的に調査 • 詳細な手順を作っても陳腐化しやすいので、運用作業者がバージョンアップの一連の作業に慣れ ることが大事 • バージョンアップはできるだけ毎回やった方がリスクは減る