k8s使用volume将ConfigMap作为文件或目录直接挂载_运维篇K8S入门基础概念

      随着容器越来越普及，精通K8S已成为行业对运维的一个基本要求。为了方便新手学习K8S，整理了K8S的一些基础概念；在理解这些概念之后，再进行安装部署、测试，或许会有更好的效果。

Master

集群控制节点。每个K8S至少需要一个master节点来负责整个集群的管理与控制。master节点通常会占用一个独立的服务器，如果是高可用部署的话，建议是3台服务器。

master节点运行着3个重要组件，分别是APIServer，sheduler和controller manager。

• APIServer：提供http rest接口的关键服务进程，是整个K8S资源增删改查操作的唯一入口，也是集群控制的入口进程。

• sheduler：负责资源调度的进程(POD调度)

• controller manager：K8S所有资源对象的自动化控制中心。

另外，master还需要启动一个ETC服务，k8s里的所有资源对象的数据都是保存在etcd中的。

Node

容器允许的工作负载节点，你可以简单理解类承载容器的宿主机。

每个Node节点运行着一组关键进程

• Kubele:负责pod对应容器的创建、启停等任务，与Master节点密切协作，实现集群管理功能。

• Kube-proxy:实现k8s 服务的通信与负载均衡机制的重要组件。

• Docker Engine:容器引擎，负责本机的容器创建和管理工作。

Pod

Pod是K8S最重要也是最基本的概念。每个Pod都有一个被称为“根容器“的Pause容器Pause容器对应的镜像属于K8S平台的一部分，除了Pause容器，每个POD还包含一个或多个紧密相关的用户业务容器。

Pod有两种类型：普通跟静态，静态pod并不放在etcd 存储里，而是放在某个具体POD的一个具体文件中，并且只在此node上运行。而普通Pod一但被创建，就被放入etcd存储中，随后被K8S master调度到某个具体的Node进行绑定，随后该pod被对应node上的kubelet进程实例化一组相关的docker容器并启动起来。

Label(标签)

label是k8s另外一个核心的概念，是一个key=value值，通过给指定的资源对象捆绑一个或者多个不同的Label来实现多维度的资源分组管理。

Replication Controller

简称RC，简单来说，定义了一个期望的场景，声明某种pod的副本数量在任何时刻都符合预期值。RC一般定义如下几个部分：

• pod期待的副本数(replicas)

• 用于筛选目标pod的Label Selector.

• 当pod的副本数小于预期数量时，用于创建新pod的pod模板(template)。

注：删除RC，并不会删除通过该RC已经创建的pod

Deployment

可以把它看做是RC的升级，引入的主要目的是为了更好的解决pod的编排问题，可以让我们随时知道当前pod部署的进度。

Horizontal Pod Autoscaler

HPA与之前的RC，Deployment一样，也属于一种K8S的管理对象，通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对的调整目标pod的副本数。目前衡量Pod负载的度量指标有两种方式：

• CPU 使用比例

• 应用程序自定义的度量指标，比如服务每秒内的相应请求数(TPS,QPS)

StatefulSet

SateefulSet里的每个pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。它控制的pod的副本的启停顺序是受控的，操作第n个pod时，前n-1个pod已经是运行且准备好的状态。StatefulSet里的pod采用稳定的持久化存储卷，通过PV/PVC来实现，删除pod时默认不会删除相关的存储卷，可以保证数据的安全。

Service(服务)

k8s里的每个service其实是我们经常提起的微服务架构中的一个“微服务”。Service定义了一个服务的访问入口地址，前端的应用(pod)通过这个入口地址访问其背后的一组由pod副本组成的集群实例，Service与其后端Pod副本集群之间通过Label Selector来实现无缝对接。

K8S三种IP类型

• Node IP:Node节点的物理网卡的ip地址，是一个真实存在的物理网络，

• Pod IP：Pod的ip地址，它是docker engine根据docker网桥的ip地址进行分配的，是一个虚拟的二层网络，Pod之间通过虚拟二层网络通信，真实的TCP/IP流量则是通过Node IP所在的物理网卡流出。

• Cluster IP :Service的IP 地址，属于K8S集群内部的地址，无法直接在集群外部直接使用这个地址。一个虚拟的IP，更像是一个伪造的IP网络。无法被ping，因为没有一个实体网络对象来响应。它只能结合Service Port组成一个通信端口，单独的Cluster ip不具备TCP/IP的基础，如果外部服务需要访问，解决办法一般是在Service里添加NodePort。

Volume(存储卷)

volume是pod中能够被多个容器访问的共享目录。k8s的Volume定义在Pod上，然后被一个pod里的多个容器挂载到具体的文件目录下；k8s的Volume与Pod的生命周期相同，但与容器的生命周期不相关，容器终止或者重启时，Volume中的数据不会丢失。k8s支持多种类型的Volume,如GlusterFS、Ceph等分布式文件系统。

Persistent Volume(PV)

PV可以理解为K8S集群中的某个网络存储中对应的一块存储，与Volume很类似，但又有区别：

• PV只能是网络存储，不属于任何Node,但可以在每个node上访问。

• PV并不定义在Pod上，而是独立于Pod之外的定义

• PV目前支持FC，NFS，iSCSI、RBD、CephFS、GlusterFS、VsphereVolume等。

如果某个pod想要申请某种类型的PV，需要先定义一个PersistentVolumelaim(PVC)对象，然后在pod的Volume定义中引用上述的PVC即可。

PV几种状态

Available(空闲状态)、Bound(已经绑定到某个PVC上)、Released(对应的PVC已经删除，但资源还没有被集群收回)、failed(PV自动回收失败)。

Namespace(命名空间)

Namespace是K8S中另外一个很重要的概念，Namespace在很多情况下用于实现多租户的资源隔离。Nameapce通过将集群内部的资源对象分配到不同的Namespace中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。

Annotation(注释)

annotation与label类似，也使用key/value键值对的形式进行定义。不同的是label具有严格的命名规则，它定义的是k8s对象的元数据(Metadata),并且用于Label Selector。而Annotation则是用户任意定义的附加信息，以便于外部工具进行查找，很多时候，k8s的模块自身会通过Anotaion的方式标记资源对象的一些特殊信息。

K8S的整体架构

Kubernetes网络插件对比分析

• Flannel

  与其他方案相比，Flannel相对容易安装和配置。它被打包为单个二进制文件FlannelD，许多常见的Kubernetes集群部署 工具 和许多Kubernetes发行版都可以默认安装Flannel。Flannel可以使用Kubernetes集群的现有etcd集群来使用API存储其状态信息，因此不需要专用的数据存储。Flannel配置第3层IPv4 Overlay网络。它会创建一个大型内部网络，跨越集群中每个节点。在此Overlay网络中，每个节点都有一个子网，用于在内部分配IP地址。在配置Pod时，每个节点上的Docker桥接口都会为每个新容器分配一个地址。同一主机中的Pod可以使用Docker桥接进行通信，而不同主机上的pod会使用flanneld将其流量封装在UDP数据包中，以便路由到适当的目标。Flannel有几种不同类型的后端可用于封装和路由。默认和推荐的方法是使用VXLAN，因为VXLAN性能更良好并且需要的手动干预更少。

• Calico

  Calico是Kubernetes生态系统中另一种流行的网络选择。虽然Flannel被公认为是最简单的选择，但Calico以其性能、灵活性而闻名尽管部署Calico所需的操作看起来相当简单，但它创建的网络环境同时具有简单和复杂的属性。与Flannel不同，Calico不使用overlay网络。相反，Calico配置第3层网络，该网络使用BGP路由协议在主机之间路由数据包。这意味着在主机之间移动时，不需要将数据包包装在额外的封装层中。BGP路由机制可以本地引导数据包，而无需额外在流量层中打包流量。除了性能优势之外，在出现网络问题时，用户还可以用更常规的方法进行故障排除除了网络连接外，Calico还以其先进的网络功能而闻名。网络策略是其最受追捧的功能之一。

• Weave

  Weave是由Weaveworks提供的一种Kubernetes CNI网络选项，它提供的模式和我们目前为止讨论的所有网络方案都不同。Weave在集群中的每个节点之间创建网状Overlay网络，参与者之间可以灵活路由。这一特性再结合其他一些独特的功能，在某些可能导致问题的情况下，Weave可以智能地路由。与Calico一样，Weave也为Kubernetes集群提供网络策略功能。设置Weave时，网络策略会自动安装和配置，因此除了添加网络规则之外，用户无需进行其他配置。一个其他网络方案都没有、Weave独有的功能，是对整个网络的简单加密。

K8S的负载均衡类型

• kube-proxy

  Kubernetes中最基本的负载均衡类型实际上是负载分配(load distribution)，这在调度层面是容易实现的。Kubernetes使用了两种负载分配的方法，都通过kube-proxy这一功能执行，该功能负责管理服务所使用的虚拟IPs。Kube-proxy的默认模式是iptables，它支持相当复杂的基于规则的IP管理。iptables模式下，负载分配的本地方法是随机选择——由一个传入的请求去随机选择一个服务中的pod。早先版本(以及原来的默认模式)的kube-proxy模式是userspace，它使用循环的负载分配，在IP列表上来分配下一个可以使用的pod，然后更换(或置换)该列表。

• Ingress(真正的负载均衡)

  我们之前提到了两种负载均衡的方法，然而，这些并不是真正的负载均衡。为了实现真正的负载均衡，当前最流行、最灵活、应用于很多领域的方法是Ingress，它通过在专门的Kubernetes pod中的控制器进行操作。控制器包括一个Ingress资源——一组管理流量的规则和一个应用这些规则的守护进程。控制器有自己内置的负载均衡特性，具备一些相当复杂的功能。你还可以让Ingress资源包含更复杂的负载均衡规则，来满足对具体系统或供应商的负载均衡功能和需求。

• 使用负载均衡器作为替代品

  除了Ingress，你还可以使用负载均衡器类型的服务来替代它。该服务使用基于云服务的外部负载均衡器。负载均衡器只能与AWS、Azure、OpenStack、CloudStack和Google Compute Engine等特定的云服务提供商一起使用，且均衡器的功能根据提供者而定。除此之外其他的负载均衡方法可以从服务提供商以及第三方获得。

***长按识别图中二维码，关注背锅先生公众号***