イベント URL: CloudNative Days Kansai 2019 - #CNDK2019
- docker の裏側
- コンテナの仕組みの解説、コンテナとは何かについて
- 知っている & 資料以上のことはないのでレポートはスキップします!
資料 URL: https://slideshare.net/zembutsu
実は CloudNative 要素があまりないと思っている 話の内容としては CloudNative Days Tokyo と同じような内容らしい(資料見た気がする)
-
マイクロサービスチームが Kubernetes クラスタの管理をしている
- namespace でマイクロサービスを分ける
- RBAC, ServiceAccount で権限を管理している
- 決済手法ごとに利用するマイクロサービスが異なる
-
マイクロサービスのため SLO の観測, Observability の設計を Kubernetes で解決する(Istio ?)
-
CloudNative != 技術、重要なのは技術ではなく組織カルチャー
資料 URL: https://speakerdeck.com/tjun/cloudnative-days-kansai2019
Anthos 自体が複雑で Google Clooud が出してきたサービスとたてつけが異なるので、解説します
(Tips: Google では古代ギリシャ語をプロダクトコード名に使うらしいけど分かりづらいので反対運動が起きているらしい)
-
Anthos
- k8s をベースにしたアプリケーション管理プラットフォーム
- ソフトウェアのサブスクリプションライセンスとして提供される(オンプレミスでも他社クラウドでも使える)
-
Anthos の主要機能
- サーバーレス(YAML を書きたくない人向けにグラフィカルにデプロイできるインターフェイスを提供する)、マーケットプレイス(ミドルウェアを 1 クリックでデプロイする)、クラスター管理、ポリシー管理、サービス管理
-
GKE On-Prem(VMWare vSphere 6.5 で動作する)
-
Anthos は Kubernetes のクラスタを立てるだけに近い
-
GKE On-Prem
- k8s のクラスタ自体のコントロールプレーン(VM のコントロールプレーン)には GKE On-Prem の vCenter を使う
- F5 のロードバランサが使えたりするので k8s と組み合わせられる
- オンプレミスでエージェントが動いていて、 GCP の API に投げているので GKE のコンソールから操作できる
-
Anthos Config Management(ポリシー管理) の仕組み
- GKE クラスタに ACM のエージェントがインストールされている状態
- エージェントがリポジトリとの差分があればクラスタに反映するような動作をする
- 誤ったオペレーション(namespace が消されて動かなくなるような場合)があれば自動的にロールバックするような仕組みになっている
- クラスタ毎に参照するリポジトリのブランチやタグを変更することができる
-
Anthos Service Mesh(サービス管理)
- Istio Control Plane の一部を Google が管理する
- トポロジーグラフを GCP コンソールから見れる (トポロジーグラフが大きくなってきたときはテーブルも使えるので使う)
- マイクロサービス毎に SLO の設定できる しきい値を超えると Stackdriver を経由して notification が来る
-
-
資料: なし(?)
前職のポジションで担当していたことの続きのお話
-
伝えたいこと
- CloudNative への移行で組織文化を良くする
- チームに合った選択をする
-
Mackerel の変遷
- On-Premise -> Cloud Based -> Cloud Native への移行
- 時系列データベースの移行、プロビジョニングツール(Chef, Ansible)の移行
-
既存サービスの移行が大変
- CI/CD を維持にしながら移行
- ツールを文化に合わせて試行錯誤しながら選択する
資料 URL: まさよし (@yoyogidesaiz) | Twitter(ここにあがるはず)
-
ペパボの開発環境における問題
- メンテナンスしていないと動かなくなるので、開発環境から k8s で構築したい
-
heroku や CloudFoundry で BuildPack が使える
- heroku で作った BuildPack が CloudFoundry で使えなかったりする
-
CloudNative BuildPack
- Pivotal と heroku が 2018 年に立ち上げた
pack build
するときにアプリケーションリポジトリを指定するとイメージが作成される (ビルドプログラムを書く??) (detect フェーズで Gemfile が存在すると Ruby の処理をしたりする)- SecurityFix があるとイメージを更新する (環境によって利用するパッケージのバージョンを指定する(if 文分岐できる))
-
techtoncd/pipeline
- knative/build は deprecated で techtoncd/pipeline を使う
- Task と Pipeline でパイプラインを実現できる
- デプロイ自体は ArgoCD をつかってデプロイする
- pipeline でコンテナイメージのタグにリポジトリのコミットハッシュをつける
-
既存環境からの移行
- pod から nginx のリバースプロキシに forward して既存環境にパスする
- coredns の設定を変更して、名前解決を捻じ曲げる(どういった理由でこういうことをしているか気になった)
- 移行後は pod に開発環境がある
-
Telepresence
- Telepresence を異常終了すると開発環境が影響を受ける
- Telepresence 中に Pod が置き換わると困る 自作シェルスクリプトで頑張っている
-
ツール: external-dns, cert-manager, Telepresence, Hashicorp Vault(権限管理)
-
開発環境を k8s に移行する意義 k8s をキャッチアップするためにインフラに k8s を使う、将来の技術投資
資料 URL: CloudNative Buildpacksで創る、CloudNativeな開発体験 - Speaker Deck
R & D な内容
-
CloudNative なソフトウェアをいかにうまく使うか & 作るかというモチベーション
-
マイクロサービスに対して変更が加わったときどの通信経路に問題があるかを知りたい
- 遅延オーバーヘッド、偽陰性、計測準備コスト
-
感想: 利用する側なので選択肢が増えることはいいことなので楽しみ & iptables じゃなくて nftable 使ったらどうなるだろう(パフォーマンス良くならないかな)
話の内容のほとんどは資料で書いてもらえている
質問した内容 Q: tcpaccept を使った CPU 利用率は sys, user どちらが大きい? A: 半分半分くらい
資料 URL: 分散システム内のプロセス間の関係性に着目したObservabilityツールの設計と実装 / Transtracer CNDK2019 - Speaker Deck
-
Operator 入門向けのセッション
- 知っているけれど復習目的で聴講することにします!
-
すでにあるオペレーターから逆算して用途を考える
-
k8s は様々な Controller とそれを利用する Resource で構成されている Operator = Custom Controller + Custom Resource
-
なぜ Operator でやるのか k8s の能力であらゆるものを自動化、あらゆるものを k8s の管理下に置く
- Pod の起動順序、整合性をどのように担保するのか
- 手続き型でやっているのは if - else - なので大変で今までと変わらない
- アプリや k8s クラスター運用の知見をコード化し、自動化する
-
Operator がないと人がオペレーションをするしかない Controller を実装して Operator をデプロイして自動化する ex. 問題があれば OpenShift のノードを引退させたり NoOps なストレージを実現するアプローチ(Ceph + Rook + NooBaa) Operator の Operator が最近は出てきている、複数の Operator を管理する (Meta Operator)
-
OperatorHub の宣伝 Automate のレベルが書かれている RedHat が certified している Operator もある
-
Operator Lifecycle Manager(OLM)
資料 URL: Operator Basic in CNDK2019 - Speaker Deck
-
2019.03 に AWS EKS に移行、 GitOps を導入
-
2019.08 DataDog に監視、ログを移行
-
freee の Kubernetes はシングルテナント
- サービスチームごとに Kubernetes が割り当てられる (感想: サービスチームごとに Kubernetes クラスタ分けるのって管理大変そうだけどどうなんだろう)
-
GitOps への興味 GitOps はローカルコマンドを使わない、アプリケーションコードだけですべて解決する ツールは Flux, ArgoCD, werf など色々あるけど、自前で実装している(clusterops コマンド)
-
GitOps で何が嬉しいのか
- 集中した権限管理、kubectl で deploy する必要がない安心感
-
社内の共通の helm ファイルをまとめたリポジトリがある
技術というよりは freee 内の Kubernetes 運用や開発体制の文化的な話かな、 ChatOps をやっているところもあった
- 課題 CircleCI に強い権限が付いている、GitHub Actions 使いたい (前は CodeDeploy Agent を使っていた)
資料 URL: Kuberneteの運用を支えるGitOps
- 仕事ではなく、どちらかというと趣味の話
発表前から資料が絶賛されていた、 15 のトピックがあって1つ1つのトピックが短いけど、聞いてるだけで最高の内容でした
発表内容自体はスライド内容に書いてあるので資料見れば ok です
ベストプラクティスはこうだと言われているが、 KubeCon NA で聞いた他社事例ではこうしている、一方コロプラではこうしているみたいな会社によってアプローチが異なるのが面白かったです
資料 URL: [CNDK2019]Production Ready Kubernetesに必要な15のこと / Production Ready Kubernetes 15 Rules - Speaker Deck