程序员:K8S,火了?它赢在了那里?又能火多久?

Posted Java_xiaoLUO

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了程序员:K8S,火了?它赢在了那里?又能火多久?相关的知识,希望对你有一定的参考价值。

普元云计算架构师宋潇男点评:

Kubernetes 已在容器编排之战中取胜,未来很可能会成为“多云”之上的标准层,进而为分布式系统的分发和运行带来根本性的改变,而其自身则会慢慢变得像 Linux Kernel 一样,成为一种系统底层的支撑,不再引人注目。

为什么会出现k8s?

Kubernetes开源架构的源头来自于Google生产系统中运行的内部集群管理系统Borg。Google将在Borg中的10多年经验在2014年开源出来,开启了Kubernetes热潮的端倪。同年,微软、RedHat、IBM、Docker、CoreOS、Mesosphere和Saltstack等公司相继加入Kubernetes生态圈。次年,VMware、HP、Intel等公司也相继加入。也正是在2015年,随着Kubernetes 1.0正式发布,掀开了容器编排管理一发不可收拾的大幕。 Kubernetes在这场容器编排的大角逐中,从普通选手(当时Docker是容器技术的裁判,而Docker Swarm、Apache Mesos、Google Kubernetes分别是Docker容器编排的选手)逐步变成了领跑选手,进而升级为了裁判(由Kubernetes主导容器编排,而将Docker和CoreOS的Rkt等容器技术纳入容器隔离技术的角逐中),从而在容器届一骑绝尘。

接下来我们重点看看K8S,希望给以参考借鉴!要是觉得还不错,不要吝啬你手里的赞哦!!

什么是k8s?

Kubernetes (通常称为K8s,K8s是将8个字母“ubernete”替换为“8”的缩写) 是用于自动部署、扩展和管理容器化(containerized)应用程序的开源系统。Google设计并捐赠给Cloud Native Computing Foundation(今属Linux基金会)来使用的。

它旨在提供“跨主机集群的自动部署、扩展以及运行应用程序容器的平台”。它支持一系列容器工具, 包括Docker等。CNCF于2017年宣布首批Kubernetes认证服务提供商(KCSPs),包含IBM、MIRANTIS、华为、inwinSTACK迎栈科技等服务商。

k8s能干什么?

Kubernetes可以实现在物理集群或虚拟机集群上调度和运行容器,当然它还可以做得更多。

为了充分发挥容器的优势并将传统的应用部署方式甩开,需要容器的部署与运行独立于基础设施。

然而,当特定的容器不再与特定的主机绑定时,主机为中心的基础设施也不再适用:负载均衡、自动扩展等,因此需要容器为中心的架构,这便是kubernetes所提供的。

Kubernetes满足了应用程序在生产环境中的一些通用需求,例如:

  • 协同定位的辅助进程,利用复杂应用部署,并且还保持了单容器单应用的模型

  • 挂载存储系统

  • 分布式加密管理

  • 应用健康状况检查

  • 应用实例副本

  • 水平自动扩展

  • 命名与发现

  • 负载均衡

  • 滚动升级

  • 资源监控

  • 日志的获取和注入

  • 支持自省和调试以及

  • 认证和授权

上述功能提供了平台即服务(PaaS)的简易性以及基础设施即服务(IaaS)的灵活性,提升了跨基础设施移植的方便性。

集群

在集群管理方面,K8s将集群中的机器划分为一个Master节点和一群工作节点Node。Master节点上运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler。这些进程自动化实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能。

K8S核心

Pod

Pod是K8s最重要也是最基础的概念!每个Pod都有一个特殊的被称为“根容器”的Pause容器,此容器与引入业务无关并且不易死亡。且以它的状态代表整个容器组的状态!Pause容器对应的镜像属于K8s平台的一部分,除了Pause容器,每个Pod还包含一个或多个用户业务容器。Pod其实有两种类型:普通的Pod及静态Pod(static Pod),static Pod并不存放在Kubemetes的eted存储里,而是存放在某个具体的Node上的一个具体文件中,并且只在此Node上启动运行。而普通的Pod一旦被创建,就会被放入到etcd中存储,确后会被KubernetesMaster调度到某个具体的Node上并进行绑定(Binding),随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动起来。在默认情况下,当Pod里的某个容器停止时,Kubemetes会自动检测到这个问题并且重新启动这个Pod(重启Podel)的所有容器),如果Pod所在的Node完机,则会将这个Node上的所有Pod重新调度到其他节点上。Pod(上图绿色方框)安排在节点上,包含一组容器和卷。同一个Pod里的容器共享同一个网络命名空间,可以使用localhost互相通信。

Endpoint(Pod IP + ContainerPort) pod ip:一个Pod里多个容器共享Pod IP地址。K8s要求底层网络支持集群内任意两个Pod之间的TCP/IP直接通信,使用虚拟二层网络技术(Flannel(没有接触过 ),OpenvSwitch)实现。在Vmware中类似的二层交换技术是VSwitch,当然了,现在整个数据中心网络二层逐步从vSwitch—>OpenvSwitch

Lable

Lable类似Docker中的tag,一个是对“特殊”镜像、容器、卷组等各种资源做标记,一个是attach到各种诸如Node、Pod、Server、RC资源对象上。不同的是Lable是一对键值对!Lable类似Tag,可使用K8s专有的标签选择器(Label Selector)进行组合查询。

Controller

Replication Controller,简称RC,她用来干啥呢?就是通过她来实现Pod副本数量的自动控制!RC确保任意时间都有指定数量的Pod“副本”在运行。

如果为某个Pod创建了RC并且指定3个副本,它会创建3个Pod,并且持续监控它们。如果某个Pod不响应,那么Replication Controller会替换它,保持总数为3。如果之前不响应的Pod恢复了,现在就有4个Pod了,那么Replication Controller会将其中一个终止保持总数为3。如果在运行中将副本总数改为5,Replication Controller会立刻启动2个新Pod,保证总数为5。还可以按照这样的方式缩小Pod,这个特性在执行滚动升级时很有用。 注意:删除RC,不会影响该RC已经创建好的Pod。在逻辑上Pod副本和RC是解耦和的!创建RC时,需要指定Pod模板(用来创建Pod副本的模板)和Label(RC需要监控的Pod标签)。 由Replication Controller衍生出Deployment,与RC相似90%,目的是更好地解决Pod编排。暂时不讨论。 Horizontal Pod Autoscaler,简称HPA,Pod横向自动扩容智能控件。与RC,Deployment一样,也属于K8s的一种资源对象。她的实现原理是通过追踪分析RC控制的所有目标Pod的负载变化情况,来确定是否针对性地调整目标Pod的副本数。

Service

微服务架构中的一个“微服务”,她是正真的新娘,而之前的Pod,RC等资源对象其实都是嫁衣。

每个Pod都会被分配一个单独的IP地址,而且每个Pod都提供了一个独立的Endpoint(Pod lP + ContainerPort)以被客户端访问,现在多个Pod副本组成了一个集群来提供服务,客户端要想访问集群,一般的做法是部署一个负载均衡器(软件或硬件),为这组Pod开启一个对外的服务端口如8000端口,并且将这些Pod的Endpoint列表加入8000端口的转发列表中,客户端就可以通过负载均衡器的对外IP地址 + 服务端口来访问此服务,而客户端的请求最后会被转发到哪个Pod,则由负载均衡器的算法所决定。

K8s的server定义了一个服务的访问入口地址,前端(Pod)通过入口地址访问其背后的一组由Pod副本组成的集群实例,service与其后端Pod副本集群之间通过Label Selector 实现“无缝对接”。

可以将Server抽象成特殊的扁平的双向管道,Service借助Label Selector保证了前端容器正确可靠地指向对应的后台容器。 RC的作用保证了Service的服务能力和服务质量始终处于预期的标准。

Kubemetes也遵循了上述常规做法,运行在每个Node上的kube-proxy进程其实就是一个智能的软件负载均衡器,它负责把对Service的请求转发到后端的某个Pod实例上,并在内部实现服务的负载均衡与会话保持机制。但Kubernetes发明了一种很巧妙又影响深远的设计:Service不是共用一个负载均衡器的IP地址,而是每个Service分配了一个全局唯一的虚拟IP地址,这个虚拟IP被称为ClusterIP。这样一来,每个服务就变成了具备唯一IP地址的“通信节点”,服务调用就变成了最基础的TCP网络通信问题。

Pod的Endpoint地址会随着Pod的销毁和重新创建而发生改变,因为新Pod的IP地址与之前旧Pod的不同。而Service一旦创建,Kubemetes就会自动为它分配一个可用的Cluster IP,而且在Service的整个生命周期内,它的ClusterIP不会发生改变。于是,服务发现这个棘手的问题Kubemetes的架构里也得以轻松解决:只要用Service的Name与Service的Cluster IP地址做一个DNS域名映射即可完美解决问题。

K8S架构组件

  Master(主控节点)和node(工作节点)

(1) master组件

Master指的是集群控制节点。每个K8s集群里需要有一个Ms节点负责整个集群的管理和控制。Kubernetes Master提供集群的独特视角,并且拥有一系列组件。

  • Kubernetes API Server(kube-apiserver),侍卫大统领!提供HTTP Rest接口的关键服务进程,是K8s里所有资源的增删改查等操作的唯一入口,也是集群控制的入口进程。API Server提供可以用来和集群交互的Rest端点。

  • Kubernetes Controller Master(kube-controller-manager)掌印大太监,大总管!K8s里所有资源对象的自动化控制中心。

  • Kubernetes Scheduler(kube-scheduler),御马间的调度室!负责资源调度(Pod调度)的进程。创建和复制Pod的Replication Controller。

(2) node组件

节点(上图橘色方框)是物理或者虚拟机器,作为Kubernetes worker,通常称为Minion。每个节点都运行如下Kubernetes关键组件。

(1) Kubelet:与Master节点协作,是主节点的代理,负责Pod对应容器的创建,启动,停止等任务。默认情况下Kubelet会向Master注册自己。Kubelet定期向主机点汇报加入集群的Node的各类信息。 (2) Kube-proxy:Kubernetes Service使用其将链接路由到Pod,作为外部负载均衡器使用,在一定数量的Pod之间均衡流量。比如,对于负载均衡Web流量很有用。 (3) Docker或Rocket:Kubernetes使用的容器技术来创建容器。

为什么要学习k8s?

利用kubernetes,你可以快速高效地响应客户如下请求:

  • 应用程序的动态、精准部署

  • 应用程序的动态扩展

  • 无缝推出新功能

  • 按需优化使用硬件资源

kubernetes是: 便携的:公有云、私有云、混合云、多云 可扩展的:模块化、即插即用、钩子化、组合化 自动修复的:自动布局、自动重启、自动副本、自动伸缩 Kubernetes项目是2014年由Google公司启动的,Kubernetes在Google公司15年生产环境经验基础上,结合了社区的一些优秀点子和实践而构建的。

相信以上的信息也让你们了解了k8s的重要性,k8s在很多的大企业中都在应用,所以我们有必要来学习k8s技术。

记得点赞点赞点赞!!!

以上是关于程序员:K8S,火了?它赢在了那里?又能火多久?的主要内容,如果未能解决你的问题,请参考以下文章

容器技术还能火多久?

SASE究竟还能火多久?

“冰桶”热了半个月 秒拍“假人挑战”能火多久?

讲真,计算机还能火多久?2020届本科,非科班,打算22年考研,害怕三四年以后读研出来计算机不行了

K8S太火了!花10分钟玩转它不香么?

终于意识到BIM确实火了