■【抄訳】【途中で力尽きました】AKSの運用に関するベストプラクティス

はじめに

AKSの運用に関するベストプラクティス(原題: Applying best practices to Azure Kubernetes Service (AKS))がMS Igniteというイベントで話されていたので

内容をかいつまんで紹介します。

参考資料

映像

https://myignite.techcommunity.microsoft.com/sessions/81598?source=SessionDeck

ソースコード等

https://github.com/Azure/aks-bestpractices-ignite19

アジェンダ

このセッションでは下記の二つについて紹介します。

高可用性設計(High Availability)に関するベストプラクティス

クラスタ管理に関するベストプラクティス

高可用性について

今回取り扱うのは主にワーカーノードの高可用性です

• k8sにはマスターノードとワーカーノードという大きく二つのコンポーネントに分かれるが、本セッションで扱うのは主にワーカーノードです。

マスターノードについて

• コントローラプレーンの可用性は99.5%...ですが、基本的に費用がかからないのでSLO目標です。
• PIサーバーがダウンした場合スケールやデプロイなど新しいマネジメントオペレーションはできない。
• しかし、稼働中のアプリケーションは影響をうけない(訳注: したがってワーカーノードの方がより考慮すべき)
• それでもコントローラプレーンで高可用性を確保したい場合下記の方法がある
  • プレミアムSKUの採用:2019年の終わりに登場予定
  • 複数クラスタの構成(副作用があるのでコントローラプレーンの冗長性確保だけを目的として実施してはいけない)

ワーカーノード

RTO(リカバリ時間目標)とRPO(目標複数時点)に応じて下記の4通りのシナリオがある

4にいくにしたがって

RTO=復旧するまでの時間が短くなる

RO=より直近の状態で復旧できる

しかし、コストや構成の複雑さは増す。

1. バックアップとリストア

2. AZ(Availability Zone)

3. リージョン内の複数のクラスタ

4. リージョン間の複数のクラスタ

バックアップとリストア

• 下記の通り、ステートフル環境の方がバックアップとリストアが難しい。
  • ステートレスクラスタ: マニフェストファイルをデプロイしなおすだけ
  • ステートフル: マニフェストファイルをデプロイして、コンポーネントの状態をさらに再構築する必要がある

• どちらのクラスタにせよ、クラスタの構築は、再デプロイ処理をより早くするためにcluster deployment as code の必要がある

コードのバックアップ(スナップショット)方法

• スナップショットには二つのオプションがある
  • Azure Snapshot APIを使用したスナップショット
  • heptio ark/vmware veleroなどのOSSプロジェクト

AZを用いた冗長性確保

17:22～

• AKSクラスタはAvailability Zoneをまたいで分散ノードを作成できる
• AZとはAzure regison内の個々の物理的場所
• AZを利用すると99.99%の可用性
• 標準のAzure Disks(ストレージ)はZoneに紐づいている
• Zoneをサポートするリージョンの数は限りがある
  • 2019年11月現在は10リージョン(https://docs.microsoft.com/en-us/azure/availability-zones/az-overview )
  • 日本だと東日本のみ
• Zoneごとの分散処理を行うためにはStandard Load Balancer SKUが必要
  • Basic SKUはZone分散をサポートしていない

複数クラスタ構築

23:48～

• 同じリージョン内に複数のクラスタを構築する方法とリージョンをまたいで複数のクラスタを構築する方法がある
• データベースのR/Wをメインクラスタで行って他のクラスタでは基本的にレプリカ構成にしたデータベースでReadのみにする
  • 基本的に他のクラスタではReadしかできないので機能に制限がかかる(縮退運転)
  • CosmosDBを使用すればR/Wの制限なく構築できるが...(訳注: コストは一番高い)

(以下作業中)

最後に

Nofalさんごめんなさい、年末頑張って仕上げます。

Permalink | 記事への反応(0) | 23:00

ツイートシェア