2020/08/23 Kubernetesを動かす
https://gyazo.com/2fe622d5bd563640a8e1c0c60598e45b
リソースの作成
GCPの準備
まずはk8sを動かす環境を用意する必要がある。
今回は「Kubernetes完全ガイド」にしたがって、GCPで動かしていく。
現在のマスターのバージョンは1.16.13-gke.1なのでこれを利用。
ノードの数は3
リージョンはasia-northeast1(日本/東京)のゾーン1
クラスターを作成するコマンドは
gcloud container clusters create <name> --cluster-version 1.16.13-gke.1 --zone asia-northeast1-a --num-nodes 3
次に認証情報を.kube/configに登録
gcloud container clusters get-credentials <name> --zone asia-northeast1-a
現在のコンテキストを確認する必要がある。
kubectl config current-context
コンテキストが間違いないことを確認。
今回はGCPで動かすのでGCPのプロジェクトが選択されればOK
クラスターが作成されていることがGCPのGUIで確認できる
https://gyazo.com/b62c549178a383b9cad577b1000ec795
コンテナの起動
マニフェストを利用してコンテナを起動させる。
形式はYAML。
code:sample-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: sample-pod
spec:
containers:
- name: nginx
image: nginx:1.18
リソースの作成
# kubectl create -f ./sample-pod.yaml
pod/sample-pod created
リソースが存在しない場合は成功する。
※後述するが、作成はapplyを利用する
GCPのGUIでワークロードタブからも確認できる。
https://gyazo.com/68c3601ea57f2e75ebc4e2ca6f1a1c89
Podの一覧を見る
kubectl get pods
https://gyazo.com/fe1daedbb6b14c3068a442870ce93a21
リソースの削除
# kubectl delete -f ./sample-pod.yaml
pod "sample-pod" deleted
リソースが存在する場合は成功する。
リソースのアップデート
kubectl apply -f sample-pod.yaml
applyを利用する。
差分がない場合はなにもしない。
リソースがない場合は作成する。
注意
リソースの作成はcreate、applyで出来る。
アップデートを行う際に、前に適用したマニフェストの情報を利用するが、
createでは作成されないため、不慮のエラーが起こり得る。
よって、createではなく、applyを使うべき。
https://gyazo.com/4038cbfdd8d6ea81ebd760754bbdb82e
https://gyazo.com/9eaecb8887150369a3067cfe1c596b24
Podsの詳細を見る
kubectl get pods sample-pod -o < wide | json >
jsonにはたくさんの情報が含まれている
イメージを抽出する場合、
spec.containers[].imageを指定する。
kubectl get pods sample-pod -o jsonpath="{.spec.containers[].image}"
マニフェスト
アノテーション
k8sではannotationやlabelといったメタデータが付与できる。
アノテーションとはシステムコンポーネントで利用するメタデータ。
いろいろな用途に使われている。
システムコンポーネントとして自動的に付与される。
yamlファイルに記述せずに作成を行っても、自動的に追加される。
https://gyazo.com/d66b0f610443f6b9d7ee416a80ba65f5
試しにsample-pod.yamlでリソース作成してみると
annotationsにlast-applied-configurationが追加されているのが確認できる。
AWSやGCPのような特定のサービスによって選択できるオプションの指定にも使われる。
label
labelとはリソースに対して付与することが出来る。
グルーピングすることで、管理がしやすくなる。
具体的なマニフェスト例
一つのマニフェストで複数のリソースを指定するには---を入力する。
code:sample-label.yaml
apiVersion: v1
kind: Pod
metadata:
name: sample-label1
labels:
label1: group1
label2: group-A
spec:
containers:
- name: nginx
image: nginx:1.18
---
apiVersion: v1
kind: Pod
metadata:
name: sample-label2
labels:
label1: group1
label2: group-B
spec:
containers:
- name: nginx
image: nginx:1.18
リソースの作成
kubectl apply -f sample-label.yaml
https://gyazo.com/9f971d7119a47efcadea1a7aabff4398
yamlファイルでlabelを付与してある。
sample-label1にはlabel1=group1 label2=groupA
sample-label2にはlabel1=group1 label2=groupAB
ラベルを使って絞り込みで表示してみる。
https://gyazo.com/ef82761190e534608bb88d8410a69be5
キーを指定してバリューを確認することも出来る
kubectl get pods -L label1, label2
https://gyazo.com/258cf27770509bdcda8a5bbff3d2eeac
注意
ラベルはレプリカセットでも利用するため、考えずにつけてしまうと問題が起こることがある。
pruneオプション
dockerでも出てくるprune
k8sでもでてくるprune
k8sでのpruneはマニフェストから削除されたリソースを検知して、リソースの削除を行う。
先程のsample-label.yamlとは別にsample-label2.yamlが存在するとする。
中身は番号が変化しただけ。
ディレクトリ内の2つのyamlでリソースを作成する。
※ファイルではなくディレクトリ名で指定し、-Rオプションをつける(再帰)
kubectl apply -f <dir>/ -R
https://gyazo.com/1d5ef81c8dce77c2edff2c530e6cbb80
実行すると4つのpodが立ち上がる。
sample-label2.yamlのみを削除し、もう一度ディレクトリで実行すると、
sample-label3とsample-label4がapplyされない。
その2つのpodが消えたことを検知し、現在のPodから削除してくれるのがpruneオプション
ラベルを使って、Applyしたマニフェストにないリソースを削除するので、ラベルには気をつける。
yamlファイルを置くディレクトリも気をつけなければ、一気に消えてしまう。
https://gyazo.com/48d6af58b685ed44217d546729995ba6
↑例) pruneを付けた場合と付けていない場合(sample-label2.yamlは消している)