diff --git a/docs/setup/01-CA_and_prerequisite.md b/docs/setup/01-CA_and_prerequisite.md index a6727ca..909da08 100644 --- a/docs/setup/01-CA_and_prerequisite.md +++ b/docs/setup/01-CA_and_prerequisite.md @@ -1,6 +1,6 @@ # 01-创建证书和环境配置 -本步骤[01.prepare.yml](../01.prepare.yml)主要完成: +本步骤[01.prepare.yml](../../01.prepare.yml)主要完成: - chrony role: 集群节点时间同步[可选] - deploy role: 创建CA证书、kubeconfig、kube-proxy.kubeconfig @@ -9,7 +9,7 @@ ## deploy 角色 -请在另外窗口打开[roles/deploy/tasks/main.yml](../roles/deploy/tasks/main.yml) 文件,对照看以下讲解内容。 +请在另外窗口打开[roles/deploy/tasks/main.yml](../../roles/deploy/tasks/main.yml) 文件,对照看以下讲解内容。 ### 创建 CA 证书和秘钥 ``` bash @@ -34,7 +34,7 @@ kubernetes 系统各组件需要使用 TLS 证书对通信进行加密,使用 整个集群要使用统一的CA 证书,只需要在 deploy 节点创建,然后分发给其他节点;为了保证安装的幂等性,如果已经存在CA 证书,就跳过创建CA 步骤 -#### 创建 CA 配置文件 [ca-config.json.j2](../roles/deploy/templates/ca-config.json.j2) +#### 创建 CA 配置文件 [ca-config.json.j2](../../roles/deploy/templates/ca-config.json.j2) ``` bash { "signing": { @@ -60,7 +60,7 @@ kubernetes 系统各组件需要使用 TLS 证书对通信进行加密,使用 + `client auth`:表示可以用该 CA 对 client 提供的证书进行验证; + `profile kubernetes` 包含了`server auth`和`client auth`,所以可以签发三种不同类型证书; -#### 创建 CA 证书签名请求 [ca-csr.json.j2](../roles/deploy/templates/ca-csr.json.j2) +#### 创建 CA 证书签名请求 [ca-csr.json.j2](../../roles/deploy/templates/ca-csr.json.j2) ``` bash { "CN": "kubernetes", @@ -76,7 +76,10 @@ kubernetes 系统各组件需要使用 TLS 证书对通信进行加密,使用 "O": "k8s", "OU": "System" } - ] + ], + "ca": { + "expiry": "876000h" + } } ``` @@ -89,7 +92,7 @@ cfssl gencert -initca ca-csr.json | cfssljson -bare ca kubectl使用~/.kube/config 配置文件与kube-apiserver进行交互,且拥有管理 K8S集群的完全权限, -准备kubectl使用的admin 证书签名请求 [admin-csr.json.j2](../roles/deploy/templates/admin-csr.json.j2) +准备kubectl使用的admin 证书签名请求 [admin-csr.json.j2](../../roles/deploy/templates/admin-csr.json.j2) ``` bash { @@ -112,8 +115,7 @@ kubectl使用~/.kube/config 配置文件与kube-apiserver进行交互,且拥 ``` + kubectl 使用客户端证书可以不指定hosts 字段 -+ 证书请求中 `O` 指定该证书的 Group 为 `system:masters`,而 `RBAC` 预定义的 `ClusterRoleBinding` 将 Group `system:masters` 与 ClusterRole `cluster-admin` 绑定,这就赋予了kubectl**所有集群权限 -** ++ 证书请求中 `O` 指定该证书的 Group 为 `system:masters`,而 `RBAC` 预定义的 `ClusterRoleBinding` 将 Group `system:masters` 与 ClusterRole `cluster-admin` 绑定,这就赋予了kubectl**所有集群权限** ``` bash $ kubectl describe clusterrolebinding cluster-admin @@ -129,8 +131,23 @@ Subjects: Group system:masters ``` +#### 生成 cluster-admin 用户证书 + +``` +cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes admin-csr.json | cfssljson -bare admin +``` + +#### 生成 ~/.kube/config 配置文件 + 使用`kubectl config` 生成kubeconfig 自动保存到 ~/.kube/config,生成后 `cat ~/.kube/config`可以验证配置文件包含 kube-apiserver 地址、证书、用户名等信息。 +``` +kubectl config set-cluster kubernetes --certificate-authority=ca.pem --embed-certs=true --server=127.0.0.1:8443 +kubectl config set-credentials admin --client-certificate=admin.pem --embed-certs=true --client-key=admin-key.pem +kubectl config set-context kubernetes --cluster=kubernetes --user=admin +kubectl config use-context kubernetes +``` + ### 生成 kube-proxy.kubeconfig 配置文件 创建 kube-proxy 证书请求 @@ -171,6 +188,23 @@ Subjects: User system:kube-proxy ``` +#### 生成 system:kube-proxy 用户证书 + +``` +cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kube-proxy-csr.json | cfssljson -bare kube-proxy +``` + +#### 生成 kube-proxy.kubeconfig + +使用`kubectl config` 生成kubeconfig 自动保存到 kube-proxy.kubeconfig + +``` +kubectl config set-cluster kubernetes --certificate-authority=ca.pem --embed-certs=true --server=127.0.0.1:8443 --kubeconfig=kube-proxy.kubeconfig +kubectl config set-credentials kube-proxy --client-certificate=kube-proxy.pem --embed-certs=true --client-key=kube-proxy-key.pem --kubeconfig=kube-proxy.kubeconfig +kubectl config set-context default --cluster=kubernetes --user=kube-proxy --kubeconfig=kube-proxy.kubeconfig +kubectl config use-context default --kubeconfig=kube-proxy.kubeconfig +``` + ## prepare 角色 ``` bash @@ -180,7 +214,7 @@ roles/prepare/ └── tasks └── main.yml ``` -请在另外窗口打开[roles/prepare/tasks/main.yml](../roles/prepare/tasks/main.yml) 文件,比较简单直观 +请在另外窗口打开[roles/prepare/tasks/main.yml](../../roles/prepare/tasks/main.yml) 文件,比较简单直观 1. 首先创建一些基础文件目录 1. 修改环境变量,把{{ bin_dir }} 添加到$PATH,需要重新登陆 shell生效 @@ -210,13 +244,13 @@ keepalived与haproxy配合,实现master的高可用过程如下: + 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) 文件,对照看以下讲解内容。 +请在另外窗口打开[roles/lb/tasks/main.yml](../../roles/lb/tasks/main.yml) 文件,对照看以下讲解内容。 #### 安装haproxy + 使用apt源安装 -#### 配置haproxy [haproxy.cfg.j2](../roles/lb/templates/haproxy.cfg.j2) +#### 配置haproxy [haproxy.cfg.j2](../../roles/lb/templates/haproxy.cfg.j2) ``` bash global log /dev/log local0 @@ -248,13 +282,13 @@ listen kube-master + bind 监听客户端请求的地址/端口,保证监听master的VIP地址和端口 + mode 选择四层负载模式 (当然你也可以选择七层负载,请查阅指南,适当调整) + balance 选择负载算法 (负载算法也有很多供选择) -+ server 配置master节点真实的endpoits,必须与 [hosts文件](../example/hosts.m-masters.example)对应设置 ++ server 配置master节点真实的endpoits,必须与 [hosts文件](../../example/hosts.m-masters.example)对应设置 #### 安装keepalived + 使用apt源安装 -#### 配置keepalived主节点 [keepalived-master.conf.j2](../roles/lb/templates/keepalived-master.conf.j2) +#### 配置keepalived主节点 [keepalived-master.conf.j2](../../roles/lb/templates/keepalived-master.conf.j2) ``` bash global_defs { router_id lb-master @@ -285,7 +319,7 @@ vrrp_instance VI-kube-master { + 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) +#### 配置keepalived备节点 [keepalived-backup.conf.j2](../../roles/lb/templates/keepalived-backup.conf.j2) ``` bash global_defs { router_id lb-backup