接上文:手动搭建高可用的kubernetes集群(一)
4. 配置kubectl 命令行工具 kubectl默认从~/.kube/config配置文件中获取访问kube-apiserver 地址、证书、用户名等信息,需要正确配置该文件才能正常使用kubectl命令。
需要将下载的kubectl 二进制文件和生产的~/.kube/config配置文件拷贝到需要使用kubectl 命令的机器上。
很多童鞋说这个地方不知道在哪个节点上执行,kubectl只是一个和kube-apiserver进行交互的一个命令行工具,所以你想安装到那个节点都行,master或者node任意节点都可以,比如你先在master节点上安装,这样你就可以在master节点使用kubectl命令行工具了,如果你想在node节点上使用(当然安装的过程肯定会用到的),你就把master上面的kubectl二进制文件和~/.kube/config文件拷贝到对应的node节点上就行了。
环境变量 1 2 $ source /usr/k8s/bin/env.sh $ export KUBE_APISERVER="https://${MASTER_URL} :6443"
注意这里的KUBE_APISERVER地址,因为我们还没有安装haproxy,所以暂时需要手动指定使用apiserver的6443端口,等haproxy安装完成后就可以用使用443端口转发到6443端口去了。
变量KUBE_APISERVER 指定kubelet 访问的kube-apiserver 的地址,后续被写入~/.kube/config配置文件
下载kubectl 1 2 3 4 5 $ wget https: //dl.k8s.io/v 1.8.2 /kubernetes-client-linux-amd64.tar.gz $ tar -xzvf kubernetes-client-linux-amd64.tar.gz$ sudo cp kubernetes/client/bin/kube* /usr/k 8s/bin/$ sudo chmod a+x /usr/k8s/bin/kube*$ export PATH=/usr/k 8s/bin: $PATH
创建admin 证书 kubectl 与kube-apiserver 的安全端口通信,需要为安全通信提供TLS 证书和密钥。创建admin 证书签名请求:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 $ cat > admin-csr.json <<EOF { "CN" : "admin" , "hosts" : [], "key" : { "algo" : "rsa" , "size" : 2048 }, "names" : [ { "C" : "CN" , "ST" : "BeiJing" , "L" : "BeiJing" , "O" : "system:masters" , "OU" : "System" } ] } EOF
后续kube-apiserver使用RBAC 对客户端(如kubelet、kube-proxy、Pod)请求进行授权
kube-apiserver 预定义了一些RBAC 使用的RoleBindings,如cluster-admin 将Group system:masters与Role cluster-admin绑定,该Role 授予了调用kube-apiserver所有API 的权限
O 指定了该证书的Group 为system:masters,kubectl使用该证书访问kube-apiserver时,由于证书被CA 签名,所以认证通过,同时由于证书用户组为经过预授权的system:masters,所以被授予访问所有API 的劝降
hosts 属性值为空列表
生成admin 证书和私钥:
1 2 3 4 5 6 7 $ cfssl gencert -ca=/etc/kubernetes /ssl/ca .pem \ -ca-key=/etc/kubernetes /ssl/ca -key.pem \ -config=/etc/kubernetes /ssl/ca -config.json \ -profile=kubernetes admin-csr.json | cfssljson -bare admin $ ls adminadmin.csr admin-csr.json admin-key.pem admin.pem $ sudo mv admin*.pem /etc/kubernetes/ssl/
创建kubectl kubeconfig 文件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 $ kubectl config set-cluster kubernetes \ --certificate-authority =/etc/kubernetes/ssl/ca.pem \ --embed-certs =true \ --server =${KUBE_APISERVER} $ kubectl config set-credentials admin \ --client-certificate =/etc/kubernetes/ssl/admin.pem \ --embed-certs =true \ --client-key =/etc/kubernetes/ssl/admin-key.pem \ --token =${BOOTSTRAP_TOKEN} $ kubectl config set-context kubernetes \ --cluster =kubernetes \ --user =admin $ kubectl config use-context kubernetes
admin.pem证书O 字段值为system:masters,kube-apiserver 预定义的 RoleBinding cluster-admin 将 Group system:masters 与 Role cluster-admin 绑定,该 Role 授予了调用kube-apiserver 相关 API 的权限
生成的kubeconfig 被保存到 ~/.kube/config 文件
分发kubeconfig 文件 将~/.kube/config文件拷贝到运行kubectl命令的机器的~/.kube/目录下去。
5. 部署Flannel 网络 kubernetes 要求集群内各节点能通过Pod 网段互联互通,下面我们来使用Flannel 在所有节点上创建互联互通的Pod 网段的步骤。
需要在所有的Node节点安装。
环境变量 1 2 3 $ export NODE_IP=192.168.1.137 # 导入全局变量 $ source /usr/k8s/bin/env.sh
创建TLS 密钥和证书 etcd 集群启用了双向TLS 认证,所以需要为flanneld 指定与etcd 集群通信的CA 和密钥。
创建flanneld 证书签名请求:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 $ cat > flanneld-csr.json <<EOF { "CN" : "flanneld" , "hosts" : [], "key" : { "algo" : "rsa" , "size" : 2048 }, "names" : [ { "C" : "CN" , "ST" : "BeiJing" , "L" : "BeiJing" , "O" : "k8s" , "OU" : "System" } ] } EOF
生成flanneld 证书和私钥:
1 2 3 4 5 6 7 8 $ cfssl gencert -ca=/etc/kubernetes /ssl/ca .pem \ -ca-key=/etc/kubernetes /ssl/ca -key.pem \ -config=/etc/kubernetes /ssl/ca -config.json \ -profile=kubernetes flanneld-csr.json | cfssljson -bare flanneld $ ls flanneld*flanneld.csr flanneld-csr.json flanneld-key.pem flanneld.pem $ sudo mkdir -p /etc/flanneld/ssl$ sudo mv flanneld*.pem /etc/flanneld/ssl
向etcd 写入集群Pod 网段信息
该步骤只需在第一次部署Flannel 网络时执行,后续在其他节点上部署Flanneld 时无需再写入该信息
1 2 3 4 5 6 7 8 $ etcdctl \ --endpoints=${ETCD_ENDPOINTS} \ --ca -file =/etc/kubernetes/ssl/ca .pem \ --cert-file =/etc/flanneld/ssl/flanneld.pem \ --key-file =/etc/flanneld/ssl/flanneld-key.pem \ set ${FLANNEL_ETCD_PREFIX} /config '{"Network" :"'${CLUSTER_CIDR}'" , "SubnetLen" : 24, "Backend" : {"Type" : "vxlan" }}' # 得到如下反馈信息 {"Network" :"172.30.0.0/16" , "SubnetLen" : 24, "Backend" : {"Type" : "vxlan" }}
写入的 Pod 网段(${CLUSTER_CIDR},172.30.0.0/16) 必须与kube-controller-manager 的 –cluster-cidr 选项值一致;
安装和配置flanneld 前往flanneld release 页面下载最新版的flanneld 二进制文件:
1 2 3 4 $ mkdir flannel$ wget https: //github.com/coreos /flannel/releases /download/v 0 .9.0 /flannel-v0 .9.0 -linux-amd64.tar.gz$ tar -xzvf flannel-v0 .9.0 -linux-amd64.tar.gz -C flannel$ sudo cp flannel/{flanneld,mk-docker-opts.sh} /usr/k8s/bin
创建flanneld的systemd unit 文件
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 $ cat > flanneld.service << EOF [Unit] Description =Flanneld overlay address etcd agentAfter =network.targetAfter =network-online.targetWants =network-online.targetAfter =etcd.serviceBefore =docker.service[Service] Type =notifyExecStart =/usr/k8s/bin/flanneld \\ -etcd-cafile =/etc/kubernetes/ssl/ca.pem \\ -etcd-certfile =/etc/flanneld/ssl/flanneld.pem \\ -etcd-keyfile =/etc/flanneld/ssl/flanneld-key.pem \\ -etcd-endpoints =${ETCD_ENDPOINTS} \\ -etcd-prefix =${FLANNEL_ETCD_PREFIX} ExecStartPost =/usr/k8s/bin/mk-docker-opts.sh -k DOCKER_NETWORK_OPTIONS -d /run/flannel/dockerRestart =on-failure[Install] WantedBy =multi-user.targetRequiredBy =docker.serviceEOF
mk-docker-opts.sh脚本将分配给flanneld 的Pod 子网网段信息写入到/run/flannel/docker 文件中,后续docker 启动时使用这个文件中的参数值为 docker0 网桥
flanneld 使用系统缺省路由所在的接口和其他节点通信,对于有多个网络接口的机器(内网和公网),可以用 –iface 选项值指定通信接口(上面的 systemd unit 文件没指定这个选项)
启动flanneld 1 2 3 4 5 $ sudo cp flanneld.service /etc/systemd/system /$ sudo systemctl daemon-reload$ sudo systemctl enable flanneld$ sudo systemctl start flanneld$ systemctl status flanneld
检查flanneld 服务
检查分配给各flanneld 的Pod 网段信息 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 $ # 查看集群 Pod 网段(/16) $ etcdctl \ --endpoints =${ETCD_ENDPOINTS} \ --ca-file =/etc/kubernetes/ssl/ca.pem \ --cert-file =/etc/flanneld/ssl/flanneld.pem \ --key-file =/etc/flanneld/ssl/flanneld-key.pem \ get ${FLANNEL_ETCD_PREFIX} /config { "Network" : "172.30.0.0/16" , "SubnetLen" : 24, "Backend" : { "Type" : "vxlan" } } $ # 查看已分配的 Pod 子网段列表(/24) $ etcdctl \ --endpoints =${ETCD_ENDPOINTS} \ --ca-file =/etc/kubernetes/ssl/ca.pem \ --cert-file =/etc/flanneld/ssl/flanneld.pem \ --key-file =/etc/flanneld/ssl/flanneld-key.pem \ ls ${FLANNEL_ETCD_PREFIX} /subnets /kubernetes/network/subnets/172.30.77.0-24 $ # 查看某一 Pod 网段对应的 flanneld 进程监听的 IP 和网络参数 $ etcdctl \ --endpoints =${ETCD_ENDPOINTS} \ --ca-file =/etc/kubernetes/ssl/ca.pem \ --cert-file =/etc/flanneld/ssl/flanneld.pem \ --key-file =/etc/flanneld/ssl/flanneld-key.pem \ get ${FLANNEL_ETCD_PREFIX} /subnets/172.30.77.0-24 {"PublicIP" :"192.168.1.137" ,"BackendType" :"vxlan" ,"BackendData" :{"VtepMAC" :"62:fc:03:83:1b:2b" }}
确保各节点间Pod 网段能互联互通 在各个节点部署完Flanneld 后,查看已分配的Pod 子网段列表:
1 2 3 4 5 6 7 8 9 10 11 12 $ etcdctl \ --endpoints=${ETCD_ENDPOINTS} \ --ca-file=/etc/kubernetes/ssl/ca.pem \ --cert-file=/etc/flanneld/ssl/flanneld.pem \ --key -file=/etc/flanneld/ssl/flanneld-key .pem \ ls ${FLANNEL_ETCD_PREFIX}/subnets /kubernetes/network/subnets/172.30 .19 .0 -24 /kubernetes/network/subnets/172.30 .30 .0 -24 /kubernetes/network/subnets/172.30 .77 .0 -24 /kubernetes/network/subnets/172.30 .41 .0 -24 /kubernetes/network/subnets/172.30 .83 .0 -24
当前五个节点分配的 Pod 网段分别是:172.30.77.0-24、172.30.30.0-24、172.30.19.0-24、172.30.41.0-24、172.30.83.0-24。
6. 部署master 节点 kubernetes master 节点包含的组件有:
kube-apiserver
kube-scheduler
kube-controller-manager
目前这3个组件需要部署到同一台机器上:(后面再部署高可用的master)
kube-scheduler、kube-controller-manager 和 kube-apiserver 三者的功能紧密相关;
同时只能有一个 kube-scheduler、kube-controller-manager 进程处于工作状态,如果运行多个,则需要通过选举产生一个 leader;
master 节点与node 节点上的Pods 通过Pod 网络通信,所以需要在master 节点上部署Flannel 网络。
环境变量 1 2 $ export NODE_IP=192.168.1.137 $ source /usr/k8s/bin/env.sh
下载最新版本的二进制文件 在kubernetes changelog 页面下载最新版本的文件:
1 2 $ wget https: $ tar -xzvf kubernetes-server-linux-amd64.tar .gz
将二进制文件拷贝到/usr/k8s/bin目录
1 $ sudo cp -r server/bin/ {kube-apiserver,kube-controller-manager,kube-scheduler} /usr/ k8s/bin/
创建kubernetes 证书 创建kubernetes 证书签名请求:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 $ cat > kubernetes-csr.json <<EOF { "CN" : "kubernetes" , "hosts" : [ "127.0.0.1" , "${NODE_IP} " , "${MASTER_URL} " , "${CLUSTER_KUBERNETES_SVC_IP} " , "kubernetes" , "kubernetes.default" , "kubernetes.default.svc" , "kubernetes.default.svc.cluster" , "kubernetes.default.svc.cluster.local" ], "key" : { "algo" : "rsa" , "size" : 2048 }, "names" : [ { "C" : "CN" , "ST" : "BeiJing" , "L" : "BeiJing" , "O" : "k8s" , "OU" : "System" } ] } EOF
如果 hosts 字段不为空则需要指定授权使用该证书的 IP 或域名列表,所以上面分别指定了当前部署的 master 节点主机 IP 以及apiserver 负载的内部域名
还需要添加 kube-apiserver 注册的名为 kubernetes 的服务 IP (Service Cluster IP),一般是 kube-apiserver –service-cluster-ip-range 选项值指定的网段的第一个IP,如 “10.254.0.1”
生成kubernetes 证书和私钥:
1 2 3 4 5 6 7 8 $ cfssl gencert -ca=/etc/ kubernetes/ssl/ ca.pem \ -ca-key=/etc/ kubernetes/ssl/ ca-key.pem \ -config=/etc/ kubernetes/ssl/ ca-config.json \ -profile=kubernetes kubernetes-csr.json | cfssljson -bare kubernetes $ ls kubernetes* kubernetes.csr kubernetes-csr.json kubernetes-key.pem kubernetes.pem $ sudo mkdir -p /etc/ kubernetes/ssl/ $ sudo mv kubernetes*.pem /etc/ kubernetes/ssl/
6.1 配置和启动kube-apiserver 创建kube-apiserver 使用的客户端token 文件 kubelet 首次启动时向kube-apiserver 发送TLS Bootstrapping 请求,kube-apiserver 验证请求中的token 是否与它配置的token.csv 一致,如果一致则自动为kubelet 生成证书和密钥。
1 2 3 4 5 $ # 导入的 environment.sh 文件定义了 BOOTSTRAP_TOKEN 变量 $ cat > token .csv <<EOF ${BOOTSTRAP_TOKEN} ,kubelet-bootstrap ,10001,"system:kubelet-bootstrap" EOF $ sudo mv token .csv /etc/kubernetes/
创建kube-apiserver 的systemd unit文件
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 $ cat > kube-apiserver.service <<EOF [Unit] Description =Kubernetes API ServerDocumentation =https://github.com/GoogleCloudPlatform/kubernetesAfter =network.target[Service] ExecStart =/usr/k8s/bin/kube-apiserver \\ --admission-control =NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota \\ --advertise-address =${NODE_IP} \\ --bind-address =0.0.0.0 \\ --insecure-bind-address =${NODE_IP} \\ --authorization-mode =Node,RBAC \\ --runtime-config =rbac.authorization.k8s.io/v1alpha1 \\ --kubelet-https =true \\ --experimental-bootstrap-token-auth \\ --token-auth-file =/etc/kubernetes/token.csv \\ --service-cluster-ip-range =${SERVICE_CIDR} \\ --service-node-port-range =${NODE_PORT_RANGE} \\ --tls-cert-file =/etc/kubernetes/ssl/kubernetes.pem \\ --tls-private-key-file =/etc/kubernetes/ssl/kubernetes-key.pem \\ --client-ca-file =/etc/kubernetes/ssl/ca.pem \\ --service-account-key-file =/etc/kubernetes/ssl/ca-key.pem \\ --etcd-cafile =/etc/kubernetes/ssl/ca.pem \\ --etcd-certfile =/etc/kubernetes/ssl/kubernetes.pem \\ --etcd-keyfile =/etc/kubernetes/ssl/kubernetes-key.pem \\ --etcd-servers =${ETCD_ENDPOINTS} \\ --enable-swagger-ui =true \\ --allow-privileged =true \\ --apiserver-count =2 \\ --audit-log-maxage =30 \\ --audit-log-maxbackup =3 \\ --audit-log-maxsize =100 \\ --audit-log-path =/var/lib/audit.log \\ --audit-policy-file =/etc/kubernetes/audit-policy.yaml \\ --event-ttl =1h \\ --logtostderr =true \\ --v =6 Restart =on-failureRestartSec =5Type =notifyLimitNOFILE =65536[Install] WantedBy =multi-user.targetEOF
如果你安装的是1.9.x版本的,一定要记住上面的参数experimental-bootstrap-token-auth,需要替换成enable-bootstrap-token-auth,因为这个参数在1.9.x里面已经废弃掉了
kube-apiserver 1.6 版本开始使用 etcd v3 API 和存储格式
–authorization-mode=RBAC 指定在安全端口使用RBAC 授权模式,拒绝未通过授权的请求
kube-scheduler、kube-controller-manager 一般和 kube-apiserver 部署在同一台机器上,它们使用非安全端口和 kube-apiserver通信
kubelet、kube-proxy、kubectl 部署在其它 Node 节点上,如果通过安全端口访问 kube-apiserver,则必须先通过 TLS 证书认证,再通过 RBAC 授权
kube-proxy、kubectl 通过使用证书里指定相关的 User、Group 来达到通过 RBAC 授权的目的
如果使用了 kubelet TLS Boostrap 机制,则不能再指定 –kubelet-certificate-authority、–kubelet-client-certificate 和 –kubelet-client-key 选项,否则后续 kube-apiserver 校验 kubelet 证书时出现 ”x509: certificate signed by unknown authority“ 错误
–admission-control 值必须包含 ServiceAccount,否则部署集群插件时会失败
–bind-address 不能为 127.0.0.1
–service-cluster-ip-range 指定 Service Cluster IP 地址段,该地址段不能路由可达
–service-node-port-range=${NODE_PORT_RANGE} 指定 NodePort 的端口范围
缺省情况下 kubernetes 对象保存在etcd/registry 路径下,可以通过 –etcd-prefix 参数进行调整
kube-apiserver 1.8版本后需要在–authorization-mode参数中添加Node,即:–authorization-mode=Node,RBAC,否则Node 节点无法注册
注意要开启审查日志功能,指定–audit-log-path参数是不够的,这只是指定了日志的路径,还需要指定一个审查日志策略文件:–audit-policy-file,我们也可以使用日志收集工具收集相关的日志进行分析。
审查日志策略文件内容如下:(/etc/kubernetes/audit-policy.yaml)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 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"
审查日志的相关配置可以查看文档了解:https://kubernetes.io/docs/tasks/debug-application-cluster/audit/
启动kube-apiserver
1 2 3 4 5 $ sudo cp kube-apiserver.service /etc/systemd/system /$ sudo systemctl daemon-reload$ sudo systemctl enable kube-apiserver$ sudo systemctl start kube-apiserver$ sudo systemctl status kube-apiserver
6.2 配置和启动kube-controller-manager 创建kube-controller-manager 的systemd unit 文件
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 $ cat > kube-controller-manager.service <<EOF [Unit] Description =Kubernetes Controller ManagerDocumentation =https://github.com/GoogleCloudPlatform/kubernetes[Service] ExecStart =/usr/k8s/bin/kube-controller-manager \\ --address =127.0.0.1 \\ --master =http://${MASTER_URL}:8080 \\ --allocate-node-cidrs =true \\ --service-cluster-ip-range =${SERVICE_CIDR} \\ --cluster-cidr =${CLUSTER_CIDR} \\ --cluster-name =kubernetes \\ --cluster-signing-cert-file =/etc/kubernetes/ssl/ca.pem \\ --cluster-signing-key-file =/etc/kubernetes/ssl/ca-key.pem \\ --service-account-private-key-file =/etc/kubernetes/ssl/ca-key.pem \\ --root-ca-file =/etc/kubernetes/ssl/ca.pem \\ --leader-elect =true \\ --v =2 Restart =on-failureRestartSec =5[Install] WantedBy =multi-user.targetEOF
–address 值必须为 127.0.0.1,因为当前 kube-apiserver 期望 scheduler 和 controller-manager 在同一台机器
–master=http://${MASTER_URL}:8080:使用http(非安全端口)与 kube-apiserver 通信,需要下面的haproxy安装成功后才能去掉8080端口。
–cluster-cidr 指定 Cluster 中 Pod 的 CIDR 范围,该网段在各 Node 间必须路由可达(flanneld保证)
–service-cluster-ip-range 参数指定 Cluster 中 Service 的CIDR范围,该网络在各 Node 间必须路由不可达,必须和 kube-apiserver 中的参数一致
–cluster-signing-* 指定的证书和私钥文件用来签名为 TLS BootStrap 创建的证书和私钥
–root-ca-file 用来对 kube-apiserver 证书进行校验,指定该参数后,才会在Pod 容器的 ServiceAccount 中放置该 CA 证书文件
–leader-elect=true 部署多台机器组成的 master 集群时选举产生一处于工作状态的 kube-controller-manager 进程
启动kube-controller-manager
1 2 3 4 5 $ sudo cp kube-controller-manager.service /etc/systemd/system /$ sudo systemctl daemon-reload$ sudo systemctl enable kube-controller-manager$ sudo systemctl start kube-controller-manager$ sudo systemctl status kube-controller-manager
6.3 配置和启动kube-scheduler 创建kube-scheduler 的systemd unit文件
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 $ cat > kube-scheduler.service <<EOF [Unit] Description =Kubernetes SchedulerDocumentation =https://github.com/GoogleCloudPlatform/kubernetes[Service] ExecStart =/usr/k8s/bin/kube-scheduler \\ --address =127.0.0.1 \\ --master =http://${MASTER_URL}:8080 \\ --leader-elect =true \\ --v =2 Restart =on-failureRestartSec =5[Install] WantedBy =multi-user.targetEOF
–address 值必须为 127.0.0.1,因为当前 kube-apiserver 期望 scheduler 和 controller-manager 在同一台机器
–master=http://${MASTER_URL}:8080:使用http(非安全端口)与 kube-apiserver 通信,需要下面的haproxy启动成功后才能去掉8080端口
–leader-elect=true 部署多台机器组成的 master 集群时选举产生一处于工作状态的 kube-controller-manager 进程
启动kube-scheduler
1 2 3 4 5 $ sudo cp kube-scheduler.service /etc/systemd/system /$ sudo systemctl daemon-reload$ sudo systemctl enable kube-scheduler$ sudo systemctl start kube-scheduler$ sudo systemctl status kube-scheduler
6.4 验证master 节点 1 2 3 4 5 6 7 $ kubectl get componentstatuses NAME STATUS MESSAGE ERROR scheduler Healthy ok controller-manager Healthy ok etcd-1 Healthy {"health" : "true" } etcd-2 Healthy {"health" : "true" } etcd-0 Healthy {"health" : "true" }
接下文:手动搭建高可用的kubernetes集群(三)