エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned
15 likes11,439 views
OPENSHIFT.RUN Summer 2020 登壇スライド
More Related Content
What's hot (20)
Similar to エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned (20)
エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned
- 1. エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned September 24th, OPENSHIFT.RUN 2020, Daiki Kawanuma
- 3. エンタープライズにおける Kubernetes 導入あるある Kubernetes 導入のモチベーション • リソースの抽象化 Declarative Configuration • 自己回復性 Self Healing • 自動スケーリング Auto Scaling https://www.datadoghq.com/ja/container-report/ ビジネスのアジリティーを高めること Kubernetes の本質的な価値 For instance, average container lifetimes exceed 30 days in 3 percent of Kubernetes environments. エンタープライズにおける主要なモチベーション • コスト削減（インフラの集約性） • 可搬性、柔軟性のある基盤を選択し将来へ投資 コンテナを避け続けるのがリスクになるのも事実 • 世界レベルで標準化されている • 時代の流れとして逆らえない • 巨人の肩に乗る • “ソリューション要件がコンテナ” ← 間違ってはいない
- 4. エンタープライズにおける Kubernetes 導入あるある コンテナ・ Kubernetes に期待を掛ける営業側 Azure AKS GCP GKE VMware Tanzu Kubernetes Grid on AWS on Azure on GCP on IBM Cloud IPI & UPI Kubernetes 戦国時代 • 選択肢として Kubernetes が選ばれやすいのは事実 • 営業としても、お客様にとって価値あるものだと信じている on Premise
- 5. エンタープライズにおける Kubernetes 導入あるある その結果発生する”絵空事の” Kubernetes 導入 べき論はわかってます… 営業の目指した価値を体現するのが現場 たとえアンチパターンでも成功に導かなければいけない使命 絵空事をなんとか、現実の世界に落とし込んでみせよう ※絵空事：絵は実際の物とは違って誇張され美化されて描かれているものであること Win, Win Kubernetesは 素晴らしいんやな Kubernetesは 素晴らしいんです 現場的に厳しい戦いになることは 往々にしてある 『あなたにKubernetesは必要ですか？』 『多分あなたにKubernetesは必要ない』 『Kubernetes の導入時に考えるべきこと』
- 6. エンタープライズにおける Kubernetes 導入あるある 段階的な Cloud Native 化への道 • ネガティブな表現をしたが、現実問題として一息に Cloud Native 化など不可能 • 許容される変更量、リスク量は限られている Kubernetes を導入して既成事実を作ってから徐々に文化を変えていくのもまた道 Kubernetes Driven で Cloud Native Journey を歩み出す
- 7. 自己紹介 Daiki Kawanuma Associate Architect, Red Hat Certified Specialist, AWS Certified Solution Architect 所属 役割 レガシーアプリを適切にモダナイゼーションする 働き方 半年から数年程度でお客様を渡り歩く “遊撃隊“ のような働き方 お客様 A社 お客様付きSE API化案件 お客様 B社 お客様付きSE 新規構築 案件 お客様 C社 お客様付きSE 更改案件 弊部門 時間（半年〜数年で移動） • 構想策定 • API • Kubernetes/OpenShift 等 IBM Japan, Cloud Application Services, Modernization Strategy
- 8. お客様事例 金融系のお客様 サーバー間取引顧客 ブラウザ顧客 バックエンドシステム ランクAシステム 法人顧客 従業員 • 約20年の歴史を持つオンプレミスのシステム • 高可用性／低レイテンシが求められるランクAのミッションクリティカルシステム • Kubernetes(ICP) で本番稼動中 更 改 サーバー間取引顧客 ブラウザ顧客 バックエンドシステム ランクAシステム 法人顧客 従業員
- 9. お客様事例 完全にOSと統合、Immutable 自動化オペレータで高度な自動化 シームレスにKubernetesをデプロイ 完全に自動化されたインストール ワンクリックでアップデート クラウドリソースを自動スケーリング 金融系のお客様 OpenShift＝Enterprise Kubernetes プラットフォーム への移行をご検討中
- 10. 本セッションのスコープ Cloud Native 化を進めるアプローチ Top Down, Bottom UP の両面からのアプローチが不可欠 営業 啓蒙 啓蒙 啓蒙 Bottom UP Top Down 本セッションのスコープ 開発部門・SIer ビジネス部門・お客様 マネジメント (意思決定者) 現場 指示 相談 RFP 相談
- 11. AGENDA • Lessons Learned 1：コストとスケール • Lessons Learned 2：現行運用との兼ね合い • Lessons Learned 3：モダナイゼーションへの道 • Lessons Learned 4：チーム • まとめ
- 13. Lessons Learned 1：コストとスケール 立ちはだかる税金の高さ • 4 vCPU • 16GB Memory Master Nodes Infra Nodes × 3ノード • 2 vCPU • 16GB Memory × 3ノード Worker Nodes Kubernetes “を”動かすのに必要なリソース＝税金 18 vCPU, 96GB Memory 72vCPU, 110GB Memory × 40 Pod ※今回の案件においては Datadog 等の SaaS を使う選択肢も無かった 使い方によっては税金が高くみえてしまう（特にインフラの集約性に着目した場合） 今回は税金を払うモチベーションはあまりないので、できるだけ節税したい
- 14. Lessons Learned 1：コストとスケール 立ちはだかる税金の高さ • 4 vCPU • 16GB Memory Master Nodes Infra Nodes × 3ノード • 2 vCPU • 16GB Memory × 3ノード Worker Nodes × 40 Pod 削れない 槍玉に挙がるのはここ トラディショナルな方法でもできるんじゃないの？ 直近は要らないんじゃない？ 今後 Kubernetes をやっていくなら必須なのだが… だが、今を乗り切る方法もあると言えばある
- 15. Lessons Learned 1：コストとスケール 立ちはだかる税金の高さ 実際に、Kubernetes では泣く泣く削りました Master Nodes Infra Nodes Worker Nodes Promtail 開発環境 ステージング／ 本番環境 Shell kubectl get pod kubectl top podLocal PV 軽量な PLG を 選択 Grafana は非常に便利だった。 何かが起こったとき（障害・負荷試験等）に状態の推移をグラフィカルに見られるのは良い また、ログを各ホストサーバーへ取得しにいくのはやはり面倒だった。
- 16. Lessons Learned 1：コストとスケール 立ちはだかる税金の高さ OpenShift では Infra Node の導入を検討中 Master Nodes Infra Nodes Worker Nodes 開発環境 ステージング／ 本番環境 • Red Hat のサポートが付く EFK を選択 (ただし運用のコアとはしない 後述) • Prometheus/Grafana はコアコンポーネントとして実質必須
- 17. Lessons Learned 1：コストとスケール 立ちはだかる税金の高さ Lessons Learned • Master や Infra の税金に勝るある程度の規模の Worker ノードにしたい（マルチテナントも有効） • とは言え、最初からでかいクラスターから始めるのは難しい場合が多い • 将来像と合わせて投資ということにする • TCO で比較する • 現行のコストと比較する • 当たり前だが、ロギングやモニタリングのコンポーネントを入れないと後で辛くなる • システムとしての重要性に加え、ビジネス面でも価値を訴求したい デイリーアクティブユーザー 都道府県別アクセス数成約率 OS /ブラウザ別アクセス数
- 18. 最近の個人的疑問 EFK が特に重い EFK vs. PLG https://www.cncf.io/blog/2020/07/27/logging-in-kubernetes-efk-vs-plg- stack/ 将来的に OpenShift に PLG の採用はあるのか？
- 19. Lessons Learned 1：コストとスケール スケーラビリティに制限のあるオンプレ環境 基本的にHWを自由に増減させることはできなかった • ギリギリのリソースでやりくりする場合が多くなる • Requests を調整して押し込めるしかない Infra Node #1 Requests CPU: 98%（定常時は30%程のCPU使用率） • Alertmanager は監視のコアコンポーネントとして用いる • 運用上クリティカルになるものは減らせない コアコンポーネントも減らせない サービスレベルで Requests を決める • サービスレベルは気にしない (運用のコアコンポーネントにはしない) • まずは導入したい（入れることに意義）
- 20. Lessons Learned 1：コストとスケール スケーラビリティに制限のあるオンプレ環境 リソースの調達には時間が掛かる • リソース追加には決済が伴うので、おいそれとリソース追加はできない • リソース見積もりをある程度精緻に行う必要がある • Core / Memory は Hardware Requirements として記載あり • OpenShift の場合 CR にデフォルト値として設定されている • ストレージ容量見積もりの手法 • アプリケーションログは現行をベースにサイジング • Elasticsearch は INDEX を張る関係上、ログ容量の3~5倍で見積もり • コアコンポーネントのログ／メトリクス量は検証クラスターで確認 検証クラスター（UPI）＠ 問題はストレージ容量の見積もり
- 21. Lessons Learned 1：コストとスケール スケーラビリティに制限のあるオンプレ環境 Lessons Learned • 大前提として、余裕のあるリソース確保には尽力したい • そうは言っても確保が難しい場合もあるかもしれない • サービスレベルを決める • Requests / Limits を駆使する • スケーラビリティに制限があるなら、尚更 PoC の重要性は高まる • リソース見積もりは実際に動かしてみることが一番 • PoC をして Feasibility を見極める（リソース見積もりに限らず重要）
- 23. Lessons Learned 2：現行運用との兼ね合い 現行運用ソフトウェアとのインテグレーション 現行運用 SW(master) • プロセス監視 • メトリクス監視 • ログ監視 現行の運用方式 システムA 現行運用 SW(agent) 現行運用 SW(agent) 現行運用 SW(agent) システムB ・・・ システムN Kubernetesだけ 別のシステム監視とはいかないな ※許容されるリスク量・変更量の話も関係する 現行運用 SW(agent) 現行運用 SW(agent) • 統合監視基盤で運用を行っている
- 24. Lessons Learned 2：現行運用との兼ね合い 現行運用ソフトウェアとのインテグレーション ソリューション（プロセス監視・メトリクス監視） Alertmanager Endpoint 現行運用 SW(agent) 現行運用 SW(master) 運管サーバー アプリケーション Pod, コアコンポーネント Pod カスタム Pod Master, Infra, Worker Nodes
- 25. Lessons Learned 2：現行運用との兼ね合い 現行運用ソフトウェアとのインテグレーション ソリューション（ログ監視） 現行運用 SW(agent) 現行運用 SW(agent) 現行運用 SW(agent) 現行運用 SW(agent) 現行運用 SW(agent) 現行運用 SW(agent) 現行運用 SW(master) アプリケーション Pod Red Hat Enterprise Linux Worker Nodes • Worker Node には RHEL を採用
- 26. Lessons Learned 2：現行運用との兼ね合い 運用文化とのせめぎ合い（インターネット接続） オンプレ環境はインターネット接続不可 お客様DC • オンプレ環境は基本的にインターネット接続不可 • 対象システムでインターネット接続を行った実績はなし OpenShift 4 のインストール方法 1. 直接接続方式 2. プロキシー接続方式 3. オフライン方式 ヤバイ、辛いという 前評判を聞いた https://rheb.hatenablog.com/entry/openshift42-proxy-upi 絶対に通さないと辛い 通さないといけない前提で話をもっていく
- 27. Lessons Learned 2：現行運用との兼ね合い 運用文化とのせめぎ合い（インターネット接続） プロキシー接続方式 registry.redhat.io *.quay.io sso.redhat.com cloud.redhat.com mirror.openshift.com *.cloudfront.net quay-registry.s3.amazonaws.com api.openshift.com art-rhcos-ci.s3.amazonaws.com nginx.org OpenShift 4 のファイアウォール設定 • 当然 FQDN です。ありがとうございます。 • FQDN指定が可能なFWを選択する必要があった
- 28. Lessons Learned 2：現行運用との兼ね合い 運用文化とのせめぎ合い（インターネット接続） 実際の穴あけドタバタ劇 僕 お客様 セキュリティ統括 FW申請書 • 月末締め • 翌月末穴あけ実施 統合FW 担当者 穴あけ 『穴あけまでに実質2ヶ月程度掛かる』 registry.redhat.io *.quay.io sso.redhat.com cert-api.access.redhat.com api.access.redhat.com infogw.api.openshift.com https://cloud.redhat.com/api/ingress mirror.openshift.com storage.googleapis.com/openshift-release *.apps.<cluster_name>.<base_domain> quay-registry.s3.amazonaws.com api.openshift.com art-rhcos-ci.s3.amazonaws.com api.openshift.com cloud.redhat.com/openshift FW申請書 いざ、インストール！ ERROR xxx xxxxxx ERROR xxx xxxxxx ERROR xxx xxxxxx ERROR xxx xxxxxx ERROR xxx xxxxxx 失敗！！！
- 29. Lessons Learned 2：現行運用との兼ね合い 運用文化とのせめぎ合い（インターネット接続） 実際の穴あけドタバタ劇 registry.redhat.io *.quay.io quay.io sso.redhat.com 2ヶ月のロスタイム 今度は失敗するわけにはいかない… お家 N/W MacBook Pro Proxy サーバ OCP master #1- 3 OCP master #1-3 OCP infra #1-2 OCP infra #1-2 OCP worker #1- 3 OCP worker #1-3 Red Hat Servers Broadband Router Firewall 以下の通信以外は拒否する様に設定 • DNS • HTTP • HTTPS 拒否 された通信をログに出力し、下記の各 OCPサーバーから Proxy を経由しない通信 (≠ HTTP(s) の通信) の有無を洗い出す HTTP(S)の ログを取る 自分の MacBook Pro で検証
- 30. Lessons Learned 2：現行運用との兼ね合い 運用文化とのせめぎ合い（インターネット接続） registry.redhat.io *.quay.io sso.redhat.com cloud.redhat.com mirror.openshift.com *.cloudfront.net quay-registry.s3.amazonaws.com api.openshift.com art-rhcos-ci.s3.amazonaws.com nginx.org quay.io infogw.api.openshift.com cdn.redhat.com storage.googleapis.com subscription.rhsm.redhat.com 結果の申請書 • 開発・構築時の留意事項 • 現行のネットワーク文化がある場合は要注意 • リードタイムを短くする努力をするか、2,3回失敗しても大丈夫なスケジュール的余裕を持つべき • 今後の保守に向けて • マイナーバージョンアップグレードで接続先が増減することは容易に想像できる • アップグレード失敗時の対策として最低限、FWのログ取得は必須 • 合わせて、よりスピーディーなワークフローへの改善にも努力したい Lessons Learned
- 32. Lessons Learned ３：モダナイゼーションへの道 アプリモダナイゼーション The Twelve-Factor App を指針の1つとする 概要 説明 方針 1. コードベース バージョン管理されている1つのコードベースと複数のデプロイ 対応済 更改前からSubversionを利用 複雑化したアプリケーションを整理する余地はまだまだ存在する 2. 依存関係 依存関係を明示的に宣言し分離する 対応済 更改前からMavenを利用 DockerfileによりOSレベルの依存関係まで明示的になった 3. 設定 設定を環境変数に格納する 対応 環境設定用XMLファイルから環境変数に置換 4. バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う 対応なし バックエンドが変更できないため 特にGWと呼ばれるキューイングサービスとは密結合している（独自実装を多く含む） 5. ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する 対応済 コンテナの可搬性により、ステージの分離がより厳密になった 6. プロセス アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する 対応なし アプリケーション改修のコストが非常に大きいため バックエンドが変更できないため 7. ポートバインディング ポートバインディングを通してサービスを公開する 対応 アプリケーションサーバーを含むコンテナイメージ とKubernetesのServiceの機能によってプ ロセス間の通信を制御する 8. 並行性 プロセスモデルによってスケールアウトする 対応（一部） アプリケーションを細かいプロセスに分離する、ただしマイクロサービス化はしない 一部アプリケーションのみ Deployment によるスケールアウトが可能になった 9. 廃棄容易性 高速な起動とグレースフルシャットダウンで堅牢性を最大化する 対応（一部） コンテナ化によってプロセスの軽量化を実施（主にミドルウェア） アプリ的なグレースフルシャットダウンには非対応 10. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ 対応（一部） 時間のギャップ：本番環境への適用に要する時間が2時間から1時間に減少 人材のギャップ：一部あり ツールのギャップ：コンテナ により開発環境でも容易になったが、GWに課題あり 11. ログ ログをイベントストリームとして扱う 対応なし ロギングコンポーネントの不採用およびロギング機能の変更負荷により断念 12. 管理プロセス 管理タスクを1回限りのプロセスとして実行する 対応（一部） 管理スクリプトの一部はコンテナイメージ内に同梱されコンテナ内で実行されるが、 手動実行の運用手順も残っている
- 33. Lessons Learned ３：モダナイゼーションへの道 Git 移行と Single Source of Truth Subversion から Git へ • 約20年間 Subversion で運用されてきた環境を段階的に Git へ移行 • コンテナ／Kubernetes 周りから Git 化を始める • 様々なツールが Git を前提に作られている • GitOps をしたい！ • スキルフルな要員が集まりやすいので Git 移行の障壁が小さい Single Source of Truth • 動かすために何をすればいいか分からない • ドキュメントもどこにあるか分からない • コンテナや Kubernetes により IasC, CasC が非常にやりやすくなった • YAML や Dockerfile が設計書そのもの • あとはその設計に至るまでの AD(Architecture Decision) がわかれば良い Excel 設計書 ＋ Redmine Wiki Subversion で管理されている ソースコード全体 今回 Git 移行のスコープとした コンテナ・Kubernetes 周りは全体の 2.4% まだまだ先は長いが、何事も小さな一歩から 脱却したい ソースコード ＋ Markdown
- 34. Lessons Learned ３：モダナイゼーションへの道 本当に必要な CI/CD • Kubernetes の早いライフサイクルに対応する必要がある (3ヶ月ごとのマイナーバージョンリリース、半年ごとのアップグレードの必要性) • 今までのN年塩漬けとは全く異なる考え方が必要になる • 本当に必要な CI/CD ってなんだっけ？ • テストを自動化しましたが CI/CD じゃないないよね？ • 目的とゴールを再確認しよう 【目的】 • 何らかの変更があってもサービスに影響が無いことを確認する 【ゴール】 • リリース・クライテリアを決める • それをできるだけ素早く簡易に実行できるようにする (自動化が絶対の手段とは限らない) 何らかの 変更 リリース・クライテリア ・ xxx ・ xxx ・ xxx 何かしらの自動化 簡易な手動実行 リリース https://access.redhat.com/ja/support/policy/updates/openshi ft OpenShift のライフサイクル
- 35. Lessons Learned ３：モダナイゼーションへの道 本当に必要な CI/CD • どのレイヤーまでをスコープとするか Host OS Orchestration Container Container Container Container Container Runtime Automated Operations Manifest Manifest Package Manager Cluster / Application/ Developer Services マニフェスト〜アプリケーションの機能確認は当然やるでしょう 各種 Operator や Prometheus 等の Cluster Service はどうしよう 性能や可用性等の非機能確認はどうしよう 非機能どこまでやろう？ インフラの CI やる？ • どこまで自動化／パイプライン化するか ソースコード取得 ビルド 単体テスト パッケージ コンテナビルド 結合テスト アーティファクト登録 ステージングデプロイ パフォーマンステスト等
- 36. Lessons Learned ３：モダナイゼーションへの道 Git 移行と Single Source of Truth Lessons Learned 本当に必要な CI/CD • 技術よりは仕組みやプロセスといったメタなことが障壁になりやすい • 活発に議論できるメンバーを3人以上集めたい • 現行の仕組みに詳しい人を巻き込むことも重要 • まずは「やってみる、やって見せる」ということが重要に感じる • 内容が良ければ、「一緒にやりたい」と言ってくれる人が現れる • Tool Driven でも大いに結構 • 導入してみると案外上手く動き出すってこともある メタな議論にも直地点を付ける（自戒）
- 38. Lessons Learned ４：チーム Kubernetes に適応したチームつくり OpenShift のサポート期間 • マイナーバージョンのサポート期間は約9カ月 • アップグレード期間も考慮すると半年ごとのアップグレード作業が必要 スーパーマンが一人は居ないと厳しい (本当は複数人ほしい) • 作りきったら終わりではない（≠塩漬 け） • 継続的な保守が不可欠 https://access.redhat.com/ja/support/policy/updates/openshi ft
- 39. Lessons Learned ４：チーム Kubernetes に適応したチームつくり お客様付きSEへのスキトラ お客様付きSE • 基本的なコマンド操作は習得済み（ kubectl get pod 等） • Kubernetes の仕組みはまだ理解不十分 僕 • 障害解析ができる • リリースノートが読める • 人に教えられる お客様付きSE お客様付きSEのみで Kubernetes の保守を回せることが理想
- 40. Lessons Learned ４：チーム Kubernetes に適応したチームつくり OpenShift スキル獲得 https://www.redhat.com/ja/services/training/do288-red-hat- openshift-development-i-containerizing-applications 1. Red Hat OpenShift Development I: Containerizing Applications 2. 週1回程度のスキトラ SA Role Role Binding
- 41. Lessons Learned ４：チーム Kubernetes に適応したチームつくり OpenShift スキル獲得 3. Operator ハンズオン https://github.com/Daiki-Kawanuma/kubernetes-operator-handson • OpenShift の設定は基本的に CR の適用で行われる • Operator の概念の理解が不可欠 『最小構成』の なんちゃって Operator 4. 社内勉強会の企画 • 最終的には Kubernetes を『教える側』になってほしいという期待 • 人に教えるには3倍の理解が必要 若手（1〜3年目）への勉強会を企画中
- 42. Kubernetes に適応したチームつくり Lessons Learned ４：チーム Lessons Learned 2. いきなり全部を教えすぎない いきなり全部並べられても分かるわけがない 相手の知識レベルに合わせて“教え過ぎない”ことを意識する 勉強したい人が自分のレベルが分からない・その人のレベルにあったコンテンツが無いのが辛い そもそもDockerの良い点や動かし方がわかっていない時にいきなりK8sの概念を聞いてもよくわからな い コンテナに限らずそれぞれの人のレベルに合わせた説明やコンテンツは需要があるのかなと思う 1. ユースケースで刺す 概念や機能を教えても腹落ちしづらい（Kubernetes のジャズ的な性質） ユースケースに刺して機能を教えていく 一緒にハンズオンやりながら説明していただけたのはめちゃくちゃ良い あとは実際に動かせる環境が準備されているというのも良い 3. 自分の作業過程や情報源をオープンにする 考え方や思考過程を目に見えるところに置いておく 気づいてもらう工夫をする 何を知っているべきか、何ができればいいのかがわからない 欲しいのは結果を導くための途中経過 4. 手を動かさせる、自分でやらせる 手を動かさないと始まらない 運用引き継ぎフェーズで一挙にスキトラは絶対に機能しないのでやめた方が良い
- 43. • 本番稼動中だが、今のところコンテナ起因の障害は０ • お客様のモチベーションであったインフラコストは集約は達成できた • 既存運用方式とのインテグレーションも問題なく実施できた • Lift & Shift の “Lift” を成功裏に実施できた まとめ で、実際に Kubernetes 導入どうだったの？ サービス目線 • リリース作業に要する時間が2時間から1時間に短縮できた • Kubernetes のリソースの集約化／抽象化という側面も開発の効率化に寄与した 開発目線 あるべき姿を定義しておけばあとはk8sが色々やってくれるというのは便利ですよね あとリソースの種類とかがわかっていればどこに定義が書いてあるかとかも探しやすいのがいいなと思います エンプラど真ん中のシステムに Kubernetes を導入したが、ちゃんと運用できてる
- 44. • ビジネスアジリティを求めるのか • 運用の自動化を求めるのか • 開発生産性の向上を求めるのか…etc まとめ コンテナ化第二章に向けて 今後、どんな Shift を描くか、Kubernetes に何を求めるのか • ビジネスアジリティの話をすると、今回削減できたのは全体のごく一部でしかない • 本当に効果を上げようと思ったら、改善できる箇所がまだまだ沢山ある やはり組織・文化と向き合うことは避けられない リリースまでに要する時間 今回の Kubernetes 導入で 削減できた時間 • チーム全体のスキルアップが必須だが、まずは一人目のスーパーマンの育成が急務 • とは言え、一人のスーパーマンに頼っていてはスケールしないので、スケールする仕組み作りが組織として必要 これから本格的に始まる Day2 Operation, Kubernetes を保守する辛みと向き合う
- 46. EOF Special Thanks • Satoshi Doi • Yusuke Urakawa • Hiromitsu Iwata • Kensuke Shigyo ご清聴ありがとうございました。
Editor's Notes
- #4: ・聴講者に触れる Kubernetes導入のモチベーション ・まずK8sの本質的な価値
- #6: エンハンス
- #7: エンハンス
- #16: エンハンス
- #17: エンハンス
- #25: 3つの方式 Alertmanager のエンドポイントを叩く Prometheus のエンドポイントを叩く Grafana のエンドポイントを叩く 1.Pros ・Prometheus が稼働していれば良く、Grafana はダウンしていても良い ・拡張性が高い、後からの他のメトリクスを監視対象にすることが容易 ・PrometheusへのAlert定義がGrafanaに比較すると面倒。Alertが正しく設定されているかビジュアルに確認できない
- #26: Pross ・個別だとスループットが下がる ・障害時の影響範囲が小さい ・アプリごとに Fluentd の設定をカスタマイズしやすい Cons ・リソース（特にメモリ）を食う
- #27: ・運用文化（この中でピックアップをしますよの小話） ・インターネット疎通 ・本番ルーム作業 ・セキュリティ（意味あるなしではなく） ・本番昇格作業 ・災対
- #31: 今回はとにかく入れるんだ 運用文化を変える暇は無いんだ Kubernetes Driven で文化を変えてやる
- #34: エンハンス
- #38: DXを支えるテクノロジーとエンタープライズ