Help us understand the problem. What is going on with this article?

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

More than 1 year has passed since last update.

なにこれ

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経由で指定できるらしい

参考文献(個人的)

Panel Discussion

開発者の責任範囲とは?

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

クラスタ戦略

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

K8sでDBやミドル使う?

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

監視、ログ

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

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

  • クラスタレイヤはIAM設計で縛る。
  • kubectl/sshなどの強い(生の)コマンドも縛る
  • GKE Blogが情報源としては良い(K8s blogよりも)。Youtubeに上がってる説明動画も。
  • コンテナイメージの脆弱性。GCRにサーチ機能がある。

コンテナイメージ作る時

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

ingressへの対応。

  • GCPのマネージドサービスが強力。基本使うべし。
  • healthCheckにハマりやすい罠
    • /が200を返すことがデフォルト条件なので
    • readinessCheckを使うとGETのURLを指定できるがドキュメント不親切。
  • 設定を更新した時、都度作り直した方が良いかも(反映されないとかあるらしい)

GKE のスケール

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

K8sの情報収集

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

  • k8sは0.3離れると1発であげられなくなる
    • 半年に一回はあげる必要がある。
  • リリース2週間から1ヶ月程度であげる会社が多かった
  • 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が見えたりする。
    • 気合いを入れて取り組めば利点はある。規模がやや大きい方が良い。

デプロイ系

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層を意識しない世界が待ち遠しい。。
  • 情報のフォローアップに努めよう
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした