2.2使用kubeadm工具快速安装Kubernetes集群最简单的方法是使用yuminstallkubernetes命令安装Kubernetes集群，但仍需修改各组件的启动参数，才能完成对Kubernetes集群的配置，整个过程比较复杂，也容易出错。Kubernetes从1.4版本开始引入了命令行工具kubeadm，致力于简化集群的安装过程，并解决Kubernetes集群的高可用问题。在Kubernetes1.13版本中，kubeadm工具进入GA阶段，宣称已经为生产环境应用准备就绪。本节先讲解基于kubeadm的安装过程（以CentOS7为例）。
（3）执行kubeadmjoin命令，将本Node加入集群：#kubeadmjoin--config=join-config.yamlkubeadm在Master上也安装了kubelet，在默认情况下并不参与工作负载。如果希望安装一个单机All-In-One的Kubernetes环境，则可以执行下面的命令（删除Node的Label“node-role.kubernetes.io/master”），让Master成为一个Node：#kubectltaintnodes--allnode-role.kubernetes.io/master-
3.设置kube-scheduler启动参数kube-scheduler复用上一步kube-controller-manager创建的客户端证书，配置启动参数：--kubeconfig=/etc/kubernetes/kubeconfig重启kube-scheduler服务。
5.设置kube-proxy的启动参数kube-proxy复用上一步kubelet创建的客户端证书，配置启动参数：--kubeconfig=/etc/kubernetes/kubeconfig重启kube-proxy服务。至此，一个基于CA的双向数字证书认证的Kubernetes集群环境就搭建完成了。
2.4.2基于HTTPBase或Token的简单认证方式除了提供了基于CA的双向数字证书认证方式，Kubernetes也提供了基于HTTPBase或Token的简单认证方式。各组件与APIServer之间的通信方式仍然采用HTTPS，但不使用CA数字证书。采用基于HTTPBase或Token的简单认证方式时，APIServer对外暴露HTTPS端口，客户端提供用户名、密码或Token来完成认证过程。需要说明的是，kubectl命令行工具比较特殊，它同时支持CA双向认证和简单认证两种模式与APIServer通信，其他客户端组件只能配置为双向安全认证或非安全模式与APIServer通信。
2.5Kubernetes集群的网络配置在多个Node组成的Kubernetes集群内，跨主机的容器间网络互通是Kubernetes集群能够正常工作的前提条件。Kubernetes本身并不会对跨主机的容器网络进行设置，这需要额外的工具来实现。除了谷歌公有云GCE平台提供的网络设置，一些开源的工具包括Flannel、OpenvSwitch、Weave、Calico等都能够实现跨主机的容器间网络互通。随着CNI网络模型的逐渐成熟，Kubernetes将优先使用CNI网络插件打通跨主机的容器网络。具体的网络原理及主流开源网络工具的原理和配置详见第7章的说明。
2.6.2kubelet配置由于在Kubernetes中是以Pod而不是以Docker容器为管理单元的，在kubelet创建Pod时，还通过启动一个名为k8s.gcr.io/pause:3.1的镜像来实现Pod的概念。该镜像存在于谷歌镜像库k8s.gcr.io中，需要通过一台能够连上Internet的服务器将其下载，导出文件，再push到私有DockerRegistry中。之后，可以给每个Node的kubelet服务都加上启动参数--pod-infra-container-image，指定为私有DockerRegistry中pause镜像的地址。例如：#cat/etc/kubernetes/kubeletkubelet_args="--kubeconfig=/etc/kubernetes/kubeconfig--hostname-override=192.168.18.3--log-dir=/var/log/kubernets--v=0--pod-infra-container-image=myregistry/pause:3.1"然后重启kubelet服务：#systemctlrestartkubelet通过以上设置就在内网环境中搭建了一个企业内部的私有容器云平台。
2.7Kubernetes的版本升级2.7.1二进制升级Kubernetes的版本升级需要考虑到不要让当前集群中正在运行的容器受到影响。应对集群中的各Node逐个进行隔离，然后等待在其上运行的容器全部执行完成，再更新该Node上的kubelet和kube-proxy服务，将全部Node都更新完成后，再更新Master的服务。通过官网获取最新版本的二进制包kubernetes.tar.gz，解压后提取服务的二进制文件。逐个隔离Node，等待在其上运行的全部容器工作完成后，更新kubelet和kube-proxy服务文件，然后重启这两个服务。更新Master的kube-apiserver、kube-controller-manager、kube-scheduler服务文件并重启。
2.8Kubernetes核心服务配置详解2.1节对Kubernetes各服务启动进程的关键配置参数进行了简要说明，实际上Kubernetes的每个服务都提供了许多可配置的参数。这些参数涉及安全性、性能优化及功能扩展（Plugin）等方方面面。全面理解和掌握这些参数的含义和配置，对Kubernetes的生产部署及日常运维都有很大的帮助。每个服务的可用参数都可以通过运行“cmd--help”命令进行查看，其中cmd为具体的服务启动命令，例如kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy等。另外，可以通过在命令的配置文件（例如/etc/kubernetes/kubelet等）中添加“--参数名=参数取值”语句来完成对某个参数的配置。本节将对Kubernetes所有服务的参数进行全面介绍，为了方便学习和查阅，对每个服务的参数都用一个小节进行详细说明。
2.8.1公共配置参数公共配置参数适用于所有服务，如表2.3所示的参数可用于kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy。本节对这些参数进行统一说明，不再在每个服务的参数列表中列出。表2.3公共配置参数表
2.8.2kube-apiserver启动参数对kube-apiserver启动参数的详细说明如表2.4所示。表2.4对kube-apiserver启动参数的详细说明
2.8.3kube-controller-manager启动参数对kube-controller-manager启动参数的详细说明如表2.5所示。表2.5对kube-controller-manager启动参数的详细说明
2.8.4kube-scheduler启动参数对kube-scheduler启动参数的详细说明如表2.6所示。表2.6对kube-scheduler启动参数的详细说明
2.8.5kubelet启动参数对kubelet启动参数的详细说明如表2.7所示。表2.7对kubelet启动参数的详细说明
2.8.6kube-proxy启动参数对kube-proxy启动参数的详细说明见表2.8。表2.8对kube-proxy启动参数的详细说明
2.9CRI（容器运行时接口）详解归根结底，KubernetesNode（kubelet）的主要功能就是启动和停止容器的组件，我们称之为容器运行时（ContainerRuntime），其中最知名的就是Docker了。为了更具扩展性，Kubernetes从1.5版本开始就加入了容器运行时插件API，即ContainerRuntimeInterface，简称CRI。
2.9.1CRI概述每个容器运行时都有特点，因此不少用户希望Kubernetes能够支持更多的容器运行时。Kubernetes从1.5版本开始引入了CRI接口规范，通过插件接口模式，Kubernetes无须重新编译就可以使用更多的容器运行时。CRI包含ProtocolBuffers、gRPCAPI、运行库支持及开发中的标准规范和工具。Docker的CRI实现在Kubernetes1.6中被更新为Beta版本，并在kubelet启动时默认启动。可替代的容器运行时支持是Kubernetes中的新概念。在Kubernetes1.3发布时，rktnetes项目同时发布，让rkt容器引擎成为除Docker外的又一选择。然而，不管是Docker还是rkt，都用到了kubelet的内部接口，同kubelet源码纠缠不清。这种程度的集成需要对kubelet的内部机制有非常深入的了解，还会给社区带来管理压力，这就给新生代容器运行时造成了难于跨越的集成壁垒。CRI接口规范试图用定义清晰的抽象层清除这一壁垒，让开发者能够专注于容器运行时本身。在通向插件式容器支持及建设健康生态环境的路上，这是一小步，也是很重要的一步。
2.9.2CRI的主要组件kubelet使用gRPC框架通过UNIXSocket与容器运行时（或CRI代理）进行通信。在这个过程中kubelet是客户端，CRI代理（shim）是服务端，如图2.3所示。ProtocolBuffersAPI包含两个gRPC服务：ImageService和RuntimeService。ImageService提供了从仓库拉取镜像、查看和移除镜像的功能。RuntimeService负责Pod和容器的生命周期管理，以及与容器的交互（exec/attach/port-forward）。rkt和Docker这样的容器运行时可以使用一个Socket同时提供两个服务，在kubelet中可以用--container-runtime-endpoint和--image-service-endpoint参数设置这个Socket。
2.9.3Pod和容器的生命周期管理Pod由一组应用容器组成，其中包含共有的环境和资源约束。在CRI里，这个环境被称为PodSandbox。Kubernetes有意为容器运行时留下一些发挥空间，它们可以根据自己的内部实现来解释PodSandbox。对于Hypervisor类的运行时，PodSandbox会具体化为一个虚拟机。其他例如Docker，会是一个Linux命名空间。在v1alpha1API中，kubelet会创建Pod级别的cgroup传递给容器运行时，并以此运行所有进程来满足PodSandbox对Pod的资源保障。在启动Pod之前，kubelet调用RuntimeService.RunPodSandbox来创建环境。这一过程包括为Pod设置网络资源（分配IP等操作）。PodSandbox被激活之后，就可以独立地创建、启动、停止和删除不同的容器了。kubelet会在停止和删除PodSandbox之前首先停止和删除其中的容器。kubelet的职责在于通过RPC管理容器的生命周期，实现容器生命周期的钩子，存活和健康监测，以及执行Pod的重启策略等。RuntimeService服务包括对Sandbox和Container操作的方法，下面的伪代码展示了主要的RPC方法。
2.9.5尝试使用新的Docker-CRI来创建容器要尝试新的Kubelet-CRI-Docker集成，只需为kubelet启动参数加上--enable-cri=true开关来启动CRI。这个选项从Kubernetes1.6开始已经作为kubelet的默认选项了。如果不希望使用CRI，则可以设置--enable-cri=false来关闭这个功能。查看kubelet的日志，可以看到启用CRI和创建gRPCServer的日志。创建一个Deployment：#kubectlrunnginx--image=nginx查看Pod的详细信息，可以看到将会创建沙箱（Sandbox）的Event：#kubectldescribepodnginx这表明kubelet使用了CRI接口来创建容器。
2.10kubectl命令行工具用法详解kubectl作为客户端CLI工具，可以让用户通过命令行对Kubernetes集群进行操作。本节对kubectl的子命令和用法进行详细说明。
2.10.2kubectl子命令详解kubectl的子命令非常丰富，涵盖了对Kubernetes集群的主要操作，包括资源对象的创建、删除、查看、修改、配置、运行等。详细的子命令如表2.10所示。表2.10kubectl子命令详解
2.10.3kubectl参数列表kubectl命令行的公共启动参数如表2.11所示。表2.11kubectl命令行的公共启动参数每个子命令（如create、delete、get等）还有特定的flags参数，可以通过$kubectl[command]--help命令进行查看。
2.10.4kubectl输出格式kubectl命令可以用多种格式对结果进行显示，输出的格式通过-o参数指定：#kubectl[command][TYPE][NAME]-o=
2.10.5kubectl操作示例本节将一些常用的kubectl操作作为示例进行说明。1.创建资源对象根据YAML配置文件一次性创建Service和RC：#kubectlcreate-fmy-service.yaml-fmy-rc.yaml根据
2.查看资源对象查看所有Pod列表：#kubectlgetpods查看RC和Service列表：#kubectlgetrc,service
3.描述资源对象显示Node的详细信息：#kubectldescribenodes
4.删除资源对象基于pod.yaml定义的名称删除Pod：#kubectldelete-fpod.yaml删除所有包含某个Label的Pod和Service：#kubectldeletepods,services-lname=
6.查看容器的日志查看容器输出到stdout的日志：#kubectllogs
7.创建或更新资源对象用法和kubectlcreate类似，逻辑稍有差异：如果目标资源对象不存在，则进行创建；否则进行更新。例如：#kubectlapply-fapp.yaml
8.在线编辑运行中的资源对象可以使用kubectledit命令编辑运行中的资源对象，例如使用下面的命令编辑运行中的一个Deployment：#kubectleditdeploynginx在命令执行之后，会通过YAML格式展示该对象的定义和状态，用户可以对代码进行编辑和保存，从而完成对在线资源的直接修改。
10.在Pod和本地之间复制文件把Pod上的/etc/fstab复制到本地的/tmp目录：#kubectlcpnginx-6ddbbc47fb-sfdcv:/etc/fstab/tmp
11.资源对象的标签设置为defaultnamespace设置testing=true标签：#kubectllabelnamespacesdefaulttesting=true
12.检查可用的API资源类型列表该命令经常用于检查特定类型的资源是否已经定义，列出所有资源对象类型：#kubectlapi-resources