Googleのパワーを強く感じられるセッション。さすがでございました。そのセッションのメモでございます。
- 福田 潔 氏
- Google Cloud Japan
- Customer Engineer
- GKE = Google kubernetes Engine
他のクラウドと比べてGoogleが勝っている点3つ
- ビッグデータ関連での利用
- ML/AIでの利用
- コンテナの利用
kubecon 2017 keynote => 「kubectl is the new ssh...」
- kubernetesの世界では、低レイヤを気にしなくてよくなる
- kubectlは、これからのエンジニア全員が覚えるべきコマンドである
なぜkubernetesが注目されるのか
- VM => コンテナ => コンテナオーケストレータ
- アプリケーションのコンテナ化が進んでいる
- モダンアプリケーションのインフラとして
コンテナオーケストレータ
- Dockerだけではできないこと
- 複数のノードに対するコンテナのデプロイは？
- ノード障害が発生した場合は？
- コンテナ障害は？
- アップデートは？
モダンアプリケーション
- デジタル空間でのビジネスが当たり前になっているので、ネットを通じて顧客接点となるアプリは非常に重要
- 使いにくいアプリは顧客獲得機会の損失を意味する
- 要件
- ユーザビリティ、24/7、アジリティ、性能、マルチデバイス
- それを支える技術要素
- 自己修復能力、モジュール化、スケール、リリースパイプライン、Blue/Green、カナリアデプロイ、ロールバック、モニタリング
- これらをkubernetesは機能としてほぼ持っている
kubernetesとは
- クーバネティス
- ギリシャ語で「操舵手」「統治者」といった語が語源
- コンテナをどこで実行するのかを管理
- Googleの社内システムからインスピレーション
- 100%オープンソース
- 様々な企業が開発に携わっている
- Write Once Run Anywhere
- 複数のコンテナランタイムをサポート
デファクトスタンダードへ
- MSとAWSがkubernetesに対応した
- 3大クラウドベンダ全てがkubernetesにコミットしている
- CNCFによって32個の認証プラットフォームを認定
Google kubernetes Engine (GKE)
- GCP上で動作するマネージドkubernetes
- 2014年に登場
- アルファクラスタ機能
- Zero-Opsクラスタを目指す
- GKEのランタイムはGCEで出来ている
- GCEにSSHする必要はない = VMは気にしなくて良い
- 特徴
- 簡単 (Simple)
- 信頼性が高い (Reliable)
- 効率性 (Efficient)
- GCP各サービスとの統合 (Integrate)
- クラスタはgcloudコマンドかGUIコンソールから、4〜5分で作成可能
- クラスタへの接続はGUIコンソールから案内される
- 5分後にはkubectlが実行できる
クラスタのアップグレード
- kubernetesはおよそ3ヶ月に1度マイナーバージョンアップ
- マスタとノード、両方のバージョンを気にする必要がある
- マスタは自動でアップグレードされる
- アップグレードスケジュールは、Release Noteに公開
ノードの自動アップグレード
- 管理オーバーヘッドが少なくなる
- セキュリティの強化
- 新しい機能へのアクセス
- 設定は、コマンドかGUIでフラグをつけるだけ
メンテナンスウィンドウ
- 自動アップグレードのタイミングを制御できるように、マスタ・ノードともに特定の曜日、4時間単位で設定が可能
マスターのearly upgrade
- 自動アップグレードを待たず、いち早くアップグレードさせることも可能
- 手動でコマンドを実行する感じ
ノードのヘルスチェック・自動修復
- マスターはノードのヘルスチェックを10秒間隔で行なっている
- 継続的にヘルスチェックを行い、長時間（10分前後）ヘルスチェックに失敗すると修復プロセスを開始する(COSを洗濯した場合)
- マニュアルでヘルスチェック・修復させることもできる
マルチゾーンクラスタ
- デフォルトでは指定したゾーンに対してクラスタマスターとノードが作成される
- 追加のゾーンを指定することもできる
- 新規作成時や既存クラスタに設定可能
リージョナルクラスタ
- ノードだけではなく、マスタも複数ゾーンに分散できる
- マスタも冗長化できる
- ただしまだベータ扱い
- GKEでは、現状マスタには課金されないので、使えるなら美味しそう
COS = Container-Optimized OS
- OSイメージの選択肢はCOSまたはUbuntu
- COS：Docker利用に最適かされた軽量OS
GKEにおけるスケール戦略
- ポッドレベル (kubernetes)
- SO(スケールアウト)はPod数を制御(HPA)、SU(スケールアップ)はPodに対するリソース割り当てを制御(VPA)
- クラスタレベル (GKE)
- SOはNode数を制御(クラスタオートスケーラ)、SUはNodeのリソース割り当て（インスタンスタイプ）を変更
- クラスタサイズの変更はコマンドで簡単にできる
- クラスタオートスケーラでは、同じ種類のノードがスケールしていく（ノードプールに設定されたノードテンプレートが使用される）
VMインスタンスタイプの変更
- 既存インスタンスを無停止で変更することはできない
- 新しいノードプールを作成し、そのプールに既存のワークロードを移行する
- ダウンタイムなしでワークロードを移行することも可能
プリエンプティブルVM
- 中断される可能性がある
- 非常に安価に利用可能
- 任意のマシンタイプ
- ワークロードによっては、VMのコストを大幅に下げることもできる
- 作り方はフラグをつけるだけ
GKEにおけるGCPの役割
- GKEクラスタの実行基盤
- ノード => GCE、永続ディスク
- ノードプール => Instance Group
- Service/Ingress => TCP/UDP/HTTP(s) LB
- VPC
- アドンコンポーネントをマネージメントサービスとして提供
- データストア => cloud spanner, Cloud Datastore, Cloud SQL
- DWH => BigQuery
- メッセージング => Cloud PubSub
- 運用管理
- CI/CD
メルカリ導入事例
「ロードバランサとGKEが導入の決め手」
GCPのロードバランサ
- アプリケーションフロントエンドは強力なLBが必要
- グローバル負荷分散：クロスリージョン フェイルオーバー
- リージョンがダウンしても別リージョンにルーティングしてくれる
- Googleのグローバルインフラ
- LBはエッジで動いていて負荷分散している
- 世界各地にエッジポイントが存在する
- エッジ + バックボーン = 低レイテンシ = 優れたUX
