初心者による初心者のためのKubernetesハンズオン

研究室内で行ったKubernetesハンズオン資料です。
対象者はKubernetesに触り始めたばかりの人の資料なので、永続化などは範囲外となっています。
また、概念などについてはあまり詳しく触れていないので、他の記事やKubernetes公式のドキュメント等を参考にしてください。

Transcript

1. 初心者による初心者のための
 Kubernetesハンズオン 2018/03/02 @uutarou10 1
2. ご注意 • 初回なのでそんなに難しいことはしません • 少し触ったことがあるくらいの人には物足りない可能性大です • YAMLを書くのでお好みのエディタを用意しておいてください • k8sの概念の詳しい解説は前の発表の資料等を参考にしてください
 (このスライドではあまり詳しく触れません) • わからないことがあったら適宜止めてくれて大丈夫です(答えられるとは言ってない) 2
3. 本日のお題 • k8s上でWordPressをイチから動かして
 特定のドメインでアクセス可能にする 3
4. 準備編
5. kubectl • 基本的にk8sは「kubectl」から操作を行う 5 $ kubectl version • 導入がまだの人は公式サイトにある手順よりインストール
 https://kubernetes.io/docs/tasks/tools/install-kubectl/ • 「Enabling shell autocompletion」(コマンド補完の有効化)は任意
 やっておくと捗るのでオススメです。

6. ClusterとContextの設定 • kubectlコマンドが操作するクラスタを指定する設定 • 複数のContextを設定しておいて切り替えて使うことができる
 (例: 研究室のクラスタとGKEを切り替えて使う) 6 $ kubectl config set-cluster t-lab --server=↩︎
 http://192.168.189.100:8080 $ kubectl config set-context t-lab --cluster=t-lab $ kubectl config use-context t-lab
7. ClusterとContextの設定 • 1行目
 kubectlに研究室のクラスタを「t-lab」という名前で登録 • 2行目
 kubectlに「t-lab」というContextを作って1行目で作ったクラスタを
 使うように指定 • 3行目
 「t-lab」コンテキストを使って作業する設定に変更した • これらの設定は「~/.kube/config」に書き込まれている 7
8. 設定できたか確認 • 実際に研究室のクラスタに接続できるか確認してみる
 (内部ネットワークに接続していることを確認!) 8 $ kubectl get node • Clusterに接続されているNode(マシン)が表示されれば成功 NAME STATUS ROLES AGE VERSION
 kube-01 Ready <none> 280d v1.5.2
 kube-03 Ready <none> 1d v1.5.2
 kube-04 Ready <none> 280d v1.5.2 3台のNodeがClusterに接続されていることがわかる
9. namespaceの作成 • k8sでは「namespace」という概念で環境を分割する • 本日のハンズオンは自分のユーザー名のnamespace上で作業します 9 $ kubectl create namespace <ユーザー名>
 namespace "<ユーザー名>" created • Contextがデフォルトで使うnamespaceを変更 $ kubectl config set-context t-lab --namespace=<ユーザー名>
10. namespaceの作成 • なにも設定しないと「default」namespaceが使われる • コマンド実行時に都度指定したい場合は… 10 $ kubectl get pod --namespace=uutarou $ kubectl get pod -n uutarou
11. YMLの文法確認 • k8sではYMLやJSONで書かれたマニフェストを
 用いて操作を行うのが一般的 11 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx:latest key: value 字下げでインデントを表す(tab使用不可) 「-」 で配列を表す
12. 準備編おわり
13. 本編
14. WordPressの構成 • WordPressはPHP製 • DBはMySQLを使用 • WordPressのDocker Image(WP本体 ＋ httpd)とMySQLのDocker Image を組み合わせて使用する(いずれも公式イメージ) 14
15. 操作の流れ • k8sはYML形式で書かれたマニフェスト(リソースの構成を記したファイル) をkubectlコマンドを用いて送信することで各種操作を行う • 送信に用いるコマンドは 15 $ kubectl create -f hoge.yml オブジェクトを作成するときはcreateですが、
 他にもreplace(既存のリソースの置き換え)などもあります。 • 送信される前にバリデーションが入るので気軽に試していきましょう!
16. MySQLを立てる(Deployment) • MySQLを含むDeploymentを作成する 16 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: mysql 使用するAPIのバージョンを指定する。
 これがあることで、k8sのバージョンが上がっても
 互換性を維持する事ができる。詳しくはAPI Doc 作成するリソースを指定。大文字から始まる。 リソースに付与する情報(メタデータ)を指定 nameは必須。他にもlabels(後述)なども指定できる。 ここまでは各リソースで共通の部分なので覚えておきましょう!
17. 17 spec: replicas: 1 template: metadata: name: mysql labels: app: wordpress role: database spec: containers: - image: mysql name: mysql env: - name: MYSQL_ROOT_PASSWORD value: dempagumi (前スライドの続き) specの中にリソースの構造を宣言していく replicasにはPodの数を指定する • Podは1つ以上のコンテナから成る k8s上の最小単位 • replicasはそのPodの複製を何個
 作るかを指定する • 複数作って負荷を分散したりできる • 今回は永続化してない都合上1個で 作成する(詳しく知りたい人は終了後にでも)
18. 18 spec: replicas: 1 template: metadata: name: mysql labels: app: wordpress role: database spec: containers: - image: mysql name: mysql env: - name: MYSQL_ROOT_PASSWORD value: dempagumi (前スライドの続き) templete以下にPodの構成を宣言する Podのマニフェストと同じ書き方 metadata以下にはPodのmetadataを宣言 labelsには好きなkey/valueを設定できる これはあとで使うのでとりあえずこれで。 spec.containersにはPodに含むDockerImageを指定。 imageはmysqlを指定。
 DockerHub以外からPullするときはフルパスで書く。 env以下にはコンテナの環境変数を指定する。 MYSQL_ROOT_PASSWORDにdempagumiと指定。
 (皆様もお好きな値にしてみてね⚡)
19. MySQLを立てる(Deployment) • 作ったYMLを適当な名前(e.g. mysql-deployment.yml)で保存 19 $ kubectl create -f mysql-deployment.yml • 実際にdeployment・podができたか確認してみる $ kubectl get deployment
 NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
 mysql 1 1 1 1 1h $ kubectl get pod
 NAME READY STATUS RESTARTS AGE
 mysql-cd8fd7c4f-gxxwh 1/1 Running 0 58m
20. MySQLを立てる(Service) • 先ほど立てたMySQLを後ほど立てるWordPressから使いたい
 →WordPressからMySQLにアクセスできる必要がある • Serviceを作る • これにより、クラスタ内のDNSで名前解決ができるようになる 20
21. 21 apiVersion: v1 kind: Service metadata: name: mysql spec: ports: - port: 3306 targetPort: 3306 selector: app: wordpress role: database 今回はv1なので要注意 外部から見えるポート番号(port)と
 Pod内のポート番号(targetPort)を指定。 portsなので複数も可。 今回はMySQLの標準のポートだけ。 ここが大事! どのPodを対象とするかをlabelを使って指定する。 appがwordpressでroleがdatabaseのPodが対象になる。 (さっき作ったMySQLのPodのmetadataを見直してみよう。)
22. MySQLを立てる(Service) • 再び適当な名前(e.g. mysql-service.yml)で保存して、
 リソースを作成してみる(Hint: createを使う) 22 • サービスができているか確認してみる(Hint: getを使う) $ kubectl $ kubectl
23. MySQLを立てる(Service) • 再び適当な名前(e.g. mysql-service.yml)で保存して、
 リソースを作成してみる(Hint: createを使う) 23 • サービスができているか確認してみる(Hint: getを使う) $ kubectl create -f mysql-servece.yml $ kubectl get service 何らかの情報を取ってきたいときは
 だいたいgetなので覚えておくと楽。 (pod/service/deployment/namespace/etc...)
24. MySQL終わり あと半分とちょこっと 休憩する?
25. WordPress本体を立てる • 基本的にはMySQLと同じでDeploymentとServiceを作る • 疲れてきただろうしサクサクいきます 25
26. 26 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: wordpress spec: replicas: 1 template: metadata: labels: app: wordpress role: web spec: containers: - image: wordpress name: wordpress env: - name: WORDPRESS_DB_HOST value: mysql - name: WORDPRESS_DB_PASSWORD value: dempagumi appはwordpressで、role(役割)はwebと指定してみた。 Docker Imageは公式のwordpressのものを使用 DB_HOSTにはMySQLのService名を指定 DB_PASSWORDはDeploymentを作った時に
 envで指定したものを選択
27. WordPress本体を立てる • 作ったYMLを適当な名前(e.g. wordpress-deployment.yml)で保存 27 $ kubectl create -f wordpress-deployment.yml • 実際にdeployment・podができたか確認してみる $ kubectl get deployment
 NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
 mysql 1 1 1 1 1h
 wordpress 1 1 1 1 1h $ kubectl get pod
 NAME READY STATUS RESTARTS AGE
 mysql-cd8fd7c4f-gxxwh 1/1 Running 0 58m
 wordpress-c8d645865-ps9hm 1/1 Running 0 1h 増えてる
28. 28 apiVersion: v1 kind: Service metadata: name: wordpress spec: ports: - port: 80 targetPort: 80 selector: app: wordpress role: web Webサーバーは80番で立っているのでtargetPort: 80 selectorを使って先ほどのPodを指定
29. WordPress本体を立てる • 適当な名前(e.g. wordpress-service.yml)で保存して、
 リソースを作成してみる。 • もうコマンド書かなくていいよね? • Serviceが作られているか確認してみる。 • もうコマンド書かなくていいよね? 29
30. WordPress本体も終わり
31. 実際にWordPressに接続してみる • Pod一覧からWordPress本体が動いているPodの名前をコピーしておく • port-forwardを使って接続してみる 31 $ kubectl port-forward wordpress-c8d645865-ps9hm 8080:80 • Podの80番ポート(HTTP)を手元の8080番からアクセスできるように
 ポートフォワードしてくれる • 手元のブラウザでhttp://localhost:8080/にアクセスしてみる
33. 実際にWordPressに接続してみる • 開く事が確認できたらとりあえずOK
 ターミナルはCtrl+Cで止めておく • Podの中を直接見たいときに便利なので覚えておくと役に立つかも
 (e.g. MySQLのPodのポートを転送すれば手元のmysqlコマンドからクエリ叩いたりとか) 33
34. 特定のhostでアクセスできるようにする • 特定のアドレスでアクセスできるようにします • e.g. http://wp.k8s.internal.t-lab.cs.teu.ac.jp のような感じ。 34
35. 特定のhostでアクセスできるようにする • Ingressというリソースを使う • Nodeに立っているNginxの設定を書き換えてVirtualHostで適切な Serviceに対して転送(Reverse Proxy)してくれる。 • Ingress自体はHTTP(S)を抽象化したものでしかなく、クラスタによっ て実装が異なる。GKEはMaglevというものが使われているらしい。 35
36. 36 apiVersion: extensions/v1beta1 kind: Ingress metadata: name: wordpress spec: rules: - host: uutarou.k8s.internal.t-lab.cs.teu.ac.jp http: paths: - backend: serviceName: wordpress servicePort: 80 host名を指定 wordpressという名前のServiceの80番を割り当てる
37. 特定のhostでアクセスできるようにする • 適当な名前(e.g. ingress.yml)で保存して、kubectl createコマンドを
 使ってリソースを作成する 37 $ kubectl create -f ingress.yml • 先ほどマニフェストの中で指定したhostにブラウザからアクセスしてみる • 表示されたかな?
38. 悲しいお知らせ • 実は今回永続化について一切取り扱ってません… • なのでPodを再起動するとデータが消えます • 試しにMySQLのPodを殺してみる 38 $ kubectl delete pod -l role=database ちなみに、-lオプションを使うと
 ラベルで絞り込んで各種操作ができる
40. 悲しいお知らせ • データベースが消えて接続できなくなった • 永続化の方法についてはこの後のおまけと第2回以降で。 40
41. 本編終わり!
 お疲れ様でした☕
42. 補足とおまけ
43. minikube • 自分でClusterを用意するにはGKE(Google Kubernetes Engine)等の
 クラウドサービスを用いるかローカル環境に構築する方法がある • 自分でVMを立てるなどしても可だが、minikubeというツールが存在する • KVM or VirtualBox上にVMを作成、Cluster構築を手軽に行える • Core m3のMacBook上でも動いたので割と軽量? • 単一Nodeで構成される為複数のNodeが使いたい場合は別の方法を用いる必要が ある • 複数NodeのClusterを構築してくれるツールも存在(e.g. kubespray)する 43
44. Dashboard • 実はDashboardというWebUIがk8sにはある 44
45. Dashboard • PodやServiceの一覧・削除 • リソースの使用状況 • 既存のリソースのYML見る • etc... 45
46. 環境変数について • DBのパスワードやホスト名はできればベタ書きしないで別でまとめて
 管理したい • WPのPodとMySQLのPodでDBのパスワードは1箇所で管理して
 各Podから参照した方がスマートだよね? • ConfigMap/Secretというリソースを使う • いずれもkeyとvalueを宣言しておけるもので、Podを作る際に参照する
 ことができる • 違いはシークレットな情報かそうではないか 46
47. 永続化について • PersistentVolume(PV)/PersistentVolumeClaim(PVC)というリソースを
 用いる事で永続化が行える • replicasを1に指定していたのは、Volumeを使っていないのでPod毎に
 異なるデータを持っている状態にあった為 47
48. 今日作ったものの消し方 • kubectl deleteで消せる 48 $ kubectl delete ingress wordpress #名前を指定して消す
 $ kubectl delete service -l app=wordpress #lオプションでラベルで絞る
 $ kubectl delete deployment -l app=wordpress
49. マニフェストファイル • 本日使用したマニフェストファイルは
 https://github.com/uutarou10/k8s-wordpress • master: PersistentVolume/PersistentVolumeClaimを使った永続化付き
 no-persistent: 本日使用したものと全く同じもの(永続化なし) 49
50. 参考資料 • Kubernetes | Production-Grade Container Orchestration
 https://kubernetes.io/ • WEB+DB PRESS Vol.99 特集3 • Software Design 2018年3月号 第2特集 50