Red Hat でソリューションアーキテクトを担当している荒木です。赤帽エンジニアブログ アドベントカレンダー 21日目をおおくりいたします。
2019年12月20日 に開催されたOpenShift.run で OpenShift 4.2 の、Machine Config Operator について紹介させていただきました。今回はその番外編として、Machine API の Machine Health Check を有効にする方法の紹介をしたいと思います。
尚、今回は、AWS上にIPI で構築された、OpenShift 4.2 を前提として紹介しております。環境や前提が異る場合、動作が異る可能性があるのでご注意ください。
openshift-installer によるAWS上のOpenShiftクラスタ構築については、こちが参考となります。
Machine API について
Machine API の概要を紹介します。Machine API は、アップストリームのCluster API プロジェクトで開発されている機能を、OpenShiftに拡張／調整して実装されています。
ここで、簡単に、Cluser APIについて紹介します。Cluster API は、Kubernetes クラスタのライフサイクル全般（作成〜削除）を範囲とし、クラスタに対する運用管理操作に一貫したインタフェースと振舞を提供する事を目標として、現在、盛んに機能が開発されているプロジェクトとなります。
- Cluster API 機能概要
- Kubeクラスタのライフサイクル管理を提供
- 各種クラスタ上のオブジェクトを抽象化
- 様々な実オブジェクト(非Kubeな実態）を抽象化し
- Kube-Native(宣言型かつ調整的な機構）を実現する
Machine API は、Cluster APIの思想に従うもので、OpenShiftクラスターが稼働するプラットフォーム(各種IaaSや、Baremetal、仮想統合環境)によらず、クラスタ環境にシンプルで一貫性のある運用管理性の実現を目指しています。
尚、Cluster API には、複数のクラスタを管理する Management Clusterのような機能がありますが、これまでのところOpenShift には実装されていません。しかし、今後、マルチクラスター機能を高度化していく過程で複数のクラスタ環境を横断的に管理する機能が提供されるようになると想像します。
- Machine API の機能
- ノードの即時的なスケールイン／アウトをコマンドラインから可能に
- ノードのスケール調整そのものを自動化(autoscale)
- ノードのローリングアップデート
- ノードの自動リカバリ（OCP 4.2 では TP）
詳細は、こちらのドキュメントを参照ください。
Machine Health Check について
Machine Helath Check (MHC)は、 OpenShiftクラスタを構成する、node(masterを除く）の稼働状況を監視し、異常を検出した場合、該当するnodeを削除し、新しいnodeを再作成するという機能を提供します。但し、Machine API を前提した機能となるため、Machine API の機能群が動作することが前提となります。(例えば、UPIで構築した環境では、Machine API の機能が制限されているため、Machine Health Check についても同様に制限があるものと考えられます。)
尚、バージョン4.2 時点、MHCは、Technical Preview です。商用環境での使用は推奨していない機能となります。注意事項／制限事項をご理解いただいたうえで利用をご検討ください。
Machine Health Check の有効化
現在、クラスタ構築後の初期状態では、MHCは、無効化されています。手動で有効化する方法を紹介します。
FeatureGate の有効化
注意 :この操作がOpenShift 環境に大きな影響となる場合があります。 FeatureGateが有効な場合、OpenShift環境のアップグレードを行えなくなります。また、FeatureGate を有効にした後、再度無効化は行なえません。このため、この操作を行う環境は、バージョンアップが必要となった場合や、致命的な不具合が発生した場合に、破棄または、再構築することが許容される環境でのみ実施してください。
FeatureGateの有効化は、Webconsole から行えます。
Step1:Custom Resource Definitions の表示
WebConsole のAdministrationメニュー下にあるCustom Resource Definition 選択し、フィルター等を使用して、"FeatureGate" CRD を特定、リンクをクリックします。
Step2:Feature Gate のインスタンス一覧
Feature Gate CRD の詳細画面にて、右上の"Actions"ドロップダウンリストより、"View Instances" を選択します。
Step3:Feature Gateを作成する。
"Create Feature Gate"ボタンをクリックし、作成パラメータの編集画面を表示します。
テキストフィールドに以下の内容を入力します。
apiVersion: config.openshift.io/v1 kind: FeatureGate metadata: name: cluster-tp spec: featureSet: "TechPreviewNoUpgrade"
入力したら、"Create"ボタンをクリックします。
Machine Health Check リソースの作成
リソース作成のため、定義ファイルを用意します。(machine-health-check.yaml) 定義ファイルには、以下のパラメータが必要となります。
- クラスタ名：cluster
- マシンセット名:cluster-worker-ap-southeast-1a
apiVersion: healthchecking.openshift.io/v1alpha1
kind: MachineHealthCheck
metadata:
name: sample-machine-health-check
namespace: openshift-machine-api
Spec:
Selector:
matchLabels:
machine.openshift.io/cluster-api-cluster: cluster
machine.openshift.io/cluster-api-machine-role: worker
machine.openshift.io/cluster-api-machine-type: worker
machine.openshift.io/cluster-api-machineset: cluster-worker-ap-southeast-1a
oc apply コマンドより、リソースを作成します。
$ oc apply -f machine-health-check.yaml machinehealthcheck.healthchecking.openshift.io/sample-machine-health-check created $ oc get MachineHealthCheck NAME AGE sample-machine-health-check 3s
Machine Health Check は、デフォルトの状態ではNotReady状態のみを認識し、5分継続した場合に障害と断定し、削除する動作となるようです。 この障害の判断基準を変更する場合は、コンフィグマップ"node-unhealthy-conditions"を作成してカスタマイズを行います。
以下の例(mc-configmap.yaml)では、5分間、通信が途絶えた場合に障害と判断します。
apiVersion: v1
kind: ConfigMap
metadata:
name: node-unhealthy-conditions
namespace: openshift-machine-api
data:
conditions: |
items:
- name: NetworkUnavailable
timeout: 5m
status: True
oc apply コマンドより、コンフィグマップを作成します。
$ oc apply -f mc-configmap.yaml configmap/node-unhealthy-conditions created $ oc get configmap NAME DATA AGE cluster-autoscaler-operator-ca 1 32h cluster-autoscaler-operator-leader 0 32h machine-api-operator 0 32h machine-api-operator-images 1 32h node-unhealthy-conditions 1 57s $
おわりに
繰り返しとなりますが、MHCは、Tech Previewなので、残念ながら商用環境を対象として本格的に使用いただくことはできませんが、この機能がGAとなれば、node に何らかサービスを継続できない障害が発生した場合に、自動的にnodeの復旧が行われるようになります。つまり、OpenShift クラスタ可用性の向上が期待される魅力的な機能ではないかと思います。
一方で、動作としては障害が検出されたnode は、自動的に削除されていまうため、障害の根本原因の追求には都合が悪い面も考えられます。また、node が復旧した場合、障害が発生したnodeで稼働していたpodや、影響をうけうるサービスの状態については個別に観察する必要があるようです。
このため、サービスまで含めた運用設計にこれらの振舞を加味する必要がありそうです。
