Service是分布式集群架构的核心
1.1概念： 给具有相同功能的容器提供一个统一的日寇地址，并可以将请求负载分发到后端的各个容器应用上
◎ Service通过Label Selector与后端pod副本集群对接
◎ 每个pod都有一个独立的Endpoint(Pod IP + ContainerPort) 给客户端访问
一般多个pod组成集群提供服务，用负载均衡器给一组pod开启一个对外的服务端口，将pod的Endpoint转发列表， 客户端就可以通过负载均衡器的对外IP地址+服务端口来访问此服务。客户端的请求最后会被转发到哪个Pod，由负载均衡器的算法所决定。
◎ Pod的Endpoint地址会随着Pod的销毁和重新创建而发生改变
◎ Service一旦被创建，Kubernetes就会自动为它分配一个可用的Cluster IP，它的Cluster IP不会发生改变，只要用Service的Name与Service的Cluster IP地址做一个DNS域名映射
1.2 service的类型 【p347】
ClusterIP：虚拟的服务IP地址，用于集群内部的pod访问，在node上的kube-proxy设置的iptables转发
Nodeport:使用宿主机的端口，通过访问node的IP地址+端口来访问服务
LoadBalance：用外接负载均衡器完成服务的负载分发
◎ 拥有唯一指定的名称（比如mysql-server）。 ◎ 拥有一个虚拟IP（Cluster IP、Service IP或VIP）和端口号。 ◎ 能够提供某种远程服务能力。 ◎ 被映射到提供这种服务能力的一组容器应用上。
1.2 NameSpace-命名空间实现资源隔离
2、Pod在Node上Kubernetes管理的最小运行单元是Pod，pod的生命周期 [p243]， pod健康检查[p245]
Pod的管理对象RC、Deployment、DaemonSet和Job都面向无状态的服务
3、RC控制器（Replication Controller） ◎ 目标Pod的定义。
◎ 目标Pod需要运行的副本数量（Replicas）。
◎ 要监控的目标Pod的标签。
Replication Controller的核心作用是确保在任何时候集群中某个RC关联的Pod副本数量都保持预设值。
Replica Set
Set与RC当前的唯一区别是，Replica Sets支持基于集合的Label selector（Set-based selector），而
RC只支持基于等式的Label Selector（equality-based selector），这使得Replica Set的功能更强。
Kubernetes里的Master：指的是集群控制节点
◎ Kubernetes API Server（kube-apiserver）：提供了HTTP Rest接口的关键服务进程， 是Kubernetes里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程。
◎ Kubernetes Controller Manager（kube-controller-manager）： Kubernetes里所有资源对象的自动化控制中心，可以将其理解为资源对象的“大总管”。
◎ Kubernetes Scheduler（kube-scheduler）：负责资源调度（Pod调度）的进程，相当于公交公司的“调度室”。 另外，在Master上通常还需要部署etcd服务，因为Kubernetes里的所有资源对象的数据都被保存在etcd。
◎ etcd :作为Kubernetes集群的主数据库
◎ CNI网络插件：跨主机的容器间网络互通，CRI（容器运行时接口 ）
◎ API：访问k8s资源的入口
用户对API资源进行操作访问步骤： 1.对客户端访问进行认证操作，确认有无访问k8s权限（token、SSl） 2.授权检查，确认是否对资源具有相关的权限ABAC(基于属性的访问控制)RBAC(基于角色的访问控制)NODE(基于节点的访问控制)WEB HOOK（自定义HTTP回调方法的访问控制）
Node节点–Node是Kubernetes集群中的工作负载节点
◎ kubelet：负责Pod对应的容器的创建、启停等任务，同时与Master密切协作，实现集群管理的基本功能。
◎ kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件。
◎ Docker Engine（docker）：Docker引擎，负责本机的容器创建和管理工作。
Label（标签）是Kubernetes系统中另外一个核心概念。一个Label是一个key=value的键值对
常用标签
◎ 版本标签：“release”:“stable”、“release”:“canary”。
◎ 环境标签：“environment”:“dev”、“environment”:“qa”、“environment”:“production”。
◎ 架构标签：“tier”:“frontend”、“tier”:“backend”、“tier”:“middleware”。
◎ 分区标签：“partition”:“customerA”、“partition”:“customerB”。
◎ 质量管控标签：“track”:“daily”、“track”:“weekly”。
–确保创建的Pod在集群中的每一台Node上运行一个副本
确保集群中每个（部分）node运行一份pod副本，当node加入集群时创建pod，当node离开集群时回收pod。 如果删除DaemonSet，其创建的所有pod也被删除，DaemonSet中的pod覆盖整个集群。
DaemonSet中pod通信的几种模式
批处理任务,，Job也是一种特殊的Pod副本自动控制器,控制的Pod副本是短暂运行
8、Volume-存储卷是Pod中能够被多个容器访问的共享目录。 Volume与Pod的生命周期相同 p87
类型：
emptyDir： Volume是在Pod分配到Node时创建的。hostPath：为在Pod上挂载宿主机上的文件或目录gcePersistentDisk：使用谷歌公有云提供的永久磁盘（Persistent Disk，PD）存放Volume的数据awsElasticBlockStore：--Volume使用亚马逊公有云提供的EBSVolume存储数据，需要先创建一个EBS Volume才能使用awsElasticBlockStore。 NFS：--NFS网络文件系统提供的共享目录存储数据其他类型的Volume-- iscsi、flocker glusterfs rbd gitRepo secret
8.1.Persistent Volume（PV）PV可以被理解成Kubernetes集群中的某个网络存储对应的一块存储，
◎ PV只能是网络存储，不属于任何Node，但可以在每个Node上访问。
◎ PV并不是被定义在Pod上的，而是独立于Pod之外定义的。
◎ PV目前支持的类型包括：gcePersistentDisk、
AWSElasticBlockStore、AzureFile、AzureDisk、FC（FibreChannel）、Flocker、NFS、iSCSI、RBD（Rados Block Device）、CephFS、Cinder、GlusterFS、VsphereVolume、Quobyte Volumes、 VMware Photon、Portworx Volumes、ScaleIO Volumes和HostPath（仅供单机测试）。
PV的accessModes属性
◎ ReadWriteOnce：读写权限，并且只能被单个Node挂载。◎ ReadOnlyMany：只读权限，允许被多个Node挂载。◎ ReadWriteMany：读写权限，允许被多个Node挂载。
8.2.PersistentVolumeClaim（PVC）PersistentVolumeClaim（PVC）是由用户进行存储的请求 。PVC消耗PV资源。Pod可以请求特定级别的资源（CPU和内存）。
8.3 ConfigMap挂载===》总结至23小点 9、ServiceAccount Account–主要是给service使用的账号，主要的内容是secret资源，包含认证需要的token,根CA
https://blog.csdn.net/BigData_Mining/article/details/88529157?utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control
service能将一个接收port映射到任意的targetPort,