はじめに
この記事では、Power Systems Virtual Server(以下PowerVS)へのOpenShift 4.7の導入後作業としてinfraノードの構成を実施します。infraノードでは、モニタリング、ロギング、ルーター、イメージレジストリーのみが稼働します。モニタリングとロギングではブロックストレージが推奨されているため、仮想サーバー・インスタンスにボリュームを追加してLocal Storageオペレーター経由で利用します。infraノード構成後は下図のように多くのPodがworkerノードから移動され、workerノードのCPUとメモリ使用量が少なくなります。
■ OpenShift 4.7導入直後
■ infraノード
1. bastionノード構成変更
OpenShiftクラスターにinfraノードを追加するためにbastionノードの構成を変更します。変更前の状態はこちらの記事を参照ください。
1.1. dnsmasq構成変更
infraノードをbootp起動したときにgrub.cfg-01-(MACアドレス)をtftpで送信するようにします。infraノードのMACアドレスはIBM Cloudコンソールで確認します。
bastionノード
vi /var/lib/tftpboot/boot/grub2/powerpc-ieee1275/grub.cfg-01-fa-1b-ef-af-c1-20
default=0
fallback=1
timeout=1
menuentry "infra-0 CoreOS (BIOS)" {
linux "rhcos-4.7.7-ppc64le-live-kernel-ppc64le" rd.neednet=1 ip=192.168.25.115::192.168.25.100:255.255.255.0:infra-0:env2:none nameserver=192.168.25.100 coreos.inst=yes coreos.inst
.install_dev=sda coreos.live.rootfs_url=http://192.168.25.100:8080/rhcos-4.7.7-ppc64le-live-rootfs.ppc64le.img coreos.inst.ignition_url=http://192.168.25.100:8080/worker.ign
initrd "rhcos-4.7.7-ppc64le-live-initramfs.ppc64le.img"
}
### vi終了
vi /var/lib/tftpboot/boot/grub2/powerpc-ieee1275/grub.cfg-01-fa-88-3c-5c-37-20
default=0
fallback=1
timeout=1
menuentry "infra-1 CoreOS (BIOS)" {
linux "rhcos-4.7.7-ppc64le-live-kernel-ppc64le" rd.neednet=1 ip=192.168.25.116::192.168.25.100:255.255.255.0:infra-1:env2:none nameserver=192.168.25.100 coreos.inst=yes coreos.inst
.install_dev=sda coreos.live.rootfs_url=http://192.168.25.100:8080/rhcos-4.7.7-ppc64le-live-rootfs.ppc64le.img coreos.inst.ignition_url=http://192.168.25.100:8080/worker.ign
initrd "rhcos-4.7.7-ppc64le-live-initramfs.ppc64le.img"
}
### vi終了
vi /var/lib/tftpboot/boot/grub2/powerpc-ieee1275/grub.cfg-01-fa-ba-6f-8a-9c-20
default=0
fallback=1
timeout=1
menuentry "infra-2 CoreOS (BIOS)" {
linux "rhcos-4.7.7-ppc64le-live-kernel-ppc64le" rd.neednet=1 ip=192.168.25.117::192.168.25.100:255.255.255.0:infra-2:env2:none nameserver=192.168.25.100 coreos.inst=yes coreos.inst
.install_dev=sda coreos.live.rootfs_url=http://192.168.25.100:8080/rhcos-4.7.7-ppc64le-live-rootfs.ppc64le.img coreos.inst.ignition_url=http://192.168.25.100:8080/worker.ign
initrd "rhcos-4.7.7-ppc64le-live-initramfs.ppc64le.img"
}
### vi終了
vi /etc/hosts(以下を追加)
192.168.25.115 infra-0
192.168.25.116 infra-1
192.168.25.117 infra-2
### vi終了
vi /etc/dnsmasq.conf(以下を追加)
dhcp-host=fa:1b:ef:af:c1:20,infra-0,192.168.25.115
dhcp-host=fa:88:3c:5c:37:20,infra-1,192.168.25.116
dhcp-host=fa:ba:6f:8a:9c:20,infra-2,192.168.25.117
### vi終了
systemctl restart dnsmasq
1.2. haproxy構成変更
infraノード上のルーターへの通信の負荷分散設定をします。workerをコメントアウトすると、ルーターをinfraノードに移動するまでOpenShiftコンソールにアクセスできなくなることに注意してください。
bastionノード
vi /etc/haproxy/haproxy.cfg(backendにinfraノードを追加しworkerはコメントアウト)
backend http-80
･･･
#server worker-0 worker-0.ocp.powervs:80 check
#server worker-1 worker-1.ocp.powervs:80 check
server infra-0 infra-0.ocp.powervs:80 check
server infra-1 infra-1.ocp.powervs:80 check
server infra-2 infra-2.ocp.powervs:80 check
backend https-443
･･･
#server worker-0 worker-0.ocp.powervs:443 check
#server worker-1 worker-1.ocp.powervs:443 check
server infra-0 infra-0.ocp.powervs:443 check
server infra-1 infra-1.ocp.powervs:443 check
server infra-2 infra-2.ocp.powervs:443 check
### vi終了
systemctl restart haproxy
2. infraノード追加
2.1. PowerVSインスタンス作成
下表のPowerVSインスタンスをinfraノードとして追加で作成します。
| ノード | vCPU | 仮想RAM | ストレージ | IPアドレス | ブート イメージ |
追加 ボリューム |
|---|---|---|---|---|---|---|
| infra-0 | 0.5(shared) | 16GB | 120GB | 192.168.25.115 | rhos-47 | infra-00 infra-01 infra-02 infra-03 |
| infra-1 | 0.5(shared) | 16GB | 120GB | 192.168.25.116 | rhos-47 | infra-10 infra-11 infra-12 infra-13 |
| infra-2 | 0.5(shared) | 16GB | 120GB | 192.168.25.117 | rhos-47 | infra-20 infra-21 infra-22 infra-23 |
また、オペレーター用に12個のストレージ・ボリュームを作成します。容量に根拠はありません。
■ モニタリング用
| 用途 | Pod | 個数 | 容量 |
|---|---|---|---|
| Prometheus | prometheus-k8s-<番号> | 2 | 20GB |
| AlertManager | alertmanager-main-<番号> | 3 | 20GB |
| Prometheus(ユーザー定義) | prometheus-user-workload-<番号> | 2 | 20GB |
| ThanosRuler(ユーザー定義) | thanos-ruler-user-workload-<番号> | 2 | 20GB |
■ ロギング用
| 用途 | Pod | 個数 | 容量 |
|---|---|---|---|
| Elasticsearch | elasticsearch-cdm-<番号> | 3 | 40GB |
ibmcloudコマンドでinfraノードのインスタンスとストレージ・ボリュームを作成します。ボリュームをinfraノードのインスタンスに接続したままでは、RHCOS導入に失敗しOpenShiftクラスターへ参加できなかったので後で接続します。
classicノード
ibmcloud pi instance-create infra-0 --image rhcos-47 --memory 16 \
--network "ocp-net 192.168.25.115" --processors 0.5 --processor-type shared \
--key-name sshkey --key-name sshkey --sys-type s922 --storage-type tier3
ibmcloud pi instance-create infra-1 --image rhcos-47 --memory 16 \
--network "ocp-net 192.168.25.116" --processors 0.5 --processor-type shared \
--key-name sshkey --key-name sshkey --sys-type s922 --storage-type tier3
ibmcloud pi instance-create infra-2 --image rhcos-47 --memory 16 \
--network "ocp-net 192.168.25.117" --processors 0.5 --processor-type shared \
--key-name sshkey --key-name sshkey --sys-type s922 --storage-type tier3
ibmcloud pi volume-create infra-00 --type tier3 --size 20
ibmcloud pi volume-create infra-01 --type tier3 --size 20
ibmcloud pi volume-create infra-02 --type tier3 --size 20
ibmcloud pi volume-create infra-03 --type tier3 --size 40
ibmcloud pi volume-create infra-10 --type tier3 --size 20
ibmcloud pi volume-create infra-11 --type tier3 --size 20
ibmcloud pi volume-create infra-12 --type tier3 --size 20
ibmcloud pi volume-create infra-13 --type tier3 --size 40
ibmcloud pi volume-create infra-20 --type tier3 --size 20
ibmcloud pi volume-create infra-21 --type tier3 --size 20
ibmcloud pi volume-create infra-22 --type tier3 --size 20
ibmcloud pi volume-create infra-23 --type tier3 --size 40
2.2. OpenShiftクラスターへのinfraノード追加
infraノードのコンソールを開いた後、infraノードを再始動しSMSメニューに入ります。IPアドレスを設定しbootp起動すると、infraノードへのRHCOSやOpenShiftの導入が進み、CSRがPendingで認識されるので2回承認します。
bastionノード
# 1回目
export KUBECONFG=/root/ocp/install/bare-metal/auth/kubeconfig
oc get csr | grep "Pending"
### 標準出力↓
csr-297mx 4m31s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending
csr-szw59 2m54s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending
csr-zw668 5m44s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending
oc get csr | grep "Pending" | awk '{print $1}' | xargs oc adm certificate approve
### 標準出力↓
certificatesigningrequest.certificates.k8s.io/csr-297mx approved
certificatesigningrequest.certificates.k8s.io/csr-szw59 approved
certificatesigningrequest.certificates.k8s.io/csr-zw668 approved
# 2回目
oc get csr | grep "Pending"
### 標準出力↓
csr-2bl4v 27s kubernetes.io/kubelet-serving system:node:infra-2 Pending
csr-7wg96 17s kubernetes.io/kubelet-serving system:node:infra-0 Pending
csr-fdq4w 21s kubernetes.io/kubelet-serving system:node:infra-1 Pending
oc get csr | grep "Pending" | awk '{print $1}' | xargs oc adm certificate approve
### 標準出力↓
certificatesigningrequest.certificates.k8s.io/csr-2bl4v approved
certificatesigningrequest.certificates.k8s.io/csr-7wg96 approved
certificatesigningrequest.certificates.k8s.io/csr-fdq4w approved
oc get nodes
### 標準出力↓
NAME STATUS ROLES AGE VERSION
infra-0 Ready worker 3m48s v1.20.0+c8905da
infra-1 Ready worker 3m52s v1.20.0+c8905da
infra-2 Ready worker 3m58s v1.20.0+c8905da
master-0 Ready master 16h v1.20.0+c8905da
master-1 Ready master 16h v1.20.0+c8905da
master-2 Ready master 16h v1.20.0+c8905da
worker-0 Ready worker 16h v1.20.0+c8905da
worker-1 Ready worker 16h v1.20.0+c8905da
infraノードにストレージ・ボリュームを接続するために停止します。
bastionノード
ssh core@infra-0 sudo shutdown -h 1
ssh core@infra-1 sudo shutdown -h 1
ssh core@infra-2 sudo shutdown -h 1
停止後しばらく待つとストレージ・ボリュームを接続できるようになります。
classicノード
ibmcloud pi volume-attach infra-00 --instance infra-0
ibmcloud pi volume-attach infra-01 --instance infra-0
ibmcloud pi volume-attach infra-02 --instance infra-0
ibmcloud pi volume-attach infra-03 --instance infra-0
ibmcloud pi volume-attach infra-10 --instance infra-1
ibmcloud pi volume-attach infra-11 --instance infra-1
ibmcloud pi volume-attach infra-12 --instance infra-1
ibmcloud pi volume-attach infra-13 --instance infra-1
ibmcloud pi volume-attach infra-20 --instance infra-2
ibmcloud pi volume-attach infra-21 --instance infra-2
ibmcloud pi volume-attach infra-22 --instance infra-2
ibmcloud pi volume-attach infra-23 --instance infra-2
2.3. infraノードの構成
2.3.1. オペレーター導入
管理コンソールのOperatorHubからオペレーターを導入します。
■ Local Storageオペレーター
■ OpenShift Elasticsearchオペレーター
■ OpenShift Loggingオペレーター
2.3.2. Local Volume作成
Local Storageオペレーターを利用して、infraノードにLocalVolumeを作成します。infraノードでlsblkコマンドを実行して追加されたデバイスを確認するのですが、下記のようにマルチパス構成されているため同じデバイスが繰り返し表示されました。モニタリング用のLocalVolumeとしてsda、sdb、sdcを、ロギング用のLocalVolumeとしてsddを指定するマニフェストを適用していますが、マルチパスを考慮して複数のデバイスを記述した方が良いのかもしれません。
bastionノード
ssh core@infra-0 lsblk -d
### 標準出力↓
sda 8:0 0 20G 0 disk
sdb 8:16 0 20G 0 disk
sdc 8:32 0 20G 0 disk
sdd 8:48 0 40G 0 disk
sde 8:64 0 120G 0 disk
sdf 8:80 0 20G 0 disk
sdg 8:96 0 20G 0 disk
sdh 8:112 0 20G 0 disk
sdi 8:128 0 40G 0 disk
sdj 8:144 0 120G 0 disk
･･･
bastionノード
oc apply -f monitoring-lv.yaml
oc apply -f logging-lv.yaml
oc get pod -n openshift-local-storage
### 標準出力↓
local-storage-operator-5d4cbd7bd7-p8thz 1/1 Running 0 61m
logging-lv-local-diskmaker-phd45 1/1 Running 0 2m19s
logging-lv-local-diskmaker-rkbcw 1/1 Running 0 2m19s
logging-lv-local-diskmaker-ttzfp 1/1 Running 0 2m19s
logging-lv-local-provisioner-kwmw9 1/1 Running 0 2m19s
logging-lv-local-provisioner-l42zk 1/1 Running 0 2m19s
logging-lv-local-provisioner-wsspv 1/1 Running 0 2m19s
monitoring-lv-local-diskmaker-dnwd6 1/1 Running 0 3m22s
monitoring-lv-local-diskmaker-dtjc8 1/1 Running 0 3m22s
monitoring-lv-local-diskmaker-rmmml 1/1 Running 0 3m22s
monitoring-lv-local-provisioner-6bdcq 1/1 Running 0 3m22s
monitoring-lv-local-provisioner-mgv4t 1/1 Running 0 3m22s
monitoring-lv-local-provisioner-zj5sd 1/1 Running 0 3m22s
oc get pv
### 標準出力↓
local-pv-117d5df 20Gi RWO Delete Available monitoring-sc 3m28s
local-pv-19bf4152 20Gi RWO Delete Available monitoring-sc 3m27s
local-pv-33c689a0 20Gi RWO Delete Available logging-sc 2m42s
local-pv-5015089e 20Gi RWO Delete Available monitoring-sc 3m28s
local-pv-5bb057fb 20Gi RWO Delete Available monitoring-sc 3m33s
local-pv-6d79c839 20Gi RWO Delete Available monitoring-sc 3m33s
local-pv-93c59c55 40Gi RWO Delete Available logging-sc 2m41s
local-pv-a8cdd61f 40Gi RWO Delete Available logging-sc 2m41s
local-pv-ae2c170 40Gi RWO Delete Available monitoring-sc 3m27s
local-pv-bd9d15 20Gi RWO Delete Available monitoring-sc 3m28s
local-pv-bf728680 20Gi RWO Delete Available monitoring-sc 3m33s
local-pv-dffcf04b 20Gi RWO Delete Available monitoring-sc 3m27s
monitoring-lv.yaml
apiVersion: local.storage.openshift.io/v1
kind: LocalVolume
metadata:
name: monitoring-lv
namespace: openshift-local-storage
spec:
nodeSelector:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- infra-0
- infra-1
- infra-2
storageClassDevices:
- storageClassName: monitoring-sc
volumeMode: Filesystem
fsType: xfs
devicePaths:
- /dev/sda
- /dev/sdb
- /dev/sdc
logging-lv.yaml
apiVersion: local.storage.openshift.io/v1
kind: LocalVolume
metadata:
name: logging-lv
namespace: openshift-local-storage
spec:
nodeSelector:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- infra-0
- infra-1
- infra-2
storageClassDevices:
- storageClassName: logging-sc
volumeMode: Filesystem
fsType: xfs
devicePaths:
- /dev/sdd
2.3.3. ロール追加
worker/infraノードにロールを追加します。nodeSelectorを指定しない場合はworkerノードにPodがデプロイされるように設定します。kube-apiserverが更新(PROGRESSING=True)されるのでしばらく待機します。
bastionノード
oc label node worker-0 node-role.kubernetes.io/app=""
oc label node worker-1 node-role.kubernetes.io/app=""
oc label node infra-0 node-role.kubernetes.io/infra=""
oc label node infra-1 node-role.kubernetes.io/infra=""
oc label node infra-2 node-role.kubernetes.io/infra=""
# 以下はPodにnodeSelectorが自動設定されるため実施しない
# DaemonSet等でPodを作成する際にスケジュールされない状況になる
# oc patch scheduler cluster --type merge --patch '{"spec":{"defaultNodeSelector":"node-role.kubernetes.io/app="}}'
# oc get co kube-apiserver
### 標準出力↓
# NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE
# kube-apiserver 4.7.9 True True False 5d22h
oc get nodes
### 標準出力↓
NAME STATUS ROLES AGE VERSION
infra-0 Ready infra,worker 79m v1.20.0+c8905da
infra-1 Ready infra,worker 79m v1.20.0+c8905da
infra-2 Ready infra,worker 79m v1.20.0+c8905da
master-0 Ready master 17h v1.20.0+c8905da
master-1 Ready master 17h v1.20.0+c8905da
master-2 Ready master 17h v1.20.0+c8905da
worker-0 Ready app,worker 17h v1.20.0+c8905da
worker-1 Ready app,worker 17h v1.20.0+c8905da
2.3.4. AlertManager設定
AlertManagerにより、デフォルトモニタリングとユーザー定義モニタリングからのアラートをPagerDuty/Webhook/Email/Slackに通知することができます。ここではSlackに通知するよう設定します。
bastionノード
oc -n openshift-monitoring create secret generic alertmanager-main \
--from-file=alertmanager.yaml --dry-run=client -o=yaml \
| oc -n openshift-monitoring replace secret --filename=-
alertmanager.yaml
global:
resolve_timeout: 5m
inhibit_rules:
- equal:
- namespace
- alertname
source_match:
severity: critical
target_match_re:
severity: warning|info
- equal:
- namespace
- alertname
source_match:
severity: warning
target_match_re:
severity: info
receivers:
- name: Critical
slack_configs:
- channel: alerts-critical
api_url: >-
<Slack Incoming Webhooks URL#1>
text: |-
{{ range .Alerts }}
*Alert:* {{ .Labels.alertname }} - `{{ .Labels.severity }}`
*Description:* {{ .Annotations.message }}
*Details:*
{{ range .Labels.SortedPairs }} ? *{{ .Name }}:* `{{ .Value }}`
{{ end }}
{{ end }}
- name: Default
slack_configs:
- channel: alerts-default
api_url: >-
<Slack Incoming Webhooks URL#2>
text: |-
{{ range .Alerts }}
*Alert:* {{ .Labels.alertname }} - `{{ .Labels.severity }}`
*Description:* {{ .Annotations.message }}
*Details:*
{{ range .Labels.SortedPairs }} ? *{{ .Name }}:* `{{ .Value }}`
{{ end }}
{{ end }}
- name: Watchdog
slack_configs:
- channel: alerts-watchdog
api_url: >-
<Slack Incoming Webhooks URL#3>
text: >-
{{ range .Alerts }}
*Alert:* {{ .Labels.alertname }} - `{{ .Labels.severity }}`
*Description:* {{ .Annotations.message }}
*Details:*
{{ range .Labels.SortedPairs }} ? *{{ .Name }}:* `{{ .Value }}`
{{ end }}
{{ end }}
route:
group_by:
- namespace
group_interval: 5m
group_wait: 30s
receiver: Default
repeat_interval: 12h
routes:
- receiver: Watchdog
match:
alertname: Watchdog
- receiver: Critical
match:
severity: critical
設定後、Slackに下記のような通知が届くようになりました。
Slack側の準備に関しては下記が参考になります。
2.3.5. モニタリング設定
ストレージとPod起動ノードに関する設定を行います。ユーザー定義モニタリングも有効化しています。
bastionノード
oc apply -f cluster-monitoring-config.yaml
oc get pod -n openshift-monitoring -o wide
### 標準出力↓
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
alertmanager-main-0 5/5 Running 0 3h7m 10.130.2.16 infra-1 <none> <none>
alertmanager-main-1 5/5 Running 0 3h19m 10.131.2.8 infra-0 <none> <none>
alertmanager-main-2 5/5 Running 0 3h39m 10.129.2.4 infra-2 <none> <none>
cluster-monitoring-operator-7dfbcc944d-l8bkg 2/2 Running 0 3h27m 10.128.0.26 master-0 <none> <none>
grafana-7c7bfd45c-dvqz9 2/2 Running 0 3h19m 10.129.2.8 infra-2 <none> <none>
kube-state-metrics-57df856d9c-7b76t 3/3 Running 0 3h8m 10.129.2.10 infra-2 <none> <none>
node-exporter-7z29r 2/2 Running 0 4h20m 192.168.25.113 worker-0 <none> <none>
node-exporter-8zwct 2/2 Running 0 4h22m 192.168.25.115 infra-0 <none> <none>
node-exporter-9ntlv 2/2 Running 0 4h20m 192.168.25.117 infra-2 <none> <none>
node-exporter-c4xhv 2/2 Running 0 4h18m 192.168.25.111 master-1 <none> <none>
node-exporter-jt5wn 2/2 Running 0 4h20m 192.168.25.116 infra-1 <none> <none>
node-exporter-v4nl6 2/2 Running 0 4h21m 192.168.25.112 master-2 <none> <none>
node-exporter-xgnrt 2/2 Running 0 4h19m 192.168.25.110 master-0 <none> <none>
node-exporter-xj2vr 2/2 Running 0 4h19m 192.168.25.114 worker-1 <none> <none>
openshift-state-metrics-77764976d9-t77bz 3/3 Running 0 3h8m 10.131.2.10 infra-0 <none> <none>
prometheus-adapter-5c865574c6-jsrfd 1/1 Running 0 3h2m 10.131.2.20 infra-0 <none> <none>
prometheus-adapter-5c865574c6-rsqmv 1/1 Running 0 3h3m 10.131.2.18 infra-0 <none> <none>
prometheus-k8s-0 7/7 Running 1 3h39m 10.129.2.6 infra-2 <none> <none>
prometheus-k8s-1 7/7 Running 1 3h19m 10.131.2.5 infra-0 <none> <none>
prometheus-operator-5667f89469-rjnrm 2/2 Running 0 3h8m 10.131.2.11 infra-0 <none> <none>
telemeter-client-595967cd48-8njgj 3/3 Running 0 3h8m 10.129.2.11 infra-2 <none> <none>
thanos-querier-649d574d69-xvksw 5/5 Running 0 3h8m 10.131.2.17 infra-0 <none> <none>
thanos-querier-649d574d69-ztn9s 5/5 Running 0 3h19m 10.129.2.9 infra-2 <none> <none>
cluster-monitoring-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-monitoring-config
namespace: openshift-monitoring
data:
config.yaml: |
enableUserWorkload: true
prometheusK8s:
volumeClaimTemplate:
spec:
storageClassName: monitoring-sc
resources:
requests:
storage: 20Gi
nodeSelector:
node-role.kubernetes.io/infra: ""
alertmanagerMain:
volumeClaimTemplate:
spec:
storageClassName: monitoring-sc
resources:
requests:
storage: 20Gi
nodeSelector:
node-role.kubernetes.io/infra: ""
prometheusOperator:
nodeSelector:
node-role.kubernetes.io/infra: ""
grafana:
nodeSelector:
node-role.kubernetes.io/infra: ""
k8sPrometheusAdapter:
nodeSelector:
node-role.kubernetes.io/infra: ""
kubeStateMetrics:
nodeSelector:
node-role.kubernetes.io/infra: ""
telemeterClient:
nodeSelector:
node-role.kubernetes.io/infra: ""
openshiftStateMetrics:
nodeSelector:
node-role.kubernetes.io/infra: ""
thanosQuerier:
nodeSelector:
node-role.kubernetes.io/infra: ""
2.3.6. ユーザー定義モニタリング設定
ストレージとPod起動ノードに関する設定を行います。
bastionノード
oc apply -f user-monitoring-config.yaml
oc get pod -n openshift-user-workload-monitoring -o wide
### 標準出力↓
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
prometheus-operator-7f6c7bd5dd-svb6k 2/2 Running 0 3h39m 10.130.0.17 master-1 <none> <none>
prometheus-user-workload-0 5/5 Running 1 3h8m 10.130.2.13 infra-1 <none> <none>
prometheus-user-workload-1 5/5 Running 1 3h41m 10.129.2.7 infra-2 <none> <none>
thanos-ruler-user-workload-0 3/3 Running 0 3h9m 10.130.2.14 infra-1 <none> <none>
thanos-ruler-user-workload-1 3/3 Running 0 3h20m 10.131.2.6 infra-0 <none> <none>
user-monitoring-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: user-workload-monitoring-config
namespace: openshift-user-workload-monitoring
data:
config.yaml: |
prometheus:
volumeClaimTemplate:
spec:
storageClassName: monitoring-sc
resources:
requests:
storage: 20Gi
nodeSelector:
node-role.kubernetes.io/infra: ""
thanosRuler:
volumeClaimTemplate:
spec:
storageClassName: monitoring-sc
resources:
requests:
storage: 20Gi
nodeSelector:
node-role.kubernetes.io/infra: ""
2.3.7. ロギング設定
ロギングについては、インスタンス作成と同時に設定を行います。短期間のログに対応する割にメモリ要求が厳しいのですが、検証目的であるため4GBに制限します。また、Curatorは非推奨になったため設定していません。
OpenShift Logging Elasticsearch インスタンスは、短期 (約 7 日間) の保存について最適化され、テストされています。長期間ログを保持する必要がある場合は、データをサードパーティーのストレージシステムに移動することが推奨されます。
Elasticsearch はメモリー集約型アプリケーションです。デフォルトで、OpenShift Container Platform はメモリー要求および 16 GB の制限を持つ 3 つの Elasticsearch ノードをインストールします。OpenShift Container Platform ノードの最初の 3 つのセットには、Elasticsearch をクラスター内で実行するのに十分なメモリーがない可能性があります。
Elasticsearch Curator は OpenShift Logging 5.0 で非推奨となり、OpenShift Logging 5.1 で削除されます。
bastionノード
# ロギング設定
oc apply -f clo-instance.yaml
oc get pod -n openshift-logging -o wide
### 標準出力↓
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
cluster-logging-operator-6bf898cbd4-9jscd 1/1 Running 0 3h39m 10.128.2.9 worker-1 <none> <none>
elasticsearch-cdm-885k66by-1-778dddc6dd-zqcwz 2/2 Running 0 152m 10.130.2.30 infra-1 <none> <none>
elasticsearch-cdm-885k66by-2-66f6dd979f-q698p 2/2 Running 0 150m 10.131.2.26 infra-0 <none> <none>
elasticsearch-cdm-885k66by-3-98df488c8-6mgsj 2/2 Running 0 148m 10.129.2.18 infra-2 <none> <none>
elasticsearch-im-app-1620483300-f76lj 0/1 Completed 0 113s 10.130.2.65 infra-1 <none> <none>
elasticsearch-im-audit-1620483300-qqsnl 0/1 Completed 0 113s 10.130.2.66 infra-1 <none> <none>
elasticsearch-im-infra-1620483300-ls5l7 0/1 Completed 0 113s 10.130.2.67 infra-1 <none> <none>
fluentd-6cfrv 1/1 Running 0 23h 10.129.2.27 infra-2 <none> <none>
fluentd-8xfhk 1/1 Running 0 23h 10.131.2.23 infra-0 <none> <none>
fluentd-9z8f4 1/1 Running 0 23h 10.131.0.30 worker-0 <none> <none>
fluentd-gx6jt 1/1 Running 0 23h 10.130.0.47 master-1 <none> <none>
fluentd-kqrpq 1/1 Running 0 23h 10.129.0.48 master-2 <none> <none>
fluentd-mp7tz 1/1 Running 0 23h 10.128.2.60 worker-1 <none> <none>
fluentd-vlwqq 1/1 Running 0 23h 10.130.2.38 infra-1 <none> <none>
fluentd-wlwsl 1/1 Running 0 23h 10.128.0.47 master-0 <none> <none>
kibana-7c584cb9db-4sxp7 2/2 Running 0 126m 10.128.2.45 infra-1 <none> <none>
clo-instance.yaml
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
name: instance
namespace: openshift-logging
spec:
managementState: Managed
logStore:
type: elasticsearch
retentionPolicy:
application:
maxAge: 1d
infra:
maxAge: 7d
audit:
maxAge: 7d
elasticsearch:
nodeCount: 3
storage:
storageClassName: logging-sc
size: 40G
resources:
limits:
cpu: 500m
memory: 4Gi
requests:
cpu: 200m
memory: 4Gi
redundancyPolicy: SingleRedundancy
nodeSelector:
node-role.kubernetes.io/infra: ''
visualization:
type: kibana
kibana:
replicas: 1
nodeSelector:
node-role.kubernetes.io/infra: ''
collection:
logs:
type: fluentd
fluentd: {}
下記URLでKibanaへアクセスし、Managementメニューからインデックスパターンを作成するとログを確認できるようになります。app/infra/auditの3種類のインデックスがありますが、インデックスパターン作成のためにはデータが蓄積されている必要があります。ロギング設定直後はinfraのデータのみが存在していました。
https://kibana-openshift-logging.apps.ocp.powervs
2.3.8. ルーターとイメージレジストリーの移動
ルーターとイメージレジストリーをinfraノードに移動します。
bastionノード
oc patch ingresscontroller default -n openshift-ingress-operator --type=merge --patch='{"spec":{"nodePlacement":{"nodeSelector": {"matchLabels":{"node-role.kubernetes.io/infra":""}}}}}'
oc patch --namespace=openshift-ingress-operator --patch='{"spec": {"replicas": 3}}' --type=merge ingresscontroller/default
oc get pod -n openshift-ingress -o wide
# 標準出力↓
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
router-default-5b89fb5765-7wndh 1/1 Running 0 4h16m 192.168.25.117 infra-2 <none> <none>
router-default-5b89fb5765-smscm 1/1 Running 0 3h56m 192.168.25.115 infra-0 <none> <none>
router-default-5b89fb5765-whkkl 1/1 Running 0 3h44m 192.168.25.116 infra-1 <none> <none>
bastionノード
oc patch configs.imageregistry.operator.openshift.io cluster -n openshift-image-registry --type=merge --patch '{"spec":{"nodeSelector":{"node-role.kubernetes.io/infra":""}}}'
oc get pod -n openshift-image-registry -o wide
# 標準出力↓
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
cluster-image-registry-operator-768846dbff-7tgjg 1/1 Running 1 4h15m 10.130.0.13 master-1 <none> <none>
image-registry-74df945c7b-6n5lg 1/1 Running 0 3h45m 10.129.2.12 infra-2 <none> <none>
node-ca-czs95 1/1 Running 0 4h57m 192.168.25.110 master-0 <none> <none>
node-ca-hcqgk 1/1 Running 0 4h59m 192.168.25.116 infra-1 <none> <none>
node-ca-j4rzj 1/1 Running 0 4h58m 192.168.25.112 master-2 <none> <none>
node-ca-jcds9 1/1 Running 0 4h59m 192.168.25.115 infra-0 <none> <none>
node-ca-k8sjp 1/1 Running 0 4h58m 192.168.25.114 worker-1 <none> <none>
node-ca-nsrh6 1/1 Running 0 4h58m 192.168.25.111 master-1 <none> <none>
node-ca-rbmw8 1/1 Running 0 4h57m 192.168.25.113 worker-0 <none> <none>
node-ca-rg5hf 1/1 Running 0 4h57m 192.168.25.117 infra-2 <none> <none>
3. リソース状況
3.1. ノード一覧
OpenShiftコンソールでノード一覧を確認しました。
3.2. リソースリクエスト
定常状態のリソースリクエストを「oc describe nodes」で確認したところ下表のようになっていました。
| ノード | cpu requests |
memory requests |
|---|---|---|
| master-0 | 1696m | 7934Mi |
| master-1 | 1695m | 7986Mi |
| master-2 | 1714m | 7930Mi |
| worker-0 | 349m | 2712Mi |
| worker-1 | 559m | 3594Mi |
| infra-0 | 819m | 8777Mi |
| infra-1 | 1078m | 8137Mi |
| infra-2 | 843m | 8958Mi |
3.3. 物理コア使用状況
定常状態の物理コア使用状況をlparstatコマンドで確認したところ下表のようになっていました。%idleは割り当てている物理コア(physc)のうち使用されていない割合を表します。つまり、used列分のコアが使用されていることになります。
maste/worker/infraノードともに仮想サーバー・インスタンスを0.5コア上限なし(共有)で作成しています。Minimum Capacity=0.25、Maximum Capacity=4.00だったので、物理コアは負荷に応じて0.25～4.00の範囲で割り当てられることになります。また、SMT8になっていました。
| ノード | %idle | physc | used (100-%idle) /100*physc |
|---|---|---|---|
| master-0 | 86.00 | 0.75 | 0.11 |
| master-1 | 85.64 | 0.75 | 0.11 |
| master-2 | 90.25 | 0.59 | 0.06 |
| worker-0 | 97.74 | 0.14 | 0.00 |
| worker-1 | 97.05 | 0.19 | 0.01 |
| infra-0 | 87.34 | 0.60 | 0.08 |
| infra-1 | 88.82 | 0.54 | 0.06 |
| infra-2 | 84.59 | 0.70 | 0.11 |
3.4. メモリー使用状況
定常状態のメモリー使用状況をfreeコマンドで確認したところ下表のようになっていました。単位はGBです。
※ masterノードのメモリ使用率が高いので、この後、すべてのノードを停止し、masterノードのメモリーを20GBに、workerノードのメモリーを12GBに変更しました。masterに限らず、特定のノードにPodが集中することがあるので、メモリーは余裕を持って割り当てた方が良いです。
| ノード | total | used | available | total - available |
|---|---|---|---|---|
| master-0 | 15.88 | 13.15 | 1.85 | 14.03 |
| master-1 | 15.88 | 12.96 | 2.06 | 13.83 |
| master-2 | 15.88 | 9.57 | 5.49 | 10.40 |
| worker-0 | 15.88 | 4.95 | 10.29 | 5.59 |
| worker-1 | 15.88 | 6.14 | 9.05 | 6.83 |
| infra-0 | 15.88 | 11.36 | 4.45 | 11.43 |
| infra-1 | 15.88 | 11.00 | 4.28 | 11.61 |
| infra-2 | 15.88 | 12.71 | 3.24 | 12.64 |
3.5. 永続ボリューム要求の使用量
infraノード構成から1週間経過後にOpenShiftコンソールから永続ボリューム要求の使用量を確認しました。この時点で容量不足にはなっていません。Prometheusの保管期間はデフォルト15日です。Elasticsearchは保管期間7日間でインスタンスを作成しました。OpenShiftのみでアプリケーションがないのであれば、このくらいの容量を確保していれば不足することはなさそうです。
■ モニタリング用
| 永続ボリューム要求 | 容量 | 使用量 |
|---|---|---|
| prometheus-k8s-db-prometheus-k8s-0 | 20 GiB | 7.64 GiB |
| prometheus-k8s-db-prometheus-k8s-1 | 20 GiB | 7.83 GiB |
| alertmanager-main-db-alertmanager-main-0 | 20 GiB | 175 MiB |
| alertmanager-main-db-alertmanager-main-1 | 20 GiB | 175 MiB |
| alertmanager-main-db-alertmanager-main-2 | 20 GiB | 175 MiB |
| prometheus-user-workload-db-prometheus-user-workload-0 | 20 GiB | 177.6 MiB |
| prometheus-user-workload-db-prometheus-user-workload-1 | 20 GiB | 177.6 MiB |
| thanos-ruler-user-workload-data-thanos-ruler-user-workload-0 | 20 GiB | 175 MiB |
| thanos-ruler-user-workload-data-thanos-ruler-user-workload-1 | 20 GiB | 175.1 MiB |
■ ロギング用
| 永続ボリューム要求 | 容量 | 使用量 |
|---|---|---|
| elasticsearch-elasticsearch-cdm-885k66by-1 | 40 GiB | 23.92 GiB |
| elasticsearch-elasticsearch-cdm-885k66by-2 | 40 GiB | 23.86 GiB |
| elasticsearch-elasticsearch-cdm-885k66by-3 | 40 GiB | 23.89 GiB |