From 80217dc1cd46024a569ca3a0204a9c5663777b3b Mon Sep 17 00:00:00 2001 From: gjmzj Date: Sun, 9 Jun 2019 10:58:01 +0800 Subject: [PATCH] docs: update setup guide --- docs/op/loadballance_ingress_nodeport.md | 10 +- docs/setup/00-planning_and_overall_intro.md | 5 +- docs/setup/01-CA_and_prerequisite.md | 174 ++------------------ docs/setup/02-install_etcd.md | 5 +- docs/setup/03-install_docker.md | 18 +- docs/setup/04-install_kube_master.md | 30 ++-- docs/setup/05-install_kube_node.md | 38 +++-- docs/setup/ex-lb.md | 123 ++++++++++++++ docs/setup/quickStart.md | 6 +- roles/deploy/defaults/main.yml | 2 +- roles/ex-lb/templates/haproxy.cfg.j2 | 2 +- roles/kube-node/tasks/node_lb.yml | 1 + 12 files changed, 201 insertions(+), 213 deletions(-) create mode 100644 docs/setup/ex-lb.md diff --git a/docs/op/loadballance_ingress_nodeport.md b/docs/op/loadballance_ingress_nodeport.md index 67d80fd..2985ea4 100644 --- a/docs/op/loadballance_ingress_nodeport.md +++ b/docs/op/loadballance_ingress_nodeport.md @@ -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 ... 前文省略 diff --git a/docs/setup/00-planning_and_overall_intro.md b/docs/setup/00-planning_and_overall_intro.md index 99f0e88..b12bf57 100644 --- a/docs/setup/00-planning_and_overall_intro.md +++ b/docs/setup/00-planning_and_overall_intro.md @@ -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) ## 部署步骤 diff --git a/docs/setup/01-CA_and_prerequisite.md b/docs/setup/01-CA_and_prerequisite.md index 909da08..fc313af 100644 --- a/docs/setup/01-CA_and_prerequisite.md +++ b/docs/setup/01-CA_and_prerequisite.md @@ -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) diff --git a/docs/setup/02-install_etcd.md b/docs/setup/02-install_etcd.md index 23d5ee0..0bdcd05 100644 --- a/docs/setup/02-install_etcd.md +++ b/docs/setup/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服务 diff --git a/docs/setup/03-install_docker.md b/docs/setup/03-install_docker.md index 46999f3..e32ce81 100644 --- a/docs/setup/03-install_docker.md +++ b/docs/setup/03-install_docker.md @@ -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个就进行清理。 diff --git a/docs/setup/04-install_kube_master.md b/docs/setup/04-install_kube_master.md index 6cdacf6..d7a5265 100644 --- a/docs/setup/04-install_kube_master.md +++ b/docs/setup/04-install_kube_master.md @@ -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节点的主要组件： diff --git a/docs/setup/05-install_kube_node.md b/docs/setup/05-install_kube_node.md index 7415bc7..e388929 100644 --- a/docs/setup/05-install_kube_node.md +++ b/docs/setup/05-install_kube_node.md @@ -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 diff --git a/docs/setup/ex-lb.md b/docs/setup/ex-lb.md new file mode 100644 index 0000000..e6bc708 --- /dev/null +++ b/docs/setup/ex-lb.md @@ -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 主节点系统，检查各验证项。 + diff --git a/docs/setup/quickStart.md b/docs/setup/quickStart.md index 22062e6..89ebce1 100644 --- a/docs/setup/quickStart.md +++ b/docs/setup/quickStart.md @@ -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 diff --git a/roles/deploy/defaults/main.yml b/roles/deploy/defaults/main.yml index 4c1553c..d402c64 100644 --- a/roles/deploy/defaults/main.yml +++ b/roles/deploy/defaults/main.yml @@ -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" diff --git a/roles/ex-lb/templates/haproxy.cfg.j2 b/roles/ex-lb/templates/haproxy.cfg.j2 index 3cebcda..e64755a 100644 --- a/roles/ex-lb/templates/haproxy.cfg.j2 +++ b/roles/ex-lb/templates/haproxy.cfg.j2 @@ -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 %} diff --git a/roles/kube-node/tasks/node_lb.yml b/roles/kube-node/tasks/node_lb.yml index c13d2e6..5ed4a7a 100644 --- a/roles/kube-node/tasks/node_lb.yml +++ b/roles/kube-node/tasks/node_lb.yml @@ -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"