Kubernetesが必要なわけ

Dockerのコンテナオーケストレーションツール

Dockerそれ自体には管理機能がないのでオーケストレーションの仕組みが必要。それを担うのがKubernetes

• リソース管理
  yamlやJSONで構成管理や自動化が出来る
• データ管理
  コンテナで共通利用する設定ファイルや認証情報を保存する仕組みがある
• オートスケーリング
• 自動化
• 障害時のセルフヒーリング
  ・プロセスの死活を検知して再デプロイを行う、
  ・クラスタ中のノード障害が起きても自動復旧する
• コンテナの死活監視
• ローリングアップデート
• ログ管理
• 他システムとの連携
  // Google製なのでGoogleサービスと連携力が強い
• コンテナのスケジューリング

 

 

Pod

• Kubernetesにおける管理上の基本単位。
• Volumeという記憶領域を共有するコンテナの集合単位

 

 

Dockerの設計原則

• 1コンテナ1プロセス
• 軽量なDockerイメージにする
  → yumやaptのキャッシュやパッケージリストをクリアする
• 実行ユーザをroot以外にする
  プロセス起動の実行ユーザ権限を最小化すること、
  rootユーザの利用は危険なので極力さける
• Immutable Infrastructureにする
  コンテナはバージョン管理を行い、実行中に不可変の状態にしておく

 

 

 

クラウドサービスでのマネージドKubernetes

実利用としてはKubernetesそのものの運用ではなくマネージドサービス経由でKubernetesを利用していく。私が本体のKubernetesを運用するシチュエーションはないように思える。

 

GCP GKE(Google Kubernetes Engine)

• 起動3分で早い。
• AWSサービスを利用していない、Kubernetesのみ利用したいならGKEが良い選択

ただGCPはサポート体制がAWSほどは整っていないので考慮される。

 

AWS EKS(Elastic Container Service for Kubernetes)

 

AWS EKSのセキュリティ

• AWSのマネージドサービスと連携する場合にインターネットを中継する場合が多いがAWS EKSはPrivate Linkに対応しているので、Kubernetesの重要なAPIをインターネットに出さなくて良い。
  // VPCとマネージドサービスの通信はVPC Endpointやprivate Linkを通して隠ぺいできる場合がある。
• Kiamを利用して特定のPodのみに必要な権限を与える

 

AWS ECSがあるよね、EKSを使うメリットは？

• ECSと違ってベンダーロックされない、GCPでも動かすことが出来る

 

AWS EKSはベアメタルインスタンス(i3.metal)に対応している

 

 

費用の比較 AWS EKS VS GCP GKE

• AWS EKS 20,000円/月
• GCP GKE 1,000円/円

GKEやっすい！

 

 

マイクロサービスとKubernetes

 

マイクロサービス

gRPC, RESTful APIなどのインターフェイスの仕様を決めてサービス同士をつないで疎結合にした設計

メリット

• サービス毎にプログラミングやフレームワークを選定して独立して開発が出来る
• 障害の影響範囲をサービス毎に留められる
• サービス毎にスケールすることが出来る

1つのマイクロサービスを1つのコンテナイメージのみに内包して開発してデプロイする、こうして独立して開発を行うことが出来る。

 

デメリット

• システム全体のモニタリングが難しい
• モニタリングが難しいのでボトルネックや障害原因の特定に時間がかかる

リクエストが処理されるまでどこを通って何をしたのかトラッキングが必要、これを解決するのがサービスメッシュという考え方

 

サービスメッシュ

マイクロサービス間のメッシュ状の通信や経路を制御する考え方

 

サービスメッシュを実現するミドルウェア

• Istio
  一番有力
• Conduit(Linkerd v2)
• Linkerd