Kubernetes & EKSによるインフラ共通基盤の構築

1 Proprietary and Confidential ©2019 JapanTaxi, Inc. All Rights Reserved
JapanTaxi Kubernetes Ecosystem (JKE)の紹介 Kubernetes & EKSによるインフラ共通基盤の構築

Introduction Introduction Quentin Plessis (プレシカンタン) Software Engineer (SREチーム) @ JapanTaxi株式会社経験と興味： - 画像処理 - GPUを使ったコンピュータビジョンとAR - モバイル通信のデータ解析と統計モデリング - Web開発 - インフラ（環境構築と運用） - ... Kubernetesの経験 2014/06 1周年 2周年 3周年 4周年 2017/10 2018/5 2019/2 2018/12 EKS AWS kops Azure AKS AWS EKS

今回のフォーカスビジネスアプリケーションインフラストラクチャビジネスを支えるアプリケーションのためにインフラストラクチャを提供するユーザービリティ簡潔性構築時間ローメンテナンス安定性セキュア

目次 1) JapanTaxiのインフラ背景 2) Kubernetesをベースに共通なインフラ基盤へ 3) Amazon EKS 4) JapanTaxi Kubernetes Ecosystem (JKE) 5) EKSを運用して思ったこと

JapanTaxiのインフラ背景 1) Kubernetes導入前の状況と課題 2) 目指している世界 3) SREチームの役割 4) 課題の解決方法

Kubernetes導入前の状況と課題 1) レガシーなシステムが多い - GUIでのデプロイに依存 - ホストに依存（ログファイル、SSHでの作業) - Dockerで動いていない 2) Microsoft Azureのサービスに詳しい人が少ない 3) アプリケーションの管理が統一されていない - デプロイ、ログの収集と閲覧、監視 → アプリケーションによってできることが異なる 4) スケールしにくい 5) 環境の回復力や再現性がない 6) マルチクラウド (AWS, Azure) 7) 外部サービスとの連携が多い（固定IPアドレスが必須） ...

目指している世界成長していくビジネス多数のアプリケーション、高い頻度でのリリース、オートスケーリング安定的なサービスサービスのダウンタイムをなるべく減らす管理方法の統一少人数で多数のアプリケーションを管理する Infrastructure as Code 監視、ログ問題の発見と原因調査コスト削減本番に持っていくまでの時間、作業量効率化アプリケーションとインフラの作業分散

JapanTaxiの運用制約 - 24時間運用しているサービス - 時間によってトラフィックの変化 → オートスケール一週間

JapanTaxiの運用制約 - バックエンドのリリース頻度：毎日 3〜10回ぐらい - 作業分散 - アプリケーションエンジニアはアプリケーションに集中できるようにしたい - SRE/インフラエンジニアはアプリケーションの細かいところを気にしなくてもいいようにしたい - マイクロサービスをどんどん追加していきたい - 作業ミスを防ぐためなるべく自動化へ

SREチームの役割

課題 - アプリケーションに集中したいですがアプリケーションを作るたびに、 - VPC, subnet, NATなどのネットワークのことを考えないといけないのは辛い - ログ送信の仕組みをアプリケーションに入れるのは辛い（言語によって...) - 監視方法を考えないといけないのは辛い（メモリーリーク発見など …) - ロードバランシング ... - スケーリング ... - SSL証明書 … - デプロイ … - ネーミング、管理 … - … - アプリケーションによってカバーしている機能とそうではない機能がある - 環境（開発、ステージング、本番）の差が出る

解決方法：Kubernetes Kubernetesを利用すると、全てのアプリケーションが同様に使える共通なインフラ基盤ができる - 全てのアプリケーションが必ず使いたい基本機能を提供する - 新しいインフラ機能を作る時、元々特定のアプリケーションのためだったとしても、インフラ基盤に追加すると全てのアプリケーションに提供できる - SREチームは方針を決めてその方針をインフラ基盤に実現する - アプリケーションエンジニアはアプリケーションに集中できる - 環境ごとにクラスターを作れば環境の差が非常に減る

Kubernetesをベースに共通なインフラ基盤へ 1) クラスターとネームスペースの使い分け 2) よく使われているリソース 3) 課題

Kubernetes / クラスターとネームスペースの使い分け例）チームAとチームB | プロダクト P, Q, R | アプリケーション A1, A2, A3, B1, B2

Kubernetes / よく使われているリソースデプロイとスケーリング Deployment, Horizontal Pod Autoscaler アクセス Service, Ingress 設定 ConfigMap, Secret 安定性 Pod Disruption Budget ジョブ Cron Job, Job 認可（RBAC） Cluster Role, Role, Cluster Role Binding, Role Binding ノード DaemonSet CustomResource CustomResourceDefinition アプリケーション毎

Kubernetesの課題と解決方法 Kubernetesの一番大きいメリット → 自由度が高い Kubernetesの一番大きいデメリット → 自由度が高すぎるインフラレイヤー（クラスター）の課題 - クラスターはどうやって作る？（kops, kops+Terraform, Amazon EKS, Azure AKS, GKE …) - クラスターができたら、初期化や基本機能の追加はどうやって適用する？ - 再現性はどうやって守る？作業 (TOIL)はどうやって減らす？インフラレイヤーの解決方法 - クラスターの作成と管理：EKS - 基本機能の追加：JKE Kubernetesの運用の仕方がありすぎる

Kubernetesの課題 Kubernetesの一番大きいメリット → 自由度が高い Kubernetesの一番大きいデメリット → 自由度が高すぎるアプリケーションレイヤーの課題 - 管理しないといけないリソースがありすぎる - Yamlファイルが大きいし重複していて慣れていない人にわかりづらい - アプリケーションの差が出る - デプロイの仕組みがあるが … (複数のアプリケーションの場合、Slack通知...) - Kubernetesの仕様自体が複雑アプリケーションエンジニア全員に理解してもらうのは非現実的 → 新しいアプリケーションを本番に持っていくには時間がかかる Kubernetesの運用の仕方がありすぎるアプリケーションレイヤーの解決方法：JKE

Amazon EKS 1) クラスター作成方法と構成図 2) 認証 3) 認可 4) まとめ

Amazon EKS

Amazon EKS / クラスター作成クラスター作成方法 1) EKSクラスター作成 (Kubernetes Control Plane) AWS Console, AWS CloudFormation, Terraform, ... 2) ノード追加 (EC2インスタンス) AWS CloudFormation, Terraform 3) 認証情報取得：kubeconfig更新 aws eks update-kubeconfig --name my-cluster --region ap-northeast-1 4) aws-auth ConfigMap 作成 kubectl apply -f aws-auth-cm.yaml

EKSクラスター構成図

Amazon EKS / クラスター作成 / Terraform 0) AWSの他のサービスと同様に、VPCやGatewayなどを用意する必要がります 1) EKS masters aws_iam_role (1), aws_iam_role_policy_attachment (2), aws_security_group (1), aws_security_group_rule (1), aws_eks_cluster (1) → 6リソース 2) EKS nodes aws_iam_role (1), aws_iam_role_policy_attachment (4), aws_iam_policy (1), aws_iam_instance_profile (1), aws_security_group (1), aws_security_group_rule (4), aws_launch_configuration (1), aws_autoscaling_group (1) → 11リソース

Amazon EKS / クラスター作成 / Terraform - クラスターをTerraformで作成すると、クラスター毎のリソース合計数 = 17 - ただし、module化すれば良い。最終的にクラスター毎の設定： module "eks-cluster" { source = "../modules/eks-cluster" cluster_name = "development-sample-001" kubernetes_version = "1.11" node_count = 3 max_node_count = 30 node_instance_type = "c5.xlarge" }

Amazon EKS / NodeGroupsとスケーリング - 複数のNodeGroupに対応している - c5.xlarge NodeGroup (Compute Optimized instance) - p3.2xlarge NodeGroup (GPU instance) - ... - オートスケール - Horizontal Pod Autoscaler - metrics-server → CPU使用率やメモリー使用率を取得するためのサービス → 自分で追加する必要がある - Cluster Autoscaler (正式) → AWS Auto Scaling group のサイズを調整してくれる → 自分で追加する必要がある

Amazon EKS / 認証認証 aws-iam-authenticator AWSの全てのサービスと同様に AWSのIAMでEKSクラスターに認証ができる kind: Config apiVersion: v1 … users: - name: arn:aws:eks:ap-northeast-1:redacted user: exec: apiVersion: client.authentication.k8s.io/v1alpha1 args: - token - -i - my-cluster command: aws-iam-authenticator aws eks update-kubeconfigで作成されるkubeconfigファイル：

Amazon EKS / 認可認可 aws-auth ConfigMap AWSの全てのサービスと同様に AWSのIAMユーザにEKSの権限を付与することはできる apiVersion: v1 kind: ConfigMap metadata: name: aws-auth namespace: kube-system data: ... mapUsers: | - userarn: arn:aws:iam::redacted:user/user_1 username: user_1 groups: - group_1 - group_2 適用方法： kubectl apply -f aws-auth-cm.yaml AWS IAM user K8S groups K8S user AWSのIAMとK8Sの IAMをマッピング

Amazon EKS / まとめ - EKSクラスターはTerraformで10分で簡単に作れる - AWSのIAMでEKSクラスターに認証ができる - AWSのIAMユーザにEKSの権限を付与することができる - 複数のNodeGroupに対応している - AWSの他のサービスと連携しやすい - KubernetesのControl Planeの管理を隠蔽してくれる - Kubernetesのノードは自分で管理する必要がある

JapanTaxi Kubernetes Ecosystem (JKE) 1) JKEでカバーしたい課題 2) JKE CLI で新しいアプリケーションを動かすには 3) JKEの仕組み詳細

JapanTaxi Kubernetes Ecosystem (JKE) Kubernetesで運用するために、 - SREチームが考えた方針と - その方針を簡単に適用するためのツール記事：本番環境へのKubernetesの導入やk8s共通基盤JKEの開発により苦労のないサーバ運用を実現

JapanTaxi Kubernetes Ecosystem (JKE)

Kubernetesの課題と解決方法 JKEでカバーしたい課題 - インフラレイヤー - クラスターができたら、初期化や基本機能の追加はどうやって適用する？ - 作業 (TOIL)はどうやって減らす？ - アプリケーションレイヤ - リソースがありすぎる - Kubernetesの仕様が複雑、Yamlファイルがわかりづらい - アプリケーションの差が出る - デプロイの仕組み - 新しいアプリケーションを本番に持っていくには時間がかかる Kubernetesの運用の仕方がありすぎる

JKE CLI で新しいアプリケーションを動かすにはフォーカスはアプリケーションに → アプリケーションエンジニアの視点で新しいアプリケーションを追加してみましょう > cd my_application > docker build & docker push > jke init > jke build > jke dev deploy > jke stg deploy > jke prod deploy > jke dev kubectl get pods NAME READY STATUS RESTARTS AGE > jke stg kubectl get pods NAME READY STATUS RESTARTS AGE > jke prod kubectl get pods NAME READY STATUS RESTARTS AGE > jke prod connect ps ... アプリケーションの追加方法クローズドな作業環境 > jke stg connect ps ... > jke dev connect ps ... コンテナに接続 jke以外のツールのインストールは不要

JKEで新しいアプリケーションを動かすには jke dev/stg/prod deploy を実行することだけで自動的に提供されている機能： - デプロイの仕組み (デプロイ、ロールバック、Slack通知、CloudWatch Logs) - アプリケーションログ：Amazon Athenaで自然に見えるようになる - 監視： - メトリクス：NewRelicのダッシュボード（クラスター、ネームスペース、コンテナレベル ) - 死活監視：PagerDuty - エラー通知：Slack - SSL証明書の自動生成 - オートスケール - … - これから追加される機能も

JKE / アプリケーションレイヤー jke init：JKE設定の自動生成 - 利用したい環境クラスターとネームスペース先 (dev, stg, prod, …) - 簡単化されたK8SのYamlファイル - helmベース - Deployment, HPA, PDB, Service, Ingressはベースチャートへ - ベースチャートを利用して、それ以外の設定を追加する application: name: my-application baseChart: name: "application" version: 0.2.2 serviceDefaults: terminationGracePeriod: 45 containers: app: ports: - name: http containerPort: 9000 protocol: TCP envFromSecret: my-secret readinessProbe: httpGet: path: /healthcheck port: http lifecycle: preStopCommand: ["/bin/bash", "-c", "sleep 15"]

JKE / アプリケーションレイヤー jke build：helmチャートをビルドする - ベースチャートを取得 - helm package - helm s3 push jke deploy : クラスターで動いているサーバまたはジョブでデプロイする - 非同期 - helm fetch - 環境毎に設定選択 - helm upgrade (デプロイ) - ログはCloudWatch Logsへ - Slackへ通知

JKE / アプリケーションデプロイフロー

JKE / 構造 …………………………………………………………………………………………………...…. ノード foundation ネームスペース monitoring インフラレイヤー（SREチーム）デプロイメントクラスターオートスケーラー SSL証明書自動生成と自動更新ログアグリゲーター NewRelic 監視 5xxエラー監視、SLI プロダクト毎 (A, B, C) リバースプロキシ ... サービスデプロイ ... アプリケーションレイヤー（アプリケーションエンジニア）ネームスペースプロダクトA デプロイメントサーババッチジョッブサーバ１ ... プロダクトB サーバ2 サーバ１プロダクトC サーバ2

JKE / インフラーレイヤー目的 - 初期化や基本機能の追加 - 作業(TOIL)を減らす ansible (k8s plugin & ローカルコマンド実行) helm umbrella chart (helmチャートのバージョン管理と設定) クラスター初期化（EKSをTerraformで作成してから) - ansible --tags init - ネームスペースの作成 - helmインストール - helmが扱えないものを管理する（1MB以上のSecretなど) 基本機能の追加 - ansible --tags my-namespace

JKE / インフラーレイヤー foundation - RBAC (ロール、権限) - SSL証明書自動管理：cert-manager - クラスターオートスケール：cluster-autoscaler - ポッドオートスケール用：metrics-server → 一時的に問題があってもサービスに影響がない monitoring - NewRelic：kube-state-metrics, newrelic-infrastructure - PagerDuty：ingressmonitorcontroller - ログ：fluent-bit, cluster-log-aggregator (内製） → 一時的に問題があってもサービスに影響がないその他 - Secrets: git-crypt - ...

JKE / まとめ JKEでできること - Kubernetesの仕様を理解しなくてもアプリケーションエンジニアは単純なコマンドだけで安定的にKubernetesでアプリケーションを動かせる - 全てのアプリケーションは全く同様に扱われている（管理、デプロイ、起動、監視） - チーム間の知識共有がしやすい - 自分のチーム以外のアプリケーションも管理ができる - SREチームの方針を実現している - 新しい機能をJKEに追加すれば全てのアプリケーションに提供できる - マルチクラウド対応これから - IngressからIstioへ - Multi Tenantをさらにコントロール：NetworkPolicy, ResourceQuota, Taints, Tolerations - JKEオープンソース化？

EKSを運用して思ったこと

運用して個人的に思ったこと - Amazon EKS vs Azure AKS Azure AKSでの本番運用：４ヶ月間 Amazon EKSでの本番運用：1ヶ月間項目 Amazon EKS Azure AKS クラスター作成 GUI, CloudFormation, Terraform GUI, Terraform ノード作成 CloudFormation, Terraform 不要 kubeconfig取得 aws cli azure cli aws-auth 必須 / ノードグループ複数対応一つだけ Terraformリソース合計数 17 2 ノード追加時間〜1min 〜5min 認証、認可 AWS IAM ... Kubernetes as is ? As is As is EKS：ノードもマネージドになったら完璧

まとめ 1) 問題：アプリケーションに集中できない解決方法： → Kubernetesをベースに共通なインフラ基盤 2) 問題：自分でクラスターを作成するのは難しい（インフラレイヤー）解決方法： → クラスター作成：EKS → 初期化、基本機能：JKE 3) 問題：K8Sの使い方がありすぎて混乱する（アプリケーションレイヤー）解決方法： → SREチームの方針を実現するJKE

〒102-0094　東京都千代田区紀尾井町3-12 3-12 Kioicho Chiyoda-ku, Tokyo 102-0094 Japan TEL 03-6265-6265　FAX 03-3239-8115
www.japantaxi.co.jp 文章·画像等の内容の無断転載及び複製等の行為はご遠慮ください。 Proprietary and Confidential ©2019 JapanTaxi, Inc. All Rights Reserved

Kubernetes & EKSによるインフラ共通基盤の構築

Kubernetes & EKSによるインフラ共通基盤の構築

More Decks by Quentin Plessis

Other Decks in Technology

Featured

Transcript