mirror of https://github.com/easzlab/kubeasz.git
docs: update setup guide
gjmzj
parent
fcc5b257a6
commit
80217dc1cd
|
|
@ -6,12 +6,12 @@
|
|||
- 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"
|
||||
```
|
||||
|
|
@ -19,10 +19,10 @@ 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
|
||||
... 前文省略
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
## 部署步骤
|
||||
|
|
|
|||
|
|
@ -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 步骤
|
||||
|
||||
|
|
@ -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
|
||||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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) 文件，对照看以下讲解内容。
|
||||
|
||||
|
|
@ -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",
|
||||
|
|
@ -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服务
|
||||
|
|
|
|||
|
|
@ -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) 文件，对照看以下讲解内容。
|
||||
|
|
@ -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个就进行清理。
|
||||
|
||||
|
|
|
|||
|
|
@ -11,35 +11,42 @@
|
|||
- 根据调度策略为这些Pod分配节点
|
||||
- controller-manager由一系列的控制器组成，它通过apiserver监控整个集群的状态，并确保集群处于预期的工作状态
|
||||
|
||||
master节点的高可用主要就是实现apiserver组件的高可用，在之前部署lb节点时候已经配置haproxy对它进行负载均衡。
|
||||
master节点的高可用主要就是实现apiserver组件的高可用，后面我们会看到每个 node 节点会启用 4 层负载均衡来请求 apiserver 服务。
|
||||
|
||||
``` text
|
||||
roles/kube-master/
|
||||
├── defaults
|
||||
│ └── main.yml
|
||||
├── tasks
|
||||
│ └── main.yml
|
||||
└── templates
|
||||
├── aggregator-proxy-csr.json.j2
|
||||
├── basic-auth.csv.j2
|
||||
├── basic-auth-rbac.yaml.j2
|
||||
├── kube-apiserver.service.j2
|
||||
├── kube-apiserver-v1.8.service.j2
|
||||
├── kube-controller-manager.service.j2
|
||||
├── kubernetes-csr.json.j2
|
||||
├── kube-scheduler.service.j2
|
||||
└── token.csv.j2
|
||||
└── kube-scheduler.service.j2
|
||||
```
|
||||
|
||||
请在另外窗口打开[roles/kube-master/tasks/main.yml](../../roles/kube-master/tasks/main.yml) 文件，对照看以下讲解内容。
|
||||
|
||||
### 创建 kubernetes 证书签名请求
|
||||
|
||||
增加判断是否已经有kubernetes证书，如果是就使用原证书，跳过生成证书步骤
|
||||
|
||||
``` bash
|
||||
{
|
||||
"CN": "kubernetes",
|
||||
"hosts": [
|
||||
"127.0.0.1",
|
||||
"{{ MASTER_IP }}",
|
||||
{% if groups['ex-lb']|length > 0 %}
|
||||
"{{ hostvars[groups['ex-lb'][0]]['EX_APISERVER_VIP'] }}",
|
||||
{% endif %}
|
||||
"{{ inventory_hostname }}",
|
||||
"{{ CLUSTER_KUBERNETES_SVC_IP }}",
|
||||
{% for host in MASTER_CERT_HOSTS %}
|
||||
"{{ host }}",
|
||||
{% endfor %}
|
||||
"kubernetes",
|
||||
"kubernetes.default",
|
||||
"kubernetes.default.svc",
|
||||
|
|
@ -62,13 +69,11 @@ roles/kube-master/
|
|||
}
|
||||
```
|
||||
- kubernetes 证书既是服务器证书，同时apiserver又作为客户端证书去访问etcd 集群；作为服务器证书需要设置hosts 指定使用该证书的IP 或域名列表，需要注意的是：
|
||||
- 多主高可用集群需要把master VIP地址 {{ MASTER_IP }} 也添加进去
|
||||
- 如果配置 ex-lb，需要把 EX_APISERVER_VIP 也配置进去
|
||||
- 如果需要外部访问 apiserver，需要在 defaults/main.yml 配置 MASTER_CERT_HOSTS
|
||||
- `kubectl get svc` 将看到集群中由api-server 创建的默认服务 `kubernetes`，因此也要把 `kubernetes` 服务名和各个服务域名也添加进去
|
||||
- 注意所有{{ }}变量与ansible hosts中设置的对应关系
|
||||
|
||||
### 创建基础用户名/密码认证配置
|
||||
|
||||
可选，为后续使用基础认证的场景做准备，如实现dashboard 用不同用户名登陆绑定不同的权限，后续更新dashboard的实践文档。
|
||||
### 【可选】创建基础用户名/密码认证配置
|
||||
|
||||
若未创建任何基础认证配置，K8S集群部署完毕后访问dashboard将会提示`401`错误。
|
||||
|
||||
|
|
@ -200,8 +205,6 @@ WantedBy=multi-user.target
|
|||
|
||||
项目master 分支使用 DaemonSet 方式安装网络插件，如果master 节点不安装 kubelet 服务是无法安装网络插件的，如果 master 节点不安装网络插件，那么通过`apiserver` 方式无法访问 `dashboard` `kibana`等管理界面，[ISSUES #130](https://github.com/easzlab/kubeasz/issues/130)
|
||||
|
||||
项目v1.8 分支使用二进制方式安装网络插件，所以没有这个问题
|
||||
|
||||
``` bash
|
||||
# vi 04.kube-master.yml
|
||||
- hosts: kube-master
|
||||
|
|
@ -217,7 +220,6 @@ WantedBy=multi-user.target
|
|||
```
|
||||
在master 节点也同时成为 node 节点后，默认业务 POD也会调度到 master节点，多主模式下这显然增加了 master节点的负载，因此可以使用 `kubectl cordon`命令禁止业务 POD调度到 master节点
|
||||
|
||||
|
||||
### master 集群的验证
|
||||
|
||||
运行 `ansible-playbook 04.kube-master.yml` 成功后，验证 master节点的主要组件：
|
||||
|
|
|
|||
|
|
@ -1,25 +1,38 @@
|
|||
## 05-安装kube-node节点
|
||||
|
||||
`kube-node` 是集群中承载应用的节点，前置条件需要先部署好`kube-master`节点(因为需要操作`用户角色绑定`、`批准kubelet TLS 证书请求`等)，它需要部署如下组件：
|
||||
`kube-node` 是集群中运行工作负载的节点，前置条件需要先部署好`kube-master`节点，它需要部署如下组件：
|
||||
|
||||
+ docker：运行容器
|
||||
+ calico： 配置容器网络 (或者 flannel)
|
||||
+ kubelet： kube-node上最主要的组件
|
||||
+ kube-proxy： 发布应用服务与负载均衡
|
||||
+ haproxy：用于请求转发到多个 apiserver，详见[HA 架构](00-planning_and_overall_intro.md)
|
||||
+ calico： 配置容器网络 (或者 flannel)
|
||||
|
||||
``` bash
|
||||
roles/kube-node
|
||||
roles/kube-node/
|
||||
├── defaults
|
||||
│ └── main.yml # 变量配置文件
|
||||
├── tasks
|
||||
│ └── main.yml
|
||||
│ ├── main.yml # 主执行文件
|
||||
│ └── node_lb.yml # haproxy 安装文件
|
||||
└── templates
|
||||
├── cni-default.conf.j2
|
||||
├── kubelet.service.j2
|
||||
├── kubelet-csr.json.j2
|
||||
└── kube-proxy.service.j2
|
||||
├── cni-default.conf.j2 # 默认cni插件配置模板
|
||||
├── haproxy.cfg.j2 # haproxy 配置模板
|
||||
├── haproxy.service.j2 # haproxy 服务模板
|
||||
├── kubelet-csr.json.j2 # 证书请求模板
|
||||
├── kubelet.service.j2 # kubelet 服务模板
|
||||
└── kube-proxy.service.j2 # kube-proxy 服务模板
|
||||
```
|
||||
|
||||
请在另外窗口打开[roles/kube-node/tasks/main.yml](../../roles/kube-node/tasks/main.yml) 文件，对照看以下讲解内容。
|
||||
|
||||
### 变量配置文件
|
||||
|
||||
详见 roles/kube-node/defaults/main.yml
|
||||
- 变量`PROXY_MODE`，配置 kube-proxy 服务代理模式 iptables or ipvs
|
||||
- 变量`KUBE_APISERVER`，根据不同的节点情况，它有三种取值方式
|
||||
- 变量`MASTER_CHG`，变更 master 节点时会根据它来重新配置 haproxy
|
||||
|
||||
### 创建cni 基础网络插件配置文件
|
||||
|
||||
因为后续需要用 `DaemonSet Pod`方式运行k8s网络插件，所以kubelet.server服务必须开启cni相关参数，并且提供cni网络配置文件
|
||||
|
|
@ -118,15 +131,6 @@ WantedBy=multi-user.target
|
|||
+ --hostname-override 参数值必须与 kubelet 的值一致，否则 kube-proxy 启动后会找不到该 Node，从而不会创建任何 iptables 规则
|
||||
+ 特别注意：kube-proxy 根据 --cluster-cidr 判断集群内部和外部流量，指定 --cluster-cidr 或 --masquerade-all 选项后 kube-proxy 才会对访问 Service IP 的请求做 SNAT；但是这个特性与calico 实现 network policy冲突，所以如果要用 network policy，这两个选项都不要指定。
|
||||
|
||||
### 批准kubelet 的 TLS 证书请求
|
||||
|
||||
``` bash
|
||||
sleep 15 && {{ bin_dir }}/kubectl get csr|grep 'Pending' | awk 'NR>0{print $1}'| xargs {{ bin_dir }}/kubectl certificate approve
|
||||
```
|
||||
+ 增加15秒延时等待kubelet启动
|
||||
+ `kubectl get csr |grep 'Pending'` 找出待批准的 TLS请求
|
||||
+ `kubectl certificate approve` 批准请求
|
||||
|
||||
### 验证 node 状态
|
||||
|
||||
``` bash
|
||||
|
|
|
|||
|
|
@ -0,0 +1,123 @@
|
|||
## EX-LB 负载均衡部署
|
||||
|
||||
根据[HA 2x架构](00-planning_and_overall_intro.md)，k8s集群自身高可用已经不依赖于外部 lb 服务；但是有时我们要从外部访问 apiserver（比如 CI 流程），就需要 ex-lb 来请求多个 apiserver；
|
||||
|
||||
还有一种情况是需要[负载转发到ingress服务](../op/loadballance_ingress_nodeport.md)，也需要部署ex-lb；
|
||||
|
||||
当遇到公有云环境无法自建 ex-lb 服务时，可以配置对应的云负载均衡服务。
|
||||
|
||||
### ex-lb 服务组件
|
||||
|
||||
ex-lb 服务由 keepalived 和 haproxy 组成：
|
||||
- haproxy：高效代理（四层模式）转发到多个 apiserver
|
||||
- keepalived：利用主备节点vrrp协议通信和虚拟地址，消除haproxy的单点故障
|
||||
|
||||
``` bash
|
||||
roles/ex-lb/
|
||||
├── clean-ex-lb.yml
|
||||
├── defaults
|
||||
│ └── main.yml
|
||||
├── ex-lb.yml
|
||||
├── 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会将其剔除负载池。
|
||||
|
||||
#### 安装haproxy
|
||||
|
||||
+ 使用apt源安装
|
||||
|
||||
#### 配置haproxy (roles/ex-lb/templates/haproxy.cfg.j2)
|
||||
|
||||
配置由全局配置和三个listen配置组成：
|
||||
- listen kube-master 用于转发至多个apiserver
|
||||
- listen ingress-node 用于转发至node节点的ingress http服务，[参阅](../op/loadballance_ingress_nodeport.md)
|
||||
- listen ingress-node-tls 用于转发至node节点的ingress https服务
|
||||
|
||||
如果用apt安装的话，可以在/usr/share/doc/haproxy目录下找到配置指南configuration.txt.gz，全局和默认配置这里不展开，关注`listen` 代理设置模块，各项配置说明：
|
||||
+ 名称 kube-master
|
||||
+ bind 监听客户端请求的地址/端口，保证监听master的VIP地址和端口
|
||||
+ mode 选择四层负载模式 (当然你也可以选择七层负载，请查阅指南，适当调整)
|
||||
+ balance 选择负载算法 (负载算法也有很多供选择)
|
||||
|
||||
#### 安装keepalived
|
||||
|
||||
+ 使用apt源安装
|
||||
|
||||
#### 配置keepalived主节点 [keepalived-master.conf.j2](../../roles/ex-lb/templates/keepalived-master.conf.j2)
|
||||
|
||||
``` bash
|
||||
global_defs {
|
||||
router_id lb-master-{{ inventory_hostname }}
|
||||
}
|
||||
|
||||
vrrp_script check-haproxy {
|
||||
script "killall -0 haproxy"
|
||||
interval 5
|
||||
weight -60
|
||||
}
|
||||
|
||||
vrrp_instance VI-kube-master {
|
||||
state MASTER
|
||||
priority 120
|
||||
unicast_src_ip {{ inventory_hostname }}
|
||||
unicast_peer {
|
||||
{% for h in groups['ex-lb'] %}{% if h != inventory_hostname %}
|
||||
{{ h }}
|
||||
{% endif %}{% endfor %}
|
||||
}
|
||||
dont_track_primary
|
||||
interface {{ LB_IF }}
|
||||
virtual_router_id {{ ROUTER_ID }}
|
||||
advert_int 3
|
||||
track_script {
|
||||
check-haproxy
|
||||
}
|
||||
virtual_ipaddress {
|
||||
{{ EX_APISERVER_VIP }}
|
||||
}
|
||||
}
|
||||
```
|
||||
+ 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 !!!`类似报错
|
||||
+ 配置 vrrp 协议通过单播发送
|
||||
|
||||
#### 配置keepalived备节点 [keepalived-backup.conf.j2](../../roles/ex-lb/templates/keepalived-backup.conf.j2)
|
||||
|
||||
+ 备节点的配置类似主节点，除了优先级和检测脚本，其他如 `virtual_router_id` `advert_int` `virtual_ipaddress`必须与主节点一致
|
||||
|
||||
### 启动 keepalived 和 haproxy 后验证
|
||||
|
||||
+ lb 节点验证
|
||||
|
||||
``` bash
|
||||
systemctl status haproxy # 检查进程状态
|
||||
journalctl -u haproxy # 检查进程日志是否有报错信息
|
||||
systemctl status keepalived # 检查进程状态
|
||||
journalctl -u keepalived # 检查进程日志是否有报错信息
|
||||
```
|
||||
+ 在 keepalived 主节点
|
||||
|
||||
``` bash
|
||||
ip a # 检查 master的 VIP地址是否存在
|
||||
```
|
||||
### keepalived 主备切换演练
|
||||
|
||||
1. 尝试关闭 keepalived主节点上的 haproxy进程，然后在keepalived 备节点上查看 master的 VIP地址是否能够漂移过来，并依次检查上一步中的验证项。
|
||||
1. 尝试直接关闭 keepalived 主节点系统，检查各验证项。
|
||||
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
## 快速指南
|
||||
|
||||
以下为快速体验k8s集群的测试、开发环境--allinone部署，国内环境下觉得比官方的minikube方便、简单很多。
|
||||
以下为快速体验k8s集群的测试、开发环境--allinone部署，国内环境下比官方的minikube方便、简单很多。
|
||||
|
||||
### 1.基础系统配置
|
||||
|
||||
|
|
@ -69,7 +69,7 @@ if __name__ == '__main__':
|
|||
|
||||
``` bash
|
||||
# 方式一：使用git clone
|
||||
git clone --depth=1 https://github.com/easzlab/kubeasz.git /etc/ansible
|
||||
git clone --depth=1 https://github.com/easzlab/kubeasz.git -b dev2 /etc/ansible
|
||||
|
||||
# 方式二：从发布页面 https://github.com/easzlab/kubeasz/releases 下载源码解压到同样目录
|
||||
```
|
||||
|
|
@ -87,7 +87,7 @@ tar -xvf k8s.1-13-5.tar.gz -C /etc/ansible
|
|||
tar xvf basic_images_kubeasz_1.0.tar.gz -C /etc/ansible/down
|
||||
```
|
||||
- 4.3 配置集群参数
|
||||
- 4.3.1 必要配置：`cd /etc/ansible && cp example/hosts.allinone.example hosts`, 然后实际情况修改此hosts文件
|
||||
- 4.3.1 必要配置：`cd /etc/ansible && cp example/hosts.allinone hosts`, 然后实际情况修改此hosts文件
|
||||
- 4.3.2 可选配置，初次使用可以不做修改，详见[配置指南](config_guide.md)
|
||||
- 4.3.3 验证ansible 安装：`ansible all -m ping` 正常能看到节点返回 SUCCESS
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ CERT_EXPIRY: "438000h"
|
|||
# apiserver 默认第一个master节点
|
||||
KUBE_APISERVER: "https://{{ groups['kube-master'][0] }}:6443"
|
||||
|
||||
# kubeconfig 配置参数，注意权限根据‘CLUSTER_NAME’设置：
|
||||
# kubeconfig 配置参数，注意权限根据‘USER_NAME’设置：
|
||||
# 'admin' 表示创建集群管理员（所有）权限的 kubeconfig
|
||||
# 'read' 表示创建只读权限的 kubeconfig
|
||||
CLUSTER_NAME: "cluster1"
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ listen ingress-node-tls
|
|||
server {{ groups['kube-node'][2] }} {{ groups['kube-node'][2] }}:23457 check inter 5s fall 2 rise 2 weight 1
|
||||
{% else %}
|
||||
{% for host in groups['kube-node'] %}
|
||||
server {{ host }} {{ host }}:23456 check inter 5s fall 2 rise 2 weight 1
|
||||
server {{ host }} {{ host }}:23457 check inter 5s fall 2 rise 2 weight 1
|
||||
{% endfor %}
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
|
|
|
|||
|
|
@ -31,6 +31,7 @@
|
|||
shell: systemctl stop haproxy
|
||||
tags: restart_lb
|
||||
|
||||
# 仅 master 节点数大于1时才启动haproxy
|
||||
- name: 开启haproxy服务
|
||||
shell: systemctl start haproxy
|
||||
when: "groups['kube-master']|length > 1"
|
||||
|
|
|
|||
Loading…
Reference in New Issue