10分くらいでわかる、KubernetesとEKSの何が便利なのか

# 注意 :bow: 
この記事は、実運用したことのない、**Kubernetes初心者が調べた**結果に基づき作成しています。
間違い・誤解などありましたら、コメントや編集リクエストでご連絡ください。

# TL;DR / 結論から先に言うと :thinking:

- コンテナをクラウドでそのまま動かそうとすると困る
  - n台動かしたいコンテナが、今クラウド全体で何台動いているのかとか
  - デプロイするときに、コンテナを立ち上げたり落としたりする順番・タイミングとか
  - コンテナに割り当てるロードバランサ、ストレージなどの作成とか
  - 他にもいろいろ
- Kubernetesはクラウド全体のコンテナ周りを一元管理してくれるので便利
    - どの環境で、どんなコンテナがどれだけ動いているかとか、把握してくれるので便利
    - コンテナ周りをどんな構成にしたいか、yml形式で書いてkubectlコマンドで渡す
    - 運用者の指示した形になるように、コンテナ周りを一元的に操作してくれるので便利
- EKSはKubernetesのうち、コンテナを一元管理してくれるところをマネージドで使えるので便利
  - Kubernetesのうち、コンテナを動かすマシンは自分たちで管理する
- ECSも似たことをしてくれるけど、自発的にロードバランサとか作ったりしてくれない
  - Kubernetesは自分からロードバランサとか作りに行ったりもする
  - ECSはFargateが使えるけど、EKSは自前でEC2立てる
- ECSの方が構成が比較的シンプルで、扱うコンテナの種類が少なければ便利なこともある

# この記事で説明したいこと :laughing:

- Kubernetesの何が便利なのか
- なぜ使うのか
- どんな問題を解決してくれるのか
- **お お よ そ** どんな構成や、仕組みで動いているのか
- EKSの何が便利なのか
- ECSとEKSの違いは何か

# この記事で説明しないこと :sweat_smile:

- 細かいコマンドや設定の仕方
- 細かいアーキテクチャ・構成の説明
- ベストプラクティスや、実運用上での事例
- Serviceなど、細かいKubernetesのコンポーネント
- サービスメッシュなど

# そもそもコンテナって何 :rolling_eyes:

- コンテナ型仮想化と呼ばれる技術がある
- Dockerなどを通じてホストOSの上で**OSっぽい環境**(コンテナ)を動かす
 - Dockerなどは、コンテナを動かすための環境を提供するミドルウェア
- VM Wareや、Virtual Boxは「ホスト型仮想化」というものもある
  - これは、OSの上に、まるまるOSを動かす
- コンテナは、ホストOSのカーネルなどを共有して使う
    - そのため、ホスト型より軽く動く
    - カーネルなどは、すでにホストOSが立ち上げている物を使うので起動も速い
    - なので、単一のアプリ単位ごとにコンテナを立ち上げたりしやすい
- コンテナ自体が一つのOSのように動くので、コンテナ同士は分断されていて影響を受けにくい
- アプリの実行に必要な構成や依存関係を、コンテナにひとまとめにしておくことができる
  - なので、実行してみたら動かないとか起きにくい

**おおざっぱなコンテナ動作のイメージ**
![image.png](https://qiita-image-store.s3.amazonaws.com/0/96675/b391d48c-646a-735b-7fec-bb5c4826c4ff.png)

# コンテナの困りごと :frowning2:

- 手元(ローカル)の環境ででコンテナを動かす分には便利
- 使いたいアプリケーションがすぐ使える
- ただ、**運用する**となると困ることが出てくる

例えば、以下のような構成を考えてみます。

- AWS上で動かしたい
- バックエンドサーバを3コンテナ動かして
- DBサーバを1コンテナ動かしたい
- できるだけ 複数の場所(リージョン/AZ)に均等に分散させたい

**手元の環境をそのままAWSに持って行った図**
![image.png](https://qiita-image-store.s3.amazonaws.com/0/96675/adec06ea-dd29-f1f3-ee0c-97244e93e07d.png)

持って行けたは持って行けました。 :tada: 
ただ、運用していく中で次のような困りごとが出てきそうです。

- 各地域に、どのコンテナが何台動いているって**誰が把握しているの**？
 - 地域ごとに均等に配置するために、毎回人力で確認しないとダメ？
- コンテナを新しいものに置き換えるときどうしよう？
 - 既存のコンテナ落としたり、立ち上げたりするタイミング・順番・依存関係
 - 毎回、各コンテナごとに手順書つくってやってもいいけど、だいぶ大変
- 死んでるコンテナ検知して、置き換える仕組み作らないと
- コンテナに割り当てるリソースも管理しないと
 - ストレージとか、ロードバランサとかコンテナごとに用意・管理しないと
- ネットワークや、アクセス権限もコンテナごとに用意・管理しないと
- などなど・・・

だいぶ大変そうです。:confounded:

**コンテナ自体の運用**の課題と、
ネットワークやロードバランシングなど**コンテナ周りの運用**の課題が、
いくつかありそうですね

# そこで、Kubernetes :ship: 

どんな構成・運用をするか、**決めないといけないことは人が決める**としても、
コンテナごとに管理・操作していたら、情報や手順が散らかって大変です。

せめて、コンテナやコンテナ周りのことを **一元的に管理したい**ところです。
できれば、**決めたことに沿って、コンテナやコンテナ周りの操作を自動化してほしい**ですね。

**Kubernetesを導入すると、そんなコンテナ周りの一元管理、一元操作をしてもらう**ことができます。
Kubernetesは、k8sと略して記述されることもあるようです。

# Kubernetesはざっくり、どんな感じに動くのか :confused: 

### コンテナ周りのことを一元的に管理してくれるやつ :information_desk_person_tone1:

まずは、コンテナ周りのことを一元的に管理してほしいところについて、知りたいです。

コンテナ周りの全体像を把握して、一元的に管理してくれるのが**Kubernetes Master(s)**です。
Kubernetes Master自体が、複数台構成で動く場合があります。

このKubernetes Masterが、環境全体のコンテナの稼働状況などを把握していて、
コンテナの稼働状況などに基づいて、運用者が指示した理想の形になるように
コンテナを配置したり、削除したりする**指示を出します**。

コンテナ周りの状況を把握してコントロールするので、
**コントロールプレーン**というものに分類されます。

(一方で、コンテナを動かす環境のことを **データプレーン**と呼びます)

![image.png](https://qiita-image-store.s3.amazonaws.com/0/96675/d1b04a4d-8f46-b21f-7041-a0c1f994f504.png)

### 実際にコンテナを動かすやつ :robot:

コンテナを管理してくれるやつは、何となくわかったので、
次は、コンテナを動かすところ(**データプレーン**)
についてどうすれば良いか知りたいところです。

単にコンテナを動かす環境だけ用意されても、
Kubernetes Masterは、手を出すことができません。

Kubernetes Masterから操作できるような仕組みが必要なはずです。

Kubernetes Mastersが管理する、コンテナを動かす環境は、
**Kubernetes Node**と呼ばれています。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/96675/9d118522-378b-9f29-1560-5e6c7db41a4c.png)

1Node = 1マシン単位です。
Nodeとして動かすマシン自体は、仮想マシンでも、物理マシンでも問題ありません。

このNodeの上では、
Masterの指示に沿ってコンテナや、コンテナの集まりを操作するソフト(**kubelet**)と、
Dockerなどのコンテナ型仮想環境が主に動いています。

### コンテナ、扱いやすい単位でまとめたくない？ :clap:

じゃあ、そのKubernetes Nodeの上で個別にコンテナが動くの？

でも、複数のコンテナをグループ化して扱いたい場合とかあるんじゃない？
個別に指定しなきゃダメ？

とか思うところがあると思います。

ということで、Kubernetes Node上では、
**複数(1台以上)のコンテナをグループにして**管理できる仕組みがあります。

グループは、**Pod**という単位でまとめられています。
コンテナは何かしらのPodに属しています。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/96675/0933f63c-5564-17c9-9633-9a8651828f03.png)

まとめる単位は、Mastersへの設定次第で決められます。
Pod内のコンテナは、**IPやストレージなど**を共有することになります。

Podの単位でまとめておくことで、まとめた操作指示をしたり、管理できたりします。

### Nodeの集まり :family_mwgb:

Nodeの集まりは、Kubernetes Clusterと呼ばれます。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/96675/ca9e96a1-51d2-2879-bb34-0864834b233c.png)


### コンテナ管理するところと、動かすところができたので :open_hands:

Kubernetes Masersの指示のもとに、Kubernetes Nodeが動けるようになりました。

Kubernetes Mastersは、NodeやPodの状況に応じて、
コンテナを作ったり、再作成したり、落としたりすことなどを、Nodeに指示できます。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/96675/7dba32c7-0330-ee94-d53f-daa408277d85.png)

# じゃあ、どうやってKubernetes Masterに指示を出すの? :ok_hand:

Kubernetes Masterに、
どういう感じにコンテナ周りを構成してほしいか伝えると、
その構成になるように操作してくれるということはわかりました。

では、どのような感じでKubernetes Masterにコンテナ周りの構成を伝えれば良いんでしょう。
ざっくり、以下のような流れで伝えます。

- yaml形式でコンテナ周りをどんな構成にしたいか、記述する
 - その設定ファイルは、**マニュフェスト**と呼ばれる。
- **kubectl**コマンドを使って、設定をKubernetes Masterに反映する
- Kubernetes Masterは反映された内容を元に、NodeやPodを操作する
- もちろん**kubectl**とKubernetes Mastersの間には認証でアクセス制御できる

![image.png](https://qiita-image-store.s3.amazonaws.com/0/96675/4be63fb8-93c0-5309-5b85-af7c13831a9d.png)

※ 今回は概要の理解が目的なので、細かい操作や設定方法はばっさり割愛させてもらいます。 :bow: 

実際の運用では、個々人がkubectlを実行するよりも、
JenkinsなどCI/CD環境が実行する場合が多いようです。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/96675/96afcc7e-a8bc-7827-37f5-6e5762555e3b.png)

# その他コンテナ周りについて :point_up:

コンテナ周りのもろもろについて、
 
- ロードバランシングなどのトラフィック管理構成
- 操作できるコンテナのアクセス権限管理
- ストレージなどの設定・割り当て
- デプロイの方法・手順など

などなど、本当にいっぱいあります・・・・
これらも同様に、マニュフェストファイルに記述して、Kubernetes Masterに作成・管理してもらうことになります。
(今回、詳細は割愛します。)

### Kubernetes って？ ああ！ :card_index: 

これらを踏まえた上で、Kubernetesというと、
前述の構成や、仕組み(と、未説明のコンポーネントなど)
全体を指すことになります。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/96675/63df8fc3-7094-5205-ad05-6877cfdf306d.png)


# Kubernetes自体の運用が大変なんでしょう？ :angel:

大変。(らしい)

なので、AWSやGCP、AzureなどでマネージドのKubernetesサービスが提供されています。

私の場合だと、AWSの知識しかほぼないため、Amazonが提供するマネージドのKubernetesサービス。
Amazon EKSについて説明します。

# EKSって？ :eyeglasses:

正式名称は、Amazon Elastic Container Service for Kubernetes

Amazonが提供するマネージドのKubernetesサービスです。

■ Amazon EKS
https://aws.amazon.com/jp/eks/


# EKSの何が便利なの？ :kissing:

**Kubernetes Master(コントロール プレーン)に当たる部分**を、
マネージドで運用してくれます。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/96675/377b6cfa-f8fb-8d3a-b351-7eea916ce75c.png)


マネージドサービスなので、以下のことは勝手にやってくれます。

- Kubernetes Masterの更新・パッチの適用
- 死んでしまったKubernetes Masterの検出、置き換え
- 複数AZへのKubernetes Masterの配置・構成
- などなど

また、 AWSの提供する他サービスとの連携も、できるようになっています。
例えば、ロードバランサや、ストレージなどをKubernetesが作成する場合、
AWSマネージドのサービスを選択できます。

そのため、それらの運用の一部をAWSに任せることができます。

一方で、Kubernetes Node(データプレーン)として、
運用するマシンは**自分で管理・運用する必要があります**。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/96675/c925df9a-89c1-9479-3bfc-9162c996072d.png)

# 案ずるより生むが易し :runner_tone2:

Amazon EKSは公式チュートリアルがあるので、簡単に体験できます。

■ Amazon EKS の使用開始
https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/getting-started.html

この、チュートリアルをオススメする理由は以下の通りです。

- VPCや、SGの作成など、Kubernetesを触る本筋以外のところは、自動化されている
 - 自動作成するCloudFormationのテンプレートが用意されている
- マニュフェストファイルも用意されており、コンテナを起動するまでが手軽に試せる
- 試した環境の削除も楽


また、Classmethodさんの解説記事が、とてもわかりやすかったです。

※上記の公式ドキュメントの内容の方が新しく、インストールするツール(コマンド)の
バージョンに差異があるため、両方を見比べながら実践すると良いと思います。

※現在は東京リージョンでも試せるはずですが、Amazon EKS 最適化 AMI が東京で提供されていないので、AMIのリージョン間コピーが必要です

■ 【まずは触って体験】リリース直後のAmazon EKSでサンプルアプリケーションを動かしてみた
https://dev.classmethod.jp/cloud/aws/eks-getting-started/


# Amazon ECSと何が違うの？ :hugging:

Amazonには、EKSと同じくコントロールプレーン(コンテナを管理するやつ)の
サービスとして、ECS(Elastic Container Service)というものがあります。

どのような違いや、特徴があるんでしょうか。

私が感じた、主な違いは以下の通りでした。

- ECSでは、コンテナを動かすところ(データプレーン)にFargateが採用できる
 - Fargateはコンテナを動かすところもマネージドで提供してくれるサービス
 - EKSではFargateを使用することは現状できない。
- ECSは、ロードバランサやストレージなどのリソースを、自分から作成しない
 - ECSは既に作成済みのロードバランサや、ストレージを割り当てる形
 - EKSは仕組みの中で、ロードバランサやストレージなどのリソースを作成することがある
- ECSは、コンテナの管理に特化しているので、シンプルな構成を、シンプルに扱える
 - 複数の多種多様なコンテナを運用しないのであれば、ECSの方がシンプルに扱うことができる
- などなど 

また、以下の記事で
「ECSはAWS上でしか動かない。」(からEKSも提供した)
とあったのが印象的でした。

■ AWSはなぜ、ECSがあるのにKubernetesのサービスを始めたのか、コックロフト氏に聞いた
https://www.atmarkit.co.jp/ait/articles/1806/11/news029.html


# まとめ :smiley:

- Kubernetesは複数コンテナを管理する必要がある時に、頼れる
- コンテナを一元的に管理、操作できる
- コンテナ周りのネットワークやストレージも一元的に管理・操作できる
- なので、多数の複数コンテナを扱う、マイクロサービス運用する場合とかに便利そう
- AWSでコンテナの種類がそんなに多くなければ、ECSの方がシンプルで良さそう

# この記事を書くためにやったこと

Kubernetes完全ガイド(第二版)を半分くらい読んで、
https://book.impress.co.jp/books/1118101055

前述の、EKSチュートリアルを実践しました。
■ 【まずは触って体験】リリース直後のAmazon EKSでサンプルアプリケーションを動かしてみた
https://dev.classmethod.jp/cloud/aws/eks-getting-started/

Kubernetes完全ガイドは、紹介に書かれているように本当に網羅的に、
わかりやすく書かれていてよかったです。

また、チュートリアルの解説もわかりやすく助かりました。


# この記事ができた経緯 :upside_down:

先日、とらのあなさんのLTイベントに参加させてもらいました。

もともと、Kubernetesを導入する理由と、利点がざっくりわからなかったので、
調べて、10分くらいにまとめて発表をしました。
せっかくなので、その内容を元に、ドキュメント形式でも残しておこうと思います。

【とらのあな主催】オタクが最新技術を追うライトニングトークイベント４回目
https://yumenosora.connpass.com/event/120688/

■ 10分くらいで雑に理解する KubernetesとEKS (ページスクロールで原稿が読めます。)
https://speakerdeck.com/masachaco/10fen-kuraideza-nili-jie-suru-kubernetestoeks