说说你对kubernetes的理解（简单）

目录

• 整体概述
• pod工作流程
• k8s网络
  • flannel
  • 网络策略，network proxy
• 几套证书理解
• 组件
  • master管理节点上组件
    • node节点

整体概述

k8s是一个编排工具，是谷歌的程序员根据谷歌公司内部使用的borg改简单来讲就是对整个容器资源整合，将全部容器资源统一进行调度管理。Kubernetes(k8s)是自动化容器操作的开源平台。这些容器操作包括：部署，调度和节点集群间扩展。

pod工作流程

1. 自主式pod：能够自我进行管理的pod，自主创建之后仍然是需要提交给APIserver，接受之后，借助于scheduler调度器调度时指定node节点，由node节点来启动此pod，如果pod中容器出现故障，需要重启容器，该操作是由kubelet来进行完成，但是如果node节点出了故障了，那么pod也就消失了，运行不了了。
2. 控制器管理的pod：引用了控制器的使用，使得pod完全可以称之为有生命周期的对象，由scheduler调度器将其调度至k8s集群中的某节点，然后启动pod，任务终止之后，就将会被清除掉。但是有一些任务是作为守护进程要求随时运行在容器中，一旦出现故障，我们要及时发现，重建或者重启容器，用接口不太容易实现。但是在k8s中提供了pod控制器，这是旧的控制器，后来出了一个新版控制器deployment在其里面LPA控制器，该组件可以水平扩展pod
   1. service组件就是iptables端口转发，手动配置的，service1.2新版本之后又加入了ipvs调度的功能。
   2. k8s核心基础组件组件有pod、service、controller控制器，pod运行容器。service和controller都是通过标签和标签选择器来识别自己治理下的pod，控制器可以对pod进行，增加，删除等等操作。
   3. service是基于名称备客户端访问和发现，所以就需要用到DNS服务，DNS服务自身也是一个pod，所以也需要service和控制器来进行管理，这个DNS的pod是基础性系统架构级pod，k8s自身就需要用到该pod

• 监控：用的是grafana+promethos，这也是附件

k8s网络

网络模型：各个pod运行在一个网络中，在一个网络名称空间，service是一个网络但service是一个虚拟出来的ip，所在node节点是一个网络，一个有三个网络模式，分别为节点网络，集群网络，pod网络

收到请求时，由节点网络代为代理至集群网络，再有集群网络代理至pod网络

1. 同一pod间多个容器的通信

   ​ Pod中的每个Docker容器拥有与Pod相同的IP和port地址空间，并且由于他们在同一个网络命名空间，他们之间可以通过localhost相互访问。
   什么机制让同一个Pod内的多个docker容器相互通信那？其实是使用Docker的一种网络模型：–net=container

2. 各个pod之间的通信，它们之间的通信直接可达的，overlay叠加网络，但其实pod之间是不会直接通信的

3. pod与service之间的通信，service只是一个虚拟IP地址，每个宿主机都有相关IPtables规则，docker就是指向一个网关，指向宿主机上，而网关收到包之后，会通过iptables规则转发转发给service，而service的地址更新等操作，其它节点有时怎么知道的呢，就引出了kube-proxy，每个节点都会有这个组件，它负责随时和APIserver保持通信，service更新时所在节点会告知APIserver，然后APIserver会生产一个任务实践，告知所有的kube-proxy，这样就完成了，不需要人为参与

flannel

它是支持CNI插件比较好的一款，支持网络配置

calico：基于BGP协议，支持网络配置和网络策略

canel：集合两种各自优点，目前用的最多

网络策略，network proxy

k8s中的名称空间和docker有所不同，它是针对于整个k8s集群而言的，一个pod分配一个名称空间，而且该名称空间只是提供一个管理上的边界，对于pod和pod之间通信并不做设置， 而网络策略就是可以通过设置iptables规则定义这些名称空间之间的访问

几套证书理解

为了安全通信

1. APIserver和etcd之间需要双向认证证书
2. APIserver与它的客户端也需要证书

组件

master管理节点上组件

master上的组件，APIserver上有很多数据，以及配置，所有数据都不存储在本地，而是存储在共享存储etcd上，但避免单点故障，所以一般至少需要三个master节点

1. APIserver：该组件是提供接口服务的是以守护进程方式运行的，用户对集群进行管理时都是通过APIserver来管理整个k8s集群。整个集群的交互都是以APIserver为核心所有查询和管理操作都需要通过API来进行，所有组件模块之间不会相互调用，是通过和APIserver打交道来完成自己那部分的工作，它所有的结果状态备持久存储于etcd中。它是整个集群的网关
2. 控制器管理器（controller manager）：执行整个系统的后台任务，包括节点状态状况、Pod个数、Pods和Service的关联等。
3. 调度器（scheduler）：用于部署和管理大规模容器应用平台，APIserver确认pod对象的创建请求之后，便需要由scheduler根据集群内各节点可用资源，以及所需的资源需求作出调度决策
4. etcd:负责节点间的服务发现和配置共享。

node节点

1. kubelet：作为agent，接收APIserver分配该节点的Pods任务及管理容器，周期性获取容器状态，反馈给apiserver。
2. 还有容器运行时环境，负责下载镜像并运行容器，至少包括docker环境等
3. kube-proxy，运行在每个计算节点上，负责Pod网络代理。定时从etcd获取到service信息来做相应的策略。

k8s 超详细总结