mirror of https://github.com/easzlab/kubeasz.git
6.6 KiB
6.6 KiB
01-创建CA证书和环境配置.md
本步骤01.prepare.yml主要完成CA证书创建、分发、环境变量、负载均衡配置等。
创建 CA 证书和秘钥
roles/ca
├── tasks
│ └── main.yml
└── templates
├── ca-config.json.j2
└── ca-csr.json.j2
kubernetes 系统各组件需要使用 TLS 证书对通信进行加密,使用 CloudFlare 的 PKI 工具集生成自签名的CA证书,用来签名后续创建的其它 TLS 证书。
请在另外窗口打开roles/ca/tasks/main.yml 文件,对照看以下讲解内容。
创建 CA 配置文件 ca-config.json.j2
{
"signing": {
"default": {
"expiry": "87600h"
},
"profiles": {
"kubernetes": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
],
"expiry": "87600h"
}
}
}
}
ca-config.json
:可以定义多个 profiles,分别指定不同的过期时间、使用场景等参数;后续在签名证书时使用某个 profile;signing
:表示该证书可用于签名其它证书;生成的 ca.pem 证书中CA=TRUE
;server auth
:表示 client 可以用该 CA 对 server 提供的证书进行验证;client auth
:表示 server 可以用该 CA 对 client 提供的证书进行验证;
创建 CA 证书签名请求 ca-csr.json.j2
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "HangZhou",
"L": "XS",
"O": "k8s",
"OU": "System"
}
]
}
生成CA 证书和私钥
cfssl gencert -initca ca-csr.json | cfssljson -bare ca
- 注意整个集群只能有一个CA证书和配置文件,所以下一步要分发给每一个节点,包括calico/node也需要使用
集群环境变量、CA分发
请在另外窗口打开roles/prepare/tasks/main.yml 文件,因比较简单直观,这里不展开讲解了。
roles/prepare/
├── files
│ ├── ca-config.json
│ ├── ca.csr
│ ├── ca-csr.json
│ ├── ca-key.pem
│ └── ca.pem
└── tasks
└── main.yml
LB 负载均衡部署
roles/lb
├── tasks
│ └── main.yml
└── templates
├── haproxy.cfg.j2
├── keepalived-backup.conf.j2
└── keepalived-master.conf.j2
Haproxy支持四层和七层负载,稳定性好,根据官方文档,HAProxy可以跑满10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom's 10GbE NICs (Myri-10G PCI-Express),这个作为软件级负载均衡,也是比较惊人的;另外,openstack高可用也有用haproxy的。
keepalived观其名可知,保持存活,它是基于VRRP协议保证所谓的高可用或热备的,这里用来防止master节点单点故障,具体说是防止haproxy的单点故障。
keepalived与haproxy配合,实现master的高可用过程如下:
- 1.keepalived利用vrrp协议生成一个虚拟地址(VIP),正常情况下VIP存活在keepalive的主节点,当主节点故障时,VIP能够漂移到keepalived的备节点,保障VIP地址可用性。
- 2.在keepalived的主备节点都配置相同haproxy负载配置,并且监听客户端请求在VIP的地址上,保障随时都有一个haproxy负载均衡在正常工作。并且keepalived启用对haproxy进程的存活检测,一旦主节点haproxy进程故障,VIP也能切换到备节点,从而让备节点的haproxy进行负载工作。
- 3.在haproxy的配置中配置多个后端真实kube-apiserver的endpoints,并启用存活监测后端kube-apiserver,如果一个kube-apiserver故障,haproxy会将其剔除负载池。
请在另外窗口打开roles/lb/tasks/main.yml 文件,对照看以下讲解内容。
安装haproxy
- 使用apt源安装
配置haproxy haproxy.cfg.j2
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon
nbproc 1
defaults
log global
timeout connect 5000
timeout client 50000
timeout server 50000
listen kube-master
bind 0.0.0.0:{{ MASTER_PORT }}
mode tcp
option tcplog
balance source
server s1 {{ LB_EP1 }} check inter 10000 fall 2 rise 2 weight 1
server s2 {{ LB_EP2 }} check inter 10000 fall 2 rise 2 weight 1
如果用apt安装的话,可以在/usr/share/doc/haproxy目录下找到配置指南configuration.txt.gz,全局和默认配置这里不展开,关注listen
代理设置模块,各项配置说明:
- 名称 kube-master
- bind 监听客户端请求的地址/端口,保证监听master的VIP地址和端口,{{ MASTER_PORT }}与hosts里面设置对应
- mode 选择四层负载模式
- balance 选择负载算法
- server 配置master节点真实的endpoits,必须与hosts文件对应设置
安装keepalived
- 使用apt源安装
配置keepalived主节点 keepalived-master.conf.j2
global_defs {
router_id lb-master
}
vrrp_script check-haproxy {
script "killall -0 haproxy"
interval 5
weight -30
}
vrrp_instance VI-kube-master {
state MASTER
priority 120
dont_track_primary
interface {{ LB_IF }}
virtual_router_id 51
advert_int 3
track_script {
check-haproxy
}
virtual_ipaddress {
{{ MASTER_IP }}
}
}
- vrrp_script 定义了监测haproxy进程的脚本,利用shell 脚本
killall -0 haproxy
进行检测进程是否存活,如果进程不存在,根据weight -30
设置将主节点优先级降低30,这样原先备节点将变成主节点。 - vrrp_instance 定义了vrrp组,包括优先级、使用端口、router_id、心跳频率、检测脚本、虚拟地址VIP等
配置keepalived备节点 keepalived-backup.conf.j2
global_defs {
router_id lb-backup
}
vrrp_instance VI-kube-master {
state BACKUP
priority 110
dont_track_primary
interface {{ LB_IF }}
virtual_router_id 51
advert_int 3
virtual_ipaddress {
{{ MASTER_IP }}
}
}
- 备节点的配置类似主节点,除了优先级和检测脚本