配備k 8 s sslクラスタ実践6:高可用性kube-apiserverコンポーネントha+keepalivedの構成
8120 ワード
参照ドキュメント:https://github.com/opsnull/follow-me-install-kubernetes-cluster作者の無私な分かち合いに感謝します.クラスタ環境の構築に成功しました.記事は、導入中に発生したエラーと詳細な操作手順の記録です.比較参考が必要な場合は、順番に読んでテストしてください.
kubernetes masterノードは、kube-apiserverkube-schedulerkube-controller-managerkube-schedulerとkube-controller-managerをクラスタモードで実行し、leader選挙によってワークプロセスを生成し、他のプロセスがブロックモードにあるコンポーネントを実行します.kube-apiserverの場合、複数のインスタンス(このドキュメントは3インスタンス)を実行できますが、他のコンポーネントには統一されたアクセスアドレスが必要です.このアドレスは高可用性が必要です.このドキュメントでは、keepalivedとhaproxyを使用して、kubeapiserverVIPの高可用性と負荷分散を実現します.
クラスタモードとha+keepalivedの主な違いは何ですか?ha+keepalivedはvipを構成し、apiの唯一のアクセスアドレスと負荷等化を実現した.クラスタモードはvipを構成していません.
6.1高可用性コンポーネントの構成
keepalivedはkube-apiserverの対外サービスのVIPを提供する.haproxyはVIPを傍受し、バックエンドにすべてのkube-apiserverインスタンスを接続し、健康診断と負荷均衡機能を提供する.keepalivedとhaproxyを実行するノードをLBノードと呼ぶ.keepalivedは1つのマスタマルチスタンバイ動作モードであるため、少なくとも2つのLBノードが存在する.このドキュメントでは、masterノードの3台のマシンを多重化し、haproxyが傍受するポート(8443)は、kube-apiserverのポート6443とは異なり、競合を回避する必要があります.keepalivedは、実行中に本機のhaproxyプロセスの状態を周期的にチェックし、haproxyプロセスの異常が検出されると、再選択主のプロセスをトリガーし、VIPは新しく選択した主ノードに移動し、VIPの高可用性を実現する.すべてのコンポーネント(kubeclt、apiserver、controller-manager、schedulerなど)は、VIPおよびhaproxyが傍受する8443ポートを介してkube-apiserverサービスにアクセスします.
インストールパッケージ(3ノードすべてインストール)yum-y install keepalived haproxy
設定cfg
他のノードにコピー
haproxyは1080ポートでstatus情報を出力する.haproxyは、環境変数${KUBE_APISERVER}で指定されたポートと一致するすべてのインタフェースの8443ポートをリスニングします.serverフィールドには、すべてのkube-apiserverが傍受するIPとポートがリストされます.
haproxyの起動
ポートが起動しているのを見てみましょうか?
6.2 keepalivedの構成
keepalivedはプライマリ(master)マルチスタンバイ(backup)実行モードなので、2種類のプロファイルがあります.マスタープロファイルは1部のみです.backupプロファイルはノード数によって異なります.このドキュメントでは、次のように計画されています.
マスタープロファイル:
スクリプトファイル
keepalivedテストに成功しました
6.3問題:スクリプトは実行されません.理由:##くれぐれも注意して、track_scriptこのパラメータのセットはvipの後ろに書かなければなりません.そうしないと、スクリプトは実行されません.
転載先:https://blog.51cto.com/goome/2164829
kubernetes masterノードは、kube-apiserverkube-schedulerkube-controller-managerkube-schedulerとkube-controller-managerをクラスタモードで実行し、leader選挙によってワークプロセスを生成し、他のプロセスがブロックモードにあるコンポーネントを実行します.kube-apiserverの場合、複数のインスタンス(このドキュメントは3インスタンス)を実行できますが、他のコンポーネントには統一されたアクセスアドレスが必要です.このアドレスは高可用性が必要です.このドキュメントでは、keepalivedとhaproxyを使用して、kubeapiserverVIPの高可用性と負荷分散を実現します.
クラスタモードとha+keepalivedの主な違いは何ですか?ha+keepalivedはvipを構成し、apiの唯一のアクセスアドレスと負荷等化を実現した.クラスタモードはvipを構成していません.
6.1高可用性コンポーネントの構成
keepalivedはkube-apiserverの対外サービスのVIPを提供する.haproxyはVIPを傍受し、バックエンドにすべてのkube-apiserverインスタンスを接続し、健康診断と負荷均衡機能を提供する.keepalivedとhaproxyを実行するノードをLBノードと呼ぶ.keepalivedは1つのマスタマルチスタンバイ動作モードであるため、少なくとも2つのLBノードが存在する.このドキュメントでは、masterノードの3台のマシンを多重化し、haproxyが傍受するポート(8443)は、kube-apiserverのポート6443とは異なり、競合を回避する必要があります.keepalivedは、実行中に本機のhaproxyプロセスの状態を周期的にチェックし、haproxyプロセスの異常が検出されると、再選択主のプロセスをトリガーし、VIPは新しく選択した主ノードに移動し、VIPの高可用性を実現する.すべてのコンポーネント(kubeclt、apiserver、controller-manager、schedulerなど)は、VIPおよびhaproxyが傍受する8443ポートを介してkube-apiserverサービスにアクセスします.
インストールパッケージ(3ノードすべてインストール)yum-y install keepalived haproxy
設定cfg
[root@k8s-master haproxy]# cat haproxy.cfg |grep -v ^#
global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
stats socket /var/lib/haproxy/stats
defaults
mode tcp
log global
timeout connect 10s
timeout client 1m
timeout server 1m
timeout check 10s
maxconn 3000
frontend kube-api
bind 0.0.0.0:8443
mode tcp
log global
default_backend kube-master
backend kube-master
balance source
server k8s-master 192.168.1.92:6443 check inter 2000 fall 2
server k8s-node1 192.168.1.93:6443 check inter 2000 fall 2
server k8s-node2 192.168.1.95:6443 check inter 2000 fall 2
listen stats
mode http
bind 0.0.0.0:1080
stats enable
stats hide-version
stats uri /haproxyadmin?stats
stats realm Haproxy\ Statistics
stats auth admin:admin
stats admin if TRUE
[root@k8s-master haproxy]#他のノードにコピー
[root@k8s-master haproxy]# scp haproxy.cfg root@k8s-node1:/etc/haproxy/
haproxy.cfg 100% 1300 1.7MB/s 00:00
[root@k8s-master haproxy]# scp haproxy.cfg root@k8s-node2:/etc/haproxy/
haproxy.cfg 100% 1300 1.7MB/s 00:00
[root@k8s-master haproxy]#haproxyは1080ポートでstatus情報を出力する.haproxyは、環境変数${KUBE_APISERVER}で指定されたポートと一致するすべてのインタフェースの8443ポートをリスニングします.serverフィールドには、すべてのkube-apiserverが傍受するIPとポートがリストされます.
haproxyの起動
[root@k8s-master haproxy]# systemctl status haproxy -l
● haproxy.service - HAProxy Load Balancer
Loaded: loaded (/usr/lib/systemd/system/haproxy.service; disabled; vendor preset: disabled)
Active: active (running) since 2018-08-21 17:15:40 CST; 2min 19s ago
Main PID: 7709 (haproxy-systemd)
Tasks: 3
Memory: 1.7M
CGroup: /system.slice/haproxy.service
├─7709 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
├─7710 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
└─7711 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
8 21 17:15:40 k8s-master systemd[1]: Started HAProxy Load Balancer.
8 21 17:15:40 k8s-master systemd[1]: Starting HAProxy Load Balancer...
8 21 17:15:40 k8s-master haproxy-systemd-wrapper[7709]: haproxy-systemd-wrapper: executing /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
[root@k8s-master haproxy]#ポートが起動しているのを見てみましょうか?
[root@k8s-master haproxy]# netstat -tnlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.1.92:2379 0.0.0.0:* LISTEN 2229/etcd
tcp 0 0 127.0.0.1:2379 0.0.0.0:* LISTEN 2229/etcd
tcp 0 0 192.168.1.92:2380 0.0.0.0:* LISTEN 2229/etcd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 749/rpcbind
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1034/sshd
tcp 0 0 0.0.0.0:1080 0.0.0.0:* LISTEN 7711/haproxy
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1238/master
tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN 7711/haproxy
tcp6 0 0 :::111 :::* LISTEN 749/rpcbind
tcp6 0 0 :::22 :::* LISTEN 1034/sshd
tcp6 0 0 ::1:25 :::* LISTEN 1238/master
[root@k8s-master haproxy]#6.2 keepalivedの構成
keepalivedはプライマリ(master)マルチスタンバイ(backup)実行モードなので、2種類のプロファイルがあります.マスタープロファイルは1部のみです.backupプロファイルはノード数によって異なります.このドキュメントでは、次のように計画されています.
master: 192.168.1.92
backup：192.168.1.93,192.168.1.95マスタープロファイル:
[root@k8s-master keepalived]# cat keepalived.conf
global_defs {
router_id NodeA
}
vrrp_script chk_haproxy {
script "/etc/keepalived/check_haproxy.sh"
interval 5
weight 2
}
vrrp_instance VI_1 {
state MASTER #
interface ens192 #
virtual_router_id 51 # 、
priority 100 #( 、 ， ， , )
advert_int 1 #VRRP Multicast
authentication {
auth_type PASS #VRRP ，
auth_pass 1111 #( )
}
virtual_ipaddress {
192.168.1.94/24 #VRRP HA
}
track_script {
chk_haproxy
}
}
[root@k8s-master keepalived]#
backup
[root@k8s-node1 keepalived]# cat keepalived.conf
global_defs {
router_id NodeA
}
vrrp_script chk_haproxy {
script "/etc/keepalived/check_haproxy.sh"
interval 5
weight 2
}vrrp_instance VI_1 {
state BACKUP #
interface ens192 #
virtual_router_id 51 # 、
priority 90 #( 、 ， ， , )
advert_int 1 #VRRP Multicast
authentication {
auth_type PASS #VRRP ，
auth_pass 1111 #( )
}
virtual_ipaddress {
192.168.1.94/24 #VRRP HA
}
track_script {
chk_haproxy
}
}
[root@k8s-node1 keepalived]#
[root@k8s-node2 keepalived]# cat keepalived.conf
global_defs {
router_id NodeA
}
vrrp_script chk_haproxy {
script "/etc/keepalived/check_haproxy.sh"
interval 5
weight 2
}vrrp_instance VI_1 {
state BACKUP #
interface ens192 #
virtual_router_id 51 # 、
priority 80 #( 、 ， ， , )
advert_int 1 #VRRP Multicast
authentication {
auth_type PASS #VRRP ，
auth_pass 1111 #( )
}
virtual_ipaddress {
192.168.1.94/24 #VRRP HA
}
track_script {
chk_haproxy
}
}
[root@k8s-node2 keepalived]#スクリプトファイル
[root@k8s-master keepalived]# pwd ## keepalived
/etc/keepalived
[root@k8s-master keepalived]# cat check_haproxy.sh
#!/bin/bash
A=`ps -C haproxy --no-header |wc -l`
if [ $A -eq 0 ];then
systemctl start haproxy.service
fi
sleep 3
if [ `ps -C haproxy --no-header |wc -l` -eq 0 ];then
pkill keepalived
fi
[root@k8s-master keepalived]#keepalivedテストに成功しました
6.3問題:スクリプトは実行されません.理由:##くれぐれも注意して、track_scriptこのパラメータのセットはvipの後ろに書かなければなりません.そうしないと、スクリプトは実行されません.
転載先:https://blog.51cto.com/goome/2164829