2017年10月27開催の広島Javaユーザーグループの資料です。 SpeakerDeckへ移行します。(https://speakerdeck.com/yasu7ri/kubernetes-super-introduction-with-java)

1. Kubernetes超入門 with Java
Kubernetes超入門ハンズオン
広島Javaユーザーグループ
#hirojug

2. 1
5月に「Oracle Code Japan Tour in Hiroshima」の「Cloud Native Java
EE」セッションでKubernetesを使用したライブコーディングデモを行って頂いた
が・・・
Kubernetesに関してあまり知識が無かったため、その場で何が行われたかあ
まり理解できていなかった参加者の方が多かった。（私も含め）
そこで、Kubernetesに関する基本的な概要の説明と基本操作のハンズオンを
通してKubernetesへ超入門したいと思います。
開催の経緯

3. 1. 本日の内容とゴール

4. 3
内容
Kubernetesの概要説明とローカル環境にKubernetesを構築してSpring Bootで
作成したREST APIを使用してコンテナオーケストレーションを体験する
ゴール
– Kubernetes概要の理解
– ローカル環境へKubernetesの構築が出来るようになる
– Kubernetesを使用した初歩的なコンテナオーケストレーションの体験
しないこと
– コンテナ(Docker)に関する説明
– Spring Bootの説明、実装方法の説明
– REST APIについて
本日の内容とゴール
ここしないと、
もやはJavaとは関係
ないのでは、、、

5. 4
本日のアジェンダ
Kubernetesの概要
ローカル環境の構築
ハンズオン
– Pod単体でのデプロイ
– Replica Setを使用したデプロイ
– Deploymentを使用したデプロイ
– Serviceの作成
– Serviceを利用したBlue/Green Deployment
告知
– オープンセミナー2018＠広島
懇親会
– 行ける人だけでちょっと飲みに行く
– 予約してません

6. 2. Kubernetesの概要

7. 6
miniKubeのダウンロード
– Windows 用の exe (minikube-windows-amd64.exe)
https://github.com/kubernetes/minikube/releases
そのまえに、、、聞きならがダウンロードをお願いします

8. 7
ベアメタルサーバーや仮想マシン上のDockerをはじめとするコンテナ群を管理
するシステム（コンテナオーケストレーションツール）。
Google社内で開発/運用されているコンテナクラスタ管理システム「Borg」での
ノウハウを結集して開発された。現在はApacheライセンスで配布されている
オープンソースソフトウェアである。
マイクロサービスを効率的にデプロイ、アップデートする機能として、コンテナの
オートスケール、 Blue Green Deployment 、 Rolling Update などの機能
を備えている。
ちなみに「Kubernetes」は、ギリシャ語で「船の操縦手」「統括者・支配者」という
意味があるとされ。「k8s」と略され記述される事が多い。
（8はKからsの間の文字数を表している）
読み方は「クーベーネィテス」や「クゥバネィテス」？
Kubernetesとは

9. 8
2014年6月：公開
2015年7月：バージョン1.0リリース
2015年7月：Linux Foundation傘下の「Cloud Native Computing Fou
ndation(CNCF)」に管理が委譲
(AT&T、Cisco、CoreOS、Docker、IBM、Intel、Microsoft、Red Hat、VM
wareなどの企業が開発に参加している)
2017年8月：AWSがCNCFに、最上位メンバーのプラチナ会員として参加
これまでの簡単な経緯

10. 9
コンテナ技術の導入により、各アプリケーションのデプロイは圧倒的に早く、自動
的に行えるようになった。しかし実際の運用では複数のアプリケーションを連動さ
せて一つのサービスとして提供する必要がある。（特にマイクロサービス的なア
プローチでは）そこでコンテナ間の連携が不可欠となり障害時の対策など運用面
を考慮した場合、複数コンテナを管理するシステムが必要となった。
「AWS」「Microsoft Azure」「Google Cloud Platform」「IBM Bluemix」など
の主要クラウドプロバイダーがCNCFの会員になった事により、現在のところコン
テナオーケストレーションツールとしてKubernetesはデファクトといえる存在に
なりつつある
Kubernetes以外のオーケストレーションツール
Docker Swarm、Amazon EC2 Container Serviceなどがある
なぜコンテナオーケストレーションツールが必要になったのか

11. 10
実行環境に依存しないアーキテクチャ
– オンプレ環境やGCP、AWS上であってもk8sを通して設定、運用すると差異はほと
んど発生しない
コンテナ実装に依存しないコンテナ実行環境
– コンテナ実装環境の抽象化によりOpen Container Initiativeが進めているコン
テナ仕様標準であればDocker以外のコンテナ実装でもよい
複数ホストにコンテナをデプロイ
– どのホストにどのコンテナを配備するかを隠蔽
コンテナ間のネットワーク管理（名前解決も含む）
– サービスディスカバリー相当の機能
コンテナの死活監視
– コンテナが死んだら、コンテナを自動で新規起動
コンテナの負荷分散
– 同一機能の複数コンテナへのアクセスバランシング機能
コンテナのリソースアロケーション
– コンテナ毎にCPUリソースやメモリーリソースの割当指定機能
Kubernetesは何をしてくれるのか

12. 11
概要構成図：簡易な外部からのアクセスに対する構成図
（本日はIngressは使用しません）
Kubernetesの概要構成
Cluster
Node
Pod
コンテナ
Service
Ingress
internet
Node
Pod
コンテナ
Node
Pod
コンテナ
Service

13. 12
Node/Cluster
Nodeとは、k8sのコンテナをデプロイするためのVMないし物理サーバのこと。
k8sを管理するデーモン群及び、ユーザーが提供する全てのコンテナがこれら
Node上で実行される。Nodeの集合体をCliuterと呼ぶ
Pod
k8sでのデプロイの最小単位。Podは１個以上のコンテナの集合体で、Node
上に展開されるk8s固有の概念。
Podの特徴は指定したコンテナは全て同時に同じNodeにデプロイされる。これ
により密結合する複数のプロセス（コンテナ）で構成された１つのアプリケーショ
ンでお互いを見つけやすくし１つの集合体としてデプロイ出来る
（例：リバースプロキシとアプリケーション、アプリケーションのフロントとバックエ
ンドなどの組合せ）
– Pod内のコンテナ同士はlocalhost経由で通信できる
– 外部から直接Podへはアクセスは出来ない
– Label:k8sで管理されているリソースは定義に基づき自動的に初期化、デプロイさ
れるがその際にランダムな名前が自動的に振られる、それらを見つけやすくするた
めPodに対してタグを付与することが出来る
Kubernetesの用語[1/3]

14. 13
Service
複数Podに対して単一IPアドレスを割り当てるk8sの機能で、結果的に
ServiceへのアクセスがPodに振り分けられるのでロードバランサの様に振る
舞う。k8sではサービスディスカバリを実現するたのリソースとされている
– Serviceの種類
 ClusterIP:クラスタ内部にサービスを公開します。この値を選択すると、クラスタ内からの
みサービスにアクセスできます(デフォルト)
 NodePort:各ノードIP上に静的なポートでサービスを公開します。
<NodeIP>：<NodePort>を要求することにより、クラスタ外からNodePortサービスに
アクセスできます
 LoadBalancer:クラウドプロバイダのロードバランサを使用して外部的にサービスを公開
します(※minikubeは非対応)
 ExternalName:DNSのCNAMEレコードを設定することにより、クラスタ内部向けのエイ
リアスを作成する。これにはバージョン1.7以上のkube-dnsが必要
Kubernetesの用語[2/3]

15. 14
Ingress
IngressはServiceにひも付き、通信内容をServiceにプロキシする。HTTP
ロードバランサに特化して実装されている為、L7でのURLパターンによるルー
ティングやSSL終端処理などの設定も行える。また、Ingressはk8sが稼働し
ている環境によって機能と実装がかわる、GCPではGCPの、AWSではAWS
の環境に合った形でプロキシが作成される
Replica Set
Podのレプリカ数（Pod内のコンテナ数）を維持/保証する機能。コンテナが指定
したレプリカ数よりも少ない場合は新たにコンテナを起動し、増えすぎてる場合
はコンテナを削除しレプリカ数を維持する
Deployment
PodやReplication Setsの宣言型アップデート機能を提供。Deploymentオ
ブジェクト内で希望する状態を記載すればDeployment Controllerが要求し
た状態に変更してくれる
その他にもKubernetes固有の概念、用語が多数存在する
Kubernetesの用語[3/3]

16. 3. ローカル環境の構築

17. 16
Minikubeは、k8sを試してみたり、日常的に開発しようと思っているユーザーの
ために、ローカルマシーン上のVM内にk8クラスタ内のコンテナを操作するため
のサーバ(Kubernetes Master)と単一ノードのk8sクラスタを構築してくれる
Minikubeとは
ローカルマシーン
(Linux,Mac OS,Windows)
VM(VirtualMachine)
Kubernetes(minikube)
Kubernetes Master
Node
(1つのみ)

18. 17
前提
– virtualBoxがインストールされていること
minikubeのセットアップ
– miniKubeのダウンロード
 Windows 用の exe (minikube-windows-amd64.exe)
https://github.com/kubernetes/minikube/releases
– minikubeの設定
 minikube-windows-amd64.exeをminikube.exe とリネームしてパスの通ったフォ
ルダに置く
 デフォルトの vm driver を VirtualBox にするため、以下のコマンド実行
– kubectl がインストールされていないのでエラーメッセージが表示される
– 表示されたURL から kubectl.exe をダウンロードしてパスの通ったフォルダに配置
– 再度vm driver を VirtualBox にするためコマンドを実行する
Kubernetesクラスタの作成
– 以下のコマンドでクラスタを作成する
– 以下のコマンドでサーバーバージョンを取得出来たら成功
Windows上にkubernetes環境を構築する
$ minikube config set vm-driver virtualbox
$ minikube start
$ minikube version

19. 4. ハンズオン

20. 19
今回のハンズオンでは、 Dockerレジストリに登録済みのSpring Bootで作成
したREST APIのDockerイメージを利用し、Kubernetesのコンテナオーケスト
レーションを体験する
Dockerレジストリ
– docker.io/uls555/getting-started-k8s-with-java
デプロイまでの流れ
ハンズオンの流れ
Docker Hub
ローカルマシーン
Docker Image
InternetREST API
minikube
push
pull
①
②
③

21. 20
使用するREST APIの確認（デモ）
REST APIのデモ
Docker Hub
ローカルマシーン
Docker Image
InternetREST API
minikube

22. 21
まずはPodの基本を抑える為にPod単体のデプロイをしてみる。リソース定義は
マニフェストと呼ばれYAML形式で記述する
Podの定義と作成
– 次の内容でpod.yamlを作成
– Podを作成
Podの確認
– このPodはクラスタ内部のプライベートIPアドレスしか持っていないので外部からは
直接アクセス出来ない
– Dashboardでも確認してみよう（URL:http://192.168.99.100:30000）
Pod単体でのデプロイ[1/2]
apiVersion: v1
kind: Pod
metadata:
name: rest-api
spec:
containers:
- image: docker.io/uls555/getting-started-k8s-with-java:v1
imagePullPolicy: Always
name: rest-api
$ kubectl create -f pod.yaml
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
rest-api 0/1 ContainerCreating 0 1m
イメージの指定

23. 22
Podの削除
Pod単体でのデプロイ[2/2]
$ kubectl delete pod rest-api

24. 23
Podを直接作成した場合、Podが異常停止した際の処理や設定変更を行った際
の管理などがされない。Replica Setを利用して複数のPodを作成する
Replica Setの定義と作成
– 次の内容でreplicaset.yamlを作成
– Replica Setを作成
Replica Setを使用したデプロイ[1/2]
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: rest-api-rs
spec:
replicas: 3
template:
metadata:
labels:
app: my-rest-api
spec:
containers:
- image: docker.io/uls555/getting-started-k8s-with-java:v1
imagePullPolicy: Always
name: rest-api
$ kubectl create -f replicaset.yaml
作成するPodの数
Podの定義

25. 24
Podの確認
Podの自動起動の確認
Replica Setで指定したPod数を維持するため、Podを削除しても自動的に
Podが起動する
– Podの削除
Replica Setの削除
Replica Setを使用したデプロイ[2/2]
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
rest-api-rs-6xpqf 1/1 Running 0 1m
rest-api-rs-m1x43 1/1 Running 0 1m
rest-api-rs-pbsmk 1/1 Running 0 1m
$ kubectl delete pod rest-api-rs-m1x43
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
rest-api-rs-6xpqf 1/1 Running 0 4m
rest-api-rs-m1x43 1/1 Terminating 0 4m
rest-api-rs-n92wz 0/1 ContainerCreating 0 5s
rest-api-rs-pbsmk 1/1 Running 0 4m
削除されたPod
新規作成されたPod
$ kubectl delete replicaset rest-api-rs

26. 25
Replica Setを直接編集すると変更履歴がk8s上に残らない。Deploymentを
使用することによりデプロイの履歴がk8s上に残るため前のバージョンに安全に
戻ることが出来る
Deploymentの定義とデプロイ
– 次の内容でdeployment.yamlを作成
– デプロイ
Deploymentを使用したデプロイ[1/3]
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: rest-api-dep
spec:
replicas: 3
template:
metadata:
labels:
app: my-rest-api
spec:
containers:
- image: docker.io/uls555/getting-started-k8s-with-java:v1
imagePullPolicy: Always
name: rest-api
マニフェストファイルは
RepulicsSetとほぼ同等
$ kubectl create -f deployment.yaml

27. 26
Podの確認
Deploymentの変更
– Replicasの数を4に変更
Deploymentを使用したデプロイ[2/3]
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
rest-api-rs-6xpqf 1/1 Running 1 9h
rest-api-rs-n92wz 1/1 Running 1 9h
rest-api-rs-pbsmk 1/1 Running 1 9h
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: rest-api-dep
spec:
replicas: 4
template:
metadata:
labels:
app: my-rest-api
spec:
containers:
- image: docker.io/uls555/getting-started-k8s-with-java:v1
imagePullPolicy: Always
name: rest-api
replicaの数を4に変更

28. 27
Deploymentの変更
– Deploymentの更新
Podの確認
– Pod数が1個追加され、4個に変更されている
Deploymentを使用したデプロイ[3/3]
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
rest-api-rs-6xpqf 1/1 Running 1 9h
rest-api-rs-9b0sl 1/1 Running 0 10s
rest-api-rs-fbcdf 0/1 ContainerCreating 0 10s
rest-api-rs-pbsmk 1/1 Running 1 9h
$ kubectl apply -f deployment.yaml
新規に起動中

29. 28
Serviceを作成して、これまで作成したPodを一つの名前に集約したサービスを
作るとともに、外部からの接続をPodに接続する
Serviceの定義と作成
– 次の内容でservice.yamlを作成
– Serviceを作成
Serviceの確認
Serviceの作成[1/3]
kind: Service
apiVersion: v1
metadata:
name: rest-api-service
spec:
type: NodePort
selector:
app: my-rest-api
ports:
- port: 8080
targetPort: 8080
$ kubectl create -f service.yaml
Serviceの種類はNodeportを選択する
※minikubeではLoadBalancerは非対応
PodのLavelに「app:my-rest-api」が設定
されているPodを紐付ける
公開するServiceのポートとPodのポートを
紐付ける
$ kubectl get services
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes 10.0.0.1 <none> 443/TCP 11h
rest-api-service 10.0.0.51 <nodes> 8080:31372/TCP 1m

30. 29
ブラウザーからServiceへの接続を確認
– NodeのIPを確認
– ブラウザーからアクセス
Deploymentの変更と更新
– コンテナイメージをv2に変更
Serviceの作成[2/3]
$ minikube ip
192.168.99.100
http://192.168.99.100:31372
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: rest-api-dep
spec:
replicas: 4
template:
metadata:
labels:
app: my-rest-api
spec:
containers:
- image: docker.io/uls555/getting-started-k8s-with-java:v2
imagePullPolicy: Always
name: rest-api
v2に変更

31. 30
Deploymentの変更と更新
– 更新
 Deploymentの更新は、デフォルトでシステムがダウンしないように少しずつアップデート
するローリングアップデートが用いられる
– 更新の確認
Deploymentのロールバックと確認
– ロールバック
– 確認
Serviceの作成[3/3]
$ kubectl apply -f deployment.yaml
deployment "rest-api-dep" replaced
$ curl 192.168.99.100:31372
{"message":"Hello World!","version":"v2"}
$ kubectl rollout undo deployment/rest-api-dep
deployment "rest-api-dep" rolled back
$ curl 192.168.99.100:31372
{"message":"Hello World!","version":"v1"}

32. 31
Deploymentを変更することでローリングアップデートは可能だが短時間に切り
替えられない。 Blue/Green Deploymentの様な方法を取りたい場合は
Serviceを利用し切り換える方法がある
新規にDeploymentを作成
– 次の内容でdeployment-v3.yamlを作成
– デプロイ
Serviceを利用したBlue/Green Deployment[1/2]
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: rest-api-dep-v3
spec:
replicas: 3
template:
metadata:
labels:
app: my-rest-api-v3
spec:
containers:
- image: docker.io/uls555/getting-started-k8s-with-java:v1
imagePullPolicy: Always
name: rest-api
Deploymentの名前とタ
グをv3に変更
$ kubectl create –f deployment-v3.yaml

33. 32
– Deploymentの確認
Serviceの変更と確認
– ServiceとPodの紐付けを行なうselectorの変更を行なう
– 更新と確認
Serviceを利用したBlue/Green Deployment[2/2]
$ kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
rest-api-dep 4 4 4 4 3h
rest-api-dep-v3 4 4 4 4 23m
kind: Service
apiVersion: v1
metadata:
name: rest-api-service
spec:
type: NodePort
selector:
app: my-rest-api-v3
ports:
- port: 8080
targetPort: 8080
PodのLavelに「app:my-rest-api-v3」が
設定されているPodを紐付ける
$ kubectl apply -f service.yaml
service "rest-api-service" configured
$ curl 192.168.99.100:31372
{"message":"Hello World!","version":"v3"}

34. 5. その他

35. 34
minikube startでエラーになったら
– Nodeを削除する
– 上記でも解消しない場合は、”.minikube”ディレクトリを削除しminikubeを再度起
動する
トラブルシューティング
$ minikube stop
$ minikube delete
$ minikube start

36. 35
参考・引用元
 WEBサイト
– Using Kubernetes on Google Container Engine
https://www.slideshare.net/enakai/using-kubernetes-on-google-container-engine
– Dockerも始めました2 ～Kubernetes編～
https://oss.sios.com/yorozu-blog/yorozu-20151216
– Dockerコンテナを管理するならKubernetes
http://tech.uzabase.com/entry/2015/02/13/180743
– minikube で Windows 上に Kubernetes 環境を構築する
http://takaya030.hatenablog.com/entry/2017/04/30/191727
– kubernetesで変わる開発スタイル 〜マイクロサービスじゃなくてもいいじゃない〜
http://sssslide.com/speakerdeck.com/sgeengineer/kubernetesdebian-warukai-fa-sutairu-
maikurosabisuziyanakutemoiiziyanai
– Kubernetesで使われる用語
http://qiita.com/t-yotsu/items/f565b2d788a3b98fe762
 書籍
– プログラマのためのGoogle Cloud Platform入門
– WEB+DB-PRESS Vol.99