kubernetes模式有哪些？kubernetes架构原则简要
kubernetes模式有哪些？kubernetes架构原则简要OOPkubernetesKind - 每个 API group-version 包含一个或者多个 API 类型 我们称之为 Kinds. 虽然同类型 Kind 在不同的 version 之间的表现形式可能不同，但是同类型 Kind 必须能够存储其他 Kind 的全部数据，也就是说同类型 Kind 之间必须是互相兼容的(我们可以把数据存到 fields 或者 annotations)，这样当你使用老版本的 API group-version 时不会造成丢失或损坏 有关更多信息，请参见Kubernetes API指南。https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.mdResource你应该听别人提到过 Resources， Re
架构https://Kubernetes.io/zh/docs/concepts/architecture/
https://kubernetes.io/zh/docs/concepts/architecture/cloud-controller/#design
控制平面
- kube-apiserver
- kube-scheduler
- kube-controller-manager
- etcd
网络插件
- Flannel：需要在每个节点上把发向容器的数据包进行封装后，再用隧道将封装后的数据包发送到运行着目标Pod的node节点上。目标node节点再负责去掉封装，将去除封装的数据包发送到目标Pod 上。数据通信性能则大受影响。Flannel网络非常类似于Docker网络的Overlay驱动，基于二层的层叠网络。
- Calico：把主机当做Internet中的路由器，使用BGP同步路由，并使用iptables来做安全访问策略。设计思路：Calico不使用隧道或NAT来实现转发，而是巧妙地把所有的二三层流量转换成三层流量，并通过主机上路由配置完成夸主机转发。
- https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/
- kubelet：负责容器整体的生命周期，挂接存储。
- kube-proxy：负责配置网络。
https://kubernetes.io/docs/reference/kubectl/cheatsheet/
- 增删改查 kubectl create/delete/（replace or apply or edit）/get
- patch是经常性操作
- kubectl -f 是无序列的，把所有的配置放进一个yaml，会出现先create deployment，再create ns，就会报错。
- helm 有序的，code里写死顺序了。
- 主动顺序apply
- 声明式
- 符合OpenAPI规范的
https://kubernetes.io/zh/docs/concepts/overview/kubernetes-api/
- GVK 和 GVR
kubectl api-resources
Groups、Versions 和 Kinds 之间的关系。
Kubernetes 中的 API Group 只是相关功能的集合 每个 group 包含一个或者多个 versions 这样的关系可以让我们随着时间的推移，通过创建不同的 versions 来更改 API 的工作方式。
Kind - 每个 API group-version 包含一个或者多个 API 类型 我们称之为 Kinds. 虽然同类型 Kind 在不同的 version 之间的表现形式可能不同，但是同类型 Kind 必须能够存储其他 Kind 的全部数据，也就是说同类型 Kind 之间必须是互相兼容的(我们可以把数据存到 fields 或者 annotations)，这样当你使用老版本的 API group-version 时不会造成丢失或损坏 有关更多信息，请参见Kubernetes API指南。
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md
Resource
你应该听别人提到过 Resources， Resource 是 Kind 在 API 中的标识，通常情况下 Kind 和 Resource 是一一对应的 但是有时候相同的 Kind 可能对应多个 Resources 比如 Scale Kind 可能对应很多 Resources：deployments/scale 或者 replicasets/scale 但是在 CRD 中，每个 Kind 只会对应一种 Resource。
- 其实，理解了 GVK 之后再理解 GVR 就很容易了，这就是面向对象编程里面的类和对象的概念是一样的：
|
kubernetes |
OOP |
|
Kind |
Class |
|
Resource |
Object |
结构
TypeMeta
metadata
-finalizer
-resourceVersion
label
annotations
Spec
status
- 常见API Group
https://kubernetes.io/docs/reference/kubernetes-api/
工作负载类型
- deployment：集群上的无状态应用
- statefulset：通过一个或者多个以某种方式跟踪状态的应用，用于有状态应用
- daemonset：本地节点常驻运行的应用
- job/cronjob：定时创建可以一直运行到结束并停止的无状态应用
- services：一组相同pods组成的网络组
kubernetes如何实现服务编排
服务编排通俗的讲就是将一个服务在合适的时间，放在一个合适的地方，让其按照规划的方式运行。
- 合适的时间：当实际服务状态和预期的状态不相符的时候
- 合适的地方：资源最充足的地方
- 规划的方式：满足用户的需求
List Watch
集群控制模块最核心的设计：
采用统一的异步消息处理机制，保证了消息的实时性、可靠性、顺序性和性能
List Watch关键设计
- 基于chunk的消息通知
当客户端第一次和API server交互的时候，api推历史的全量，之后传增量，增量就是chunk，这种依靠增量同步的模式，就叫chunk模式。
- 本地缓存 & 本地索引
- 无界队列 & 事件去重
- 基于观察者模式的注册
