kubernetes简介

举报
xindoo 发表于 2022/04/16 00:45:39 2022/04/16
【摘要】 声明:本文主要是自Google全球云服务总裁David K. Rensin 《kubernetes》一书中的内容,介绍可能不够详尽,文章也缺乏组织性,先发出来,这个月我会继续完善本文,也欢迎各位指教...

声明:本文主要是自Google全球云服务总裁David K. Rensin 《kubernetes》一书中的内容,介绍可能不够详尽,文章也缺乏组织性,先发出来,这个月我会继续完善本文,也欢迎各位指教。

  kuberbetes在希腊语中是「舵手、领航员」的意思,据我了解k8s算是Google borg的开源版本,正是因为google 15年放出borg的论文和近两年docker的火热,k8s也成为炙手可热的项目,部分云厂商比如Google、MS Azure、AWS甚至直接提供了kubernetes解决方案。
  为了更好理解kubernetes,我们先来看下没有它之前我们是如何管理集群的。
  在容器化之前,业内都是采用物理或者虚机部署,需要人肉处理各种服务异常,所有变更都为人肉操作,你得自己管理一切,包括服务器宕机、扩缩容、应用发布…… 随着服务规模的增长,人工操作也变得不大现实。于是这个时期就诞生了各种集群操作工具,比如chef、puppet、Ansible……,这些工具让集群维护变得稍微简答了点,但任然有局限。
  我大概知道点Ansible,个人感觉这个工具虽然好用,但基本上只适合千百台服务器规模的集群。集群到一定规模后,有资源的厂商可能会自己开发一些集群管理工具,大多数系统的模式是一个系统调用服务器上的agent做一些操作。
  容器的诞生彻底改变了集群发布和运维的方式,因为每次都发布的是同一个image,image又可以直接运行在服务器上,所以不用考虑线上环境一致性的问题。
  但容器的使用又带来一些新的问题,比如虽然它相对于vm更轻量,但并不是一台完整的vm,还需要很多编排系统才能高效可靠的运转,容器资源需要调度,生命周期需要系统管理…… 容器的使用解决了一些问题,但也带来跟多新的问题,这时候就诞生了类似kubernetes的资源调度和管理系统。
  其实kubernetes不仅仅是减轻了线上运维的压力,也能够提升机器资源的利用率,据说borg就为Google节省了10%以上的机器资源,Google目前机器数量超百万,一台服务器几万人民币,算下光机器就节省多少钱,再算下节省多少人力。

kubernetes

应用和服务

  在介绍kubernetes之前,先说下应用和服务的区别,因为kubernetes是以服务(通常是微服务)为维度管理的,了解服务的概念有助于理解后面一些该概念。
  服务有两个明显的特点。

  1. 一个服务只完成很少件事。
  2. 没有用户交互接口,只能通过API调用

  而一个完整的应用,有用户界面(即便只有命令行界面),也通常提供了各种复杂的功能。

Master和node

  粗看,Kubernetes只有两种角色,master和node(或称minion),master负责管理所有的node,node上跑了各种各种的服务。

master

  master上主要有三个模块
  1. API Server 暴露出kubernetes的api,可以被用户或者其他系统操作。
  2. Etcd 一个kv存储系统,kubernetes上所有信息都被存到这。我大概了解了下,etcd可以用来替代zookeeper,相较于zk有多方面的提升,具体可以参考这篇文章etcd介绍
  3. 调度和控制管理 管理调度容器,比如确保每个服务容器数量,坏点自己动替换……

node

  每个node上有三个主要进程
  1. kubelet node上的agent,响应master发来的命令
  2. Proxy 通过ip和servername把请求转发到正确的container上
  3. cAdvisor 非必须,主要是为了收集node上的信息,比如当前运行了哪些container、资源使用率……
  大概架构图如下:
  这里写图片描述

接下来介绍一些kubernetes的关键词及具体概念

pods

  在上图中看到了每个node中有好几个pod,pod中又有一堆container,其实一个pod就是一堆类似功能的container的集合, 这些container通常共享一个ip或者同一个文件系统,但在pod里所有container系统沟通都是通过localhost做的,有点像一台物理机上多个vm直接沟通。这里有很重要一点,kubernetes是在pod级别做管理的,不是container级别。pod里有哪些container都是用户在pod模板里指定的。
  这里写图片描述
  为什么kubernetes要以pod为维度管理而不是container? 我的理解,一个pod是做一组动作,每个动作可能由一个进程完成,你可以把多个进程放到一个container里做,但这可能会带来一些新问题。 比如你除了关注单个进程外,你还要考虑到进程之间的相互调用,这明显维护起来比较复杂了,而且也不便于排查问题。
  单个container只包含单个进程,为什么还需要有pod的概念? 如果一组连续的动作被部署到不同的container,而container又在不同的机器上,这可能意味着着你一连串的请求需要在局域网甚至城域网中游走,相较于机器内部之间调用明显耗时多了。

Volumes

  volume其实是container可以看见和使用的一个虚拟文件系统,和docker的volume很类似,但有所不同。docker中volume和docker container绑定在一起共生死的,但kubernetes中volume是和pod绑定的。同一个pod中的所有container都可以共享volume,其中一个container死了,volume不会消失。 这种方式也使得pod中container文件交互变得很容易。
  kubernetes有各种volume,但最常用的有下面三种

EmptyDir

  这种volume在创建的时候都是初始化为空,同一个pod里的所有container都可以读和写这个volume,该种volume也会随着pod的删除而被删除。

Network File System(NFS)

  网络文件系统,不随pod的删除而被删除,一般用于存储一些日志文件。

GCEPersistenDisk(PD)

  云存储,想存多久存多久。可靠性肯定要比nfs高多了。

上面一些关键词都是kubernetes各个组件相关的概念,接下来介绍和pod管理调度相关的一些概念。

Labels & Annotations

Labels

  这个应该算是kubernetes中比较重要的概念了,因为靠label才能找到你想要的pod。label其实是个键值对,一个label可以表示一个pod,但一个pod可以有多个副本。

Label Selectors

  通过label selector你就可以按一定规则找出相关的pod,现在有两种选取规则。一直是等式规则,比如tier = frontend, 你就可以找出所有label key为tier且value为frontend的pod。
  还有另外一种基于集合的选取规则 关键词 「IN」「NOT IN」,举几个例子。

    environment in (production, qa)
    tier notin (frontend, backend)
    partion
  
 
  • 1
  • 2
  • 3

  第一个例子,返回所有label中key是environment并且value是production或qa的pod。第二个例子,返回所有key是tier且值不是frontend和backend的pod。最后一个例子,返回所有key是partion的pod。

Annotations

  注释,label存储的是确切的信息,annotation存储非确切信息,annotation补不会被kubernetes直接使用,它只是用来注释下这个pod是干嘛的,主要还是给人看的。

Replication Controllers

  如果某个服务流量过大,一个pod无法支撑所有流量,这个时候就需要一个集群共同承担流量了,集群由多个同一pod的副本组成,pod的副本被称为replicas。整个集群的管理由replication controllers来做。比如你在pod.yaml中定义了这个机器有x个pod,replication controller就会保证有正确数量的pod,某个pod死了会自动启一个。
  有个需要注意的地方,replication controller死了后,它所管理的pod并不会被删除。如果你想删除pod,必须把集群的pod数设置为0。

Services

   service是提供用户发现你服务的模块, 其实上面跑着上文中提到的label selector。因为某个pod并不稳定,可能随时新建随时删除,serives出现屏蔽掉了pod变动对服务调用方带来的影响。顺便说一句,service是长期存活的。
   当一个请求过来的时候,他先到proxy service,proxy service通过label selector找到对应的pod,将请求转发过去。如果有多个pod提供同一种服务,proxy service会采用轮询的方式转发请求。

Health Check

  要想保证你的服务可用,你得确保pod是正常运行的,不正常的pod应该被replication controller替换掉。kubernetes提供了以下几种健康检查方式。

低级别的进程检查

  只关注进程在不在,进程不在一定有问题,但进程在一定就没问题吗?

自动应用级别的检查

  kubernetes提供了一些简单的应用检查,来确定你的pod是否正常运行。

TCP端口检查

  测试你端口的连接是否正常,是否有超时的情况

HTTP GET

  pod提供一个http接口做监控检查。接口直接实现,只需要返回一些状态码来标识pod是否健康即可。

container exec

  如果你的pod没有提供http服务,但可能tcp socket监控不够, 你可以配置一些周期性的container命令来检查pod是否正常。

文章来源: xindoo.blog.csdn.net,作者:xindoo,版权归原作者所有,如需转载,请联系作者。

原文链接:xindoo.blog.csdn.net/article/details/71250430

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。