Kubernetes Meetup Tokyo #2に参加してきました

丹内です。Kubernetes Meetup Tokyo #2というイベントに参加してきました。
kubernetes(k8s)はDockerコンテナの管理フレームワークで、運用のための様々な機能を持っています。

発表

Kubernetes evolution and extensibility

• コンテナが非常に多いので、モジュラ(Modularity)にする必要がある
• システムを構成するコンテナの数が増えると管理上の問題が出てくるので、Modularityが重要になってくる。

構成要素

• 1: Cloud Provider
  • LBやストレージ、Multi-AZを提供する Google, Amazon, Openstackなど
• 2: ノード
  • 各マシンを指す
  • ソフトウェアとしてはコンテナランタイム
  • 最初の実装がdocker。他にもrkt(CoreOS)やhyper_(Hyper.sh)など
• 3: スケジューラ
  • Kubernates APIを使うプログラム。
• 4: kubelet
  • v1.0で導入されたNetwork Plugin
  • v1.1ではCNIプラグインを使う
  • storage pluginもある。様々なDBへのプラグインが提供されている
• 4: L7LB
  • nginx/haproxyなど
  • googleは、自前の用途に合うhttp LBを作ってコンテナとしてデプロイしている
• 5: API Server
  • システムの中心。サードパティリソース。
• 6: kube-proxy
  • 複数のコンテナのフロントになるサービスIP。LBのIPなど。
  • キュー・プロキシと発音していた

それ以外で必要なもの

• apiserver
  • Authentication
  • Authorization
  • Admission
• APIコールのバリデート、アクセス制御
• スケジューラに対してのプライオリティ
• APIコンテナからetcdのストレージコンテナへ、APIストレージとしての機能
• Credentialsコンテナ
  • secretなど機密情報を扱う
• kube-dns
  • replacable
  • 動的なDNSを提供
• ログ、モニタリング
  • datadog agent

k8s最新の機能

• deployment
  • ローリングアップデートが基本(Updates-as-a-serviceと書いていた)
  • ローリングアップデートとロールバックがワンコマンドで行われるデモ
• DaemonSets
  • 全ノードで動かすロギングデーモンを設定できる
  • v1.2でβ
• Jobs
  • 特定回数実行するジョブ
  • v1.2でGA
• PesSets
  • クラスタソフトウェアを動かす
  • MySQL　リードレプリカやRedis
  • v1.3でα
• ClusterFederation
  • Federated Service
  • 複数ホストをまたがる耐障害性を持たせる

Kubernetes Monitoring by Datadog

• コンテナをどのようにモニタリングするか?
• k8sをモニタリングする == 乗っているコンテナをモニタリングする and クラスタをモニタリングする
  • Datadog Monitoring Theory
• Datadogが提唱する、活用可能なモニタリング論
• Herokuの12Factor Appみたいなもの
• https://www.datadoghq.com/blog/monitoring-101-investigation/
• https://www.datadoghq.com/blog/monitoring-101-alerting/
• 以下の3つを集めようと提唱している
• Work metrics
  • システムがちゃんと動いていることが分かるメトリクス
  • スループットとか
• Resource metrics
  • なぜその値になったか分かるメトリクス
  • CPUとか
• Events
  • 何がトリガーになったのかわかるメトリクス
  • デプロイとか操作とか
  • まずworkにアラートを設定し、必要に応じてresourceとeventsを見る

どのようにコレクトするか

• オンプレ時代は設定ファイルをハードコードしてても大丈夫だった。AutoScalingも無かった。
• 仮想化時代やクラウド時代だと動的に変わる
  • Sensuで自動登録/自動解除
  • Role-Base Aggregation: ホストじゃなくてロールで扱う。これらの概念が出てきたコンセプト。
• コンテナ時代では、同じコンテナにはエージェントを入れない
  • どのホストにどのコンテナがデプロイされるかわからない
  • どこに置かれるかわからないものをどう追いかけるか
• side-carsパターン
  • サイドカーみたいにアプリケーションコンテナにモニタリングコンテナを付随される
  • シンプルだが、同じホストに同じコンテナが複数デプロイされた時に、モニタリングコンテナが重複する。
• agent with service discovery
  • 全ホストにエージェントを置いて、自分がなにを見なければならないか自分で判断する
  • kubeletに自分が見るべきコンテナを問い合わせてから動作を開始する
  • エージェントの重複はないが、構成が複雑になる。

ネイティブのソリューション

• kubeletとセットでCAdvisorが各ノードにデプロイされていて、Heapsterでアグリゲーションしてダッシュボードに送る
• cAdvisorはkubeletに含まれていて、基礎的なメトリックスを取る。カスタムメトリックスも取れる。
• 自作APIの場合：PrometheusというOSSを使ってカスタムメトリックスを返すエンドポイントを作って公開する
• サードパティAPIの場合：exporterコンテナを使って公開する
• Prometheusは公式ツールのようになっている。サポートするOSSも多い

モニタリングがdatadogの理由

• 公式でintegrationがあるから
• long data retention
  • ロールアップ(一定期間後、解像度が荒くなる)が13ヶ月間ない
  • 一年前の今日と比較できる
• Evnents Timeline
  • Kubernatesとかのイベントを取れる
  • datadog以外でイベントを取れるサービスは少ない
• query based monitoring
  • ホストじゃなくて論理的なグルーピングで見るとき、ラベルとかで扱うことができる

setup

• daemonsetを使って、各ホストにagentが置かれるようにする(dd-agent conteiner)
• kubernatesはプラガブルなので、メトリクスの互換がある(sysdig, cadvisor, ...)
  • dd-agent service discovery機能
  • etcdかconsulに設定を置いて、dd-agentコンテナはそれを見る
  • 動作時、kubeletからコンテナ一覧をもらって、該当するコンテナがあったらテンプレを使ってモニタリングを開始する
  • テンプレートから設定ファイルを動的に作る
• tips
  • datadogはネームタグしか見ていないので、その名前に注意
  • git2consulというツールを使うと楽
  • 変更があったときにテンプレを作るのでタイムラグがない

クラスタモニタリング

• クラスタ全体のメトリクスを返してくれるエンドポイントはkubernatesにはない
• k8sが動いているということは、Podsとサービスが動いているということ
  • ただ何かあった時に切り分けできるように、分けてモニタリングする必要がある
• webアプリとは違ってメトリクスはネストしてはいない
  • 各サービス(kubelet/etcd/pods)のメトリクスのコレクションとかんがえられる
• kubeletは、datadogでモニタリングできる
  • etcdもdatadogはインテグレーションがある
  • Podsは、まず全体をクエリベースでkube-systemコンテナでフィルタリングして止まっているコンテナを大まかに把握したり、HTTPチェックでAPIを監視したり
• ノードの監視は、kuberatesタグをつけてdatadogで見る。

Go Microservices w/ Kubernetes

• モノリシックで大きくなって遅くなったアプリを分割してマイクロサービスにする。ではそのデプロイはどうするか
• サービスが小さく1サーバを割り当てるのはもったいないので、1プロセスのコンテナに必要なリソースのみを割り当てる。
• コンテナのデプロイには課題が多い。ノードが落ちたら、コンテナがクラッシュしたら、アップデートはどうするか
  • 大体の課題をk8sが解決してくれる
• ユーザがk8sのmaster Apiを叩くと、nodeをオーケストレーションしてくれる
• kubectl createでデプロイメントリソースを作り、レプリカセットが監視して一定数を維持する
• rolling updateも、新旧レプリカセットがPodを操作することで実現
• マイクロサービスをどのようにkubeにマッピングするか?
  • 他のアプリに接続するようにそれぞれサービスを作る(アプリ/deployment/サービスがそれぞれセット)
• デモ: フロントエンドアプリとバックエンドアプリ2つとredisから構成されるサービス
  • アプリはgo製
  • ポートのマッピングとLBプラグインの指定
  • それぞれのサービスはgrpcで疎通
  • protocコマンドでPBCからgoのコードを生成
  • それをgoアプリにインポートするとgrpcコネクションを使ってクライアントオブジェクトを生成できる
• goでバイナリを作ると、dockerfileが小さくて済む
  • FROM scratchにバイナリを入れるだけで、10Mくらいのimageを作れる
  • なのでgoはマイクロサービスに向いている

LT

@Ladicle - kubernetes helm & helmc

• manufestをBASHで管理してたが厳しい。ユニットテストしずらい。-> なのでhelm。
• k8sのパッケージマネージャ。
• helm-classicはgithubベースで開発されてたが、k8s-helmはクラサバ型
• まだアルファだが、これからはメンテされなくなるからk8s-helm
• PR出すと数日でレビューされてマージされて楽しい！

@summerwind - Managing manifest files with Spruce

• manifests管理その2
• 環境変数埋め込みたいとかマージして使いたいというのは同じ動機
• YAMLのマージツールで、元はCloudFoundryのツール
• hashicorp/Vaultにも対応。
• YAMLを差分を書いて必要な分をマージするだけで、環境に応じた設定を作れる

@jacopen - もうひとつのk8s PaaS、Deis workflowの話

• k8s自体はPaasではないが、よく出来ているのでそれを元にPaaSを作る試みが多い。その一つがDeis
• deisはdockerimage/dockerfile/buildpackでデプロイできる

@superbrothers - Awesome kubectl explain ?

• デプロイメントリソースを作るとき、どんな構造か分かりにくいという問題がある
• ドキュメントもapi定義書も分量多くて見るの辛い。types.goを直接読むもキツイ。
• kubectl explainというサブコマンドで、リソースタイプを入れるとkubeapiのswatterで公開されているものを見せてくれる
• けどターミナルでしか使えないので、　kubectl-expla.inというサービスを作った

@yuanying - OpenStack Magnum で Kubernetes をデプロイ

• Openstackにdockerをデプロイするコンポーネント
• magnumではBAYというものを作る。BAYはk8sのCluster。
• BayModelというテンプレからBayというk8sクラスタを作りnodeを作る

@dtan4 - （仮）Kubernetes を Go から触る

• k8sec: secretを気軽にいじれる
• secretをアプリの環境変数で使いたかったけど面倒だったのが動機
• kubectlはAPIに似ているので実運用では使いにくいし、非運用者は触りにくい運用者
• k8s api client libraryではgoのみ公式

@Yasu - 本番 (Kubernetes) と開発環境で使えるコンテナ運用

• k8s本番運用までは、サービスのコンテナ化(マイクロサービス化&コンテナイメージ管理)、開発環境もコンテナ管理、データ管理方法の変更などの課題が多い
• コンテナイメージ管理について解説
• docker_authというサードパティイメージがあるので使うと良さそう

@mumoshu - From dev to prod: Kubernetes on AWS

• k8sをHAにしたい。自動化したい
• ツール:coreos-k8s/kube-aws
• 大きな変更をするときはクラスタ作り直しをしている
• 東京のAZが2つなのでスプリットブレインになりやすい
• minikube使って認証
• 本番と同じログ&モニタリングを開発でもdatadog使っている
  • 本番でログ設定が違うのは良くない

@enakai00 - DevOpsにおける組織に固有の事情をどのように整理するべきか

• 前回「ロールと人のマッピングの難しさ」を話したら反響が会ったので共有
• ツールやプロセスは統一できるが、実行するのは人で、それに1ロール1人でマッピングして理想を実現できるというわけではない
• 今いる人に最新のツールやプロセスをマッピングするので、組織ごとに正解は異なる
• 一般論で語れない部分(組織特有の部分)をもっと語ってそういうノウハウを共有するべき
• 勉強会でツールやプロセスを話すのは良いが、一般論では語れないことも語って欲しい。

ちなみに前回の発表はこちら

@tnir ソフトハウスにおけるKubernetes導入の取り組み

• 会社にインフラがないしインフラエンジニアも居ないのでPaaS
• 自分が関わっているところはdockerだが他はオンプレ+ansible。なぜならノウハウがないから導入が進まない。
• いろんな案件で色んなIaaS使っているのでプラットフォーム非依存のk8sは良い
• 古いRHEL使いたい案件もあり、小さな構築をたくさん作って運用している

まとめ

k8sについての会というよりは、Dockerとマイクロサービスの関連性と、それらを運用段階まで持っていくk8sという一連の流れを知れて非常に刺激的な勉強会でした。
多くの人がGolangに言及していたのも印象的でした。運用しやすいDockerimageを作成できるというメリットを活かせるというのも納得です。
昨年のre:Inventから「これからはコンテナとLambdaの時代だ」という話が多かったのですが、Lambdaだけでなくコンテナも導入していけるように日々頑張っていこうと思いました。