[レポート] CON301: Mastering Kubernetes on AWS #reinvent

大栗です。

現在re:Inventに来ています。こちらでKubernetesのセッションに参加したのでレポートします。

Mastering Kubernetes on AWS

本記事はAWS re:Invent 2018のセッション「CON301-R -- [REPEAT] Mastering Kubernetes on AWS」のレポートです。

Kubernetes offers a powerful abstraction layer for managing containerized infrastructure. Amazon Elastic Container Service for Kubernetes (Amazon EKS) makes it easy to run Kubernetes on AWS without having to manage master nodes or the etcd operator. In this session, we cover what you need to know to get your application up and running with Kubernetes on AWS. We show how Amazon EKS makes deploying Kubernetes on AWS simple and scalable, including networking, security, monitoring, and logging.

スピーカーはAWSのシニアビジネスデベロップメントマネージャーであるYaniv Donenfeld氏とSnapchatのSenior Director of EngineeringsであるKarl D'Adamo氏です。

レポート(AWSパート)

開発でコンテナを動かすのは簡単です。このコマンドだけでできます。

# vi Dockerfile
# docker build -t mykillerapp:0.0.1 .
# docker run -it mykillerapp:0.0.1 .

しかし本番環境のデータプレーンは大量にあったり、コントロールプレーンを高可用に維持しなければなりません。

そう、すごく大変です。

Kubernetesのワークロードの51%はAWSで動いています。

そこでAmazon EKSです。

クロスアカウントでEKSを起動して、コントロールプレーンとワーカーノードを別アカウントに展開することもできます。

Networking: Pod to pod

Kubernetesのネットワークには3個のルールがあります。

  • すべてのPodはNAT無しで直接通信する
  • すべてのノードがすべてのPodとNAT無しで通信する(逆も同様)
  • Podがそれ自体で見ているIPは、他が見ているのと同じIP

AWS VPC CNI plugin

プライマリのCIDRレンジはRFC 1918のアドレスの範囲になるので、"10/8", "172.16/12", "192.168/16"となります。

  • EKSではPod、マスタからワーカーへの通信(exec、ログ、プロキシなど)、インターナルKubernetesサービスネットワーク(VPCのレンジに10.100/16か172.20/16を選択)で使用する。
  • セットアップは、EKSクラスタを作成して、サブネットのリスト(少なくとも2AZ)を設定して、タグの設定。

セカンダリのCIDRレンジ(New!)はRFC 1918以外のアドレス(100.64.0.0/10, 198.19.0.0/16)が利用できる

  • Amazon EKSではPodのみで使用できる。(CNI 1.2.1以上)
  • Amazon EKSのカスタムネットワークの設定、有効化、ENIConfig CRDの作成、ノードのアノテーション設定

AWS VPC CNI pluginの設定可能性

  • カスタムネットワーク設定
  • SNAT / 外部SNAT
  • 設定可能なウォームプール

Networking: Pod to service

サービスタイプがClusterIPの場合は、

  • クラスタのインターナルIP上にサービスを公開する
  • クラスタ内からのみアクセス可能
  • kube-proxy経由でアクセス可能
  • バッキングサービス、ラップトップからの接続、内部ダッシュボードの表示に役立つ

サービスタイプがNodePortの場合は、

  • 各ノードの静的ポートにサービスを公開する
  • クラスタIPへのルーティング、これは自動で作成される
  • クラスタの内部から :
  • 1ポートに1サービス
  • ポートは30000-32767

サービスタイプがLoadBalancerの場合は、

  • クラウドプロバイダーのロードバランサを使って外部にサービスを公開する
  • NodePortとClusterIPサービス(LBにルーティングされる)が自動で作成される。
  • ロードバランサ付きの各サービスは自分のIPアドレスを得る
  • L4(TPC)かL7(HTTP)サービスを公開する

サービスロードバランサー: NLB

NLBはクライアントのIPアドレスの転送をサポートしている

  • . spec.exteralTrafficPolicy = Local の場合はクライアントIPがポッドに渡される
  • 一致するポッドのないノードは指定されたNLBのヘルスチェック .spec.healthCheckNodePort で削除される
  • DaemonSetかPodアンチアンフィニティを使用してトラフィックを分離する

サービスタイプがExternalNameの場合は、

  • サービスをCNAME(externalNameフィールド)にをマッピングする
  • プロキシを使用しない
  • 他のサービスを同様にmy-serviceワーカーにアクセスする
  • DNSレベルのリダイレクトが起こる(プロキシやフォワードでなく)

Kubernetesの入力オブジェクト

  • サービス内のクラスタへのルートをHTTP/HTTPSで公開する
  • 様々な実装: ALB、Nginx、F5、HAProxyなど
  • デフォルトのサービスタイプはClusterIP

Logging: workers

EFKでロギングを実装

EKSのワーカーノードに対してdaemonsetでfluentdを起動、CloudWatch Logsを経由したり直接でElasticsearch Serviceにサブスクライブして、kibanaで可視化する

レポート(Snapchatパート)

Snapchatでは、インフラストラクチャのゴールとして、柔軟性、セキュリティ、可用性/性能、コスト低減、運用作業の最小化の5つを上げています。

2016年のSnapの技術状況は、少数の大きなモノリシックアプリケーションでした。プロジェクトは柔軟性がなく、インプラストラクチャは長いポールから始まりました。

2016年での悪い点は、組織の境界で別の方法になっていました。中央のチームのシングルスレッドの仕事。新しいプロジェクトチームは成約によって楽しくありませんでした。

古いアーキテクチャでは地域化が不可能でした。性能問題がたくさんあり、普通にやることがスタックして、チームは新しい地域でサービスを展開できませんでした。

サービス指向アーキテクチャ

我々は他の組織のマイクロサービスの価値を見てきた。しかしSOAがベストなアプローチなのだろうか?

ポータビリティ

我々の戦略は常にベスト・オブ・ブリードだったのでコンテナは自明でした。

オーケストレーションの半分は戦いです。ベンダーに任せましょう。

大きなサービスの集まりを管理するという問題の解決して、自分たちで動かすのか?Amazon EKSで高いポータビリティ、マネージドコントロールプレーンでオペレーションの削減。

SnapでのAmazon EKS

  • 今後の見通し
    • 本番は6サービスを本番環境に投入している。ho
    • 2019年の終わりには30-50のサービスを本番投入予定。
    • 最終的には数百サービスをEKSに、マルチリージョンの異なったポリシーの冗長咲かれたサービスを乗せる。
  • 本番サービスのEKSの規模
    • 7,500コアのCPU
    • 毎秒250,000トランザクション
    • セキュアなサービスメッシュの高密度なPod/ノード比率
    • 2019年にはグローバルな地域化

結果

  • お金を沢山抑えられた
  • コンテナとAmazon EKSで新しいテクノロジーを導入する柔軟性を得られた
  • 性能が向上した
  • Amazon EKSはすでにSnapで広く採用されている

次のステージ

  • 行進を続ける
    • サービスによるサービス
    • APIによるAPI
  • 地域化の最適化

さいごに

昨年のre:Inventで鳴り物入りで発表されたAmazon EKSはSnapChatの様な大規模サービオで本番投入されています。今後東京リージョンにも上陸したらすぐにでも本番投入ができそうな勢いでした。