今更ながらKubernetesとEKS早わかりまとめ
概要
自分のkubernetesの理解促進のために、kubernetes(とAWS EKS)に関することをざっとまとめています
*Qiitaからの転載です
kubernetesとは
- ものすごく雑にいうと、複数コンテナのオーケストレーションを管理するためのシステムであり、リモート環境上で複数コンテナに対してdocker-composeみたいに管理できる代物
- wiki曰く、
- コンテナ化したアプリケーションのデプロイ、スケーリング、および管理を行うための、オープンソースのコンテナオーケストレーションシステム
- Kubernetesの目的は、「ホストのクラスターを横断してアプリケーションコンテナを自動デプロイ、スケーリング、操作するためのプラットフォーム」を提供することとされている
- Docker単体では、複数のDockerコンテナ群(マイクロサービスの集まり)を管理するのが難しいという欠点があるので、個々のDockerコンテナをオーケストレーションするために使われてる
- 元々はGoogleが作ってたけど、今ではCNCF(Cloud Native Computing Foundation)がメンテしてる
- CNCF基準では
Graduated
レベルであり、品質や安定性はかなりあるっぽい
- CNCF基準では
- CNCFによるメンテや、GoogleがkubernetesをGKEとして取り入れたりしてるので、コンテナオーケストレーションエンジンの中ではデファクトに近い存在
特徴
- コードでインフラが管理でき、コンテナのスケーリングやコンテナ間通信とかが楽にできるのがメリット
Infrastracture as Code
- YAML/JSON形式(マニフェストという)でデプロイするコンテナや周辺リソースの管理をできる
スケーリング/オートスケーリング
- 同一コンテナイメージを元に、複数のkubernetes Nodeにレプリカをデプロイできる
スケジューリング
- どのkubernetes Nodeにどんなコンテナをどのように配置するかのスケジューリングが可能
- 例えばAWSのアベイラビリティゾーンやインスタンスタイプなどを指定できる
リソース管理
- 特別な設定をしていない場合には、kubernetesがkubernetes NodeのCPUやメモリの空きリソースを見てコンテナ配置のスケジューリングを自動で行う
セルフヒーリング
- kubernetesはコンテナのプロセス監視を行なっており、コンテナのプロセスが停止した場合には、自動的に再デプロイできる
サービスディスカバリとロードバランシング
- kubernetesはロードバランシング機能を持っており、設定したコンテナ間のルーティングが可能
- スケール時の自動追加/削除はもちろん、障害時における切り離しや、ローリングアップデート時における事前の切り離しなども自動で行える
- 個々のコンテナ同士がお互いに参照できるようにサービスディスカバリ機能を有する
全体的な構成
- kubernetesのアーキテクチャ図がわかりやすいかもです(概念的に押さえといたほうが良さそうなところは赤枠で囲ってます)
- 開発者はkubectlというコマンドを介して、kubernetesのマスターノード(図の左のでかい箱)にいろんな命令を送り、マスターノードが各ノード(図の右側の2つの箱)を管理しています
- NodeはPodというアプリケーション単位の集まりを管理しています
Master Node
- すべてクラスター内の単一ノードで実行される状態を管理するプロセスの集合であり、クラスターの望ましい状態を維持する責務を持つ
Node
- Kubernetesにおけるワーカーマシンで、1つのVMまたは物理的なマシン
- 各ノードにはPodを動かすために必要なサービスが含まれており、マスターコンポーネントによって管理されています
- アプリケーションとクラウドワークフローを実行するマシン(VM、物理サーバーなど)
- Kubernetesマスターが各ノードを制御するが、運用者自身がノードと直接対話することはほとんどない
Pod
- Node上で管理されており、1つ追上のコンテナからなるコンテナの集合体である
- デプロイされたアプリケーションがPodの中にあるイメージ
- 密接に関わるアプリケーション同士を1つのPodにまとめて管理する
- Podの中ではコンテナは同一のstorageやnetworkを共有している
- Nodeの中に複数のPodが存在するイメージ
- 以下はPodとノードについてより拝借
AWS EKSについて
Amazon Elastic Kubernetes Service (EKS) は、AWS で Kubernetes を簡単に実行できるマネージド型の Kubernetes サービスです。お客様独自の Kubernetes コントロールプレーンをインストール、運用、保守管理する必要はありません。Amazon EKS は Kubernetes 準拠を認定されているため、アップストリームの Kubernetes で実行されている既存のアプリケーションは Amazon EKS と互換性があります。
Amazon EKS は、コンテナの起動と停止、仮想マシン上のコンテナのスケジューリング、クラスターデータの保存などのタスクを担当する Kubernetes コントロールプレーンノードの可用性とスケーラビリティを自動的に管理します。Amazon EKS では、各クラスターのコントロールプレーンの異常なノードを自動的に検出し、置換を行います。
Amazon Elastic Container Service for Kubernetes (EKS)の所感によると、
Kubernetesマスタ(Etcd + Controller Node)のマネージドサービスです。
とまぁ、コントロールプレーン(いわゆる、Master Node)をマネージドでやってくれるようで、雰囲気としては、以下の図の感じだそうです(出典:10分くらいでわかる、KubernetesとEKSの何が便利なのか)
コントロールプレーンの運用(冗長化やバックアップなど)はかなり大変らしく、それがマネージドになるのはありがたいそうな。
特徴
Workerノードのデプロイはスコープ外
- デプロイメントツールやCloudFormationを利用して、EKS + Workerノードをセットでつくる必要あり。または、EKSをポチポチしてMasterノードをつくり、EC2インスタンスをポチポチして AnsibleやkubeadmでプロビジョニングすることでWorkerをつくる必要がある
AWSユーザとKubernetesユーザの一元管理サポート
- AWS IAMユーザ、IAMロールとKubernetesユーザの変換をサポート
Kubernetesのネットワークレベルアクセス制御サポート
- CalicoというKubernetes界隈で標準的に使われているOSSを利用するようです
ECSとの違い
- プラットフォームの上でものを作るということが割と参考になるかもしれません
ECSについて
1つ1つのサービスにはそれぞれの責務の範囲が明確にあり、ユーザーはそれらをビルディング・ブロックとして組み合わせることでシステムを作っていく. 各 AWS サービスはそれぞれの API を呼ぶ形で疎結合に組み合わせることができ、一部のブロックを他のブロックに、例えば ECS から Lambda に置き換えられる. この思想と哲学が、AWS が幅広いユースケースをカバーすることを可能にし、ユーザーが AWS 上で持続可能なシステム構築と運用を行うことを可能にしていると言えます.
AWS そのものがプラットフォームであり、ECS はそんなプラットフォームの機能の一部として、ユーザーがコンテナを使って解決したい課題を解くためのサービスという関係性です.
EKSについて
かたや、Kubernetes というソフトウェアは、ユーザー自身が独自の哲学に基づいてそんなプラットフォームを作り上げることを可能にするものです1. つまり、Kubernetes を AWS 上で実行するということは、Platform on Platform の状態を作り上げていることになり、そこには2つの思想と2つの哲学が親子関係を持っていることになります.
要は
- AWSの思想に則ってやる場合にはECSで、kubernetesの思想に則ってやる場合にはEKS
- 優劣というかは、どのプラットフォームでやる必要があるかなどを考える必要がありそう
そのほか
- AWS re:Invent 2019でKES向けのFargateも登場した
- [AWS re:Invent 2019] Amazon Fargate for Amazon EKSが発表されました
- ECSのFargate同様、めちゃくちゃ凝ったEC2を自前で作り込む必要がない場合には、Fargateにしたほうが運用管理は楽っぽい
参考
kubernetes
- Wiki Kubernetes
-
kubernetes(本家サイト)
- 特にKubernetesの基本を学ぶとコンセプトが結構全体に関する説明載ってます
- Kubernetes完全ガイド
- 今さら人に聞けない Kubernetes とは?
- 【レポート】Kubernetes on AWS(Amazon EKS実践入門) #AWSSummit(classmethod)
- Amazon EKSとECSの最新事例を聞いてきた( JAWS-UG コンテナ支部 #14 #jawsug_ct )
- Kubernetesの基礎
Discussion