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は触ったことないのでちょっとやってみたい感じはしますね