Kubernetes学习笔记(1)

1 Kubernetes入门

---

1.1 Kubernetes是什么？

k8s是一个基于容器技术的分布式架支持平台，以实现资源管理的自动化以及跨多个数据中心的资源利用率的最大化。它具备完备的集群管理能力：

• 多层次的安全防护和准入机制
• 多租户应用支撑
• 透明的服务注册和服务发现机制
• 内建的智能负载均衡器
• 强大的故障发现和自我修复
• 服务滚动升级和在线扩容能力
• 可扩展的资源自动调度机制
• 多力度资源配额管理能力。

k8s基本知识

• Service（虚拟Cluster IP + Service Port）：分布式集群架构的核心。都是基于Socket通信方式对外提供服务（Redis、Memcache、MySQL、WebServer），实现没狗哥具体业务的一个特定的TCP Server进程。
• Pod：运行于节点（NOde）之上，包含一个Pause容器和若干业务容器的对象。其他业务容器共享Pause容器的网络栈和Volume卷。
• K8s通过给Pod贴标签（Label），然后给Service定义标签选择器（Label Selector,），进行Service和Pod进行关联。并不是每个Pod和它里面运行的容器都能“映射”到一个Service上，只有那些提供服务的一组Pod才会被“映射”成一个服务。
• Master节点：运行着kube-apiserver、kube-controller-manager和kube-scheduler服务进程，实现整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能的节点。
• Node节点：运行着kubelet、kube-proxy服务进程，负责Pod的创建、启动、监控、重启、销毁，以及实现软件模式的负载均衡器。
• RC（Replication Controller）:用来定义Pod、Pod运行副本数量、监控目标Pod的标签。

---

1.2 为什么要用Kubernetes？

• k8s是当前唯一被业界广泛认可和看好的Docker分布式系统解决方案。
• k8s全面拥抱微服务器，微服务器的核心是将一个巨大的单体应用分解为很多小的互相连接的微服务，一个微服务背后可能有多个实例副本在支撑，副本的数量可能会伴随着系统的负荷变化而进行调整，内嵌的负载均衡器在这里发挥重要作用。
• k8s可以随时随地搬迁上云，切具备超强的横向扩容能力。

---

1.3 Kubernets基本概念和术语

1.3.1 Master

• 每个k8s集群里需要一个Master节点来负责整个集群的管理和控制，关键进程如下：
• Kubernetes API Server(kube-apiserver)：提供了HTTP Rest接口的关键服务进程，是k8s里所有资源的增删改查等操作的唯一入口，也是集群控制的入口进程。
• Kubernetes Controller Manager（kube-controller-manager）：K8s里所有资源的自动化控制中心。
• Kbernetes Scheduler(kube-scheduler)：负责资源调度（Pod调度）的进程。
• etcd服务：k8s所有资源对象的数据全部是保存在etcd中的。

1.3.2 Node

• Node节点是k8s集群中的工作负载节点，每个Node会被Master分配一些工作负载（Docker容器），当某个Node宕机时，其上的工作负载会被Master自动转移到其他Node上去。
• Node节点关键进程如下：
• kubelet：负责Pod对应的容器的创建、启停等任务，同时与Master节点密切协作，实现集群管理的基本功能。
• kube-prox：实现Kubernetes Service 的通信与负载均衡机制的重要组件。
• Dokcer Engine（docker）:Docker 引擎，负责本机的容器创建和管理工作。
• 常用命令：
• # kubectl get nodes //查看Nodes
• # kubectl describe node k8s-node-1 //查看某个node信息

1.3.3 Pod

• Pod：由一个Pause容器（根容器）和若干个业务容器组成。引入业务无关并且不易死亡的Pause容器作为Pod的根容器，以它的状态代表整个容器组的状态。Pod里的多个业务容器共享Pause容器的IP和Volume，解决业务容器之间的通信问题和文件共享问题。
• 普通Pod：一经创建，就会被放入到etcd中存储，随后被Master调度到某个具体的Node上并进行绑定（Binding），随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Dokcer容器并启动起来。
• Pod Volume定义在Pod之上，可以用分布式文件系统GlusterFS实现后端存储，然后被各种容器挂在到自己的文件系统中。
• Event是一个事件的记录，记录了事件的最早产生时间、最后重现时间、重复次数、发起者、类型，以及导致此事件的原因等众多信息。
• 每个Pod都可以对其能使用的服务器上的计算资源设置限额，CPU以千分之一为最小配额单位，用m表示。100~300m，即占用0.1~0.3个CPU。Memory配额也是绝对值，单位是内存字节数，MiB。
• #kubectl describe pod xxxx //查看pod信息

1.3.4 Label

• Label（标签）：Label是一个key=value的键值对，打过Label后，随后可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象。
• Label Selector 在Kubernetes中的重要使用场景：
• kube-controller进程通过资源对象RC上定义的Label Selector来筛选要监控的Pod副本的数量，从而实现Pod副本的数量始终符合预期设定的全自动控制流程。
• kube-proxy进程通过Service的Label Selector 来选择对应的Pod，自动建立起每个Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡机制。
• 通过对某些Node定义特定的Label，并且在Pod定义文件中使用NodeSelector 这种标签调度策略，kube-scheduler进程可以实现Pod“定向调度”的特性。
• 使用Label可以给对象创建多组标签，Label和Label Selector 共同构成了kubernetes系统中最核心的应用模型，使得被管理对象能够被精细的分组管理，同时实现了整个集群的高可用性。

1.3.5 Replication Controller

• RC定义了一个期望场景，即声明某种Pod的副本数量在任意时刻都符合某个预期值，RC的定义包括：
• Pod期待的副本数
• 用于筛选目标Pod的Label Selector
• 当Pod的副本数量小于预期数量时，用于创建新Pod的Pod模板（template）。
• 通过RC机制，k8s很容易实现停止一个旧版本Pod，创建一个新版本Pod，此消彼长，这种“滚动升级”。

1.3.6 Deployment

• Deployment（内部使用Replica Set来实现），为了更好的解决Pod的编排问题。可以看为RC的一次升级，相速度超过90%。
• 相比RC，Deployment最大升级是随时知道当前Pod“部署”的进度。
• # kubectl create -f tomcat-deployment.yaml
• # kubectl get deployments //查看Deployment信息
• # kubectl get rs //查看对应的Replica Set
• # kubectl get pods //查看Pods
• # kubectl describe deployments //查看Deployment控制的Pod的水平扩展过程。

1.3.7 Horizontal Pod Autoscaler

• HPA也属于k8s资源对象，通过跟踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数。HPA有两种方式作为Pod负载的度量指标。
• CPUUtilizationPercentage（CPU利用率），即目标Pod所有副本自身的CPU利用率的平均值。
• TPS或QPS（应用程序自定义的度量指标），比如服务在每秒内的响应的请求数。

1.3.8 StatefulSet

• StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。
• StatefulSet控制的Pod副本的启停顺序受控。
• StatefulSet里的Pod采用稳定的持久化存储卷，通过PV/PVC来实现，删除Pod时默认不删除与StatefulSet相关的存储卷。

1.3.9 Service

• k8s里的每个Service其实就是微服务架构中的一个“微服务”。k8s的Service定义了一个服务的访问入口地址，前端的应用（Pod）通过这个入口地址访问其背后的一组由Pod副本组成的集群实例，Service与其后端Pod副本集群之间则是通过LabelSelector来实现“无缝对接”。RC的作用实际上是保证Service的服务能力和服务质量始终处于预期的标准。
• K8s所提供的微服务网格架构，即通过分析、识别并建模系统中的所有服务为微服务——k8s Service，最终我们的系统由多个提供不同业务能力而又彼此独立的微服务单元组成，服务之间通过TCP/IP进行通信，从而形成了我们强大而又灵活的弹性网格，拥有了强大的分布式能力、弹性扩展能力、容错能力。
• k8s的服务发现机制：前期使用Linux环境变量解决，后面通过Add-ON增值包的方引入DNS系统，把服务名作为DNS域名，直接通过服务名建立通信。
• IP：
• Node IP：Node节点IP地址，k8Is集群之外的节点访问k8s集群之内的节点或者TCP/IP服务时，必须通过Node IP进行通信。
• Pod IP：Pod IP地址，Dokcer Engine根据docker0网桥的IP地址段进行分配的，是个一个虚拟的二层网络。k8s内一个Pod里的容器访问另外一个Pod里的容器，就是通过Pod IP所在的虚拟二层网络进行通信的，而真实的TCP/IP流量则是通过Node IP所在的物理网卡流出的。
• Cluster IP：Service IP地址，又k8s管理和分配给Service对象的IP地址，无法被Ping，只能结合Service Port组成一个具体的通信端口，属于k8s集群内部的地址。

1.3.10 Volume

• Volume是Pod中能够被多个容器访问的共享目录。类似于Docker的Volume，但不等价。首先，k8s的Volume定义在Pod上，被一个Pod里的多个容器挂载使用，且与Pod的生命周期相同，和容器不相关，容器终止或重启时，Volume数据不丢失。
• Volume类型：
• emptyDir：由k8s自动分配的忙碌，当Pod从Node上移除时，emptyDir数据会被永久删除。一般作为临时空间。
• hostPath：Pod上挂载宿主机上的文件或目录。
• gcePersistentDisk：使用谷歌公有云提供的永久磁盘（PD）。
• awsElasticBlockStore：使用亚马逊公有云提供的EBS Volume存储数据。
• NFS：使用网络文件系统提供的共享目录存储数据。
• 其他：iscsi，flocker，glusterfs，rbd，gitRepo，secret

1.3.11 Persistent Volume

• PV可以理解成k8s集群中的某个网络存储中对应的一块存储，PV只能是网络存储，PV并不是定义在Pod上，独立于Pod之外。
• PV的accessModes属性：
• ReadWriteOnce:读写权限、并且只能被单个Node挂载
• ReadOnlyMany：只读权限，允许被多个Node挂载
• ReadWriteMany：读写权限，允许被多个Node挂载
• PV的状态：Available（空闲状态）、Bound（已绑定到某个PVC上）、Released（对应的PVC已删除，但资源未被集群收回）

1.3.12 Namespace

• Names用于实现多租户的资源隔离。我们可以给每一个租户创建一个Namespace来实现多租户的资源隔离，结合k8s的资源配额管理，限定不同租户能占用的资源，例如CPU、内存使用量等。
• 1.3.13 Annotation（注解）
• Annotation使用键值对形式定义，是用户可以任意定义的“附加信息”，以便于外部工具进行查找。