2019年11月13日に開催されたKubernetes Meetup Tokyo #25の発表内容をまとめたものです
映像はこちら

入門、KubernetesPersistentVolume

坂下幸徳さん(@ysakashita3、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に新しい機能を追加してくのが最近のトレンド
ストレージのモデル
範囲と権限
- 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について

早川大貴さん(@bells17_、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, 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

チェシャ猫さん(@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読書メモの紹介

稲津和磨さん(@ina_ani)、ゼットラボ株式会社

Kubeweekly

Kubernetesの記事をまとめたニュースレターが毎週更新される
メールアドレスを登録すればメールで受信できる
稲津さんが日本語での要約をQiitaに投稿している

Cluster AutoscalerをTerraformとHelmfileでデプロイしてPrometheusでモニタリングする

int128さん(@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な分散ストレージ！

小林さん(@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開催予定

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が取得できるようになる