Kubernetes Introduction

Kubernetes Introduction
Oracle Cloud Hangout Café Season7 #1
Yutaka Ichikawa
Oracle Corporation Japan
Solutions Architect
Jun07, 2023

View Slide

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

View Slide

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

View Slide

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

View Slide

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を動かしてみる

View Slide

6
コンテナとコンテナ・オーケストレーション

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

18
コンテナイメージの構造
Container
Image
読み込み専用
（ReadOnly）
ベースイメージ
CentOS
イメージ層
FROM centos:7
ENTRYPOINT ["/usr/sbin/nginx", "-g", "daemon off;“]
Dockerfile
①
②
③
④
⑤
⑤
④
③
②
①
コンテナ起動時の構造
ベースイメージ
CentOS
イメージ層
書き込み可能
イメージ層
読み込み専用
（ReadOnly）
「 $ docker container run 」
コマンドでコンテナが起動すると、
自動的に書き込み可能なレイ
ヤーが作られる仕組み
⑤
④
③
②
①
書き込み可能なイメージ層は
「 $ docker container commit 」コマンドで
保存されて、その層が読込専用となります。左例
でいうと⑥の層ができることになります。
6

View Slide

19
Docker 実践～ 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
ENTRYPOINT [“/usr/sbin/nginx”, “-g”, “daemon off;“]
①
②
③
④
⑤
Dockerfile コンテナイメージ
# docker image build -t cyberblack/test-nginx .
Build
※ cyberblack の箇所は DockerHub アカウント名
cyberblack/test-nginx
①
②
③
⑤
④

View Slide

20
Docker 実践～ 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

View Slide

21
# 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 にログイン

View Slide

22
# 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
# 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
Push
Pull
Ship
# docker image push cyberblack/test-nginx
# docker image pull cyberblack/test-nginx Container Image
$ docker image push
$ docker image pull

View Slide

23
Docker 実践～ 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

View Slide

24
Docker 実践～ 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

Welcome to nginx!

Hello,Docker & Kubernetes

コンテナ（Nginx）にアクセス
sample-nginx
port:80
localhost
port:8080
localhost ポート8080経由でコンテナーの80ポートへ
curl でアクセス
# curl http://localhost:8080
Run

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

33
Kubernetes コンポーネント

View Slide

34
Control Plane & Node

View Slide

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

View Slide

36

View Slide

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

View Slide

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

View Slide

39
Pod

View Slide

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

View Slide

41
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

View Slide

42
ReplicaSet & Deployment

View Slide

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

View Slide

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

View Slide

45
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

View Slide

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

View Slide

47
セルフヒーリングの仕組み
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 書き込む。

View Slide

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

View Slide

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

View Slide

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

View Slide

51
Reconcile Loop
2個のコンテナ（ Pod ）しか起動していない場合

View Slide

52
Reconcile Loop
Diff: 1個のコンテナ（ Pod ）が足りない

View Slide

53
Reconcile Loop
Act: 1個の nginx のコンテナ（ Pod ）を作成する

View Slide

54
Service

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

59
Ingress

View Slide

60
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

View Slide

61
Volume & PersistentVolume &

View Slide

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

View Slide

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

View Slide

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

View Slide

65
ConfigMap & Secret

View Slide

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

View Slide

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

View Slide

68
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

View Slide

69
Label & Namespace

View Slide

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

View Slide

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

View Slide

72
Kubernetes クラスタ構築 & アプリケーションデプロイ

View Slide

73
クラスタ構築

View Slide

74
Kubernetes クラスタ構築ツールを利用せずに、全てを1から構築する「 Kubernetes the hard way 」
https://github.com/kelseyhightower/kubernetes-the-hard-way

View Slide

75
kubeadm
https://kubernetes.io/docs/setup/independent/install-kubeadm/
Kubernetes クラスタを構築するオープンソースソフトウェア

View Slide

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
kubeadm
https://github.com/oracle-japan/ochacafe-s5-3

View Slide

77
Kubernetes マネージドサービス
Amazon
Elastic Kubernetes Service
Google
Kubernetes Engine
Azure
Kubernetes Service
Oracle
Container Engine for
Kubernetes

View Slide

78
WordPress を動かしてみる

View Slide

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

View Slide

80
デモ環境概要図

View Slide

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

View Slide

82
Secret 作成

View Slide

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

View Slide

84
NFS サーバの作成

View Slide

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

View Slide

86
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 を利用して外部ストレージにデータを保存

View Slide

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

View Slide

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

View Slide

89
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 となる。

View Slide

90
Deployment として、NFS サーバを作成
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
$ kubectl get pvc
2. PVC の確認
事前に作成した、PVC を指定

View Slide

91
WordPress & MySQL から接続する NFS の Service を作成
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 443/TCP,12250/TCP 33d
nfs-service ClusterIP 10.96.211.52 2049/TCP,20048/TCP,111/TCP 167m
nfs-service.yaml
$ kubectl apply -f nfs-service.yaml
$ kubectl get services
2. Service の確認

View Slide

92
PV & PVC の作成

View Slide

93
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

View Slide

94
PV & PVC の作成
$ kubectl apply -f mysql-pv.yaml
$ kubectl apply -f mysql-pvc.yaml
$ kubectl apply -f wordpress-pv.yaml
$ kubectl apply -f wordpress-pvc.yaml
2. Bound の確認
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

View Slide

95
Deployment & Service の作成

View Slide

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

View Slide

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

View Slide

98
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

View Slide

99
3. Service のステータス確認
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 443/TCP,12250/TCP 34d
mysql-service ClusterIP 10.96.94.102 3306/TCP 26h
nfs-service ClusterIP 10.96.211.52 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. ブラウザアクセス

View Slide

100
Pod のスケールアウトとインの作成
WordPress Pod を 10 個にして、スケールアップ
$ kubectl scale deployment wordpress --replicas 10
スケールアップの確認
$ kubectl get pods
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

View Slide

101
Pod のスケールアウトとインの作成
WordPress Pod を 1個にして、スケールイン
$ kubectl scale deployment wordpress --replicas 1
スケールインの確認
$ kubectl get pods
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

View Slide

102
オブジェクトの削除
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

View Slide

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

View Slide

104
参考

View Slide

105
参考
Docker & Kubernetes Kubernetes
Security
日本語書籍
Public Cloud & Container/Kubernetes

View Slide

106
参考
Certified Kubernetes
Administrator
資格
Developer
Security Specialist

View Slide

Thank you
107

View Slide

Kubernetes Introduction

Kubernetes Introduction

oracle4engineer
PRO

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript

Kubernetes Introduction

Kubernetes Introduction

oracle4engineer PRO

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript

oracle4engineer
PRO