Yuuniworks Notes

# Kubernetes (opens new window)

# 環境構築メモ

  1. クラスタ作成
  2. gcloud, kubectl の認証設定
  3. ブログ (opens new window)を参考に証明書の自動取得環境を設定
  4. 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 段階の処理が必要となる。

  1. PV を作成
  2. PVC を作成
  3. Pod.spec.volumes において PVC を指定
  4. 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: 通信をどのようにサービスにつなげるか、というルール。

# セットアップ

ブログ (opens new window)を参考に設定する。

  • 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 が払い出せないなどの不具合が出る。