kubeasz/docs/01-创建CA证书和环境配置.md

199 lines
6.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

## 01-创建CA证书和环境配置.md
本步骤[01.prepare.yml](../01.prepare.yml)主要完成CA证书创建、分发、环境变量、负载均衡配置等。
### 创建 CA 证书和秘钥
``` bash
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](../roles/ca/tasks/main.yml) 文件,对照看以下讲解内容。
#### 创建 CA 配置文件 [ca-config.json.j2](../roles/ca/templates/ca-config.json.j2)
``` bash
{
"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](../roles/ca/templates/ca-csr.json.j2)
``` bash
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "HangZhou",
"L": "XS",
"O": "k8s",
"OU": "System"
}
]
}
```
#### 生成CA 证书和私钥
``` bash
cfssl gencert -initca ca-csr.json | cfssljson -bare ca
```
+ 注意整个集群只能有一个CA证书和配置文件所以下一步要分发给每一个节点包括calico/node也需要使用
### 集群环境变量、CA分发
请在另外窗口打开[roles/prepare/tasks/main.yml](../roles/prepare/tasks/main.yml) 文件,因比较简单直观,这里不展开讲解了。
``` bash
roles/prepare/
├── files
│   ├── ca-config.json
│   ├── ca.csr
│   ├── ca-csr.json
│   ├── ca-key.pem
│   └── ca.pem
└── tasks
└── main.yml
```
### LB 负载均衡部署
``` bash
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](../roles/lb/tasks/main.yml) 文件,对照看以下讲解内容。
#### 安装haproxy
+ 使用apt源安装
#### 配置haproxy [haproxy.cfg.j2](../roles/lb/templates/haproxy.cfg.j2)
``` bash
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](../roles/lb/templates/keepalived-master.conf.j2)
``` bash
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](../roles/lb/templates/keepalived-backup.conf.j2)
``` bash
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 }}
}
}
```
+ 备节点的配置类似主节点,除了优先级和检测脚本