kubernetes 1.12 从零开始(四): 必须先讲一下基本概念

Tags: 视频教程  kubernetes 

目录

说明

本系列所有文章可以在系列教程汇总中找到,演示和讲解视频位于网易云课堂·IT技术快速入门学院 课程说明资料QQ交流群Kubernetes1.12从零开始(初):课程介绍与官方文档汇总,探索过程遇到的问题记录在:Kubernetes1.12从零开始(一):遇到的问题与解决方法

如果是生产环境,选择kubernetes版本的时候,一定要小心斟酌,别选太新的版本,选择上一个,或者上上个稳定版本。 我这里是在做教程,就“择新不择旧”了,哪个版本新用哪个,让时效性尽量好一点。

先介绍一下kubernetes中的一些基本概念,不然后面容易感觉云里雾里。

借花献佛,多参考官方文档:kubernetes Concepts

Kubernetes的组成

kubernetes Components可以按照Master和Node进行划分。Master就是kubernetes的管理节点,它是kubernetes的大脑,是调度中心,Node是kubernetes的任务节点,提供计算资源,承担运行容器的工作。这是一种很经典的设计方式。

Master组件包括:

etcd
kube-apiserver
kube-scheduler
kube-controller-manager
cloud-controller-manager

Node组件包括:

kubelet
kube-proxy
Container Runtime

etcd用来做什么的,为什么选择它?

etcd是用来存放数据并通知变动的。

Kubernetes中没有用到数据库,它把关键数据都存放在etcd中,这使kubernetes的整体结构变得非常简单。

因为在kubernetes中,数据是随时发生变化的,比如说用户提交了新任务、增加了新的Node、Node宕机了、容器死掉了等等,都会触发状态数据的变更。状态数据变更之后呢,Master上的kube-scheduler和kube-controller-manager,就会重新安排工作,它们的工作安排结果也是数据。这些变化,都需要及时地通知给每一个组件。

etcd有一个特别好用的特性,可以调用它的api监听其中的数据,一旦数据发生变化了,就会收到通知。有了这个特性之后,kubernetes中的每个组件只需要监听etcd中数据,就可以知道自己应该做什么。kube-scheduler和kube-controller-manager呢,也只需要把最新的工作安排写入到etcd中就可以了,不用自己费心去逐个通知了。

试想一下,如果没有etcd,那么要怎样做?这里的本质是:数据的传递有两种方式,一种是消息的方式,比如说NodeA有了新的任务,Master直接给NodeA发一个消息,中间不经过任何人;一种是轮询的方式,大家都把数据写到同一个地方,每个人自觉地盯着看,及时发现变化。前者演化出rabbitmq这样的消息队列系统,后者演化出一些有订阅功能的分布式系统。

第一种方式的问题是,所有要通信的组件之间都要建立长连接,并且要处理各种异常情况,比例如连接断开、数据发送失败等。不过有了消息队列(message queue)这样的中间件之后,问题就简单多了,组件都和mq建立连接即可,将各种异常情况都在mq中处理。

那么为什么kubernetes没有选用mq而是选用etcd呢?mq和etcd是本质上完全不同的系统,mq的作用消息传递,不储存数据(消息积压不算储存,因为没有查询的功能),etcd是个分布式存储(它的设计目标是分布式锁,顺带有了存储功能),是一个带有订阅功能的key-value存储。如果使用mq,那么还需要引入数据库,在数据库中存放状态数据。

选择etcd还有一个好处,etcd使用raft协议实现一致性,它是一个分布式锁,可以用来做选举。如果在kubernetes中部署了多个kube-schdeuler,那么同一时刻只能有一个kube-scheduler在工作,否则各自安排各自的工作,就乱套了。怎样保证只有一个kube-schduler在工作呢?通过etcd选举出一个leader。

关于分布式锁和etcd可以参阅Google的论文:The Chubby lock service for loosely-coupled distributed systems

需要注意,虽然etcd可以存储数据,但不要滥用,它运行raft协议保证整个系统中数据一致,因此写入、读取速度都是很慢的。kubernetes早期支持的Node数量有限,就是因为etcd是瓶颈。etcd主要在一些分布式系统中提供选举功能。

别看kubernetes现在可以支撑的集群规模很大,但是它产生的请求数,要比一些大型网站面临的请求数,少很多个很多数量级。那里是mysql、memcache、redis的地盘。

Kube-apiserver,kube-scheduler、kube-controller-manager、cloud-controller-manager

前面讲,每个组件只需要和etcd通信就可以及时获得通知了。但实际上,每个组件不是直接和etcd通信的,它们都是和kube-apiserver通信,然后kube-apiserver再和etcd通信。这就是kube-apiserver的作用。在组件与etcd中间加上了这一层,可以实现访问控制等,并且在一定程度上与etcd解耦。

Kube-scheduler是调度器,是安排容器的去处的,就是为每个容器找到一个合适的Node。

Kube-controller-manager是管理器,是用来管理kubernetes中的任务的,保证每个任务处于正确的状态。这个现在可能不好理解,后面看到Deployment、Daemonset等kubernetes中的概念就知道了。

cloud-controller-manager使用来打通IaaS的,在云上部署kubernetes的时候用到,可以自动增减Node之类的。这个我还没用过(2018-10-06 23:19:56)。

Kubelet、kube-proxy、Container Runtime

在上一节kubelet的用途中已经介绍过kubelet的作用,这里不赘述了。记住它就是node上的agent就可以了。

Kube-proxy需要说一下,它是用来在node上设置报文转发策略、通行策略的,也就是iptables规则。额,这个现在也只能说到这,这属于网络方面的SDN领域,一时半会儿说不清楚。

Container Runtime,不要被这个词唬住了,在实际使用中,一般就是Docker。但是概念还是要掰扯清楚的,kubernetes不是离开Docker不能运转的,因为它实现了自己的agent——kubelet,docker对它来说只是kubelet管理的一个组件。哪天kubelet不开心,它完全可以把docker踢掉,换成别的组件,有kubelet屏蔽底层的差异,上层感觉不到变化一切照旧。

后来kubelet还真的不开心了,折腾出一个叫做Container Runtime的。其实就是kubelet定义了一个叫做CRI的接口,任何实现了CRI接口的软件,都可以和kubelet对接。只要符合标准就可以和kubelet玩耍。这样一来,docker不过是众多符合标准的软件中的一个。

出现这种情况,一是架构设计上有“解耦”的需要,另外也有商业的因素。当时Docker公司表现出很强烈的自成一派的倾向,想要通过把持docker从头吃到尾,包揽所有组件,引发了不少抗议。

虽然Docker最终落败,kubernetes奠定了江湖地位,也搞出了CRI。但是,现在主流还是用docker,以后或许会变。

以插件(Addon)形式存在的组件

上述的几个组件搭起了kubernetes的总体框架,仅靠上面的几个组件,就可以把kubernetes搭起来,但是不能用! 因为上述的几个组件解决了管理、调度、执行这三个最基本、最基本的工作,它们真的只完成了这三个工作。

只这样是不行的,部署在kubernetes中的容器,怎样被访问,容器与容器之间怎样通信?还有日志监控等等,都是必须有的功能。

Kubernetes在设计上高屋建瓴,把这些统统归结到插件(Addon)中了。这样一解耦,其它公司、团队,就可以撒着欢地设计自己的插件了,多样的插件带来了多种可能。譬如说,单单官方收录的网络插件就有六七种。

通过插件化设计,kubernetes团队就可以专心做管理、调度、执行三个工作,分工明确,更新有序。

而且插件可以直接部署在kubernetes中,这样一来插件的管理也变得非常方便。在第五篇“手动部署”中我们会陆续接触到一些核心插件。

Kubernetes中任务(Workload)

我们把提交到kubernetes中的任务统一称为Workload,任务分位两大类:PodController

Pod好理解,它就是一组不可分离的容器。

注意: 虽然前面的章节中我们总是提起的是容器,但kubernetes中任务的最小单位其实是Pod,之前因为还没有介绍Pod,所以都用容器指代。

Kubernetes中任务的最小单位是Pod,Pod可以是一个容器或者多个容器。如果是多个容器,这些容器都是紧密结合在一起的,它们不仅要位于相同的Node上,并且拥有相同的IP地址,甚至于进程空间。

Pod是比容器更高一层的概念。增加了这一层,自然是为了增加灵活性。如果一个Pod中只能有一个容器,那么一个功能复杂一点的Pod,就需要在这个容器中同时运行几种不同类型的服务。Pod支持多容器,就可以把这些任务拆解到不同的容器中。

对于Pod,需要特别关注的是Pod的生命周期, 甚至可以在不同阶段挂载钩子Attach Handlers to Container Lifecycle Events, 我把和Pod相关的文档,都收集在了Pod和Container操作中。

Controller是比Pod更高一层的概念。Controller是由一组Pod组成的,这一组Pod是可以分布在不同的Node上。Pod虽然支持多个容器,但是它的定位还是单一任务,不支持无法跨Node分布容器。跨Node分布任务的重任,分派给了Controller,Pod安心关注内部的容器就可以了。

怎样跨Node分布Pod?这是最容易出“花活儿”的地方,事实也确实如此,现在kubernetes支持的Controller有以下几种:

ReplicaSet,确保始终有固定数量的Pod在运行;

Deployment,比ReplicaSet更高一层,用来定义Pod或者ReplicaSet;

StatefulSet,确保始终有固定数量的Pod在运行,并且保证这些Pod是严格按照顺序启动的;

DaemonSet,确保每个Node上都有指定的Pod在运行;

Jobs,一批运行结束即退出的“非常驻”Pod;

CronJob,定时在kubernetes中启动的一批Pod。

还是建议直接阅读官方文档,上面的超连接连接到了对应文档页。这部分官方文档写的很好,比较容易理解。

Kubernetes中的配置(Configuration)

注意,这里指定的是kubernetes的配置,不是kubernetes的配置。

一个软件系统其实就是由两部分组成的:程序文件和配置文件。前一小节我们简单介绍了kubernetes中的任务,那么这些任务使用的配置要如何管理?

最傻最直接的方式就是把配置文件和程序文件打包在一起,比如说全打包到容器中。但这样显然是不好的,程序文件就是程序文件,配置文件就是配置文件。 最好将两者严格分开,这样很多用户可以共用相同的程序文件,维护各自不同的配置文件。升级的时候,也可以很好地保护原先的配置。

在kubernetes中部署任务的时候,最好这样规划:

容器的镜像就是纯粹的程序文件,运行时需要的配置用其它方式获得。

配置怎样获得呢?kubernetes支持这样几种方式:

在提交任务的时候,指定命令行参数、或者环境变量,见数据注入应用的方法;

将配置保存在ConfigMap中,提交任务的时候挂载ConfigMap,见Configure a Pod to Use a ConfigMap;

一些敏感配置,比如账号密码等,最好做成Secrets,提交任务的时候挂载它,见Secret;

如果你的配置文件是由kubernetes外部的系统管理的,可以考虑使用Init Containers,在Pod正式启动前,准备好配置。

这样几种方式,基本上能应对各种情况了。

Kubernetes的存储与网络

前面已经介绍了“任务”和“配置”,解决了“计算”方面的问题。那么“存储”和“网络”方面是怎样的呢?

先说存储,kubernetes支持很多类型的Volume,如下:

awsElasticBlockStore
azureDisk
azureFile
cephfs
configMap
csi
downwardAPI
emptyDir
fc (fibre channel)
flocker
gcePersistentDisk
gitRepo (deprecated)
glusterfs
hostPath
iscsi
local
nfs
persistentVolumeClaim
projected
portworxVolume
quobyte
rbd
scaleIO
secret
storageos
vsphereVolume

注意,这里的“支持”是说,kubernetes可以将这些类型的存储挂载到容器中,而不是说它提供了这些存储系统。计算、存储、网络,是基础设施的三大块内容,kubernetes只做计算这块。

你可以把这些存储系统,比如说Ceph等,部署在kubernetes外部,或者部署在kubernetes中(这样是可以的,存储系统也是一堆运行的任务),对kubernetes来说没有什么区别,都是一个外部的服务。

不过存储系统是应该单独部署,还是和其它业务容器混部在kubernetes中,可一定要仔细想清楚了,要防止某个组件崩溃,导致一系列系统崩溃。更要小心,别出现你依赖我,我依赖你的死循环。

“网络”方面的内容有两个: 一个是基础网络是怎样的,也就是Pod之间的网络通信是怎样进行的,这个依靠网络插件实现;一个是部署在kubernetes中的任务怎样被访问到?这里的访问又 分为从kubernetes内部访问,和从kubernetes外部访问。

Kubernetes中用Service描述要暴露的服务,而后借助DNSIngress等,实现了服务的内部暴露和外部暴露。

其它

Kubernetes发展至今,已经成了一个相当庞大、复杂的系统。我们上面介绍的都是最基本的内容,在这些内容之外,还有kubernetes的功能拓展,以及联邦集群等内容。

围绕kubernetes发展的系统也有很多,除了多次提到的网络插件,在日志采集、监控告警方面,还有fluentd、filebeat、prometheus等等。

这些内容,以后择机介绍。

参考

  1. kubernetes1.12从零开始(三):用minikube与kubeadm部署
  2. kubernetes Concepts
  3. kubernetes Components
  4. The Chubby lock service for loosely-coupled distributed systems
  5. Installing a pod network add-on

kubernetes

  1. kubernetes 使用:多可用区、Pod 部署拓扑与 Topology Aware Routing
  2. kubernetes 扩展:Cloud Controller Manager
  3. kubernetes 准入:操作合法性检查(Admission Control)
  4. kubernetes 鉴权:用户操作权限鉴定(Authorization)
  5. kubernetes 认证:用户管理与身份认证(Authenticating)
  6. kubernetes 开发:代码生成工具
  7. kubernetes 扩展:operator 开发
  8. kubernetes 扩展:CRD 的使用方法
  9. kubernetes configmap 热加载,inotifywatch 监测文件触发热更新
  10. kubernetes 扩展:扩展点和方法(api/cr/plugin...)
  11. kubernetes 调度组件 kube-scheduler 1.16.3 源代码阅读指引
  12. kubernetes 代码中的 k8s.io 是怎么回事?
  13. 阅读笔记《不一样的 双11 技术,阿里巴巴经济体云原生实践》
  14. kubernetes ingress-nginx 启用 upstream 长连接,需要注意,否则容易 502
  15. ingress-nginx 的限速功能在 nginx.conf 中的对应配置
  16. kubernetes 中的容器设置透明代理,自动在 HTTP 请求头中注入 Pod 信息
  17. kubernetes ingress-nginx 的测试代码(单元测试+e2e测试)
  18. kubernetes ingress-nginx http 请求复制功能与 nginx mirror 的行为差异
  19. kubernetes 基于 openresty 的 ingress-nginx 的状态和配置查询
  20. kubernetes ingress-nginx 0.25 源代码走读笔记
  21. kubernetes ingress-nginx 的金丝雀(canary)/灰度发布功能的使用方法
  22. kubernetes 操作命令 kubectl 在 shell 中的自动补全配置
  23. kubernetes 组件 kube-proxy 的 IPVS 功能的使用
  24. kubernetes initializer 功能的使用方法: 在 Pod 等 Resource 落地前进行修改
  25. kubernetes 版本特性: 新特性支持版本和组件兼容版本
  26. kubernetes API 与 Operator: 不为人知的开发者战争(完整篇)
  27. kubernetes 1.12 从零开始(七): kubernetes开发资源
  28. kubernetes 1.12 从零开始(六): 从代码编译到自动部署
  29. kubernetes 网络方案 Flannel 的学习笔记
  30. kubernetes 1.12 从零开始(五): 自己动手部署 kubernetes
  31. kubernetes 1.12 从零开始(四): 必须先讲一下基本概念
  32. kubernetes 1.12 从零开始(三): 用 kubeadm 部署多节点集群
  33. kubernetes 1.12 从零开始(二): 用 minikube 部署开发测试环境
  34. kubernetes 1.12 从零开始(一): 部署环境准备
  35. kubernetes 1.12 从零开始(零): 遇到的问题与解决方法
  36. kubernetes 1.12 从零开始(初): 课程介绍与官方文档汇总
  37. kubernetes 集群状态监控:通过 grafana 和 prometheus
  38. 一些比较有意思的Kubernetes周边产品
  39. Borg论文阅读笔记
  40. kubelet下载pod镜像时,docker口令文件的查找顺序
  41. kubernetes 的 Client Libraries 的使用
  42. kubernetes的网络隔离networkpolicy
  43. kube-router的源码走读
  44. kubernetes 跨网段通信: 通过 calico 的 ipip 模式
  45. kubernetes的调试方法
  46. kubernetes 与 calico 的衔接过程
  47. 怎样理解 kubernetes 以及微服务?
  48. kubernetes中部署有状态的复杂分布式系统
  49. kubernetes的apiserver的启动过程
  50. kubernetes的api定义与装载
  51. kubernetes的federation部署,跨区Service
  52. kubernetes的编译、打包、发布
  53. kubernetes的第三方包的使用
  54. kubernetes的Storage的实现
  55. kubernetes 的 Apiserver 的 storage 使用
  56. kubernetes的Controller-manager的工作过程
  57. kubernetes的Client端Cache
  58. kubernetes 的 Apiserver 的工作过程
  59. kubernetes的CNI插件初始化与Pod网络设置
  60. kubernetes的Pod变更过程
  61. kubernetes的kubelet的工作过程
  62. kuberntes 的 Cmdline 实现
  63. kubernetes的Pod内挂载的Service Account的使用方法
  64. kubernetes的社区资源与项目参与方式
  65. kubernetes的Kube-proxy的转发规则分析
  66. kubernetes的基本操作
  67. kubernetes在CentOS上的集群部署
  68. kubernetes在CentOS上的All In One部署
  69. 怎样选择集群管理系统?

视频教程

  1. kubernetes 1.12 从零开始(七): kubernetes开发资源
  2. kubernetes 1.12 从零开始(六): 从代码编译到自动部署
  3. kubernetes 1.12 从零开始(五): 自己动手部署 kubernetes
  4. kubernetes 1.12 从零开始(四): 必须先讲一下基本概念
  5. kubernetes 1.12 从零开始(三): 用 kubeadm 部署多节点集群
  6. kubernetes 1.12 从零开始(二): 用 minikube 部署开发测试环境
  7. kubernetes 1.12 从零开始(一): 部署环境准备
  8. kubernetes 1.12 从零开始(零): 遇到的问题与解决方法
  9. kubernetes 1.12 从零开始(初): 课程介绍与官方文档汇总
  10. 【视频】新型监控告警工具prometheus(普罗米修斯)入门使用(附视频讲解)
  11. 【视频】超级账本HyperLedger: Fabric Go SDK的使用
  12. 【视频】超级账本HyperLedger: Fabric使用kafka进行区块排序(共识)
  13. 【视频】超级账本HyperLedger: 为Fabric的Peer节点配置CouchDB
  14. 【视频】超级账本HyperLedger: Fabric从1.1.0升级到1.2.0
  15. 【视频】超级账本HyperLedger: 使用Ansible进行Fabric多节点分布式部署(实战)
  16. 【视频】超级账本HyperLedger: Fabric进阶,在已有的Channel中添加新的组织
  17. 【视频】超级账本HyperLedger: Fabric-CA的使用演示(两个组织一个Orderer三个Peer)
  18. 【视频】超级账本HyperLedger: Fabric的全手动、多服务器部署教程
  19. 【视频】超级账本HyperLedger: Fabric nodejs SDK的使用
  20. 超级账本HyperLedger: Fabric部署过程时遇到的问题汇总
  21. 【视频】8元小课之自动化运维工具ansible(二): 文档阅读摘要
  22. 【视频】8元小课之自动化运维工具ansible(一): 使用入门

推荐阅读

Copyright @2011-2019 All rights reserved. 转载请添加原文连接,合作请加微信lijiaocn或者发送邮件: [email protected],备注网站合作

友情链接:  李佶澳的博客  系统软件  程序语言  运营经验  关注方向  水库文集  网文收藏  网络课程  发现知识星球  百度搜索 谷歌搜索