【K8s+Docker技术全解】06.Master主控节点服务-部署kube-apiserver集群

# 部署Master主控节点服务 Master和Node是两个逻辑上节点，当服务器资源充足时，可以将其分开在不同的机器上部署，当服务器资源不足时，也可以放到同一台机器上部署。Master节点在部署的时候必须要考虑高可用方案，至少部署两个Master。 ## 99.151/152部署kube-apiserver集群 ### 什么是kube-apiserver？ 主节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端。是整个集群中资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制。 `kube-apiserver`提供了集群管理的restful api接口(鉴权、数据校验、集群变更等)，负责和其它模块之间进行数据交互，承担了通信枢纽功能。 通过`kubectl`操作集群资源时需要登陆到Master节点之上，而跨主机调用apiserver时，直接通过Master前端的负载均衡来实现。 这里 99.101、99.102 使用nginx做4层负载均衡器，使用keepalived做一个vip：拟规划IP为 192.168.99.100，依赖nginx代理kube-apiserver，实现高可用。 99.151、99.152则作为kube-apiserver安装服务器。 ### 下载k8s的Server Binaries版本 访问 https://github.com/kubernetes/kubernetes/releases 下载二进制包（点击CHANGELOG/CHANGELOG-1.18.md。.这选择 v1.18.2 版本 即跳转到 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md#server-binaries 进去之后找到 **Server Binaries**，下载**amd64**版本，链接为： https://dl.k8s.io/v1.18.2/kubernetes-server-linux-amd64.tar.gz v1.17.5：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.17.md#server-binaries v.1.16.9：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.16.md#server-binaries v.1.15.11：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.15.md#server-binaries ### 运维主机签发client证书 这个client证书是apiserver和etcd集群通信需要的证书，在这个通信过程中，etcd集群是server端，apiserver是客户端，所以需要做一个client证书给apiserver #### 创建client证书签名请求(csr)的json配置文件client-csr.json ```bash # 192.168.99.200 [root@k8s99-200 ~]# cd certs/ [root@k8s99-200 certs]# vim client-csr.json ``` 内容如下 ```json { "CN": "k8s_node", "hosts": [ ], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "sichuan", "L": "chengdu", "O": "study", "OU": "ops" } ] } ``` #### 生成基于该配置文件的证书 ```bash # 192.168.99.200 [root@k8s99-200 certs]# cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client client-csr.json | cfssljson -bare client # 查看签发的证书 [root@k8s99-200 certs]# ll | grep client -rw-r--r--. 1 root root 997 6月 1 22:56 client.csr -rw-r--r--. 1 root root 283 6月 1 22:56 client-csr.json -rw-------. 1 root root 1679 6月 1 22:56 client-key.pem -rw-r--r--. 1 root root 1387 6月 1 22:56 client.pem ``` ### 运维主机签发kube-apiserver证书 签发Server证书，apiserver对外提供服务，即连接apiserver需要证书 #### 创建client证书签名请求(csr)的json配置文件apiserver-csr.json ```bash # 192.168.99.200 [root@k8s99-200 certs]# vim apiserver-csr.json ``` 内容如下 ```json { "CN": "k8s_apiserver", "hosts": [ "127.0.0.1", "192.168.0.1", "kubernetes.default", "kubernetes.default.svc", "kubernetes.default.svc.cluster", "kubernetes.default.svc.cluster.local", "192.168.99.151", "192.168.99.152", "192.168.99.153", "192.168.99.100" ], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "sichuan", "L": "chengdu", "O": "study", "OU": "ops" } ] } ``` `hosts`里面写了apiserver可能部署的地址，把这些IP地址都写进去，另外还要加一个vip`192.168.99.100`，虚拟IP地址，后面nginx+keepalived方向代理时使用。 #### 生成kube-apiserver证书和私钥 ```bash # 192.168.99.200 [root@k8s99-200 certs]# cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server apiserver-csr.json | cfssljson -bare apiserver # 查看签发的证书 [root@k8s99-200 certs]# ll | grep apiserver -rw-r--r--. 1 root root 1253 6月 1 22:58 apiserver.csr -rw-r--r--. 1 root root 589 6月 1 22:57 apiserver-csr.json -rw-------. 1 root root 1675 6月 1 22:58 apiserver-key.pem -rw-r--r--. 1 root root 1619 6月 1 22:58 apiserver.pem ``` 对于上面两套证书，client证书是apiserver作为客户端需要使用这个证书去给etcd通信，还要签发一套server证书，当apiserver启动时，别人还需要拿客户端证书和apiserver通信。即apiserver要和etcd通信需要client证书，apiserver要启动需要server证书。这两套证书提供给后面部署kube-apiserver使用。 ### 99.151部署kube-apiserver #### 解压kubernetes 将下载的软件包上传到服务器上，然后解压 ```bash # 192.168.99.151 [root@k8s99-151 etcd]# cd ~ [root@k8s99-151 ~]# ls etcd-v3.3.19-linux-amd64.tar.gz kubernetes-server-linux-amd64-binaries-v1.18.2.tar.gz [root@k8s99-151 ~]# tar xzf kubernetes-server-linux-amd64-binaries-v1.18.2.tar.gz -C /opt/ [root@k8s99-151 ~]# cd /opt [root@k8s99-151 opt]# ls etcd etcd-v3.3.19 kubernetes # 将解压后的文件夹添加版本号保存，然后创建软链接，以便后面升级 [root@k8s99-151 opt]# mv kubernetes/ kubernetes-v1.18.2 [root@k8s99-151 opt]# ls etcd etcd-v3.3.19 kubernetes-v1.18.2 [root@k8s99-151 opt]# ln -s /opt/kubernetes-v1.18.2/ /opt/kubernetes [root@k8s99-151 opt]# ll 总用量 0 lrwxrwxrwx. 1 root root 12 6月 1 22:45 etcd -> etcd-v3.3.19 drwxr-xr-x. 5 etcd etcd 178 6月 1 22:46 etcd-v3.3.19 lrwxrwxrwx. 1 root root 24 6月 1 23:01 kubernetes -> /opt/kubernetes-v1.18.2/ drwxr-xr-x. 4 root root 79 4月 16 20:36 kubernetes-v1.18.2 ``` #### 查看kubernetes目录结构 ```bash [root@k8s99-151 opt]# cd kubernetes [root@k8s99-151 kubernetes]# ll 总用量 33100 drwxr-xr-x. 2 root root 6 4月 16 20:36 addons -rw-r--r--. 1 root root 32583402 4月 16 20:36 kubernetes-src.tar.gz # 源码包，不使用可以删除 -rw-r--r--. 1 root root 1309372 4月 16 20:36 LICENSES drwxr-xr-x. 3 root root 17 4月 16 20:31 server [root@k8s99-151 kubernetes]# cd server/ [root@k8s99-151 server]# ll 总用量 4 drwxr-xr-x. 2 root root 4096 4月 16 20:36 bin [root@k8s99-151 server]# ll bin/ 总用量 1086812 -rwxr-xr-x. 1 root root 48123904 4月 16 20:36 apiextensions-apiserver -rwxr-xr-x. 1 root root 39813120 4月 16 20:36 kubeadm -rwxr-xr-x. 1 root root 120664064 4月 16 20:36 kube-apiserver -rw-r--r--. 1 root root 8 4月 16 20:32 kube-apiserver.docker_tag -rw-------. 1 root root 174562304 4月 16 20:32 kube-apiserver.tar -rwxr-xr-x. 1 root root 110051328 4月 16 20:36 kube-controller-manager -rw-r--r--. 1 root root 8 4月 16 20:32 kube-controller-manager.docker_tag -rw-------. 1 root root 163949568 4月 16 20:32 kube-controller-manager.tar -rwxr-xr-x. 1 root root 44032000 4月 16 20:36 kubectl -rwxr-xr-x. 1 root root 113275608 4月 16 20:36 kubelet -rwxr-xr-x. 1 root root 38379520 4月 16 20:36 kube-proxy -rw-r--r--. 1 root root 8 4月 16 20:32 kube-proxy.docker_tag -rw-------. 1 root root 118547456 4月 16 20:32 kube-proxy.tar -rwxr-xr-x. 1 root root 42942464 4月 16 20:36 kube-scheduler -rw-r--r--. 1 root root 8 4月 16 20:32 kube-scheduler.docker_tag -rw-------. 1 root root 96840704 4月 16 20:32 kube-scheduler.tar -rwxr-xr-x. 1 root root 1687552 4月 16 20:36 mounter # 里面的 .tar 文件，是Docker镜像，以及 .docker_tag 文件，kubeadm部署才用得到。在现在这种部署方式中用不到，可以通过执行下面命令删除 [root@k8s99-151 server]# cd bin/ [root@k8s99-151 bin]# rm *.tag [root@k8s99-151 bin]# rm *_tag ``` 这一般用到的有`kube-apiserver`、`kube-controller-manager`、`kubectl`、`kubelet`、`kube-proxy`、`kube-scheduler` #### 拷贝证书到各运算节点 拷贝证书（`ca.pem`、`client.pem`、`apiserver.pem`）、私钥（`client-key.pem`、`apiserver-key.pem`），注意私钥文件属性是600 ```bash # 192.168.99.151 [root@k8s99-151 bin]# pwd /opt/kubernetes/server/bin # 测试是否ping通主机名，ping不通，添加hosts [root@k8s99-151 bin]# ping k8s99-200 ping: k8s99-200: 未知的名称或服务 [root@k8s99-151 bin]# /etc/rc.local [root@k8s99-151 bin]# ping k8s99-200 PING k8s99-200.host.com (192.168.99.200) 56(84) bytes of data. 64 bytes from 192.168.99.200 (192.168.99.200): icmp_seq=1 ttl=64 time=0.678 ms # 在 /opt/kubernetes/server/bin 创建存放证书的文件夹 [root@k8s99-151 bin]# mkdir certs [root@k8s99-151 bin]# cd certs/ # 拷贝证书和私钥到本机当前文件夹 [root@k8s99-151 certs]# scp k8s99-200:/opt/certs/ca.pem . root@k8s99-200`s password: ca.pem 100% 1354 241.6KB/s 00:00 [root@k8s99-151 certs]# scp k8s99-200:/opt/certs/ca-key.pem . root@k8s99-200`s password: ca-key.pem 100% 1675 1.6MB/s 00:00 [root@k8s99-151 certs]# scp k8s99-200:/opt/certs/client.pem . root@k8s99-200`s password: client.pem 100% 1387 1.9MB/s 00:00 [root@k8s99-151 certs]# scp k8s99-200:/opt/certs/client-key.pem . root@k8s99-200`s password: client-key.pem 100% 1679 1.0MB/s 00:00 [root@k8s99-151 certs]# scp k8s99-200:/opt/certs/apiserver.pem . root@k8s99-200`s password: apiserver.pem 100% 1610 1.5MB/s 00:00 [root@k8s99-151 certs]# scp k8s99-200:/opt/certs/apiserver-key.pem . root@k8s99-200`s password: apiserver-key.pem # 查看复制的文件 [root@k8s99-151 certs]# ll 总用量 24 -rw-------. 1 root root 1675 6月 1 23:03 apiserver-key.pem -rw-r--r--. 1 root root 1619 6月 1 23:03 apiserver.pem -rw-------. 1 root root 1675 6月 1 23:03 ca-key.pem -rw-r--r--. 1 root root 1354 6月 1 23:03 ca.pem -rw-------. 1 root root 1679 6月 1 23:03 client-key.pem -rw-r--r--. 1 root root 1387 6月 1 23:03 client.pem ``` #### 创建kube-apiserver启动脚本 ##### kube-apiserver审计日志记录和采集 Kubernetes 审计功能提供了与安全相关的按时间顺序排列的记录集，记录单个用户、管理员或系统其他组件影响系统的活动顺序。它能帮助集群管理员处理以下问题： - 发生了什么？ - 什么时候发生的？ - 谁触发的？ - 为什么发生？ - 在哪观察到的？ - 它从哪触发的？ - 它将产生什么后果？ Kube-apiserver 执行审计。每个执行阶段的每个请求都会生成一个事件，然后根据特定策略对事件进行预处理并写入后端。 每个请求都可以用相关的 “stage” 记录。已知的 stage 有： - **RequestReceived -** 事件的 stage 将在审计处理器接收到请求后，并且在委托给其余处理器之前生成。 - **ResponseStarted -** 在响应消息的头部发送后，但是响应消息体发送前。这个 stage 仅为长时间运行的请求生成（例如 watch）。 - **ResponseComplete -** 当响应消息体完成并且没有更多数据需要传输的时候。 - **Panic -** 当 panic 发生时生成。 审计日志记录功能会增加 API server的内存消耗，因为需要为每个请求存储审计所需的某些上下文。此外，内存消耗取决于审计日志记录的配置。 **审计策略** 审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的 \[审计级别\]\[auditing-level\]。已知的审计级别有： **None -** 符合这条规则的日志将不会记录。 **Metadata -** 记录请求的 metadata（请求的用户、timestamp、resource、verb 等等），但是不记录请求或者响应的消息体。 **Request -** 记录事件的 metadata 和请求的消息体，但是不记录响应的消息体。这不适用于非资源类型的请求。 **RequestResponse -**记录事件的 metadata，请求和响应的消息体。这不适用于非资源类型的请求。 您可以使用 --audit-policy-file 标志将包含策略的文件传递给 kube-apiserver。如果不设置该标志，则不记录事件。注意 rules 字段必须在审计策略文件中提供。 ```bash # 192.168.99.151 [root@k8s99-151 certs]# cd .. [root@k8s99-151 bin]# pwd /opt/kubernetes/server/bin # 创建配置文件目录 [root@k8s99-151 bin]# mkdir conf && cd conf [root@k8s99-151 conf]# vim audit.yaml ``` apiserver启动时必须要的一个配置。 内容如下（直接网上复制的，如果vim按i粘贴出现缩进问题，在命令模式下shift+:输入set paste回车，再按i输入） ```yaml apiVersion: audit.k8s.io/v1beta1 # This is required. kind: Policy # Don't generate audit events for all requests in RequestReceived stage. omitStages: - "RequestReceived" rules: # Log pod changes at RequestResponse level - level: RequestResponse resources: - group: "" # Resource "pods" doesn't match requests to any subresource of pods, # which is consistent with the RBAC policy. resources: ["pods"] # Log "pods/log", "pods/status" at Metadata level - level: Metadata resources: - group: "" resources: ["pods/log", "pods/status"] # Don't log requests to a configmap called "controller-leader" - level: None resources: - group: "" resources: ["configmaps"] resourceNames: ["controller-leader"] # Don't log watch requests by the "system:kube-proxy" on endpoints or services - level: None users: ["system:kube-proxy"] verbs: ["watch"] resources: - group: "" # core API group resources: ["endpoints", "services"] # Don't log authenticated requests to certain non-resource URL paths. - level: None userGroups: ["system:authenticated"] nonResourceURLs: - "/api*" # Wildcard matching. - "/version" # Log the request body of configmap changes in kube-system. - level: Request resources: - group: "" # core API group resources: ["configmaps"] # This rule only applies to resources in the "kube-system" namespace. # The empty string "" can be used to select non-namespaced resources. namespaces: ["kube-system"] # Log configmap and secret changes in all other namespaces at the Metadata level. - level: Metadata resources: - group: "" # core API group resources: ["secrets", "configmaps"] # Log all other resources in core and extensions at the Request level. - level: Request resources: - group: "" # core API group - group: "extensions" # Version of group should NOT be included. # A catch-all rule to log all other requests at the Metadata level. - level: Metadata # Long-running requests like watches that fall under this rule will not # generate an audit event in RequestReceived. omitStages: - "RequestReceived" ``` ##### 创建启动脚本kube-apiserver-startup.sh 可以通过`./kube-apiserver --help`查看到命令的参数 现在创建一个启动脚本，直接通过脚本来启动apiserver ```bash # 192.168.99.151 [root@k8s99-151 conf]# cd .. # 可以看到有很多参数，grep -A 5，显示5行 [root@k8s99-151 bin]# ./kube-apiserver --help | grep -A 5 apiserver-count # 创建日志目录 [root@k8s99-151 bin]# mkdir /var/log/kube-apiserver/ [root@k8s99-151 bin]# mkdir /var/log/kube-apiserver/audit-log [root@k8s99-151 bin]# vim kube-apiserver-startup.sh # 写入以下内容 #!/bin/bash ./kube-apiserver \ --apiserver-count 2 \ --audit-log-path /var/log/kube-apiserver/audit-log \ --audit-policy-file ./conf/audit.yaml \ --authorization-mode RBAC \ --client-ca-file ./certs/ca.pem \ --requestheader-client-ca-file ./certs/ca.pem \ --enable-admission-plugins NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota \ --etcd-cafile ./certs/ca.pem \ --etcd-certfile ./certs/client.pem \ --etcd-keyfile ./certs/client-key.pem \ --etcd-servers https://192.168.99.102:2379,https://192.168.99.151:2379,https://192.168.99.152:2379 \ --service-account-key-file ./certs/ca-key.pem \ --service-cluster-ip-range 192.168.0.0/16 \ --service-node-port-range 3000-29999 \ --target-ram-mb=1024 \ --kubelet-client-certificate ./certs/client.pem \ --kubelet-client-key ./certs/client-key.pem \ --log-dir /var/log/kube-apiserver/ \ --tls-cert-file ./certs/apiserver.pem \ --tls-private-key-file ./certs/apiserver-key.pem \ --v 2 ``` 添加执行权限 ```bash # 192.168.99.151 [root@k8s99-151 bin]# chmod +x kube-apiserver-startup.sh [root@k8s99-151 bin]# ll | grep *.sh -rwxr-xr-x. 1 root root 1119 4月 24 23:17 kube-apiserver-startup.sh # 然后可以通过下面命令测试启动 [root@k8s99-151 bin]# ./kube-apiserver-startup.sh ``` 若出现下面的日志 ```bash W0425 20:42:24.813407 1902 clientconn.go:1208] grpc: addrConn.createTransport failed to connect to {https://192.168.99.151:2379 <nil> 0 <nil>}. Err :connection error: desc = "transport: Error while dialing dial tcp 192.168.99.xxx:2379: connect: connection refused". Reconnecting... ``` 表示etcd节点没启动（通过`netstat -luntp | grep etcd`检查）或者是防火墙没允许该端口（通过`firewall-cmd --list-port`检查） #### 使用supervisor启动apiserver ##### 创建apiserver的supervisor启动配置 创建kube-apiserver的supervisor配置文件 ```bash # 192.168.99.151 [root@k8s99-151 bin]# vim /etc/supervisord.d/kube-apiserver.ini # 如以下内容 ``` ```ini [program:kube-apiserver-k8s99-151] command=/opt/kubernetes/server/bin/kube-apiserver-startup.sh numprocs=1 directory=/opt/kubernetes/server/bin/ autostart=true autorestart=true startsecs=30 startretries=3 exitcodes=0,2 stopsignal=QUIT stopwaitsecs=10 user=root redirect_stderr=true stdout_logfile=/var/log/kube-apiserver/apiserver.stdout.log stdout_logfile_maxbytes=64MB stdout_logfile_backups=4 stdout_capture_maxbytes=1MB stdout_events_enabled=false ``` 相较于etcd的supervisor配置，这儿主要是要修改执行命令`command`； 进入的目录`directory`，否则`kube-apiserver-startup.sh`的相对目录找不到； 以及启动的用户`user`，直接是root启动，否则读取读取`apiserver-key.pem`显示无权限； 最后一个就是`stdout_logfile`，日志输出，方便查看运行的错误日志。 ##### 启动kube-apiserver-k8s99-151 ```bash # 192.168.99.151 [root@k8s99-151 bin]# supervisorctl update kube-apiserver-k8s99-151: added process group [root@k8s99-151 bin]# supervisorctl status etcd-server-k8s99-151 RUNNING pid 8223, uptime 1 day, 1:50:59 kube-apiserver-k8s99-151 FATAL Exited too quickly (process log may have details) # 咋又报错了。。。原因是启动用户user=root没修改 [root@k8s99-151 bin]# cat /var/log/kube-apiserver/apiserver.stdout.log | grep Error Error: open ./certs/apiserver-key.pem: permission denied # 根据日志的错误提示修复后启动 [root@k8s99-151 bin]# supervisorctl update kube-apiserver-k8s99-151: stopped kube-apiserver-k8s99-151: updated process group [root@k8s99-151 bin]# supervisorctl status etcd-server-k8s99-151 RUNNING pid 3289, uptime 0:19:59 kube-apiserver-k8s99-151 RUNNING pid 3517, uptime 0:00:45 ``` 现在就把apiserver成功启动起来了。 #### 检查apiserver端口监听 使用supervisor启动后，可以检查kube-apiserver的端口监听 ```bash # 192.168.99.151 [root@k8s99-151 bin]# netstat -luntp | grep kube-apiserv tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 3518/./kube-apiserv tcp6 0 0 :::6443 :::* LISTEN 3518/./kube-apiserv ``` 注意启动的程序名称为`kube-apiserv`，难怪过滤`kube-apiserver`没结果 apiserver启动以后监听本地回环8080端口，另一个是监听6443端口 #### 防火墙允许对外端口 ```bash # 192.168.99.151 [root@k8s99-151 bin]# firewall-cmd --zone=public --add-port=6443/tcp --permanent [root@k8s99-151 bin]# firewall-cmd --reload ``` ### 99.152部署kube-apiserver 类似上面的部署方式，一般只需要修改`kube-apiserver.ini`配置文件即可 ```bash # 192.168.99.152 cd ~ mkdir /opt/ # 解压kubernets tar xzf kubernetes-server-linux-amd64-binaries-v1.18.2.tar.gz -C /opt/ # 创建软连接 cd /opt mv kubernetes/ kubernetes-v1.18.2 ln -s /opt/kubernetes-v1.18.2/ /opt/kubernetes # 进入kubernets执行文件目录 cd kubernetes cd server/bin/ rm -f *.tar rm -f *_tag ll # 拷贝运维主机上的证书和私钥到当前目录 /etc/rc.local # 防止短域名不通 mkdir certs cd certs/ # 需要手动拷贝 scp k8s99-200:/opt/certs/ca.pem . scp k8s99-200:/opt/certs/ca-key.pem . scp k8s99-200:/opt/certs/client.pem . scp k8s99-200:/opt/certs/client-key.pem . scp k8s99-200:/opt/certs/apiserver.pem . scp k8s99-200:/opt/certs/apiserver-key.pem . ll # 创建audit.yaml配置 cd .. mkdir conf cd conf/ cat > audit.yaml << EOF apiVersion: audit.k8s.io/v1beta1 # This is required. kind: Policy # Don't generate audit events for all requests in RequestReceived stage. omitStages: - "RequestReceived" rules: # Log pod changes at RequestResponse level - level: RequestResponse resources: - group: "" # Resource "pods" doesn't match requests to any subresource of pods, # which is consistent with the RBAC policy. resources: ["pods"] # Log "pods/log", "pods/status" at Metadata level - level: Metadata resources: - group: "" resources: ["pods/log", "pods/status"] # Don't log requests to a configmap called "controller-leader" - level: None resources: - group: "" resources: ["configmaps"] resourceNames: ["controller-leader"] # Don't log watch requests by the "system:kube-proxy" on endpoints or services - level: None users: ["system:kube-proxy"] verbs: ["watch"] resources: - group: "" # core API group resources: ["endpoints", "services"] # Don't log authenticated requests to certain non-resource URL paths. - level: None userGroups: ["system:authenticated"] nonResourceURLs: - "/api*" # Wildcard matching. - "/version" # Log the request body of configmap changes in kube-system. - level: Request resources: - group: "" # core API group resources: ["configmaps"] # This rule only applies to resources in the "kube-system" namespace. # The empty string "" can be used to select non-namespaced resources. namespaces: ["kube-system"] # Log configmap and secret changes in all other namespaces at the Metadata level. - level: Metadata resources: - group: "" # core API group resources: ["secrets", "configmaps"] # Log all other resources in core and extensions at the Request level. - level: Request resources: - group: "" # core API group - group: "extensions" # Version of group should NOT be included. # A catch-all rule to log all other requests at the Metadata level. - level: Metadata # Long-running requests like watches that fall under this rule will not # generate an audit event in RequestReceived. omitStages: - "RequestReceived" EOF # 创建启动脚本，和99.101一样 cd .. mkdir -p /var/log/kube-apiserver/audit-log # echo里面使用单引号，因为里面有! echo '#!/bin/bash ./kube-apiserver \ --apiserver-count 2 \ --audit-log-path /var/log/kube-apiserver/audit-log \ --audit-policy-file ./conf/audit.yaml \ --authorization-mode RBAC \ --client-ca-file ./certs/ca.pem \ --requestheader-client-ca-file ./certs/ca.pem \ --enable-admission-plugins NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota \ --etcd-cafile ./certs/ca.pem \ --etcd-certfile ./certs/client.pem \ --etcd-keyfile ./certs/client-key.pem \ --etcd-servers https://192.168.99.102:2379,https://192.168.99.151:2379,https://192.168.99.152:2379 \ --service-account-key-file ./certs/ca-key.pem \ --service-cluster-ip-range 192.168.0.0/16 \ --service-node-port-range 3000-29999 \ --target-ram-mb=1024 \ --kubelet-client-certificate ./certs/client.pem \ --kubelet-client-key ./certs/client-key.pem \ --log-dir /var/log/kube-apiserver/ \ --tls-cert-file ./certs/apiserver.pem \ --tls-private-key-file ./certs/apiserver-key.pem \ --v 2' > kube-apiserver-startup.sh chmod +x kube-apiserver-startup.sh ll | grep *.sh # 测试脚本启动 ./kube-apiserver-startup.sh # 使用supervisor启动，需要修改启动明曾 echo "[program:kube-apiserver-k8s99-152] command=/opt/kubernetes/server/bin/kube-apiserver-startup.sh numprocs=1 directory=/opt/kubernetes/server/bin/ autostart=true autorestart=true startsecs=30 startretries=3 exitcodes=0,2 stopsignal=QUIT stopwaitsecs=10 user=root redirect_stderr=true stdout_logfile=/var/log/kube-apiserver/apiserver.stdout.log stdout_logfile_maxbytes=64MB stdout_logfile_backups=4 stdout_capture_maxbytes=1MB stdout_events_enabled=false" > /etc/supervisord.d/kube-apiserver.ini supervisorctl update # 检查apiserver启动状态和端口监听状态 supervisorctl status && netstat -luntp | grep kube-apiserv # 防火墙允许对外端口 firewall-cmd --zone=public --add-port=6443/tcp --permanent firewall-cmd --reload ```

明人不说暗话 领红包就是支持！！！ 来都来了，再到页面底部看下呗~ ↓ ↓ ↓

本文地址： http://blog.starmeow.cn/detail/4734ba6f3de83d861c3176a6273cac6d/

很赞哦！ (0)