目录
Kubernetes是什么？ 就是个编排运行容器的集群
简单来讲Kubernetes是让应用构建成为容器（镜像）之后在基于镜像，以容器化的方式运行容器编排容器，来让应用之间正常通信来管理容器之间的关系的，容器管理系统
1、你有一堆容器。每个容器都有docker的容器引擎，他们都能以容器化的方式运行应用，当应用不存在的时候他能自动的docker hadoop上下载拉去镜像，这些都是管理员自己解决解决问题，KUbernetes的作用是在当前容器应用中，根据某种算法选出性能最好更适合他的节点把应用运行在这个节点上，至于创建和启动K8s是不管的，这些问题都会交给docker
2、当这个容器stop了，他就会把这个容器调到别的节点上，而储存都会在外部的共享储存上，当你换机器够只要外部储存能连接上当前节点就可以保存数据不变。而k8s要知道到有哪些存储可用，以及当前的调度结果，从而驱动着存储服务进行调度对接，为容器提供存储空间
3 、因为调度节点ip等不同，还需要在上面做一个虚拟网段出来，无论容器调到那个机器都会在同一个网段或者网络当中
Kubernetes既不负责创运行容器，也不负责创建存储空间（存储空间是管理员在外部提供的），也不负责创建存储空间，这些都是有管理员额外选定后由第三方组件来实现但是他们都得接收Kubernetes的指挥
因此Kubernetes是个编排平台，很多核心功能都是由第三方平台提供，很多功能他只是对接别人的平台实现，他就是自己做成个框架，做成个标准，做成个机制，具体实现交给第三方平台
大概分为一下几个步骤
1、容器编排； Image --> App Container “是以应用为中心的编排平台”
2、 面向平台的平台：支持强大的扩展能力：构建其它的平台
3、他主要完成容器生命周期管理和关系管理
3.1，生命周期管理
容器编排： 器生命周期管理。容器创建、运行、监控、终止。
为容器运行提供支撑： 存储卷：卷编排。网络：网络编排
3.,2，容器关系管理 Pod
超亲密关系：运行一个整体的超亲密关系的容器为Pod，Kubernetes抽象出来的新概念Pod
非超亲密关系：各自独立运行
- 通过Service作为访问入口互相发现和访问， Service需要DNS的支撑
- DNS为Service提供一个独立DNS域名格式的名称
- 应用构建为容器（镜像）以后，基于镜像以容器话的方式运行容器编排容器，来让应用之间正常通信来管理容器之间的关系的容器管理系统
Kubernetes集群的节点类型
K8s的节点就两类由Master和Worker两类节点组成 也可以看成M/S结构的
- Master：控制节点
- Worker：工作节点
Master为了实现这种架构会在每个Worker上安装一个应用程序，每个Worker上的程序都会和Master实时交互，并且执行Master的命令 ，每个Worker上的应用叫做集群代理程序
K8s编排运行容器的最小单元是Pod的
Pod简单理解就是在容器外部加了一成壳，其实在节点上看到的还是容器，但是K8s管理的是Pod，不是容器 Pod有另外一个名字叫容器集，可以把多个容器（超亲密）才一个Pod里运行。Pod只是个概念你看到的还是容器，本质上是为了更好地运行管理容器。本质上是共享Network、IPC和UTS名称空间以及存储资源的容器集
- 可将其想象成一台物理机或虚拟机，各容器就是该主机上的进程
- 各容器共享网络协议栈、网络设备、路由、IP地址和端口等，但Mount、PID和USER仍隔离
- 每个Pod上还可附加一个“存储卷（Volume）”作为该“主机”的外部存储，独立于Pod的生命周期，可由Pod内的各容器共享
运行逻辑
- Kubernetes将所有工作节点的资源集结在一起形成一台更加强大的“服务器”
- 计算和存储接口通过Master之上的API Server暴露
- 客户端通过API提交应用程序的运行请求，而后由Master通过调度算法将其自动指派至某特定的作节点以
- Master会自动处理因工作节点的添加、故障或移除等变动对Pod的影响
Kubernetes集群架构
- Kubernetes属于典型的Server-Client形式的二层架构
- Master主要由API Server、Controller-Manager和Scheduler三个组件，以及一个用于集群状态存储的Etcd存储服务组成，它们构成整个集群的控制平面
- 而每个Node节点则主要包含Kubelet、Kube Proxy及容器运行时（docker是最为常用的实现）三个组件，它们承载运行各类应用容器
Worker（简称Node）
每个节点上都应该有两个，一个Kubelet，一个Kube-proxy
而主节点也是有三个组成API Server，scheduler，controller manager
Kubernetes的系统组件：分为三个部分
- 多节点：分成两类
- Master：控制平面 一个或一组节点
- Worker：数据平面 一个或一组节点
- Add-Ons：系统组件 而附件是编排运行在这些节点之上的 ，他的功能对接起来功能才算完成
Master基础组件
API Server：提供了k8s各类资源对象 以API形式对外提供服务，服务器程序，监听在某个套接字上；是整个系统的数据总线和数据中心
scheduler：调度器，负责为那些未能绑定到某节点的Pod，挑选一个最适配的Worker来运行它；只会从API接收指令；
controller： 他们的职责是保证集群中各种资源的状态和用户定义(yaml)的状态一致, 如果出现偏差, 则修正资源的状态. 除调度之外的编排决策，几乎都由Controller负责形式
工作负载型COntroller 应用程序的
生命周期管理 部署、启动、健康状态监控、重启、重建、销毁
controller manager ：是各种controller的集合 管理者,是集群内部的管理控制中心
第三方 etcd： 是一个高度一致的分布式键值通用存储
在这里只能存Kubernetes所支持的数据模式，由API Server进行定义和抽象
默认使用json格式 被称为资源类型 --> 实例化之后的结果，称为资源对象，存储在etcd中
PV/PVC: Volume控制器
Deployment：编排无状态应用
StatefulSet：编排有状态应用 ······kubelel 三个标准接口
CRI 容器运行时接口
Volume（CSI）容器存储接口
CNI 容器网络接口
Node基础组件
Kubelet ：是 kubernetes 工作节点上的一个代理组件，群代理程序，负责控制平面事关Pod运行的各种决策 ，向kube-apiserver汇报主机的运行状况。
Kube-proxy： 是 kubernetes 工作节点上的一个网络代理组件，运行在每个节点上。 Kube-proxy维护节点上的网络规则，实现了Kubernetes Service 概念的一部分 。它的作用是使发往 Service 的流量（通过ClusterIP和端口）负载均衡到正确的后端Pod。
- iptables模式：将Service资源的定义转为适配当前节点视角的iptables规则
- ipvs模式：将Service资源的定义转为适配当前节点视角的ipvs和少量iptables规则
是打通Pod网络在Service网络的关键所在
插件
负责扩展Kubernetes集群的功能的应用程序，通常以Pod形式托管运行于Kubernetes集群之上
必选插件 他算不上插件，他是必选的，可以说没有他是运行不起来的，但是他可以用插件的的方式运行
- Network Plugin：网络插件，经由CNI接口，负责为Pod提供专用的通信网络，有多种实现
- Cluster DNS：集群DNS服务器，负责服务注册、发现和名称解析，当下的实现是CoreDNS
- Kube-Proxy：有些部署工具把 Kube-Proxy也当做插件
重要插件
- Ingress Controller：Ingress控制器，负责为Ingress资源提供具体的实现，实现http/https协议的七层路由和流量调度，有多种实现，例如Ingress-Nginx、Contour等
- Dashboard：基于Web的UI
- 指标监控系统：Prometheus
- 日志系统：ELK、PLG等
为什么要设计标签选择器？
Service使用标签选择器（Label Selector）筛选并匹配Pod对象上的标签（Label），从而发现Pod
仅具有符合其标签选择器筛选条件的标签的Pod才可由Service对象作为后端端点使用
客户端 -->访问标签选择器中间层的ip（固定）-->通过标签选择器来过滤到需要的把ip取出来返回去，挂了也会移除换成好的（就是有健康状态选择机制的标签选择器） 在K8s上就叫 Service，CoreDNS会自动的给Service相关服务分配个主机名。他这个负载均衡事实并上不存在，他是软件逻辑，事实上是有 Kube-Proxy来实现
声明式API
API Server 老板指挥司机controller干活，Kubelet （健康检测程序）
申明式API: 面向对象 指挥司机
命令式API: 面向过程 指挥汽车
Pod 和工作负载型控制器
Pod是运行应用的原子单元，其生命周期管理和健康状态监测由kubelet负责完成，而诸如更新、扩缩容和重建等应用编排功能需要由专用的控制器实现，这类控制器即工作负载型控制器
ReplicaSet和Deployment #无状态控制器 和节点Pod没关系
DaemonSet #系统级应用，每个节点运行一个
StatefulSet #有状态控制器 和节点Pod没关系
Job和CronJob # Job作业性。不持久 CronJob周期性作业
- 工作负载型控制器的工作重心
- 确保选定的Pod精确符合期望的数量 #数量不足时依据Pod模板创建，超出时销毁多余的对象
- 按配置定义进行扩容和缩容
- 依照策略和配置进行应用更新
工作负载型控制器：
核心功能：按照用户期望的副本数量，创建并运行Pod
deployment --> nginx 运行谁
replicas: 3 数量
emplate： Pod模板 没有基于模板创建
label selector --> label 多了删除，通过标签关联，避免删错
部署并访问应用
部署应用
- 依照编排需求，选定合适类型的工作负载型控制器 配置好Pod模板，配置好数量，配置标签选择器和标签
- 创建工作负载型控制器对象，由其确保运行合适数量的Pod对象
- 创建Service对象，为该组Pod对象提供固定的访问入口
kubernetes网络模型
Kubernetes集群上会存在三个分别用于节点、Pod和Service的网络
- 于worker上完成交汇
- 由节点内核中的路由模块，以及iptables/netfilter和ipvs等完成网络间的流量转发
-
Kubernetes网络模型(2)
节点网络
- 集群节点间的通信网络，并负责打通与集群外部端点间的通信
- 网络及各节点地址需要于Kubernetes部署前完成配置，非由Kubernetes管理，因而，需要由管理员手动进行，或借助于主机虚拟化管理程序进行
Pod网络
- 为集群上的Pod对象提供的网络
- 虚拟网络，需要经由CNI网络插件实现，例如Flannel、Calico、Cilium等
Service网络
- 在部署Kubernetes集群时指定，各Service对象使用的地址将从该网络中分配
- Service对象的IP地址存在于其相关的iptables或ipvs规则中
- Service他能以serviceip对外发布，或者Service端口对外发布
- 由Kubernetes集群自行管理
Kubernetes集群中的通信流量
Kubernetes网络中主要存在4种类型的通信流量
- 同一Pod内的容器间通信
- Pod间的通信
- Pod与Service间的通信
- 集群外部流量与Service间的通信
Pod网络需要借助于第三方兼容CNI规范的网络插件完成，这些插件需要满足以下功能要求
- 所有Pod间均可不经NAT机制而直接通信
- 所有节点均可不经NAT机制直接与所有Pod通信
- 所有Pod对象都位于同一平面网络中
1710
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
