コンテナアプリケーション開発のことはじめ～ Docker & Kubernetes ～

コンテナアプリケーション開発のことはじめ～ Docker & Kubernetes ～ Yutaka Ichikawa Oracle
Corporation Japan Principal Cloud Solution Engineer Jul28, 2023

Copyright © 2023, Oracle and/or its affiliates 2 Profile Name
• Yutaka Ichikawa/市川豊 Belong • Solutions Architect Role • Principal Cloud Solution Engineer SNS • Twitter/GitHub/Qiita:cyberblack28 Blog • https://cyberblack28.hatenablog.com/ Materials • https://speakerdeck.com/cyberblack28/ Community • Oracle Cloud Hangout Cafe #ochacafe • CloudNative Days Tokyo #cndt #o11y2022 Certified • Certified Kubernetes Administrator • Certified Kubernetes Application Developer • Certified Kubernetes Security Specialist • Kubernetes and Cloud Native Associate Publications

Copyright © 2023, Oracle and/or its affiliates 3 • 第1章
コンテナの世界に飛び込む前に • 第2章コンテナアプリケーション開発に必要なソフトウェア • 第3章コンテナアプリケーション開発のライフサイクル Build・ Ship・Run • 第4章コンテナオーケストレーション • 第5章 Kubernetes でコンテナアプリケーションを動かすまで • 第6章ローカル開発の準備 • 第7章コンテナアプリケーションにおける CI/CD 解説動画（https://onl.sc/XJm16m8）解説資料（https://onl.sc/hjuqfdU）

Copyright © 2023, Oracle and/or its affiliates 4 ThinkIT +
Oracle Cloud Hangout Café Oracle Cloud Hangout Café ダイジェスト • 第1回「CI/CD最新事情」 2023年1月 • 第2回「マイクロサービスの認証・認可とJWT」 2023年2月 • 第3回「Kubernetes Operator 超入門」 2023年3月 • 第4回「Kubernetes のセキュリティ」 2023年4月 • 第5回「実験！カオスエンジニアリング」 2023年5月 • 第6回「Service Mesh がっつり入門！」 2023年6月 https://thinkit.co.jp/article/20858

Copyright © 2023, Oracle and/or its affiliates 5 1. コンテナとコンテナオーケストレーション
• これまでのアプリケーション開発 • OS/ライブラリとアプリケーションの分離 • 仮想マシンとコンテナの違い • OS/ライブラリとアプリケーションの統合 • Docker 実践～ Build ～ • Docker 実践～ Ship ～ • Docker 実践～ Run ～ • Docker 実践～ Build/Ship/Run ～ • コンテナライフサイクル • コンテナを支えるオーケストレーション Agenda 2. Kubernetes コンポーネント • Control Plane & Node • Pod • ReplicaSet & Deployment • Service • Ingress • PersistentVolume & PersistentVolumeClaim • ConfigMap & Secret • Namespace & Label 3. Kubernetes クラスタ構築&アプリケーションデプロイ • WordPressを動かしてみる • OCI Container Service 紹介

Copyright © 2023, Oracle and/or its affiliates 7 コンテナ技術とコンテナ・オーケストレーションこれまでのアプリケーション開発
物理マシン仮想マシン仮想マシン（クラウド）コンテナ物理サーバでアプリケーションを稼働 VM 物理サーバ上に複数の仮想マシンでアプリケーションを稼働クラウドをベースとしたスケーラブルな仮想マシンでアプリケーションを稼働物理マシン・仮想マシンもノードとして束ねて、コンテナという小さい単位でアプリケーションを稼働

Copyright © 2023, Oracle and/or its affiliates 8 コンテナ技術とコンテナ・オーケストレーションこれまでのアプリケーション開発
アプリケーションコードをソースコードリポジトリにコミット/プッシュ CI/CDパイプラインによるテスト、ビルド、デプロイ Developer Code Repository CI/CD Pipeline すべて自動化されている場合もあれば、手動で行う場合もあります。本番環境ステージング環境検証環境 Operator Infrastructure Engineer 開発環境 OS/ライブラリ VM 物理マシン仮想マシン仮想マシン（クラウド）

Copyright © 2023, Oracle and/or its affiliates 9 コンテナ技術とコンテナ・オーケストレーション OS/ライブラリとアプリケーションの分離
アプリケーション本番環境ステージング環境検証環境開発環境 OS/ライブラリ VM 物理マシン仮想マシン仮想マシン（クラウド）アプリケーションは物理マシンや仮想マシンのOS/ライブラリ上で稼働稼働するアプリケーションは実行環境に依存する環境差異が原因で他の環境で稼働するけど、本番環境で稼働しない等の障害が発生する OSのパッチバージョンが異なる、このライブラリが無かった、関係ないものがインストールされている…

アプリケーション OS/ライブラリ • 仮想マシンイメージがベンダー製品特有（ベンダーロックイン） • 容量も重い（数ギガ～数十ギガ） • 可搬性（Portability）が低い Xen Server 仮想マシンイメージ KVM VMWare ハイパーバイザーハードウェア VMWare Xen/Server KVM 物理/仮想マシンにおける、OS/ライブラリのアップデートには人手や時間を要するため、アプリケーションのリリースに影響する… 仮想マシン

これまでのアプリケーション開発 OS/ライブラリが既に整っている実行環境にアプリケーションをデプロイするという形式 1.アプリケーション • 環境差異による問題が発生 • OS/ライブラリ側に何かあるとアプリケーションに影響 2.インフラ • 仮想マシンイメージがベンダー製品特有（ベンダーロックイン） • 仮想マシンイメージの容量が重く可搬性（Portability）が低い • 物理/仮想マシンの特性上、OS/ライブラリのアップデートに時間を要して、アプリケーションのリリースに影響する

Copyright © 2023, Oracle and/or its affiliates 12 コンテナ技術とコンテナ・オーケストレーション仮想マシンとコンテナの違い
ハードウェアハイパーバイザー OS/Hyper Visor OS/Hyper Visor カーネルカーネルアプリケーションアプリケーションライブラリライブラリ仮想マシン仮想マシンハードウェアカーネル OS/Hyper Visor OS/Hyper Visor コンテナコンテナコンテナエンジン各仮想マシンのカーネル上で実行、隔離性が高いが、起動が遅く（数分）オーバヘッドが大きいカーネルを共有しているため、隔離性は低いが、起動が高速（数秒）でオーバヘッドが小さい仮想マシンコンテナアプリケーションアプリケーションライブラリライブラリ

Copyright © 2023, Oracle and/or its affiliates 13 コンテナ技術とコンテナ・オーケストレーション OS/ライブラリとアプリケーションの統合
OS/ライブラリアプリケーションコンテナイメージビルド（Build） OS/ライブラリ • OS/ライブラリとアプリケーションをパッケージイメージ化 • 技術としてはOSSのため、ベンダーロックインを回避 • イメージはこれまでの仮想マシンイメージに比べるとはるかに軽いのでポータビリティ性が高い 1.ビルド（Build）

• イメージをレジストリに保存して、共有 2.シップ（Ship） OS/ライブラリ OS/ライブラリ OS/ライブラリイメージレジストリ Push Pull シップ（Ship）イメージの共有 OS/ライブラリコンテナプラットフォーム

• コンテナイメージを基にコンテナを起動 3.ラン（Run）コンテナプラットフォーム上でイメージからコンテナを起動して、アプリケーションを稼働。イメージもプラットフォームも特定ベンダー技術に依存しないため、仮想マシンイメージと違って、ベンダーロックインも回避。 OS/ライブラリラン（Run） OS/ライブラリコンテナプラットフォームコンテナコンテナイメージ

コンテナアプリケーション開発 OS/ライブラリとアプリケーションを統合して、軽量イメージ化して、コンテナプラットフォームにコンテナとしてデプロイする形式 1.アプリケーション • OS/ライブラリとアプリケーションが一つに統合されているため、環境差異による問題が起きにくい 2.インフラ • 仮想マシンイメージと仕組みが異なり、OSSベースでベンダーロックインも回避、軽量で可搬性（Portability）が高い • OS/ライブラリのアップデートも容易なため、リリースサイクルを速め、スピード（Agility）が向上

Copyright © 2023, Oracle and/or its affiliates 17 コンテナ技術とコンテナ・オーケストレーション Docker
実践～ Build ～「 $ docker image build 」コマンドを実行して Dockerfile からコンテナイメージを作成 Container Image コンテナイメージ FROM centos:7 RUN yum -y install epel-release RUN yum -y install nginx COPY index.html /usr/share/nginx/html ENTRYPOINT ["/usr/sbin/nginx", "-g", "daemon off;"] Dockerfile $ docker image build Build

Copyright © 2023, Oracle and/or its affiliates 18 コンテナ技術とコンテナ・オーケストレーションコンテナイメージの構造
Container Image 読み込み専用（ReadOnly）ベースイメージ CentOS イメージ層 FROM centos:7 RUN yum -y install epel-release RUN yum -y install nginx COPY index.html /usr/share/nginx/html ENTRYPOINT ["/usr/sbin/nginx", "-g", "daemon off;“] Dockerfile ① ② ③ ④ ⑤ ⑤ ④ ③ ② ① コンテナ起動時の構造ベースイメージ CentOS イメージ層書き込み可能イメージ層読み込み専用（ReadOnly）「 $ docker container run 」コマンドでコンテナが起動すると、自動的に書き込み可能なレイヤーが作られる仕組み ⑤ ④ ③ ② ① 書き込み可能なイメージ層は「 $ docker container commit 」コマンドで保存されて、その層が読込専用となります。左例でいうと⑥の層ができることになります。 6

実践～ Build ～ # docker image build -t cyberblack/test-nginx . Sending build context to Docker daemon 25.09kB Step 1/5 : FROM centos:7 7: Pulling from library/centos ab5ef0e58194: Pull complete Digest: sha256:4a701376d03f6b39b8c2a8f4a8e499441b0d567f9ab9d58e4991de4472fb813c Status: Downloaded newer image for centos:7 ---> 5e35e350aded Step 2/5 : RUN yum -y install epel-release ---> Running in 83d64f46ae64 ・・省略（yumの処理）・ Complete! Removing intermediate container 83d64f46ae64 ---> 827e069c2cf4 Step 3/5 : RUN yum -y install nginx ---> Running in 5a61a4cfa4c1 ・・省略（yumの処理）・ Complete! Removing intermediate container 5a61a4cfa4c1 ---> 8e94cdfc1d95 Step 4/5 : COPY index.html /usr/share/nginx/html ---> f78c1d4c9694 Step 5/5 : ENTRYPOINT [“nginx”, “-g” “daemon off;”] ---> Running in 115085b978f4 Removing intermediate container 115085b978f4 ---> aa214ab9d4f0 Successfully built aa214ab9d4f0 Successfully tagged cyberblack/test-nginx:latest FROM centos:7 RUN yum -y install epel-release RUN yum -y install nginx COPY index.html /usr/share/nginx/html ENTRYPOINT [“/usr/sbin/nginx”, “-g”, “daemon off;“] ① ② ③ ④ ⑤ Dockerfile コンテナイメージ # docker image build -t cyberblack/test-nginx . Build ※ cyberblack の箇所は DockerHub アカウント名 cyberblack/test-nginx ① ② ③ ⑤ ④

実践～ Ship ～ビルドしたイメージを「 $ docker image push 」してアップロード、イメージレジストリからイメージを「 $ docker image pull 」してダウンロードできます。また、イメージレジストリ及びリポジトリはパブリック/プライベートがあるので環境に合わせて利用できます。コンテナエンジン（dockerd）ハードウェア pull コンテナイメージレジストリ CentOS リポジトリ Ubuntu リポジトリ Container Image push tag:latest tag:6.7 ・・ tag:latest tag:14.04 ・・ Ship Nginx リポジトリ tag:latest tag:19.1 ・・カーネル run build Container Image Container Image $ docker image pull $ docker image push Dockerfile

実践～ Ship ～ # docker login Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one. Username: cyberblack Password: WARNING! Your password will be stored unencrypted in /root/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store Login Succeeded Hub Docker Hub にログイン

実践～ Ship ～ # docker image push cyberblack/test-nginx The push refers to repository [docker.io/cyberblack/test-nginx] 39e4809cbd03: Pushed 66061884888d: Pushed 5a338cc84c53: Pushed 77b174a6a187: Mounted from library/centos latest: digest: sha256:8287e7100ce2ddf7cd76202ab25ccbfd287b223242231cd83005ed0cda1e9c f6 size: 1160 Docker Hub に Push Container Image cyberblack/test-nginx # docker pull cyberblack/test-nginxUsing default tag: latest latest: Pulling from cyberblack/test-nginx ab5ef0e58194: Already exists 1379c469e275: Pull complete dbb831d3fcac: Pull complete a6bb76d398b0: Pull complete Digest: sha256:8287e7100ce2ddf7cd76202ab25ccbfd287b223242231cd83005ed0cda1e9cf6 Status: Downloaded newer image for cyberblack/test-nginx:latest docker.io/cyberblack/test-nginx:latest Docker Hub から Pull Hub cyberblack/test-nginx Push Pull Ship # docker image push cyberblack/test-nginx # docker image pull cyberblack/test-nginx Container Image $ docker image push $ docker image pull

実践～ Run ～ローカルでbuildしたコンテナイメージやコンテナレジストリからpullしたコンテナイメージを基に「 $ docker container run 」コマンドを実行して、コンテナを起動します。コンテナエンジン（dockerd）ハードウェア pull コンテナイメージレジストリ CentOS リポジトリ Ubuntu リポジトリ Container Image push tag:latest tag:6.7 ・・ tag:latest tag:14.04 ・・ Nginx リポジトリ tag:latest tag:19.1 ・・カーネル run build Container Image Container Image $ docker container run Dockerfile Run

実践～ Run ～ # docker container run --name sample-nginx -d -p 8080:80 cyberblack/test-nginx a8506ee968e6d5ae664ba4046fe15b518127f6c826247fcaac2f3c1cd24e4cef コンテナを起動と同時に Docker イメージを展開 # docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a8506ee968e6 cyberblack/test-nginx "nginx -g 'daemon of…" 13 seconds ago Up 12 seconds 0.0.0.0:8080->80/tcp sample-nginx コンテナ稼働を確認 # curl http://localhost:8080 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> </head> <body> <h1>Hello,Docker & Kubernetes</h1> </body> </html> コンテナ（Nginx）にアクセス sample-nginx port:80 localhost port:8080 localhost ポート8080経由でコンテナーの80ポートへ curl でアクセス # curl http://localhost:8080 Run

実践～ Build/Ship/Run ～ Build Ship Run イメージレジストリ Dockerfile コンテナイメージアプリケーションフレームワークアプリケーションライブラリ OS イメージ ① コンテナイメージ自動作成 ③ イメージを基にコンテナを起動イメージの作成手順を記載 $ docker image pull $ docker image push $ docker image build $ docker container run コンテナ ② Docker イメージの保存・共有

Copyright © 2023, Oracle and/or its affiliates 26 コンテナ技術とコンテナ・オーケストレーションコンテナを支えるオーケストレーション
単体のコンテナでは、コンテナ自体が落ちたり、コンテナ環境を支えるホストなどのハードウェアや仮想マシンに障害が発生して稼働が停止した場合などの対処が無く、システム自体利用不可。この状態でのプロダクション利用は厳しい。コンテナの停止、ホストが停止した場合でも自動修復して、サービス無停止による継続。アプリケーションをサービス無停止の状態でデプロイ可能な DevOps 環境を構築する上でコンテナーオーケストレーションは必須。 OKE Compute OCIR コンテナイメージ Kubernetes

Kubernetes は、Google 社内のコンテナーオーケストレーションシステムである Borg からインスパイアされて開発された OSS のコンテナーオーケストレーション。読み方：クーバーネーティス、クーバネティス、クバネティス等略称：K8s（Kubernetes） 8文字現在は、CNCF (Cloud Native Computing Foundation) で管理され、多数の企業が参加するコミュニティで開発。

Kubernetesの主な役割と実現 • コンテナのスケジューリング • ローリングアップデート • オートスケーリング • 死活監視 • 頻繁なアプリケーションのデプロイを可能にするシステム基盤 • 無停止によるリリース、高可用なシステム基盤 • 負荷に応じた伸縮自在なシステム基盤主な役割実現 • コンテナの自動修復 • サービスディスカバリ • ロードバランシング

マニフェストファイル YAML Controllerがあるべき理想の状態へ収束 Controller 内の Reconciliation loop（調整ループ）と呼ばれる、あるべき理想の状態へ収束させるループ処理を実行。 Kubernetesクラスタ登録 Controller 監視コンテナ管理（作成・削除） Reconciliation loop 宣言的オペレーション

Kubernetesは分散処理基盤 Virtual Machine & BareMetal Kubernetes Container

Kubernetes is becoming the Linux of the cloud by Jim Zemlin （The Linux Foundation）

Multi-Cloud to Multi-Kubernetes Cloud Native to Kubernetes Native

Copyright © 2023, Oracle and/or its affiliates 34 Control Plane
& Node

Control Plane & Node Kubernetes には、構成要素として Control Plane と Worker Node というコンポーネントがある Control Plane クラスタの制御を受け持ち、スケジューリングやイベント検知など、クラスタの全体に関わる管理を担う。 Node アプリケーションコンテナの稼働場所となり、コンテナランタイムが稼働し、Control Plane と連携してコンテナの起動などの実行を担う。

Control Plane & Node

Control Plane コンポーネント概要 API server Kubernetes への API リクエストを REST で受け付けるフロントエンドサーバオブジェクトのCRUDやユーザおよびサービスアカウントの認証認可、リクエストの制御を行う Admission Control 機能がある Scheduler Pod を最適な Node に配置する Cloud controller manager クラウドプロバイダーの機能と連携して、ロードバランサやディスクボリュームなどのリソースを管理する Controller Manager Kubernetes クラスタのリソース状態を管理して、要求される各リソースの状態（あるべき姿）を維持する etcd Kubernetes クラスタに登録される全ての情報を保存するデータストア（KVS）

Node コンポーネント概要 kubelet Node への Pod のスケジューリングを監視して、Container Runtime を利用して Pod の生成、更新、破棄などを行う Container Runtime kubelet によるコンテナイメージの取得とコンテナの作成、更新、破棄などを実行。 Kubernetes は、コンテナランタイムの取替が可能なため、containerd 、cri-o 、gVisor など利用可能 kube-proxy 各 Node で動作する、Service オブジェクトが持つ仮想的な Cluster IP や NodePort 宛のトラフィックを Pod へ正常に転送するネットワークプロキシの役割を担う

Pod Container Container Node1 Node2 • 1つまたは複数のコンテナをデプロイする最小単位 • Pod 内のコンテナは同じホスト名と IP アドレスを持つ • Pod 内のコンテナは同じポート番号を持つことはできない • Pod 内のコンテナはローカルホスト通信 • Pod 内のコンテナは同じ Node 上で稼働、Node をまたぐことはできない

Pod ができるまでの仕組み 1.Podを作るマニフェストまたはコマンドを kubectl で実行すると、 API serverが受け付けて、etcd に格納。 2.Scheduler は API serverを経由して etcd を監視、更新されるとリソース（ここではPod）をどの Node に配置するか決める。 3. Scheduler が配置する Pod の nodename を更新、 kubelet も API server 経由で etcd を監視しているので、 nodename が合致する kubelet が ContainerRuntime を利用して Pod（コンテナ）を作成。 Pod （コンテナ）を作成したことを API serverに伝えると、 API server が etcd を更新。 Container Image Registry

Copyright © 2023, Oracle and/or its affiliates 42 ReplicaSet &
Deployment

ReplicaSet ReplicaSet は、 Pod のレプリカを作成して、マニフェストファイルで定義されたレプリカ数( replicas )を保証し、定義された数の Pod を常に起動させる仕組み。 Kubernetes Cluster ReplicaSet (Replica 数 = 5)

ReplicaSet ReplicaSet は、Node や Pod に障害が発生した場合、定義されたレプリカ数を保証するために、別ノードで復旧、 Kubernetes のセルフヒーリング機能。 ReplicaSet (Replica 数 = 5) Kubernetes Cluster

Deployment Deployment は ReplicaSet の作成、更新、履歴管理を行う。ローリングアップデート、ロールバックを可能にする。 1世代 2世代 3世代 4世代ローリングアップデートロールバック replicas:5 Image: nginx:1.15 replicas:5 Image: nginx:1.16 replicas:5 Image: nginx:1.17 replicas:5 Image: nginx:1.18

Deployment & ReplicaSet & Pod の関係管理管理上位リソース Pod Replicaset Deployment

セルフヒーリングの仕組み Container Image Registry マニフェストファイル（yaml） replicas:3 replicas:3 1.「kubectl create -f deployment.yaml」 kubectl コマンドでマニフェストファイル(あるべき姿の定義)を登録します。etcd に格納されます。 2. Controller Manager が API server を経由して etcd から Node の状況 ( Deployment と ReplicaSet の定義、あるべき姿 ) を常に監視して、差異が生じた場合に再作成を実行 3. kubelet は、再作成のアクションを確認して、コンテナを起動。 4. kubelet は Node の状況確認及び自分の Node の状況を API server に連絡、API server は、更新内容を etcd 書き込む。

Reconcile Loop Kubernetes は、マニフェストファイルの内容をあるべき理想の形（Desired State）とする。そして、常にその状態であるかを監視して、相違がある場合、 Reconcile Loop により自動修復。登録監視 Controller Reconcile Loop あるべき理想の形でない場合、修復を行う。コンテナの作成、削除クラスタの状態

Reconcile Loop Reconcile Loop とは、 Controller 内で実行されている理想とするあるべき姿に収束させるループ機能。 Observe Diff Act Act: Observe: Diff: 現状確認理想と現実の差分計算差分に対する処理

Reconcile Loop 例：3個の Nginx コンテナ（ Pod ）を起動することを理想とする理想の状態クラスタの状態

Reconcile Loop 2個のコンテナ（ Pod ）しか起動していない場合理想の状態クラスタの状態

Reconcile Loop 2個のコンテナ（ Pod ）しか起動していない場合 Diff: 1個のコンテナ（ Pod ）が足りない理想の状態クラスタの状態

Reconcile Loop 2個のコンテナ（ Pod ）しか起動していない場合 Act: 1個の nginx のコンテナ（ Pod ）を作成する理想の状態クラスタの状態

Service Service はクラスタ内外からのリクエストを Pod にアクセスする為のルーティングや DNS 機能を提供。主な機能として、 ClusterIP 、NodePort 、LoadBalancer がある。 Kubernetes Cluster Node #1 Node #2 Node #3

ClusterIP クラスタ内の Pod 同士が、内部 DNS で名前解決して通信するプライベート IP アドレス。 Kubernetes Cluster 内部 DNS 代表 IP アドレス（ClusterIP）クライアントリクエスト DNS 登録/削除名前解決 IP アドレス返答負荷分散

NodePort Node の IP アドレスに公開ポート番号を開放して、クラスタ外部からのアクセスを受け付ける。 Service は、kube-proxy と連携して、各ノードにポートを開き、ノード横断で Pod にリクエストを送信。 Kubernetes Cluster クラスタ外リクエスト Node #1 IP address:NodePort クラスタ外リクエスト Node #2 IP address:NodePort クラスタ外リクエスト Node #3 IP address:NodePort type: NodePort Node #1 Node #2 Node #3

LoadBalancer クラスタ外のロードバランサと連携して外部からのアクセスを受け付ける。各クラウドプロバイダーで対応。 type: LoadBalancer Node #1 Node #2 Node #3 Kubernetes Cluster 外部ロードバランサクラスタ外リクエスト外部IPアドレス

Ingress Ingress は外部からの HTTP(S) トラフィックを内部 Service にルーティングし、レイヤ7のロードバランシングを提供。パスベースルーティング、HTTPS終端、名前ベースのバーチャルホスティングも可能。外部 DNS VIP 外部公開用アドレス（外部LB）外部クライアント（ブラウザ） https://xxxx.sample.co.jp/foo 名前解決 Internet Kubernetes Cluster https://xxxx.sample.co.jp/bar path: /foo path: /bar

Copyright © 2023, Oracle and/or its affiliates 61 Volume &
PersistentVolume & PersistentVolumeClaim

Volume コンテナ側からマウント可能なボリューム領域。保存領域の実態をポイントする。 Volume は、あらかじめ用意された利用可能な Volume を Pod のマニフェストファイルから直接指定して利用。 Container Volume Container NIC ※例として Container を 2個としています。ローカルディスクなど IP アドレスコンテナ同士は、ローカルホスト通信 Kubernetes Cluster

PersistentVolume (PV) & PersistentVolumeClaim (PVC) PersistentVolume は、永続ボリュームと連携して、Kubernetes クラスタにボリュームを登録するリソース。 PersistentVolumeClaim は、PersistentVolume をアサインするリソース。 Pod から PersistentVolume を利用する場合、 Pod のマニフェストにPersistentVolumeClaim を定義して利用。 Container Container NIC ※例として Container を 2個としています。 IP アドレスコンテナ同士は、ローカルホスト通信ストレージプラグインを利用することで多種の外部ストレージを利用できます。 Kubernetes Cluster Volume Volume

PVC と PV の利用手順例ストレージ ① インフラエンジニアがストレージを準備 ② クラスタ管理者が PV を作成し、ストレージを Kubernetes クラスタに登録 ③ 開発者が PVC を作成し、Pod からマウントする場合の名称、利用する PV 条件を指定 ④ Kubernetes は PVC の条件に合致する PV があれば PVC と PV を紐づける ⑤ 開発者は、Pod 定義で PVC を指定して Pod を生成するインフラエンジニアクラスタ管理者開発者 ① ② ② ③ ④ ⑤ ② ③ ⑤ ② ③ ⑤ PersistentVolume マニフェストファイル PersistentVolumeClaim マニフェストファイル Pod / Deployment マニフェストファイル

Copyright © 2023, Oracle and/or its affiliates 65 ConfigMap &
Secret

ConfigMap ConfigMap は、環境変数、引数等の設定情報（Key-Value 保持）をコンテナに渡すために使用。Volume としてコンテナにマウントして、コンテナからはファイルとして認識される。 Kubernetes Cluster Container Volume Container NIC ※例として Container を 2個としています。 IP アドレスコンテナ同士は、ローカルホスト通信 httpd.conf, nginx.conf のような設定ファイルやパラメータだけでも可能です。格納可能なデータサイズは 1MB となります。 Key=Value

Secret Secret は、機密性の高いデータ（ ID/Password 情報、SSL/TLS 証明書、アクセストークン等）を保持する上で使用する Volume 。 Kubernetes Cluster tmpfs 領域 tmpfs 領域は、メモリ内に保持されるため、 Node のディスク書き込まれない。参照利用する Pod が存在する場合にのみデータを Node に送信。転送は over SSL/TLS となる。 etcd 内では、平文で保存されるため、etcd のアクセス権限やセキュリティの対応が必要。

Secret リソースの暗号化 Secret は、base64 でエンコードされているが、暗号化されていない。Git リポジトリに Secret の設定が定義されているマニフェストファイルをアップロードするのはセキュリティリスクがあるため、マニフェストファイルを暗号化するオープンソースソフトウェアを利用する。 • Kubesec https://kubesec.io/ • SealedSecret https://github.com/bitnami-labs/sealed-secrets • ExternalSecret https://github.com/godaddy/kubernetes-external-secrets

Copyright © 2023, Oracle and/or its affiliates 69 Label &
Namespace

Label & Label Selector Kubernetes 上のオブジェクトにタグのような属性を設定して、グループ化したり、特定のオブジェクトを抽出できるようにする仕組み。 • Label LabelはKey/Value ペアの文字列で、Pod などのオブジェクトに任意のメタ情報を付与して識別用途として利用。 • Label Selector Label 設定値の条件に該当するものをグループとして識別用途利用。

Namespace Namespace は、複数のユーザー間で（リソース割り当てを介して）クラスタリソースを分割する仕組みです。 • 1ユーザー毎に1個の Namespace • Namespace におけるリソースの名前は、Namespace 内で一意である必要がありますが、Namespace 間では一意である必要はありません • Namespace 毎にリソースの利用上限を設定可能

Copyright © 2023, Oracle and/or its affiliates 72 Kubernetes クラスタ構築
& アプリケーションデプロイ

& アプリケーションデプロイ Kubernetes クラスタ構築ツールを利用せずに、全てを1から構築する「 Kubernetes the hard way 」 https://github.com/kelseyhightower/kubernetes-the-hard-way

& アプリケーションデプロイ kubeadm https://kubernetes.io/docs/setup/independent/install-kubeadm/ Kubernetes クラスタを構築するオープンソースソフトウェア

76 Copyright © 2023, Oracle and/or its affiliates Virtual Machine
Virtual Machine k8s-control-plane k8s-node Item Spec Shape VM.Standard.A1.Flex CPU Ampere MEM (control plane) 12GB MEM (node/manage) 6GB OS Ubuntu 20.04 ContainerRuntime Containerd CNI Calico kubectl ssh Virtual Machine manage OCI Always-Free 環境で構築できます。 User Kubernetes クラスタ構築 & アプリケーションデプロイ kubeadm https://github.com/oracle-japan/ochacafe-s5-3

& アプリケーションデプロイ Kubernetes マネージドサービス Amazon Elastic Kubernetes Service Google Kubernetes Engine Azure Kubernetes Service Oracle Container Engine for Kubernetes

デモ環境で利用するソースなど https://bit.ly/ochacafe7-1

デモ環境概要図

OKE 構築クイック作成で Kubernetes クラスタを構築 https://oracle-japan.github.io/ocitutorials/cloud-native/devops-for-beginners-oke/ ※構築手順は、チュートリアルを参照

Secret 作成

Secret 作成 $ kubectl create secret generic mysql --from-literal=password=mysql-p@ssw0d 1.データベースのパスワードを格納する Kubernetes シークレットを作成 OCI の Cloud Shell で kubectl コマンドを実行

NFS サーバの作成

Kubernetes クラスタ上におけるデータの一時性と永続性一時性（ Temporary ）：Pod が削除または再デプロイさると同時にデータが消えること Pod volume Container Container Container Pod volume Pod 削除 = データ削除コンテナ内の書き込みレイヤーのボリュームにデータを保存 Pod 内のボリュームにデータを保存、例としては emptyDir

Kubernetes クラスタ上におけるデータの一時性と永続性永続性（ Persistent ）：Pod が削除または再デプロイされてもデータは消えないこと Pod volume Container ノードまたはディスク削除 = データ削除 Pod volume Container pvc pv Node Node Pod volume Container pvc pv Node External Storage 外部ストレージ・volumeの削除= データ削除ノードにあるローカルディスクまたは PVC/PV を利用してローカルディスクにデータを保存、直接の場合は、hostPath をマニフェストに定義する PVC/PV を利用して外部ストレージにデータを保存

PersistentVolumeClaim と PersistentVolume の仕組み Pod PersistentVolumeClaim PersistentVolume 20GiB PersistentVolume 30GiB PersistentVolume 40GiB 5GiB のボリュームを要求ボリュームの割り当て払い出されるボリュームは、要求されている 5GiB に近い 20GiB のボリュームとなるので、要求容量よりも 15GiB 多いボリュームとなる。 PersistentVolume の容量は設計時に校了が必要。

StorageClass による Dynamic Provisioning StorageClass の仕組みを利用して、PersistentVolumeClaim が発行されたタイミングで動的に PersistentVolume を作成してアサインできます。 Pod PersistentVolumeClaim PersistentVolume 5GiB 5GiB のボリュームを要求ボリュームの割り当て Dynamic Provisioning は、要求に応じて動的にボリュームを作成して割り当てる仕組み。StorageClass を登録して、PersistentVolumeClaim から呼び出すと Provisioner が要求に応じた PersistentVolume を作成して割り当てることができる。 StorageClass Provisioner

NFS サーバの作成 CSI ボリューム・プラグインを利用して、ブロックボリュームの PersistentVolumeClaim を作成 nfs-pvc.yaml oci-bv ストレージ・クラスの定義 ( provisioner: blockvolume.CSI.oraclecloud.com ) で指定された CSI プラグインを使用して、ブロック・ボリュームを動的にプロビジョニング。 $ kubectl apply -f nfs-pvc.yaml $ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE nfs-pvc Pending oci-bv 1m 1.マニフェストの適用 2. PVC の確認 oci-bv ストレージ・クラスの定義に volumeBindingMode: WaitForFirstConsumer が含まれているため、PVC のステータスは Pending となる。

NFS サーバの作成 Deployment として、NFS サーバを作成 NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE nfs-pvc Bound csi-3ce3f735-04a8-4b22-a768-7ae794d200a7 50Gi RWO oci-bv 141m nfs-server.yaml NFS サーバの Pod が作成されると PVC のステータスが、Pending から Bound に変わり、バインドされたことになる。 $ kubectl apply -f nfs-server.yaml 1.マニフェストの適用 $ kubectl get pvc 2. PVC の確認事前に作成した、PVC を指定

NFS サーバの作成 WordPress & MySQL から接続する NFS の Service を作成 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP,12250/TCP 33d nfs-service ClusterIP 10.96.211.52 <none> 2049/TCP,20048/TCP,111/TCP 167m nfs-service.yaml $ kubectl apply -f nfs-service.yaml 1.マニフェストの適用 $ kubectl get services 2. Service の確認

PV & PVC の作成

PV & PVC の作成 WordPress & MySQL Pod から紐づける PVC & PV を作成定義説明 name,labels 多数 PV がある場合に識別しやすくなるため、設定が推奨 storageClassName PV の StorageClass を指定 PVC は、紐づける PV の storageClassName を指定 storage 利用する容量を指定 accessModes ・ReadWriteOnce(RWO) 単一ノードから Read/Write ・ReadOnlyMany(ROX) 複数ノードから Read ・ReadWriteMany(RWX) 複数ノードから Read/Write persistentVolumeReclaimPolicy ・Delete PV の実体が削除される・Retain 指定しない場合は Retain 、PV の実体は削除せずに保持、他の PVC によって、このPVは再マウントされない・Recycle PV のデータを削除 ( rm –rf ./* ) し、再利用可能にする他の PVC によって再マウントされる nfs nfs-service の IP アドレスを入力して、NFS サーバを指定 mysql-pv.yaml wordpress-pv.yaml wordpress-pvc.yaml mysql-pvc.yaml

PV & PVC の作成 $ kubectl apply -f mysql-pv.yaml 1.マニフェストの適用 $ kubectl apply -f mysql-pvc.yaml $ kubectl apply -f wordpress-pv.yaml $ kubectl apply -f wordpress-pvc.yaml 2. Bound の確認 NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE persistentvolumeclaim/mysql-pvc Bound mysql-pv 10Gi RWX mysql 25h persistentvolumeclaim/nfs-pvc Bound csi-3ce3f735-04a8-4b22-a768-7ae794d200a7 50Gi RWO oci-bv 26h persistentvolumeclaim/wordpress-pvc Bound wordpress-pv 10Gi RWX wordpress 25h NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE persistentvolume/csi-3ce3f735-04a8-4b22-a768-7ae794d200a7 50Gi RWO Delete Bound default/nfs-pvc oci-bv 26h persistentvolume/mysql-pv 10Gi RWX Retain Bound default/mysql-pvc mysql 25h persistentvolume/wordpress-pv 10Gi RWX Retain Bound default/wordpress-pvc wordpress 25h $ kubectl get pvc,pv

Deployment & Service の作成

Deployment & Service の作成 WordPress & MySQL の Deployment を作成定義説明 containers Pod 内のコンテナの設定等を指定します。・image イメージレジストリ指定します。・env 環境変数指定、ここでは環境変数として MYSQL_ROOT_PASSWORD を定義し、Secrets に登録したパスワードを参照しています。・containerPort コンテナのポート番号を指定します。・volumeMounts PVC で要求する volume をマウントするコンテナ側のディレクトリを指定します。・volumes 連携する PVC を指定します。 mysql.yaml wordpress.yaml

Deployment & Service の作成 WordPress & MySQL の Service を作成定義説明 type ・ClusterIP クラスタ内で Pod 同士が通信するためのプライベートで IP アドレス・NodePort 「全ての Kubernetes Node の IPアドレス:port 」で受信したトラフィックをコンテナーに転送する形で外部通信を確立・LoadBalancer LB 経由でアクセス可能なサービス、L4 ロードバランサ機能 mysql-service.yaml wordpress-service.yaml

Deployment & Service の作成 WordPress & MySQL の Deployment を作成 $ kubectl apply -f mysql.yaml $ kubectl apply -f mysql-service.yaml $ kubectl apply -f wordpress.yaml $ kubectl apply -f wordpress-service.yaml 2. Pod のステータス確認 NAME READY STATUS RESTARTS AGE mysql-8585f7cbd7-9hz79 1/1 Running 0 25h nfs-server-5c9d68c76c-kxq4d 1/1 Running 0 26h wordpress-76f698c64-2qh8m 1/1 Running 0 25h $ kubectl get pods

Deployment & Service の作成 3. Service のステータス確認 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP,12250/TCP 34d mysql-service ClusterIP 10.96.94.102 <none> 3306/TCP 26h nfs-service ClusterIP 10.96.211.52 <none> 2049/TCP,20048/TCP,111/TCP 26h wordpress-service LoadBalancer 10.96.251.162 150.230.xxx.xxx 80:32516/TCP 25h $ kubectl get services http://EXTERNAL-IP/wp-admin/install.php 4. ブラウザアクセス

Pod のスケールアウトとインの作成 WordPress Pod を 10 個にして、スケールアップ $ kubectl scale deployment wordpress --replicas 10 スケールアップの確認 $ kubectl get pods NAME READY STATUS RESTARTS AGE mysql-c468c5548-bh6t5 1/1 Running 0 6m41s nfs-server-754d98f49b-zmfld 1/1 Running 0 10m wordpress-74d8c99c7f-6dhzg 1/1 Running 0 104s wordpress-74d8c99c7f-kg96k 1/1 Running 0 104s wordpress-74d8c99c7f-m2dg7 1/1 Running 0 104s wordpress-74d8c99c7f-mjrsm 1/1 Running 0 6m19s wordpress-74d8c99c7f-nzxkd 1/1 Running 0 104s wordpress-74d8c99c7f-pbr57 1/1 Running 0 104s wordpress-74d8c99c7f-pfrfz 1/1 Running 0 104s wordpress-74d8c99c7f-qqtdc 1/1 Running 0 104s wordpress-74d8c99c7f-rknbm 1/1 Running 0 105s wordpress-74d8c99c7f-svhpj 1/1 Running 0 104s

Pod のスケールアウトとインの作成 WordPress Pod を 1個にして、スケールイン $ kubectl scale deployment wordpress --replicas 1 スケールインの確認 $ kubectl get pods NAME READY STATUS RESTARTS AGE mysql-c468c5548-bh6t5 1/1 Running 0 6m41s nfs-server-754d98f49b-zmfld 1/1 Running 0 10m wordpress-74d8c99c7f-mjrsm 1/1 Running 0 6m19s

オブジェクトの削除 WordPress と MySQL の Deployment と Service を削除 $ kubectl delete -f wordpress-service.yaml $ kubectl delete -f wordpress.yaml $ kubectl delete -f mysql-service.yaml $ kubectl delete -f mysql.yaml WordPress と MySQL の PV と PVC を削除 $ kubectl delete pvc wordpress-pvc $ kubectl delete pvc mysql-pvc $ kubectl delete pv wordpress-pv $ kubectl delete pv mysql-pv

オブジェクトの削除 NFS の Deployment と Service と PVC を削除 $ kubectl delete service nfs-service $ kubectl delete deployment nfs-server $ kubectl delete pvc nfs-pvc Secret を削除 $ kubectl delete secret mysql

Service 紹介 OCI で選択可能な幅広いアプリケーションインフラストラクチャ Container Instances DIY K8s/Docker on VM or BM OKE with Customer- managed Nodes Serverless OKE (Virtual Nodes) OCI Functions MORE AGILITY Virtual Machine Bare Metal Managed Kubernetes(OKE) Compute Containers Functions MORE CONTROL

Service 紹介エンタープライズ品質と開発生産性を両立する Kubernetes プラットフォームエンタープライズ品質の性能と可用性 • 高性能インフラストラクチャによる分散アプリケーション環境 • 冗長化構成を自動で構成し、高可用性を実現マネージド環境と費用対効果 • 複雑な Kubernetes の構築不要で、開発を即座に開始 • 追加費用不要でコア機能を提供するマネージド Kubernetes 環境 • インフラ管理不要な Virtual Nodes オプション機能も提供 Cloud Native Java ソリューションや Oracle Database との親和性 • Oracle のマイクロサービス対応ソリューションと共に活用可能 • 既存資産・スキルを活用した、Cloud Native アプローチによる開発

Service 紹介エンタープライズ品質の性能と可用性ミッションクリティカル・システムに不可欠な安定した高性能を確実に維持 • 各ホスト間を低レイテンシーかつ広帯域のN/Wで接続したボトルネックの無いインフラストラクチャ • 大規模な数のコンテナのデプロイメントにおいてネットワーク性能劣化による品質低下を確実に防止 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性能検証結果エンタープライズ規模の処理量を支えるパフォーマンス高性能IaaS上に構築された確実な性能を実現するKubernetesプラットフォーム

Service 紹介エンタープライズ品質の性能と可用性 • 高性能IaaS上にKubernetesクラスタを構築し、安定したパフォーマンス • ドメインを横断してクラスタを構成を標準とする、高可用性アーキテクチャ高性能インフラによる分散アプリケーション環境／冗長化構成を自動で構成し高可用性を実現 ※単一AD構成のデータセンターの場合は、AD内で物理H/Wレベルのメンテナンス区画で分離されたFault Domainにまたがって分散配置することで可用性を担保

Service 紹介エンタープライズ品質の性能と可用性 • 開発環境から大規模ワークロードの本番環境まで対応可能なインスタンスの種類 • CPU や I/O 性能等ワークロードの特性に合わせたシェイプ・タイプを提供 • CPU アーキテクチャも、Intel/AMD/ARM から選択可能開発から本番、汎用ワークロードから高速演算処理まで特性に合わせた最適な選択肢 • GPU搭載タイプ • AI、機械学習、 HPC向け GPU • NVMe SSD内蔵タイプ • I/O性能重視のワークロード向けインスタンスの種類シェイプ・タイプ VMインスタンス Standard ベアメタルインスタンス • 汎用タイプ • 一般的なワークロード向け Dense I/O • HPC用タイプ • 高速プロセッサー搭載、クラスタリング用ネットワーク HPC • 仮想マシン環境 • 1コアから24コアまでサイズ選択可能な仮想マシン • 開発環境から本番環境まで利用可能な汎用インスタンス • 専用サーバー環境 • コンピュートリソース(CPU、メモリ)を必要とするワークロード用の物理サーバー環境 • 性能重視のアプリケーション向け Virtual Machine Bare Metal Compute • 一般ワークロードからHPCまで Arm

Service 紹介 Cloud Native Java ソリューションや Oracle Database との親和性マイクロサービス対応ソリューションと共に活用可能/既存資産を活用 OKE WebLogic Server Clusters Helidon/GraalVM を活用したマイクロサービスアプリケーション Autonomous Database MySQL Database Service On-Premis Pluggable DB Operator Oracle Database Operator、 Oracle MySQL Operator、 OCI Service Operator for Kubernetes などOracleが提供する Operatorでデータベースのライフサイクル管理マイクロサービスアプリケーションと親和性を高める Oracle Databaseや MySQLのマネージドサービスとの連携 WebLogic Server for OKE Helidon GraalVM Pluggable Database Autonomous Database MySQL Database Service Java EE/Jakarta EE 準拠のアプリケーションサーバコンテナ対応版 Javaのマイクロサービスフレームワーク ※WebLogic Serverユーザにはサポートあり高速起動/高速処理/マルチ言語対応のランタイムエンジンマイクロサービスのためのマルチテナントデータベースマルチモデル集中型データベースと機械学習ベースの自動化により運用コストを最大90%削減して完全なライフサイクル管理を実現するOCIネイティブな Oracle Database OLTPとOLAPに対応する1つのMySQL HeatWave Database Service

Copyright © 2023, Oracle and/or its affiliates 112 Basic Cluster（基本クラスタ）
& Enhanced Cluster（拡張クラスタ） OKE で選択可能な2つのクラスタタイプ Enhanced Cluster (拡張クラスタ) • Basic Clusterで提供される機能に加えて、OKEが提供する全ての機能を提供 • Clusterごとに課金が発生（¥14/hour） • Basic Clusterに加えて提供されるオプション機能は以下 • Virtual Nodes • アドオン機能管理 • Workload Identity • オンデマンドノードサイクル • SLA(Service Level Agreement)の提供 • サポートする Worker Node 数は 2000 Nodeまで Basic Cluster (基本クラスタ) • Kubernetes および OKE によって提供されるコア機能(コントロールプレーンのIn-place upgrade、機能強化、セキュリティアップデートなど)を提供 • IaaS サービス課金のみ (Clusterに課金はなし) • Virtual Nodes をはじめとした拡張クラスタのみで提供されるサービスは利用不可 • サポートする Worker Node 数は 1000 Nodeまで ※Basic ClusterからEnhanced ClusterへはIn-place upgradeによるアップグレードが可能(Enhanced ClusterからBasic Clusterへのダウングレードは不可)

Nodes 紹介インフラ管理不要(サーバレス)の Worker Node オプション ▪ ユースケース Worker Node の運用にコストをかけずに運用したい Worker Node の運用コスト増大を防ぎたい ▪ 特徴 • サーバレス Worker Node 環境 (Control Planeは従来通りマネージドで提供) • スケーリング、アップグレード、トラブルシューティングなどの運用上のコストを自動化 • コンテナアプリケーションが消費するリソース ( CPU/メモリ ) に基づいたきめ細やかな従量課金 ▪ 価格 • Cluster(Enhanced Cluster): ¥14/hour • Virtual Nodes (1Nodeあたり): ¥2.1/hour • Podが利用するリソース(OCPU/メモリ): Computeと同様 ※Network/Load BalancerなどのIaaSサービス利用分を別途課金 Container Engine For Kubernetes Managed Node Pool Virtual Node Pod 自動スケール Node 自動スケール(※) Virtual Node ※スケーリングは未実装(2023/7現在)

Nodes 紹介 Enhanced Cluster (拡張クラスタ) オプション Virtual Nodes • ユーザによるセキュリティパッチやトラブルシューティングなどのメンテナンス不要な仮想的な Worker Node • OKE で利用する Worker Node を仮想ノードとしてプロビジョニング • Compute のシェイプは E3/E4 のみ（2023年7月時点） • ユーザ側での OCPU とメモリの選択は不要 • Pod が消費する OCPU とメモリは、デプロイされた Pod の Resource Requests / Limits から算出(※) • 1 Virtual Node あたり 500 Pod まで実行可能 • Virtual Nodeのリソース( OCPU/メモリ )考慮は不要 • オートスケールにはHPAリソースの作成が必要 • Cluster Autoscaler は未実装(2023/7) • CNI は OCI VCN-Native Pod networking を利用ノード・タイプを管理対象または仮想から選択ユーザはノード数とポッド・シェイプ( Compute シェイプ)の選択のみポッド・シェイプのOCPU / メモリは OKE 側で算出管理対象 = Managed Nodes 仮想 = Virtual Nodes (※)Resource Requests/Limitsの指定がない場合、0.125OCPU /メモリ 0.5GB を割り当てる(課金は1 OCPU/メモリ1GBとして切り上げ)

Nodes 紹介 Enhanced Cluster (拡張クラスタ) オプションオンデマンドノードサイクル • Worker Node の Kubernetes バージョンとホスト OS バージョンのアップグレードを簡素化 • アップグレード時のパラメータとして以下を設定することで可用性を担保(整数/パーセンテージで指定) • maxSurge: アップグレード時に追加する新規 Worker Node 数(デフォルト1) • maxUnavailable:アップグレード時に利用不可を許容する Worker Node 数(デフォルト0) • 新規の Worker Node を最新の Kubernetes / OS バージョンで作成し、既存 Node を自動的に削除( drain は自動で実施) • アップグレード時の新規 Node と既存 Node のサイクサイクルの挙動は maxSurge / maxUnavailable に準拠実行すると Worker Node のアップグレードが開始される

Nodes 紹介 Virtual Nodesオプションの制限事項とロードマップ (2023/07) Virtual Nodes での制限事項 • Worker Node への SSH 接続不可 • cloud-init スクリプトの利用不可 • Node Doctor スクリプトの利用不可現在は未実装だが、今後のロードマップによりサポートされる機能 (Managed Nodes ではサポート済み) • Virtual Nodes のオートスケール • Virtual Nodes と Managed Nodes を混合したクラスタ • 永続化ボリューム(Block Volume/File Storage Service)の利用 • E3/E4(AMD)以外のポッド・シェイプ(Compute シェイプ)のサポート • Virtual Nodes に対する Reserved capacity https://docs.oracle.com/ja-jp/iaas/Content/ContEng/Tasks/contengcomparingvirtualwithmanagednodes_topic.htm

Nodes 紹介補足：Virtual Nodes と Managed Nodes の使い分け Managed Nodes を利用するユースケース • 以下のいずれかを満たす必要がある場合 • Worker Node に SSH ログインする必要がある場合 • 任意のソフトウェアをインストールしたい • OS/カーネルパラメータをカスタマイズしたい … • Cluster Autoscaler を利用する場合 • 永続化領域を利用したい場合 • OCI Block Volume や OCI FSS を利用した場合 • AMD 以外の Compute インスタンスを利用する場合 Virtual Nodesを利用するユースケース • ステートレス(永続化領域不要)なアプリケーションをスケーラブルに動作させたい場合(ただし、Node のスケールは利用しない) • Worker Node の運用コストを削減したい場合 • Worker Node が消費するリソースを気にすることなく、コンテナアプリケーションだけに注力して運用したい場合

Copyright © 2023, Oracle and/or its affiliates 122 OKE 利用パターン
Virtual Nodes と Managed Nodes の使い分け基本クラスタ(Basic Cluster) 拡張クラスタ(Enhanced Cluster) Managed Nodes Managed Nodes Virtual Nodes コア機能 ◯ ◯ ◯ Workload Identity × ◯ ◯ アドオン管理 × ◯ ◯ オンデマンドノードサイクル × ◯ - (コントロールプレーンと同時アップグレードのため考慮不要) SLA × ◯ ◯ 課金 Worker Node( Compute )のみ ( OKE および Cluster 課金なし) Cluster + Worker Node( Compute ) Cluster + Virtual Nodes + Pod が利用する OCPU/メモリ

Instances 紹介

Instances 紹介インフラ管理不要 (サーバレス) のコンテナ実行環境 ▪ ユースケースコンテナオーケストレーション( Kubernetes )を必要としないコンテナアプリケーションのデプロイ例)API、Web アプリ、継続的インテグレーション・デリバリー ( CI/CD )のジョブ、開発・テスト環境など ▪ 特徴 • セキュアに分離、最適化されたコンテナ実行環境 • ユーザによる仮想マシンの管理、パッチ適用、トラブルシューティングが不要 • コンテナを即座に実行可能 ▪ 価格通常の Compute と同様( OCPU/メモリ課金 ) ※ Serverless Container Instancesに対する課金はなし Container Instances Container Web アプリ物理マシン仮想マシンコンテナランタイムコンテナアプリケーション Oracle Managed Web API CI/CD ビルドジョブ Container Container OCIR Other Container Rgistry

Instances 紹介 OCI Container Instances のユースケース 1. コンテナ・オーケストレーション ( Kubernetes など) を必要としないコンテナ化されたアプリケーション 2. 迅速なインスタンスの作成と破棄が求められるワークロード • API サーバ/Web アプリケーション • 一時的なワークロード • CI/CD パイプライン・ジョブ • 開発/テスト環境 • データ/メディア処理 • 自動化タスク 3. サーバー/ VM 上で直接実行されるスタンドアロンコンテナ・ワークロード e.g., スケールアウトが考慮されていないレガシー・アプリケーションをコンテナ化してサーバレスで運用負荷軽減

Instances 紹介 Demo Movie - WordPress on Container Instances - Container Instances で WordPress を稼働させるデモ動画が公開されています。 https://www.youtube.com/watch?v=uXYhRp7MtcE

コンテナアプリケーション開発 のことはじめ ～ Docker & Kubernetes ～

コンテナアプリケーション開発 のことはじめ ～ Docker & Kubernetes ～

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript

コンテナアプリケーション開発のことはじめ～ Docker & Kubernetes ～

コンテナアプリケーション開発のことはじめ～ Docker & Kubernetes ～