kubernetes 核心概念

1 kubernetes核心概念

1.1 Pod

Pod是可以在Kubernetes中创建和管理的、最小的可部署的计算单元

Pod就像豌豆荚一样,其中包含着一组(一个或多个)容器;这些容器共享存储、网络、以及怎样运行这些容器的声明。

Pod就像一台物理服务器一样,其中包含一个或多个应用容器,这些容器中运行着用户应用程序。

举例说明Pod、Container、应用程序三者之间的关系:麻屋子,红帐子,里面住着白胖子。Pod就是麻屋子,Container就是红帐子,应用程序就是里面的白胖子。

1.2 Controller

在Kubernetes中,用于管理和运行Pod的对象

在Kubernetes中,控制器通过监控集群的公共状态,并致力于将当前状态转变为期望的状态

举例说明Controller(控制器)作用:房间里的温度自动调节器

当你设置了温度,告诉了温度自动调节器你的期望状态(DesiredState)。房间的实际温度是当前状态(CurrentState)。通过对设备的开关控制,温度自动调节器让其当前状态接近期望状态。

一个控制器至少追踪一种类型的Kubernetes资源。这些对象有一个代表期望状态的spec字段。该资源的控制器负责确保其当前状态接近期望状态。不同的类型的控制器所实现的控制方式不一样,例如:

Deployment

  • 部署无状态应用。
  • 部署无状态应用:认为pod都一样,没有顺序要求,不用考虑在哪个node运行,随意进行扩展和伸缩。
  • 管理Pod和 ReplicaSet
  • 部署、滚动升级等。
  • 典型的像web服务、分布式服务等

StatefulSet

  • 部署有状态应用
  • 有状态应用,每个pod都独立运行,保持pod启动顺序和唯一性;有唯一的网络标识符,持久存储;有序,比如mysql主从;主机名称固定。而且其扩容以及升级等操作也是按顺序进行的操作。

DaemonSet

  • 部署守护进程
  • DaemonSet保证在每个Node上都运行一个容器副本,常用来部署一些集群的日志、监控或者其他系统管理应用。新加入的node也同样运行在一个pod里面。

job

  • 一次性任务。
  • Job负责批量处理短暂的一次性任务(shortlivedone-offtasks),即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束。

Cronjob

  • 周期性定时任务。数据库备份。

1.3 Label

Label是附着到object上(例如Pod)的键值对。可以在创建object的时候指定,也可以在object创建后随时指定。Labels的值对系统本身并没有什么含义,只是对用户才有意义。

一个Label是一个key=value的键值对,其中key与value由用户自己指定。

Label可以附加到各种资源对象上,例如Node、Pod、Service、RC等,一个资源对象可以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象上去,Label通常在资源对象定义时确定,也可以在对象创建后动态添加或者删除。

我们可以通过指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能,以便于灵活、方便地进行资源分配、调度、配置、部署等管理工作。例如:部署不同版本的应用到不同的环境中;或者监控和分析应用(日志记录、监控、告警)等。

Label相当于我们熟悉的“标签",给某个资源对象定义一个Label,就相当于给它打了一个标签,随后可以通过LabelSelector(标签选择器)查询和筛选拥有某些Label的资源对象,Kubernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制。

1.4 Label Selector

通过label selector,客户端/用户可以指定一个object集合,通过label selector对object的集合进行操作。

Labelselector有两种类型:

  • equality-based(基于等式):可以使用=、==、I=操作符,可以使用逗号分隔多个表达式
  • set-based(基于集合):可以使用in、notin、!操作符,另外还可以没有操作符,直接写出某个label的key,表示过滤有某个key的object而不管该key的value是何值,!表示没有该label的object

当我们给一组对象,比如有10个pod,打上了不同的标签之后,当我们要选择其中的部分,或者全部作为使用目标的时候,就可以使用label selector来实现这个操作,标签选择器中指定具体的过滤的条件,然后,就能在10个pod中过滤出满足我们要求的这些pod。

1.5 Service

将运行在一组Pods上的应用程序公开为网络服务的抽象方法。

由于Pod是非永久性资源对象,如果你使用Controller运行你的应用程序,你可以动态创建和销毁Pod,这样就会导致无法准确访问到所想要访问的Pod

例如:如果一组Pod(称为"后端")为集群内的其他Pod(称为"前端")提供功能,那么前端如何找出并跟踪要连接的IP地址,以便前端可以使用提供工作负载的后端部分?

是一组iptables或ipvs规划,通过把客户端的请求转发到服务端(Pod),如有多个Pod情况,亦可实现负载均衡的效果。

例如:一个图片处理后端,它运行了3个副本(Pod)。这些副本是可互换的一一前端不需要关心它们调用了哪个后端副本。然而组成这一组后端程序的Pod实际上可能会发生变化,前端客户端不应该也没必要知道,而且也不需要跟踪这一组后端的状态。

1.6 Endpoints

为Service管理后端Pod,当后端Pod被创建或销毁时,endpoints列表会更新Pod对应的iP地址,以便Service访问请求能够确保被响应。

1.7 DNS

为kubernetes集群内资源对象的访问提供名称解析,这样就可以实现通过DNS名称而非IP地址来访问服务。

  • 实现集群内Service名称解析
  • 实现集群内Pod内Container中应用访问互联网提供域名解析

2 kubernetes核心概念之间关系

2.1 pod与controller

Controller通过API Server与Kubernetes集群通信,监控Pod的状态,并根据需要进行调整。这种设计使得Kubernetes能够提供高可用性和弹性伸缩的能力。

pod是通过Controller实现应用的运维,比如伸缩,滚动升级等待。pod和controller通过label标签建立关系。

2.2 pod与service

service是为了防止pod失联,提供的服务发现,类似于微服务的注册中心。定义一组pod的访问策略。可以为一组具有相同功能的容器应用提供一个统一的入口地址,并将请求负载分发到后端的各个容器应用上。

service通过selector来管控对应的pod。根据label和selector建立关联,通过service实现pod的负载均衡。

3 基于kubernetes集群容器化应用的微服务

3.1 服务部署方式介绍

单体服务架构

  • 所有服务进程运行在同一台主机内。

分布式服务架构

  • 服务进程分布于不同的主机,其中一台主机出现故障,不影响其它主机上的服务运行。

微服务架构

  • 使用容器化技术把分布式服务架构运行起来,并实现对不同的服务进程的高可用及快速发布等。

3.2 服务组件之间的关系

service -> container -> service -> container

pod出现故障,controller重新把pod拉起,pod 的 ip地址发生变化,service通过label标签寻找到相对应的pod,将pod信息添加到endpoint上,对pod发起请求时仍旧可以连接到。

  • 24
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值