AWS 上の OpenShift (4 系) の cluster を一時停止する方法
『IT自動化の力でビジネス加速を全ての企業に』
”IT自動化の専門会社”、リアルグローブ・オートメーティッド(RGA)の技術ブログ編集部の水谷です。本日もRGAの技師がまとめた技術情報を読者の皆様にお届けしていきます！
RGAでは Red Hat社 が提供するコンテナオーケストレーションツール「OpenShift 」を利用したインフラ基盤環境の構築支援やコンテナアプリケーションの開発支援を提供しています。OpenShift は、直接 Kubernetes を利用する場合に比べ、 GUI が整備されているため扱いやすく、コンテナ運用に関する様々な便利機能が追加されているので、コンテナ基盤の運用担当者にとって、大変有用なツールであると思います。
今回は RGA の技師がそんな OpenShift を使った検証作業において遭遇した「ふとした疑問」について調査した記録を、記事にしてみました。
――――――――――――――――――――――――――――――――――
OpenShift (4 系) の Cluster について、作成と削除はデフォルトのコマンドでサポートされており、create や destroy コマンドで行えます。しかし、一時的な停止については同様な手順で行えず、例えば stop コマンドのようなものは存在しません。
一時停止が必要な場面が多くあるわけではありませんが、検証作業をしているときに「停止して、作業を延期する」といったことがしたい場合もあります。
そこで、今回の記事では公式ブログを参考に、Cluster の停止と再起動方法についてまとめてみます。
Cluster の一時停止
上記のように、OpenShift には Cluster を一時停止させるデフォルトのコマンドが存在しません。今回は Cluster を停止させる方法、再起動させる方法を合わせて「Cluster を一時停止させる手順」としてまとめてみたいと思います。
以下のページを参考にしておりますので、合わせてご参照ください。
Enabling OpenShift 4 Clusters to Stop and Resume Cluster VMs
なお、このマニュアルでは 「OpenShift を AWS 上でインストールしている。」ことを前提とします。
また、以下の環境を想定しています。
OpenShift version 4.2.14
AWS 上に OpenShift を IPI インストール
Cluster の停止方法
停止には以下のスクリプトを実行します。使用する yaml ファイルについては、上記の公式ブログから引用しています。
cat << 'EOF' >$HOME/kubelet-bootstrap-cred-manager-ds.yaml.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: kubelet-bootstrap-cred-manager
namespace: openshift-machine-config-operator
labels:
k8s-app: kubelet-bootrap-cred-manager
spec:
replicas: 1
selector:
matchLabels:
k8s-app: kubelet-bootstrap-cred-manager
template:
metadata:
labels:
k8s-app: kubelet-bootstrap-cred-manager
spec:
containers:
- name: kubelet-bootstrap-cred-manager
image: quay.io/openshift/origin-cli:v4.0
command: ['/bin/bash', '-ec']
args:
- |
#!/bin/bash
set -eoux pipefail
while true; do
unset KUBECONFIG
echo "---------------------------------"
echo "Gather info..."
echo "---------------------------------"
# context
intapi=$(oc get infrastructures.config.openshift.io cluster -o "jsonpath={.status.apiServerInternalURI}")
context="$(oc --config=/etc/kubernetes/kubeconfig config current-context)"
# cluster
cluster="$(oc --config=/etc/kubernetes/kubeconfig config view -o "jsonpath={.contexts[?(@.name==\"$context\")].context.cluster}")"
server="$(oc --config=/etc/kubernetes/kubeconfig config view -o "jsonpath={.clusters[?(@.name==\"$cluster\")].cluster.server}")"
# token
ca_crt_data="$(oc get secret -n openshift-machine-config-operator node-bootstrapper-token -o "jsonpath={.data.ca\.crt}" | base64 --decode)"
namespace="$(oc get secret -n openshift-machine-config-operator node-bootstrapper-token -o "jsonpath={.data.namespace}" | base64 --decode)"
token="$(oc get secret -n openshift-machine-config-operator node-bootstrapper-token -o "jsonpath={.data.token}" | base64 --decode)"
echo "---------------------------------"
echo "Generate kubeconfig"
echo "---------------------------------"
export KUBECONFIG="$(mktemp)"
kubectl config set-credentials "kubelet" --token="$token" >/dev/null
ca_crt="$(mktemp)"; echo "$ca_crt_data" > $ca_crt
kubectl config set-cluster $cluster --server="$intapi" --certificate-authority="$ca_crt" --embed-certs >/dev/null
kubectl config set-context kubelet --cluster="$cluster" --user="kubelet" >/dev/null
kubectl config use-context kubelet >/dev/null
echo "---------------------------------"
echo "Print kubeconfig"
echo "---------------------------------"
cat "$KUBECONFIG"
echo "---------------------------------"
echo "Whoami?"
echo "---------------------------------"
oc whoami
whoami
echo "---------------------------------"
echo "Moving to real kubeconfig"
echo "---------------------------------"
cp /etc/kubernetes/kubeconfig /etc/kubernetes/kubeconfig.prev
chown root:root ${KUBECONFIG}
chmod 0644 ${KUBECONFIG}
mv "${KUBECONFIG}" /etc/kubernetes/kubeconfig
echo "---------------------------------"
echo "Sleep 60 seconds..."
echo "---------------------------------"
sleep 60
done
securityContext:
privileged: true
runAsUser: 0
volumeMounts:
- mountPath: /etc/kubernetes/
name: kubelet-dir
nodeSelector:
node-role.kubernetes.io/master: ""
priorityClassName: "system-cluster-critical"
restartPolicy: Always
securityContext:
runAsUser: 0
tolerations:
- key: "node-role.kubernetes.io/master"
operator: "Exists"
effect: "NoSchedule"
- key: "node.kubernetes.io/unreachable"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 120
- key: "node.kubernetes.io/not-ready"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 120
volumes:
- hostPath:
path: /etc/kubernetes/
type: Directory
name: kubelet-dir
EOF
oc apply -f $HOME/kubelet-bootstrap-cred-manager-ds.yaml.yaml
oc delete secrets/csr-signer-signer secrets/csr-signer -n openshift-kube-controller-manager-operator以上のスクリプトの内容で "OpenShift の Cluster の停止"が始まります。
しかし、これだけでは Cluster が乗っている VM は停止していません。そこで、下記のコマンドを実行して cluster operator の停止を確認してから、VM を停止します。
watch oc get clusteroperators結果：
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE
authentication 4.2.14 True False False 8d
cloud-credential 4.2.14 True False False 8d
cluster-autoscaler 4.2.14 True False False 8d
console 4.2.14 True False False 25m
dns 4.2.14 True False False 8d
image-registry 4.2.14 True False False 45m
ingress 4.2.14 True False False 8d
insights 4.2.14 True False False 8d
kube-apiserver 4.2.14 True True False 8d
kube-controller-manager 4.2.14 True False False 8d
kube-scheduler 4.2.14 True False False 8d
machine-api 4.2.14 True False False 8d
machine-config 4.2.14 True False False 17h
marketplace 4.2.14 True False False 24m
monitoring 4.2.14 True False False 48m
network 4.2.14 True False False 8d
node-tuning 4.2.14 True False False 24m
openshift-apiserver 4.2.14 True False False 30m
openshift-controller-manager 4.2.14 True False False 8d
openshift-samples 4.2.14 True False False 52m
operator-lifecycle-manager 4.2.14 True False False 8d
operator-lifecycle-manager-catalog 4.2.14 True False False 8d
operator-lifecycle-manager-packageserver 4.2.14 True False False 25m
service-ca 4.2.14 True False False 8d
service-catalog-apiserver 4.2.14 True False False 8d
service-catalog-controller-manager 4.2.14 True False False 8d
storage 4.2.14 True False False 58mすべての cluster operator において Available=True, Progressing=False, Degraded=False となっていることを確認し、次の作業で Cluster の VM を停止してください。
# REGION と CLUSTERNAME は環境にあったものに変更してください
export REGION="ap-northeast-1"
export CLUSTERNAME="cluster-xxxx"
aws ec2 stop-instances --region ${REGION} --instance-ids $(aws ec2 describe-instances --filters "Name=tag:Name,Values=${CLUSTERNAME}-*" "Name=instance-state-name,Values=running" --query Reservations[*].Instances[*].InstanceId --region ${REGION} --output text)以上で OpenShift の Cluster を停止が完了します。使用している AWS のアカウントから EC2 インスタンスの停止を確認してから、作業を終えてください。
再起動
OpenShift の Cluster の再起動をするにあたって、まず VM の起動を行います。
# REGION と CLUSTERNAME は環境にあったものに変更してください
export REGION="ap-northeast-1"
export CLUSTERNAME="cluster-xxxx"
aws ec2 start-instances --region ${REGION} --instance-ids $(aws ec2 describe-instances --filters "Name=tag:Name,Values=${CLUSTERNAME}-*" "Name=instance-state-name,Values=stopped" --query Reservations[*].Instances[*].InstanceId --region ${REGION} --output text)上記作業後に Node の起動ができているかの確認を行います。
oc get nodes結果：
NAME STATUS ROLES AGE VERSION
ip-10-0-132-82.us-east-2.compute.internal Ready worker 18h v1.14.0+b985ea310
ip-10-0-134-223.us-east-2.compute.internal Ready master 19h v1.14.0+b985ea310
ip-10-0-147-233.us-east-2.compute.internal Ready master 19h v1.14.0+b985ea310
ip-10-0-154-126.us-east-2.compute.internal Ready worker 18h v1.14.0+b985ea310
ip-10-0-162-210.us-east-2.compute.internal Ready master 19h v1.14.0+b985ea310
ip-10-0-172-133.us-east-2.compute.internal Ready worker 18h v1.14.0+b985ea310このとき status が全て Ready であれば作業完了です。
NotReady な Node がある場合、その Node の証明書署名要求 (CSR) の発行を行います。NotReady な Node の CSR が Pending と表示されるのを以下のコマンドで確認してください（表示されるまで何度か試してみてください）。
oc get csrCSR が表示されたら、それらの承認を行います。次のコマンドで全ての未処理な CSR を承認していきます。
oc get csr -oname | xargs oc adm certificate approve上記コマンドの完了後、CSR が承認されたことを確認します。
oc get csr全ての Node が Ready と表示されていることが確認できれば終了です。
まとめ
以上の操作によって、 OpenShift の Cluster の停止と再起動が可能です。
この一時停止が必要となる場面は稀かもしれませんが、現状ではコマンド操作でこの操作が行えないので注意してください。また、バージョンによってはこのドキュメント内容が適切でない場合もあるかもしれませんので、注意してください。
追記
OCP4.5からはシャットダウン方法が公式ドキュメントに記載されました。
――――――――――――――――――――――――――――――――――
執筆者プロフィール：合屋 純
九州大学大学院理学府修士卒 大学院で物理学を専攻し、数値計算プログラムに触れたことをキッカケにエンジニアリングに興味を持つ。
現在はリアルグローブ・オートメーティッドにて、コンテナ関連技術や自動化ツールの導入業務に従事。
【ご案内】
ITシステム開発やITインフラ運用の効率化、高速化、品質向上、その他、情シス部門の働き方改革など、IT自動化導入がもたらすメリットは様々ございます。
IT業務の自動化にご興味・ご関心ございましたら、まずは一度、IT自動化の専門家リアルグローブ・オートメーティッド(RGA)にご相談ください！
お問合せは以下の窓口までお願いいたします。
【お問い合わせ窓口】
株式会社リアルグローブ・オートメーティッド
代表窓口：info@rg-automated.jp
URL：https://rg-automated.jp
