この記事は PMOB Advent Calendar 5日目の記事です．
ホントはSlack botの話を書くつもりだったけれど，改善したいところが見つかって準備のために後に回すことにした．
そのかわりというと変だけど，ちょうど JapanContainerDays に参加していたのでそのレポートを公開することにする．
Chris Aniszczyk(COO of CNCF)による基調講演
3年前からk8sが出て現在デフォルトになった ここ3年は大変だった
CNCFも3年目
k8sが人気になった理由
- より多くの組織がクラウドを使った
- CI/CDツール
- プリミティブでマルチクラウド
CNCFのプロジェクトには成熟度がある
- キャズムを超えろ
Kubernetes, Prometheus, Envoyはgraduatedまで行った
認定準拠のプログラム
パートナーは認定を受けているのでちゃんと移行できることが保証できている(EKSとか)
l.cncf.io にCloud Native Trail Mapがある
cloud nativeまでの歴史
- 仮想化されてないハードウェア -> 仮想化 -> IaaS -> PaaS -> Open SOurce IaaS -> Open Source PaaS -> コンテナ -> Cloud Native
2019年これからどうするのか
- 誰でも使えるようにする
- ギャップを埋める
Linuxがマーケットを支配した，Androidにも使われてる
それと同じようにk8sを別の領域にもやっていく
- IoT + Edge + Kuberenetes
例としてchik-fil-Aがすべての店舗でk8sを展開した
kubeedge
Serverless + Nodeless
- s.cncf.io で状況がわかる
- virtual-kubelet
通信業界での変化
- Network Architecture 1.0 -> 2.0 -> 3.0
- -> ハードウェアは2.0と同じ，コンテナ化されたワークロードが動く
- kubervirtも動く，一つのブレーンで動く
Microservices on Kubernetes at Mercari 中島 大一
マイクロサービスプラットフォームチーム
なぜコンテナ・k8sなのか
- 組織とアーキテクチャによりCDが可能になる
- 新しいコードを恐れずにpushできるかが大事
- Immutable Infrastrucutureが必須になる
- 同じ環境を本番に・ロールバック・カナリアリリース
VMでもできるけど何故コンテナなのか
- ビルド・起動が高速
- 可搬性
- リソース効率
何故k8sなのか
- 拡張性
- エコシステム
k8sができること
- ロールアウト
- セルフヒーリング
- ロードバランス
- オートスケール
できないこと
- ソースコードデプロイ・ビルド
- アプリケーションレベルのサービス
- ログ・モニタリング
- 設定する言語の提供
メルカリは色んなアプリケーションがある，
それをうまいこと動かすPaaSはない
開発者がyml書いてる
拡張性について
- コントローラの拡張
- 専用の設定をインジェクト
-> メルカリ用の抽象基盤ができる
でも大変じゃない？
それを助けるエコシステム
エコシステムレイヤーというのが明示的に存在している
-> 大量のツールが有る
自分たちのワークロードにあった抽象化
ServerlessにはKnative，MLにはKubeflowみたいな
エコシステムにコントリビュート
certificate-expiry-monitor-controller LEじゃない証明書が切れたらSlack通知みたいな
Kubernetesによる機械学習基盤への挑戦 谷脇 大輔
PFNではオンプレのGPUクラスタがある(国内最大級)
なぜk8sなのか
- セキュリティ・プライバシー機能
- スケジューリング
- 拡張性
- OSS・エコシステム
harbor, node selector, Pod Affinity, Device plugin
スケジューリング
Custom Scheduler, PriorityClassによるプリエンプション, werbhookによりkube-throtter
kube-throtterによりPriorityClass毎にユーザが実行できるPod数を制御できる
マルチテナント
RBACによってNamespaceへのアクセス制御
PSP, Admission WebhookによりLDAPのユーザIDをセット
最後にPrometheus
自由度の担保
- 特定のツールでロックインしない
- webからそうさとかkubectl execやNFSでマウントしてsshとか
全リソース使った実験ができるように
- 他のジョブはプリエンプションされる
今後
- Kubeflow
- k8sの改善
- 利用をリード
- 自社技術との親和性向上
LINEエンジニアを支えるCaaS基盤の今とこれから 西脇 雄基
LINEのプライベートクラウド IaaS + マネージドミドルウェア + CaaS
IaaSの品質が良くても複雑でそれをエンジニアが使いこなせないと品質が落ちてしまう
複雑性を隠蔽する基盤が求められた
PaaS はk8sで実現
コードをpushするといい感じに公開してくれるようになった 限界もあった
- 複数コンテナ基盤として使いづらい
- バッチ
- インフラ要件が特殊なもの
- 野良Kubernetes
- 監視されてない
- アップグレード
- 社全体の最適化が難しい
KaaSの基盤が高まる
Kubernetesクラスタ + 運用するソフトウェア
GUIで操作できるようになっている
-> k8s詳しくなくても試せる
Ranchaer 2.Xをベースに独自にAPIをラップして作った
できていること・やるべきこと
- 運用コストの削減
- アップグレード
- 洗練されたKubernetesの提供
- パフォーマンス考慮
- 検証済みアドオンの提供
-> プロダクションへ
FaaS
- Event駆動
- Knativeで実現
CaaS
- PaaS -> APIサーバを動かしたい
- FaaS -> Bot webhook, opretation自動化
- KaaS -> 細かいコントロールもしたい
Cloud Nativeの未来とIBMの取組み 斎藤 和史
絶対止めないシステム -> 絶対止めないビジネスへ
顧客分析のためにクラウドネイティブを実践
社内用プライベートクラウドが巨大
Watson API on k8s
The Weather Company(iPhoneの天気) on k8s
HELMを使ってk8s最適構成に
次は
クラスタがたくさん増えてしまう
- 環境の分離
- クラウド活用
- プロジェクト分離
- 地理分散
- マルチクラウド
継続的な運用
-> 使いこなせるスーパーエンジニアが必要
解決先として
- 新しいテクノロジーを積極採用?
- スーパーエンジニアを育てる
- IBM Cloud Garage
- ハイブリッド/マルチクラウドできる仕組みを作る
IBM Multicloud Manager
クラウドネイティブで作る、新しいクルマの世界 小泉 清一
Uberの例が出た
同じ土俵に立つために同じ道具を手に入れる
-> Cloud/OSS, アジャイル/DevOps
GKE/On-premise
研究者がアルゴリズムに集中できるようにAPIでラップしている
事業をニーズに合わせて変化できるためにクラウドネイティブを活用している
ZOZOTOWNシステムリプレイスにおけるKubernetes活用 鶴見 純一
kubernetesを採用した経緯・利用方法
- レガシー
柔軟なリソース確保
オンプレリソース確保
- モノリシック
- 手作業の運用
クラウドにAPIを移行 DBもレプリでクラウドに移行
導入前課題
- デプロイ手作業 -> ローリングアップデート
- 柔軟にスケール -> 水平Podオートスケーリング
- 運用負荷 -> オートヒーリング
移行難易度を下げるためにAzureへ
OSSで最新機能がいち早く導入されるACS Engineを選んだ
namespaceを使ってstaging, prodと分けて，stagingだけデプロイみたいなことができる
デプロイ
カナリアリリース・ローリングアップデート
1年間の本番運用でわかったコンテナがチーム開発にもたらしてくれたもの 永井 勝一郎
会場にコンテナ本番運用してるの半数もいない
開発環境と本番の乖離をなくして，開発サイクルを早く回したい
一部Fargateで動いている
コンテナ導入で設定したゴール
- Dockerfileを開発者全員でメンテする
「強制力を持つ Infrastracture as Code」
クラスタはサービスごと
- 干渉しないように
DevOpsの役割に変化がおきた
今までの課題
構成の把握に時間かかる
Dev「環境どういう構成になってますか」
Ops「コード化 + baseイメージ」
Devがchefとかsshとかで見に行く
本番と構成が違う
- 環境差分が原因で本番で動かない
- 開発者の心理的不安
- 上書きの繰り返し
- 簡単にロールバックできないから慎重になる
PHPバージョンのアップデート
やるべきことが多すぎて時間がかかる
スライドでは9ステップあった
バージョンアップとコード修正が別基軸
- 開発者は開発環境のバージョンととコード修正
- インフラはステージングと本番のPHPバージョンアップ
Docker以後
- ローカルで検証
- ステージングでデプロイ・検証
- プロダクションにデプロイ
ダメでもロールバックできる
デプロイ粒度が，アプリケーション実行基盤そのものに変化した
アプリケーション実行基盤を開発者が自律的にコントロール
-> サービス開発サイクルの速度向上
Imutable Infrastructure
-> 変化に強い安定したシステム運用
導入に必要なこと
- オーケストレーションツールの選定
- 継続的デプロイの整備
- 誰がやっても同じ結果が出るように
- ログ・リソースモニタリングの基盤
- SSHなくても運用できるような仕組み(極端ではあるとのこと)
安定したサービス運用のために
- 複数のコンテナホストの管理
- プロビジョニング
- 落ちたときの振る舞い
などなど必要
-> オーケストレーションツール
オーケストレーションツール
それぞれの環境に適したツールを選択することが重要
- インフラ/SREのメンバが多くいて，高度なことをやるならk8s
継続的デプロイ
- イメージのビルド
- push
- コンテナの入れ替え
1サービスに付き1Dockerfile
ログ・リソースモニタリング
- ログドライバでfluentdやCloud Watch Logsでデータストアへ
- アプリケーションからSaaSへ(Sentry, Papertrail)
- 1コンテナを細かく見るよりかはシステムを系で捉える
なにか起きたときに調査できる体制
導入後にインフラエンジニアは
- 設定変更作業から開放
- 安定して動く基盤を整備
- 速い・安定したアーキテクチャを作る
まとめ
- DevOpsの境界がシンプルになり開発サイクルの速度が上がる
- 心理的安全性があがり，変化に対しての許容度が上がる
- Immutable Infrastructureによって安定したシステム運用が手に入る
レガシーシステムのコンテナ化に挑戦した話 和田 亨
- VMの再現性がない
- スケールに強く
- 実行環境のロックインを避ける
- エンジニアのモチベーション改善
デプロイはcapとfabric
課題
- chefの保守
- Jenkinsプラグイン
- デプロイは踏み台サーバからcap /fabric
- ビルド番号をメモ(?????)
移行
- NodePool scale, pod replica
- Circle CI
- helm template, kubectl apply
Artifactroy
Adtech Kubernetes Engine
Monitoring Logging Deploy
Datadog
- 全NodeにDaemonSet
- AutoDiscovery
streamingに
- 集計するログはfluent sidecarでGCS
- 集計しないログはstdout
stdoutどうするの候補
- Daemonset サービスによってログ量が違うから過剰リソースとなることがある
- Datadog 高い
- fluent-bit リソース食わなさそう 検証中
なので今は捨ててる
Deply
Graceful Restartが必要
移行して
- 過去の夫妻消せた
- メンバにコンテナの良さが伝わった
- ミドルウェアバージョンアップの権勝利リリースが用意
- chefメンテからの開放
- k8sみんなで習得すべくがんばっている
ミドルウェア〜Webアプリまで全てをHelm化したサービスの運用事例 山田 直行
リソースの全てでhelm使ってる
- Goのアプリケーション
- ミドルウェア
自前のChartやOSS
本番で1年以上使ってる
- helm-diff
- (cdk synthのdit diffみたいな感じっぽい)
ローカルのhelmバージョンをバージョン指定で固定する
- メンバーのバージョンを合わせるため
インフラレポジトリにアプリ以外のChartを集約
helm運用
ローカルでもCI/CDでもhelm diff -> helm upgrade
makeでラップしている
運用事例 Redis移行
移行前 自作カスタマイズしたRedis ClusterのChart
- HA構成にするために工夫が必要
- Cluster Nodeが1つ落ちると再JOINできない
- Node Poolのアップグレードできない
- helm installだけでは起動できなかった
移行後 公式チャートのstable/redis-ha
helm
マイクロサービスのまとまりがわかりやすい
デメリットなさそう
- もう1レイヤー出てくる
- makeでラップしてるしそんな意識してない
Chartをどこで管理するか
- OSSのチャートをコピーしている
- 変更に追従できない
v3でhelmのLuaサポート
想定QA
Chart管理はコピペになってる
chartのバージョン固定
レプリカ数は，values.yamlかえてgit push
ci/cd コード変更されたら，ステージングまで自動デプロイ 本番はslack使って手動
イメージタグCI/CDでhelm upgrade --set image.tagする
gitレポジトリ上はlatestとしてコミット
改めて見直す、コンテナベースで作るメリット〜安心して開発を回す技術的ポイント〜 - 藤原涼馬, 伊藤瑛, 宮地克也
cloud native trail mapを参考にどこまで入れるのか考えると良い
既存の技術スタックから考える
インフラの提供がアプリケーション開発の足かせにならないようにする
サービスの発展に本質的ではないものに手間はかけない
ロックインを回避するためにk8s
CI/CDにConcource
- Circle CIのバージョンとライセンスコスト
- コンテナネイティブなCI/CD
- アドホックな入力の排除
コンテナが得意でないものや実装の手間を省いてくれるものはマネージドサービスへ
組織の成熟度に応じて最適な技術スタックは異なる
特定のリスクが別のリスクを呼び込まないか
アプリケーション側の視点から
割れ窓理論
CIに求めること -> 信頼性・実行速度
ローカルは通るけどCIは通らないみたいなこともある
信頼性がないと割れ窓の検出が難しくなる
ビルドの実行時間やばい
-> 二時間かかることもあった
そもそも，環境依存じゃないテストで落ちる方が多い
無駄な奴はdocker buildで失敗させることで時間短縮
Test Sizesの考えに従って外界に依存のないテストからやるようにする
docker buildのタイミングでsmall testを回す
build, small test -> push -> midium という順番
インフラエンジニア視点から
パッケージインストールなど変更が少ないものを上に持ってくる
なるべくbuildしたいPRにちかいImageをcacheとして使う
サービス開発で最初に運用するのはCI・CDサーバ
TBD 原 康紘
サービスディスカバリ
- ロードバランサを利用 サーバサイド
- DNSを利用 クライアントサイド
ARNどうやるの
-> Cloud MapでARNを登録して名前をつける
特定の属性からとか正常状態とかでディスカバリできる
ECSはそのまま使える
servicediscovery コマンドでやる
設定値も同時に付与することができる
App Mesh
マイクロサービスの課題
- 問題の発生箇所を見つけるには？
- 問題発生時他のサービスに影響を与えないようにするには？
- 他のサービスと通信できるように設定するには？
- 通信を可視化するには？
選択肢として
- アプリケーションコードに実装する
- サイドカープロキシへオフロードする
envoyを使って実装
App Mesh
- Cloud Watch
- XーRay
- その他envoyが連携してるもの
サービスメッシュ使っている人会場に0人
AWSでもユースケースが足りてないので機能を絞って提供している
not prodctuion
cliから気合いで使う
Fargate未対応
aws-app-mesh-examples
ECS CodeDeploy連携
ローリングアップデートじゃなくてBlue/Greenも
各タイミングでLambda実行できるのでフック処理失敗でロールバックできる
aws ecs deploy コマンド
CodePipelineからも使える
ステータス見るのはCodeDeploy側
2019年はコンテナよりもクラウドネイティブ!? Knativeのすべて 草間 一人
Knative
コンテナ活用フェーズに入っている
事前アンケートでは44%がDev環境の利用
k8s試すのにも色々やる必要あって大変じゃない？
クラウドネイティブ時代
2016年くらいからどうProdに導入するか？って話題になってきた
2019年はどうやってクラウドネイティブな仕組みにしていくか
Istioのyaml大変
そこで登場したのがKnative
k8sの上にKnativeとIstioという構成になっている
knctlで操作
ここでデモ イメージと名前を指定してすぐwebアプリケーションがアクセスできた
Knative 何ができるのか
一段上の抽象化
Knativeのサービスはk8sのサービスと違う概念
rollout
カナリアリリースがめっちゃしやすい
ymlもかけるけどめっちゃ短くかける
cppforlife/knctl ほぼ公式
Dockerfile作るの大変
Knativeからいい感じに作ってくれる機能がある
Knativeでもイベントドリブンできる
各層でSources, Buses, Flowsで抽象化されている
KnativeのServerlessはFaaSではない
building blockと呼ばれている
LambdaみたいなやつはRiffとかKwskとか
始めるには？
GKEにKnativeの機能を付け加えるやつプレビュー中
おわり
コンテナを本番運用するの大変だし，中々やれている会社もあまりないという感じではあったけれど，周辺ツールも揃っているし進化も速いしで知らないといつか置いてかれるのかなぁという感じだった．
二日目もそのうち投稿すると思う．
