GCPUG Tokyo Kubernetes Engine Day April 2018に参加した

# なにこれ

GCPUG主催のKubernetes関連セミナー参加メモです
<https://gcpug-tokyo.connpass.com/event/81224/>

# 自分の前提

- 最近はSREっぽいインフラよりの仕事が多い
    - データ分析系
- dockerは結構使ってるが、kubernetesはGKEのチュートリアルやったくらい
- GCPは基本サービスを一通り程度

# セミナーメモ

## MicroServices on GKE

<https://speakerdeck.com/tcnksm/microservices-on-gke-at-mercari>

- deeeet @ Mercari
- モノリシックからマイクロサービスへの移行
  - フェーズが成熟するとスケーラビリティが重要になる
  - ビジネス、機能、組織＝人数

- 既存を活用しながら移行を進めるためのパターン
  - gatewayパターン
    - API gatewayを一つ作り、その配下にいろんなサービスを増やしている
      - 既存（モノリシック）のMercariAPI群も一旦この配下にくっつけちゃう
    - 一つのエンドポイント。共通でやれることはここでやってしまう。SSLとか認証とか
  - stranglerパターン
    - 既存のAPIからサービスを切り出しながら、APIGatewayにぶら下げていく

- マイクロサービス化でいろいろな技術（言語とか）も使える
  - docker化することでインフラの共通化・標準化が一定量にできる

- その他使っている技術、プロダクトについて
  - gRPCやProtocolBufferの活用
  - GatewayはGoLangで自作している（GCPのLBでできないこと）
  - deployはSpinnakerを使っている
    - netflix社製。Blue/Greenデプロイ、カナリーリリースとかのCDワークフローがかける
      - kayentaでカナリー分析して、点数をつけてくれる
      - 点数に従ってワークフローの分岐を書けば良い。人がダッシュボード見て決めてる対応の自動化
  - Istio 
      - 各サービスはEnvoyというレイヤを必ず通して、サービス間リクエストを投げるようにする
      - 集中管理しているサービスとAPI連携して、ポリシー管理、ログなどを取ってくれる
      - マイクロサービスは可視化が超重要。遅い理由調査とか。
      - サービス間のNWのパラメータ、受ける側はリミットとか考えることがめっちゃ増える

- GCP/GKEの使い方
  - クラスタ戦略
      - 3つのリージョンに各々2つのクラスタ
          - Prod/Devのみ。サービスごとにクラスタは切らない。ほんとは一つにしたい  
  - プロジェクト戦略
      - Prod/Devで一つづつ。SREだけがProdに触れる
  - インスタンス戦略
      - n1-standard-16 / n1-highmemory-16
- GCP問題
    - IAM周り
        - 別にサービスごとにPJを立てて、そちらにマネージドサービスを立てる
        - namespaceごとにサービスアカウントを作り、PJマタギのアクセスを許す
    - logging周り
        - 同じPJのstdoutが全部stackdriverに流れ込む（サービス混在）
        - 各サービスごとPJのBQにログ連携するようにstackdriverを設定する
        - realtimeはdatadog+logmaticを検討中
    - 設定はやや複雑なのでIaC。terraform
        - githubでissueを切ると自動でGCP側の操作が行われる

- GCPに閉じてない、外部サービスを使ってるもの
    - CircleCI vs Container Builder
        - github連携
    - datadog vs stackdriver　monitoring
        - 外部サービス連携
    - Gremlin
        - Chaos Enginerringのサービス。あるPODの性能遅くするとかをGUI経由で指定できるらしい

### 参考文献(個人的)
  - kazeburoさん@デブサミ。これ聞いてたのでイメージはある程度つかめていた
  - <https://speakerdeck.com/kazeburo/sre-in-mercari-developers-summit-2018>

## Panel Discussion

### 開発者の責任範囲とは？

- mercariはDockerFile書いてGCRにあげる、SpinnakerのGUIでリリースフローを書くとこまでDev。
  - Kubernetes等のYAMLを書くのは今はインフラ。でもマニフェスト(Podスケールとか)はDevに渡したい
- 規模が小さいチームが多く、Dev/SRE全部見る人が一人はいる、みたいなケースが多かった。
    - 小さくてもやれるのがk8sと理解。

### クラスタ戦略

- モノリシック系なので、サービスごとかなあ。
  - GPUが欲しいサービスがあって、2つクラスタがあるそう
- GoogleのBorg自体が、１リージョン一つなので集約できないことはないはず

### K8sでDBやミドル使う？

- 載せない。基本はマネージド。なければ作る
  - 永続層はやはりコンテナから切り出す、消えるし、と理解。
- オンプレでk8sならミドル使ってる人が多い気がする
- RabbitMQやるかも。Pub/SubのACK時間微妙。

### 監視、ログ

- stackdriverから始める。リリースフェーズではお金かかるけどDataDog。
  - ノードごと、コンテナごとのヒートマップもみれたり、UIやメトリクスは充実

### セキュリティ面で気をつけることは？

- クラスタレイヤはIAM設計で縛る。
- kubectl/sshなどの強い（生の)コマンドも縛る
- GKE Blogが情報源としては良い（K8s blogよりも）。Youtubeに上がってる説明動画も。
- コンテナイメージの脆弱性。GCRにサーチ機能がある。
    - <https://cloud.google.com/container-registry/docs/vulnerability-scanning?hl=ja>
    - できるだけ余計なものを入れないことがこつ。
    - ベースイメージに脆弱性があったりすることも。。

### コンテナイメージ作る時

- goだとalpine linuxにバイナリ置くだけ。シンプル。
  - ビルドも別サーバでやると良い
  - alpineはCコンパイラが違うので、中でなんかやらない方が良い

### ingressへの対応。

- GCPのマネージドサービスが強力。基本使うべし。
    - <https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer?hl=ja>
- healthCheckにハマりやすい罠
  - /が200を返すことがデフォルト条件なので
  - readinessCheckを使うとGETのURLを指定できるがドキュメント不親切。
- 設定を更新した時、都度作り直した方が良いかも（反映されないとかあるらしい）

### GKE のスケール

- Cluster Autoscaler / Horizontal Pod Autoscalerの2種類。併用できる。
  - CAのNode縮退が遅い気がする。Googleの思想？
  - devや負荷テストの時は手で消したり、preemptive運用とかが良い

### K8sの情報収集

- GCPBlogのマイナーバージョンアップサマリが入りとしては良い
  - <https://cloudplatform.googleblog.com/2018/03/Kubernetes-1-10-an-insider-take-on-whats-new.html>

### k8sのバージョンアップ頻度。マスタとノード。

- k8sは0.3離れると１発であげられなくなる
  - 半年に一回はあげる必要がある。
- リリース２週間から１ヶ月程度であげる会社が多かった
- GKEのAutoUpgradeはDevならONが多い
  - PDB使うとSLを落とさずにPodをロールアップグレードしてくれるはず（GKEを信じてれば）
- GCP全般で枯れてないサービスが多いので、走り続ける気持ちは必要かな

- spinnakerは実は壊れやすい。slackとか見てても。x.0ではなく、x.1まで待つ。。

### CI/CD

- Container builder
  - 通知が弱い？Cloud Functionとか書く必要がありそう。
  - jenkinsでコンテナ作ったりしてる人はこちらに引っ越した方が良い
- Spinnaker のエラーログがつらい
  - 1年で数回製品バグがあったが、Javaのraw errorが見えたりする。
  - 気合いを入れて取り組めば利点はある。規模がやや大きい方が良い。

### デプロイ系

- Blue/Green(Red/Black)デプロイ。Podをセレクタで切り替える
  - <http://aws.typepad.com/sajp/2015/12/what-is-blue-green-deployment.html>
  - 基本シンプルでおすすめだが、リソースを2倍食うとこが難点。
- ローリング
  - リソース節約向け。
- リリースの性質や規模などで使い分け？

### GAEのようなバージョンURLの仕組みを作ったり、使いたいと思うか？

- podのバージョンごとにURLが公開されるイメージ
  - リリース時にまず自分でチェックするとか
- Istioでできるらしい

### Jenkins X

- Jenkins -> k8sのプラグイン
  - PRからブランチごとのサービスを立ち上げるくらいまで自動でやるらしい

### GKE以外のマネージドKubernetes Service

- EKS/AKS共にPreview
- Fargate/Azure ContainerみたいにContainer aaSまでいってほしい。。

# 感想

- ライトな気持ちで来てみたが、それでもわかりやすい内容でしたし、自分でやって見る上でも参考になると思った
- 実サービスをやれるレベルまで来ていると感じた。
    - 今の自分の仕事に取り込めるかは別。安定したSLとかいらないことが多いので。
- コンテナaaS欲しい。GCEとかEC2層を意識しない世界が待ち遠しい。。
- 情報のフォローアップに努めよう