はじめに

この記事では、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