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

206 lines
7.5 KiB
Markdown
Raw Normal View History

2017-11-27 20:22:53 +08:00
## 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
```
2017-12-04 16:36:08 +08:00
kubernetes 系统各组件需要使用 TLS 证书对通信进行加密,使用 CloudFlare 的 PKI 工具集生成自签名的CA证书用来签名后续创建的其它 TLS 证书。[参考阅读](https://coreos.com/os/docs/latest/generate-self-signed-certificates.html)
根据认证对象可以将证书分成三类:服务器证书,客户端证书,对等证书 `peer cert`(表示既是`server cert`又是`client cert`)在kubernetes 集群中需要的证书种类如下:
+ `etcd` 节点需要标识自己监听服务的server cert也需要client cert与`etcd`集群其他节点交互当然可以分别指定2个证书这里为简化使用一个peer 证书
+ `kube-apiserver` 需要标识apiserver服务的server cert也需要client cert 从而操作`etcd`集群这里为简化使用一个peer 证书
+ `kubectl` `calico` `kube-proxy` 只需要 client cert因此证书请求中 hosts 字段可以为空
+ `kubelet` 证书比较特殊不是手动生成它由node节点`TLS BootStrap` 向`apiserver`请求由master节点的`controller-manager` 自动签发包含一个client cert 和一个server cert
2017-11-30 22:44:45 +08:00
请在另外窗口打开[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"
}
}
}
}
```
2017-12-04 16:36:08 +08:00
+ `ca-config.json`:可以定义多个 profiles分别指定不同的过期时间、使用场景等参数这里为了方便使用 `kubernetes` 这个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
2017-11-30 22:23:19 +08:00
cfssl gencert -initca ca-csr.json | cfssljson -bare ca
```
+ 注意整个集群只能有一个CA证书和配置文件所以下一步要分发给每一个节点包括calico/node也需要使用
### 集群环境变量、CA分发
2017-12-01 09:10:14 +08:00
请在另外窗口打开[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的。
2017-12-04 16:36:08 +08:00
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会将其剔除负载池。
2017-11-30 22:44:45 +08:00
请在另外窗口打开[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 }}
}
}
```
+ 备节点的配置类似主节点,除了优先级和检测脚本