OCHaCafe これからはじめる！Kubernetes基礎

Copyright © 2019, Oracle and/or its affiliates. All rights reserved.
| これからはじめる！Kubernetes基礎日本オラクル株式会社クラウド事業戦略統括クラウドソリューション推進本部ソリューションエンジニア茂こと Oracle Cloud Hangout Café Season2 #1

| Kubernetesが何者かを知り仕組みをざっくり理解すること今日の目標 2

| 自己紹介 3 • 茂こと（しげること） • 日本オラクルのソリューションエンジニア – 入社後数年Oracle DB、Exadataを担当 – 昨年からCloud Nativeソリューションの色々を担当 • CloudNative Days Tokyo 2019：7/23 コミュニティセッション【CNCFサンドボックスプロダクト15本ノック!】登壇します。宜しくおねがいします。 @cotoc88 撮影：JapanコンテナDays実行委員会 https://cloudnativedays.jp/cndt2019/

| 8/6，7 Modern Cloud Day Tokyo 4 宜しくおねがいします…

| 本日の内容 • Introduction • Docker/コンテナ仮想化とは • Kubernetesとは • Kubernetesの主要なリソース • Kubernetesを実現するプロセス群 5

| Introduction システムに求められるニーズと開発手法のトレンド 6

| 企業システムに求められるニーズ • ビジネスにもとめられる進化のスピードと品質 – サービスの早期リリース – 市場の動向/反応を早期フィードバックして対応 – サービス停止による機会損失をなくす • 企業システムは変化するビジネス要件に短い時間で対応（リリース）できることが求められるようになり、それに伴い開発アプローチも変化 7 社内業務の効率化から新ビジネスの創造へ

| リリース ITインフラアプリケーション月次週次日次/時間毎複数サーバ VM(仮想マシン) 開発アプローチシンプルな開発モデルウォーターフォール DevOps Agile、CI/CD コンテナ .Net Java クラサバから Webアプリへマイクロサービス A B C 三層アーキテクチャ DB APP 2008 2019 ～2000 システム開発アプローチの変遷 8

| 高頻度リリースを実現するための開発トレンド 9 アーキテクチャと開発手法の両面から高頻度リリースの取り組みが行われている実行環境 • マイクロサービス・アーキテクチャ – 疎結合な複数サービスを組み合わせる事で、俊敏にアプリケーションを構築する設計思想 – 変更の影響範囲をサービス単位に留められるため、高頻度のリリースに適する • 継続的インテグレーション/デリバリー – ソースコードの変更を契機にビルドからテストまでを自動化 – テストされたアプリを環境毎に自動でデプロイ – 自動化に高頻度リリースを実現するアップデートビルドコミット自動化された一連のテストリリースプロセスの反復環境が分離されているのでシステム全断が起きにくい

| Cloud Nativeなアプリケーションであるとは? 10 ビジネスに求められる「スピード」と「柔軟性・拡張性」を実現する設計思想クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミューダブルインフラストラクチャ、および宣言型APIがあります。これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。 (略) コンテナ、コンテナ・オーケストレーターはあくまで実現手段の1つ https://github.com/cncf/toc/blob/master/DEFINITION.md CNCF Cloud Native Definition v1.0

| Docker/コンテナ仮想化とは 11

| Docker/コンテナ仮想化とは • Docker – 2013年に登場したコンテナ型仮想化技術 – コンテナのランタイムに加え、コンテナイメージの作成・配布のエコシステムを提供 • コンテナ型仮想化の特徴 – コンテナの容量が非常に小さい（数MB～）。動作が軽い → 手軽に使いたいソフトウェアのコンテナを入手して、どんな環境でもすぐに動かすことができる軽量・高速な仮想マシン + それを作成・配布するエコシステム

| コンテナ型仮想化 • 特徴 – 軽容量/高速 • カーネル部分をホストOSと共有するため軽量 • ゲストOSが無い分起動が早い • オーバヘッドが少なくパフォーマンスが高い – 実行環境の隔離 • アプリ間の影響が最小限 – 可搬性 • 環境毎の差異をコンテナが吸収 • 13 コンテナ型仮想化という技術で実現される仮想マシンの一種 H/W ホストOS Bin/Lib アプリA Bin/Lib アプリB Bin/Lib アプリC Bin/Lib アプリD コンテナ管理基盤

| ハイパーバイザー型コンテナ型仮想化の実現方式仮想マシン(VM)は、OSの完全なコピー(ゲストOS)を保持する VM毎に、OSをインストールする必要があるカーネル部分をホストOSと共有するため、 VM毎に、OSをインストールする必要は無い性能ゲストOSの起動を伴う上、HWエミュレートのオーバーヘッド有りホストOSから見るとアプリケーションのプロセス起動のみ HWエミュレートによるオーバーヘッドはほぼ無いゲストイメージサイズ仮想マシンにゲストOSを含むためマシンイメージが大きく、ストレージの容量が大きい (数十GB～) ゲストOSのイメージを所持する必要がなく、ストレージの容量が小さい (数MB～) OSの種類複数のゲストOSを選択可能 (Linux,Windows,その他) ホストOSに依存、異なるOSのシステムは動かせないホストOS ハイパーバイザー Bin/Lib アプリA Bin/Lib ゲストOS ゲストOS H/W アプリB アプリC ハイパーバイザー型軽量高速コンテナ型 H/W ホストOS Bin/Lib アプリA Bin/Lib アプリB Bin/Lib アプリC Bin/Lib アプリD コンテナ管理基盤仮想化実現方式の違いハイパーバイザー型 vs コンテナ型 14

| Dockerがもたらしたもの • 優れた開発者エクスペリエンス – 手軽に使いたいソフトウェアのコンテナを入手して、どんな環境でもすぐに動かすことができる • Immutable Infrastructure – 可搬性、再利用性：アプリケーションの実行環境をコンテナとしてパッケージ化 – 同等の環境を、簡単に構築することができる手作業でのテストコンテナレジストリ自動受け入れテスト自動キャパシティテストリリースコミットステージソースコードリポジトリコンテナとして実行環境をパッケージし、各環境で使い回すコミット

| • ローカル開発環境 – アプリケーション開発者のローカル開発環境で、開発に必要なソフトウェアを立ち上げる – e.g. • アプリケーションが参照するテストデータ入りのDB • テスト環境 – 複数のテスト環境を、短期間で自動構築 – テストフェーズ毎に同等の環境を作ることでテストの品質を向上を向上 • CI/CDツール – アプリケーションのビルド等で必要なライブラリを、コンテナにパッケージングしておき、その環境内でビルド – 確実に同一環境内でアプリケーションが作成されることを保証する Dockerの主なユースケース軽量・高速な仮想マシン + それを作成・配布するエコシステム

| Kubernetes コンテナ・オーケストレーター 17

| コンテナの運用で明らかになった課題 18 様々な運用・管理のオペレーションを大量のコンテナに対して行う必要がある障害対応ネットワーク監視サービスディスカバリスケーリングアップデートデータ永続化

| コンテナ・オーケストレーター • 複数コンテナのデプロイ、スケーリング等を自動管理するプラットフォーム •Kubernetes がデファクトスタンダード大量のコンテナを管理・運用にコンテナ・オーケストレーターの利用が有効 ✓ スケジューリング分散配置 ✓ 手動／自動でスケーリング ✓ 複数コンテナをまとめて制御 ✓ 障害時のコンテナ自動復旧 ✓ ネットワークアクセスの管理 ✓ コンテナの監視 etc… 19

| • デプロイの管理 – 適切なコンテナの配置 • 自動復旧 – コンテナの障害時にはコンテナの数を一定に保つ 20 • スケーリング – コンテナの数を手動、または自動で増やす・減らす Kubernetesが行うことの例 >_ >_ replicas: 3

| 主要コンテナ・オーケストレーターの人気度 • 2017の1年間でKubernetesが大きく躍進した一方、他のオーケストレーターに伸びがなかった 2017年にKubernetesが他のオーケストレーターを大きく引き離した Googleトレンドでの主要コンテナ・オーケストレーターの人気度 2017 21

| Kubernetesは他のオーケストレーターと何が違うのか • 様々なOSSと組み合わせることにより、柔軟に機能拡張可能 ① 柔軟に機能拡張することが可能。様々な用途に適用できる • コンテナ運用をさらに効率化・高度化 – 詳細なメトリック監視と可視化: • Prometheus + Grafana – コンテナのログの転送収集: • Fluentd / Fluent Bit – ネットワークトラフィックの制御: • Istio + Envoy • Kubernetesの適用領域の拡大 – 機械学習プラットフォーム: • Kubeflow – 分散ストレージ • Rook – 分散型データベース • Vitess • CNCFのバックアップにより多数OSSプロジェクトが活発に活動するようになり、 Kubernetesを中心にしたOSSのエコシステムが成立 22

| Kubernetesは他のオーケストレーターと何が違うのか • Kubernetesクラスタの構築方法に様々な選択肢がある • 要件に応じた最適な環境を手に入れることができる ② Kubernetesの利用を始める上で幅広い選択肢がある自由なカスタマイズ、エッジな要件への対応構築・運用管理の省力化フルスクラッチインストール Kubernetes構築ツールを利用したインストールマネージドKubernetesサービス・Oracle Container Engine for Kubernetes ・Google Kubernetes Engine ・Azure Kubernetes Service ・Amazon Elastic Container Service for Kubernetes ・Kubeadm ・Rancher ・Terraformインストーラ for OCI ・Kubespray ・Kops 23

| Kubernetesの宣言的なオペレーション • Kubernetesクラスタ上で動作させるリソースをマニフェストで定義 • マニフェストはYAML（Yet Another Markup Language）形式で記述する ✓ 利便性：シンプルな記述方式 ✓ メンテナンス： YAMLファイルをソース管理することで変更を追跡可能 ✓ 柔軟性：コマンドラインより複雑な構造を作成可能 24 マニフェストで「あるべきリソースの状態」を宣言 apiVersion: v1 kind: Pod metadata: name: sample-pod spec: containers: - name: nginx-container image: nginx:1.15 1 2 3 4 5 6 7 8 9 10 Kubernetesクラスタ上にはマニフェストの定義に従いオブジェクトが生成される

| Kubernetes利用環境の全体像 • 大きく分けて、Kubernetesクラスタ、kubectl、コンテナレジストリで構成 Kubernetesクラスタ >_ kubectl（コマンドラインツール）ノードとネットワークコンテナレジストリ 25

| Kubernetesの主要なリソース • Pod – 複数のコンテナを束ね管理する • ReplicaSet – Pod数（レプリカ数）を維持、管理する • Deployment – Rolling UpdateのためにReplicaSetを管理する • Service – Podに対するクラスタ内外のアクセスルーティングを制御する ReplicaSet Deployment Service Pod コンテナ User 26

| Kubernetesの操作 • Kubernetesの操作は kubectl コマンドラインツールを使用 • kubectlはAPI Server（後述）が提供するREST APIの操作を行う 27 ReplicaSet Deployment Service Pod コンテナ >_ Kubectl （コマンドラインツール） etcd API Server Admin マニフェストの定義（あるべき状態）が保存される

| Kubernetesの主要なリソース 28

| 再掲：Kubernetesの主要なリソース • Pod – 複数のコンテナを束ね管理する • ReplicaSet – Pod数（レプリカ数）を維持、管理する • Deployment – Rolling UpdateのためにReplicaSetを管理する • Service – Podに対するクラスタ内外のアクセスルーティングを制御する ReplicaSet Deployment Service Pod コンテナ User 29

| Pod • コンテナの生成/破棄等の最小単位 – 1つのPodに複数のコンテナを定義できる（例：サイドカー・パターン） – 定義された複数のコンテナは必ず同一のノードにデプロイされる – Pod内の複数のコンテナはクラスタ内のネットワークで通用するIPが 1つのPodに1つ割り当てられる複数のコンテナを束ね管理する単位ノード2 ノード3 ノード1 Pod コンテナ Pod内のコンテナは共通のライフサイクルとなる apiVersion: v1 kind: Pod metadata: name: sample-pod spec: containers: - name: nginx-container image: nginx:1.15 1 2 3 4 5 6 7 8 30

| Podのデザインパターン • サイドカー・パターン – 1つのPodの中に主となるメインコンテナと、補助するサイドカーコンテナを配置する • Pod内のコンテナは同一のIPアドレスを共有するため、ローカルホストでアクセス可能 • Podにボリュームをアタッチすることでコンテナ間のデータ共有も可能 – 利用例：Webサーバーコンテナとログの転送用のコンテナ 31 Main Side Car Pod 127.0.0.1 Vol Write Read コンテナを分離するメリット ✓ 個々の処理に必要なリソースを柔軟に選択 ✓ 開発の分離 ✓ 組み合わせが柔軟 ✓ 再利用可能 ✓ 独立してUpgarade可能

| Podのヘルスチェック(コンテナの監視) • Liveness Probe：コンテナ（プロセス）が起動しているかどうか確認 – 失敗を検知した場合はPodを自動的に再起動 • Readiness Probe：アプリケーションのリクエストを受け入れられるか確認 – 例えばロードや重いリクエストの処理中で別のリクエストが返せない場合を想定 – 失敗を検知した場合はルーティングの対象から外されて、成功するまで該当のPod にリクエストが来なくなる 32 ヘルスチェックの方法成功の判断任意のコマンドを実行ステータスコード0で成功特定のポート/パスにHTTPリクエストを行う HTTPステータスコードが200以上400未満で成功特定のポートにTCPチェックを行うポートがオープンしていたら成功決まった間隔でヘルスチェックを行う

| ReplicaSet • 指定したPod数を維持するリソース – ReplicaSetに管理されているPodの特定にはラベル（後述）を用いる Pod数（レプリカ数）を維持、管理する ReplicaSet apiVersion: apps/v1 kind: ReplicaSet metadata: app: nginx ## ラベル spec: replicas: 3 ## Pod数 template: ## Pod テンプレート metadata: labels: app: nginx ## ラベル spec: containers: - name: nginx-container image: nginx:1.15 ports: - コンテナPort: 80 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 spec.replicas: 3 PodはReplicaSetの定義内の Pod テンプレートをもとに作成される Pod テンプレート app:nginx Podが死んだ場合でも個数が3になるように管理する app:nginx app:nginx app:nginx Label 33

| Label/Label Selector • リソースにラベルをつけ、識別、グループ分けをし管理する仕組み • Label – リソースに定義する Key-Valueのペアセット – 任意のラベルを定義可能 • Label Selector – Labelの値からリソース検索やフィルタリング可能 – リソース同士の関連付け 34 app:nginx app:nginx app:nginx env:stage env:prod env:dev

| Deployment • RollingUpdateするためにReplicaSetを管理するリソース – アプリケーションの更新を行う場合新しいコンテナイメージをPodテンプレートに指定するだけでRollingUpdate可能 apiVersion: apps/v1 kind: Deploymet metadata: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx-container image: nginx:1.16 ##コンテナバージョン指定 ports: - コンテナPort: 80 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ReplicaSet spec.replicas: 3 Deployment ReplicaSet spec.replicas: 3 nginx:1.15 nginx:1.15 nginx:1.15 nginx:1.16 nginx:1.16 nginx:1.16 旧ReplicaSetのPodは順次削除される新しいReplicaSetが作られ Podも順次作成されるアプリを更新 35

| Service ClusterIP – クラスタ内からのリクエストのみを受け入れる方式ロードバランサ Loadbalancer – 専用のロードバランサをプロビジョニングし、クラスタ外からのリクエストを受け入れる方式 36 • Podに対するクラスタ内外からのリクエストをルーティング • 複数のタイプから用途によって選択インフラが対応している必要がある

| 追加で抑えておきたいリソース • ConfigMap – コンテナの設定情報をkey-valueの形式で保持するリソース • Secret – 機密情報を保持するリソース • Namespace – クラスターを区画に分けて管理するための論理領域 37 ReplicaSet Deployment Service User Namepsace Secret/ConfigMap

| ConfigMap • コンテナに設定情報を渡すために使うリソース • ConfingMapに記述した設定情報を、2通りの方法で渡すことができる – コンテナの環境変数として渡す – 設定情報が記述されたファイルをコンテナにマウントさせたように見せる 38 apiVersion: v1 kind: ConfigMap metadata: name: mycnf namespace: mysql data: my.cnf: | [mysqld] log_error=/var/lib/mysql/error_test.log default_authentication_plugin=mysql_native_password [mysql] prompt="innodb>" 1 2 3 4 5 6 7 8 9 10 11 12 Vol Config Map Key/Value形式で記述・Manifestから作成・ファイルを指定して作成 (--from-file) Manifestの例

| Secret • 機密度の高いデータを保持する際に使うリソース • ConfigMapと違い、コンテナでSecretのデータを読み取ると必ずメモリ内のみに保持されて不要になったら削除される(tmpfsが使用されている) • 値はBASE64エンコードしてクラスターに格納する 39 Manifestの例 apiVersion: v1 kind: Secret metadata: name: mysql-root-user-secret namespace: mysql data: password: XXXXXXX 1 2 3 4 5 6 7 Vol Secret Key/Value形式で記述・Manifestから作成・kubectlから直接作成・ファイルから作成・envfileから作成

| Namespace • クラスターを区画に分けて管理するための論理領域 • 使い方 – 商用、検証、開発環境で1つのクラスタの中で分ける – 開発チーム単位で分ける – あるプロダクト単位で分ける 40 Namepsace: hhiroshell Namepsace: cotoc

| Kubernetesを実現するプロセス群 41

| Kubernetes利用環境の全体像 • 大きく分けて、Kubernetesクラスタ、kubectl、コンテナレジストリで構成 Kubernetesクラスタ >_ kubectl（コマンドラインツール）ノードとネットワークコンテナレジストリ 42

| Kubernetesクラスタを実現するプロセス群 >_ kubectl API Server Scheduler kubelet コンテナ runtime Controller Manager ※主要なプロセスを記載 kube-proxy Masterノード Workerノード etcd Kubernetesクラスタ 43

| Kubernetesクラスタを実現するプロセス群 >_ kubectl API Server Scheduler kubelet コンテナ runtime Controller Manager ※主要なプロセスを記載 kube-proxy 44

| Masterノードのコンポーネント • API Server – Kubernetesの操作、コンポーネントがやり取りするための受け口 etcdを参照、更新、削除等を行うAPIサーバ • Controller Manager – 各リソースのコントローラーを起動制御するマネージャー – コントローラーがクラスタ上のリソースが定義された状態を保つように動作 • Scheduler – Podをどのノードに割り当てるかを決定する • etcd – Kubernetesクラスタの構成情報を保持する分散KVS 45

| API Server と etcd • API Server – API Server以外のコンポーネントは直接etcdを参照せず、APIサーバーを通してリソースにアクセスする – kubectlコマンドも、APIサーバーへのアクセスを通して操作を行う – リソース情報のCRUD(Create/Read/Update/Delete)処理を行う – 認証、認可、アクセス制御の仕組みを提供 • etcd – リソースの構成情報はすべてetcdに保存される – 高信頼分散KVS 46 Kubernetesの操作、コンポーネントがやり取りするための受け口 >_ kubectl API Server Scheduler kubelet Controller Manager kube- proxy

| Controller Manager 47 ControllerはReconciliation Loop（突き合わせループ）により宣言した状態を維持する • Controller Managerは各リソースのコントローラーを起動し管理するマネージャー • Controllerはマニフェストにより定義された状態を保つように動作するコンポーネント – Deployment, ReplicaSetなどリソース毎に専用のControllerが存在 Observe Analyze Act オブジェクトの現在の状態を確認するオブジェクトの現在の状態と期待する状態を比較する状態を一致させるために必要な処理を行う

| Scheduler • 新しく作られたPod（NodeNameの指定がないPod）をどのWorkerノードで動作させるか、ノードのリソース使用状況（CPU、メモリ）やラベルから判断 48 新しく作られたPodのノードへの割り当てを行うスケジューラー NEW Pod Scheduler NodeName: ノード2 ノード1 ノード2 ノード3 kubelet/docker NEW‼ NodeName:＿ kubelet/docker kubelet/docker

| Kubernetesクラスタを実現するプロセス群 >_ kubectl API Server Scheduler kubelet Container runtime Controller Manager ※主要なプロセスを記載 kube-proxy 49

| Workerノードのコンポーネント • Container runtime – コンテナのランタイム Docker など • kubelet – Workerノード上に配置されるエージェント – Podの起動停止やPodの状態をAPI Serverに送り、更新する役割を持つ • kube-proxy – コンテナとの接続を保証するためにノードのNWを管理する – Serviceの設定を元にPodへのアクセスをルーティングする 50

| kubelet • 各ノードで動作するエージェントで、Podの起動・管理を行う – APIサーバーと通信して、自分のノード上で実行されるべきPodを発見 – Podの起動停止 – マシン上で実行されるコンテナのヘルスチェックと異常時には再起動を担当 – コンテナの状態をAPI Serverに送る 51 kubelet Container runtime Workerノード

| kube-proxy • コンテナとの接続を保証するためにノードのNWを管理する • Serviceの設定を元にPodへのアクセスをルーティングする 52 API Server kube-proxy kube-proxy

| Kubernetesクラスタを実現するプロセス群 >_ kubectl API Server Scheduler kubelet コンテナ runtime Controller Manager ※主要なプロセスを記載 kube-proxy 53

| Podを作るまでの流れ 54 参考：Heptio.com Create Pod Flow https://blog.heptio.com/core-kubernetes-jazz-improv-over-orchestration-a7903ea92ca

| マネージドKubernetesを利用する場合このパートで書いたことの殆どは意識しなくてよい…！ >_ kubectl API Server Scheduler kubelet コンテナ runtime Controller Manager ※主要なプロセスを記載 kube-proxy Managed Service Kubernetes 55

| OKEでKubernetesクラスタを作る Demo① 56

| Oracle Container Engine for Kubernetes • カスタマイズなしのピュアなKubernetes実装 • Certified Kubernetes Program適合[^1] • GUI / コマンドラインツールによるクラスタのプロビジョニング、アップグレード • OCIのストレージ、ロードバランサーとの統合[^2] マネージドKubernetesサービス [^1]: Kubernetesクラスタの動作の一貫性とアプリの可搬性を保証する目的で、CNCF が策定した認定プログラム [^2]: StorageClass と ServiceのLoadBalancerタイプが使用可能 i 57

| Oracleが提供するKubernetesのアーキテクチャ • ハイパフォーマンスな次世代IaaS上にKubernetesクラスタを構築 • Availability Domainを横断してクラスタを構成し、高可用性を実現 OracleのIaaSの能力を生かすKubernetesクラスタ構成 Kubernetes クラスタ Availability Domain 1 Availability Domain 2 Availability Domain 3 58

| エンタープライズグレードのパフォーマンス • ミッションクリティカルなクラスタを運用するのに最適な基盤 – 高速SSDを搭載したベアメタル（非仮想）サーバー – 3つのAvailability Domains (AD) でリージョンを構成。AD間、AD内のホスト間を、低レイテンシー、広帯域のN/Wで接続高性能次世代IaaSがもたらすハイパフォーマンス 59 https://www.accenture.com/t20171003T083750Z__w__/us- en/_acnmedia/PDF-62/Accenture-Enterprise-Workloads-Meet-Cloud.pdf OCI Other AD1 AD2 AD3 AD間: 1Tb/s, < 500µs AD内: 25Gb/s, < 100µs 第3者機関によるN/W性能検証結果

| 【参考】パフォーマンスに適用されるSLA Availability, Management, and Performance SLAs – Includes FastConnect availability SLA – Includes compute, storage, database management SLAs – Includes local storage, network block storage, and network performance SLAs パフォーマンスを含む広範なSLAを、他社に先駆けて提供 60

| アプリを動かしてみよう Demo② 61

| • Kubernetes完全ガイド (impress top gear) – 青山真也さん • Kubernetes実践ガイドクラウドネイティブアプリケーションを支える技術 (impress top gear) – 北山晋吾さん、早川博さん • cndjp: 一晩でKubernetesを覚えて帰ろう。ワンナイトBootCamp! -- cndjp#10 – yosshi_さん • Cloud Native関連コミュニティの皆様 • ブロガーの皆様 62 Special Thank!!

OCHaCafe これからはじめる！Kubernetes基礎

OCHaCafe これからはじめる！Kubernetes基礎

More Decks by cotoc

Other Decks in Technology

Featured

Transcript