目录
前言：基于k8s基本概念 在此之上了解K8s的基本组件
一个pod 会封装多个容器组成一个子节点的运行环境 （最小单元，容器的数量2+）
一个Pod中的容器共享网络命名空间（基础容器提供的pause）
Pod是短暂的 （叙述的是其生命周期）
一组容器的集合：基础容器（pause）+ 初始化容器（initcontainers）+业务容器（Maincontainer）（主应用容器+挂斗/副容器)
pod：首先，最小组成单元，是一组容器的集合，应用容器跑在pod资源中的
① K8S中资源的概念
② 资源清单格式（资源清单/配置文件）：Yaml/语法
③ Pod 生命周期（创建——》发布/暴露（service）——》更新——》回滚——》删除）
什么是控制器？对不同的对象及其特性使用不同的方式控制管理
控制器说明：
ReplicaSet（RS子控制器）：确保预期的Pod副本数量
Deployment：无状态应用部署
StatefulSet：有状态应用部署（IP得固定）
DaemonSet：确保所有Node运行相同服务/应用的一个Pod
Job：一次性任务
Cronjob：定时任务
ingress：管理的是L7层的网络模式（http/https流量）
ingress包含：nginx、Haproxy、traffic、istio、kong
PV PVC：动态存储
K8S内部的Pod 通讯是以一组私有地址进行通讯的，所以默认情况下无法直接为客户端（服务、用户）提供访问，可以通过Service服务发现，把我们内部的pod资源暴露给客户端访问（以暴露一个ip:端口的方式），让客户端可以通过这个IP：端口的形式访问到K8S内部的多个pod（通常意义上是一个应用的副本集）
通过service这个统一入口/定义的访问策略对外暴露服务，Service 作为一组Pod 的统一访问出入口（定义一组Pod的访问策略），以RR分流算法进行负载均衡，把Pod中的应用服务暴露出来给客户端访问service ——》暴露方式是四层的
访问的方式是通过kube-proxy 匹配iptables功能进行转发的（四层）
k8s官方默认提供了四层的代理/负载均衡方式，而我们可以借助于官方后续支持的ingres-nginx 提供七层转发/负载均衡
为什么需要kube-proxy和service
容器的特点就是快速创建、快速销毁。为了能够访问这些pod，需要引入负载均衡和VTP实现后端真实服务的自动转发和故障漂移
这个负载均衡就是service，VIP就是service IP，service就是一个四层负载均衡。k8s为了实现在集群所有的节点都能访问service，Kube-proxy默认会在所有的节点创建这个VIP，实现负载均衡
创建service需要servicecontroller，EndpointController，kube-proxy,三大模块同时协作
当一个service对象状态发生变化的时候，Informer都会通知serviceController，创建对应的服务
Endpointcontroller会同时订阅service和Pod的增删事件。其功能如下：
负责生成和维护所有endpoint对象的控制器
负责监听service和对应pod的变化
监听到service被删除，则删除和该service同名的endpoint对象
监听到新的service被创建，则根据新建service信息（YAML）获取相关pod列表，然后创建对应endpoint对象
监听到service被更新，则根据更新后的service信息获取相关pod列表，然后更新对应endpoint对象
监听到pod事件，则更新对应的service的endpoint对象，将podip记录到endpoint中
主体：service pod
主体：endpoint对象
功能：定义后端位置和自动发现、自动更新
kube-proxy负责service实现，实现了k8s内部service和外部node port到service的访问。
kube-proxy采用iptables的方式配置负载均衡，基于iptables的kube-proxy的主要职责包括两大块：一块是侦听service更新事件，并更新service相关的iptables规则；一块是侦听endpoint更新事件，更新endpoint相关的iptables规则(如KUBE-SVC-链中的规则），然后将包请求转入endpoint对应的Pod。
serviceController：是控制service来创建对应的Pod关联的规则的
endpointController：是定义后端pod的具体位置，也就是endpoint (upstream +consul的自动发现和更新)
kube-proxy：是用来定叉具体的后端转发和分流规则的
以上组成了一个service所必要的功能
服务不依赖自身的状态，实例的状态数据可以维护在内存中。
任何一个请求都可以被任意一个实例处理。
不存储状态数据，实例可以水平拓展，通过负载均衡将请求分发到各个节点。
在一个封闭的系统中，只存在一个数据闭环。
通常存在于单体架构的集群中。
服务本身依赖或者存在局部的状态数据，这些数据需要自身持久化或者可以通过其他节点恢复。
一个请求只能被某个节点（或者同等状态下的节点）处理。
存储状态数据，实例的拓展需要整个系统参与状态的迁移。
在一个封闭的系统中，存在多个数据闭环，需要考虑这些闭环的数据一致性问题。
通常存在于分布式架构中。
简化：
无状态服务：就是没有特殊状态的服务,各个请求对于服务器来说统一无差别处理,请求自身携带了所有服务端所需要的所有参数(服务端自身不存储跟请求相关的任何数据,不包括数据库存储信息
有状态服务：与之相反,有状态服务在服务端保留之前请求的信息,用以处理当前请求,比如session等
超简化：
有状态服务：需要持久化，多次请求之间需要共享一些信息
无状态服务：一次性，不需要持久化，每次请求都是一条新的数据
K8S会自动完成把一个新的pod 调度到对应的节点（预选/优选算法）对于生产环境上，我们往往会需要将pod创建的过程（比如创建到的节点位置）进行管理
例如：
指定节点位置创建Pod（指定调度）
将不同的Pod创建在一个节点上（亲和）
将不同的Pod 创建在不同的节点上（反亲和）
根据自己的需要，对pod进行节点组装等
Label ： 标签，附加到某个资源上，用于关联对象、查询和筛选
创建一个Pod
1、编写pod yml文件（nginx资源怎么跑，用什么环境变量，需不需要资源限制，要调度到哪个节点） label：nginx
2、把pod 暴露出去，Service——》通过yml文件定义 label：nginx
通过同一个label标签，进行关联，组合在一起
namespaces ： 命名空间，将对象逻辑上隔离
资源名称空间：网络、user、pid
default
kube-system
kube-node-release
kube-public
在同一个名称空间的pod可以通信（创建pod不指定默认在default里）
名称空间限制pod数量
Annotations ：注释（描述性信息）
认证、鉴权、访问控制、原理及流程
从搭建集群，就需要用到加密，CA认证
管理和控制，必须先通过认证/授权，才能进行管理
跑的一些应用，nginx、squid ——》需要一些访问控制策略
类似linux里面yum
helm 安装 magodb
helm 模板、自定义