kubernetes meetup #7

3
Like
0
Comment

takky

Edited at 2017-10-13

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 / prometeus

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 cyberblac28

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

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 / prometeus

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

takky

376Contribution

ORGANIZATION

パブリック/プライベートクラウドでつかうKubernetes
Kubernetes with Prometheus
kubernetesの色々 by cyberblac28
KubernetesでもServerlessしたい! By y_take_23
Hardware LBで "type LoadBalancer"を使ってみた by SCHOfield
Securing Kubernetes clusters on AWS by mumoshu
githubを使って簡単にhelm repoを公開してみよう by everpeace
まとめ

Edit request