Kubernetes Meetup Tokyo #31参加してきた

Kubernetes Meetup Tokyo初参加してきた。
へーって思った内容を書き留める。
※実践編！みたいなのは全部飛ばしてます


| 内容 | スピーカー |
|:------------------|:------------------|
| いま、Kubernetes 好きのあなたにこそ伝えたい Amazon ECS 〜 違いに学ぶ Kubernetes の考え方・使い方 〜 (30min) | Tori Hara(@toricls), AWS |
| 入門！ClusterAPI 〜k8sクラスターもk8s APIで管理したい〜 (30min)	| 髙石 諒 (@r_takaishi), GMOペパボ株式会社 |
| Helmfile: Superchage your deployment pipeline (30min)| Yusuke Kuoka(@mumoshu), Z Lab Corporation |


# いま、Kubernetes 好きのあなたにこそ伝えたい Amazon ECS <br> 〜 違いに学ぶ Kubernetes の考え方・使い方 〜
ECSとKubernetesの違いについて紹介されている。
どっちがいいとかではなく、ここが面白いよね〜と言う話。

## 作成する設定ファイルの違い
load barancherでappにトラフィックを流す場合に作成する設定ファイル

- kubernetesの場合
  deployment、service、Ingressを作成する

- Amazon ECSの場合
  Task Definition、Service作成する

### 補足
ECSはKubernetesに比べて設定ファイルが短くなりがち&ファイル数も少ない。
AWSにある他のサービスと組み合わせるので、管理する範囲がKubernetesよりも狭くなるため。


## deployフローの違い

- kubernetesの場合
  1. Application Repository（Dockerfile）にcommit
  2. CI走る
  3. Docker Pushし、Imageを登録 & Manifest RepositoryへPull Request投げる
  4. CD走る（deploy）

<br>

- Amazon ECSの場合
　　 1. Applicationのリポジトリ（dockerfile、task定義）にcommit
　　 2. CI走る
　　 3. Docker Pushし、Image登録 & ECS API叩いて、Diff登録 & Manifest RepositoryにPull Request
　　 4. CD走る（deploy）

### 補足
ECSにおいては管理できる範囲は狭い。ECSのyamlではクラスタ名指定。
ECSではクラウド上の登録されたタスク定義と名前とリビジョンがクラスタを管理し、Kubernetesではdeployするファイルがクラスタを管理する。



## log収集の違い

- kubernetesの場合
  - ログの取集はノードやクラスタレベルでの意思決定、オペレーション
  - DeamonSetによって、ログ収集エージェントをノード郡に展開
  - Docker Logドライバーをサポートしないという方針。
    - Docker独自の仕様だから良くないという考え。

<br>

- Amazon ECSの場合
  - ログ収集はアプリケーションレベルでの意思決定、オペレーションが想定されている
  - docker logドライバーをタスク定義から設定する。
  - アプリごとにログの送付先が異なるケースが想定されている。



## Kubernetesにあって、Amazon ESCに無いもの

 - ECSにはJob
   - Step Functionで実行できる！
 
 - cronJobs
   - Event Bridge + Step Function + ECSで同じことができる
 
 - Admission Controller
   - ECSでは同じようなことができるサービスはまだない。悲しみ。

## Amazon ESCにあって、Kubernetesに無いもの
 - ECSタスクにはコンテナディペンデンシー
   - コンテナの起動・終了の順番を指定できる。
     - initContainer等があるが、コンテナ群の起動順序を管理まではちょっと...という感じらしい。


## ToriさんKubernetesとECSに対しての考え
 - kubernetes
   - DevとOpsや、Devとインフラを明確に線引きしようとしている...?
   
 - ECS
   - 開発者が広い範囲の管理を行えるようになっていると思う。

# 入門！ClusterAPI 〜k8sクラスターもk8s APIで管理したい〜 
Cluster APIとは何者なんだ！と言う話。

## クラスタAPIとは

 - Kubernetesクラスタを管理するためのAPI
 - KubernetesのAPIでKubernetesを管理できる
 - パブリッククラウド、プライベートクラウド、ペアメタルなどの様々なインフラで利用可能
 - CRDとCustomController、CLIツールで構成されている。
   - CRD：KubernetesのAPIを拡張し、独自リソースを定義するための機能
   - CustomController：Kubernetes上のリソースの作成、更新、削除に反応して、何かしらの処理を行うプログラム。CRDと一緒に作ることができる。

## なぜクラスタAPIが必要？
Kubernetesの構築・運用をするためにはいろいろ考えないといけないことがある。

 - コントロールプレーンのHA、台数増減
 - Nodeをどうクラスターに参加させるか、台数増減
 - Kubernetesのバージョンアップ
 - 障害時のオペレーション、オートヒール等


Kubernetesが分散システムなので、構築・運用が難しくなる。
→kubernetesは分散システムの管理に向いている。
→ **Kubernetesでkubernetesを管理すればいいじゃん！** となった


>KubernetesでKubernetesで管理することで、構築・更新・自動復旧などのKubernetesのワークロードに載せることができる

→Cluster APIはこれを目指している。

## まとめ
 - ClusterAPIはKubernetesの機能を使ってKubernetesクラスターを管理するための仕組み。
 - インフラレイヤーに注力し、複数の環境をサポートする。
 - 複数のカスタムリソースとカスタムコントローラーが強調して動作していて、CRD/カスタムコントローラーの設計・実装の参考になる。
 - 現在も活発に開発がされており、機能追加が期待される。


# Helmfile: Superchage your deployment pipeline
Kubernetesのdeploy管理が楽になるツールを紹介するぜ！と言う話。

## helmfileとは
- Helmベースの宣言的デプロイツール。
- HelmはKubernetesのパッケージマネージャー。
- 前のデプロイとの差分をみれるコマンドがあったりして便利。


**helmfileサンプル集**
https://github.com/cloudposse/helmfile


## まとめ
Kubernetesのデプロイ面倒でいろいろコストが大きくなりがち。
Helmfileを使うと面倒を減らせるのでいいぞ！（多機能だし）

そのうちHeml公式プロジェクトに入るかも!?!?!?と言う話もあるっぽい。