Kubernetesクライアント
KubernetesのAPIと連携するコマンド
クラスタのステータス
クラスタのバージョンを確認する
kubectl version
クラスタの診断をする
kubectl get componentstatuses
Kubernetesのノードの表示
クラスタ上の全てのノードを表示する
kubectl get nodes
特定のノードについての詳しい情報をみる
kubectl describe nodes node-1
クラスタのコンポーネント
Kubernetes proxy
proxyのdaemonSetsオブジェクトを確認する
kubectl get daemonSets --namespace=kube-system kube-proxy
Kubernetes DNS
DNSのDeploymentオブジェクトを確認する
kubectl get deployments --namespace=kube-system kube-dns
DNSのServiceオブジェクトを表示する
kubectl get services --namespace=kube-system kube-dns
よく使うkubectlコマンド使い方
Kubernetesオブジェクトの操作でよく使うコマンド
Context
デフォルトのNamespaceを変えるContextを作る
kubectl config set-context my-context --namespace=mystuff
Contextを切り替える
kubectl config use-context my-context
Kubernetes APIオブジェクトの参照
現在のNamespace内のリソースの全てを表示
kubectl get <リソース名>
特定のリソースを表示
kubectl get <リソース名> <オブジェクト名>
特定のオブジェクトについて詳しい情報を表示
kubectl describe <リソース名> <オブジェクト名>
特定の
Kubernetesオブジェクトの作成・更新・削除
obj.ymlの設定に基づいてオブジェクトを作成・更新
kubectl apply -f obj.yml
obj.ymlに設定されたオブジェクトを削除する
kubectl delete -f obj.yml
指定したオブジェクトを削除
kubectl delete <リソース名> <オブジェクト名>
オブジェクトのLabel
barという名前のPodにcolor=redというラベルをつける
kubectl label pods bar color=red
barという名前のPodからcolorのラベルを削除する
kubectl label pods bar color-
デバッグ用のコマンド
実行中のコンテナのログを見る
kubectl logs <Pod名>
実行中のコンテナでコマンドをを実行する
kubectl exec -it <Pod名> -- bash
cpコマンドを使ってコンテナにファイルをコピー・コンテナからファイルをコピー
kubectl cp <Pod名>:/path/to/remote/file /path/to/local/file
Pod
Podはいくつかのコンテナをグループ化したもの。
PodはKubernetesが扱うコンテナグループの最小単位
Podの作成
Podを作成して実行する
動作中のPodのステータスはkubectl get podsで見れる
kubectl run kuard --image=gcr.io/kuar-demo/kuard-amd64:1
Podを削除する
kubectl delete deployments/kuard
Podを動かす
apiVersion: v1
kind: Pod
metadata:
name: kuard
spec:
containers:
- image: gcr.io/kuard-demo/kuard-amd64:1
name: kuard
ports:
- containerPort: 8080
name: http
protocol: TCP
上記のymlを用意して、Podを用意する
kubectl apply -f kuard-pod.yml
Podの一覧表示
クラスタ内で動いているPodの一覧を取得する
kubectl get pods
Podの詳細情報
指定したPodの詳細情報を取得する
kubectl describe pods kuard
Podの削除
指定したPodを削除する
kubectl delete pods/kuard
指定したファイルに基づいてPodを削除する
kubectl delete -f kuard-pod.yml
ポートフォワードを使用する
Kubernetesのマスタを経由してローカルホストからアクセスできるようにする
これでlocalhost:8080でアクセスできる
kubectl port-forward kuard 8080:8080
ログからの詳細情報の取得
Podのログにアクセスする
kubectl logs kuard
execを使用してコンテナ内でコマンド実行
kubectl exec kuard date
対話的な操作をする
kubectl exec -it kaurd ash
コンテナとローカル間でのファイル転送
コンテナからローカルマシンにファイルをコピー
kubectl cp <Pod名>:/captures/capture3.txt ./capture3.txt
ローカルマシンからコンテナにファイルをコピー
kubectl cp $HOME/config.txt <Pod名>:/config.txt
Liveness probe
apiVersion: v1
kind: Pod
metadata:
name: kuard
spec:
containers:
- image: gcr.io/kuar-demo/kuard-amd64:1
name: kuard
livenessProbe:
httpGet:
path: /healthy
port: 8080
initialDelaySeconds: 5
timeoutSeconds: 1
periodSeconds: 10
failureThreshold: 3
ports:
- containerPort: 8080
name: http
protocol: TCP
上記のymlを用意してPodを用意する
上記以外にも様々なヘルスチェックの種類がある
kubectl apply -f kuard-pod-health.yml
リソースの要求
下記のようにリソースの使い方を指定することができる
apiVersion: v1
kind: Pod
metadata:
name: kuard
spec:
containers:
- image: gcr.io/kuar-demo/kuard-amd64:1
name: kuard
resources:
requests:
cpu: "500m"
memory: "128Mi"
ports:
-containerPort: 8080
name: http
protocol: TCP
リソースの制限
apiVersion: v1
kind: Pod
metadata:
name: kuard
spec:
containers:
- image: gcr.io/kuar-demo/kuard-amd64:1
name: kuard
resources:
requests:
cpu: "500m"
memory: "128Mi"
limits:
cpu: "1000m"
memory: "256Mi"
ports:
- containerPort: 8080
name: http
protocol: TCP
VolumeとPodの組み合わせ
apiVersion: v1
kind: Pod
metadata:
name: kuard
spec:
volumes:
- name: "kuard-data"
hostPath:
path: "/var/lib/kuard"
containers:
- image: gcr.io/kuard-demo/kuard-amd64:1
name: kuard
volumeMounts:
- mountPath: "/data"
name: "kuard-data"
ports:
- containerPort: 8080
name: http
protocol: TCP
全てまとめて実行する
apiVersion: v1
kind: Pod
metadata:
name: kuard
spec:
volumes:
- name: "kuard-data"
nfs:
server: my.nfs.server.local
path: "/exports"
containers:
- image: gcr.io/kuar-demo/kuard-amd64:1
name: kuard
ports:
- containerPort: 8080
name: http
protocol: TCP
resources:
requests:
cpu: "500m"
memory: "128Mi"
limits:
cpu: "1000m"
memory: "256Mi"
volumeMounts:
- mountPath: "/data"
name: "kuard-data"
livenessProbe:
httpGet:
path: /healthy
port: 8080
initialDelaySeconds: 5
timeoutSeconds: 1
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 30
timeoutSeconds: 10
periodSeconds: 10
failureThreshold: 3
Label
Labelはオブジェクトを識別しグループ化するもの
Labelの適用
まずLabelをつけたDeployment(Podの集まり)を用意する
alpacaとbandicootというアプリケーションを本番用とテスト用を用意する
kubectl run alpaca-prod \
--image=gcr.io/kuar-demo/kuard-amd64:1 \
--replicas=2 \
--labels="ver=1,app=alpaca,env=prod"
kubectl run alpaca-test \
--image=gcr.io/kuar-demo/kuard-amd64:2 \
--replicas=1 \
--labels="ver=2,app=alpaca,env=test"
kubectl run bandicoot-prod \
--image=gcr.io/kuar-demo/kuard-amd64:2 \
--replicas=2 \
--labels="ver=2,app=bandicoot,env=prod"
kubectl run bandicoot-staging \
--image=gcr.io/kuar-demo/kuard-amd64:2 \
--replicas=1 \
--labels="ver=2,app=bandicoot,env=staging"
LabelをつけたDeploymentの一覧を、Label付きで取得する
kubectl get deployments --show-labels
補足として、作成したDeploymentを全て削除して後片付けしておく
kubectl delete deployments --all
Labelの変更
Labelの値を列で見たいときは、kubectl getに-Lオプションをつける
kubectl get deployments -L env
Labelの値の末尾に-をつけると、Labelを削除できる
kubectl label deployments alpaca-test 'env-'
Labelセレクタ
全てのPodをラベル付きで一覧表示するときはこう
kubectl get pods --show-labels
Labelで絞って一覧表示したいときはこう
kubectl get pods --selector="ver=2"
複数Labelをandで絞り込みたいときはカンマで繋いで指定する
kubectl get pods --selector="app=bandicoot,ver=2"
あるLabelが複数値のどれかに一致したPodを表示したいときはこう
kubectl get pods --selector="app in (alpaca,bandicoot)"
あるLabelが設定されているPodを一覧取得したいときはこう
kubectl get deployments --selector="env"
Service
Serviceオブジェクトは、PodをグルーピングするLabelを抽象化した概念
Serviceオブジェクト作成
kubectl runでDeploymentを作成し、kubectl exposeでServiceを作成する
kubectl run alpaca-prod \
--image=gcr.io/kuar-demo/kuard-amd64:1 \
--replicas=3 \
--port=8080 \
--labels="ver=1,app=alpaca,env=prod"
kubectl expose deployment alpaca-prod
kubectl run bandicoot-prod \
--image=gcr.io/kuar-demo/kuard-amd64:2 \
--replicas=2 \
--port=8080 \
--labels="ver=2,app=bandicoot,env=prod"
kubectl expose deployment bandicoot-prod
Serviceの一覧を取得する
kubectl get services -o wide
Labelがapp=alpacaのPodのうち一つ、名前を変数に格納する
ALPACA_POD=$(kubectl get pods -l app=alpaca \
-o jsonpath='{.items[0].metadata.name}')
先ほどのapp=alpacaのPod一つをlocalhost:48858でアクセス可能にしてみる
kubectl port-forward $ALPACA_POD 48858:8080
Readiness probe
Podがリクエストを受け付けられるかどうかを監視する仕組み
先ほどのDeploymentsにReadiness probeをつけてみる
まずはDeploymentsを編集する
kubectl edit deployments/alpaca-prod
下記のように編集する
３回連続でチェックに失敗すればPodはリクエストが受けられない状態と判断され、１回でもチェックが通ればリクエストを受けられると判断される
spec:
...
template:
...
spec:
containers:
...
name: alpaca-prod
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 2
initialDelaySeconds: 0
failureThreshold: 3
successThreshold: 1
Deploymentを再定義するとPodは再作成されるので、改めてport-forwardする
ALPACA_POD=$(kubectl get pods -l app=alpaca \
-o jsonpath='{.items[0].metadata.name}')
kubectl port-forward $ALPACA_POD 48858:8080
Readiness probeの動きを観察するには下記が便利
kubectl get endpoints alpaca-prod --watch
ReplicaSet
ReplicaSetはPodの数やPodのテンプレートを管理するもの
ReplicaSetの定義
以下はReplicaSet最小限の定義例
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: kuard
spec:
replicas: 1
template:
metadata:
labels:
app: kuard
version: "2"
spec:
containers:
- name: kuard
image: "gcr.io/kuar-demo/kuard-amd64:2"
ReplicaSetの作成
下記コマンドで上記で記述したReplicaSetを作成する
kubectl apply -f kuard-rs.yml
ReplicaSetが作成されるとPodが作成される
kubectl get pods
ReplicaSetの調査
ReplicaSetの状態を調査する場合はこのコマンド
kubectl describe rs kuard
PodからのReplicaSetの特定
下記コマンド後にownerReferencesの項目を見ると良い
kubectl get pods <Pod名> -o yaml
ReplicaSetに対応するPodの集合の特定
ReplicaSetに対応したPodの集合を得たい場合は-lコマンドで絞る
kubectl get pods -l app=kuard,version=2
ReplicaSetの手動スケール
ReplicaSetのファイルを設定し直さなくてもPodの数はアドホックに調整できる
kubectl scale replicasets kuard --replicas=4
設定ファイルを使う場合はReplicaSetを設定するymlファイルの該当項目を下記に書き換える
spec:
replicas: 3
ymlファイル書き換え後に設定ファイルを反映させる
kubectl apply -f kuard-rs.yml
設定が反映されたことを確認する
kubectl get pods
ReplicaSetのオートスケール
CPU使用率に対応したオートスケール設定はこう
kubectl autoscale rs kuard --min=2 --max=5 --cpu-percent=80
オートスケールの設定を確認したいときはhorizontalpodautoscalersを確認する
kubectl get hpa
ReplicaSetの削除
ReplicaSetを削除する
kubectl delete rs kuard
ReplicaSetが削除されるとPodも削除される
kubectl get pods
DaemonSet
ReplicaSetと同様にPodのレプリカを作る仕組み
ここがわかりやすい
ReplicaSetは、各Kubernetes Node上に合計でx個のPodをNodeのリソース状況に合わせて配置していきます。
そのため、各Node上のPodの数が必ず等しいとも限りませんし、各Node上に確実に配置されるとも限りません。
一方DaemonSetは、全nodeに1 podずつ配置するリソースとなっています。
そのため、レプリカ数などは指定できませんし、2 podずつ配置するといったこともできません。
DaemonSetの作成
クラスタ内のノードのnamespace=kube-system配下にfluentdを仕込む
まずは設定ファイルを用意する
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: fluentd
namespace: kube-system
labels:
app: fluentd
spec:
template:
metadata:
labels:
app: fluentd
spec:
containers:
- name: fluentd
image: fluent/fluentd:v0.14.10
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
設定をクラスタに反映させる
kubectl apply -f fluentd.yml
DaemonSetの状態を見たいときは
kubectl describe daemonset fluentd --namespace=kube-system
DaemonSetは、全nodeに1 podずつ配置するリソース
kubectl get pods -o wide --all-namespaces
Nodeへの配置
特定のLabelがついたNodeにのみDaemonSetを配置する
まずはNodeにLabelを配置する
kubectl label nodes docker-for-desktop ssd=true
確認
kubectl get nodes --show-labels
ちなみにLabelを削除したいときはこう
kubectl label nodes docker-for-desktop ssd-
ここで、DaemonSetを指定したLabelのついたNodeに配置する
apiVersion: extensions/v1beta1
kind: "DaemonSet"
metadata:
name: nginx-fast-storage
labels:
app: nginx
ssd: "true"
spec:
template:
metadata:
labels:
app: nginx
ssd: "true"
spec:
nodeSelector:
ssd: "true"
containers:
- name: nginx
image: nginx:1.10.0
DaemonSetがちゃんと配置されたか見る
kubectl get pods --all-namespaces -o wide
Job
デーモンをたてずにコンテナを実行をするためのオブジェクト
一回限りの実行
kubectlを使ってJobを発行する
--restart=OnFailuerはkubectlにJobオブジェクトを作成するように支持するオプション
kubectl run -i oneshot \
--image=gcr.io/kuar-demo/kuard-amd64:1 \
--restart=OnFailure \
-- --keygen-enable \
--keygen-exit-on-complete \
--keygen-num-to-gen 10
Jobを削除する
kubectl delete jobs oneshot
設定ファイルからJobを発行する
apiVersion: batch/v1
kind: Job
metadata:
name: oneshot
labels:
chapter: jobs
spec:
template:
metadata:
labels:
chapter: jobs
spec:
containers:
- name: kuard
image: gcr.io/kuar-demo/kuard-amd64:1
imagePullPolicy: Always
args:
- "--keygen-enable"
- "--keygen-exit-on-complete"
- "--keygen-num-to-gen=10"
restartPolicy: OnFailure
実行する
kubectl apply -f job-oneshot.yml
Job oneshotを表示する
kubectl describe jobs oneshot
作成されたPodのログでJobの結果を確認できる
kubectl logs oneshot-*****
では、Jobの処理が失敗したときの挙動を見てみよう
exit-codeが0以外になるようにして意図的にJobが失敗するように設定する
...
spec:
template:
spec:
containers:
...
args:
- "--keygen-enable"
- "--keygen-exit-one-complete"
- "--keygen-exit-code=1"
- "--keygen-num-to-gen=3"
上記のJobを改めて発行後にしばらくしたら下記のコマンドを実行
kubectl get pods -a -l job-name=oneshot
Podの起動リトライが複数実行されていることが確認できる
リトライにリソースを使われないように、リトライごとに再起動の遅延は大きくなる
それでは別の実験をするために一旦該当Jobを削除する
kubectl delete jobs oneshot
設定ファイルのrestartPolicyをOnFailureからNeverに変更して、Jobを再起動し、様子を見る
kubectl apply -f job-oneshot.yml
kubectl get pods -a -l job-name=oneshot
restartPolicyをNeverに設定すると、Podの失敗を検知すると代わりのPodを作成するようになる
ただしこの方法はPodのゴミがNodeの上に際限なく残ってしまうので非推奨
閾値分成功するまで並列に実行
Jobを並列実行することができる
parallelismで並列数を指定し、completionsで実行するべき回数を指定する
apiVersion: batch/v1
kind: Job
metadata:
name: parallel
labels:
chapter: jobs
spec:
parallelism: 5
completions: 10
template:
metadata:
labels:
chapter: jobs
spec:
containers:
- name: kuard
image: gcr.io/kuar-demo/kuard-amd64:1
imagePullPolicy: Always
args:
- "--keygen-enable"
- "--keygen-exit-on-complete"
- "--keygen-num-to-gen=10"
restartPolicy: OnFailure
設定ファイルからJobを実行し、様子をみる
kubectl apply -f job-parallel.yml
kubectl get pods -w
ConfigMap
設定情報を扱うためのオブジェクト
ConfigMapの作成
下記のような設定用のファイルがあったとする
parameter1 = value1
parameter2 = value2
上記の設定を内包するConfigMapを作成する
kubectl create configmap my-config \
--from-file=my-config.txt \
--from-literal=extra-param=extra-value \
--from-literal=another-param=another-value
作成したConfigMapを見る
kubectl get configmaps my-config -o yaml
ConfigMapの使用
先に作ったConfigMapを実際に使用してみる
my-configを内包したPodの設定ファイルを作る
apiVersion: v1
kind: Pod
metadata:
name: kuard-config
spec:
containers:
- name: test-container
image: gcr.io/kuar-demo/kuard-amd64:1
imagePullPolicy: Always
command:
- "/kuard"
- "$(EXTRA_PARAM)"
env:
- name: ANOTHER_PARAM
valueFrom:
configMapKeyRef:
name: my-config
key: another-param
- name: EXTRA_PARAM
valueFrom:
configMapKeyRef:
name: my-config
key: extra-param
volumeMounts:
- name: config-volume
mountPath: /config
volumes:
- name: config-volume
configMap:
name: my-config
restartPolicy: Never
Pod設定ファイルを適用
kubectl apply -f kuard-config.yml
Podを公開する
kubectl port-forward kuard-config 8080
ブラウザでアクセスすると、ConfigMap経由で追加した環境変数ANOTHER_PARAMとEXTRA_PARAMが追加されていることが確認できる
また、my-config.txtがファイルシステム/configにマウントされていることも確認できる
Secret
ConfigMapに設定できない秘匿情報を管理するオブジェクト
Secretの作成
ConfigMapでは扱えない機密情報を扱うためのオブジェクト
秘匿ファイルとして下記TLSファイルを用意する
curl -o kuard.crt https://storage.googleapis.com/kuar-demo/kuard.crt
curl -o kuard.key https://storage.googleapis.com/kuar-demo/kuard.key
kuard-tlsというSecretオブジェクトを作成する
kubectl create secret generic kuard-tls \
--from-file=kuard.crt \
--from-file=kuard.key
下記コマンドで詳細を確認する
kubectl describe secrets kuard-tls
Secretの使用
上記で作成したkuard-tlsを/tlsにマウントしたPodを作る
apiVersion: v1
kind: Pod
metadata:
name: kuard-tls
spec:
containers:
- name: kuard-tls
image: gcr.io/kuar-demo/kuard-amd64:1
imagePullPolicy: Always
volumeMounts:
- name: tls-certs
mountPath: "/tls"
readOnly: true
volumes:
- name: tls-certs
secret:
secretName: kuard-tls
kubectl apply -f kuard-secret.yml
Podを公開する
kubectl port-forward kuard-tls 8443:8443
https://localhost:8443へ警告を無視してアクセスすると、ファイルシステム/tlsが存在することが確認できる
プライベートDockerレジストリ
プライベートDockerレジストリ用のSecretオブジェクトを作成する
kubectl create secret docker-registry my-image-pull-secret \
--docker-username=<ユーザー名> \
--docker-password=<パスワード> \
--docker-email=<メールアドレス>
上記Secretを利用してプライベートDockerレジストリにアクセスする設定ファイルはこう
apiVersion: v1
kind: Pod
metadata:
name: kuard-tls
spec:
containers:
- name: kuard-tls
image: gcr.io/kuar-demo/kuard-amd64:1
imagePullPolicy: Always
volumeMounts:
- name: tls-certs
mountPath: "/tls"
readOnly: true
imagePullSecrets:
-name: my-image-pull-secret
volumes:
- name: tls-certs
secret:
secretName: kuard-tls
Deployment
DeploymentはReplicaSetをリリースするための仕組み
Deployment実行
Podを実行するコマンドは内部的にDeploymentオブジェクトを作成している
kubectl run nginx --image=nginx:1.7.12
上記コマンドで作成されたDeploymentオブジェクトを確認する
kubectl get deployments nginx
Deploymentのスケール
DeploymentはReplicaSetを管理下に置いている
DeploymentがスケールするとReplicaSetもスケールする
kubectl scale deployments nginx --replicas=2
ReplicaSetの一覧を表示するとスケールされたことが確認できる
kubectl get replicasets --selector=run=nginx
しかしReplicaSetをスケールダウンを試みてもスケールダウンは実行されない
kubectl scale replicasets nginx-1128242161 --replicas=1
kubectl get replicasets --selector=run=nginx
これはDeploymentがReplicaSetを管理下に置いている、トップレベルのオブジェクトであるため
Deploymentの作成
先ほど作成したDeploymentをディスク上のymlファイルに保存する
kubectl get deployments nginx --export -o yaml > nginx-deployment.yml
nginx-deployments.ymlの中身をみるとReplicaSetオブジェクトと中身が似ているが、Podの管理に加えロールアウトの管理をするStrategyオブジェクトをもつ
Deploymentの管理
先ほどのDeploymentオブジェクトの設定ファイル経由でスケールさせる
spec:
replicas: 3
kubectl apply -f nginx-deployment.yml
スケールしたことを確認する
kubectl get deployments nginx
設定ファイルを更新してコンテナのイメージを更新する
containers:
- image: nginx:1.9.10
imagePullPolicy: Always
kubectl apply -f nginx-deployment.yml
Deploymentを更新すると、新しいバージョンのロールアウトが実行されるので、その様子を見る
kubectl rollout status deployments nginx
ロールアウトすると旧ReplicaSetと新ReplicaSetが管理下に置かれる
kubectl get replicasets -o wide
ロールアウトを途中で止めるには下記コマンドを実行する
kubectl rollout pause deployments nginx
ロールアウト停止中にまたロールアウトを再開したいときは下記コマンドを実行する
kubectl rollout resume deployments nginx
ロールアウト履歴
ロールアウトの履歴は下記コマンドで確認できる
kubectl rollout history deployments nginx
指定リビジョンの詳細を見るには下記コマンド
kubectl rollout history deployment nginx --revision=2
ロールアウトをロールバックしたいときはこう
kubectl rollout undo deployments nginx
ReplicaSetのレプリカ数を見るとちゃんとロールアウトとロールバックが実行されていることが確認できる
kubectl get replicasets -o wide
特定のリビジョンにロールバックしたいときはこう
kubectl rollout undo deployments nginx --to-revision=3
Deploymentの削除
kubectl delete deployments nginx
kubectl delete -f nginx-deployments.yml
どちらの場合でもDeploymentを削除すると管理下のサービスも削除される