吴声子夜歌的博客

接下来，需要为这两个工作组分别定义一个Context，即运行环境。这个运行环境将属于某个特定的命名空间。128:8080clusters:- cluster:contexts:- context:- context:users: []注意，通过kubectl config命令在${HOME}/.kube目录下生成了一个名为config的文件，文件的内容为以kubectlconfig view命令查看到的内容。所以，也可以通过手工编辑该文件的方式来设置Context。

与其他资源对象一样，对CRD的定义也使用YAML配置进行声明。metadata:labels:spec:names:- istio-ioversions:schema:x-kubernetes-preserve-unknown-fields: true # 允许 Istio 复杂的动态结构，避免 v1 严格的结构校验报错schema:- name: v1schema:CRD定义中的关键字段如下。（1）group。

由于Fabric8框架对Kubernetes API对象做了很好的封装，对其中的大量对象都做了定义，所以用户可以通过其提供的资源对象去定义Kubernetes API对象，例如上面例子中的Namespace对象。在本例中选用的Jersey框架的版本为1.19，所涉及的Jar包如图所示。下面的例子代码用于获取Pod资源列表，其中，第1部分代码用于获取所有的Pod资源对象，第2、3部分代码主要用于说明如何使用标签选择Pod资源对象，最后一部分代码用于举例说明如何使用field选择Pod资源对象。

Kubernetes API是集群系统中的重要组成部分，Kubernetes中各种资源（对象）的数据都通过该API接口被提交到后端的持久化存储（etcd）中，Kubernetes集群中的各部件之间通过该API接口实现解耦合，同时Kubernetes集群中一个重要且便捷的管理工具kubectl也是通过访问该API接口实现其强大的管理功能的。Kubernetes API中的资源对象都拥有通用的元数据，资源对象也可能存在嵌套现象，比如在一个Pod里面嵌套多个Container。

准备工作已经就绪，集群管理员现在可以在Kubernetes集群中定义一个StorageClass了。metadata:name: gluster-heketi # StorageClass 的名称provisioner: kubernetes.io/glusterfs # 动态卷供应商，指定使用 GlusterFS 插件resturl: "http://172.17.2.2:8080" # Heketi REST API 的服务地址（无需认证的内网或测试环境地址）

Kubernetes对于有状态的容器应用或者对数据需要持久化的应用，不仅需要将容器内的目录挂载到宿主机的目录或者emptyDir临时存储卷，而且需要更加可靠的存储来保存应用产生的重要数据，以便容器应用在重建之后仍然可以使用之前的数据。不过，存储资源和计算资源（CPU/内存）的管理方式完全不同。

Calico是一个基于BGP的纯三层的网络方案，与OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成。Calico在每个计算节点都利用Linux Kernel实现了一个高效的vRouter来负责数据转发。每个vRouter都通过BGP1协议把在本节点上运行的容器的路由信息向整个Calico网络广播，并自动设置到达其他节点的路由转发规则。Calico保证所有容器之间的数据流量都是通过IP路由的方式完成互联互通的。

CNI提供了一种应用容器的插件化网络解决方案，定义对容器网络进行操作和配置的规范，通过插件的形式对CNI接口进行实现。CNI是由rkt Networking Proposal发展而来的，试图提供一种普适的容器网络解决方案。CNI仅关注在创建容器时分配网络资源，和在销毁容器时删除网络资源，这使得CNI规范非常轻巧、易于实现，得到了广泛的支持。在CNI模型中只涉及两个概念：容器和网络。- 容器（Container）​：是拥有独立Linux网络命名空间的环境，例如使用Docker或rkt创建的容器。

在我们的例子中，容器就是图7.8中的容器1和容器2。有趣的结果是，在查看完每个容器的网络模型后，我们可以看到这样的配置：我们检查的第1个容器是运行了“google_containers/pause:latest”镜像的容器，它使用了Docker默认的网络模型bridge；针对由Docker创建的每一个容器，都会创建一个虚拟的以太网设备（Veth设备对）​，其中一端关联到网桥上，另一端使用Linux的网络命名空间技术，映射到容器内的eth0设备，然后从网桥的地址段内给eth0接口分配一个IP地址。

这种关系和同一个VM内的进程之间的关系是一样的，看起来 Pod内容器之间的隔离性减小了，而且Pod内不同容器之间的端口是共享的，就没有所谓的私有端口的概念了。网桥能够解析收发的报文，读取目标MAC地址的信息，和自己记录的MAC表结合，来决策报文的转发目标网络接口。运行着Linux内核的机器本身就是一台主机，有可能是网络报文的目的地，其收到的报文除了转发和丢弃，还可能被送到网络协议栈的上层（网络层）​，从而被自己（这台主机本身的协议栈）消化，所以我们既可以把网桥看作一个二层设备，也可以把它看作一个三层设备。

为了使用更新后的Secret，必须删除旧Pod，并重新创建一个新Pod。在使用Mount方式挂载Secret时，Container中Secret的data域的各个域的Key值作为目录中的文件，Value值被BASE64编码后存储在相应的文件中。Pod和容器的安全策略可以在Pod或Container的securityContext字段中进行设置，如果在Pod和Container级别都设置了相同的安全类型字段，容器将使用Container级别的设置。

联想到Mountable secrets的标记，以及之前看到的Pod中的三个文件的文件名，我们恍然大悟：在每个Namespace下都有一个名为default的默认ServiceAccount对象，在这个Service Account里面有一个名为Tokens的可以当作Volume被挂载到Pod里的Secret，当Pod启动时，这个Secret会自动被挂载到Pod的指定目录下，用来协助完成Pod中的进程访问API Server时的身份鉴权。在继续学习之前，请回忆6.1节API Server认证的内容。

API Server在接收到请求后，会读取该请求中的数据，生成一个访问策略对象，如果在该请求中不带某些属性（如Namespace）​，则这些属性的值将根据属性类型的不同，设置不同的默认值（例如，为字符串类型的属性设置一个空字符串；通常可以对/api、/api/*、/apis、/apis/*和/version对于客户端发现服务器提供的资源和版本信息给予“允许”授权，对于其他非资源的访问一般可以禁止，以限制客户端对API Server进行没有必要的查询。简单地说，授权就是授予不同的用户不同的访问权限。

综上所述，由于kube-proxy的作用，在Service的调用过程中客户端无须关心后端有几个Pod，中间过程的通信、负载均衡及故障恢复都是透明的。iptables模式虽然实现起来简单，但存在无法避免的缺陷：在集群中的Service和Pod大量增加以后，iptables中的规则会急速膨胀，导致性能显著下降，在某些极端情况下甚至会出现规则丢失的情况，并且这种故障难以重现与排查，于是Kubernetes从1.8版本开始引入第3代的IPVS（IP Virtual Server）模式，如图所示。

cAdvisor是一个开源的分析容器资源使用率和性能特性的代理工具，它是因为容器而产生的，因此自然支持Docker容器，在Kubernetes项目中，cAdvisor被集成到Kubernetes代码中，kubelet则通过cAdvisor获取其所在节点及容器的数据。如果发现本地的Pod被修改，则kubelet会做出相应的修改，比如在删除Pod中的某个容器时，会通过DockerClient删除该容器。如果发现删除本节点的Pod，则删除相应的Pod，并通过Docker Client删除Pod中的容器。

具体来说，Kubernetes Scheduler的作用是将待调度的Pod（API新创建的Pod、Controller Manager为补足副本 而创建的Pod等）按照特定的调度算法和调度策略绑定（Binding）到集群中某个合适的Node上，并将绑定信息写入etcd中。前面深入分析了Controller Manager及它所包含的各个组件的运行机制，本节将继续对Kubernetes中负责Pod调度的重要功能模块—Kubernetes Scheduler的工作原理和运行机制做深入分析。完整的流程如图所示。

它负责监听Service和对应的Pod副本的变化，如果监测到Service被删除，则删除和该Service同名的Endpoints对象。作为完备的企业级的容器集群管理平台，Kubernetes也提供了ResourceQuota Controller（资源配额管理）这一 高级功能，资源配额管理确保了指定的资源对象在任何时候都不会超量占用系统物理资源，避免了由于某些业务进程的设计或实现的缺陷导致整个系统运行紊乱甚至意外宕机，对整个集群的平稳运行和稳定性有非常重要的作用。在后面的章节中会深入讲解这部分内容。

Kubernetes API Server通过一个名为kube-apiserver的进程提供服务，该进程运行在Master上。在默认情况下，kube-apiserver进程在本机的8080端口（对应参数–insecure-port）提供REST服务。我们可以同时启动HTTPS安全端口（–secure-port=6443）来启动安全机制，加强REST API访问的安全性。我们通常可以通过命令行工具kubectl来与KubernetesAPI Server交互，它们之间的接口是RESTful API。

由于Pod和Service都是Kubernetes集群范围内的虚拟概念，所以集群外的客户端系统无法通过Pod的IP地址或者Service的虚拟IP地址和虚拟端口号访问它们。为了让外部客户端可以访问这些服务，可以将Pod或Service的端口号映射到宿主机，以使客户端应用能够通过物理机访问容器应用。通过kubectl create命令创建这个Pod：通过物理机的IP地址和8081端口号访问Pod内的容器服务：（2）通过设置Pod级别的hostNetwork=true，该Pod中所有容器的端口号都将被直

apiVersion: v1 # 必填项kind: Service # 必填项metadata: # 必填项name: string # 必填项：Service 名称namespace: string # 命名空间labels: # 标签：必须是 key: value 键值对格式annotations: # 注解：必须是 key: value 键值对格式spec: # 必填项selector: # 标签选择器：必须是 key: value 键值对格式。

进入某个实例查看mongo集群的状态，mongo-0发生故障前在集群中的角色为PRIMARY，在其脱离集群后，mongo集群会自动选出一个SECONDARY节点提升为PRIMARY节点（本例中为mongo-2）​。同时，系统也为mongo-3分配了一个新的PVC用于保存数据，此处不再赘述，有兴趣的读者可自行查看系统为mongo-3绑定的Volume设置和后端GlusterFS共享存储的资源分配情况。至此，一个由3个实例组成的MongoDB集群就创建完成了，其中每个实例都拥有稳定的名称和独立的存储空间。

下面通过一个完整的示例，对如何搭建和使用基于自定义指标的HPA体系进行说明。基于自定义指标进行自动扩缩容时，需要预先部署自定义Metrics Server，目前可以使用基于Prometheus、Microsoft Azure、Datadog Cluster等系统的Adapter实现自定义Metrics Server，未来还将提供基于GoogleStackdriver的实现自定义Metrics Server。

例如，假设我们创建一个Deployment，这个Deployment开始创建5个Nginx:1.7.9的Pod副本，在这个创建Pod动作尚未完成时，我们又将Deployment进行更新，在副本数不变的情况下将Pod模板中的镜像修改为Nginx:1.9.1，又假设此时Deployment已经创建了3个Nginx:1.7.9的Pod副本，则Deployment会立即杀掉已创建的3个Nginx:1.7.9 Pod，并开始创建Nginx:1.9.1 Pod。关于Deployment标签选择器的更新的注意事项如下。

Kubernetes 1.3引入了一个Alpha版本的新特性initcontainer（初始化容器，在Kubernetes 1.5时被更新为 Beta版本）​，用于在启动应用容器（app container）之前启动一个或多个初始化容器，完成应用容器所需的预置条件，如图所示。init container与应用容器在本质上是一样的，但它们是仅运行一次就结束的任务，并且必须在成功执行完成后，系统才能继续执行下一个容器。在Pod重新启动时，init container将会重新运行，常见的Pod重启场景如下。

如果Kubernetes调度器的众多特性还无法满足我们的独特调度需求，则还可以用自己开发的调度器进行调度。从1.6版本开始，Kubernetes的多调度器特性也进入了快速发展阶段。一般情况下，每个新Pod都会由默认的调度器进行调度。但是如果在Pod中提供了自定义的调度器名称，那么默认的调度器会忽略该Pod，转由指定的调度器完成Pod的调度。

前面提到的NoExecute这个Taint效果对节点上正在运行的Pod有以下影响。

在最早的Kubernetes版本里是没有这么多Pod副本控制器的，只有一个Pod副本控制器RC（ReplicationController）​，这个控制器是这样设计实现的：RC独立于所控制的Pod，并通过Label标签这个松耦合关联关系控制目标Pod实例的创建和销毁，随着Kubernetes的发展，RC也出现了新的继任者—Deployment，用于更加自动地完成Pod副本的部署、版本更新、回滚等功能。这里X指的是一个集群中的节点、机架、区域等概念，通过Kubernetes内置节点标签中的key来进行声明。

在某些集群中，集群中的每个节点都需要将自身的标识（ID）及进程绑定的IP地址等信息事先写入配置文件中，进程在启动时会读取这些信息，然后将这些信息发布到某个类似服务注册中心的地方，以实现集群节点的自动发现功能。我们知道，每个Pod在被成功创建出来之后，都会被系统分配唯一的名字、IP地址，并且处于某个Namespace中，那么我们如何在Pod的容器内获取Pod的这些重要信息呢？Pod在整个生命周期中被系统定义为各种状态，熟悉Pod的各种状态对于理解如何设置Pod的调度策略、重启策略是很有必要的。

ConfigMap供容器使用的典型用法如下。（1）生成为容器内的环境变量。（2）设置容器启动命令的启动参数（需设置为环境变量）​。（3）以Volume的形式挂载为容器内部的文件或目录。ConfigMap以一个或多个key:value的形式保存在Kubernetes系统中供应用使用，既可以用于表示一个变量的值（例如apploglevel=info）​，也可以用于表示一个完整配置文件的内容（例如xml...>...

apiVersion: v1 # 版本号kind: Pod # 类型固定为Podmetadata: # 元数据name: string # 名称namespace: string # 命名空间，默认为defaultlabels: # 自定义标签列表annotations: # 自定义注解列表spec: # Pod中容器的详细定义containers: # Pod中的容器列表- name: string 容器名称image: string # 容器的镜像名称。

其中，command、TYPE、NAME、flags的含义如下。command：子命令，用于操作Kubernetes集群资源对象的命令，例如create、delete、describe、get、apply等。TYPE：资源对象的类型，区分大小写，能以单数、复数或者简写形式表示。例如以下3种TYPE是等价的。NAME：资源对象的名称，区分大小写。如果不指定名称，系统则将返回属于TYPE的全部对象的列表，例如将返回所有Pod的列表。flags。

每个容器运行时都有特点，因此不少用户希望Kubernetes能够支持更多的容器运行时。Kubernetes从1.5版本开始引入了CRI接口规范，通过插件接口模式，Kubernetes无须重新编译就可以使用更多的容器运行时。CRI包含Protocol Buffers、gRPC API、运行库支持及开发中的标准规范和工具。Docker的CRI实现在Kubernetes 1.6中被更新为Beta版本，并在kubelet启动时默认启动。可替代的容器运行时支持是Kubernetes中的新概念。

每个服务的可用参数都可以通过运行“cmd --help”命令进行查看，其中cmd为具体的服务启动命令，例如kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy等。公共配置参数适用于所有服务，如表所示的参数可用于kube-apiserver 、kube-controller- manager、kube-scheduler、kubelet、kube-proxy。对kube-apiserver启动参数的详细说明如表所示。

应对集群中的各Node逐个进行隔离，然后等待在其上运行的容器全部执行完成，再更新该Node上的kubelet和kube-proxy服务，将全部Node都更新完成后，再更新Master的服务。kubeadm提供了upgrade命令用于对kubeadm安装的Kubernetes集群进行升级。这一功能提供了从1.10到1.11、从1.11到1.12、从1.12到1.13及从1.13到1.14的升级能力，这里试用一下从1.13到1.14的升级。输入“y”​，确认之后，开始进行升级。

在多个Node组成的Kubernetes集群内，跨主机的容器间网络互通是Kubernetes集群能够正常工作的前提条件。但是，许多企业内部由于安全原因无法访问Internet，需要通过创建一个内部的私有Docker Registry，并修改一些Kubernetes的配置，来启动内网中的Kubernetes集群。由于在Kubernetes中是以Pod而不是以Docker容器为管理单元的，在kubelet创建Pod时，还通过启动一个名为k8s.gcr.io/pause:3.1的镜像来实现Pod的概念。

在使用kubectl对Kubernetes集群进行操作时，默认使用非安全端口8080对API Server进行访问，也可以设置为安全访问API Server的模式，需要设置3个证书相关的参数“—certificate -authority”​“–client-certificate”和“–client-key”​，分别表示用于CA授权的证书、客户端证书和客户端密钥。其中，在生成cs_client.crt时，-CA参数和-CAkey参数使用的是API Server的ca.crt和ca.key文件。

将Kubernetes的二进制可执行文件复制到/usr/bin目录下，然后在/usr/lib/system/system目录下为各服务创建systemd服务配置文件（完整的systemd系统知识请参考Linux的相关手册）​，这样就完成了软件的安装。要使Kubernetes正常工作，需要详细配置各个服务的启动参数。配置文件/etc/kubernetes/apiserver的内容包括了kube-apiserver的全部启动参数，主要的配置参数在变量KUBE_API_ARGS中指定。

最简单的方法是使用yum install kubernetes命令安装Kubernetes集群，但仍需修改各组件的启动参数，才能完成对Kubernetes集群的配置，整个过程比较复杂，也容易出错。需要注意的是，CentOS Linux 7默认启动了防火墙服务（firewalld）​，而Kubernetes的Master与工作Node之间会有大量的网络通信，安全的做法是在防火墙上配置各组件需要相互通信的端口号，具体要配置的端口号详见2.8 节各服务启动参数中监听的端口号。

Service服务也是Kubernetes里的核心资源对象之一，Kubernetes里的每个Service其实就是我们经常提起的微服务架构中的一个微服务，之前讲解Pod、RC等资源对象其实都是为讲解Kubernetes Service做铺垫的。下图显示了Pod、RC与Service的逻辑关系。

Kubernetes中的大部分概念如Node、Pod、ReplicationController、Service等都可以被看作一种资源对象，几乎所有资源对象都可以通过Kubernetes提供的kubectl工具（或者API编程调用）执行增、删、改、查等操作并将其保存在etcd中持久化存储。从这个角度来看，Kubernetes其实是一个高度自动化的资源控制系统，它通过跟踪对比etcd库里保存的“资源期望状态”与当前环境中的“实际资源状态”的差异来实现自动控制和自动纠错的高级功能。在声明一个Kubernetes