mirror of https://github.com/easzlab/kubeasz.git
12 KiB
12 KiB
01-创建证书和环境配置.md
本步骤01.prepare.yml主要完成:
- chrony role: 集群节点时间同步[可选]
- deploy role: 创建CA证书、kubeconfig、kube-proxy.kubeconfig
- prepare role: 分发CA证书、kubectl客户端安装、环境配置
- lb role: 安装负载均衡[可选]
deploy 角色
请在另外窗口打开roles/deploy/tasks/main.yml 文件，对照看以下讲解内容。
创建 CA 证书和秘钥
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集群，这里也使用一个对等证书kubectlcalicokube-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"
}
]
}
生成CA 证书和私钥
cfssl gencert -initca ca-csr.json | cfssljson -bare ca
生成 kubeconfig 配置文件
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 地址、证书、用户名等信息。
生成 kube-proxy.kubeconfig 配置文件
创建 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
prepare 角色
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 }} 目录
- 最后设置基础操作系统软件和系统参数，请阅读脚本中的注释内容
LB 角色-负载均衡部署
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 文件，对照看以下讲解内容。
安装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:{{ 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文件对应设置
安装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 {{ 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_idadvert_intvirtual_ipaddress必须与主节点一致
启动 keepalived 和 haproxy 后验证
- lb 节点验证
systemctl status haproxy # 检查进程状态
journalctl -u haproxy # 检查进程日志是否有报错信息
systemctl status keepalived # 检查进程状态
journalctl -u keepalived # 检查进程日志是否有报错信息
netstat -antlp|grep 8443 # 检查tcp端口是否监听
- 在 keepalived 主节点
ip a # 检查 master的 VIP地址是否存在
keepalived 主备切换演练
- 尝试关闭 keepalived主节点上的 haproxy进程，然后在keepalived 备节点上查看 master的 VIP地址是否能够漂移过来，并依次检查上一步中的验证项。
- 尝试直接关闭 keepalived 主节点系统，检查各验证项。