文章目录

kubernetes基础理论

k8s全称kubernetes,k8s是为容器服务而生的一个可移植容器的编排管理工具
​​​【kubernetes官网】​

一、kunernetes发展史

#kunernetes发展史
Kubernetes项目来源于Borg,可以说是集结了Borg设计思想的精华,并且吸收了Borg系统中的经验和教训。

Kubernetes作为容器集群管理工具,于2015年7月22日迭代到 v 1.0并正式对外公布,这意味着这个开源容器编排系统可以正式在生产环境使用

Kubernetes总体而言可以认为是Borg的一个开源的版本,但是Kubernetes和Borg有一些不一样





#Kubernetes与Borg的不同:

二、kunernetes概述

1>Kubernetes 是 Google 在 2014 年开源的一个容器集群管理系统,使用 Go 开发,简称为 K8s,用于容器化应用程序的部署,扩展和管理

2>Kubernetes 的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制

3>Kubernetes 提供了容器编排(yml),资源调度,弹性伸缩,部署管理,服务发现等一系列功能,目标是让部署容器化应用简单高效

4>Kubernetes 兼容多种容器类型,市场占用率最高

三、kubernetes的特性(优点)

自我修复
弹性伸缩扩容
服务发现与调度
负载均衡
横向扩容
存储卷挂载

1#自我修复: 
在节点故障时替换和重新部署,保证预期的副本数量;杀死健康检查失败的容器(探针),并且在未准备好之前不会处理客户端请求,确保线上服务不中断

2#弹性伸缩:
使用命令(字符界面)或 UI(图形化界面),基于 CPU 使用情况自动快速扩容和缩容应用程序实例,保证应用业务高峰并发时的高可用性;业务低峰时回收资源,以最小成本运行服务

3#自动部署和回滚:
K8s 采用滚动更新策略更新应用,一次更新一个 Pod,而不是同时删除所有 Pod,如果更新过程中出现问题,将回滚更改,确保升级不受影响业务

4#服务发现和负载均衡:
K8s 为多个容器提供一个统访问入口(内部 IP 地址和一个 DNS 名称),并且负载均衡关联的所有容器,使得用户无需考虑容器 IP 问题

5#机密和配置管理:
管理机密数据和应用程序配置,而不需要把敏感数据暴露在镜像里,提高敏感数据安全性;并可以将一些常用的配置存储在 K8s 中,方便应用程序使用(身份验证:命名空间,逻辑划分权限管理)

6#存储编排:
挂载外部存储系统,无论是来自本地存储,公有云(如 AWS),还是网络存储(如NFS、GlusterFS、Ceph)都作为集群资源的一部分使用, 极大提高存储使用灵活性

7#批处理:

四、kubnetes使用扩展(业务升级)

1#灰度发布(金丝雀):
指在黑与白之间,能够平滑过渡的一种发布方式,灰度发布可以有效保证整体系统的稳定,降低产品升级所影响的用户范围,从小面到大面使用,分别测试

例如:让一部分用户继续使用产品特性A,一部分用户开始用产品特性B,如果用户对B没有什么反对意见,那么逐渐扩大范围,把所有用户都迁移到B上面来




2#蓝绿发布:
例如:项目逻辑上分为A/B组,首先把A组从负载均衡中摘除,进行新版本部署,B组继续提供服务,当A组升级完毕,负载均衡重新接入A组,再将B组从负载列表中摘除进行新版本部署,A组重新提供服务

最终,B组完成升级,负载均衡重新接入B组,至此,A/B组皆升级完毕,对外提供服务,达到用户无感知、平滑过渡的效果



3#滚动发布:

五、kubernetes的集群架构及组件

kubernetes集群由Master节点+Node(Worker)节点组成
集群架构图

@kubernetes(k8s)基础理论知识_k8s cri

【Master节点】

Master节点指的是集群控制节点,管理和控制整个集群,基本上k8s的所有控制命令都发给它,它负责具体的执行过程

master节点的主要有:
🎁​​​Kube-apiserver​​​:
🎁​​​Kube-controller-manager​​​:
🎁​​​kube-scheduler​​​:
🎁​​​etcd​​​:
🎁cloud-controller-manager

1#Kube-apiserver:(提供Kubernetes API 服务的组件)
Kubernetes API,集群的统一入口, 各组件协调者
以 RESTful API提供接口服务(支持网站标准协议)
所有对象资源的增删改查和监听操作都交给 APIServer 处理后再提交给 Etcd 存储数据




2#Kube-controller-manager: (处理集群中常规后台任务)
一个资源对应一个控制器,比如容器资源(pod)挂了,若控制器还存活,则会重新创建该资源,所以修复能力依赖于控制完成
controllerManager 负责管理这些控制器,控制器包括:
1> 节点控制器(Node Controller): 负责在节点出现故障时进行通知和响应。
2>副本控制器(Replication Controller): 负责为系统中的每个副本控制器对象维护正确数量的 Pod。
3>端点控制器(Endpoints Controller): 填充端点(Endpoints)对象(即加入 Service 与 Pod)。
4>服务帐户和令牌控制器(Service Account & Token Controllers): 为新的命名空间创建默认帐户和 API 访问令牌.





3#kube-scheduler:
根据调度算法为新创建的 Pod 选择一个 Node 节点,可以任意部署可以部署在同一个节点上,也可以部署在不同的节点上
所有资源的创建不一定都要经过调度器




4#etcd:
分布式键值存储系统
用于保存集群状态数据
比如 :Pod、Service 等对象信息




5#cloud-controller-manager(云控制器管理器)
cloud-controller-manager 运行与基础云提供商交互的控制器,cloud-controller-manager 二进制文件是 Kubernetes 1.6 版本中引入的 alpha 功能
cloud-controller-manager 仅运行云提供商特定的控制器循环
cloud-controller-manager 允许云供应商的代码和 Kubernetes 代码彼此独立地发展
控制器具有云提供商依赖性,如下:
1>节点控制器(Node Controller): 用于检查云提供商以确定节点是否在云中停止响应后被删除
2>路由控制器(Route Controller): 用于在底层云基础架构中设置路由
3>服务控制器(Service Controller): 用于创建、更新和删除云提供商负载均衡器
4>数据卷控制器(Volume Controller): 用于创建、附加和装载卷、并与云提供商进行交互以编排卷

【node节点】

node节点指定是集群中的Worker,除了master以外的节点被称为Node或者Worker节点,可以在master中使用命令 kubectl get nodes查看集群中的node节点。
每个Node都会被Master分配一些工作负载(Docker容器),当某个Node宕机时,该节点上的工作负载就会被Master自动转移到其它节点上

node节点的主要有:
🎁kubelet:
🎁kube-proxy
🎁docker 或 rocket(容器类型)

1#kubelet:
kubelet 是 Master 在 Node 节点上的 Agent(代理),管理本机运行容器的生命周期,比如创建容器、Pod 挂载数据卷、下载 secret、获取容器和节点状态等工作,kubelet 将每个 Pod 转换成一组容器
kubelet是Node节点上最重要的核心组件,负责Kubernetes集群具体的计算任务,具体功能包括:
1>监听Scheduler组件的任务分配
2>挂载POD所需Volume
3>下载POD所需Secrets
4>通过与docker daemon的交互运行docker容器
5>定期执行容器健康检查
6>监控、报告POD状态到kube-controller-manager组件
7>监控、报告Node状态到kube-controller-manager组件





2#kube-proxy:
在 Node 节点上实现 Pod 网络代理
维护节点上的网络规则和四层负载均衡工作,这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信





3》Addons(插件)
插件使用 Kubernetes 资源 (DaemonSet, Deployment等) 实现集群功能。因为这些提供集群级别的功能,所以插件的命名空间资源属于 kube-system 命名空间





4#docker 或 rocket(容器类型):

六、kubernetes核心概念

@kubernetes(k8s)基础理论知识_kubernetes_02

【名词解释】

【api server】: 所有服务访问统一入口,各组件协调者,以RESTful API提供接口服务,所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。

【controller manager】: 维持副本期望数目,处理集群中常规后台任务,一个资源对应一个控制器,而ControllerManager就是负责管理这些控制器的。

【schedule】: 负责介绍任务,选择合适的节点进行分配任务。根据调度算法为新创建的Pod选择一个Node节点,可以任意部署,可以部署在同一个节点上,也可以部署在不同的节点上

【ectd】: google公司使用go语言开发的键值对数据库,存储k8s集群所有重要信息(需要持久化的),比如Pod、Service等对象信息

【kubelet】: 直接跟容器引擎(如docker)交互,实现容器的生命周期管理。是Master在Node节点上的Agent,管理本机运行容器的生命周期,比如创建容器、Pod挂载数据卷、下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器

【kube-proxy】:在Node节点上实现Pod网络代理,维护网络规则和四层负载均衡工作。写入规则至iptables、IPVS实现服务映射访问。kube-proxy支持三种模式,在v1.8之前我们使用的是iptables 以及userspace两种模式,在kubernetes 1.8之后引入了ipvs模式

【CoreDNS】: 可以为集群中的SVC(service简写)创建一个域名IP的对应关系解析

【Dashboard】: 给k8s集群提供一个B/S结构的访问体系

【Ingress Controller】: 官方ks8集群只能实现四层代理,它可以实现七层管理(根据域名进行负责均衡)

【Federation】: 提供一个跨集群中心多k8s的统一管理功能

【Prometheus】: 提供k8s集群的监控能力

【ELK】: 提供k8s集群日志统一分析平台

【RC(ReplicationController)】: 确保容器应运的副本数始终保持在用户定义的副本数

【RS(ReplicaSet)】: 新版本k8s建议使用RS取代RC,RC与RS没多少本质区别,它支持集合式的selector,在大型项目管理中RS比RC更简单方便

【Deployment】: 有状态应用部署,用来自动管理ReplicaSet,虽然RS可以独立使用,但使用Deployment就不用担心与其它机器的兼容性问题(如RS不支持rolling-update,但Deloyment支持)

【Pod】: 它只是容器所运行的一个环境,自身不会运行。Kubernetes通过控制器(Deployment、StatefuleSet、DaemonSet)能够创建和管理多个Pod,并在集群范围内处理副本、部署和提供自愈能力。在Pod中,所有容器都被统一安排和调度,并运行在共享的上下文中。

【HPA(Horizontal Pod Autoscaling)】: 仅适用与Deployment和ReplicaSet,在V1版本中仅支持根据Pod的CPU利用率进行扩容

【DaemonSet 】 确保全部(或者一些)Node上运行一个Pod的副本。当有Node加入集群时,也会为它们新增一个pod,当有node从集群中移除时,这些pod也会被回收。删除DaemonSet将会删除它创建的所有Pod

【Job】 : 负责处理批处理任务,保证批处理任务的Pod成功结束(即不是正常退出会重新执行)一次性任务

【Cron Job】: 管理基于时间的Job(指定时间点运行一次,或周期性的在给定时间点运行)

【StatefulSet】:解决有状态服务问题(对应Deloyment和ReplicaSets是为无状态服务而设计,docker、apache、lvs都是无状态服务,无状态指的是没有必要的存储需要,要实时保留,有状态服务如mysql、mongodb等都需要实时存储,特点:抽离出集群之后再放回来由于数据不完整就没法继续工作了)

【harbor】: Docker容器应用的开发和运行离不开可靠的镜像管理,虽然Docker官方也提供了公共的镜像仓库,但是从安全和效率等方面考虑,部署私有环境内的Registry也是非常必要的。Harbor是由VMware公司开源的企业级的Docker Registry管理项目,是构建企业级私有docker镜像的仓库的开源解决方案,它包括权限管理(RBAC)、LDAP、日志审核、管理界面、自我注册、镜像复制和中文支持等功能,它还整合了K8s的插件(Add-ons)仓库,即Helm通过chart方式下载,管理,安装K8s插件。

【Squid cache(简称为Squid)】: 是一个流行的自由软件(GNU通用公共许可证)的代理服务器和Web缓存服务器。Squid有广泛的用途,从作为网页服务器的前置cache服务器缓存相关请求来提高Web服务器的速度,到为一组人共享网络资源而缓存万维网,域名系统和其他网络搜索,到通过过滤流量帮助网络安全,到局域网通过代理上网。Squid主要设计用于在Unix一类系统运行。

【koolshare】: 软路由,可以利用虚拟机搭建一个软路由 来模拟一个路由器,然后在需要连接的机器上把网关设置成软路由的ip就行了。软路由选择Windows操作系统,因为我们需要在PE环境(windows下制作出来的一个临时紧急系统)中进行软路由的写入,固件类型选择BIOS,网络类型选择使用仅主机模式网络,虚拟磁盘类型选择IDE【一定要选择IDE模式】,SCSI会报错

【kubectl 】 是一个用于操作kubernetes集群的命令行接口,通过利用kubectl的各种命令可以实现各种功能,是在使用kubernetes中非常常用的工具.如对镜像进行创建和删除。

【IPVS】: IPVS (IP Virtual Server,IP虚拟服务器)是基于Netfilter的、作为linux内核的一部分实现传输层负载均衡的技术,通常称为第4层LAN交换。IPVS集成在LVS(Linux Virtual Server)中,它在主机中运行,并在真实服务器集群前充当负载均衡器。IPVS可以将对TCP/UDP服务的请求转发给后端的真实服务器,并使真实服务器的服务在单个IP地址上显示为虚拟服务。因此IPVS天然支持Kubernetes Service。

【kube-proxy】 是为service构建路由规则的模块,之前依赖iptables来实现主要service类型的支持,比如(ClusterIP和NodePort)。但是iptables很难支持上万级的service,因为iptables纯粹是为防火墙而设计的,并且底层数据结构是内核规则的列表。

【Namespaces】: 命名空间,将对象逻辑上隔离,用于角色管理和控制

【Annotations】: 注释,方便阅读

【Cronjob】:周期性计划定时任务

【Service】: 对外提供服务,防止 Pod 失联,定义一组 Pod 的访问策略,方便访问

【Label】: 标签,附加到某个资源上,用于关联对象、查询和筛选

【ReplicaSet】:创建资源,确保预期的 Pod 副本数量

【StatefulSet】:有状态应用部署

【DaemonSet】:确保所有 Node 运行同一个 Pod,即管理进程资源






# IPVS 与 IPTABLES区别
IPVS模式在Kubernetes v1.8中引入,并在v1.9中进入了beta。 1.11中实现了GA(General Availability)。IPTABLES模式在v1.1中添加,并成为自v1.2以来的默认操作模式。 IPVS和IPTABLES都基于netfilter。

#IPVS模式和IPTABLES模式之间的差异如下:

【kubernetes组件关系】

@kubernetes(k8s)基础理论知识_kubernetes_03

七、服务发现

服务发现在微服务架构里,服务之间经常进行通信,服务发现就是解决不同服务之间通信的问题。比如一个nginx的pod,要访问一个mysql服务,就需要知道mysql服务的ip和port,获取ip和port的过程就是服务发现

@kubernetes(k8s)基础理论知识_k8s_04

服务端想去想问一组pod,如果pod不相关是不能通过service进行代理的,那么pod必须具有相关性

如同一个RS\RC创建的,或拥有同一组标签(service通过标签去选择pod)

service有自己的ip、端口,客户端通过访问service的IP和端口通过算法(如RR轮询)来间接访问pod

【pod的组件关系】

【pod】:
K8s 中最小的部署单元,是一组容器的集合
一个 Pod 中的容器共享网络命名空间,像一个小型局域网一样,所以其中容器之间可以彼此通讯
Pod 是短暂的,因为其一旦故障,会重新创建新的
K8s 管理的基本都是业务,而业务都是跑在 Pod 上

@kubernetes(k8s)基础理论知识_负载均衡_05

Pod不同情况下的网络通讯模式,如下:

1#同一个pod内部通讯:
同一个pod共享同一个网络命名空间,共享同一个协议栈,同一个Pod内的多个容器通过io互相访问





2#各pod节点通信,分2种情况:
1>各Pod不在同一台主机: 由于pod的地址与docker0在同一个网段,但docker0网段与宿主机网卡处于不同的IP网段,而不同node之间的通讯只能通过宿主机的物理网卡进行,可将Pod的IP与Node的IP关联起来互相访问
2>在同一台主机: Docker0网桥直接转发至另一个pod,看不需要经过Flannel




3#Pod与Service之间通讯:
通过各节点的iptables规则转发通讯(新版本支持lvs转发,性能更高)





4#Pod到外网:

【kubernetes 支持的两种服务发现模式】

1#环境变量:
Pod创建的时候,服务的ip和port会以环境变量的形式注入到pod里
比如:pod创建时有一个redis-master服务,服务ip地址是10.0.0.11,port是6379,则会把下面一系列环境变量注入到pod里,通过这些环境变量访问redis-master服务
REDIS_MASTER_SERVICE_HOST=10.0.0.11REDIS_MASTER_SERVICE_PORT=6379REDIS_MASTER_PORT=tcp://10.0.0.11:6379





2#dns:
K8s集群会内置一个dns服务器,service创建成功后,会在dns服务器里导入一些记录,想要访问某个服务,通过dns服务器解析出对应的ip和port,从而实现服务访问
service 是微服务架构中的微服务
service

八、网络通讯方式(flannel)

1》kubernetes的网络模型假定了所有pod都在一个可以直接连通的扁平的网络空间,由于这在GCE(Google Computer Engine)里面是现成的,所以k8s假定这个网络已经存在了。

2》而在私有云搭建k8s集群,由于这个扁平的网络不存在,需要自己实现网络架设,打通不同节点上的docker容器互联,然后运行k8s。

3》可以通过诸如网络通讯方案Flannel来实现扁平的网络空间。

4》Flannel是CoreOS团队针对k8s设计的网络规划服务,功能是让集群中不同节点的主机创建的Docker容器都具有全集群唯一的虚拟IP地址,并在这些IP之间建立一个网络覆盖(Overlay Network)来将数据包原封不动的传递到目标容器

【模拟flannel传送数据过程】

@kubernetes(k8s)基础理论知识_k8s cri_06

#模拟使用Flannel网络
(宿主机A上的docker容器(10.1.15.10)发送数据到宿主机B上的docker容器(10.1.20.20)的流程)
1>首先,docker容器10.1.15.10要发送数据到宿主机B上,进行匹配相关的路由,根据源容器和目的容器的IP匹配路由规则,同时匹配两个IP的路由规则是10.1.0.0/16,如果是同一个宿主机上的容器访问,匹配的是10.1.15.0或者10.1.20.0
2>数据从docker0网桥出来以后投递到flannel0网卡
3>监听flannel0网卡的Flanneld服务收到数据后封装成数据包发送到宿主机B
4宿主机B上的Flanneld服务接收到数据包后解包还原成原始数据
5>Flanneld服务发送数据到flannel0网卡,根据目的容器地址匹配到路由规则10.1.20.0/24(docker0)
6>投递数据到docker0网桥,进而进入到目标容器10.1.20.20

九、kubernetes的三种部署方式

方式一:minikube(小规模部署)​​【部署地址】​

1》是一个工具,可以在本地快速运行一个单点的Kubernetes,仅用于尝试Kubernetes或日常开发的用户使用

方式二:kubeadm(集群部署)​​【部署地址】​

1》kubeadm是一个k8s部署工具,提供kubeadm init和kubeadm join,用于快速部署Kubernetes集群

2》kubeadm降低部署门槛,屏蔽了很多细节,遇到问题很难排查

方式三:二进制包部署(推荐使用)​​【下载地址】​

1》二进制部署,从官方下载发行版的二进制包,手动部署每个组件,组成Kubernetes集群

2》二进制包部署k8s,虽然手动部署麻烦,单期间可以学习很多工作原理,也利于后期维护

【kubernetes部署状态流程】

1》创建一个 Kubernetes 集群

@kubernetes(k8s)基础理论知识_kubernetes_07


2》应用程序部署


@kubernetes(k8s)基础理论知识_k8s_08


3》应用程序探索


@kubernetes(k8s)基础理论知识_kubernetes_09


4》应用外部可见


@kubernetes(k8s)基础理论知识_kubernetes_10


5》应用可扩展


@kubernetes(k8s)基础理论知识_kubernetes_11


6》应用更新


@kubernetes(k8s)基础理论知识_k8s cri_12


7》发布应用


@kubernetes(k8s)基础理论知识_kubernetes_13

十、kubectl的使用及资源清单

​【kubectl的使用及资源清单详解】​