Kubernetes权威指南:从Docker到Kubernetes实践全接触

本系列文章是书籍:Kubernetes权威指南(第四版):从Docker到Kubernetes实践全接触/龚正等 编著. 的学习笔记 第1章 Kubernetes入门
第2章 Kubernetes安装配置指南
第3章 深入掌握Pod
第4章 深入掌握Service
第5章 核心组件运行机制
第6章 深入分析集群安全机制
第7章 网络原理
第8章 共享存储原理
第9章 Kubernetes开发指南
第10章 Kubernetes集群管理
第11章 Trouble Shooting指导
第12章 Kubernetes开发中的新功能



文章目录

  • Kubernetes权威指南:从Docker到Kubernetes实践全接触
  • 第1章 Kubernetes入门
  • 1.1 Kubernetes是什么
  • 定义
  • 基本知识
  • 运维工作
  • 1.2 为什么要用Kubernetes
  • 1.docker的舵手
  • 2.精简开发团队
  • 3.拥抱微服务架构
  • 4.可以随时随地将系统整体“搬迁”到公有云上
  • 5.快速扩容/缩容
  • 1.3 从一个简单的例子开始
  • 1.3.1 环境准备
  • 1.3.2 启动MySQL服务
  • 1.3.3 启动Tomcat应用
  • 1.3.4 通过浏览器访问网页
  • 1.4 Kubernetes的基本概念和术语
  • 1.4.1 Master
  • 1.4.2 Node
  • 1.4.3 Pod
  • 1.4.4 Label
  • 1.4.5 Replication Controller
  • 1.4.6 Deployment
  • 1.4.7 Horizontal Pod Autoscaler
  • 1.4.8 StatefulSet
  • 1.4.9 Service
  • 1.4.10 Job
  • 1.4.11 Volume
  • 1.4.12 Persistent Volume
  • 1.4.13 Namespace
  • 1.4.14 Annotation
  • 1.4.15 ConfigMap
  • 1
  • 总结



第1章 Kubernetes入门

提示:这里可以添加本文要记录的大概内容:

例如:随着人工智能的不断发展,机器学习这门技术也越来越重要,很多人都开启了学习机器学习,本文就介绍了机器学习的基础内容。


1.1 Kubernetes是什么

定义

首先,Kubernetes是一个全新的基于容器技术的分布式架构领先方案
其次,Kubernetes其实是一个高度自动化的资源控制系统
再次,Kubernetes是一个开放的开发平台
最后,Kubernetes是一个完备的分布式系统支撑平台

总结,Kubernetes是一个全新的基于容器技术的分布式架构解决方案,并且
是一个一站式的完备的分布式系统开发和支撑平台。
自己的理解:k8s是一张大网,一张架构图,能够解决集群(许多容器)管理问题,甚至还可以自动化运维,缩容扩容也很容易

基本知识

1.service
Service是分布式集群架构的核心,是实现了某个具体业务的特定TCP Server进程。相当于把功能的相关组件打包在一起,一个黑匣子,对外只提供端口,连接便可使用。

2.pod
pod可以理解为容器的集合,通常把一组密切相关的服务进程放入同一个Pod中。

service里面包含pod,pod是集群管理的最小组件。给每个Pod都贴上一个标签(Label),可以解决Service与Pod的关联问题。

首先,Pod运行在一个被称为节点(Node)的环境中,这个节点既可以是物理机,也可以是私有云或
者公有云中的一个虚拟机,通常在一个节点上运行几百个Pod;
其次,在每个Pod中都运行着一个特殊的被称为Pause的容器,其他容器则为业务容器。

3.机器划分
在集群管理方面,Kubernetes将集群中的机器划分为一个Master和一些Node。

在Master上运行着集群管理相关的一组进程kubeapiserver、kube-controller-manager和kubescheduler,这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和
纠错等管理功能,并且都是自动完成的。
Node作为集群中的工作节点,运行真正的应用程序,在Node上Kubernetes管理的最小运行单元是Pod。在Node上运行着Kubernetes的kubelet、kube-proxy服务进程,这些服务进程负责Pod的创建、启动、监控、重启、销毁,以及实现软件模式的负载均衡器。

运维工作

运维工作总会遇到服务扩容和服务升级这两个难题

服务的扩容涉及资源分配(选择哪个节点进行扩容)、实例部署和启动等环节,在一个复杂的业务系统中,这两个难题基本上靠人工一步步操作才得以解决,费时费力又难以保证实施质量。
在Kubernetes集群中,只需为需要扩容的Service关联的Pod创建一个RC(Replication Controller),服务扩容以至服务升级等令人头疼的问题都迎刃而解。

1.2 为什么要用Kubernetes

1.docker的舵手

当前,Docker这门容器化技术已经被很多公司采用,从单机走向集群已成为必然,Kubernetes作为当前被业界广泛认可和看好的基于Docker的大规模容器化分布式系统解决方案,得到了以谷歌为首的IT巨头们的大力宣传和持续推进。

2.精简开发团队

只需一名架构师负责系统中服务组件的架构设计,几名开发工程师负责业务代码的开发,一名系统兼运维工程师负责Kubernetes的部署和运维,就可以开发复杂系统了

3.拥抱微服务架构

4.可以随时随地将系统整体“搬迁”到公有云上

5.快速扩容/缩容

。。。

1.3 从一个简单的例子开始

运行在Tomcat里的Web App
当我们通过浏览器访问此应用时,就会显示一个表格的页面,数据则来自数据库。此应用需要启动两个容器:Web App容器和MySQL容器,并且Web App容器需要访问MySQL容器。

在Docker时代
在一个宿主机上启动了这两个容器,就需要把MySQL容器的IP地址通过环境变量注入Web App容器里;同时,需要将Web App容器的8080端口映射到宿主机的8080端口,以便在外部访问。

在Kubernetes时代

1.3.1 环境准备

安装Kubernetes和下载相关镜像,然后使用kubeadm快速安装一个Kubernetes集群
注:本书示例中的Docker镜像下载地址为 https://hub.docker.com/u/kubeguide/

1.3.2 启动MySQL服务

首先,为MySQL服务创建一个RC定义文件mysql-rc.yaml
RC(ReplicationController)
replicas=1,表示只能运行一个MySQL Pod实例。当在集群中运行的Pod数量少于replicas时,RC
会根据在spec.template一节中定义的Pod模板来生成一个新的Pod实例

在创建好mysql-rc.yaml文件后,为了将它发布到Kubernetes集群中

Kubernetes根据mysql这个RC的定义自动创建的Pod,此外会发现MySQL Pod对应的容器还多创建了一个来自谷歌的pause容器,这就是Pod的“根容器”

最后,创建一个与之关联的Kubernetes Service—MySQL的定义文件(文件名为mysql-svc.yaml)
运行kubectl命令,创建Service,根据Service的唯一名称,容器可以从环境变量中获取Service对应的Cluster IP地址和端口,从而发起TCP/IP连接请求。

1.3.3 启动Tomcat应用

1.3.4 通过浏览器访问网页

1.4 Kubernetes的基本概念和术语

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

在声明一个Kubernetes资源对象的时候,需要注意一个关键属性:apiVersion。Kubernetes大部分常见
的核心资源对象都归属于v1这个核心API,比如Node、Pod、Service、Endpoints、Namespace、RC、PersistentVolume等。
我们可以采用YAML或JSON格式声明(定义或创建)一个Kubernetes资源对象,每个资源对象都有自己的特定语法格式(可以理解为数据库中一个特定的表)

1.4.1 Master

Kubernetes里的Master指的是集群控制节点,在每个Kubernetes集群里都需要有一个Master来负责整个集群的管理和控制,基本上Kubernetes的所有控制命令都发给它,如果它宕机或者不可用,那么对集
群内容器应用的管理都将失效。

在Master上运行着以下关键进程

  • Kubernetes API Server(kube-apiserver):提供了HTTP Rest接口的关键服务进程,是Kubernetes里所有资源的增、删、改、查等操作的唯一入口,也是集群控制的入口进程。
  • Kubernetes Controller Manager(kube-controller-manager):Kubernetes里所有资源对象的自动化控制中心,可以将其理解为资源对象的“大总管”。
  • Kubernetes Scheduler(kube-scheduler):负责资源调度(Pod调度)的进程,相当于公交公司的“调度室”。
    另外,在Master上通常还需要部署etcd服务,因为Kubernetes里的所有资源对象的数据都被保存在etcd中。

1.4.2 Node

除了Master,Kubernetes集群中的其他机器被称为Node。Node是Kubernetes集群中的工作负载节
点,每个Node都会被Master分配一些工作负载(Docker容器),当某个Node宕机时,其上的工作负载会被Master自动转移到其他节点上。
在每个Node上都运行着以下关键进程。

  • kubelet:负责Pod对应的容器的创建、启停等任务,同时与Master密切协作,实现集群管理的基本功能。
  • kube-proxy:实现Kubernetes Service的通信与负载均衡机制的重要组件。
  • Docker Engine(docker):Docker引擎,负责本机的容器创建和管理工作。

1.4.3 Pod

Pod是Kubernetes最重要的基本概念,每个Pod都有一个特殊的被称为“根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分,除了Pause容器,每个Pod还包含一个或多个紧密相关的用户业务容器。
为什么Kubernetes会设计出一个全新的Pod的概念并且Pod有这样特殊的组成结构?

  • 引入业务无关并且不易死亡的Pause容器作为Pod的根容器,以它的状态代表整个容器组的状态,可以解决难以判断整体容器状态的问题
  • Pod里的多个业务容器共享Pause容器的IP,共享Pause容器挂接的Volume,这样既简化了密切关联的业务容器之间的通信问题,也很好地解决了它们之间的文件共享问题。

Pod其实有两种类型:普通的Pod及静态Pod(Static Pod)。
静态Pod,没被存放在Kubernetes的etcd存储里,而是被存放在某个具体的Node上的一个具体文件中,并且只在此Node上启动、运行。
普通Pod,一旦被创建,就会被放入etcd中存储,随后会被Kubernetes Master调度到某个具体的Node上。

Pod及周边对象
1.Endpoint
Kubernetes为每个Pod都分配了唯一的IP地址,称之为Pod IP。
在Pod里所包含的容器组的定义则在spec一节中声明,包括容器名,镜像,容器端口(containerPort)。。。
Pod的IP加上这里的容器端口(containerPort),组成了一个新的概念—Endpoint,它代表此Pod里的一个服务进程的对外通信地址。
2.Volume
3.Event

1.4.4 Label

Label和Label Selector共同构成了Kubernetes系统中核心的应用模型,使得被管理对象能够被精细地分组管理,同时实现了整个集群的高可用性。

1.4.5 Replication Controller

声明某种Pod的副本数量在任意时刻都符合某个预期值,包括

  • Pod期待的副本数量
  • 用于筛选目标Pod的Label Selector
  • 当Pod的副本数量小于预期数量时,用于创建新Pod的Pod模板(template)

在我们定义了一个RC并将其提交到Kubernetes集群中后,Master上的Controller Manager组件就得到通知,定期巡检系统中当前存活的目标Pod,并确保目标Pod实例的数量刚好等于此RC的期望值,如果有过多的Pod副本在运行,系统就会停掉一些Pod,否则系统会再自动创建一些Pod
在运行时,我们可以通过修改RC的副本数量,来实现Pod的动态缩放(Scaling),这可以通过执行kubectl scale命令来一键完成

通过RC机制,Kubernetes很容易就实现了“滚动升级”(Rolling Update),比如在当前系统中有10个对应的旧版本的Pod,则最佳的系统升级方式是旧版本的Pod每停止一个,就同时创建一个新版本的Pod,在整个升级过程中此消彼长,而运行中的Pod数量始终是10个,几分钟以后,当所有的Pod都已经是新版本时,系统升级完成。

总结:

  • 在大多数情况下,我们通过定义一个RC实现Pod的创建及副本数量的自动控制。
  • 在RC里包括完整的Pod定义模板。
  • RC通过Label Selector机制实现对Pod副本的自动控制。
  • 通过改变RC里的Pod副本数量,可以实现Pod的扩容或缩容。
  • 通过改变RC里Pod模板中的镜像版本,可以实现Pod的滚动升级。

1.4.6 Deployment

Deployment可以把它看作RC的一次升级,让我们可以随时知道当前Pod“部署”的进度。

1.4.7 Horizontal Pod Autoscaler

Pod横向自动扩容(HPA),HPA与之前的RC、Deployment一样,也属于一种Kubernetes资源对象。通过追踪分析指定RC控制的所有目标Pod的负载变化情况,来确定是否需要有针对性地调整目标Pod的副本数量,这是HPA的实现原理

HPA有以下两种方式作为Pod负载的度量指标

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

CPUUtilizationPercentage是一个算术平均值,即目标Pod所有副本自身的CPU利用率的平均值。即目标Pod所有副本自身的CPU利用率的平均值。一个Pod自身的CPU利用率是该Pod当前CPU的使用量除以它的Pod Request的值,比如定义一个Pod的PodRequest为0.4,而当前Pod的CPU使用量为0.2,则它的CPU使用率为50%,这样就可以算出一个RC控制的所有Pod副本的CPU利用率的算术平均值了。如果某一时刻CPUUtilizationPercentage的值超过80%,则意味着当前Pod副本数量很可能不足以支撑接下来更多的请求,需要进行动态扩容,而在请求高峰时段过去后,Pod的CPU利用率又会降下来,此时对应的Pod副本数应该自动减少到一个合理的水平。如果目标Pod没有定义Pod Request的值,则无法使用CPUUtilizationPercentage实现Pod横向自动扩容

1.4.8 StatefulSet

用来管理有状态的集群
先明白一个概念:有状态的集群

  • 每个节点都有固定的身份ID,通过这个ID,集群中的成员可以相互发现并通信
  • 集群的规模是比较固定的,集群规模不能随意变动
  • 集群中的每个节点都是有状态的,通常会持久化数据到永久存储中
  • 如果磁盘损坏,则集群里的某个节点无法正常运行,集群功能受损

如果通过RC或Deployment控制Pod副本数量来实现上述有状态的集群,就会发现第1点是无法满足的,因为Pod的名称是随机产生的,Pod的IP地址也是在运行期才确定且可能有变动的,我们事先无法为每个Pod都确定唯一不变的ID。另外,为了能够在其他节点上恢复某个失败的节点,这种集群中的Pod需要挂接某种共享存储,为了解决这个问题,Kubernetes从1.4版本开始引入了PetSet这个新的资源对象,并且在1.5版本时更名为StatefulSet,StatefulSet从本质上来说,可以看作Deployment/RC的一个特殊变种,它有如下特性。

  • StatefulSet里的每个Pod都有稳定、唯一的网络标识,可以用来发现集群内的其他成员。假设StatefulSet的名称为kafka,那么第1个Pod叫kafka-0,第2个叫kafka-1,以此类推。
  • StatefulSet控制的Pod副本的启停顺序是受控的,操作第n个Pod时,前n-1个Pod已经是运行且准备好的状态
  • StatefulSet里的Pod采用稳定的持久化存储卷,通过PV或PVC来实现,删除Pod时默认不会删除与StatefulSet相关的存储卷(为了保证数据的安全)

1.4.9 Service

1.概述
Service服务也是Kubernetes里的核心资源对象之一,Kubernetes里的每个Service其实就是我们经常提起的微服务架构中的一个微服务,功能就是通过Label Selector来实现Service与其后端Pod副本集群之间的无缝对接的。
2.Kubernetes的服务发现机制
任何分布式系统都会涉及“服务发现”这个基础问题,Kubernetes则采用了直观朴素的思路去解决这个棘手的问题
首先,每个Kubernetes中的Service都有唯一的Cluster IP及唯一的名称,而名称是由开发者自己定义的,部署时也没必要改变,所以完全可以被固定在配置中。接下来的问题就是如何通过Service的名称找
到对应的Cluster IP。Kubernetes通过Add-On增值包引入了DNS系统,把服务名作为DNS域名,这样程序就可以直接使用服务名来建立通信连接了。
3.外部系统访问Service的问题
为了更深入地理解和掌握Kubernetes,我们需要弄明白Kubernetes里的3种IP,这3种IP分别如下。

  • Node IP:Node的IP地址
  • Pod IP:Pod的IP地址
  • Cluster IP:Service的IP地址

1.4.10 Job

1.4.11 Volume

1.4.12 Persistent Volume

1.4.13 Namespace

1.4.14 Annotation

1.4.15 ConfigMap

1


总结

提示:这里对文章进行总结:

例如:以上就是今天要讲的内容,本文仅仅简单介绍了pandas的使用,而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。