Kubernetes Meetup Tokyo #25 まとめ

- 2019年11月13日に開催された[Kubernetes Meetup Tokyo #25](https://k8sjp.connpass.com/event/150873/)の発表内容をまとめたものです
- 映像は[こちら](https://www.youtube.com/watch?v=m4SpEzKN-RM)

# [入門、KubernetesPersistentVolume](https://speakerdeck.com/ysakashita/ru-men-kubernetes-persistent-volume)
- 坂下 幸徳さん([@ysakashita3](https://twitter.com/ysakashita3)、[ysakashita](https://github.com/ysakashita))、ゼットラボ株式会社

## 初心者向けストレージのあれこれ
- 混同しやすいワード
    - データプレーン
        - 格納と転送処理を担う  

- コントロールプレーン
    - 管理APIなどの処理を担う

- ストレージ種別
    - ブロックストレージ
        - ストレージの元祖
        - 内蔵ドライブと同じように見える
        - 速度は一番早い
        - DBやOSのブートディスクに使われる
        
    - ファイルストレージ
        - NAS Serverが内部にある
        - NAS Serverがブロックストレージに繋がっている
        - ネットワークドライブとして見える
        - ファイルの共有に使われる

    - オブジェクトストレージ
        - 例：AWSのS3
        - 中にHTTPS Server
        - HTTPSのURLでアクセスできる
        - Key-ValueストアのDBがあることが多く、メタデータが保存されており、それを基にストレージのデータにアクセスする
        - 大量のデータが格納可能
        - 写真や動画の格納に使われる

## Kubernetesにおけるストレージモデルと動き
- CNCFにストレージ系のサービスは多数
- Kubernetesでは1.9からCSIがサポートされ、ストレージの機能は徐々に増えている
- 1.13でCSIがGA
  - CSIに新しい機能を追加してくのが最近のトレンド

- ストレージのモデル
    - PersistentVolimeClaim
    - PersistentVolume
    - StorageClass
    - 管理者とユーザーの役割が考慮されており、管理者はPVとSCを作成し、ユーザーがPVCを作成してそれをPodに割り当てる 
    - 対象はブロックストレージとファイルストレージがメイン
      - オブジェクトはHTTPSで書き込めるので対象になっていない

- 範囲と権限
    - SCとPVは全Namespaceで共通のリソース
      - クラスタ全体の管理権限が必要
  - PVCはNamespace毎のリソース
- PersistentVolimeClaim
  - Volume要求仕様
     - SC名やサイズ、アクセスモードなどのスペックを示す
  - Kubernetesでのアクセスモードは3種類
     - ReadWriteOnce(RWO)
         - 1つのNodeからRead/Writeでマウント
     - ReadOnlyMany(ROX)
         - 複数のNodeからReadOnlyでマウント
     - ReadWriteMany(RWX)
         - 複数のNodeからRead/Writeでマウント
- PV
  - SC名やサイズ、アクセスモード、Reclaim policyが指定される
  - Reclaim Policy
      - PVCが削除された場合のPVの振る舞い
        - Retain
          - PVは残る
        - Recycle(Deperecated)
          - PVは残すが中のデータは削除
        - Delete
          - PVも削除
- SC
  - ストレージプールを表す
  - ProvisionerがAPIを呼ぶ
- Container Storage Interface(CSI)
  - コンテナオーケストレーション向けの標準仕様
  - Kuberentesを初めとした主要なコンテナオーケストレーションで採用されている
- StatefulSet
  - PV、PVCを安全に使うリソース
  - Pod名に番号が付与される
  - Podの更新処理が番号順に行われる
  - Pod生成時にPVCを自動生成
  - 削除してもStatefulSetとPodが削除されるのみ
      - PVとPVCの誤削除防止
- PVの割り当て
    - Manual Provisioning
      - 管理者がSCとPVを事前にデプロイしておき、ユーザーがPVCを使ってPVを選択
    - Dynamic Provisionig
      - 管理者はSCのみを事前に準備しておき、ユーザーがPVCをデプロイするとPVが自動生成される
- PodのRollingUpdate時の振る舞い(セルフヒーリングのときも同じ)
  - 古いPodはストレージからデタッチされ、新しいPodが再度アタッチを試みる 
  - これによりデータは消さずにアップデートが可能
- マネージドストレージ
  - 各クラウドプロバイダで提供されているストレージサービスを仕様する
- GKEでの事例
  - デフォルトでSCがデプロイ済み
  - PVCでのマニフェストをデプロイ
  - Dynamic ProvisiongでPVができる
  - Podで使う場合はマウントパスとPVCの名前を記述する

## よくある質問と回答
- ストレージは何を選んだら良いか？
  - ポイントは
      - 格納したいデータの価値
      - アプリからの利用用途
      - 障害発生時の対応体制
- Cinder(Open Stack)とA社どちらがいいか？
  - 比較対象が違う
- DBにはブロックストレージ or ファイルストレージ？
    - ブロックストレージがベター
    - ファイルストレージは非推奨(MySQLのリファレンス)
      - ファイルストレージのロック機能が邪魔をしてしまう
- DeploymentでPVを使って良い？
    - StatefulSetがおすすめ
    - Terminating中にCreateされたPodがアタッチを試みてエラーになることがある

# [KubernetesにおけるCSIについて](https://docs.google.com/presentation/d/1S0FcCAgZn11ZFbJfU2eUhOa--vONqrsd0waRvwoTBcE/edit)
- 早川 大貴さん([@bells17_](https://twitter.com/bells17_)、[bells17](https://github.com/bells17))、株式会社IDCフロンティア


## Kubernetesにおけるボリュームプラグインの歴史
- v1.9でCSIがアルファリリース、1.13でGA
- 最終的には全てのプラグインをCSIプラグインとして外部に切り出す予定
    - CSI移行のモチベーション
        - ストレージプロバイダ視点
            - ストレージプロバイダはCSIプラグインを実装するだけで各コンテナオーケストレーターに対応できる
        - Kuberentes視点
            - ボリュームプラグインのソースコードをKubernetesから除外できる
                - 各コンチロールプレーンのサイズも小さくなる
            - ボリュームプラグインはコンテナとして提供されるものであり、それによってマシンとの依存関係を除くことができる

## CSI
- コンテナオーケストレーターでストレージを利用するための共通の仕様を定義したも
- CSIドライバ
    - コンテナイメージ形式で提供される
    - コンテナオーケストレーターとの通信は　ｇRPCプロトコルを使用する
- 提供する機能
    - ボリュームの作成/削除
    - ノードへのアタッチ/デタッチ
    - ボリュームのマウント/アンマウント
    - ボリュームのスナップショット作成/削除
- gRPCのインターフェース
    - Controller Plugin
        - Master Nodeで動くgRPCサーバー
        - 2種類のgRPCサービスが実装されている
        - 以下の機能を提供
            - ボリュームの作成/削除
            - ノードへのボリュームのアタッチ/デタッチ
            - ボリュームのスナップショット作成/削除
    - Node Pligin
        - Worker Nodeで動くgRPCサーバー
        - 2種類のgRPCサービスが実装されている
        - 以下の機能を提供
            - ノードにアタッチされたボリュームのフォーマット
            - ボリュームのマウント/アンマウント

## KuberentesとCSIの連携方法
- Controller Plugin/Node Pluginそれぞれにサイドカー形式でアプリケーションを提供する
    - Controller Pluginには5種類、Node Pluginには1種類のサイドカーがある


## おまけ
- CSIドライバを自分で開発する際の便利なツールがいくつか用意されている

# How to develop the high-available Redis database application on Kubernetes
- Ran Xuさん([@Haier0715](https://twitter.com/Haier0715), [fengzixu](https://github.com/fengzixu/))

## Why we want to develop it
- ユーザーの観点
    - Kubernetes上で、オンラインサービスをサポートするためのデータベースを使いたい
    - DBAは高給なので雇えない
- Redis DBの観点
    - RedisをKuberentes上で動かすのには難しい
    - ラーニングコストが高い

## What capabilities do we want
- 必要な性質
    - データの信頼性
    - 高可用性 
    - 使いやすさ
    - 保守のしやすさ

## How to implement it 
### Highly Reliable Data
- Redisのデータ永続化には2つの方法があり、どちらも有効化した
    - RDB
        - スナップショットをRDBファイルとして保存
    - AOF(Append Only File)
        - すべての書き込みコマンドを記録
- Kubernetes上ではPersistent Volumeを使用
- リモートブロックストレージとしてCeph RBDを使用

### Highly Available Service 
- ユーザーがアクセスするためにデータリンクを提供
- SLB(Super Load Balancer)を作成し、ここからRedisクラスターにアクセスする
    - これにより、Nodeの一部がダウンしてもRedisクラスタにアクセスできる
- アーキテクチャのメリット
    - タスク(バックアップやヘルスチェック)の競合が防げる
    - オペレーターとkube api-serverとの通信が減らせる

### Easy to use
- Helm Chartに設定を記載し、`helm install`コマンドでデプロイできる

## その他
- コードはOSSに公開予定

# LT 
## [賢く「散らす」ためのTopology Spread Constraints](https://speakerdeck.com/ytaka23/kubernetes-meetup-tokyo-25th)
- チェシャ猫さん([@y_taka_23](https://twitter.com/y_taka_23))

### 背景
- Podの配置を複数のNodeに分散させるだけでなく、そのNodeのトポロジー(AZなど)を考慮した配置をするべき
    - AZ障害が起きても問題を最小限にするため

### 既存の「散らす」機能
- DaemonSet
    - 無駄が多くなる
- Pod Anti Affinity
    - 各トポロジーに1Podしか配置できない
    - ローリングアップデートができない

### Topology Spread Constraints
- v1.16でアルファ機能
- Nodeを論理的にグルーピングできる
- spec.topologySpreadConstraintsに記述
- Topology間でPodを分散させる
    - 許容できるPod個数の差を指定
    - Podのラベルで指定
    - 「強制」か「優先」が選択できる
- 複数の条件を指定すると条件が満たされずに配置できなくなることがあるので、Skew(個数の差)の調整や優先条件の採用をすることで回避する

## [KubeWeekly読書メモの紹介](https://www.slideshare.net/inajob/kubeweekly/inajob/kubeweekly)
- 稲津和磨さん([@ina_ani](https://twitter.com/ina_ani))、ゼットラボ株式会社

### [Kubeweekly](https://kubeweekly.io/)
- Kubernetesの記事をまとめたニュースレターが毎週更新される
- メールアドレスを登録すればメールで受信できる
- 稲津さんが日本語での要約を[Qiita](https://qiita.com/tags/kubeweekly)に投稿している

## [Cluster AutoscalerをTerraformとHelmfileでデプロイしてPrometheusでモニタリングする](https://speakerdeck.com/int128/deploy-the-cluster-autoscaler-with-terraform-and-helmfile-monitor-with-prometheus)
- int128さん([@int128](https://twitter.com/int128))、 NTTデータ

### Cluster Autoscalerとは
- Nodeのリソース(CPUやメモリ)使用状況に応じてNodeの数を増減するツール
- Helm Chartで簡単にデプロイできる
    - GKEとAKSではマネージドサービスで提供されている
- AWSではCluster AutoscalerがAuto Scaling Groupを操作するためのIAM Roleが必要
    - kube2iamかkiamを使って付与する

### Helmfile
- `helm install`コマンドではなくhelmfileを使ってデプロイ
- 複数のHelm Releasesのセットをyamlで宣言できる
    - 環境依存値もkustomizeのように外出しできる

### パイプライン
- Kubernetesクラスタレイヤーはhelm、クラウドレイヤーはTerraformで管理

### Cluster Autoscalerのモニタリング
- メトリクスをPrometheusで収集
    - ServiceMonitorを利用するとServiceとPrometheusを紐づけられる

## [Rook v1.1なら出来る！PVC-basedな分散ストレージ！ ](https://speakerdeck.com/tzkoba/rook-v1-dot-1narachu-lai-rupvc-basednafen-san-sutorezi)
- 小林さん([@tzkb](https://twitter.com/tzkb))

### Rook
- v1.1が9/13にリリース
    - PVC-based OSDs/MONsが追加

### PVC-basedとは
- Host-based
    - ホストのディレクトリをホストパスでみる
    - Nodeにディスクなどが必要
    - Podは移動不可
- PVC-based
    - MONとOSDにPVC経由でストレージをアタッチ
    - 特別なNodeが不要
    - Podは移動できる

### PVC-basedのユースケース
- KuberentesによるStorage as a Serviceの実現に近付く
    - NodeとVolumeが分離されているため復元力が高い

### 告知
- [Japan Rook Meetup](https://rook.connpass.com/event/152741/)開催予定

## Kubespray でCinder CSI Plugin対応した話
- 櫛原さん

### Cloud Provider external対応
- In-treeのCloud Providerの問題点
    - remote_ipが取得できない
    - Openstackで非推奨
- OpenstackのCloudControllerManagerが外出しされる
### Cinder CSI Plugin対応
- Cinder CSI PluginはNode上で動いている
- Cinder API経由でCephにストレージを洗い出す
- CentOSだと動かず、CoreOSにしたら動いた
- remote_ipが取得できるようになる