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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | ハイパーバイザー型コンテナ型仮想化の実現方式仮想マシン(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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 主要コンテナ・オーケストレーターの人気度 • 2017の1年間でKubernetesが大きく躍進した一方、他のオーケストレーターに伸びがなかった 2017年にKubernetesが他のオーケストレーターを大きく引き離した Googleトレンドでの主要コンテナ・オーケストレーターの人気度 2017 21

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 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

Slide 24

Slide 24 text

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 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クラスタ上にはマニフェストの定義に従いオブジェクトが生成される

Slide 25

Slide 25 text

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 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の例

Slide 39

Slide 39 text

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 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から作成

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | Kubernetesクラスタを実現するプロセス群 >_ kubectl API Server Scheduler kubelet コンテナ runtime Controller Manager ※主要なプロセスを記載 kube-proxy Masterノード Workerノード etcd Kubernetesクラスタ 43

Slide 44

Slide 44 text

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | エンタープライズグレードのパフォーマンス • ミッションクリティカルなクラスタを運用するのに最適な基盤 – 高速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性能検証結果

Slide 60

Slide 60 text

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 【参考】パフォーマンスに適用される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

Slide 61

Slide 61 text

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

No content