首页 > 其他分享 >以二进制文件安装K8S之部署Master高可用集群

以二进制文件安装K8S之部署Master高可用集群

时间：2023-08-19 22:45:50浏览次数：48  
标签：kube kubernetes etc 二进制 192.168 apiserver -- Master K8S

如下以二进制文件方式部署安全的Kubernetes Master高可用集群，具体步骤如下：
1.下载Kubernetes服务的二进制文件
2.部署kube-apiserver服务
3.创建客户端CA证书
4.创建客户端连接kube-apiserver服务所需的kubeconfig配置文件
5.部署kube-controller-manager服务
6.部署kube-scheduler服务
7.使用HAProxy和keepalived部署高可用负载均衡器

下载Kubernetes服务的二进制文件

从Kubernetes的官方GitHub代码库页面下载各组件的二进制文件，在Releases页面找到需要下载的版本号，单击CHANGELOG链接，跳转到已编译好的Server端二进制（Server Binaries）文件的下载页面进行下载。

也可以直接进入到这个页面单击对应版本的CHNAGELOG文件，即可跳转到已编译好的Server端二进制文件下载页面。

可以分别下载Server Binaries和Node Binaries二进制文件。
在Server Binaries中包含不同系统架构的服务端可执行文件，例如kubernetes-server-linux-amd64.tar.gz文件包含了x86架构下Kubernetes需要运行的全部服务程序文件；Node Binaries则包含了不同系统架构、不同操作系统的Node需要运行的服务程序文件，包括Linux版和Windows版等。

主要的服务程序二进制文件列表如下所示：

文件名 说明
kube-apiserver kube-apiserver主程序
kube-apiserver.docker_tag kube-apiserver docker镜像的tag
kube-apiserver.tar kube-apisener docker镜像文件
kube-controller-manager kube-controller-manager主程序
kube-controller-manager.docker_tag kube-controller-manager docker镜像的tag
kube-controller-manager.tar kube-controller-manager docker镜像文件
kube-scheduler kube-scheduler主程序
kube-scheduler.docker_tag kube-scheduler docker镜像的tag
kube-scheduler.tar kube-scheduler docker镜像文件
kubelet kubelet主程序
kube-proxy kube-proxy主程序
kube-proxy.docker_tag kube-proxy docker镜像的tag
kube-proxy.tar kube-proxy docker镜像文件
kubectl 客户端命令行工具
kubeadm Kubernetes集群安装命令行工具
apiextensions-apiserver 提供实现自定义资源对象的扩展API Server
kube-aggregator 聚合API Server程序

在Kubernetes的Master节点上需要部署的服务包括etcd、kube-apiserver、kube-controller-manager和kube-scheduler。
在工作节点（Worker Node）上需要部署的服务包括docker、kubelet和kube-proxy。当然，在本实例中由于需要在Master节点上以容器方式部署HAProxy和KeepAlived，所以在Master节点上也需要安装Docker环境。
将Kubernetes的二进制可执行文件（kube-apiserver，kube-controller-manager，kube-scheduler）复制到/usr/bin目录下，然后在/usr/lib/systemd/system目录下为各服务创建systemd服务配置文件，这样就完成了软件的安装。

部署kube-apiserver服务

先确保已经在所有Master节点上将kube-apiserver复制到/usr/bin目录下。

（1）设置kube-apiserver服务需要的CA相关证书。

准备master_ssl.cnf文件用于生成x509 v3版本的证书，示例如下：

[ req ]
req_extensions = v3_req
distinguished_name = req_distinguished_name

[ req_distinguished_name ]

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster.local
DNS.5 = k8s-1
DNS.6 = k8s-2
DNS.7 = k8s-3
IP.1 = 169.169.0.1
IP.2 = 192.168.3.135
IP.3 = 192.168.3.136
IP.4 = 192.168.3.137
IP.5 = 192.168.3.100

在该文件中主要需要在subjectAltName字段（[alt_names]）设置Master服务的全部域名和IP地址，包括：

  • DNS主机名，例如k8s-1、k8s-2、k8s-3等，主机名需要添加到/etct/hosts文件中；
  • Master Service虚拟服务名称，例如kubernetes.default等；
  • IP地址，包括各kube-apiserver所在主机的IP地址和负载均衡器的IP地址，例如192.168.3.135、192.168.3.136、192.168.3.137和192.168.3.100；
  • Master Service虚拟服务的ClusterIP地址，例如169.169.0.1。

然后使用openssl命令创建kube-apiserver的服务端CA证书，包括apiserver.key和apiserver.crt文件，将其复制到/etc/kubernetes/pki目录下：

openssl genrsa -out apiserver.key 2048
openssl req -new -key apiserver.key -config master_ssl.cnf -subj "/CN=192.168.3.135" -out apiserver.csr
openssl x509 -req -in apiserver.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 36500 -extensions v3_req -extfile master_ssl.cnf -out apiserver.crt

将apiserver.crt和apiserver.key拷贝到所有个Master节点的/etc/kubernetes/pki目录下。

（2）为kube-apiserver服务创建systemd服务配置文件/usr/lib/systemd/system/kube-apiserver.service，内容如下：

[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/kubernetes/kubernetes

[Service]
EnvironmentFile=/etc/kubernetes/apiserver
ExecStart=/usr/bin/kube-apiserver $KUBE_API_ARGS
Restart=always

[Install]
WantedBy=multi-user.target

所有Master节点都要做相同的配置。

（3）配置文件/etc/kubernetes/apiserver的内容通过环境变量KUBE_API_ARGS设置kube-apiserver的全部启动参数，包含CA安全配置的启动参数示例如下：

KUBE_API_ARGS="--insecure-port=0 \
--secure-port=6443 \
--tls-cert-file=/etc/kubernetes/pki/apiserver.crt \
--tls-private-key-file=/etc/kubernetes/pki/apiserver.key \
--client-ca-file=/etc/kubernetes/pki/ca.crt \
--apiserver-count=3 --endpoint-reconciler-type=master-count \
--etcd-servers=https://192.168.3.135:2379,https://192.168.3.136:2379,https://192.168.3.137:2379 \
--etcd-cafile=/etc/kubernetes/pki/ca.crt \
--etcd-certfile=/etc/etcd/pki/etcd_client.crt \
--etcd-keyfile=/etc/etcd/pki/etcd_client.key \
--service-cluster-ip-range=169.169.0.0/16 \
--service-node-port-range=30000-32767 \
--allow-privileged=true \
--logtostderr=false --log-dir=/var/log/kubernetes --v=0"

主要参数说明如下：

  • --secure-port：HTTPS端口号，默认值为6443。
  • --insecure-port：HTTP端口号，默认值为8080，设置为0表示关闭HTTP访问。
  • --tls-cert-file：服务端CA证书文件全路径，例如/etc/kubernetes/pki/apiserver.crt。
  • --tls-private-key-file：服务端CA私钥文件全路径，例如/etc/kubernetes/pki/apiserver.key。
  • --client-ca-file：CA根证书全路径，例如/etc/kubernetes/pki/ca.crt。
  • --apiserver-count：API Server实例数量，例如3，需要同时设置参数--endpoint-reconciler-type=master-count。
  • --etcd-servers：连接etcd的URL列表，这里使用HTTPS，例如https://192.168.3.135:2379、https://192.168.3.136:2379和https://192.168.3.137:2379。
  • --etcd-cafile：etcd使用的CA根证书文件全路径，例如/etc/kubernetes/pki/ca.crt。
  • --etcd-certfile：etcd客户端CA证书文件全路径，例如/etc/etcd/pki/etcd_client.crt。
  • --etcd-keyfile：etcd客户端私钥文件全路径，例如/etc/etcd/pki/etcd_client.key。
  • --service-cluster-ip-range：Service虚拟IP地址范围，以CIDR格式表示，例如169.169.0.0/16，该IP范围不能与物理机的IP地址有重合。
  • --service-node-port-range：Service可使用的物理机端口号范围，默认值为30000～32767。
  • --allow-privileged：是否允许容器以特权模式运行，默认值为true。
  • --logtostderr：是否将日志输出到stderr，默认值为true，当使用systemd系统时，日志将被输出到journald子系统。设置为false表示不输出到stderr，可以输出到日志文件。
  • --log-dir：日志的输出目录，例如/var/log/kubernetes。
  • --v：日志级别。

所有Master节点都要做相同的配置。

（4）在配置文件准备完毕后，在所有Master主机上分别启动kube-apiserver服务，并设置为开机自启动：

# 启动kube-apiserver服务并设置开机启动
systemctl start kube-apiserver && systemctl enable kube-apiserver

# 查看kube-apiserver服务状态
systemctl status kube-apiserver

如果服务启动失败，可以查看启动日志：journalctl -xefu kube-apiserver 。

创建客户端CA证书

kube-controller-manager、kube-scheduler、kubelet和kube-proxy服务作为客户端连接kube-apiserver服务，需要为它们创建客户端CA证书进行访问。

（1）通过openssl工具创建CA证书和私钥文件，命令如下：

openssl genrsa -out client.key 2048
openssl req -new -key client.key -subj "/CN=admin" -out client.csr
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 36500

其中，-subj参数中“/CN”的名称可以被设置为“admin”，用于标识连接kube-apiserver的客户端用户的名称。

（2）将生成的client.key和client.crt文件保存在/etc/kubernetes/pki目录下（所有Master节点都需要执行该操作）。

创建客户端连接kube-apiserver服务所需的kubeconfig配置文件

本节为kube-controller-manager、kube-scheduler、kubelet和kube-proxy服务统一创建一个kubeconfig文件作为连接kube-apiserver服务的配置文件，后续也作为kubectl命令行工具连接kube-apiserver服务的配置文件。

在kubeconfig文件中主要设置访问kube-apiserver的URL地址及所需CA证书等的相关参数，示例如下：

apiVersion: v1
kind: Config
clusters:
- name: default
  cluster:
    server: https://192.168.3.100:9443
    certificate-authority: /etc/kubernetes/pki/ca.crt
users:
- name: admin
  user:
    client-certificate: /etc/kubernetes/pki/client.crt
    client-key: /etc/kubernetes/pki/client.key
contexts:
- context:
    cluster: default
    user: admin
  name: default
current-context: default

其中的关键配置参数如下：

  • server：配置为负载均衡器（HAProxy）使用的VIP地址（如192.168.3.100）和HAProxy监听的端口号（如9443）。
  • client-certificate：配置为客户端证书文件（client.crt）全路径。
  • client-key：配置为客户端私钥文件（client.key）全路径。
  • certificate-authority：配置为CA根证书（ca.crt）全路径。
  • users中的name和context中的user是连接API Server的用户名，设置为与客户端证书中的“/CN”名称保持一致，例如“admin”。

将kubeconfig文件保存到/etc/kubernetes目录下（所有Master节点都需要执行该操作）。

部署kube-controller-manager服务

前提：在所有Master节点上分别将kube-controller-manager复制到/usr/bin目录下。

（1）为kube-controller-manager服务创建systemd服务配置文件/usr/lib/systemd/system/kube-controller-manager.service，内容如下：

[Unit]
Description=Kubernetes Controller Manager
Documentation=https://github.com/kubernetes/kubernetes

[Service]
EnvironmentFile=/etc/kubernetes/controller-manager
ExecStart=/usr/bin/kube-controller-manager $KUBE_CONTROLLER_MANAGER_ARGS
Restart=always

[Install]
WantedBy=multi-user.target

所有Master节点都需要添加上述配置。

（2）配置文件/etc/kubernetes/controller-manager的内容为通过环境变量KUBE_CONTROLLER_MANAGER_ARGS设置的kube-controller-manager的全部启动参数，包含CA安全配置的启动参数示例如下：

KUBE_CONTROLLER_MANAGER_ARGS="--kubeconfig=/etc/kubernetes/kubeconfig \
--leader-elect=true \
--service-cluster-ip-range=169.169.0.0/16 \
--service-account-private-key-file=/etc/kubernetes/pki/apiserver.key \
--root-ca-file=/etc/kubernetes/pki/ca.crt \
--log-dir=/var/log/kubernetes --logtostderr=false --v=0"

对主要参数说明如下。

  • --kubeconfig：与API Server连接的相关配置。
  • --leader-elect：启用选举机制，在3个节点的环境中应被设置为true。
  • --service-account-private-key-file：为ServiceAccount自动颁发token使用的私钥文件全路径，例如/etc/kubernetes/pki/apiserver.key。
  • --root-ca-file：CA根证书全路径，例如/etc/kubernetes/pki/ca.crt。
  • --service-cluster-ip-range：Service虚拟IP地址范围，以CIDR格式表示，例如169.169.0.0/16，与kube-apiserver服务中的配置保持一致。

所有Master节点都需要添加上述配置。

（3）配置文件准备完毕后，在所有Master主机上分别启动kube-controller-manager服务，并设置为开机自启动：

# 启动kube-controller-manager并设置为开机启动
systemctl start kube-controller-manager && systemctl enable kube-controller-manager
# 查看kube-controller-manager服务状态
systemctl status kube-controller-manager

如果启动失败，查看kube-controller-manager日志：journalctl -xefu kube-controller-manager

部署kube-scheduler服务

前提：在所有Master节点上分别将kube-scheduler复制到/usr/bin目录下。

（1）为kube-scheduler服务创建systemd服务配置文件/usr/lib/systemd/system/kube-scheduler.service，内容如下：

[Unit]
Description=Kubernetes Scheduler
Documentation=https://github.com/kubernetes/kubernetes

[Service]
EnvironmentFile=/etc/kubernetes/scheduler
ExecStart=/usr/bin/kube-scheduler $KUBE_SCHEDULER_ARGS
Restart=always

[Install]
WantedBy=multi-user.target

在所有Master节点添加上述配置。

（2）配置文件/etc/kubernetes/scheduler的内容为通过环境变量KUBE_SCHEDULER_ARGS设置的kube-scheduler的全部启动参数，示例如下：

KUBE_SCHEDULER_ARGS="--kubeconfig=/etc/kubernetes/kubeconfig \
--leader-elect=true \
--logtostderr=false --log-dir=/var/log/kubernetes --v=0"

对主要参数说明如下。

  • --kubeconfig：与API Server连接的相关配置。
  • --leader-elect：启用选举机制，在3个节点的环境中应被设置为true。

在所有Master节点添加上述配置。

（3）在配置文件准备完毕后，在所有Master节点上分别启动kube-scheduler服务，并设置为开机自启动：

# 启动kube-scheduler并设置为开机启动
systemctl start kube-scheduler && systemctl enable kube-scheduler
# 查看kube-scheduler服务运行状态
systemctl status kube-scheduler

如果启动失败，查看kube-scheduler日志：journalctl -xefu kube-scheduler

通过systemctl status <service_name>验证服务的启动状态，状态为running并且没有报错日志表示启动成功。

# 查看kube-apiserver服务运行状态
systemctl status kube-apiserver.service
# 查看kube-controller-manager服务运行状态
systemctl status kube-controller-manager.service
# 查看kube-scheduler服务运行状态
systemctl status kube-scheduler.service

至此，一个支持3个节点高可用的K8S Master集群基础服务就搭建完毕了，接下来继续配置负载均衡和高可用。

使用HAProxy和keepalived部署高可用负载均衡器

接下来，在3个kube-apiserver服务的前端部署HAProxy和keepalived，使用VIP 192.168.3.100作为Master的唯一入口地址，供客户端访问。
将HAProxy和Keepalived均部署为至少有两个实例的高可用架构，以避免单点故障。

下面以在192.168.3.135和192.168.3.136两台服务器上部署为例进行说明。
HAProxy负责将客户端请求转发到后端的3个kube-apiserver实例上，keepalived负责维护VIP 192.168.3.100的高可用。

HAProxy和keepalived的部署架构如图：

接下来对部署HAProxy和keepalived组件进行说明。

1）部署两个HAProxy实例

准备HAProxy的配置文件haproxy.cfg，内容示例如下：

global
    log 127.0.0.1 local2
    chroot /var/lib/haproxy
    pidfile /var/run/haproxy.pid
    maxconn 4096
    user haproxy
    group haproxy
    daemon
    stats socket /var/lib/haproxy/stats

defaults
    mode http
    log global
    option httplog
    option dontlognull
    option http-server-close
    option forwardfor except 127.0.0.0/8
    option redispatch
    retries 3
    timeout http-request 10s
    timeout queue 1m
    timeout connect 10s
    timeout client 1m
    timeout server 1m
    timeout http-keep-alive 10s
    timeout check 10s
    maxconn 3000

frontend kube-apiserver
    mode tcp
    bind *:9443
    option tcplog
    default_backend kube-apiserver

listen stats
    mode http
    bind *:8888
    stats auth admin:password # 这里输入的admin和password是将来访问/stats时需要输入的用户名和密码
    stats refresh 5s
    stats realm HAProxy\ Statistics
    stats uri /stats
    log 127.0.0.1 local3 err

backend kube-apiserver
    mode tcp
    balance roundrobin
    server k8s-master1 192.168.3.135:6443 check
    server k8s-master2 192.168.3.136:6443 check
    server k8s-master3 192.168.3.137:6443 check

对主要参数说明如下。

  • frontend：HAProxy的监听协议和端口号，使用TCP，端口号为9443。
  • backend：后端3个kube-apiserver的地址，以IP:Port方式表示，例如192.168.3.135:6443、192.168.3.136:6443和192.168.3.137:6443；mode字段用于设置协议，此处为tcp；balance字段用于设置负载均衡策略，例如roundrobin为轮询模式。
  • listen stats：状态监控的服务配置，其中，bind用于设置监听端口号为8888；stats auth用于配置访问账号；stats uri用于配置访问URL路径，例如/stats。

下面以Docker容器方式运行HAProxy且镜像使用haproxytech/haproxy-debian为例进行说明。

在两台服务器192.168.3.135和192.168.3.136上启动HAProxy，将配置文件haproxy.cfg挂载到容器的/usr/local/etc/haproxy目录下，启动命令如下：

docker run -d --name k8s-haproxy --net=host --restart=always -v ${PWD}/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro haproxytech/haproxy-debian:2.3

在一切正常的情况下，通过浏览器访问http://192.168.3.135:8888/stats地址即可访问HAProxy的管理页面，登录后查看到的主页界面如下图所示。

这里主要关注最后一个表格，其内容为haproxy.cfg配置文件中backend配置的3个kube-apiserver地址，它们的状态均为“UP”，表示与3个kube-apiserver服务成功建立连接，说明HAProxy工作正常。

2）部署两个keepalived实例

Keepalived用于维护VIP地址的高可用，同样在192.168.3.135和192.168.3.136两台服务器上进行部署。
主要需要配置keepalived监控HAProxy的运行状态，当某个HAProxy实例不可用时，自动将VIP地址切换到另一台主机上。
下面对keepalived的配置和启动进行说明。

在第1台服务器192.168.3.135上创建配置文件keepalived.conf，内容如下：

! Configuration File for keepalived

global_defs {
	router_id LVS_1
}

vrrp_script checkhaproxy
{
	script "/usr/bin/check-haproxy.sh"
	interval 2
	weight -30
}

vrrp_instance VI_1 {
	state MASTER
	interface ens32
	virtual_router_id 51
	priority 100
	advert_int 1

	virtual_ipaddress {
		192.168.3.100/24 dev ens32
	}
	
	authentication {
		auth_type PASS
		auth_pass password
	}
	
	track_script {
		checkhaproxy
	}
}

主要参数在vrrp_instance段中进行设置，说明如下。

  • vrrp_instance VI_1：设置keepalived虚拟路由器VRRP的名称。
  • state：设置为“MASTER”，将其他keepalived均设置为“BACKUP”。
  • interface：待设置VIP地址的网卡名称。
  • virtual_router_id：例如51。
  • priority：优先级，例如100。
  • virtual_ipaddress：VIP地址，例如192.168.18.100/24。
  • authentication：访问keepalived服务的鉴权信息。
  • track_script：HAProxy健康检查脚本。

KeepAlived需要持续监控HAProxy的运行状态，在某个HAProxy实例运行不正常时，自动切换到运行正常的HAProxy实例上。
需要创建一个HAProxy健康检查脚本，定期运行该脚本进行监控，例如新建脚本check-haproxy.sh并将其保存到/usr/bin目录下（其实不用放在/usr/bin目录下也可以，只需要放在将来启动KeepAlived容器的路径上即可），内容示例如下：

#!/bin/bash

count=`netstat -apn | grep 9443 | wc -l`
if [ $count -gt 0 ]; then
	exit 0
else
	exit 1
fi

若检查成功，则应返回0；若检查失败，则返回非0值。
该脚本需要拷贝到2台安装KeepAlived的Master节点上：192.168.3.135和192.168.3.136 。

KeepAlived根据上面的配置，会每隔2s检查一次HAProxy的运行状态。例如，如果在192.168.3.135上检查失败，KeepAlived就会将VIP地址切换到正常运行HAProxy的192.168.3.136服务器上，保证VIP 192.168.3.100地址的高可用。

在第2台服务器192.168.3.136上创建配置文件keepalived.conf，内容示例如下：

! Configuration File for keepalived

global_defs {
	router_id LVS_2
}

vrrp_script checkhaproxy
{
	script "/usr/bin/check-haproxy.sh"
	interval 2
	weight -30
}

vrrp_instance VI_1 {
	state BACKUP
	interface ens32
	virtual_router_id 51
	priority 100
	advert_int 1

	virtual_ipaddress {
		192.168.3.100/24 dev ens32
	}
	
	authentication {
		auth_type PASS
		auth_pass password
	}
	
	track_script {
		checkhaproxy
	}
}

这里与第1个keepalived配置的主要差异如下。

  • vrrp_instance中的state被设置为“BACKUP”，这是因为在整个keepalived集群中只能有一个被设置为“MASTER”。如果keepalived集群不止2个实例，那么除了MASTER，其他都应被设置为“BACKUP”。
  • vrrp_instance的值“VI_1”需要与MASTER的配置相同，表示它们属于同一个虚拟路由器组（VRRP），当MASTER不可用时，同组的其他BACKUP实例会自动选举出一个新的MASTER。
  • HAProxy健康检查脚本check-haproxy.sh与第1个keepalived的相同。

下面以Docker容器方式运行KeepAlived且镜像使用osixia/keepalived为例进行说明。
在两台服务器192.168.3.135和192.168.3.136上启动KeepAlived，将配置文件keepalived.conf挂载到容器的/container/service/keepalived/assets目录下，启动命令如下：

docker run -d --name k8s-keepalived --restart=always --net=host --cap-add=NET_ADMIN --cap-add=NET_BROADCAST --cap-add=NET_RAW -v ${PWD}/keepalived.conf:/container/service/keepalived/assets/keepalived.conf -v ${PWD}/check-haproxy.sh:/usr/bin/check-haproxy.sh osixia/keepalived:2.0.20 --copy-service

在运行正常的情况下，KeepAlived会在服务器192.168.3.135的网卡ens32上设置192.168.3.100的IP地址，同样在服务器192.168.3.135上运行的HAProxy将在该IP地址上监听9443端口号，对需要访问k8s Master的客户端提供负载均衡器的入口地址，即192.168.3.100:9443。

通过ip addr命令查看服务器192.168.3.135的IP地址信息，可以看到在ens32网卡上新增了192.168.3.100地址：

[root@m1 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:ce:e7:52 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.135/24 brd 192.168.3.255 scope global noprefixroute dynamic ens32
       valid_lft 1597sec preferred_lft 1597sec
    inet 192.168.3.100/24 scope global secondary ens32 # 这里是虚拟IP:192.168.3.100
       valid_lft forever preferred_lft forever
    inet6 fe80::e88e:f064:183d:7826/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:d6:0a:3a:d3 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
[root@m1 ~]#

使用curl命令即可验证通过HAProxy的192.168.3.100:9443地址是否可以访问到kube-apiserver服务：

[root@m1 ~]# curl -v -k https://192.168.3.100:9443
* Rebuilt URL to: https://192.168.3.100:9443/
*   Trying 192.168.3.100...
* TCP_NODELAY set
* Connected to 192.168.3.100 (192.168.3.100) port 9443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=192.168.3.129
*  start date: Aug 18 10:25:22 2023 GMT
*  expire date: Jul 25 10:25:22 2123 GMT
*  issuer: CN=192.168.3.129
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* Using Stream ID: 1 (easy handle 0x55fbc97556b0)
* TLSv1.3 (OUT), TLS app data, [no content] (0):
> GET / HTTP/2
> Host: 192.168.3.100:9443
> User-Agent: curl/7.61.1
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS app data, [no content] (0):
< HTTP/2 401 
< cache-control: no-cache, private
< content-type: application/json
< content-length: 165
< date: Fri, 18 Aug 2023 10:49:43 GMT
< 
* TLSv1.3 (IN), TLS app data, [no content] (0):
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
    
  },
  "status": "Failure",
  "message": "Unauthorized",
  "reason": "Unauthorized",
  "code": 401
* Connection #0 to host 192.168.3.100 left intact
}
[root@m1 ~]#

可以看到TCP/IP连接创建成功，得到响应码为401的应答，说明通过VIP地址192.168.3.100成功访问到了后端的kube-apiserver服务。
至此，Master上所需的3个服务就全部启动完成了，即：一个3节点高可用支持安全访问的K8S Master集群就搭建完毕了。

标签：kube,kubernetes,etc,二进制,192.168,apiserver,--,Master,K8S
From： https://www.cnblogs.com/nuccch/p/17643329.html

相关文章

  • 详解二进制，八进制，十进制，十六进制的原理与转换
    首先了解一下数字系统的由来数字系统是人类为了表示数量和进行计数而创造的一种工具。数字系统的发展可以追溯到古代文明，不同的文化和社会在不同的时间和地点创造了各种数字系统。以下是数字系统的一些关键发展阶段： 早期计数：最早的人类社会使用自然物体如石块、棍子、贝壳等......
  • Python练习：输入一个整数，输出该数二进制表示中1的个数。
      Python3整数对象存储为无符号数加上符号位标志，所以不存在“负数”补码形式，因此，计算“1”的数量需要按去符号后的无符号数：cnt=bin(n).count('1')另外，Python3无长整，整数长度原则上不限，所以不能以假定的32位处理。    补码+原码=2**321#-*-coding:ut......
  • k8s推送代码至gitlab报错error: RPC failed; result=22, HTTP code = 413 fatal: The
    #gitpush-uoriginmainUsernamefor'http://gitlab.wjl.net':rootPasswordfor'http://[email protected]':Countingobjects:1032,done.Deltacompressionusingupto8threads.Compressingobjects:100%(871/871),done.error:R......
  • 部署k8s-1.28.0
    ===============================================================#centos8及其以上不用操作！！！#所有节点上关闭swap分区swapoff-a;sed-i'/fstab/d'/etc/fstab#升级系统内核#导入elrepogpgkeyrpm--importhttps://www.elrepo.org/RPM-GPG-KEY-elrepo.org#安......
  • k8s help
    [root@localhost~]#kubectlcreatedeploymentweb01--image=httpd--port=80-r100-ndefault--dry-run=client-oyaml[root@localhost~]#kubectlcreatedeploymentweb01--image=httpd--port=80-r100-ndefault--dry-run=none-oyaml[root@localhost~]#......
  • K8s 部署Django项目
    K8s部署Django项目K8s作为目前主流互联网使用技术栈，本次介绍如何将Django项目部署到Kubernetes中。项目代码使用前面几章节定义的Django文件上传代码，使用上一章打包好的镜像，接下来就是部署到K8s中,请往下看：DeploymentyamlapiVersion:apps/v1kind:Deploymentmetadata:......
  • gitlab+jenkins+harbor+k8s部署微服务环境
    一、gitlab1.gitlb部署version:'3'services:gitlab:image:'gitlab/gitlab-ce:latest'container_name:'gitlab'restart:alwayshostname:'192.168.1.188'#部署机器的ip,非容器ip(因为是本地不是线上所以用ip，线上的话可以用域名)......
  • K8S集群管理：用名字空间分隔系统资源
    Kubernetes的名字空间并不是一个实体对象，只是一个逻辑上的概念。它可以把集群切分成一个个彼此独立的区域，然后我们把对象放到这些区域里，就实现了类似容器技术里namespace的隔离效果，应用只能在自己的名字空间里分配资源和运行，不会干扰到其他名字空间里的应用。 Kubernetes面对大......
  • 打印二进制的奇数位和偶数位
    voidprint(inta){ inti=0; printf("奇数位："); for(i=30;i>=0;i-=2) { printf("%d",(a>>i)&1); } printf("\n"); printf("偶数位："); for(i=31;i>=1;i-=2) { printf("%d",(a>>i)&......
  • [kubernetes]二进制部署k8s集群-基于containerd
    0.前言k8s从1.24版本开始不再直接支持docker，但可以自行调整相关配置，实现1.24版本后的k8s还能调用docker。其实docker自身也是调用containerd，与其k8s通过docker再调用containerd，不如k8s直接调用containerd，以减少性能损耗。除了containerd，比较流行的容器运行时还有podman，但是podm......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99