在本地存储运营商上创建日志和监控的持久卷
概述
以下是关于使用OCP 4.10环境下的本地存储操作符创建日志记录和监控持久卷(PV)时的备忘录。
记录和监控PV建议使用块存储。
- OCP 4.10 Docs / スケーラビリティーおよびパフォーマンス / 10. ストレージの最適化 / 10.2. 設定可能な推奨のストレージ技術
区块量支持如下。
- OCP 4.10 Docs / ストレージ / 3. 永続ストレージについて / 3.5. ブロックボリュームのサポート
在建立验证环境时，可能会遇到以下情况：既没有符合CIS标准的存储产品，也无法提供满足OpenShift Data Foundation配置需求的节点规格。另外，可能无法使用验证环境的vCenter管理员用户权限，也无法使用vSphere的CSI驱动程序提供的永久存储卷，这使得准备块卷的永久存储卷相当困难。
即使是在这种情况下，使用本地存储运算符，您也可以在本地环境中创建块卷。本次将使用local-storage运算符的LocalVolume资源来配置记录和监控的步骤。
- OCP 4.10 Docs / ストレージ / 4. CONFIGURING PERSISTENT STORAGE / 4.10. ローカルボリュームを使用した永続ストレージ / 4.10.2. ローカルストレージ Operator を使用したローカルボリュームのプロビジョニング
构成
OCP的组成
这篇文章中提到的OCP集群的前提配置是基于已经安装了OCP 4.10的配置。
Qiita / OpenShift 4.10 ベアメタルUPI (iPXE) インストール
OCP 4.10をベアメタルのUPIでインストールしています。
ベアメタルのUPIの構成ですが、node自体はVMwareの仮想マシンで作成しています。
基础设施节点
创建基础设施节点的步骤如下：
Qiita / OpenShiftでMachine Config Pool (MCP) を使用してInfra nodeを作成する
モニタリングは、デフォルトのモニタリング(prometheusk8s、alertmanager)のみで、ユーザーワークロードモニタリングはここでは入れていません。
クラスターロギングは、このリンク先で導入したElasticsearch、Fluentd、Kibanaの構成です。
构图
以下是此次的基础结点和虚拟硬盘，以及通过本地卷进行PV配置的构建图。
硬盘配置（虚拟机）
(添加) 虚拟机配置(disk.EnableUUID (/dev/disk/by-id))
建议使用”/dev/disk/by-id/”来定义LocalVolume资源的devicePaths。
因此，本次将使用”/dev/disk/by-id/”进行指定。
在vSphere环境的虚拟机中，为了让客户操作系统RHCOS认识到/dev/disk/by-id，需要在虚拟机的详细设置中将disk.EnableUUID设为TRUE。无论是bare metal UPI的步骤还是OCP 4.10文档中的vSphere UPI安装指南，都有提到需要设置disk.enableUUID: TRUE。
-
- KB / How to get the WWID of the disk within a RHEL guest on VMware ESX host?
-
- KB / How to check and set the disk.EnableUUID parameter from VM in vSphere for Openshift Container Platform.
- Qiita / OCS(OpenShift Container Storage)をインターナルモードで作成する
所以，这次我也会安排这个设置。
一般来说，在本地卷上创建持久卷是为了日志记录和监控使用的，仅仅针对基础设施节点。但是，可能也会在本地卷上创建用于应用程序Pod的持久卷，因此我们会在所有节点的虚拟机上统一进行这个设置。
-
- 仮想マシンの「設定の編集」画面を表示
-
- 「設定の編集」画面の「仮想マシンオプション」タブを表示
-
- 「仮想マシンオプション」タブの「詳細」->「設定パラメータ」欄の「設定の編集」のリンクをクリック
-
- - 表示される「設定のパラメータ」画面で「設定の追加」をクリックし、以下を入力してOKをクリック
名前: disk.EnableUUID
値: TRUE
設定されていることを確認
(補充) 在VMware虚拟机中，虚拟硬盘和Linux上的设备识别
以下可以参考 VMware 的虚拟机虚拟磁盘和 Linux 上设备的识别。
-
- VMware におけるSCSIコントローラの認識順序
- KB / 仮想マシンの SCSI コントローラを変更すると VMware vSphere ESXi でハード ディスクの順序が変わる (2135969)
根据上述链接中的信息，对于VMware虚拟机的虚拟硬盘，只要在同一SCSI控制器内，虚拟硬盘号将按照SCSI地址顺序被操作系统识别，并且操作系统会按照字母顺序识别为/dev/sdx，其中x为字母。本次RHCOS的操作系统区域位于infra节点的虚拟机的虚拟硬盘#1 (SCSI(0: 0))，被识别为/dev/sda，而日志和监控的虚拟硬盘将按照SCSI控制器0中的SCSI地址顺序去创建。如果不做特别意识，在普通情况下添加虚拟硬盘时会自动按照这种顺序进行，所以实际上不太需要特别关注此问题。
(補充)
LocalVolume资源的devicePaths可以使用/dev/sdb等设备名称进行设置。尤其是在本次创建虚拟硬盘时，我们要注重SCSI控制器和地址的意义，所以不会出现udev识别方面的偏差，例如/dev/sdb。但在本次操作中，我们按照推荐的方式使用/dev/disk/by-id/进行指定。
磁盘配置（日志记录）
-
- OCP 4.10 Docs / ロギング / 3. OPENSHIFT LOGGING のインストール / 3.1. Web コンソールを使用した OpenShift Logging のインストール
-
- OCP 4.10 Docs / ロギング / 4. ロギングデプロイメントの設定 / 4.3. ログストアの設定
-
- OCP 4.10 Docs / ロギング / 4. ロギングデプロイメントの設定 / 4.3. ログストアの設定 / 4.3.2. ログ保持時間の設定
- OCP 4.10 Docs / ロギング / 4. ロギングデプロイメントの設定 / 4.3. ログストアの設定 / 4.3.6. ログストアの永続ストレージの設定
有三个副本为1的部署创建了三个 Elasticsearch，通过将 infra-0[1-3] 上的三个 PV 分别绑定到它们，使得三个 Pod 可以在 infra-0[1-3] 上分别运行。
如果参考上述文档，在安装时，elasticsearch的PVC实例被规定为200G，并且默认情况下将在7天后被删除。
日志的容量，只有实际操作才能知道确切的大小，但由于我们在验证环境中无法提供大容量，所以容量设置为80G，并且设定为在1天后删除。
(虽然有提到索引大小会大于40GB x 主分片数，但由于我们设定为在1天后删除，所以目前暂时不太担心这个问题。)
记录
用途nodeVMの仮想ハードディスクSCSIアドレスOSでのデバイス名/dev/disk/by-id/xxx容量(GiB)Elasticsearchinfra-0[1-3]ハードディスク 2SCSI(0: 1)/dev/sdb後ほどスクリプトで洗い出し80
磁盘配置（监控）
由于prometheusK8s的replicas设为2，一个Statefulset能够创建出一个副本，所以我们可以使用infra-0[1-3]三个持久化卷中的任意两个，在infra-0[1-3]的任意两个节点上运行两个Pod。(*1)
由于alertmanagerMain的replicas设为2，一个Statefulset能够创建出一个副本，所以我们可以使用infra-0[1-3]三个持久化卷中的任意两个，在infra-0[1-3]的任意两个节点上运行两个Pod。(*1)
根据以下数据参考，在拥有50个节点和1800个Pod的情况下，Prometheus存储每天会增加6.3GB，15天后将达到94GB。
- OCP 4.10 Docs / スケーラビリティーおよびパフォーマンス / 8. CLUSTER MONITORING OPERATOR のスケーリング / 8.1. Prometheus データベースのストレージ要件
另外，根据以下内容，Prometheus度量数据的保留期默认为15天。
- OCP 4.10 Docs / モニタリング / 2. モニタリングスタックの設定 / 2.8. 永続ストレージの設定
由于这次的验证环境中节点和Pod的数量都不是很多，所以我将设置中的2.8.2.永久性本地存储请求（PVC）的示例容量设置为大约40Gi。
然而，由于验证环境的磁盘容量并不很大，所以我将磁盘保留期限更改为大约3天。
Alertmanager使用的磁盘空间并不多，所以可以设置较小的容量，但根据上述的示例，我选择了大约10Gi。
（监控）
用途nodeVMの仮想ハードディスクSCSIアドレスOSでのデバイス名/dev/disk/by-id/xxx容量(GiB)prometheusK8sinfra-0[1-3]ハードディスク 3SCSI(0: 2)/dev/sdc後ほどスクリプトで洗い出し40alertmanagerMaininfra-0[1-3]ハードディスク 4SCSI(0: 3)/dev/sdd後ほどスクリプトで洗い出し10
这次我们没有引入用户工作负载监控。如果要添加的话，在验证环境中可以按照以下方式进行。
用途nodeVMの仮想ハードディスクSCSIアドレスOSでのデバイス名/dev/disk/by-id/xxx容量(GiB)prometheusinfra-0[1-3]ハードディスク 5SCSI(0: 4)/dev/sde後ほどスクリプトで洗い出し40thanosRulerinfra-0[1-3]ハードディスク 6SCSI(0: 5)/dev/sdf後ほどスクリプトで洗い出し10
以前的OCP 4.9版本中，alertmanagerMain创建了一个replicas为3的Statefulset，并通过绑定来自infra-0[1-3]的三个PV，使得三个Pod在每个infra-0[1-3]上分别运行。
然而，自OCP 4.10版本开始，replicas被更改为2。根据OCP 4.10发布注记
1.3.20.7
1.8 已知的问题在本次情况下，由于infra节点上的虚拟硬盘配置都相同，由于prometheusK8s和alertmanagerMain的replica数为2，因此将会有一个infra节点的PV无法使用。
由于LocalVolume资源的devicePaths是通过/dev/disk/by-id/指定的，所以原本只需在需要的infra节点上创建所需数量的虚拟硬盘即可。然而，在infra-0[1-3]上虚拟硬盘配置发生了变化。
这样一来，在创建初始配置时可能会变得难以理解，而且在稍后参考KB或其他资源时需要以/dev/sdx作为关键来查找/dev/disk/by-id/。因此，为了方便理解，这次将infra-0[1-3]的虚拟硬盘配置（即使有多余的）故意设置成相同。
在RHCOS上确认磁盘的识别。
请确保从vCenter创建的虚拟硬盘能够在RHCOS操作系统上被正确识别。（虚拟硬盘的SCSI地址按照顺序排列为/dev/sdb和sdc）。（本文不涵盖用于用户工作负载监控的虚拟硬盘的配置）。
[root@bastion-01 ~]# ssh core@infra-01 -- lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 40G 0 disk
|-sda1 8:1 0 1M 0 part
|-sda2 8:2 0 127M 0 part
|-sda3 8:3 0 384M 0 part /boot
`-sda4 8:4 0 39.5G 0 part /sysroot
sdb 8:16 0 80G 0 disk
sdc 8:32 0 40G 0 disk
sdd 8:48 0 10G 0 disk
sde 8:64 0 40G 0 disk
sdf 8:80 0 10G 0 disk
sr0 11:0 1 1024M 0 rom
[root@bastion-01 ~]#
[root@bastion-01 ~]# ssh core@infra-02 -- lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 40G 0 disk
|-sda1 8:1 0 1M 0 part
|-sda2 8:2 0 127M 0 part
|-sda3 8:3 0 384M 0 part /boot
`-sda4 8:4 0 39.5G 0 part /sysroot
sdb 8:16 0 80G 0 disk
sdc 8:32 0 40G 0 disk
sdd 8:48 0 10G 0 disk
sde 8:64 0 40G 0 disk
sdf 8:80 0 10G 0 disk
sr0 11:0 1 1024M 0 rom
[root@bastion-01 ~]#
[root@bastion-01 ~]# ssh core@infra-03 -- lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 40G 0 disk
|-sda1 8:1 0 1M 0 part
|-sda2 8:2 0 127M 0 part
|-sda3 8:3 0 384M 0 part /boot
`-sda4 8:4 0 39.5G 0 part /sysroot
sdb 8:16 0 80G 0 disk
sdc 8:32 0 40G 0 disk
sdd 8:48 0 10G 0 disk
sde 8:64 0 40G 0 disk
sdf 8:80 0 10G 0 disk
sr0 11:0 1 1024M 0 rom
[root@bastion-01 ~]#
在/dev/disk/by-id/目录下，会显示与sdb和sdc等链接的三个条目。（以sdb为例）
-
- /dev/disk/by-id/scsi-36000c29345d1023bd04cbaba37b62c17
-
- /dev/disk/by-id/scsi-SVMware_Virtual_disk_6000c29345d1023bd04cbaba37b62c17
- /dev/disk/by-id/wwn-0x6000c29345d1023bd04cbaba37b62c17
这次，我们将在LocalVolume资源的devicePaths中指定/dev/disk/by-id/scsi-36000xxxxxx。
[root@bastion-01 ~]# ssh core@infra-01 -- "ls -l /dev/disk/by-id/ | grep sdb"
lrwxrwxrwx. 1 root root 9 May 25 10:10 scsi-36000c29345d1023bd04cbaba37b62c17 -> ../../sdb
lrwxrwxrwx. 1 root root 9 May 25 10:10 scsi-SVMware_Virtual_disk_6000c29345d1023bd04cbaba37b62c17 -> ../../sdb
lrwxrwxrwx. 1 root root 9 May 25 10:10 wwn-0x6000c29345d1023bd04cbaba37b62c17 -> ../../sdb
[root@bastion-01 ~]#
[root@bastion-01 ~]# ssh core@infra-01 -- "ls -l /dev/disk/by-id/ | grep sdb | grep scsi-36000"
lrwxrwxrwx. 1 root root 9 May 25 10:10 scsi-36000c29345d1023bd04cbaba37b62c17 -> ../../sdb
[root@bastion-01 ~]#
以下的知识库非常有参考价值，可以通过使用/ dev/sdb，sdc等作为键来列出/ dev/disk/by-id/中infra-0[1-3]的所有选项。
- KB / How to list the local disk IDs for every OCS worker in Openshift 4.x
（补足）
本知识库中的内容是关于如何使用OpenShift Data Foundation与Local Storage Operator结合使用来查找可以使用的磁盘/dev/disk/by-id/。
由于本次计划仅使用Local Storage Operator，因此没有创建用于OpenShift Data Foundation的存储节点。
因此，文中提到的ocs-disk-gatherer-own-project.yaml文件需要进行一些修改。
例如，需要根据本次基础设施节点或工作节点相应地修改以下存储节点的node selector和tolerations的值。
这次我没有使用之前提到的KB的方法，而是直接在infra node上使用grep等命令进行搜索/dev/disk/by-id/scsi-36000xxxxxxxx。
（稍后会在LocalVolume的清单文件中使用以下命令输出。我会添加空格等以便能够直接复制粘贴。）
[root@bastion-01 ~]# for disk in sd{b..f}; do echo ----------------; echo $disk; for node in infra-0{1..3}; do echo " - /dev/disk/by-id/$(ssh core@$node -- "ls -l /dev/disk/by-id/ | grep scsi-36000" | grep $disk | awk '{print $9}')"; done; done
----------------
sdb
- /dev/disk/by-id/scsi-36000c29345d1023bd04cbaba37b62c17
- /dev/disk/by-id/scsi-36000c2952611aa4f13bd8198b3340d91
- /dev/disk/by-id/scsi-36000c298a8b8798a0fdc29981a9bb243
----------------
sdc
- /dev/disk/by-id/scsi-36000c29a5f70b6bd1f25aca63b360dc6
- /dev/disk/by-id/scsi-36000c295cf468146795091b2b9f21a1d
- /dev/disk/by-id/scsi-36000c293a4d6fdfad46a19b223238e5c
----------------
sdd
- /dev/disk/by-id/scsi-36000c292c64adf34d67ff0080ec8686a
- /dev/disk/by-id/scsi-36000c298ec479efbc44f98d673edc887
- /dev/disk/by-id/scsi-36000c29f96a0a5aa5dc5a6204d02874a
----------------
sde
- /dev/disk/by-id/scsi-36000c29ee83b515115cf2ca8e357915d
- /dev/disk/by-id/scsi-36000c2979c9e48a8beb1d23a7e41d85e
- /dev/disk/by-id/scsi-36000c29476519e125b18652d21cd3c90
----------------
sdf
- /dev/disk/by-id/scsi-36000c29d26c476bf6f90b9ee4f7581ef
- /dev/disk/by-id/scsi-36000c29e6376eae73ad5a02bd0ef5f35
- /dev/disk/by-id/scsi-36000c2924a75fdc65b262812b3267e29
[root@bastion-01 ~]#
本地存储操作器的安装
请按照以下链接中的步骤安装Local Storage Operator。
这次我们是从OCP的 Web 控制台进行安装的。
-
- OCP 4.10 Docs / ストレージ / 4. Configuring persistent storage / 4.10. ローカルボリュームを使用した永続ストレージ
- OCP 4.10 Docs / ストレージ / 4. Configuring persistent storage / 4.10. ローカルボリュームを使用した永続ストレージ / 4.10.1. ローカルストレージ Operator のインストール
创建用于安装本地存储操作员的项目
创建一个安装Local Storage Operator的项目。
项目名称将按照文档设定为openshift-local-storage。
[root@bastion-01 ~]# oc adm new-project openshift-local-storage
Created project openshift-local-storage
[root@bastion-01 ~]#
为 openshift-local-storage 项目（命名空间）添加附加配置。
在创建了OpenShift本地存储项目（命名空间）后，如果在清单的.spec.nodeSelector中指定了节点，那么会自动在该节点上运行名为diskmaker-manager的守护进程Pod。
在以前的版本中，根据LocalVolume资源的数量创建了-local-diskmaker和-local-provisioner守护程序Pod的DaemonSet。但是在OCP 4.10中，创建LocalVolume的节点会有一个diskmaker-manager守护程序Pod的DaemonSet（不是每个LocalVolume，而是每个节点中只有一个）。
监控和日志记录PV是由LocalVolume资源创建在基础设施节点的RHCOS硬盘上。
如果将PV用于应用程序Pod，同样要使用LocalVolume资源，并且会在工作节点的RHCOS硬盘上创建。
因此，需要将此diskmaker-manager Pod 部署在基础结点和工作结点上。
本次使用Qiita / OpenShift的Machine Config Pool (MCP)来创建基础架构节点的步骤。
为了使以上的Pod能够在infra节点和worker节点中任意节点运行，我们需要确认如何设置使应用程序Pod不在infra节点上运行。
本次是将”在基础结点上不运行应用程序Pod的配置”作为”(1)仅使用nodeSelector”。
在这种情况下，如果未明确设置nodeSelector到openshift-local-storage项目（命名空间），则应用程序既可以在基础结点上运行，也可以在工作结点上运行。
因此，在本次情况下并不太需要，但为了确保不受集群单元的默认nodeSelector影响，我按照OCP文档的要求，在openshift-local-storage项目（命名空间）中也设置了忽略默认nodeSelector的配置。
[root@bastion-01 ~]# oc annotate project openshift-local-storage openshift.io/node-selector=''
project.project.openshift.io/openshift-local-storage annotated
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get project openshift-local-storage -o yaml | grep -A 7 " annotations:"
annotations:
openshift.io/description: ""
openshift.io/display-name: ""
openshift.io/node-selector: ""
openshift.io/sa.scc.mcs: s0:c26,c15
openshift.io/sa.scc.supplemental-groups: 1000680000/10000
openshift.io/sa.scc.uid-range: 1000680000/10000
creationTimestamp: "2022-05-16T12:10:38Z"
[root@bastion-01 ~]#
如果在infra node上设置了taint，当使用”在infra node上运行应用Pod”的设置中，使用了”（2）使用nodeSelector和taint/toleration”的方法时，由于infra node上有taint，所以需要在LocalVolume资源中设置toleration。
安装本地存储操作器
这次我们将从OCP的Web控制台安装本地存储运算符。
使用具有cluster-admin角色的管理员用户登录到OpenShift容器平台Web控制台，然后从左侧菜单中选择操作员->操作员中心。
在「Operator安装」页面上，选择「集群指定的命名空间」。这次我们可以看到刚刚创建的openshift-local-storage显示在其中。
其他设置，如「安装模式」和「更新批准」等，我们按如下方式进行了配置。
配置完毕后，点击「安装」按钮。
設定項目デフォルト値設定値備考更新チャネルstable4.10案件では通常バージョンを明確に管理する必要があることが多いのでチャネルはバージョン名のものにしておきました。インストールモードクラスターの特定のnamespaceデフォルトのまま
インストール済みのnamespaceOperator推奨のnamespace (openshift-local-storage)デフォルトのまま
更新の承認自動デフォルトのまま(※)実案件ではコンポーネントのバージョンは明確に管理する必要があったり、アップデートするタイミングを業務外にする必要があることがあります。
そのような場合には、自動でチャネル内の最新のパッチバージョンに更新されないようにするため「手動」にしたりします。
インストール済みのnamespaceOperator推奨のnamespace (openshift-local-storage)デフォルトのまま
更新の承認自動デフォルトのまま(※)実案件ではコンポーネントのバージョンは明確に管理する必要があったり、アップデートするタイミングを業務外にする必要があることがあります。
そのような場合には、自動でチャネル内の最新のパッチバージョンに更新されないようにするため「手動」にしたりします。
由于操作员的Pod本身没有特定的nodeSelector设置，因此可以在任意的基础设施或工作节点上运行。
[root@bastion-01 ~]# oc get pod -n openshift-local-storage
NAME READY STATUS RESTARTS AGE
local-storage-operator-68cfffb766-lgs85 1/1 Running 0 2m47s
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get pod -n openshift-local-storage -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
local-storage-operator-68cfffb766-lgs85 1/1 Running 0 2m53s 10.131.2.12 worker-01 <none> <none>
[root@bastion-01 ~]#
创建LocalVolume资源
- OCP 4.10 Docs / ストレージ / 4. CONFIGURING PERSISTENT STORAGE / 4.10. ローカルボリュームを使用した永続ストレージ / 4.10.2. ローカルストレージ Operator を使用したローカルボリュームのプロビジョニング
创建清单文件
移动到创建清单文件的工作目录中。
[root@bastion-01 ~]# ls -l work/manifest/
合計 0
drwxr-xr-x. 2 root root 118 3月 26 18:59 chrony
drwxr-xr-x. 2 root root 49 4月 1 21:18 htpasswd
drwxr-xr-x. 2 root root 6 5月 17 14:05 localvolume
drwxr-xr-x. 2 root root 41 5月 16 20:26 logging
drwxr-xr-x. 2 root root 28 5月 9 20:33 mcp
drwxr-xr-x. 2 root root 47 5月 13 19:50 monitoring
drwxr-xr-x. 2 root root 55 5月 9 20:28 pv
[root@bastion-01 ~]#
[root@bastion-01 ~]# cd work/manifest/localvolume/
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# ls -l
合計 0
[root@bastion-01 localvolume]#
创建用于日志记录和监控的LocalVolume资源的清单文件。
[root@bastion-01 localvolume]# vi localvolume-elasticsearch.yaml
[root@bastion-01 localvolume]# vi localvolume-prometheusk8s.yaml
[root@bastion-01 localvolume]# vi localvolume-alertmanagermain.yaml
[root@bastion-01 localvolume]# vi localvolume-prometheus.yaml
[root@bastion-01 localvolume]# vi localvolume-thanosruler.yaml
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# ls -l
合計 20
-rw-r--r--. 1 root root 648 5月 17 16:16 localvolume-alertmanagermain.yaml
-rw-r--r--. 1 root root 642 5月 17 16:15 localvolume-elasticsearch.yaml
-rw-r--r--. 1 root root 636 5月 17 16:17 localvolume-prometheus.yaml
-rw-r--r--. 1 root root 642 5月 17 16:16 localvolume-prometheusk8s.yaml
-rw-r--r--. 1 root root 638 5月 17 16:17 localvolume-thanosruler.yaml
[root@bastion-01 localvolume]#
记录/logging
- elasticsearchでは、先ほど確認したinfra-0[1-3]の/dev/sdbの/dev/by-id/scsi-36000xxxxxxを指定します。
apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
name: "localvolume-elasticsearch"
namespace: "openshift-local-storage"
spec:
nodeSelector:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- infra-01
- infra-02
- infra-03
storageClassDevices:
- storageClassName: "local-elasticsearch"
volumeMode: Filesystem
fsType: xfs
devicePaths:
- /dev/disk/by-id/scsi-36000c29345d1023bd04cbaba37b62c17
- /dev/disk/by-id/scsi-36000c2952611aa4f13bd8198b3340d91
- /dev/disk/by-id/scsi-36000c298a8b8798a0fdc29981a9bb243
监控
- prometheusK8sでは、先ほど確認したinfra-0[1-3]の/dev/sdcの/dev/by-id/scsi-36000xxxxxxを指定します。
apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
name: "localvolume-prometheusk8s"
namespace: "openshift-local-storage"
spec:
nodeSelector:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- infra-01
- infra-02
- infra-03
storageClassDevices:
- storageClassName: "local-prometheusk8s"
volumeMode: Filesystem
fsType: xfs
devicePaths:
- /dev/disk/by-id/scsi-36000c29a5f70b6bd1f25aca63b360dc6
- /dev/disk/by-id/scsi-36000c295cf468146795091b2b9f21a1d
- /dev/disk/by-id/scsi-36000c293a4d6fdfad46a19b223238e5c
- alertmanagermainでは、先ほど確認したinfra-0[1-3]の/dev/sddの/dev/by-id/scsi-36000xxxxxxを指定します。
apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
name: "localvolume-alertmanagermain"
namespace: "openshift-local-storage"
spec:
nodeSelector:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- infra-01
- infra-02
- infra-03
storageClassDevices:
- storageClassName: "local-alertmanagermain"
volumeMode: Filesystem
fsType: xfs
devicePaths:
- /dev/disk/by-id/scsi-36000c292c64adf34d67ff0080ec8686a
- /dev/disk/by-id/scsi-36000c298ec479efbc44f98d673edc887
- /dev/disk/by-id/scsi-36000c29f96a0a5aa5dc5a6204d02874a
创建本地Volume资源
将已创建的清单文件应用。
在适用前，尚未存在LocalVolume资源或PV。
[root@bastion-01 ~]# oc get localvolume -n openshift-local-storage
No resources found in openshift-local-storage namespace.
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get pod -n openshift-local-storage -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
local-storage-operator-68cfffb766-lgs85 1/1 Running 2 19h 10.131.2.2 worker-01 <none> <none>
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
image-registry-storage 100Gi RWX Retain Bound openshift-image-registry/image-registry-storage image-registry 44d
[root@bastion-01 ~]#
应用LocalVolume资源的清单文件。
[root@bastion-01 ~]# cd work/manifest/localvolume/
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# ls -l
合計 20
-rw-r--r--. 1 root root 696 5月 17 17:08 localvolume-alertmanagermain.yaml
-rw-r--r--. 1 root root 690 5月 17 17:08 localvolume-elasticsearch.yaml
-rw-r--r--. 1 root root 684 5月 17 17:08 localvolume-prometheus.yaml
-rw-r--r--. 1 root root 690 5月 17 17:08 localvolume-prometheusk8s.yaml
-rw-r--r--. 1 root root 686 5月 17 17:08 localvolume-thanosruler.yaml
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# oc apply -f localvolume-elasticsearch.yaml
localvolume.local.storage.openshift.io/localvolume-elasticsearch created
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# oc apply -f localvolume-prometheusk8s.yaml
localvolume.local.storage.openshift.io/localvolume-prometheusk8s created
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# oc apply -f localvolume-alertmanagermain.yaml
localvolume.local.storage.openshift.io/localvolume-alertmanagermain created
[root@bastion-01 localvolume]#
创建用于日志记录和监控的本地存储卷资源，并创建相应的存储类（SC）和永久卷（PV）。
[root@bastion-01 localvolume]# oc get localvolume -n openshift-local-storage
NAME AGE
localvolume-alertmanagermain 19s
localvolume-elasticsearch 34s
localvolume-prometheusk8s 26s
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# oc get pod -n openshift-local-storage -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
diskmaker-manager-bzpfr 2/2 Running 0 25s 10.128.2.18 infra-02 <none> <none>
diskmaker-manager-j878w 2/2 Running 0 19s 10.130.2.18 infra-03 <none> <none>
diskmaker-manager-xnxgk 2/2 Running 0 24s 10.131.0.52 infra-01 <none> <none>
local-storage-operator-68cfffb766-lgs85 1/1 Running 2 20h 10.131.2.2 worker-01 <none> <none>
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# oc get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
local-alertmanagermain kubernetes.io/no-provisioner Delete WaitForFirstConsumer false 35s
local-elasticsearch kubernetes.io/no-provisioner Delete WaitForFirstConsumer false 50s
local-prometheusk8s kubernetes.io/no-provisioner Delete WaitForFirstConsumer false 42s
[root@bastion-01 localvolume]#
PV在infra-0[1..3]上為每個組件創建了三個。
[root@bastion-01 localvolume]# oc get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
image-registry-storage 100Gi RWX Retain Bound openshift-image-registry/image-registry-storage image-registry 44d
local-pv-13e978f0 40Gi RWO Delete Available local-prometheusk8s 44s
local-pv-476b4e36 80Gi RWO Delete Available local-elasticsearch 47s
local-pv-6a3a9d54 40Gi RWO Delete Available local-prometheusk8s 44s
local-pv-6cb91dfa 10Gi RWO Delete Available local-alertmanagermain 27s
local-pv-aec025c7 80Gi RWO Delete Available local-elasticsearch 45s
local-pv-e646c476 40Gi RWO Delete Available local-prometheusk8s 44s
local-pv-e7a740c6 80Gi RWO Delete Available local-elasticsearch 47s
local-pv-f209ee07 10Gi RWO Delete Available local-alertmanagermain 37s
local-pv-fc84cac 10Gi RWO Delete Available local-alertmanagermain 38s
[root@bastion-01 localvolume]#
设置持续监控和日志记录的卷的参数。
配置并监控使用所创建的PV。
监控
-
- OCP 4.10 Docs / スケーラビリティーおよびパフォーマンス / 8. CLUSTER MONITORING OPERATOR のスケーリング / 8.1. Prometheus データベースのストレージ要件
-
- OCP 4.10 Docs / モニタリング / 2. モニタリングスタックの設定 / 2.8. 永続ストレージの設定
-
- OCP 4.10 Docs / モニタリング / 2.8. 永続ストレージの設定 / 2.8.2. ローカ永続ボリューム要求 (PVC）の設定
- OCP 4.10 Docs / モニタリング / 2.8. 永続ストレージの設定 / 2.8.3. Prometheus メトリクスデータの保持期間の変更
请在监控设置的ConfigMap的清单文件中修改，以使用先前创建的PV。
修正前的用于监控设置的ConfigMap的清单文件将基于“在OpenShift中使用Machine Config Pool (MCP)创建Infra节点 / 将运维组件的Infra节点移动 / 进行监控”的说明进行编写。
本次将在prometheusK8s和alertmanagerMain的volumeClaimTemplate.spec.storageClassName中定义之前通过LocalVolume资源创建的SC名称。
由于本次没有占用太多的磁盘空间，所以将retention的天数设置为3d。
[root@bastion-01 ~]# cd work/manifest/monitoring/
[root@bastion-01 monitoring]#
[root@bastion-01 monitoring]# cp -p cluster-monitoring-configmap.yaml cluster-monitoring-configmap.yaml.bak.20220517
[root@bastion-01 monitoring]# vi cluster-monitoring-configmap.yaml
[root@bastion-01 monitoring]#
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-monitoring-config
namespace: openshift-monitoring
data:
config.yaml: |+
alertmanagerMain:
nodeSelector:
node-role.kubernetes.io/infra: ""
volumeClaimTemplate:
spec:
storageClassName: local-alertmanagermain
resources:
requests:
storage: 10Gi
prometheusK8s:
retention: 3d
nodeSelector:
node-role.kubernetes.io/infra: ""
volumeClaimTemplate:
spec:
storageClassName: local-prometheusk8s
resources:
requests:
storage: 40Gi
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: ""
应用已创建的ConfigMap的清单文件。
[root@bastion-01 ~]# cd work/manifest/monitoring/
[root@bastion-01 monitoring]#
[root@bastion-01 monitoring]# oc apply -f cluster-monitoring-configmap.yaml
configmap/cluster-monitoring-config configured
[root@bastion-01 monitoring]#
确认设置内容已经反映出来。
[root@bastion-01 monitoring]# oc get configmap -n openshift-monitoring cluster-monitoring-config -o yaml
apiVersion: v1
data:
config.yaml: |
alertmanagerMain:
nodeSelector:
node-role.kubernetes.io/infra: ""
volumeClaimTemplate:
spec:
storageClassName: local-alertmanagermain
resources:
requests:
storage: 10Gi
prometheusK8s:
retention: 3d
nodeSelector:
node-role.kubernetes.io/infra: ""
volumeClaimTemplate:
spec:
storageClassName: local-prometheusk8s
resources:
requests:
storage: 40Gi
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: ""
kind: ConfigMap
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","data":{"config.yaml":"alertmanagerMain:\n nodeSelector:\n node-role.kubernetes.io/infra: \"\"\n volumeClaimTemplate:\n spec:\n storageClassName: local-alertmanagermain\n resources:\n requests:\n storage: 10Gi\nprometheusK8s:\n retention: 3d\n nodeSelector:\n node-role.kubernetes.io/infra: \"\"\n volumeClaimTemplate:\n spec:\n storageClassName: local-prometheusk8s\n resources:\n requests:\n storage: 40Gi\nprometheusOperator:\n nodeSelector:\n node-role.kubernetes.io/infra: \"\"\ngrafana:\n nodeSelector:\n node-role.kubernetes.io/infra: \"\"\nk8sPrometheusAdapter:\n nodeSelector:\n node-role.kubernetes.io/infra: \"\"\nkubeStateMetrics:\n nodeSelector:\n node-role.kubernetes.io/infra: \"\"\ntelemeterClient:\n nodeSelector:\n node-role.kubernetes.io/infra: \"\"\nopenshiftStateMetrics:\n nodeSelector:\n node-role.kubernetes.io/infra: \"\"\nthanosQuerier:\n nodeSelector:\n node-role.kubernetes.io/infra: \"\"\n"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"cluster-monitoring-config","namespace":"openshift-monitoring"}}
creationTimestamp: "2022-05-13T10:56:50Z"
name: cluster-monitoring-config
namespace: openshift-monitoring
resourceVersion: "23356132"
uid: a4c70d4f-d2ec-40e4-b60e-5be1bc6c903d
检查 Prometheus-k8s 和 alertmanager-main 的 Pod 是否开始使用 PV。
在 OCP 4.10 中，它们的副本数都是 “2”。
[root@bastion-01 monitoring]# oc get statefulsets.apps -n openshift-monitoring
NAME READY AGE
alertmanager-main 2/2 2m6s
prometheus-k8s 2/2 2m11s
[root@bastion-01 monitoring]#
Pod已重新创建，在两个基础设施节点上运行。（这次恰好都是infra-01和infra-02上运行。）
[root@bastion-01 monitoring]# oc get pod -n openshift-monitoring -o wide | grep prometheus-k8s
prometheus-k8s-0 6/6 Running 0 3m9s 10.128.2.19 infra-02 <none> <none>
prometheus-k8s-1 6/6 Running 0 3m9s 10.131.0.59 infra-01 <none> <none>
[root@bastion-01 monitoring]#
[root@bastion-01 monitoring]# oc get pod -n openshift-monitoring -o wide | grep alertmanager-main
alertmanager-main-0 6/6 Running 0 3m14s 10.128.2.20 infra-02 <none> <none>
alertmanager-main-1 6/6 Running 0 3m14s 10.131.0.60 infra-01 <none> <none>
[root@bastion-01 monitoring]#
PVC已为每个Pod创建并绑定。
[root@bastion-01 monitoring]# oc get pvc -n openshift-monitoring
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
alertmanager-main-db-alertmanager-main-0 Bound local-pv-fc84cac 10Gi RWO local-alertmanagermain 3m46s
alertmanager-main-db-alertmanager-main-1 Bound local-pv-6cb91dfa 10Gi RWO local-alertmanagermain 3m46s
prometheus-k8s-db-prometheus-k8s-0 Bound local-pv-13e978f0 40Gi RWO local-prometheusk8s 3m51s
prometheus-k8s-db-prometheus-k8s-1 Bound local-pv-6a3a9d54 40Gi RWO local-prometheusk8s 3m51s
[root@bastion-01 monitoring]#
PV是两个基础节点中其中一个Pod正在运行的三个之一，这两个PV已与PVC绑定。
[root@bastion-01 monitoring]# oc get pv | grep local-prometheusk8s
local-pv-13e978f0 40Gi RWO Delete Bound openshift-monitoring/prometheus-k8s-db-prometheus-k8s-0 local-prometheusk8s 34m
local-pv-6a3a9d54 40Gi RWO Delete Bound openshift-monitoring/prometheus-k8s-db-prometheus-k8s-1 local-prometheusk8s 34m
local-pv-e646c476 40Gi RWO Delete Available local-prometheusk8s 34m
[root@bastion-01 monitoring]#
[root@bastion-01 monitoring]# oc get pv | grep local-alertmanagermain
local-pv-6cb91dfa 10Gi RWO Delete Bound openshift-monitoring/alertmanager-main-db-alertmanager-main-1 local-alertmanagermain 34m
local-pv-f209ee07 10Gi RWO Delete Available local-alertmanagermain 34m
local-pv-fc84cac 10Gi RWO Delete Bound openshift-monitoring/alertmanager-main-db-alertmanager-main-0 local-alertmanagermain 34m
[root@bastion-01 monitoring]#
记录
-
- OCP 4.10 Docs / ロギング / 3. OPENSHIFT LOGGING のインストール / 3.1. Web コンソールを使用した OpenShift Logging のインストール
-
- OCP 4.10 Docs / ロギング / 4. ロギングデプロイメントの設定 / 4.3. ログストアの設定
-
- OCP 4.10 Docs / ロギング / 4. ロギングデプロイメントの設定 / 4.3. ログストアの設定 / 4.3.2. ログ保持時間の設定
- OCP 4.10 Docs / ロギング / 4. ロギングデプロイメントの設定 / 4.3. ログストアの設定 / 4.3.6. ログストアの永続ストレージの設定
请修改ClusterLogging资源的清单文件，以使用先前创建的PV。
修正前的ClusterLogging的 manifests 文件用于 OpenShift 创建 Infra 节点使用 Machine Config Pool (MCP) / 将操作组件的 infra 节点迁移 / 日志记录。
这次我们将在elasticsearch的spec.logStore.elasticsearch.storage.storageClassName中定义先前由LocalVolume资源创建的存储类名。
由于这次没有使用太大的磁盘容量，所以retentionPolicy的天数设置为所有索引都为1天。
[root@bastion-01 ~]# cd work/manifest/monitoring/
[root@bastion-01 monitoring]#
[root@bastion-01 monitoring]# cp -p clo-instance-5.4-no-pv.yaml clo-instance-5.4-with-pv.yaml
[root@bastion-01 monitoring]# vi clo-instance-5.4-with-pv.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: 1d
audit:
maxAge: 1d
elasticsearch:
nodeCount: 3
nodeSelector:
node-role.kubernetes.io/infra: ''
storage:
storageClassName: local-elasticsearch
size: 80G
redundancyPolicy: "SingleRedundancy"
visualization:
type: "kibana"
kibana:
replicas: 1
nodeSelector:
node-role.kubernetes.io/infra: ''
collection:
logs:
type: "fluentd"
fluentd: {}
应用已创建的ClusterLogging清单文件
[root@bastion-01 ~]# cd work/manifest/logging/
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc apply -f clo-instance-5.4-with-pv.yaml
clusterlogging.logging.openshift.io/instance configured
[root@bastion-01 logging]#
确认设置内容已经反映。
[root@bastion-01 logging]# oc get clusterlogging -n openshift-logging instance -o yaml
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
annotations:
(略)
generation: 2
name: instance
namespace: openshift-logging
resourceVersion: "23382994"
uid: 57757036-7ab9-4327-b829-e215d0dd2445
spec:
collection:
logs:
fluentd: {}
type: fluentd
logStore:
elasticsearch:
nodeCount: 3
nodeSelector:
node-role.kubernetes.io/infra: ""
redundancyPolicy: SingleRedundancy
storage:
size: 80G
storageClassName: local-elasticsearch
retentionPolicy:
application:
maxAge: 1d
audit:
maxAge: 1d
infra:
maxAge: 1d
type: elasticsearch
managementState: Managed
visualization:
kibana:
nodeSelector:
node-role.kubernetes.io/infra: ""
replicas: 1
type: kibana
status:
(略)
应用清单文件后，如果什么都不做，elasticsearch的Pod将不会重新创建，并且不会立即使用PV。
（elasticsearch-cdm-xxxxxx的3个部署的Pod未重新创建。）
[root@bastion-01 logging]# oc get deployment -n openshift-logging
NAME READY UP-TO-DATE AVAILABLE AGE
cluster-logging-operator 1/1 1 1 22h
elasticsearch-cdm-hxg5zzyz-1 1/1 1 1 22h
elasticsearch-cdm-hxg5zzyz-2 1/1 1 1 22h
elasticsearch-cdm-hxg5zzyz-3 1/1 1 1 22h
kibana 1/1 1 1 22h
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get pod -n openshift-logging
NAME READY STATUS RESTARTS AGE
cluster-logging-operator-665847fd47-4k8nk 1/1 Running 2 22h
(略)
elasticsearch-cdm-hxg5zzyz-1-6c7cc986d5-r8vtk 2/2 Running 4 22h
elasticsearch-cdm-hxg5zzyz-2-6c459cd687-dd8kr 2/2 Running 4 22h
elasticsearch-cdm-hxg5zzyz-3-6c4c778db5-zttmd 2/2 Running 6 22h
(略)
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get pv | grep local-elasticsearch
local-pv-476b4e36 80Gi RWO Delete Available local-elasticsearch 88m
local-pv-aec025c7 80Gi RWO Delete Available local-elasticsearch 88m
local-pv-e7a740c6 80Gi RWO Delete Available local-elasticsearch 88m
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get pvc -n openshift-logging
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
elasticsearch-elasticsearch-cdm-hxg5zzyz-1 Pending local-elasticsearch 3m16s
elasticsearch-elasticsearch-cdm-hxg5zzyz-2 Pending local-elasticsearch 3m16s
elasticsearch-elasticsearch-cdm-hxg5zzyz-3 Pending local-elasticsearch 3m16s
[root@bastion-01 logging]#
为了重新创建Pod，需要将nodeCount设置为0，然后再恢复为3。此外，还需要仔细考虑执行OCP 4.10文档/4.3.8 Elasticsearch集群的滚动重启步骤等内容。但是，这次我选择简单地通过删除Deployment来重新创建Pod。
[root@bastion-01 logging]# oc get deploy -n openshift-logging
NAME READY UP-TO-DATE AVAILABLE AGE
cluster-logging-operator 1/1 1 1 23h
elasticsearch-cdm-hxg5zzyz-1 1/1 1 1 22h
elasticsearch-cdm-hxg5zzyz-2 1/1 1 1 22h
elasticsearch-cdm-hxg5zzyz-3 1/1 1 1 22h
kibana 1/1 1 1 22h
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc delete deploy -n openshift-logging elasticsearch-cdm-hxg5zzyz-1 elasticsearch-cdm-hxg5zzyz-2 elasticsearch-cdm-hxg5zzyz-3
deployment.apps "elasticsearch-cdm-hxg5zzyz-1" deleted
deployment.apps "elasticsearch-cdm-hxg5zzyz-2" deleted
deployment.apps "elasticsearch-cdm-hxg5zzyz-3" deleted
[root@bastion-01 logging]#
根据运算符的设置，Deployment将自动重新创建。
[root@bastion-01 logging]# oc get deploy -n openshift-logging
NAME READY UP-TO-DATE AVAILABLE AGE
cluster-logging-operator 1/1 1 1 23h
elasticsearch-cdm-hxg5zzyz-1 1/1 1 1 2m49s
elasticsearch-cdm-hxg5zzyz-2 1/1 1 1 2m48s
elasticsearch-cdm-hxg5zzyz-3 1/1 1 1 2m47s
kibana 1/1 1 1 22h
[root@bastion-01 logging]#
Pod已经重新创建，并在基础设施节点上运行。
[root@bastion-01 logging]# oc get pod -n openshift-logging -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
cluster-logging-operator-665847fd47-4k8nk 1/1 Running 2 23h 10.131.0.12 infra-01 <none> <none>
(略)
elasticsearch-cdm-hxg5zzyz-1-5f58bc7c98-7fvmd 2/2 Running 0 3m24s 10.128.2.21 infra-02 <none> <none>
elasticsearch-cdm-hxg5zzyz-2-75464f4897-rdm89 2/2 Running 0 3m23s 10.131.0.73 infra-01 <none> <none>
elasticsearch-cdm-hxg5zzyz-3-5cc5765cd4-g95ht 2/2 Running 0 3m22s 10.130.2.19 infra-03 <none> <none>
(略)
所有的PVC都被绑定到了Pod上。
[root@bastion-01 logging]# oc get pvc -n openshift-logging
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
elasticsearch-elasticsearch-cdm-hxg5zzyz-1 Bound local-pv-476b4e36 80Gi RWO local-elasticsearch 9m33s
elasticsearch-elasticsearch-cdm-hxg5zzyz-2 Bound local-pv-e7a740c6 80Gi RWO local-elasticsearch 9m33s
elasticsearch-elasticsearch-cdm-hxg5zzyz-3 Bound local-pv-aec025c7 80Gi RWO local-elasticsearch 9m33s
[root@bastion-01 logging]#
PV绑定到PVC上的是在3个运行中的基础结点上的Pod的PV。
[root@bastion-01 logging]# oc get pv | grep local-elasticsearch
local-pv-476b4e36 80Gi RWO Delete Bound openshift-logging/elasticsearch-elasticsearch-cdm-hxg5zzyz-1 local-elasticsearch 94m
local-pv-aec025c7 80Gi RWO Delete Bound openshift-logging/elasticsearch-elasticsearch-cdm-hxg5zzyz-3 local-elasticsearch 94m
local-pv-e7a740c6 80Gi RWO Delete Bound openshift-logging/elasticsearch-elasticsearch-cdm-hxg5zzyz-2 local-elasticsearch 94m
[root@bastion-01 logging]#
最后，我们将检查elasticsearch集群的状态。
确认所有elasticsearch的Pod都已经处于Running状态。
[root@bastion-01 logging]# oc get pod -n openshift-logging --selector component=elasticsearch
NAME READY STATUS RESTARTS AGE
elasticsearch-cdm-hxg5zzyz-1-5f58bc7c98-7fvmd 2/2 Running 0 8m1s
elasticsearch-cdm-hxg5zzyz-2-75464f4897-rdm89 2/2 Running 0 8m
elasticsearch-cdm-hxg5zzyz-3-5cc5765cd4-g95ht 2/2 Running 0 7m59s
[root@bastion-01 logging]#
我会确认Elasticsearch状态是否为绿色。
[root@bastion-01 logging]# oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-hxg5zzyz-1-5f58bc7c98-7fvmd -- health
Fri May 17 09:40:21 UTC 2022
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1655462421 09:40:21 elasticsearch green 3 3 20 10 0 0 0 0 - 100.0%
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-hxg5zzyz-1-5f58bc7c98-7fvmd -- es_cluster_health
{
"cluster_name" : "elasticsearch",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 3,
"number_of_data_nodes" : 3,
"active_primary_shards" : 10,
"active_shards" : 20,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
}
[root@bastion-01 logging]#
我会确认所有指标都显示为绿色。
[root@bastion-01 logging]# oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-hxg5zzyz-1-5f58bc7c98-7fvmd -- indices
Tue May 17 09:55:26 UTC 2022
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open app-000001 weU8Atv-RyShO7CyoBnhjw 3 1 0 0 0 0
green open infra-000001 vE6uVwM3SAGvKNCOQ4J45g 3 1 11579 0 19 10
green open audit-000001 ktPf9mp3RVev6R7QyrZ8Bg 3 1 0 0 0 0
green open .security _kf4-56uRfK9FVFK-vGVCw 1 1 6 0 0 0
[root@bastion-01 logging]#
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-hxg5zzyz-1-5f58bc7c98-7fvmd -- es_util --query=_cat/indices?
green open app-000001 weU8Atv-RyShO7CyoBnhjw 3 1 0 0 1.5kb 783b
green open infra-000001 vE6uVwM3SAGvKNCOQ4J45g 3 1 12731 0 24.1mb 11mb
green open audit-000001 ktPf9mp3RVev6R7QyrZ8Bg 3 1 0 0 1.5kb 783b
green open .security _kf4-56uRfK9FVFK-vGVCw 1 1 6 0 66.1kb 33kb
[root@bastion-01 logging]#
Kibana 中文的翻译：基本夜纳
删除elasticsearch的部署并重新创建Pod后，可能会导致Kibana界面无法查询日志。
在这种情况下，重新创建Kibana Pod也许是一个好主意。
重新创建Kibana的Pod。
[root@bastion-01 ~]# oc get deploy -n openshift-logging kibana
NAME READY UP-TO-DATE AVAILABLE AGE
kibana 1/1 1 1 38h
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc scale -n openshift-logging --replicas=0 deployment/kibana
deployment.apps/kibana scaled
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get deploy -n openshift-logging kibana
NAME READY UP-TO-DATE AVAILABLE AGE
kibana 0/1 1 0 38h
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc scale -n openshift-logging --replicas=1 deployment/kibana
deployment.apps/kibana scaled
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get deploy -n openshift-logging kibana
NAME READY UP-TO-DATE AVAILABLE AGE
kibana 1/1 1 1 38h
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get pod -n openshift-logging | grep kibana
kibana-95cdccd9b-7xmpx 2/2 Running 0 57s
[root@bastion-01 ~]#
如果显示登录界面，请使用OCP管理员用户进行登录。
由于重建了Kibana的Pod，所以需要重新创建index pattern。
这次我们创建了”infra*”和”app*”这两个index pattern，以便显示infra和app的日志。
補充
这次我们只使用了local-storage operator来创建日志、监控的PV。
不过，如果环境准备好的话，我认为使用OpenShift Data Foundation来准备PV会更好。
关于这个，我打算另外说明一下。
