云原生基础概念

概念"/>

云原生基础概念

CNCF 云原生基金会

云原生：
应用容器化
基于微服务架构

分布式链路监控是什么？

常规的指标监控流程：

我们在日常的维护中，比如某个客户端用户反馈404 那我们首先会通过类似于zabbix这种监控去定位，是否存储某个服务异常，如果不能然后我们才会监控请问资源所对应的应用日志。

那分布式链路追踪监控，就相当于 我们的客户端从请求我们的服务，整个请问报文，流转到哪里，是什么服务发生中断，都能做到实时的监控。不同于传统的指标监控，能够更加准确的定位问题。

k8 我们可以理解成是一个云操作系统

什么是云操作系统

就比如传统的操作系统，那么它管理的也只是当前主机上的操作系统资源，云操作系统就是相当于，一个操作系统控制一堆的计算机，相当于1对多的概念。

CMDB 资产管理系统

k8功能:

1 容器编排
2 支持 扩缩容、滚动发布、健康监测
3 声明式API
4 CRI（定义高级容器运行时方案）） ---->Containerd
5 CNI（软件定义网络方案）
6 CSI (定义容器存储接口方案)

总结：
k8 只是单纯的C/W架构，规范各 容器运行时、存储、网络的接口

k8中的节点类型

Master 控制节点
Worker 工作节点

k8运行逻辑

K8将所有的工作节点上的资源结合在一起，构成一个更加强大的服务器
计算和存储接口通过Master节点中的Kuber Api server暴露
客户端通过API提交应用程序的运行请求，而后Master通过调度算法将其自动分配给特定的某个工作节点，然后以Pod对象的形式运行
Master会自动的处理因工作节点的添加，故障或者移除等变动对pod的影响

k8典型的特征为声明式API 每个API底层都有运行该API 程序。

Pause是什么？

如图一个Pod 包含两个超亲密关系的容器,但是当Kubelte在创建POD之前，就会先创建一个Pause为容器提供网络层的namespace，然后pod会与pause共享网络策略。

namespace类型我们知道一共有如下几种。
Mount 隔离文件系统。
User 隔离用户。
PID 隔离进程。
Network 隔离网络。
IPC隔离进程间通信。
UTS隔离用户域。
CGrop隔离文件。
Time。

pause会先创建 IPC Network UTS 这些namespace

原子单元: 就比如说一个POD中运行了两个或者多个容器，那么这两个容器不能分开运行在不同的节点上。

k8s组件构成

Master 主要由API server Controller-Manager和scheduler三个组件构成，以及用于集群状态存储的etcd服务组成，他们构成整个集群的控制平面

Node节点则主要包含kubelet、Kube Proxy 以及container runtime 三个组件，他们主要承载运行各类容器

Master节点：
etcd是一个KV 存储 具有 高可用 、高一致性。

kube-scheduler : 选择调度策略
Kube-apiserver: 管理整个K8S资源的唯一的入口

kube-controller-manager 控制器
例如包含如下
route controller
volume controller
service controller
node controller
deployment controller
replicaset controller

总结 ： 控制器控制K8S所有的 controller以此来管理容器，这些也是支撑k8s 声明式API所拥有的底层代码

工作节点：
kubelet : 通过CNI CSI CRI 管理容器的网络 、存储、容器运行时，那容器运行时又管理整个容器的声明周期，那么总的说Kubelet是管理整个POD所有需要建立资源。

kube-proxy k8s是代理，是用来控制k8s node节点上的service

k8s中的service 和 schedule之间的联系

service 主要起到了服务发现的机制，schedule是将请求调度到某个service上。

原因：
因为当我们客户端访问某个POD中的容器资源时，首先会通过kubescheduler 调度到service 上 service是通过Kube-proxy会发现当前访问的POD在那个node上。然后再将数据返回给service ，最后通过service将请求传递到某个POD中。

我们每个主机上都有内核， 任何客户端想要访问我们的POD时，首先流量会到某个节点，无论访问任何一个节点，我们在每个节点都定义了一个service ip (SIP) 然后kube-proxy会从kube-apiserver 通过etcd 获取当前访问资源对应的POD的信息，然后再返回给service 然后再创建Iptables 规则DNAT到某个IP+PORT 以此完成负载均衡的操作，最后就会将请求传递给某个POD。
如下图所示

我们在node节点创建的任何的service都会存在于所有的node节点上。另外service也并不是组件而是工作在内核空间的一组iptables规则
所以当我们的请求转发到node上时，所能够看到的iptables规则也是不一样的
kube-proxy组件的功能
1 发现当期node上的services
2 为service提供pod信息，以便于创建Iptables规则

当然service 的逻辑远远不只是这么简单，我们后续会专门介绍。

当然此处service 生成的iptables规则我们也可以定位ipvs的规则，但是要通过更改配置。