【k8s权威指南】第1章 Kubernetes入门

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开发中的新功能

第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提供了大量能使我们快速便捷地处理数据的函数和方法。文章来源地址https://www.toymoban.com/news/detail-407525.html

到了这里，关于【k8s权威指南】第1章 Kubernetes入门的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！