通过kubeadm能够快速部署一个Kubernetes集群，但是如果需要精细调整Kubernetes各组件服务的参数及安全设置、高可用模式等，管理员就可以使用Kubernetes二进制文件进行部署。
本节基于Kubernetes 1.19版本，以二进制文件方式对如何配置、部署一个启用了安全机制、3节点高可用的Kubernetes集群进行说明。对于测试环境，可以适当进行简化，将某些组件部署为单点。
在Kubernetes系统中，Master节点扮演着总控中心的角色，通过不间断地与各个工作节点（Node）通信来维护整个集群的健康工作状态，集群中各资源对象的状态则被保存在etcd数据库中。如果Master不能正常工作，各Node就会处于不可管理状态，用户就无法管理在各Node上运行的Pod，其重要性不言而喻。同时，如果Master以不安全方式提供服务（例如通过HTTP的8080端口号），则任何能够访问Master的客户端都可以通过API操作集群中的数据，可能导致对数据的非法访问或篡改。
在正式环境中应确保Master的高可用，并启用安全访问机制，至少包括以下几方面。
◎ Master的kube-apiserver、kube-controller-mansger和kube-scheduler服务至少以3个节点的多实例方式部署。
◎ Master启用基于CA认证的HTTPS安全机制。
◎ etcd至少以3个节点的集群模式部署。
◎ etcd集群启用基于CA认证的HTTPS安全机制。
◎ Master启用RBAC授权模式（详见6.2节的说明）。
Master的高可用部署架构如图2.1所示。
图2.1 Master的高可用部署架构
在Master的3个节点之前，应通过一个负载均衡器提供对客户端的唯一访问入口地址，负载均衡器可以选择硬件或者软件进行搭建。软件负载均衡器可以选择的方案较多，本文以HAProxy搭配Keepalived为例进行说明。主流硬件负载均衡器有F5、A10等，需要额外采购，其负载均衡配置规则与软件负载均衡器的配置类似，本文不再赘述。
本例中3台主机的IP地址分别为192.168.18.3、192.168.18.4、192.168.18.5，负载均衡器使用的VIP为192.168.18.100。
下面分别对etcd、负载均衡器、Master、Node等组件如何进行高可用部署、关键配置、CA证书配置等进行详细说明。
为etcd和Kubernetes服务启用基于CA认证的安全机制，需要CA证书进行配置。如果组织能够提供统一的CA认证中心，则直接使用组织颁发的CA证书即可。如果没有统一的CA认证中心，则可以通过颁发自签名的CA证书来完成安全配置。
etcd和Kubernetes在制作CA证书时，均需要基于CA根证书，本文以为Kubernetes和etcd使用同一套CA根证书为例，对CA证书的制作进行说明。
CA证书的制作可以使用openssl、easyrsa、cfssl等工具完成，本文以openssl为例进行说明。下面是创建CA根证书的命令，包括私钥文件ca.key和证书文件ca.crt：
主要参数如下。
◎ -subj：“/CN”的值为Master主机名或IP地址。
◎ -days：设置证书的有效期。
将生成的ca.key和ca.crt文件保存在/etc/kubernetes/pki目录下。
etcd作为Kubernetes集群的主数据库，在安装Kubernetes各服务之前需要首先安装和启动。
从GitHub官网下载etcd二进制文件，例如etcd-v3.4.13-linux-amd64.tar.gz，如图2.2所示。
图2.2 下载界面
解压缩后得到etcd和etcdctl文件，将它们复制到/usr/bin目录下。
然后将其部署为一个systemd的服务，创建systemd服务配置文件/usr/lib/systemd/system/etcd.service，内容示例如下：
其中，EnvironmentFile指定配置文件的全路径，例如/tc/etcd/etcd.conf，其中的参数以环境变量的格式进行配置。
接下来先对etcd需要的CA证书配置进行说明。对于配置文件/etc/etcd/etcd.conf中的完整配置参数，将在创建完CA证书后统一说明。
先创建一个x509 v3配置文件etcd_ssl.cnf，其中subjectAltName参数（alt_names）包括所有etcd主机的IP地址，例如：
然后使用openssl命令创建etcd的服务端CA证书，包括etcd_server.key和etcd_server.crt文件，将其保存到/etc/etcd/pki目录下：
再创建客户端使用的CA证书，包括etcd_client.key和etcd_client.crt文件，也将其保存到/etc/etcd/pki目录下，后续供kube-apiserver连接etcd时使用：
接下来对3个etcd节点进行配置。etcd节点的配置方式包括启动参数、环境变量、配置文件等，本例使用环境变量方式将其配置到/etc/etcd/etcd.conf文件中，供systemd服务读取。
3个etcd节点将被部署在192.168.18.3、192.168.18.4和192.168.18.5 3台主机上，配置文件/etc/etcd/etcd.conf的内容示例如下：
主要配置参数包括为客户端和集群其他节点配置的各监听URL地址（均为HTTPS URL地址），并配置相应的CA证书参数。
etcd服务相关的参数如下。
◎ ETCD_NAME：etcd节点名称，每个节点都应不同，例如etcd1、etcd2、etcd3。
◎ ETCD_DATA_DIR：etcd数据存储目录，例如/etc/etcd/data/etcd1。
◎ ETCD_LISTEN_CLIENT_URLS和ETCD_ADVERTISE_CLIENT_URLS：为客户端提供的服务监听URL地址，例如https：//192.168.18.3：2379。
◎ ETCD_LISTEN_PEER_URLS和ETCD_INITIAL_ADVERTISE_PEER_URLS：为本集群其他节点提供的服务监听URL地址，例如https：//192.168.18.3：2380。
◎ ETCD_INITIAL_CLUSTER_TOKEN：集群名称，例如etcd-cluster。
◎ ETCD_INITIAL_CLUSTER：集群各节点的endpoint列表，例如"etcd1=https：//192.168.18.3：2380，etcd2=https：//192.168.18.4：2380，etcd3=https：//192.168.18.5：2380"。
◎ ETCD_INITIAL_CLUSTER_STATE：初始集群状态，新建集群时设置为“new”，集群已存在时设置为“existing”。
CA证书相关的配置参数如下。
◎ ETCD_CERT_FILE：etcd服务端CA证书-crt文件全路径，例如/etc/etcd/pki/etcd_server.crt。
◎ ETCD_KEY_FILE：etcd服务端CA证书-key文件全路径，例如/etc/etcd/pki/etcd_server.key。
◎ ETCD_TRUSTED_CA_FILE：CA根证书文件全路径，例如/etc/kubernetes/pki/ca.crt。
◎ ETCD_CLIENT_CERT_AUTH：是否启用客户端证书认证。
◎ ETCD_PEER_CERT_FILE：集群各节点相互认证使用的CA证书-crt文件全路径，例如/etc/etcd/pki/etcd_server.crt。
◎ ETCD_PEER_KEY_FILE：集群各节点相互认证使用的CA证书-key文件全路径，例如/etc/etcd/pki/etcd_server.key。
◎ ETCD_PEER_TRUSTED_CA_FILE：CA根证书文件全路径，例如/etc/kubernetes/pki/ca.crt。
基于systemd的配置，在3台主机上分别启动etcd服务，并设置为开机自启动：
然后用etcdctl客户端命令行工具携带客户端CA证书，运行etcdctl endpoint health命令访问etcd集群，验证集群状态是否正常，命令如下：
结果显示各节点状态均为“healthy”，说明集群正常运行。
至此，一个启用了HTTPS的3节点etcd集群就部署完成了，更多的配置参数请参考etcd官方文档的说明。
首先，从Kubernetes的官方GitHub代码库页面下载各组件的二进制文件，在Releases页面找到需要下载的版本号，单击CHANGELOG链接，跳转到已编译好的Server端二进制（Server Binaries）文件的下载页面进行下载，如图2.3和图2.4所示。
图2.3 GitHub上Kubernetes的下载页面一
图2.4 GitHub上Kubernetes的下载页面二
在压缩包kubernetes.tar.gz内包含了Kubernetes的全部服务二进制文件和容器镜像文件，也可以分别下载Server Binaries和Node Binaries二进制文件。在Server Binaries中包含不同系统架构的服务端可执行文件，例如kubernetes-server-linux-amd64.tar.gz文件包含了x86架构下Kubernetes需要运行的全部服务程序文件；Node Binaries则包含了不同系统架构、不同操作系统的Node需要运行的服务程序文件，包括Linux版和Windows版等。
主要的服务程序二进制文件列表如表2.4所示。
表2.4 主要的服务程序二进制文件列表
在Kubernetes的Master节点上需要部署的服务包括etcd、kube-apiserver、kube-controller-manager和kube-scheduler。
在工作节点（Worker Node）上需要部署的服务包括docker、kubelet和kube-proxy。
将Kubernetes的二进制可执行文件复制到/usr/bin目录下，然后在/usr/lib/systemd/system目录下为各服务创建systemd服务配置文件（完整的systemd系统知识请参考Linux的相关手册），这样就完成了软件的安装。
下面对每个服务的配置进行详细说明。
（1）设置kube-apiserver服务需要的CA相关证书。准备master_ssl.cnf文件用于生成x509 v3版本的证书，示例如下：
在该文件中主要需要在subjectAltName字段（[alt_names]）设置Master服务的全部域名和IP地址，包括：
◎ DNS主机名，例如k8s-1、k8s-2、k8s-3等；
◎ Master Service虚拟服务名称，例如kubernetes.default等；
◎ IP地址，包括各kube-apiserver所在主机的IP地址和负载均衡器的IP地址，例如192.168.18.3、192.168.18.4、192.168.18.5和192.168.18.100；
◎ Master Service虚拟服务的ClusterIP地址，例如169.169.0.1。
然后使用openssl命令创建kube-apiserver的服务端CA证书，包括apiserver.key和apiserver.crt文件，将其保存到/etc/kubernetes/pki目录下：
（2）为kube-apiserver服务创建systemd服务配置文件/usr/lib/systemd/system/kube-apiserver.service，内容如下：
（3）配置文件/etc/kubernetes/apiserver的内容通过环境变量KUBE_API_ARGS设置kube-apiserver的全部启动参数，包含CA安全配置的启动参数示例如下：
对主要参数说明如下。
◎ --secure-port：HTTPS端口号，默认值为6443。
◎ --insecure-port：HTTP端口号，默认值为8080，设置为0表示关闭HTTP访问。
◎ --tls-cert-file：服务端CA证书文件全路径，例如/etc/kubernetes/pki/apiserver.crt。
◎ --tls-private-key-file：服务端CA私钥文件全路径，例如/etc/kubernetes/pki/apiserver.key。
◎ --client-ca-file：CA根证书全路径，例如/etc/kubernetes/pki/ca.crt。
◎ --apiserver-count：API Server实例数量，例如3，需要同时设置参数--endpoint-reconciler-type=master-count。
◎ --etcd-servers：连接etcd的URL列表，这里使用HTTPS，例如https：//192.168.18.3：2379、https：//192.168.18.4：2379和https：//192.168.18.5：2379。
◎ --etcd-cafile：etcd使用的CA根证书文件全路径，例如/etc/kubernetes/pki/ca.crt。
◎ --etcd-certfile：etcd客户端CA证书文件全路径，例如/etc/etcd/pki/etcd_client.crt。
◎ --etcd-keyfile：etcd客户端私钥文件全路径，例如/etc/etcd/pki/etcd_client.key。
◎ --service-cluster-ip-range：Service虚拟IP地址范围，以CIDR格式表示，例如169.169.0.0/16，该IP范围不能与物理机的IP地址有重合。
◎ --service-node-port-range：Service可使用的物理机端口号范围，默认值为30000~32767。
◎ --allow-privileged：是否允许容器以特权模式运行，默认值为true。
◎ --logtostderr：是否将日志输出到stderr，默认值为true，当使用systemd系统时，日志将被输出到journald子系统。设置为false表示不输出到stderr，可以输出到日志文件。
◎ --log-dir：日志的输出目录，例如/var/log/kubernetes。
◎ --v：日志级别。
（4）在配置文件准备完毕后，在3台主机上分别启动kube-apiserver服务，并设置为开机自启动：
kube-controller-manager、kube-scheduler、kubelet和kube-proxy服务作为客户端连接kube-apiserver服务，需要为它们创建客户端CA证书进行访问。这里以对这几个服务统一创建一个证书作为示例。
（1）通过openssl工具创建CA证书和私钥文件，命令如下：
其中，-subj参数中“/CN”的名称可以被设置为“admin”，用于标识连接kube-apiserver的客户端用户的名称。
（2）将生成的client.key和client.crt文件保存在/etc/kubernetes/pki目录下。
本节为kube-controller-manager、kube-scheduler、kubelet和kube-proxy服务统一创建一个kubeconfig文件作为连接kube-apiserver服务的配置文件，后续也作为kubectl命令行工具连接kube-apiserver服务的配置文件。
在Kubeconfig文件中主要设置访问kube-apiserver的URL地址及所需CA证书等的相关参数，示例如下：
其中的关键配置参数如下。
◎ server URL地址：配置为负载均衡器（HAProxy）使用的VIP地址（如192.168.18.100）和HAProxy监听的端口号（如9443）。
◎ client-certificate：配置为客户端证书文件（client.crt）全路径。
◎ client-key：配置为客户端私钥文件（client.key）全路径。
◎ certificate-authority：配置为CA根证书（ca.crt）全路径。
◎ users中的user name和context中的user：连接API Server的用户名，设置为与客户端证书中的“/CN”名称保持一致，例如“admin”。
将kubeconfig文件保存到/etc/kubernetes目录下。
（1）为kube-controller-manager服务创建systemd服务配置文件/usr/lib/systemd/system/kube-controller-manager.service，内容如下：
（2）配置文件/etc/kubernetes/controller-manager的内容为通过环境变量KUBE_CONTROLLER_MANAGER_ARGS设置的kube-controller-manager的全部启动参数，包含CA安全配置的启动参数示例如下：
对主要参数说明如下。
◎ --kubeconfig：与API Server连接的相关配置。
◎ --leader-elect：启用选举机制，在3个节点的环境中应被设置为true。
◎ --service-account-private-key-file：为ServiceAccount自动颁发token使用的私钥文件全路径，例如/etc/kubernetes/pki/apiserver.key。
◎ --root-ca-file：CA根证书全路径，例如/etc/kubernetes/pki/ca.crt。
◎ --service-cluster-ip-range：Service虚拟IP地址范围，以CIDR格式表示，例如169.169.0.0/16，与kube-apiserver服务中的配置保持一致。
（3）配置文件准备完毕后，在3台主机上分别启动kube-controller-manager服务，并设置为开机自启动：
（1）为kube-scheduler服务创建systemd服务配置文件/usr/lib/systemd/system/kube-scheduler.service，内容如下：
（2）配置文件/etc/kubernetes/scheduler的内容为通过环境变量KUBE_SCHEDULER_ARGS设置的kube-scheduler的全部启动参数，示例如下：
对主要参数说明如下。
◎ --kubeconfig：与API Server连接的相关配置。
◎ --leader-elect：启用选举机制，在3个节点的环境中应被设置为true。
（3）在配置文件准备完毕后，在3台主机上分别启动kube-scheduler服务，并设置为开机自启动：
通过systemctl status <service_name>验证服务的启动状态，状态为running并且没有报错日志表示启动成功，例如：
接下来，在3个kube-apiserver服务的前端部署HAProxy和keepalived，使用VIP 192.168.18.100作为Master的唯一入口地址，供客户端访问。
将HAProxy和keepalived均部署为至少有两个实例的高可用架构，以避免单点故障。下面以在192.168.18.3和192.168.18.4两台服务器上部署为例进行说明。HAProxy负责将客户端请求转发到后端的3个kube-apiserver实例上，keepalived负责维护VIP 192.168.18.100的高可用。HAProxy和keepalived的部署架构如图2.5所示。
图2.5 HAProxy和keepalived的部署架构
接下来对部署HAProxy和keepalived组件进行说明。
准备HAProxy的配置文件haproxy.cfg，内容示例如下：
对主要参数说明如下。
◎ frontend：HAProxy的监听协议和端口号，使用TCP，端口号为9443。
◎ backend：后端3个kube-apiserver的地址，以IP：Port方式表示，例如192.168.18.3：6443、192.168.18.4：6443和192.168.18.5：6443；mode字段用于设置协议，此处为tcp；balance字段用于设置负载均衡策略，例如roundrobin为轮询模式。
◎ listen stats：状态监控的服务配置，其中，bind用于设置监听端口号为8888；stats auth用于配置访问账号；stats uri用于配置访问URL路径，例如/stats。
下面以Docker容器方式运行HAProxy且镜像使用haproxytech/haproxy-debian为例进行说明。
在两台服务器192.168.18.3和192.168.18.4上启动HAProxy，将配置文件haproxy.cfg挂载到容器的/usr/local/etc/haproxy目录下，启动命令如下：
在一切正常的情况下，通过浏览器访问http：//192.168.18.3：8888/stats地址即可访问HAProxy的管理页面，登录后查看到的主页界面如图2.6所示。
图2.6 登录后查看到的主页界面
这里主要关注最后一个表格，其内容为haproxy.cfg配置文件中backend配置的3个kube-apiserver地址，它们的状态均为“UP”，表示与3个kube-apiserver服务成功建立连接，说明HAProxy工作正常。
Keepalived用于维护VIP地址的高可用，同样在192.168.18.3和192.168.18.4两台服务器上进行部署。主要需要配置keepalived监控HAProxy的运行状态，当某个HAProxy实例不可用时，自动将VIP地址切换到另一台主机上。下面对keepalived的配置和启动进行说明。
在第1台服务器192.168.18.3上创建配置文件keepalived.conf，内容如下：
主要参数在vrrp_instance段中进行设置，说明如下。
◎ vrrp_instance VI_1：设置keepalived虚拟路由器VRRP的名称。
◎ state：设置为“MASTER”，将其他keepalived均设置为“BACKUP”。
◎ interface：待设置VIP地址的网卡名称。
◎ virtual_router_id：例如51。
◎ priority：优先级，例如100。
◎ virtual_ipaddress：VIP地址，例如192.168.18.100/24。
◎ authentication：访问keepalived服务的鉴权信息。
◎ track_script：HAProxy健康检查脚本。
Keepalived需要持续监控HAProxy的运行状态，在某个HAProxy实例运行不正常时，自动切换到运行正常的HAProxy实例上。需要创建一个HAProxy健康检查脚本，定期运行该脚本进行监控，例如新建脚本check-haproxy.sh并将其保存到/usr/bin目录下，内容示例如下：
若检查成功，则应返回0；若检查失败，则返回非0值。Keepalived根据上面的配置，会每隔2s检查一次HAProxy的运行状态。例如，如果在192.168.18.3 上检查失败，keepalived就会将VIP地址切换到正常运行HAProxy的192.168.18.4服务器上，保证VIP 192.168.18.100地址的高可用。
在第2台服务器192.168.18.4上创建配置文件keepalived.conf，内容示例如下：
这里与第1个keepalived配置的主要差异如下。
◎ vrrp_instance中的state被设置为“BACKUP”，这是因为在整个keepalived集群中只能有一个被设置为“MASTER”。如果keepalived集群不止2个实例，那么除了MASTER，其他都应被设置为“BACKUP”。
◎ vrrp_instance的值“VI_1”需要与MASTER的配置相同，表示它们属于同一个虚拟路由器组（VRRP），当MASTER不可用时，同组的其他BACKUP实例会自动选举出一个新的MASTER。
◎ HAProxy健康检查脚本check-haproxy.sh与第1个keepalived的相同。
下面以Docker容器方式运行HAProxy且镜像使用osixia/keepalived为例进行说明。在两台服务器192.168.18.3和192.168.18.4上启动HAProxy，将配置文件keepalived.conf挂载到容器的/container/service/keepalived/assets目录下，启动命令如下：
在运行正常的情况下，keepalived会在服务器192.168.18.3的网卡ens33上设置192.168.18.100的IP地址，同样在服务器192.168.18.3上运行的HAProxy将在该IP地址上监听9443端口号，对需要访问Kubernetes Master的客户端提供负载均衡器的入口地址，即192.168.18.100：9443。
通过ip addr命令查看服务器192.168.18.3的IP地址信息，可以看到在ens33网卡上新增了192.168.18.100地址：
使用curl命令即可验证通过HAProxy的192.168.18.100：9443地址是否可以访问到kube-apiserver服务：
可以看到TCP/IP连接创建成功，得到响应码为401的应答，说明通过VIP地址192.168.18.100成功访问到了后端的kube-apiserver服务。至此，Master上所需的3个服务就全部启动完成了。接下来就可以部署Node的服务了。
在Node上需要部署Docker、kubelet、kube-proxy，在成功加入Kubernetes集群后，还需要部署CNI网络插件、DNS插件等管理组件。Docker的安装和启动详见Docker官网的说明文档。本节主要对如何部署kubelet和kube-proxy进行说明。CNI网络插件的安装部署详见7.7节的说明，DNS插件的安装部署详见4.3节的说明。
本节以将192.168.18.3、192.168.18.4和192.168.18.5三台主机部署为Node为例进行说明，由于这三台主机都是Master节点，所以最终部署结果为一个包含三个Node节点的Kubernetes集群。
（1）为kubelet服务创建systemd服务配置文件/usr/lib/systemd/system/kubelet.service，内容如下：
（2）配置文件/etc/kubernetes/kubelet的内容为通过环境变量KUBELET_ARGS设置的kubelet的全部启动参数，示例如下：
对主要参数说明如下。
◎ --kubeconfig：设置与API Server连接的相关配置，可以与kube-controller-manager使用的kubeconfig文件相同。需要将相关客户端证书文件从Master主机复制到Node主机的/etc/kubernetes/pki目录下，例如ca.crt、client.key、client.crt文件。
◎ --config：kubelet配置文件，从Kubernetes 1.10版本开始引入，设置可以让多个Node共享的配置参数，例如address、port、cgroupDriver、clusterDNS、clusterDomain等。关于kubelet.config文件中可以设置的参数内容和详细说明，请参见官方文档的说明。
◎ --hostname-override：设置本Node在集群中的名称，默认值为主机名，应将各Node设置为本机IP或域名。
◎ --network-plugin：网络插件类型，建议使用CNI网络插件。
配置文件kubelet.config的内容示例如下：
在本例中设置的kubelet参数如下。
◎ address：服务监听IP地址。
◎ port：服务监听端口号，默认值为10250。
◎ cgroupDriver：设置为cgroupDriver驱动，默认值为cgroupfs，可选项包括systemd。
◎ clusterDNS：集群DNS服务的IP地址，例如169.169.0.100。
◎ clusterDomain：服务DNS域名后缀，例如cluster.local。
◎ authentication：设置是否允许匿名访问或者是否使用webhook进行鉴权。
（3）在配置文件准备完毕后，在各Node主机上启动kubelet服务并设置为开机自启动：
（1）为kube-proxy服务创建systemd服务配置文件/usr/lib/systemd/system/kube-proxy.service，内容如下：
（2）配置文件/etc/kubernetes/proxy的内容为通过环境变量KUBE_PROXY_ARGS设置的kube-proxy的全部启动参数，示例如下：
对主要参数说明如下。
◎ --kubeconfig：设置与API Server连接的相关配置，可以与kubelet使用的kubeconfig文件相同。相关客户端CA证书使用部署kubelet服务时从Master主机复制到Node主机的/etc/kubernetes/pki目录下的文件，包括ca.crt、client.key和client.crt。
◎ --hostname-override：设置本Node在集群中的名称，默认值为主机名，各Node应被设置为本机IP或域名。
◎ --proxy-mode：代理模式，包括iptables、ipvs、kernelspace（Windows节点使用）等。
（3）在配置文件准备完毕后，在各Node主机上启动kube-proxy服务，并设置为开机自启动：
在各个Node的kubelet和kube-proxy服务正常启动之后，会将本Node自动注册到Master上，然后就可以到Master主机上通过kubectl查询自动注册到Kubernetes集群的Node的信息了。
由于Master开启了HTTPS认证，所以kubectl也需要使用客户端CA证书连接Master，可以直接使用kube-controller-manager的kubeconfig文件，命令如下：
我们可以看到各Node的状态为“NotReady”，这是因为还没有部署CNI网络插件，无法设置容器网络。
类似于通过kubeadm创建Kubernetes集群，例如选择Calico CNI插件运行下面的命令一键完成CNI网络插件的部署：
在CNI网络插件成功运行之后，Node的状态会更新为“Ready”：
为了使Kubernetes集群正常工作，我们还需要部署DNS服务，建议使用CoreDNS进行部署，请参见4.3节的说明。
至此，一个有三个Master节点的高可用Kubernetes集群就部署完成了，接下来用户就可以创建Pod、Deployment、Service等资源对象来部署、管理容器应用和微服务了。
本节对Kubernetes各服务启动进程的关键配置参数进行了简要说明，实际上Kubernetes的每个服务都提供了许多可配置的参数。这些参数涉及安全性、性能优化及功能扩展等方方面面。全面理解和掌握这些参数的含义和配置，对Kubernetes的生产部署及日常运维都有很大帮助。对各服务配置参数的详细说明参见附录A。
Kubernetes除了提供了基于CA证书的认证方式，也提供了基于HTTP Token的简单认证方式。各客户端组件与API Server之间的通信方式仍然采用HTTPS，但不采用CA数字证书。这种认证机制与CA证书相比，安全性很低，在生产环境不建议使用。
采用基于HTTP Token的简单认证方式时，API Server对外暴露HTTPS端口，客户端携带Token来完成认证过程。需要说明的是，kubectl命令行工具比较特殊，它同时支持CA证书和简单认证两种方式与API Server通信，其他客户端组件只能配置基于CA证书的认证方式或者非安全方式与API Server通信。
基于Token认证的配置过程如下。
（1）创建包括用户名、密码和UID的文件token_auth_file，将其放置在合适的目录下，例如/etc/kuberntes目录。需要注意的是，这是一个纯文本文件，用户名、密码都是明文。
（2）设置kube-apiserver的启动参数“--token-auth-file”，使用上述文件提供安全认证，然后重启API Server服务。
（3）用curl客户端工具通过token访问API Server：
