初参加です。
明日明後日位のイベントのday0的な位置づけ K8sなど中心に。
- Tanzu
13:00- General Session
パットゲルシンガー、レイ・オファレル、クレイグ・マクラッキー
- Technolosists who master multi-cloud will own the next decade.
- The Five S’s
- Soeed, Security, Scalability, Stability, (Cost)Savings
14:30- 『クラウドネイティブ人間』になるための自動化入門
草間一人(Pivotal Labs)
- 自動化：アプリにもインフラにも共通する項目
- なぜ自動化したいのか
- 生産性を上げるため
- 他者の力を借りる
- 「水車」紀元前200年
- 昔からあったが、普及していなかった
- 奴隷を使ったほうが効率が良かった（コスト）
- 昔からあったが、普及していなかった
- 現代最強の労働力：コンピューター
- 「水車」紀元前200年
- 他者の力を借りる
- 生産性を上げるため
- クラウドのメリット
- APIがある
- アウトプットの違い
- 数十倍の差がある組織は実際ある
- エンジニア個々の能力がそうであるとは限らない
- 0リング理論
- たった1箇所の問題が全体に影響すること
- スペースシャトルチャレンジャーの事故から
- 逆に、一部のを劇的に改善しても、大して変わらない
- ステップを減らすと出力が改善する
- マイクロ秒、ミリ秒の世界では、人間の介在自体が０リングである
- クラウドに置き換えて改善という考え方から脱却しないといけない
- →クラウドネイティブ
- IaC, オーケストレーション
- K8s
- NoOps
- No Uncomfortable Ops
- なぜ運用は嬉しくないのか
- たくさんの問題が発生する
- サーバーダウン、NW障害、、ログ対応、昼夜問わず・・
- たくさんの問題が発生する
- 手続き的vs宣言的
- K8sは宣言的
- APIを順番に叩いていくのが手続き的
- Project Pacific
- vSpereの中でK8sが動くようになる
- コンテナもVMもK8sクラスタ自体も宣言的にデプロイできる
- 自動化の不都合な真実
- 自動化は腐る
- リポジトリからパッケージがなくなっていて死ぬ
- パッケージの依存関係が壊れて死ぬ
- 継ぎ足ししていたら環境が汚れて
- 自動化ツールのバージョンアップで
- 自動化ツールがオワコンになって
- 前任者に寄る自動化が魔窟で
- 上記の問題点を運用でカバーしてじわじわ
- クラウドネイティブな技術も腐る
- ツールのバージョンアップで死ぬ頻度は高い
- 様々なツールが出てきているが多くは淘汰される
- 正しく理解せず使うと、結局運用でカバーすることに
- 例：istioのテスト保証K8sバージョン
- 良くなっている麺も多い
- IaCが矯正される
- 環境変数を使うので環境の汚染が置きにくい
- 決まったフォーマットでコード化するので魔窟になりにくい
- コード化しているので複数人でレビューできる
- なりにくいだけで、ならないわけではない
- テストをしよう
- いきなり全部を自動化しようとは考えないこと
- 自動化した部分がトラブル続きだった場合は、結果として出力が落ちてしまう
- 全体プロセスの見直しも重要
- テクノロジーだけで解決するのではなく、全体フローから見直し、不要なものを削除する
- 自動化は腐る
- Factorioおすすめ
15:30- Anthosで実現すつモダンなアプリケーション開発
篠原一徳(Google Cloud)
- Anthosとは
- アプリケーションのモダナイぜーションのためのプラットフォーム
- GKEをオンプレや他社クラウドでも利用できるようにする
- 従量課金ではなく、サブスクリプションライセンスで提供している
- 古代ギリシャ語で「花」
- モダナイぜーションの目指すところ
- 高速なリリースサイクル
- 追加・変更につよい
- 容易に拡張
- 高可用性の維持・向上
- モダナイぜーションに向けた技術観点でのアプローチ
- マイクロサービス化
- インフラとアプリの疎結合化
- コンテナに関連をまとめる
- サーバーレス
- 自動化
- マネージドサービス活用（注目）
- Toil（面倒ごと）を抱えない
- Anthos Config Management
- NamespaceやQuota, ROleBindingなどの設定をハイブリッドがK8s環境に自動的に展開
- 設定をクラスタ間で同期
- コンプライアンスポリシーを継続的に適用
- Policy as code
- 各クラスタがgitに保存した設定を監視している。変更があれば差分を自動的に反映する。
- クラスタごとに設定を分けたい場合は、gitのブランチを分けて管理する
- NamespaceやQuota, ROleBindingなどの設定をハイブリッドがK8s環境に自動的に展開
- Anthos Service Mesh
- マネージドIstio
- コントロールプレーンをGoogleが管理
- Envoy（あんぼい）
- ユースケース
- ハイブリッド構成
- スケーリングを柔軟に行いたいアプリをクラウドに
- パブリッククラウドに保存できない情報を扱うアプリをオンプレに
- 既存システム（オンプレ）との連携がタイトなアプリをオンプレに
- パブリッククラウドのマネージドサービスと連携したいときにクラウドに
- マネージドK8sをどのクラウドでも同じように動くように
- クラウドベンダー間でもサポートバージョンなどの差異がある
- Monitoring / Logging の一元化
- Stackdriverに集約できる
- ソフトウェアサプライチェーンの統一
- 野良Jenkinsの駆逐
- ハイブリッド構成
16:30- Kubernetesセキュリティのベストプラクティス
仙波慎也(VMware)
- CNCFのクラウドネイティブ定義
- 2015年から
- CNCFのK8sセキュリティベストプラクティス
- 全部で9つある
- 最新バージョンへのアップグレード
- インプレースアップグレード
- 新しいクラスタを立ち上げる
- データタイプ
- ステートレス：マスターノード、ワーカノード
- ステートフル：etcd、永続ボリューム
- データ保護方法の選択肢はいくつかある
- VELEROを推奨
- https://github.com/vmware-tanzu/velero
- vmwareが買収した
- RBAC
- ロールスプロール問題
- クラスタとNAMESPACEの乱立に寄り、無秩序な状態になっている
- 考えすぎない。プリセットで用意されているロールを活用する
- Developer(単一のNSへのadmin), Mangers(view), Cluster-Administrator
- ロールスプロール問題
- ネットワークポリシー
- NS、pod、ipセレクタで制御する
- 監査ログの有効化
- APIサーバーは、監査目的ですべての要求を記録する
- 監査ログは、非常にノイズが多い場合があるため、必要なもののみ記録する
- ノードセキュリティの強化
- TLSは、それをサポートするすべてのコンポーネントで有効にする必要がある
- etcdはコントローラーから分離し、ファイアウォールで保護する必要がある
- 一貫性のあるセキュリティ運用が求められる
- VMware NSXでできる
17:30- お客様事例から学ぶKubernetesプロジェクト成功の秘訣
スコット・ロウ(VMware)
- 銀行のシステムリプレイスの話
- K8sに移行
- CustomResourceDefinitions(CRD)を使った
- Key takeaways
- Start with a single use case, and solve that user case first.
- The solution doesn’t have to be perfect from the beginning.
- Find what works and replace what doesn’t work.
- Using a building block approach makes it easier to swap components.