kubernetes meetup #7

10/12(木)に開かれた k8s meetup #7のメモを公開します
スライドは 以下connpassに公開されているのでそちらから。
https://k8sjp.connpass.com/event/67092/

#  パブリック/プライベートクラウドでつかうKubernetes
## AbemaTV
- node 200大
- GWの70万同時接続
- デプロイ
     - Deploykun (ChatOPS)
     - リリース共有 / かなりあリリース

- ロギング
     - CloudLogging + Cloud Pub/sub
     - Podの標準出力はLogging
     - アプリログはPub/subへ投げてBQへ

- 監視ツール
     - Stackdriver / prometheus

## Private Cloud
- Dockerイメージ
     - GCR
- ロギング
    - 魔改造したfluentd
- kubesparyでのデプロイが遅め
- 内部で完結すると高いので適度に外に逃がす (GCR)

## 新規サービス もmicroservice アーキテクチャでGKE
- 開発初期は属人化しやすい。
- 社内ノウハウ
- 開発が活発

## デプロイ
- DockerイメージはCircle CIでビルドしてレジストリへPush
- 開発時はkubectlでリリースしてた
- オペミス多かった

## デプロイ中期
- 手動カナリアリリース
- ミスしても問題ないように1podだけリリースできるように。

## デプロイフロー後期
- ChatOps

## デプロイフロー今後
- Spinnaker, Concourse CI
- 新規サービスで採用

## Helmの採用
- yamlの作成コスト削減

## ログ
- ログが多すぎてfluentdが高負荷に
- stdout fluentdからCloud Loggingへ
- アプリログはPub/Sub -> BQ

## 大量のメトリクス
- podの監視はStackDriver
- Podが対象だとStackDriverが遅延
- Prometeusの導入

## まとめ
- 自前でk8s立てるときは全部管理しないようにする。

## 属人性の観点
- 開発サービスが小さいのでそれぞれが開発するようになると属人性がたかまる可能性がある
- PrometeusのGUIはgrafana




# Kubernetes with Prometheus
## Prometheus
- Pull型のメトリクス監視
- 多彩なService Discovery
- CNCFコンポーネントの1つ

## Pull型
- 監視対象に軽量なhttp server(Exporter)を立てて、Prometeus側が引っ張ってくる
- KubernetesのAPIServerにレスポンス送ることでいい感じに収集してくれる


## Alertmanager
- Prometheusで発生したアラートを管理するプログラム
- Alertmanager (重複の排除など)
- 複数の通知先に対応


## Kubernetesでの活用
- パフォーマンスモニタリング
     - CPU/RAM
     - アプリケーションごとのメトリクス (req/s)

- アラーティング
     - Podの異常検出
     - Nodeの異常検出

## Prometeusのデプロイ
- 関連コンポーネントをクラスタ内にデプロイして監視するといい (APIサーバ周り)
- ただしそのクラスタが落ちるとアラート出ないので、外部に一個用意するといい。

## 監視のレイヤー
- App : アプリケーション固有の実装
- K8s :  cAdvisor : コンテナごとCPU,RAM kube-state-metrics:pod数
- Server : NodeExporter : 死活監視 

## アプリケーションの監視
- アプリケーション側にPrometeus形式のエンドポイントを実装
- Service側にアノテーションを追加するだけ

## cAdvisorの注意点
- k8s1.7.8でメトリクスが歯抜けバグがある
- Podごとに30以上のメトリクスが出力
- cAdvisorのメトリクスデータの通信量に注意

## Prometheusの反映自体をどうするか。
- 設定ファイルはCOnfigMapで管理したい
- メモリにキャッシュが乗っているので再起動したくない
- reload APIがある。

- HelmのPrometheus Chartsにサイドカーの実装がある

## Prometheusのメモリが足りない
- メモリはstorage.local.target-heap-sizeのデフォルトが2GB
- どんなに大きくても2GB以上で開放しようとする
- バッファして書き込む感じなので開放が間に合わないとRushedModeへ。アラートも上がらない。

- target-heap-sizeを増やす。 カーディナリティを低くする。
- 関連メトリクスは外部から監視するといい。

- カーディナリティが高いとメモリ、CPU使用量が多くなる。

## アラートの通知ルールは難しい。

# kubernetesの色々 by cyberblack28
- Rancherコミュニティの人
- 最近のk8s
- AWSがCNCFのプラチナ会員に
- GitHubがKubernetesの採用
- k8sはデファクトになりつつあるし、今後採用が増えていく

- Rancher2.0は何が新しいのか
- k8s上で動く


# KubernetesでもServerlessしたい! By y_take_23
- いわゆるコンテナレス
- イメージの管理の煩わしさが減る
- Kubless
     - Kubernetes-Native
     - functionごとに個別のPodを作成
     - ソースコードはConfigMap
- Fission
     - On Demand Specialization
     - 汎用podをプールして呼ぶ

# Hardware LBで "type LoadBalancer"を使ってみた by SCHOfield
- オンプレでGKEのtype:LoadBalancerみたいなものを作る話。

# Securing Kubernetes clusters on AWS by mumoshu
- k8sのアプリはどこで動くか ? コンテナ
- コンテナに入っているもの
     - bash/curl /apache / python / glibc などなどが入っている
     - コンテナに入っているもの　どこに脆弱性があるかわからない。
- 対策
     -　バックドア仕込めないようにする
     - 影響を最小限にする。
          - 脆弱なアプリを作らない
          - CoreOSのclair 脆弱なイメージがデプロイされないように
          - kube2iam
- RBAC
     - K8sAPIをpodやユーザごとにアクセスコントロールする機能


# githubを使って簡単にhelm repoを公開してみよう by everpeace
- 公式のHelm使うとRedis周りも簡単にデプロイできる
- Helmは複数Repoに対応している。
- Helm RepositoryはHTTP/HTTPSエンドポイントならOK





# まとめ
Cyber Agentさんの事例はかなり参考になりましたね。
普通のアプリケーションレベルだとfluentd詰まるってことはあんまないと思うんですがAbemaレベルだとそこがネックになるのか...って感じでした。
また、Prometheusは触ったことないのでちょっとやってみたい感じはしますね