2023年10月28日土曜日

Pacemaker+Corosyncのハートビートのタイムアウト値を変更する

以前の記事にて、Pacemaker+Corosyncにてクラスターを構成し、NGINXなどを冗長化する手順を記載した。

今までは細かいチューニングはしてこなかったが、先日検証環境にて仮想マシンを3台同時にOSインストールを行ったところ、負荷上昇に伴い、Corosyncにて以下のようなハートビートの閾値超過の警告メッセージが表示された。

Error in corosync.log : Aug 05 07:42:28 [2474] t3046ngnx 
corosync warning [MAIN  ] 
Corosync main process was not scheduled (@1691188948066) 
for 2737.8225 ms (threshold is 2400.0000 ms). 
Consider token timeout increase.

要約すると、「Corosyncのハートビート(token)がタイムアウト値の閾値に近づいていることから、タイムアウト値の増加を検討せよ」、というメッセージとなる。

本記事では、Pacemaker+Corosyncのハートビートのタイムアウト値を変更する手順を記載する。

環境

今回検証した環境は以下の通り。

  • OS : AlmaLinux release 9.2
  • Pacemaker : version 2.1.5
  • Corosync : Corosync Cluster Engine, version ‘3.1.7’

念のため、Pacemaker+Corosyncのクラスター構成図を以下に記載する。

Corosyncのハートビートのタイムアウト値を変更する手順 (pcsコマンドで設定する場合)

pcsコマンドで以下の通り実行すれば、corosync.confへの設定追記から各ノードへの同期・反映まで、必要な作業はすべて実施してくれる。

最も簡単な手順となるため、通常はpcsコマンドで設定すれば問題ないだろう。

# pcs cluster config update totem token=5000
Sending updated corosync.conf to nodes...
t3045ngnx: Succeeded
t3046ngnx: Succeeded
t3045ngnx: Corosync configuration reloaded

Corosyncのハートビートのタイムアウト値を変更する手順 (手動で設定する場合)

もし、pcsコマンドではなく手動で実施したい場合は本手順で実施する。

1. 設定前確認

Corosyncのハートビート間隔は、tokenという値で設定されている。現在の設定はcorosync-cmapctlコマンドで確認できる。現在は、3000ミリ秒(3秒)で設定されていることがわかる。

# corosync-cmapctl | egrep 'token|consensus'
runtime.config.totem.cancel_token_hold_on_retransmit (u32) = 0
runtime.config.totem.consensus (u32) = 3600
runtime.config.totem.token (u32) = 3000 # <-★3000ミリ秒で設定(デフォルト)
runtime.config.totem.token_retransmit (u32) = 714
runtime.config.totem.token_retransmits_before_loss_const (u32) = 4
runtime.config.totem.token_warning (u32) = 75

タイムアウト値の修正は基本的にtokenのみで問題ないが、関連して自動計算されるconsensusという値もある。他にもtokenの値などから自動計算されるパラメータがあるが、本記事では設定しないので説明は割愛する。

設定項目 内容
token ハートビート間隔(ミリ秒)。こちらの間隔の80%を超えると警告メッセージが表示される(そのため、前述したメッセージでは閾値が2400.0000 msと表示されている)。
consensus 新しいメンバーシップの設定を開始する前に合意が得られるまでの待ち時間。自動的にtoken * 1.2倍で設定される値ため、原則個別設定は不要。

2. corosync.confを修正

/etc/corosync/corosync.confに対して、以下設定を追加する。

# vi /etc/corosync/corosync.conf
totem {
    version: 2
    cluster_name: clst-01
    transport: knet
    crypto_cipher: aes256
    crypto_hash: sha256
    cluster_uuid: 956d398413b349219b60cef218e681f9
    token: 5000 # <-★追加
}

3. クラスター間で設定を同期

設定したcorosync.confの内容をクラスターに所属する全ノードに同期させる。

# pcs cluster sync
t3045ngnx: Succeeded
t3046ngnx: Succeeded
Warning: Corosync configuration has been synchronized, please reload corosync daemon using 'pcs cluster reload corosync' command.

4. クラスターに設定を反映

同期した設定を反映させる。

# pcs cluster reload corosync
Corosync reloaded

5. 設定後確認

再度Corosyncの設定状況を確認すると、以下の通りtokenの設定が更新されていることがわかる。

# corosync-cmapctl | egrep 'token|consensus'
runtime.config.totem.cancel_token_hold_on_retransmit (u32) = 0
runtime.config.totem.consensus (u32) = 6000
runtime.config.totem.token (u32) = 5000 # <-★更新されている
runtime.config.totem.token_retransmit (u32) = 1190
runtime.config.totem.token_retransmits_before_loss_const (u32) = 4
runtime.config.totem.token_warning (u32) = 75
totem.token (u32) = 5000

以上で、Pacemaker+Corosyncのハートビートのタイムアウト値を変更する手順は完了となる。

参考

2023年10月21日土曜日

KubernetesのCNI「flannel」をバージョンアップする手順

先日Kubernetes環境をバージョンアップする手順を記載した。

前回はKubernetes本体のバージョンアップ手順を記載したが、関連コンポーネントであるCRI (Container Runtime Interface)やCNI (Container Network Interface)のバージョンアップについては言及していなかった。

私の自宅Kubernetes環境ではCNIとしてflannelを用いている。本記事ではKubernetesのCNI「flannel」をバージョンアップする手順を記載する。

環境

以下に今回構築する各種ソフトウェアのバージョンを記載する。

  • ホストOS : AlmaLinux 8.6
  • Kubernetes : v1.27.3
  • Docker : 23.0.5
  • CRI : cri-dockerd 0.3.4
  • CNI : flannel v0.21.5 -> v0.22.0

今回の構成の概要図を以下に記載する。

flannelバージョンアップ手順

1, 事前バージョン確認

flannelのバージョンアップ前のバージョン確認をしておく。Dockerのコンテナイメージの情報から、今回のバージョンアップ前のバージョンは、v0.21.5となっていることがわかる。

# docker images | grep flannel
flannel/flannel                             v0.21.5   a6c0cb5dbd21   2 months ago    68.9MB
flannel/flannel-cni-plugin                  v1.1.2    7a2dcab94698   7 months ago    7.97MB

2. 最新のマニフェストファイルを適用

flannelの最新のマニフェストファイルをダウンロードする。

# curl -LO https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

kubectl applyにて更新する。最下行のdaemonset.apps/kube-flannel-dsconfiguredとなっていれば、更新処理が実行される。

# kubectl apply -f kube-flannel.yml
namespace/kube-flannel unchanged
serviceaccount/flannel unchanged
clusterrole.rbac.authorization.k8s.io/flannel unchanged
clusterrolebinding.rbac.authorization.k8s.io/flannel unchanged
configmap/kube-flannel-cfg unchanged
daemonset.apps/kube-flannel-ds configured

3. バージョンアップ完了まで待機

マニフェストファイルを更新すると、ノード単位で順番にPodの再作成がされ自動的にローリングアップデートがされる。最終的に各ノードで動作していたkube-flannel-dsのPodは、新しいバージョンのPodとして起動する。

# kubectl get pod -n=kube-flannel -w
NAME                    READY   STATUS        RESTARTS      AGE
kube-flannel-ds-5bqnn   1/1     Terminating   4 (8d ago)    60d
kube-flannel-ds-mghhs   1/1     Running       2 (35d ago)   60d
kube-flannel-ds-x9mzn   1/1     Running       2 (35d ago)   60d
kube-flannel-ds-5bqnn   0/1     Terminating   4 (8d ago)    60d
kube-flannel-ds-5bqnn   0/1     Terminating   4 (8d ago)    60d
kube-flannel-ds-5bqnn   0/1     Terminating   4 (8d ago)    60d
kube-flannel-ds-fgg2w   0/1     Pending       0             0s
kube-flannel-ds-fgg2w   0/1     Pending       0             0s
kube-flannel-ds-fgg2w   0/1     Init:0/2      0             0s
kube-flannel-ds-fgg2w   0/1     Init:1/2      0             1s
kube-flannel-ds-fgg2w   0/1     PodInitializing   0             7s
kube-flannel-ds-fgg2w   1/1     Running           0             8s
kube-flannel-ds-mghhs   1/1     Terminating       2 (35d ago)   60d
kube-flannel-ds-mghhs   0/1     Terminating       2 (35d ago)   60d
kube-flannel-ds-mghhs   0/1     Terminating       2 (35d ago)   60d
kube-flannel-ds-mghhs   0/1     Terminating       2 (35d ago)   60d
kube-flannel-ds-ztdg7   0/1     Pending           0             0s
kube-flannel-ds-ztdg7   0/1     Pending           0             0s
kube-flannel-ds-ztdg7   0/1     Init:0/2          0             0s
kube-flannel-ds-ztdg7   0/1     Init:1/2          0             1s
kube-flannel-ds-ztdg7   0/1     PodInitializing   0             6s
kube-flannel-ds-ztdg7   1/1     Running           0             7s
kube-flannel-ds-x9mzn   1/1     Terminating       2 (35d ago)   60d
kube-flannel-ds-x9mzn   0/1     Terminating       2 (35d ago)   60d
kube-flannel-ds-x9mzn   0/1     Terminating       2 (35d ago)   60d
kube-flannel-ds-x9mzn   0/1     Terminating       2 (35d ago)   60d
kube-flannel-ds-cz2q4   0/1     Pending           0             0s
kube-flannel-ds-cz2q4   0/1     Pending           0             0s
kube-flannel-ds-cz2q4   0/1     Init:0/2          0             0s
kube-flannel-ds-cz2q4   0/1     Init:1/2          0             1s
kube-flannel-ds-cz2q4   0/1     PodInitializing   0             7s
kube-flannel-ds-cz2q4   1/1     Running           0             9s

4. 事後バージョン確認

flannelのバージョンアップ後のバージョン確認する。事前の確認においてv0.21.5だけだったコンテナイメージにv0.22.0が追加されている。

# docker images | grep flannel
flannel/flannel                                 v0.22.0   38c11b8f4aa1   7 weeks ago     69.8MB
flannel/flannel                                 v0.21.5   a6c0cb5dbd21   2 months ago    68.9MB
flannel/flannel-cni-plugin                      v1.1.2    7a2dcab94698   7 months ago    7.97MB

さらに、Podの詳細情報を確認すると、v0.22.0のコンテナイメージで起動していることが確認できる。

# kubectl describe pod kube-flannel-ds-cz2q4 -n=kube-flannel
Name:                 kube-flannel-ds-cz2q4
Namespace:            kube-flannel

~(中略)~

Containers:
  kube-flannel:
    Container ID:  docker://fcd1857a182c3622a9ba4bed91101e443d384705dcee03c97d0bf179704cec6d
    Image:         docker.io/flannel/flannel:v0.22.0 ★
    Image ID:      docker-pullable://flannel/flannel@sha256:5f83f1243057458e27249157394e3859cf31cc075354af150d497f2ebc8b54db

~(以下略)~

以上で、KubernetesのCNI「flannel」をバージョンアップする手順は完了となる。

2023年10月14日土曜日

KubernetesのCRI「cri-dockerd」をバージョンアップする手順

先日Kubernetes環境をバージョンアップする手順を記載した。

前回はKubernetes本体のバージョンアップ手順を記載したが、関連コンポーネントであるCRI (Container Runtime Interface)やCNI (Container Network Interface)のバージョンアップについては言及していなかった。

私の自宅Kubernetes環境ではCRIとしてcri-dockerdを用いている。本記事ではKubernetesのCRI「cri-dockerd」をバージョンアップする手順を記載する。

環境

以下に今回構築する各種ソフトウェアのバージョンを記載する。

  • ホストOS : AlmaLinux 8.6
  • Kubernetes : v1.27.3
  • Docker : 23.0.5
  • CRI : cri-dockerd 0.3.2 -> 0.3.4
  • CNI : flannel v0.22.0

今回の構成の概要図を以下に記載する。

cri-dockerdバージョンアップ手順

1. 事前バージョン確認

cri-dockerdのバージョンアップ前のバージョン確認をしておく。今回のバージョンアップ前のバージョンは、0.3.2となっていることがわかる。

# cri-dockerd --buildinfo
Program: cri-dockerd
Version: 0.3.2 (HEAD)
GitCommit: HEAD
Go version: go1.20.4

2. drain実行 (Podの退避・Podの配置の禁止)

一時的にcri-dockerdのサービス再起動が発生することから、念のためバージョンアップ対象ノードからPodを退避(drain)したのち、Podの配置を禁止(cordon)する。

# kubectl drain t1051kube --ignore-daemonsets
node/t1051kube cordoned
~(以下略)~

drainされると、ノードのステータスがSchedulingDisabledとなる。

# kubectl get node
NAME        STATUS                     ROLES           AGE   VERSION
t1051kube   Ready,SchedulingDisabled   control-plane   62d   v1.27.3
t1052kube   Ready                      control-plane   62d   v1.27.3
t1053kube   Ready                      control-plane   34d   v1.27.3

3. cri-dockerdのバージョンアップ

git cloneにてcri-dockerdのリポジトリから必要なファイルを入手する。

# git clone https://github.com/Mirantis/cri-dockerd.git

cri-dockerdはGo言語にてビルドする必要があるため、そちらに必要となるファイルも入手する。

# wget https://storage.googleapis.com/golang/getgo/installer_linux
# chmod +x ./installer_linux
# ./installer_linux

cri-dockerdの公式手順に従い、再インストールを行う。

# cd cri-dockerd/
# mkdir -p bin
# /root/.go/bin/go build -o bin/cri-dockerd
# install -o root -g root -m 0755 bin/cri-dockerd /usr/local/bin/cri-dockerd
# cp -af packaging/systemd/* /etc/systemd/system
# sed -i -e 's,/usr/bin/cri-dockerd,/usr/local/bin/cri-dockerd,' /etc/systemd/system/cri-docker.service

最後にcri-dockerdのサービスを再起動する。

# systemctl daemon-reload
# systemctl restart cri-docker.service

4. uncordon実行

バージョンアップが完了したので、対象ノードのcordon状態を解消するため、uncordonを実行する。

# kubectl uncordon t1051kube

最終的にノードがバージョンアップされた状態でReadyとなった。

# kubectl get node
NAME        STATUS   ROLES           AGE   VERSION
t1051kube   Ready    control-plane   62d   v1.27.3
t1052kube   Ready    control-plane   62d   v1.27.3
t1053kube   Ready    control-plane   34d   v1.27.3

5. 事後バージョン確認

cri-dockerdのバージョンアップ後のバージョン確認する。事前の確認において0.3.2だったものが0.3.4となっていることがわかる。

# cri-dockerd --buildinfo
Program: cri-dockerd
Version: 0.3.4 (HEAD)
GitCommit: HEAD
Go version: go1.20.6

6. 手順1~5を残りのノードに対して繰り返す

残りのノードに対してもdrain、バージョンアップ、uncordonを繰り返しながらローリングアップデートを実行する。

以上で、KubernetesのCRI「cri-dockerd」をバージョンアップする手順は完了となる。

2023年10月7日土曜日

Ansible実行時の「Encryption using the Python crypt module is deprecated.」の警告メッセージを消す方法

ある日Ansibleを実行していると、以下の警告メッセージが表示された。

[DEPRECATION WARNING]: Encryption using the Python crypt module is deprecated.
The Python crypt module is deprecated and will be removed from Python 3.13.
Install the passlib library for continued encryption functionality.
This feature will be removed in version 2.17.
Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

本記事では、Ansibleの「Encryption using the Python crypt module is deprecated.」の警告メッセージを消す方法を記載する。

環境

  • OS : AlmaLinux 8.5
  • Ansible : 8.1.0 (ansible [core 2.15.1])
  • Python : 3.9.16

原因

以下2点つの条件が重なった際に警告メッセージが表示されるようだ。

  1. Playbookでpassword_hashといったパスワードをハッシュ化する構文を使用している。
    • password: "{{ 'P@ssw0rd!' | password_hash('sha512') }}"
  2. Pythonライブラリであるpasslibがインストールされていない。

解消方法

警告メッセージにも記載されている通り、Pythonライブラリであるpasslibをインストールすれば問題ない。

# python3 -m pip install passlib
WARNING: Running pip install with root privileges is generally not a good idea. Try `python3 -m pip install --user` instead.
Collecting passlib
  Downloading passlib-1.7.4-py2.py3-none-any.whl (525 kB)
     |████████████████████████████████| 525 kB 13.8 MB/s 
Installing collected packages: passlib
Successfully installed passlib-1.7.4

簡単ではあるが、以上で完了となる。

人気の投稿