Docker和k8s焦点概念(明白友爱版)

打印 上一主题 下一主题

主题 894|帖子 894|积分 2682

背景
这是在HWL负责网校云业务线测试时,给同事分享的基础概念文档。
目录:
一. Docker焦点概念
二. Kubernetes是什么及架构
三. Kubernetes焦点概念
四. Deployment摆设Pod操作
一、Docker焦点概念

 
1、为什么是Docker

虚拟机:
基础设施(Infrastructure)。服务器,或者是云主机。
主操作系统(Host Operating System)。服务器上运行的操作系统
虚拟机管理系统(Hypervisor)。利用Hypervisor,可以在主操作系统之上运行多个不同的从操作系统。
从操作系统(Guest Operating System)。假设你需要运行3个相互隔离的应用,则需要使用Hypervisor启动3个从操作系统,也就是3个虚拟机。这些虚拟机都非常大,也许有700MB,这就意味着它们将占用2.1GB的磁盘空间。更糟糕的是,它们还会消耗很多CPU和内存。
各种依赖。每一个从操作系统都需要安装许多依赖。
应用。安装依赖之后,就可以在各个从操作系统分别运行应用了,这样各个应用就是相互隔离的。
Docker
Docker守护历程(Docker Daemon)。Docker守护历程代替了Hypervisor,它是运行在操作系统之上的后台历程,负责管理Docker容器。
各种依赖。对于Docker,应用的全部依赖都打包在Docker镜像中,Docker容器是基于Docker镜像创建的。
应用。应用的源代码与它的依赖都打包在Docker镜像中,不同的应用需要不同的Docker镜像。不同的应用运行在不同的Docker容器中,它们是相互隔离的。
对比虚拟机与Docker
Docker守护历程可以直接与主操作系统进行通信,为各个Docker容器分配资源;它还可以将容器与主操作系统隔离,并将各个容器相互隔离。虚拟机启动需要数分钟,而Docker容器可以在数毫秒内启动。由于没有痴肥的从操作系统,Docker可以节省大量的磁盘空间以及其他系统资源。

2、Docker 架构
 


Docker使用客户端 - 服务器(C/S)架构,使用远程API管理和创建Docker 容器。Docker 客户端与Docker 守护历程通信,后者负责构建、运行和分发Docker容器。
Docker客户端和守护历程可以在同一系统上运行,也可以将Docker客户端毗连到远程Docker守护历程。Docker客户端和守护历程使用REST API,通过UNIX套接字或网络接口进行通信。
Client
客户端通过命令行或其他工具与守护历程通信,客户端会将这些命令发送给守护历程,然后执行这些命令。命令使用Docker API,Docker客户端可以与多个守护历程通信。
Docker daemon
Docker守护历程(docker daemon)监听Docker API请求并管理Docker对象,如镜像,容器,网络和卷。守护程序还可以与其他守护程序通信以管理Docker服务。
Docker Host
Docker Host是物理机或虚拟机,用于执行Docker守护历程的仓库。
Docker Registry
Docker仓库用于存储Docker镜像,可以是Docker Hub这种公共仓库,也可以是个人搭建的私有仓库。使用docker pull或docker run命令时,将从配置的仓库中提取所需的镜像。使用docker push命令时,镜像将被推送到配置的仓库。
Docker Image
Docker 镜像可以看作是一个特别的文件系统,除了提供容器运行时所需的程序、库、资源、配置等文件外,还包含了一些为运行时预备的一些配置参数(如匿名卷、情况变量、用户等)。
镜像可以用来创建 Docker 容器,一个镜像可以创建很多容器。Docker 提供了一个很简单的机制来创建镜像或者更新现有的镜像,用户以致可以直接从其他人那边下载一个已经做好的镜像来直接使用。
Docker Container
Docker 利用容器来运行应用。容器是从镜像创建的运行实例。它可以被启动、开始、制止、删除。每个容器都是相互隔离的、保证安全的平台。
可以把容器看做是一个简易版的 Linux 情况(包括root用户权限、历程空间、用户空间和网络空间等)和运行在此中的应用程序。
3、Docker CLI
 

4、Dockerfile

5、Docker Compose
Compose 是用于界说和运行多容器 Docker 应用程序的工具。通过 Compose,您可以使用 YML 文件来配置应用程序需要的全部服务。然后,使用一个命令,就可以从 YML 文件配置中创建并启动全部服务。
 
6、Docker Swarm 集群管理
Swarm是Docker 引擎内置(原生)的集群管理和编排工具,它将 Docker 主机池变化为单个虚拟 Docker 主机。

 

Docker Swarm 适用于简单和快速开辟至关重要的情况,而 Kubernetes 适合大中型集群运行复杂应用程序的情况。
两者不是竞争对手,各有利弊,因需选择。
 
二、Kubernetes是什么及架构
1、k8s是什么
先来一张Kubernetes官网的截图,可以看到,官方对Kubernetes的界说:Kubernetes(k8s)是一个自动化摆设、扩展和管理容器化应用程序的开源系统。

Kubernetes 这个单词是希腊语,它的中文翻译是“舵手”或者“飞行员”。在一些常见的资料中也会看到“ks”这个词,也就是“k8s”,它是通过将8个字母“ubernete ”替换为“8”而导致的一个缩写。 Kubernetes 为什么要用“舵手”来命名呢?

这是一艘载着一堆集装箱的轮船,轮船在大海上运着集装箱奔忙,把集装箱送到它们该去的地方。Container 这个英文单词也有另外的一个意思就是“集装箱”。Kubernetes 也就借着这个寓意,希望成为运送集装箱的一个轮船,来帮助我们管理这些集装箱,也就是管理这些容器。
这个就是为什么会选用 Kubernetes 这个词来代表这个项目的原因。更详细一点地来说:Kubernetes 是一个自动化的容器编排平台,它负责应用的摆设、应用的弹性以及应用的管理。
2、k8s能做什么

  • 服务的发现与负载的平衡 
  • 容器的自动装箱,也会把它叫做 scheduling,就是“调度”,把一个容器放到一个集群的某一个呆板上,Kubernetes会帮助我们去做存储的编排,让存储的声明周期与容器的生命周期创建毗连
  • 容器的自动化恢复。在一个集群中,常常会出现宿主机的问题,导致容器本身的不可用,Kubernetes会自动地对这些不可用的容器进行恢复
  • 应用的自动发布与应用的回滚,以及与应用相关的配置密文的管理
  • 对于 job 类型任务,Kubernetes可以去做批量的执行
  • 为了让这个集群、这个应用更富有弹性,Kubernetes支持容器的水平伸缩
2.1调度
Kubernetes 可以把用户提交的容器放到 Kubernetes 管理的集群的某一台节点上去。Kubernetes 的调度器是执行这项能力的组件,它会观察正在被调度的这个容器的大小、规格。 
好比,容器所需要的CPU以及它所需要的内存,然后在集群中找一台相对比较空闲的呆板来进行一次放置的操作。

2.2 自动修复
Kubernetes 有节点健康查抄的功能,它会监测这个集群中全部的宿主机,当宿主机本身出现故障,或者软件出现故障的时候,这个节点健康查抄会自动对它进行发现。
接下来 Kubernetes 会把运行在这些失败节点上的容器进行自动迁移,迁移到一个正在健康运行的宿主机上,来完成集群内容器的自动恢复。

2.3 水平伸缩
Kubernetes有业务负载查抄的能力,它会监测业务上所承担的负载,如果这个业务本身的CPU利用率或内存占用过高,或者响应时间过长,它可以对这个业务进行一次扩容。
好比,下面的例子中,黄颜色的过度繁忙,Kubernetes就可以把黄颜色负载从一份变为三份。接下来,它就可以通过负载平衡把原来打到第一个黄颜色上的负载平均分到三个黄颜色的负载上去,以此来提高响应速度。

3、k8s的架构
Kubernetes 架构是一个比较典型的二层架构和server-client架构。Master作为中心管控节点,与Node创建毗连。
全部 UI 的、clients、user侧的组件,只会和Master进行毗连,把希望的状态或者想执行的命令下发给 Master,Master会把这些命令或者状态下发给相应的节点,进行最终的执行。


  • Master
Kubernetes 的Master包含四个主要的组件:API Server、Controller、Scheduler以及etcd。

API Server:提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制。
Kubernetes 中全部的组件都会和API Server进行毗连,组件与组件之间一般不进行独立的毗连,都依赖于API Server进行消息的传送;
Controller:控制器,它负责维护集群的状态,好比故障检测、自动扩展、滚动更新等。上面的2个例子,第1个自动对容器进行修复、第2个自动水平扩张,都是由Controller 完成的;
Scheduler:是调度器,负责资源的调度,按照预定的调度计谋将Pod调度到相应的呆板上。比方上面的例子,把用户提交的pod,依据它对CPU、memory请求的大小,找一台合适的节点,进行放置;
etcd:是一个分布式的存储系统,保存了整个集群的状态,好比Pod、Service等对象信息。API Server 中所需要的原信息都被放置在etcd中,etcd本身是一个高可用系统,通过etcd保证整个Kubernetes的Master组件的高可用性。

  • Node
Kubernetes 的 Node 是真正运行业务负载的,每个业务负载会以 Pod 的形式运行。一个 Pod 中运行的一个或者多个容器。
kubelet:Master在Node节点上的Agent,是真正去运行 Pod 的组件,也是Node上最关键的组件,负责本Node节点上Pod的创建、修改、监控、删除等生命周期管理,同时Kubelet定时“上报”本Node的状态信息到API Server。
它通过 API Server 接收到所需要 Pod 运行的状态。然后提交到 Container Runtime 组件中。

Container Runtime:容器运行时。负责镜像管理以及Pod和容器的真正运行(CRI),可以明白为类似JVM
Storage Plugin 或者 Network Plugin:对存储跟网络进行管理
在 OS 上去创建容器所需要运行的情况,最终把容器或者 Pod 运行起来,也需要对存储跟网络进行管理。Kubernetes 并不会直接进行网络存储的操作,他们会靠 Storage Plugin 或者Network Plugin 来进行操作。用户自己或者云厂商都会去写相应的 Storage Plugin 或者 Network Plugin,去完成存储操作或网络操作。
Kube-proxy:负责为Service提供cluster内部的服务发现和负载平衡,完成 service 组网
在 Kubernetes 自己的情况中,也会有 Kubernetes 的 Network,它是为了提供 Service network 来进行搭网组网的。真正完成 service 组网的组件是 Kube-proxy,它是利用了 iptable 的能力来进行组建 Kubernetes 的 Network,就是 cluster network。
组件间的通信 

步骤说明:
1. 通过 UI 或者 CLI 提交1个 Pod 给 Kubernetes 进行摆设,这个 Pod 请求首先会提交给API Server,下一步 API Server 会把这个信息写入到存储系统 etcd,之后 Scheduler 会通过 API Server 的 watch机制得到这个信息:有1个Pod 需要被调度。
2. Scheduler会根据node集群的内存状态进行1次调度决策,在完成这次调度之后,它会向 API Server 报告:“OK!这个 Pod 需要被调度到XX节点上。”
API Server 接收后,会把这次的操作效果再次写到 etcd 中。
3. API Server 关照相应的节点进行这个Pod真正的执行启动。相应节点的 kubelet 会得到关照,然后kubelet 会去调 Container runtime 来真正去启动配置这个容器和这个容器的运行情况,去调度 Storage Plugin 来去配置存储,network Plugin 去配置网络。
 
三、Kubernetes焦点概念
第一个概念:Pod
Pod 是 Kubernetes 的最小调度以及资源单元。可以通过 Kubernetes 的 Pod API 生产一个 Pod,让 Kubernetes 对这个 Pod 进行调度,也就是把它放在某一个 Kubernetes 管理的节点上运行起来。一个 Pod 简单来说是对一组容器的抽象,它里面会包含一个或多个容器
好比下图,它包含了两个容器,每个容器可以指定它所需要资源大小
固然,在这个 Pod 中也可以包含一些其他所需要的资源:好比说我们所看到的 Volume 卷这个存储资源。

第二个概念:Volume
管理 Kubernetes 存储,用来声明在 Pod 中的容器可以访问的文件目录,一个卷可以被挂载在 Pod 中一个或者多个容器的指定路径下面。
而 Volume 本身是一个抽象的概念,一个 Volume 可以去支持多种的后端的存储。Kubernetes 的 Volume 支持很多存储插件,可以支持本地的存储和分布式的存储,好比像 ceph,GlusterFS;也可以支持云存储,好比阿里云上的云盘、AWS 上的云盘、Google 上的云盘等等。

第三个概念:Deployment
Deployment 是在Pod上更为上层的一个抽象,它可以界说一组Pod 的副本数目、以及Pod的版本。一般用Deployment来做应用的真正的管理,而Pod是构成Deployment最小的单元。
Kubernetes通过 Controller(控制器)维护Deployment中Pod 的数目,Controller也会去帮助Deployment自动恢复失败的Pod。
好比,可以界说一个Deployment,这个Deployment里面需要2个Pod,当1个Pod失败的时候,控制器就会监测到,再去新天生1个Pod,把Deployment中的Pod数目从1个恢复到2个。通过控制器,也可以完成发布计谋,好比进行滚动升级、重新天生的升级或者进行版本回滚。

第四个概念:Service
Service:提供1个或者多个 Pod 实例的稳定访问地点
好比,一个 Deployment 大概有2个以致更多个完全雷同的 Pod。对于外部的用户来讲,访问哪个 Pod 都是一样的,所以希望做一次负载平衡,在做负载平衡的同时,只需要访问某一个固定的 VIP,也就是 Virtual IP 地点,而不需要得知每一个详细的 Pod 的 IP 地点。
如果1个 Pod 失败了,大概会换成另外一个新的。提供了多个详细的 Pod 地点,对外部用户来说,要不停地去更新 Pod 地点。当这个 Pod 再失败重启之后,如果有一个抽象,把全部 Pod 的访问能力抽象成1个第三方的 IP 地点,实现这个的 Kubernetes 的抽象就叫 Service。
实现 Service 有多种入口方式: 

  • ClusterIP:Service 在集群内的唯一 ip 地点,我们可以通过这个 ip,平衡的访问到后端的 Pod,而无须关心详细的 Pod。
  • NodePort:Service 会在集群的每个 Node 上都启动一个端口,我们可以通过任意Node 的这个端口来访问到 Pod。
  • LoadBalancer:在 NodePort 的基础上,借助公有云情况创建一个外部的负载平衡器,并将请求转发到 NodeIP:NodePort。
  • ExternalName:将服务通过 DNS CNAME 记录方式转发到指定的域名(通过 spec.externlName 设定)。

第五个概念:Namespace
Namespace:用来做一个集群内部的逻辑隔离,包括鉴权、资源管理等。Kubernetes 的每个资源,好比Pod、Deployment、Service 都属于一个 Namespace,同一个 Namespace 中的资源需要命名的唯一性,不同的 Namespace 中的资源可以重名。

K8SAPI
Kubernetes API 是由 HTTP+JSON 构成的:用户访问的方式是HTTP,访问API 中 content 的内容是JSON格式的。
用Kubectl 命令、Kubernetes UI或者Curl,直接与Kubernetes交互都是使用 HTTP + JSON 的形式。
如下图,对于这个Pod类型的资源,它的HTTP访问的路径就是 API,apiVesion: V1, 之后是相应的Namespaces,以及Pods资源,最终是 Podname,也就是Pod的名字。

当提交一个 Pod,或者 get 一个 Pod 的时候,它的 content 内容都是用JSON 或者是YAML表达的。上图中YAML的例子,在这个YAML文件中,对Pod资源的描述分为几个部门。
第一个部门,一般是 API 的 version。好比在这个例子中是 V1,它也会描述我在操作哪个资源; kind 如果是 pod,在 Metadata 中,就写上这个 Pod 的名字;好比nginx。也会给pod打一些 label,在 Metadata 中,有时候也会去写 annotation,也就是对资源的额外的一些用户层次的描述。
比较重要的一个部门叫 Spec,Spec 也就是希望 Pod 达到的一个预期的状态。好比pod内部需要有哪些 container 被运行;这里是一个name为nginx 的 container,它的 image 是什么?它暴露的 port 是什么?
当从 Kubernetes API 中去获取这个资源的时候,一般在 Spec 下面会有一个status字段 ,它表达了这个资源当前的状态;好比一个 Pod 的状态大概是正在被调度、或者是已经 running、或者是已经被 terminates(被执行完毕)。
Label是一个比较故意思的 metadata,可以是一组KeyValue的聚集。
如下图,第一个 pod 中,label 就大概是一个 color 等于 red,即它的颜色是红颜色。固然也可以加其他 label,好比说 size: big 就是大小,界说为大的,它可以是一组label。
这些 label 是可以被 selector(选择器)所查询的。就好比sql 类型的 select 语句。

通过label,kubernetes 的API层就可以对这些资源进行筛选。
比方,Deployment大概代表一组Pod,是一组Pod 的抽象,一组Pod就是通过label selector来表达的。固然Service对应的一组Pod来对它们进行统一的访问,这个描述也是通过label selector来选取的一组Pod。
四、Depolyment摆设pod操作
屏幕。。。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

三尺非寒

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表