Skip to content

Commit

Permalink
docs: update setup guide
Browse files Browse the repository at this point in the history
  • Loading branch information
@gjmzj
gjmzj committed Jun 9, 2019
1 parent fcc5b25 commit 80217dc
Show file tree
Hide file tree
Showing 12 changed files with 201 additions and 213 deletions.
10 changes: 5 additions & 5 deletions docs/op/loadballance_ingress_nodeport.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,23 +6,23 @@
- 2.部署ingress-controller时使用`LoadBalancer`类型服务，需要集群支持`LoadBalancer`
- 3.部署ingress-controller时使用`nodePort`类型服务，然后在集群外使用 haproxy/f5 等配置 virtual server 集群

本文档讲解使用 haproxy 配置 ingress的 VS 集群，前提是`多主多节点集群`并且配置了自建`lb`节点
本文档讲解使用 haproxy 配置 ingress的 VS 集群，前提是配置了自建`ex-lb`节点

## 1.配置 lb 参数开启转发 ingress nodeport
## 1.配置 ex-lb 参数开启转发 ingress nodeport

``` bash
# 编辑 roles/lb/defaults/main.yml，配置如下变量
# 编辑 roles/ex-lb/defaults/main.yml，配置如下变量
INGRESS_NODEPORT_LB: "yes"
INGRESS_TLS_NODEPORT_LB: "yes"
```

## 2.重新配置启动LB节点服务

``` bash
$ ansible-playbook /etc/ansible/roles/lb/lb.yml
$ ansible-playbook /etc/ansible/roles/ex-lb/ex-lb.yml
```

## 3.验证 lb 节点的 haproxy 服务配置 `/etc/haproxy/haproxy.cfg` 包含如下配置
## 3.验证 ex-lb 节点的 haproxy 服务配置 `/etc/haproxy/haproxy.cfg` 包含如下配置

``` bash
... 前文省略
Expand Down
5 changes: 2 additions & 3 deletions docs/setup/00-planning_and_overall_intro.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -15,13 +15,12 @@
|:-|:-|:-|
|管理节点|1|运行ansible/easzctl脚本，可以复用master节点，但如果需要[管理创建多个集群](easzctl_cmd.md#%E5%85%B8%E5%9E%8B-easzctl-%E5%88%9B%E5%BB%BA%E7%AE%A1%E7%90%86%E7%9A%84%E9%9B%86%E7%BE%A4%E6%8B%93%E6%89%91%E5%A6%82%E4%B8%8B)，建议使用独立节点（1c1g）|
|etcd节点|3|注意etcd集群需要1,3,5,7...奇数个节点，一般复用master节点|
|master节点|2|高可用集群至少2个master节点)|
|master节点|2|高可用集群至少2个master节点|
|node节点|3|运行应用负载的节点，可根据需要提升机器配置/增加节点数|

项目预定义了2个例子，请修改后完成适合你的集群规划。

- [单节点](../../example/hosts.allinone)
- 注意：在 ha-2x 架构下，单节点可以简单地通过`add-master/add-node/add-etcd`扩容成高可用集群
- [单节点](../../example/hosts.allinone) ，在 ha-2x 架构下，单节点集群可以通过`add-master/add-node/add-etcd`扩容成高可用集群
- [多主多节点](../../example/hosts.multi-node)

## 部署步骤
Expand Down
174 changes: 17 additions & 157 deletions docs/setup/01-CA_and_prerequisite.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,35 +2,40 @@

本步骤[01.prepare.yml](../../01.prepare.yml)主要完成:

- chrony role: 集群节点时间同步[可选]
- [chrony role](../guide/chrony.md): 集群节点时间同步[可选]
- deploy role: 创建CA证书、kubeconfig、kube-proxy.kubeconfig
- prepare role: 分发CA证书、kubectl客户端安装、环境配置
- lb role: 安装负载均衡[可选]

## deploy 角色

请在另外窗口打开[roles/deploy/tasks/main.yml](../../roles/deploy/tasks/main.yml) 文件，对照看以下讲解内容。

### 创建 CA 证书和秘钥
### 创建 CA 证书和

``` bash
roles/deploy/
├── defaults
│   └── main.yml # 配置文件：证书有效期，kubeconfig 相关配置
├── files
│   └── read-group-rbac.yaml # 只读用户的 rbac 权限配置
├── tasks
│   └── main.yml
│   └── main.yml # 主任务脚本
└── templates
├── admin-csr.json.j2 # kubectl客户端使用的证书请求模板
├── admin-csr.json.j2 # kubectl客户端使用的admin证书请求模板
├── ca-config.json.j2 # ca 配置文件模板
├── ca-csr.json.j2 # ca 证书签名请求模板
├── kubedns.yaml.j2
└── kube-proxy-csr.json.j2 # kube-proxy使用的证书请求模板
├── kube-proxy-csr.json.j2 # kube-proxy使用的证书请求模板
└── read-csr.json.j2 # kubectl客户端使用的只读证书请求模板
```

kubernetes 系统各组件需要使用 TLS 证书对通信进行加密，使用 CloudFlare 的 PKI 工具集生成自签名的 CA 证书，用来签名后续创建的其它 TLS 证书。[参考阅读](https://coreos.com/os/docs/latest/generate-self-signed-certificates.html)

根据认证对象可以将证书分成三类：服务器证书`server cert`，客户端证书`client cert`，对等证书`peer cert`(表示既是`server cert`又是`client cert`)，在kubernetes 集群中需要的证书种类如下：

+ `etcd` 节点需要标识自己服务的`server cert`，也需要`client cert`与`etcd`集群其他节点交互，当然可以分别指定2个证书，也可以使用一个对等证书
+ `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`
+ `kubelet` 需要标识自己服务的`server cert`，也需要`client cert`请求`apiserver`，也使用一个对等证书

整个集群要使用统一的CA 证书，只需要在 deploy 节点创建，然后分发给其他节点；为了保证安装的幂等性，如果已经存在CA 证书，就跳过创建CA 步骤

Expand Down Expand Up @@ -131,7 +136,7 @@ Subjects:
Group system:masters
```

#### 生成 cluster-admin 用户证书
#### 生成 admin 用户证书

```
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes admin-csr.json | cfssljson -bare admin
Expand Down Expand Up @@ -207,157 +212,12 @@ kubectl config use-context default --kubeconfig=kube-proxy.kubeconfig

## prepare 角色

``` bash
roles/prepare/
├── files
│   ├── 95-k8s-sysctl.conf
└── tasks
└── main.yml
```
请在另外窗口打开[roles/prepare/tasks/main.yml](../../roles/prepare/tasks/main.yml) 文件，比较简单直观

1. 首先设置基础操作系统软件和系统参数，请阅读脚本中的注释内容
1. 首先创建一些基础文件目录
1. 修改环境变量，把{{ bin_dir }} 添加到$PATH，需要重新登陆 shell生效
1. 把证书工具 CFSSL 和 kubectl 下发到指定节点，并下发kubeconfig配置文件
1. 把证书工具 CFSSL 下发到指定节点，并下发kubeconfig配置文件
1. 把CA 证书相关下发到指定节点的 {{ ca_dir }} 目录
1. 最后设置基础操作系统软件和系统参数，请阅读脚本中的注释内容

## LB 角色-负载均衡部署
``` bash
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](../../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:{{ 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文件](../../example/hosts.m-masters.example)对应设置

#### 安装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 {{ 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](../../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 {{ ROUTER_ID }}
advert_int 3
virtual_ipaddress {
{{ MASTER_IP }}
}
}
```
+ 备节点的配置类似主节点，除了优先级和检测脚本，其他如 `virtual_router_id` `advert_int` `virtual_ipaddress`必须与主节点一致

### 启动 keepalived 和 haproxy 后验证

+ lb 节点验证

``` bash
systemctl status haproxy # 检查进程状态
journalctl -u haproxy # 检查进程日志是否有报错信息
systemctl status keepalived # 检查进程状态
journalctl -u keepalived # 检查进程日志是否有报错信息
netstat -antlp|grep 8443 # 检查tcp端口是否监听
```
+ 在 keepalived 主节点

``` bash
ip a # 检查 master的 VIP地址是否存在
```
### keepalived 主备切换演练

1. 尝试关闭 keepalived主节点上的 haproxy进程，然后在keepalived 备节点上查看 master的 VIP地址是否能够漂移过来，并依次检查上一步中的验证项。
1. 尝试直接关闭 keepalived 主节点系统，检查各验证项。

[后一篇](02-install_etcd.md)
5 changes: 1 addition & 4 deletions docs/setup/02-install_etcd.md
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
## 02-安装etcd集群

kuberntes 系统使用 etcd 存储所有数据，是最重要的组件之一，注意 etcd集群只能有奇数个节点(1,3,5...)，本文档使用3个节点做集群。
kuberntes 集群使用 etcd 存储所有数据，是最重要的组件之一，注意 etcd集群需要奇数个节点(1,3,5...)，本文档使用3个节点做集群。

请在另外窗口打开[roles/etcd/tasks/main.yml](../../roles/etcd/tasks/main.yml) 文件，对照看以下讲解内容。

Expand All @@ -10,8 +10,6 @@ https://github.com/etcd-io/etcd/releases

### 创建etcd证书请求 [etcd-csr.json.j2](../../roles/etcd/templates/etcd-csr.json.j2)

首先判断下是否etcd 证书已经存在，如果已经存在就跳过证书生成步骤

``` bash
{
"CN": "etcd",
Expand Down Expand Up @@ -86,7 +84,6 @@ WantedBy=multi-user.target
```
+ 完整参数列表请使用 `etcd --help` 查询
+ 注意etcd 即需要服务器证书也需要客户端证书，这里为方便使用一个peer 证书代替两个证书，更多证书相关请阅读 [01-创建CA证书和环境配置](01-CA_and_prerequisite.md)
+ 注意{{ }} 中的参数与ansible hosts文件中设置对应
+ `--initial-cluster-state` 值为 `new` 时，`--name` 的参数值必须位于 `--initial-cluster` 列表中；

### 启动etcd服务
Expand Down
18 changes: 10 additions & 8 deletions docs/setup/03-install_docker.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,14 +2,16 @@

``` bash
roles/docker/
├── defaults
│   └── main.yml # 变量配置文件
├── files
│   ├── daemon.json
│   ├── docker
│   └── docker-tag
│   ├── docker # bash 自动补全
│   └── docker-tag # 查询镜像tag的小工具
├── tasks
│   └── main.yml
└── templates
└── docker.service.j2
│   └── main.yml # 主执行文件
└── templates
├── daemon.json.j2 # docker daemon 配置文件
└── docker.service.j2 # service 服务模板
```

请在另外窗口打开[roles/docker/tasks/main.yml](../../roles/docker/tasks/main.yml) 文件，对照看以下讲解内容。
Expand Down Expand Up @@ -58,14 +60,14 @@ WantedBy=multi-user.target
}
```

这将在后续部署calico下载 calico/node镜像和kubedns/heapster/dashboard镜像时起到重要加速效果。
这将在后续部署calico下载 calico/node镜像和kubedns/heapster/dashboard镜像时起到加速效果。

由于K8S的官方镜像存放在`gcr.io`仓库，因此这个镜像加速对K8S的官方镜像没有效果；好在`Docker Hub`上有很多K8S镜像的转存，而`Docker Hub`上的镜像可以加速。这里推荐两个K8S镜像的`Docker Hub`项目,几乎能找到所有K8S相关的镜像，而且更新及时，感谢维护者的辛勤付出！

+ [mirrorgooglecontainers](https://hub.docker.com/u/mirrorgooglecontainers/)
+ [anjia0532](https://hub.docker.com/u/anjia0532/), [项目github地址](https://github.com/anjia0532/gcr.io_mirror)

当然对于企业内部应用的docker镜像，想要在K8S平台运行的话，特别是结合开发`CI/CD` 流程，肯定是需要部署私有镜像仓库的，后续会简单提到 `Harbor`的部署。
当然对于企业内部应用的docker镜像，想要在K8S平台运行的话，特别是结合开发`CI/CD` 流程，肯定是需要部署私有镜像仓库的，参阅[harbor文档](../guide/harbor.md)。

另外，daemon.json配置中也配置了docker 容器日志相关参数，设置单个容器日志超过10M则进行回卷，回卷的副本数超过3个就进行清理。

Expand Down
Loading

0 comments on commit 80217dc

Please sign in to comment.