Kubernetes
環境構築メモ
- クラスタ作成
gcloud
,kubectl
の認証設定- ブログを参考に証明書の自動取得環境を設定
- secret のアップロード(Googie Drive に原本あり)
コマンド
認証
gcloud auth login
gcloud config set project ${PROJECT_ID}
gcloud container clusters get-credentials ${CLUSTER_NAME} # kubectlの認証
情報の取得
# TYPE = (node | svc | deploy | pod)
kubectl get ${TYPE}
-o yaml
-l KEY=VALUE # tagで検索
kubectl logs ${POD_NAME}
kubectl describe ${TYPE} ${NAME}
kubectl top node
cli でのデプロイ等
# deploy from images
kubectl run ${DEPLOY_NAME} \
--image ${IMAGE_NAME}
[--port 80] \
[--requests='cpu=0'] \
[--rm] \
[-it] \
[${COMMAND}] # 指定した場合、DockerfileのCMDは無視される
# create service (expose deploy)
kubectl expose deployment ${DEPLOY_NAME}
--port=80
--type=LoadBalancer
--load-balancer-ip="104.199.216.116"
# scale deployment
kubectl scale deployment ${DEPLOY_NAME} --replicas=4
kubectl autoscale deployment ${DEPLOY_NAME} --min=1 --max=3
# delete
kubectl delete ${TYPE} ${NAME}
YAML ファイルの操作
kubectl apply -f *****.yml
kubectl delete -f *****.yml
# edit yaml
kubectl edit ${TYPE} ${NAME}
Pod の操作
kubectl exec ${POD_NAME} env
kubectl exec ${POD_NAME} ls /
kubectl exec -it ${POD_NAME} bash
クラスタの操作
gcloud container clusters create \
--machine-type custom-1-1024 \
--num-nodes 1 \
--disk-size 10 \
${CLUSTER_NAME}
gcloud container clusters resize --size 2 ${CLUSTER_NAME}
gcloud container clusters delete ${CLUSTER_NAME}
ローカル環境との接続
# port-forward
kubectl port-forward ${POD_NAME} 5432:5432
# copy files
kubectl cp ${POD_NAME}:/tmp/foo /tmp/bar
Volumes
GCE Persistent disk を使うためには下記の 4 段階の処理が必要となる。
- PV を作成
- PVC を作成
- Pod.spec.volumes において PVC を指定
- Pod.spec.containers[].volumeMounts で、上記の Volume とマウントポイントを指定
- https://kubernetes.io/docs/concepts/storage/persistent-volumes/
- https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/
Persistent Volume
ボリューム自身(ディスクなど)。Pod のライフサイクルとは分離している。
Persistent Volume Claim
ボリュームの要件。Pod が Node のリソースを消費するように、PVC は PV を消費する。
Ingress
機能
- バーチャルホスト
- TLS 通信を終端
- ロードバランサ
構成要素
- Ingress Controller: HTTP エンドポイント/ロードバランサとして機能する
- Ingress Resource: 通信をどのようにサービスにつなげるか、というルール。
セットアップ
ブログを参考に設定する。
- Service の spec.type は NodePort にする
- Deployment に
ReadinessProve
を書いておかないと起動に失敗する。 - Ingress が Readiness を確認するまでに 5 ~ 10 分くらいかかる。その間、502 や 404 エラーが表示される。
- Virtual Host を使った場合、当てはまるルートがない場合は default backend という kube-system ネームスペースに用意された Pod に転送される(404 エラーを返す)
Helm
helm は、kubernetes のクライアントサイドのパッケージマネージャ。 下記の二つからなる。あらかじめバイナリをダウンロードし、パスを通しておくこと。
- helm: クライアントサイド
- Tiller: サーバサイド
# kube-systemネームスペースに、tillerというサービスアカウントを作成
kubectl create serviceaccount tiller --namespace kube-system
# tillerアカウントにcluster-adminの権限をバインドする(与える)
kubectl create clusterrolebinding tiller-binding `
--clusterrole=cluster-admin `
--serviceaccount=kube-system:tiller
# Tiller(helmのサーバサイドコンポーネント)を作成し、アップデートする
helm init --upgrade --service-account tiller
Health check
- Liveness prove Check if pods lives. if not, pods restarted.
- Readiness prove Check if pod is ready. if not, traffic is not sent to pods until it is ready.
その他
- Network Tier は Tokyo Region ではまだ使えない。使うと kubenetes でロードバランサの IP が払い出せないなどの不具合が出る。