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

なにこれ

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

自分の前提

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

セミナーメモ

MicroServices on GKE

• 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層を意識しない世界が待ち遠しい。。
• 情報のフォローアップに努めよう