kubernetes超入門 with java

Kubernetes超入門 with Java

Kubernetes超入門ハンズオン

広島Javaユーザーグループ

#hirojug

1

5月に「Oracle Code Japan Tour in Hiroshima」の「Cloud Native Java EE」セッションでKubernetesを使用したライブコーディングデモを行って頂いたが・・・

Kubernetesに関してあまり知識が無かったため、その場で何が行われたかあまり理解できていなかった参加者の方が多かった。（私も含め）

そこで、Kubernetesに関する基本的な概要の説明と基本操作のハンズオンを通してKubernetesへ超入門したいと思います。

開催の経緯

1. 本日の内容とゴール

3

内容

Kubernetesの概要説明とローカル環境にKubernetesを構築してSpring Bootで作成したREST APIを使用してコンテナオーケストレーションを体験する

ゴール

– Kubernetes概要の理解

–ローカル環境へKubernetesの構築が出来るようになる

– Kubernetesを使用した初歩的なコンテナオーケストレーションの体験

しないこと

– コンテナ(Docker)に関する説明

– Spring Bootの説明、実装方法の説明

– REST APIについて

本日の内容とゴール

ここしないと、もやはJavaとは関係ないのでは、、、

4

本日のアジェンダ

Kubernetesの概要

ローカル環境の構築

ハンズオン

– Pod単体でのデプロイ

– Replica Setを使用したデプロイ

– Deploymentを使用したデプロイ

– Serviceの作成

– Serviceを利用したBlue/Green Deployment

告知

–オープンセミナー2018＠広島

懇親会

–行ける人だけでちょっと飲みに行く

–予約してません

2. Kubernetesの概要

6

miniKubeのダウンロード

– Windows 用の exe (minikube-windows-amd64.exe) https://github.com/kubernetes/minikube/releases

そのまえに、、、聞きならがダウンロードをお願いします

7

ベアメタルサーバーや仮想マシン上のDockerをはじめとするコンテナ群を管理するシステム（コンテナオーケストレーションツール）。

Google社内で開発/運用されているコンテナクラスタ管理システム「Borg」でのノウハウを結集して開発された。現在はApacheライセンスで配布されているオープンソースソフトウェアである。

マイクロサービスを効率的にデプロイ、アップデートする機能として、コンテナのオートスケール、 Blue Green Deployment 、 Rolling Update などの機能を備えている。

ちなみに「Kubernetes」は、ギリシャ語で「船の操縦手」「統括者・支配者」という意味があるとされ。「k8s」と略され記述される事が多い。

（8はKからsの間の文字数を表している）

読み方は「クーベーネィテス」や「クゥバネィテス」？

Kubernetesとは

8

2014年6月：公開

2015年7月：バージョン1.0リリース

2015年7月：Linux Foundation傘下の「Cloud Native Computing Foundation(CNCF)」に管理が委譲(AT&T、Cisco、CoreOS、Docker、IBM、Intel、Microsoft、Red Hat、VMwareなどの企業が開発に参加している)

2017年8月：AWSがCNCFに、最上位メンバーのプラチナ会員として参加

これまでの簡単な経緯

9

コンテナ技術の導入により、各アプリケーションのデプロイは圧倒的に早く、自動的に行えるようになった。しかし実際の運用では複数のアプリケーションを連動させて一つのサービスとして提供する必要がある。（特にマイクロサービス的なアプローチでは）そこでコンテナ間の連携が不可欠となり障害時の対策など運用面を考慮した場合、複数コンテナを管理するシステムが必要となった。

「AWS」「Microsoft Azure」「Google Cloud Platform」「IBM Bluemix」などの主要クラウドプロバイダーがCNCFの会員になった事により、現在のところコンテナオーケストレーションツールとしてKubernetesはデファクトといえる存在になりつつある

Kubernetes以外のオーケストレーションツールDocker Swarm、Amazon EC2 Container Serviceなどがある

なぜコンテナオーケストレーションツールが必要になったのか

10

実行環境に依存しないアーキテクチャ

–オンプレ環境やGCP、AWS上であってもk8sを通して設定、運用すると差異はほとんど発生しない

コンテナ実装に依存しないコンテナ実行環境

– コンテナ実装環境の抽象化によりOpen Container Initiativeが進めているコンテナ仕様標準であればDocker以外のコンテナ実装でもよい

複数ホストにコンテナをデプロイ

–どのホストにどのコンテナを配備するかを隠蔽

コンテナ間のネットワーク管理（名前解決も含む）

–サービスディスカバリー相当の機能

コンテナの死活監視

– コンテナが死んだら、コンテナを自動で新規起動

コンテナの負荷分散

–同一機能の複数コンテナへのアクセスバランシング機能

コンテナのリソースアロケーション

– コンテナ毎にCPUリソースやメモリーリソースの割当指定機能

Kubernetesは何をしてくれるのか

11

概要構成図：簡易な外部からのアクセスに対する構成図（本日はIngressは使用しません）

Kubernetesの概要構成

Cluster

Node

Pod

コンテナ

Service

Ingress

internet

Node

Pod

コンテナ

Node

Pod

コンテナ

Service

12

Node/ClusterNodeとは、k8sのコンテナをデプロイするためのVMないし物理サーバのこと。k8sを管理するデーモン群及び、ユーザーが提供する全てのコンテナがこれらNode上で実行される。Nodeの集合体をCliuterと呼ぶ

Podk8sでのデプロイの最小単位。Podは１個以上のコンテナの集合体で、Node上に展開されるk8s固有の概念。Podの特徴は指定したコンテナは全て同時に同じNodeにデプロイされる。これにより密結合する複数のプロセス（コンテナ）で構成された１つのアプリケーションでお互いを見つけやすくし１つの集合体としてデプロイ出来る（例：リバースプロキシとアプリケーション、アプリケーションのフロントとバックエンドなどの組合せ）

– Pod内のコンテナ同士はlocalhost経由で通信できる

–外部から直接Podへはアクセスは出来ない

– Label:k8sで管理されているリソースは定義に基づき自動的に初期化、デプロイされるがその際にランダムな名前が自動的に振られる、それらを見つけやすくするためPodに対してタグを付与することが出来る

Kubernetesの用語[1/3]

13

Service複数Podに対して単一IPアドレスを割り当てるk8sの機能で、結果的にServiceへのアクセスがPodに振り分けられるのでロードバランサの様に振る舞う。k8sではサービスディスカバリを実現するたのリソースとされている

– Serviceの種類

ClusterIP:クラスタ内部にサービスを公開します。この値を選択すると、クラスタ内からのみサービスにアクセスできます(デフォルト)

NodePort:各ノードIP上に静的なポートでサービスを公開します。<NodeIP>：<NodePort>を要求することにより、クラスタ外からNodePortサービスにアクセスできます

LoadBalancer:クラウドプロバイダのロードバランサを使用して外部的にサービスを公開します(※minikubeは非対応)

ExternalName:DNSのCNAMEレコードを設定することにより、クラスタ内部向けのエイリアスを作成する。これにはバージョン1.7以上のkube-dnsが必要


14

IngressIngressはServiceにひも付き、通信内容をServiceにプロキシする。HTTPロードバランサに特化して実装されている為、L7でのURLパターンによるルーティングやSSL終端処理などの設定も行える。また、Ingressはk8sが稼働している環境によって機能と実装がかわる、GCPではGCPの、AWSではAWSの環境に合った形でプロキシが作成される

Replica SetPodのレプリカ数（Pod内のコンテナ数）を維持/保証する機能。コンテナが指定したレプリカ数よりも少ない場合は新たにコンテナを起動し、増えすぎてる場合はコンテナを削除しレプリカ数を維持する

DeploymentPodやReplication Setsの宣言型アップデート機能を提供。Deploymentオブジェクト内で希望する状態を記載すればDeployment Controllerが要求した状態に変更してくれる

その他にもKubernetes固有の概念、用語が多数存在する


3. ローカル環境の構築

16

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

Minikubeとは

ローカルマシーン(Linux,Mac OS,Windows)

VM(VirtualMachine)

Kubernetes(minikube)

Kubernetes MasterNode

(1つのみ)

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

4. ハンズオン

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

①

②

③

20

使用するREST APIの確認（デモ）

REST APIのデモ

Docker Hub

ローカルマシーン

Docker Image

InternetREST API

minikube

21

まずはPodの基本を抑える為にPod単体のデプロイをしてみる。リソース定義はマニフェストと呼ばれYAML形式で記述する

Podの定義と作成

–次の内容でpod.yamlを作成

– Podを作成

Podの確認

– このPodはクラスタ内部のプライベートIPアドレスしか持っていないので外部からは直接アクセス出来ない

– Dashboardでも確認してみよう（URL:http://192.168.99.100:30000）

Pod単体でのデプロイ[1/2]

apiVersion: v1kind: Podmetadata:

name: rest-apispec:

containers:- image: docker.io/uls555/getting-started-k8s-with-java:v1

imagePullPolicy: Alwaysname: rest-api

$ kubectl create -f pod.yaml

$ kubectl get podsNAME READY STATUS RESTARTS AGErest-api 0/1 ContainerCreating 0 1m

イメージの指定

22

Podの削除

Pod単体でのデプロイ[2/2]

$ kubectl delete pod rest-api

23

Podを直接作成した場合、Podが異常停止した際の処理や設定変更を行った際の管理などがされない。Replica Setを利用して複数のPodを作成する

Replica Setの定義と作成

–次の内容でreplicaset.yamlを作成

– Replica Setを作成

Replica Setを使用したデプロイ[1/2]

apiVersion: extensions/v1beta1kind: ReplicaSetmetadata:

name: rest-api-rsspec:

replicas: 3template:metadata:

labels:app: my-rest-api

spec:containers:

- image: docker.io/uls555/getting-started-k8s-with-java:v1imagePullPolicy: Alwaysname: rest-api

$ kubectl create -f replicaset.yaml

作成するPodの数

Podの定義

24

Podの確認

Podの自動起動の確認Replica Setで指定したPod数を維持するため、Podを削除しても自動的にPodが起動する

– Podの削除

Replica Setの削除

Replica Setを使用したデプロイ[2/2]

$ kubectl get podNAME READY STATUS RESTARTS AGErest-api-rs-6xpqf 1/1 Running 0 1mrest-api-rs-m1x43 1/1 Running 0 1mrest-api-rs-pbsmk 1/1 Running 0 1m

$ kubectl delete pod rest-api-rs-m1x43$ kubectl get podNAME READY STATUS RESTARTS AGErest-api-rs-6xpqf 1/1 Running 0 4mrest-api-rs-m1x43 1/1 Terminating 0 4mrest-api-rs-n92wz 0/1 ContainerCreating 0 5srest-api-rs-pbsmk 1/1 Running 0 4m

削除されたPod

新規作成されたPod

$ kubectl delete replicaset rest-api-rs

25

Replica Setを直接編集すると変更履歴がk8s上に残らない。Deploymentを使用することによりデプロイの履歴がk8s上に残るため前のバージョンに安全に戻ることが出来る

Deploymentの定義とデプロイ

–次の内容でdeployment.yamlを作成

–デプロイ

Deploymentを使用したデプロイ[1/3]

apiVersion: apps/v1beta1kind: Deploymentmetadata:

name: rest-api-depspec:



spec:containers:


マニフェストファイルはRepulicsSetとほぼ同等

$ kubectl create -f deployment.yaml

26

Podの確認

Deploymentの変更

– Replicasの数を4に変更


$ kubectl get podsNAME READY STATUS RESTARTS AGErest-api-rs-6xpqf 1/1 Running 1 9hrest-api-rs-n92wz 1/1 Running 1 9hrest-api-rs-pbsmk 1/1 Running 1 9h


name: rest-api-depspec:



spec:containers:


replicaの数を4に変更

27

Deploymentの変更

– Deploymentの更新

Podの確認

– Pod数が1個追加され、4個に変更されている


$ kubectl get podsNAME READY STATUS RESTARTS AGErest-api-rs-6xpqf 1/1 Running 1 9hrest-api-rs-9b0sl 1/1 Running 0 10srest-api-rs-fbcdf 0/1 ContainerCreating 0 10srest-api-rs-pbsmk 1/1 Running 1 9h

$ kubectl apply -f deployment.yaml

新規に起動中

28

Serviceを作成して、これまで作成したPodを一つの名前に集約したサービスを作るとともに、外部からの接続をPodに接続する

Serviceの定義と作成

–次の内容でservice.yamlを作成

– Serviceを作成

Serviceの確認

Serviceの作成[1/3]

kind: ServiceapiVersion: v1metadata:

name: rest-api-servicespec: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 servicesNAME CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes 10.0.0.1 <none> 443/TCP 11hrest-api-service 10.0.0.51 <nodes> 8080:31372/TCP 1m

29

ブラウザーからServiceへの接続を確認

– NodeのIPを確認

–ブラウザーからアクセス

Deploymentの変更と更新

– コンテナイメージをv2に変更


$ minikube ip192.168.99.100

http://192.168.99.100:31372

apiVersion: apps/v1beta1kind: Deploymentmetadata:name: rest-api-dep

spec:replicas: 4template:metadata:labels:

app: my-rest-apispec:containers:


v2に変更

30

Deploymentの変更と更新

–更新

Deploymentの更新は、デフォルトでシステムがダウンしないように少しずつアップデートするローリングアップデートが用いられる

–更新の確認

Deploymentのロールバックと確認

–ロールバック

–確認


$ kubectl apply -f deployment.yamldeployment "rest-api-dep" replaced

$ curl 192.168.99.100:31372{"message":"Hello World!","version":"v2"}

$ kubectl rollout undo deployment/rest-api-depdeployment "rest-api-dep" rolled back

$ curl 192.168.99.100:31372{"message":"Hello World!","version":"v1"}

31

Deploymentを変更することでローリングアップデートは可能だが短時間に切り替えられない。 Blue/Green Deploymentの様な方法を取りたい場合はServiceを利用し切り換える方法がある

新規にDeploymentを作成

–次の内容でdeployment-v3.yamlを作成

–デプロイ

Serviceを利用したBlue/Green Deployment[1/2]


name: rest-api-dep-v3spec:


labels:app: my-rest-api-v3

spec:containers:


Deploymentの名前とタグをv3に変更

$ kubectl create –f deployment-v3.yaml

32

– Deploymentの確認

Serviceの変更と確認

– ServiceとPodの紐付けを行なうselectorの変更を行なう

–更新と確認

Serviceを利用したBlue/Green Deployment[2/2]

$ kubectl get deploymentNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGErest-api-dep 4 4 4 4 3hrest-api-dep-v3 4 4 4 4 23m

kind: ServiceapiVersion: v1metadata:

name: rest-api-servicespec: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.yamlservice "rest-api-service" configured$ curl 192.168.99.100:31372{"message":"Hello World!","version":"v3"}

5. その他

34

minikube startでエラーになったら

– Nodeを削除する

–上記でも解消しない場合は、”.minikube”ディレクトリを削除しminikubeを再度起動する

トラブルシューティング

$ minikube stop$ minikube delete$ minikube start

35

参考・引用元

WEBサイト

– Using Kubernetes on Google Container Enginehttps://www.slideshare.net/enakai/using-kubernetes-on-google-container-engine

– Dockerも始めました2 ～Kubernetes編～https://oss.sios.com/yorozu-blog/yorozu-20151216

– Dockerコンテナを管理するならKuberneteshttp://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

kubernetes超入門 with java

Technology