本步骤01.prepare.yml主要完成:
- 创建CA证书、kubeconfig、bootstrap.kubeconfig、kube-proxy.kubeconfig和kubedns配置
- 分发CA证书、kubectl客户端安装、环境配置
- 安装负载均衡
请在另外窗口打开roles/deploy/tasks/main.yml 文件,对照看以下讲解内容。
roles/deploy/
├── tasks
│ └── main.yml
└── templates
├── admin-csr.json.j2 # kubectl客户端使用的证书请求模板
├── ca-config.json.j2 # ca 配置文件模板
├── ca-csr.json.j2 # ca 证书签名请求模板
├── kubedns.yaml.j2
└── kube-proxy-csr.json.j2 # kube-proxy使用的证书请求模板
kubernetes 系统各组件需要使用 TLS 证书对通信进行加密,使用 CloudFlare 的 PKI 工具集生成自签名的 CA 证书,用来签名后续创建的其它 TLS 证书。参考阅读
根据认证对象可以将证书分成三类:服务器证书server cert
,客户端证书client cert
,对等证书peer cert
(表示既是server cert
又是client cert
),在kubernetes 集群中需要的证书种类如下:
etcd
节点需要标识自己服务的server cert
,也需要client cert
与etcd
集群其他节点交互,当然可以分别指定2个证书,也可以使用一个对等证书master
节点需要标识 apiserver服务的server cert
,也需要client cert
连接etcd
集群,这里也使用一个对等证书kubectl
calico
kube-proxy
只需要client cert
,因此证书请求中hosts
字段可以为空kubelet
证书比较特殊,不是手动生成,它由node节点TLS BootStrap
向apiserver
请求,由master
节点的controller-manager
自动签发,包含一个client cert
和一个server cert
整个集群要使用统一的CA 证书,只需要在 deploy 节点创建,然后分发给其他节点;为了保证安装的幂等性,如果已经存在CA 证书,就跳过创建CA 步骤
创建 CA 配置文件 ca-config.json.j2
{
"signing": {
"default": {
"expiry": "87600h"
},
"profiles": {
"kubernetes": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
],
"expiry": "87600h"
}
}
}
}
signing
:表示该证书可用于签名其它证书;生成的 ca.pem 证书中CA=TRUE
;server auth
:表示可以用该 CA 对 server 提供的证书进行验证;client auth
:表示可以用该 CA 对 client 提供的证书进行验证;profile
kubernetes包含了
server auth和
client auth`,所以可以签发三种不同类型证书;
创建 CA 证书签名请求 ca-csr.json.j2
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "HangZhou",
"L": "XS",
"O": "k8s",
"OU": "System"
}
]
}
cfssl gencert -initca ca-csr.json | cfssljson -bare ca
kubectl使用~/.kube/config 配置文件与kube-apiserver进行交互,且拥有管理 K8S集群的完全权限,
准备kubectl使用的admin 证书签名请求 admin-csr.json.j2
{
"CN": "admin",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "HangZhou",
"L": "XS",
"O": "system:masters",
"OU": "System"
}
]
}
- kubectl 使用客户端证书可以不指定hosts 字段
- 证书请求中
O
指定该证书的 Group 为system:masters
,而RBAC
预定义的ClusterRoleBinding
将 Groupsystem:masters
与 ClusterRolecluster-admin
绑定,这就赋予了kubectl**所有集群权限 **
$ kubectl describe clusterrolebinding cluster-admin
Name: cluster-admin
Labels: kubernetes.io/bootstrapping=rbac-defaults
Annotations: rbac.authorization.kubernetes.io/autoupdate=true
Role:
Kind: ClusterRole
Name: cluster-admin
Subjects:
Kind Name Namespace
---- ---- ---------
Group system:masters
使用kubectl config
生成kubeconfig 自动保存到 ~/.kube/config,生成后 cat ~/.kube/config
可以验证配置文件包含 kube-apiserver 地址、证书、用户名等信息。
- 注意 kubelet bootstrapping认证时是靠 token的,后续批准节点后 (kubectl certificate approve),由
master
为其生成证书和私钥
创建 kube-proxy 证书请求
{
"CN": "system:kube-proxy",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "HangZhou",
"L": "XS",
"O": "k8s",
"OU": "System"
}
]
}
- kube-proxy 使用客户端证书可以不指定hosts 字段
- CN 指定该证书的 User 为 system:kube-proxy,预定义的 ClusterRoleBinding system:node-proxier 将User system:kube-proxy 与 Role system:node-proxier 绑定,授予了调用 kube-apiserver Proxy 相关 API 的权限;
$ kubectl describe clusterrolebinding system:node-proxier
Name: system:node-proxier
Labels: kubernetes.io/bootstrapping=rbac-defaults
Annotations: rbac.authorization.kubernetes.io/autoupdate=true
Role:
Kind: ClusterRole
Name: system:node-proxier
Subjects:
Kind Name Namespace
---- ---- ---------
User system:kube-proxy
- kubedns.yaml文件中部分参数(CLUSTER_DNS_SVC_IP, CLUSTER_DNS_DOMAIN)根据hosts文件设置而定,因此需要用template模块替换参数
- 运行本步骤后,在 manifests/kubedns目录下生成 kubedns.yaml 文件,以供后续部署时使用
roles/prepare/
├── files
│ ├── 95-k8s-sysctl.conf
└── tasks
└── main.yml
请在另外窗口打开roles/prepare/tasks/main.yml 文件,比较简单直观
- 首先创建一些基础文件目录
- 修改环境变量,把{{ bin_dir }} 添加到$PATH,需要重新登陆 shell生效
- 把证书工具 CFSSL 和 kubectl 下发到指定节点,并下发kubeconfig配置文件
- 把CA 证书相关下发到指定节点的 {{ ca_dir }} 目录
- 最后设置基础操作系统软件和系统参数,请阅读脚本中的注释内容
roles/lb
├── tasks
│ └── main.yml
└── templates
├── haproxy.cfg.j2
├── haproxy.service.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协议保证所谓的高可用或热备的,这里用来预防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 文件,对照看以下讲解内容。
- 使用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:{{ KUBE_APISERVER.split(':')[2] }}
mode tcp
option tcplog
balance source
server s1 {{ master1 }} check inter 10000 fall 2 rise 2 weight 1
server s2 {{ master2 }} check inter 10000 fall 2 rise 2 weight 1
如果用apt安装的话,可以在/usr/share/doc/haproxy目录下找到配置指南configuration.txt.gz,全局和默认配置这里不展开,关注listen
代理设置模块,各项配置说明:
- 名称 kube-master
- bind 监听客户端请求的地址/端口,保证监听master的VIP地址和端口
- mode 选择四层负载模式 (当然你也可以选择七层负载,请查阅指南,适当调整)
- balance 选择负载算法 (负载算法也有很多供选择)
- server 配置master节点真实的endpoits,必须与 hosts文件对应设置
- 使用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 {{ ROUTER_ID }}
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等
- 特别注意
virtual_router_id
标识了一个 VRRP组,在同网段下必须唯一,否则出现Keepalived_vrrp: bogus VRRP packet received on eth0 !!!
类似报错
配置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 {{ ROUTER_ID }}
advert_int 3
virtual_ipaddress {
{{ MASTER_IP }}
}
}
- 备节点的配置类似主节点,除了优先级和检测脚本,其他如
virtual_router_id
advert_int
virtual_ipaddress
必须与主节点一致
- lb 节点验证
systemctl status haproxy # 检查进程状态
journalctl -u haproxy # 检查进程日志是否有报错信息
systemctl status keepalived # 检查进程状态
journalctl -u keepalived # 检查进程日志是否有报错信息
netstat -antlp|grep 8443 # 检查tcp端口是否监听
- 在 keepalived 主节点
ip a # 检查 master的 VIP地址是否存在
- 尝试关闭 keepalived主节点上的 haproxy进程,然后在keepalived 备节点上查看 master的 VIP地址是否能够漂移过来,并依次检查上一步中的验证项。
- 尝试直接关闭 keepalived 主节点系统,检查各验证项。