物理部署架构图 云上云下 物理部署、虚拟化部署

发展历程

描述：近些年Cloud云计算以及大数据的发展促进了企业从传统转型到数字信息化再到云，运维部署技术也从物理机转向虚拟化再转向容器化，随着分布式架构应用的火热，以及对业务快速迭代的需要，便推动了如今的k8s分布式架构运维平台，它实现了对容器资源的编排与控制。

公有云类型：1，IaaS,基础设施即服务；2，PaaS，平台即服务；3，SaaS，软件即服务。

部署时代的变迁：
    1，传统部署时代：直接将应用程序部署到物理机器；由于物理机上不能为应用程序定义资源使用边界，我们很难合理的分配计算资源。
    2，虚拟化部署时代：针对资源边界问题，虚拟化应运而生。用户可以在单台物理机的CPU上运行多个虚拟机。A,虚拟化技术使应用程序被虚拟机相互分开，限制了应用程序之间的非法访问，进而提供了一定程度的安全性。B,虚拟化技术提高了物理机的资源利用率，可以更容易地安装或更新应用程序，降低硬件成本，因此可以更好的规模化实施。C,每个虚拟机可以认为是被虚拟画的物理机上的一台完整的机器，其中运行了一台机器所有组件，包括虚拟机自身的操作系统。
    3，容器化部署时代：与虚拟机类似，但是降低了隔离层级，共享了操作系统。因此，可以认为容器是轻量级的。A,与虚拟机相似，每个容器拥有自己的文件系统，CPU,内存，进程空间等；B,运行应用程序所需要的资源都被容器包装，并和底层基础架构解耦，不强制依赖宿主系统硬件环境；C,容器化的应用程序可以跨云服务商，跨Linux操作系统发行版进行部署。

容器化的好处：
    1，敏捷地创建和部署应用程序：比VM创建容器镜像更快更方便
    2，持续开发，集成和部署：通过快速，简便的回滚，提供可靠且频繁的容器映像生成和部署
    3，分离开发和运维的关注点：降低了开发和运维的耦合度
    4，可监控性：操作系统级别的资源监控信息以及应用程序健康状态以及其他信号的监控信息
    5，开发，测试，生产不同阶段的环境一致性：一次build到处运行
    6，跨云服务商，跨操作系统发行版的可移植性：在Ubuntu,RHEL,CoreOs,本地,主要公共云和其他任何位置上运行
    7，以应用程序为中心的管理：问题的焦点则是在操作系统的逻辑资源上运行一个应用程序；而VM注重于在虚拟硬件上运行一个操作系统
    8，松耦合，分布式，弹性，无约束的微服务应用程序被分成更小的，独立的微服务，并可以动态的部署和管理，而不是一个部署在专属机器上的庞大的单片应用程序
    9，资源隔离：确保应用程序性能不受干扰
    10，资源利用：资源高效，高密度利用

前世今生

前辈：Apache MESOS分布式资源管理框架，2019年被弃用退出舞台；Docker Swarm针对于Docker最薄弱的集群化，容器编排与服务构建，2019年阿里云弃用；

K8s：Go语言重写Borg容器化框架；Google每周运行数十亿个容器，K8s基于与之相同的原则来设计，能够在不扩展运维团队的情况下进行规模扩展；无论本地测试还是跨国公司，k8s的灵活性都能让你在应对复杂系统时得心应手；k8s是开源的；k8s生态系统更大，增长更快，有更多的支持，服务和工具可供用户选择，可以将k8s看作Docker的上层架构。

F&Q

什么是K8s系统？

k8s是一个用于自动化部署，扩展和管理容器化应用程序的开源系统。简单的说它就是一个全新基于容器技术的分布式架构方案，k8s是一个可移植可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置（依据配置信息自动地执行容器化应用程序的管理）和自动化。

简要介绍

F&Q

1，为什么需要k8s？他能做什么？

容器是打包和运行应用程序的好方式但是避免不了容器发生故障，在生产环境中您需要管理运行应用程序的容器并确保不会停机。例如：当一个容器故障停机，另外一个容器需要立即启动以替补停机的容器。类似的这种堆容器的管理动作由系统执行会更好更快捷

k8s针对此问题提供了一个可弹性运行分布式系统的框架，可以使你非常健壮的运行分布式系统。可以处理嘤嘤程序的伸缩，故障转移，部署模式。

2，设计理念？

遵循一切以服务为中心，一切围绕服务运转，微服务架构，简化开发流程和运维成本。

3，什么是容器编排技术？

容器编排技术的定义是预定义流程的执行，与此相应的k8s构建了一系列的相互独立，可预排的控制过程，以持续不断的将系统从当前状态调整到声明的目标状态。

4，K8s提供特性说明？

1，服务发现和负载均衡：通过DNS名称和IP地址暴露容器的访问方式，并且可以在同组容器内分发负载以实现负载均衡。
2，存储编排：可以自动挂载指定的存储系统，例如本地存储/nfs/iscsl/云存储等
3，自动发布和回滚：描述已部署容器的所需状态并将以合适的速率调整容器的实际状态，可以自动执行部署创建新容器，删除现有容器并将其所有资源采用到新容器
4，自愈：重新启动发生故障，替换容器，kill不满足自定义健康检查的容器，在容器就绪之前，避免调用者发现该容器
5，密钥以及配置管理：可以存储和管理敏感信息，例如密码，oAuth Token,ssh密钥等，可以更新容器应用程序的密钥，配置等信息，而无须重新构建容器的镜像

5，K8s不是什么？

k8s不是一个传统意义的PaaS系统。它主要在容器层面上工作而不是硬件层面，它提供了与PaaS相似的通用特性：部署 伸缩 负载均衡 日志 监控。然而k8s并不是一个单一整体，这些特性都是可选的

6，k8s提供了什么？

1，不限制应用程序的类型：k8s目的广泛支持不同类型的工作负载，包括有状态，无状态，数据处理等类型的应用，简单来说，只要能在容器中运行的都能在k8s上运行
2，不部署源码，不编译或构建应用程序：可以作为部署平台参与到CI/CD流程，但是不涉及镜像构建和分发的过程，即持续集成，交付和部署工作流由公司业务及技术要求决定
3，不提供应用程序级服务：包括中间件，数据处理框架，数据库，缓存，分布式存储。此类组件可以在k8s上运行，或者可以被运行在k8s上的应用程序访问
4，不限定日志，监控，报警的解决方案：k8s提供一些阳历展示如何与日志，监控，报警等组件集成，同时提供收集，导出监控度量的一套机制，用户可以根据自己的需求进行选择日志，监控，报警组件。「ELK,Graphana,Pinpoint,Skywalking,Metrics Server,Prometheus」
5，不提供或者限定配置语言：提供一组声明式的API，可以按照自己的方式定义部署信息。「helm/kustomize/kubectl/kuboard/octant/k9s/kubernetes dashboard」
6，不提供或限定任何机器的配置，维护，管理或者自愈的系统
7，实际上k8s不是一个纯粹意义的容器编排系统，因为它消除了容器编排的需求

7，优势&劣势

优势：1，开源；2，轻量级；3，贴近底层；4，弹性收缩；5，负载均衡
劣势：学习成本高

8，k8s版本号格式

x.y.z, x为大版本，y为小版本，z为补丁版本号。

9，如何掌握k8s？

A,入门介绍：k8s基础架构，组件含义类型
B,基础概念：Pod控制器类型，K8s网络通讯模式
C,部署：单节点构建k8s集群
D,资源清单：掌握资源清单的语法，编写pod,掌握Pod的生命周期
E,Pod控制器：掌握各种控制器的特点以及使用定义方式
F,服务发现：掌握SVC原理及其构建方式
G,存储：掌握多种存储类型的特点，并且能在不同环境中选择合适的存储方案
H,调度器：掌握调度器原理，能够根据要求把Pod定义到想要的节点运行
J,安全：集群的认证，鉴权，访问控制，原理以及流程
K,HELM：Linux yum掌握HELM原理，HEMLM原理，HELM模版自定义，HELM部署常用插件
L,运维：修改kubeadm证书可用期限，构建高可用k8s集群
I,开发：k8s自开发实现特殊功能

k8s系统架构

K8s由Borg演变，我们先看一下Borg

Borg组件说明：
    1，BorgMaster:集群大脑，负责组件请求分发，为防止单节点故障，高可用集群副本数据最好是>=3奇数个节点
    2，Borglet:工作节点提供各类资源运行对应的容器，并实时与paxos进行联系监听，如果有请求取出（消费者）去执行该任务
    3，Persistent Store:简写Paxos它是Google的一个键值对数据库
    4，Scheduler:调度器将任务调度的数据写入Persistnent Store而不是直接与Borglet节点进行联系
    5，访问方式：Borgcfg，Command-line Tools,Web Browsers

 K8s系统架构

K8s组件说明：
    1，Master: 
        A,控制平面,Control Plane Components,控制平面堆集群作出全局决策，以及检测和响应集群事件，例如当不满足部署的replicas字段时启动新的Pod
        B,Kube-Api-Server，所有服务请求访问统一入口，基于HTTP协议进行的C/S架构开发；由于HTTP协议本身支持多种请求方式和验证则没有必要采用TCP协议重写
        C,Kube-Controller Manager,控制器组件内部包含多个控制器，并且每个控制器都是一个单独的进程，节点控制器NC,副本控制器RC,端点控制器EC,服务账户和令牌控制器SA&TC
        D,Cloud-Controller Manager,云控制管理器是1.8的alpha特性在未来发布的版本中将k8s与任何其他云集成的最佳方式，他主要用于特定于云平台的控制回路可以想做他与kube-controller-manager类似
        E,Kube-Scheduler,调度器负责任务调度选择合适的节点进行任务分配
        F,Etcd,他是一个可信赖的分布式键值对存储服务数据库，能够为整个k8s分布式集群存储某些关键性数据，并协助分布式集群的正常运转

    2，Nodes:
        A,Kubelet,通过CRI直接跟容器引擎交互实现容器的生命周期管理
        B,Kube-proxy,负责写入规则至Iptables,IPVS实现服务映射访问
        C,Container Runtime,容器运行环境负责运行容器的软件，k8s支持多个容器运行环境docker,containerd,Cri-O以及任何实现k8s CRI容器运行环境接口的软件

 组件浅析

Master节点

Control Plane Components控制平面组件的作用说明

它是集群的控制平台组件，主要负责集群中的全局决策和探测，并且响应集群事件，例如当Deployment的实际Pod副本数未达到replicas字段的规定时，启动一个新的Pod,控制平面组件可以运行于集群中的任何机器上，但为了简洁该组件通常运行在一台无业务容器的机器上

Master节点下组件的介绍

    Kube-apiserver:提供k8s API控制平台的前端可以进行水平扩展
    etcd:支持一致性和高可用的键值对存储组件，k8s的配置信息都在这里
    kube-scheduler:主要用于任务调度，监控所有新创建尚未分派到节点上的Pod，并且自动选择为Pod选择一个合适的节点去运行，影响调度的因素有：Pod的资源需求，硬件，软件，策略限制，亲和和反亲和约定，数据本地化要求，工作负载间的干扰和最后时限
    kube-controller-manager:在主节点上运行控制器的组件，从Logic上来说每一个控制器是一个独立的进程，但是为了降低复杂度，这些控制器被编译到同一个可执行文件并运行在一个进程里，该模块包含的控制器有：节点控制器(负责监听节点停机的事件并作出对应响应)，副本控制器(负责为集群中每一个副本控制对象维护期望的Pod副本数)，端点控制器(负责为端点对象赋值，负责链接Service和Pod)，服务账户和令牌控制器(负责为新的名称空间创建default Service Account以及API Access Token)
    cloud-controller-manager:云控制管理器是1.8的alpha特性，这是将k8s与任何其他云集成的最佳方式。云控制管理器允许将集群连接到云提供商的API,并将与云平台交互的组件 与 仅与集群交互咋组件分离开来即用于特定云平台的控制回路。与kube-controller-manager类似，cloud-controller-manager将若干逻辑上独立的控制回路组合到同一个可执行的文件中，供你以同一进程的方式运行。可以对其执行水平扩展以提升性能或者增强容错能力。

Node节点

Node运行在每一个节点上，包括worker或者master节点，负责维护运行中的Pod并提供k8s运行时环境

组件介绍：

1，kubelet:此组件是运行在每一个集群节点上的代理程序确保Pod中的容器处于运行状态，负责对容器的生命周期进行管理并且与master节点密切关联来实现集群的基本管理工作。
    A,通过多种途径获得PodSpec定义，并确保PodSpec定义中所描述的容器处于运行和健康的状态
    B,Kubelet不管理非k8s创建的容器
2，Kube-proxy:此组件是一个网络代理程序，运行在集群中的每一个节点上，实现k8s Service概念的重要部分。
    A,它维护节点上的网络规则使得您可以在集群内，集群外正确的与Pod进行网络通信，同时也是负载均衡中最重要的点
    B,如果有可用的操作系统包过滤层kube-proxy将使用它，否则kube-proxy将转发流量本身
3，容器引擎：负责运行容器，k8s支持多种引擎：docker/containerd/cri-o/rktlet以及任何实现了k8s CRI接口的容器引擎

关于容器引擎

什么是容器引擎？

创建和管理容器的工具，通过读取镜像来生成容器，并负责从仓库拉去奖项或者提交镜像到仓库

多种引擎介绍：
    
    Docker Engine:开源容器化技术，用于构建和容器化应用程序，包含以下组件，守护进程dockerd,与docker守护进程进行对话的接口的APi,命令行接口CLI客户端使用Docker API通过脚本或者直接命令控制与Dockerd守护进程交互

    Containerd Engine:容器运行环境的核心引擎，可以实现对容器的各种操作和网络和存储配置。提供了标准化接口，方便各平台集成，并且还可以将运行环境做成可插拔。

K8s插件

描述：插件使用K8s资源实现集群功能，因为这些插件提供集群级别的功能，插件中命名空间域的资源属于kube-system命名空间。

常用k8s插件

    CoreDNS:可以为集群中的SVC创建一个域名IP的对应关系解析，实际上就是一个DNS服务器和环境中的其他DNS服务器一起工作，它是实现负载均衡最重要的一环，所有k8s集群都应该有Cluster DNS，在容器启动时为k8s服务提供DNS记录即自动将DNS服务器加入到容器的DNS搜索列表中
    
    WEB UI:Web管理界面，通过该界面管理集群中运行的应用程序以及集群本身进行故障排除
    
    Kuboard:基于k8s的微服务管理界面，较于Dashboard来说kuboard的特点，无须手工编写YAMl文件，微服务参考架构，尚贤文相关的监控，场景化的设计

    Container Resource Monitoring:将容器的度量指标记录在事件序列数组中，并提供了UI界面

    Cluster-level Logging：机制负责将容器日志放到一个统一存储，并提供搜索浏览的页面

    Prometheus:提供k8s的监控，将关于容器的一些常见的时间蓄列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面

    ELK：k8s集群日志统一分析平台，负责将容器的日志数据保存到一个集中的日志存储中，该存储能够提供搜索和浏览

    Federation:提供一个可以跨集群中心多k8s统一管理功能

    Ingress:官方只能实现四层代理，但是它实现了七层代理，例如Ingress-Nginx等前端代理

小结

描述：前面我们说了k8s能够对容器化软件进行部署管理，在不停机的前提下提供简单快速的发布和更新方式，k8s是自动化部署，缩放，以及集装箱应用管理一个开放源码的容器业务流程引擎

下面描述的是拥有一个Master和六个Worker的k8s集群，可以通过平面化查看其他k8s组件展示：
    
    Master:负责管理集群以及协调集群中的所有活动
        
        Kube-apiserver,kube-controller-manager,kube-scheduler，其负责Pod调度，弹性收缩，以及应用程序安全控制，维护应用程序的状态，扩展和更新应用程序

    Worker:作为集群中的工作节点运行真正的应用程序，简单的说他就是充当k8s集群中的工作计算机

        每个Worker运行一组进程：Kubelet,Kubelet-Proxy，他们负责创建Pod,启动监听，重启，销毁以及实现应用的负载均衡
        
        每个Worker节点还安装了用于处理容器操作的工具，例如docker或者container.io

        工作负载是在k8s运行的应用程序

工作负载

描述：工作负载是在k8s上运行的应用程序

Pods

描述：Pod是学习k8s最重要也是最基础的概念

Q：Pod的定义？什么是Pod?

A：Pod是可以在k8s中创建和管理的最小的可部署的计算单元，简单的说它是k8s系统node节点中的最小组成单位，k8s设计pod对象是为了将服务进程包装到相应的pod中使其成为Pod中运行的容器。Pod通常运行在Node节点上，在k8s中，Pod代表的是集群上处于运行状态的一组容器。Pod共享上下文包括一组Linux名字空间，控制组和可能一些其他的隔离方面，即用来隔离Docker容器的技术。并且在上下文中，每个独立的应用可能会进一步的实施隔离。Pod是特定于应用的逻辑主机，其中包含一个或者多个应用容器，这些容器是相对紧密的耦合在一起。



实现原理

描述：在每个Pod运行之前会首先启动一个特殊的Pause容器或者叫做Pod的根容器，只要Pod建立都有他，而其他容器则为业务容器共享该Pod的Pause容器的网络栈（localhost）以及Volumn(共享存储)即Pod中的每个容器共享网络名字空间，包括IP地址和网络端口，在同一个Pod内，所有容器共享一个IP地址和端口空间。并且可以通过localhost发现对方，他们也能通过如SystemV信号量或者POSIX共享内存这类标准的进程间方式互相通信

Q:Pause容器作用不言而喻？

A:1,引入与业务无关并且不易死亡的Pause容器作为Pod的根容器，解决整体检测及判断行动有效或无效的问题，其状态代表了整个容器组的状态；2，共享网络栈和存储栈

Q:容器的特权模式？

A:Pod中的任何容器都可以使用容器规约中的安全性上下文中的privileged参数启用特权模式。这对于想要使用操作管理权能的容器很有用。容器内的进程几乎可以获得与容器外的进程相同的特权。

Q:Pod异常处理调度机制？

A:1,默认情况下，当Pod里的某个容器停止时，k8s会自动检测到这个问题并重新启动该Pod；2，工作节点宕机的情况下，则会将该Node上的所有Pod重新调度到其他节点上


补充说明：

1，Pause 容器对应镜像属于k8s平台的一部分，出了Pause容器外每个Pod还包括一个或者多个紧密相关的用户业务容器；
2，同一个Pod中的服务端口不可重叠使用，例如Nginx使用80端口，则tomcat只能使用8080，否则可能导致容器无法启动或者重复启动
3，Pod中除了Pause容器，应用容器黑可以包含在Pod启动期间运行的Init容器，其三者关系时Pause容器》Init容器

Pod分类

根据学习使用和功能特征，分为两类Pod

1,单实例Pod，不被控制器管理的Pod，一旦死亡便不能自动化切换或者根据期望值进行创建Pod

2,控制器创建的Pod：使用工作负载资源及其控制器以实现应用的扩展和自动修复

    A.RC：用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出将会自动创建新的Pod来替代，而如果异常多出来的容器也会自动回收
    B.RS：他与ReplicationController没有本质的不同只是名字不一样，在新版k8s中建议用RS代替RC，但是RS支持集合式的标签selector，虽然他可以独立使用，但是建议采用Deployment来自动管理RS，这样做的好处是无需担心跟其他机制的不兼容的问题，例如RS不支持回滚更新，但是Deployment支持
    C.Deployment：他为Pod和Rs提供了一个声明式的定义方法，用于替代以前的RC来方便管理应用其典型的应用场景如下：定义Deployment来创建Pod和RS，滚动升级与回滚应用，扩容和缩容，暂停与继续Deployment
    D.StatefulSet：为了解决有状态服务的问题(前面的Deployment和RS是为了无状态服务而设计)其利用场景包括如下:
        a,稳定的持久化存储，即Pod重新调度后还能访问到相同的持久化数据基于PVC来实现；
        b,稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service即没有Cluster IP的Service来实现；
        c,有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行(即从0->N-1在下一个Pod运行之前的所有值钱的Pod是必须Running和Ready状态)，他们是基于Init Containers来实现；
        d,有序收缩和有序删除(从N-1->0)
    E.DaemonSet:确保在全部或者一部分Node节点上运行一个Pod副本，当有Node加入集群时也会为他们新增一个Pod,当有Node从集群中移除时这些Pod也会将被回收，当删除DaemonSet将会删除他创建的所有Pod，例如下面的典型用法：
        a,运行集群存储Daemon，例如在每个Node上运行Glusterd,Ceph;
        b,在每个Node上运行日志收集Daemon；例如Fluentd,logstash;
        c,在每个Node上运行监控Daemon；例如Prometheus Node Exporter;
    F:Job:负责批处理任务即仅执行一次的任务，他保证批处理任务的在一个或者多个Pod成功结束，常用于数据备份
    G:CronJob:管理基于时间的job即在给定的时间点只运行一次，周期性的在给定时间点运行
    H:HPA:仅适用于Deployment,RS在V1版本中仅支持根据Pod的CPU利用率来进行扩容，在V1-Alpha版本中就是仅仅支持根据内存和用户定义的Metric扩缩容

F&Q

Q：什么事Rolling-update?以及什么是rollbacks-update（undo）？

A：滚动更新，即新版本替换旧版本，但是旧版本容器并未被删除而是被暂停；回滚更新，即线上版本回滚前一个或者某一个版本；

Q：服务分类（资源清单）？什么是有状态服务？什么又是无状态服务？

A：有状态服务，DBMS，暂停或者离开某段时间后返回到集群中无法正常工作，由于这段时间内有新的数据产生；无状态服务，LVS APACHE，暂停或者离开某段时间后返回到集群中仍然可以继续的正常工作，可以把它比作如流水线的管理人员，其离开一会并不会导致流水线作业停止

Q：Deployment与RC之间的关系？

A：Pod创建并不是由RC直接创建而是由Deployment进行创建，并且RS也是由Deployment创建的，Pod与RS都是由Delpoyment创建

Q：有序部署扩容与删除缩容注意事项？

A：在同一个Pod中各项目容器的启动顺序可能有一定的关联，例如Mysql->Tomcat->Nginx当缩容时也需按照相应的反向顺序进行关闭

资源清单

描述：k8s所有的资源对象的定义和描述采用了yaml或者json的文件格式，将其比喻作剧本即k8s按照要求定义进行相应资源的增删改查

以下是k8s资源清单定义中必不可少的四个对象：
    
    apiVersion 对象资源版本
    Kind 对象资源
    metadata 对象资源原数据
    spec 对象资源详细描述
    labels 资源对象标签


Labels:

描述：Labels是k8s中另外一个核心概念，它是一个KV键值对其可以附加在各种资源对象(Node,Pod,RC,RS,Deployment,Service)之上的定义，并且一个资源对象可以定义多个Label标签（多对多的关系）

作用：为指定资源对象绑定一个或者多个不同的Label来实现多维度的资源分组管理功能，以便灵活，方便的进行资源分配，调度，配置和部署等；例如在Node中可以利用标签来设置Pod的亲密性，在RS中利用匹配的标签来检测拥有该标签的数量保证Pod数量满足副本数，在SVC中利用标签可进行选择Pod进行负载均衡

例子：

版本标签：“release”:"stable"
环境标签：“environment”:"dev"
架构标签：“tire”:"backend"
分区标签：“partition”:"customer"

Selector:

描述：有了标签Label后我们还需要配合标签选择器，来进行标签的查询和筛选使之分配给该标签的资源对象相应的资源，或者说绑定相应的资源，使该方法类似于Sql对象查询机制

如何使用标签以及选择器：通过标签选择器Label Selector查询和筛选拥有某些Label的资源对象，而k8s通过类似于sql的简单而又通用的对象查询机制，通过采用等事类和集合类两种方式进行匹配在Node,Pod,RS,Service中的标签

例如：Label为name=nginx附加到一个Pod时，那么对应的Label Selector表达式类比于Sql语句：SELECT * FROM POD WHERE Pod_name = "nginx"

匹配规则：

等式类：name = redis-app, env != product
集合类：name In, name Notin, name Exists, name DoesNotExists

使用标签的方式1:

apiVersion: apps/v1 #k8s集群版本 kubectl api-versions
kind: Deployment
metadata:
    name: nginx-deployment # deployment名称
    labels: 
        app: nginx
        enviroment: test
spec: # deployment描述，该deployment在k8s中将如何作用
    replicas: 1
    selector: # 与Pod模版的标签共同作用
        matchLabels: # 基于等式匹配
            app: nginx
        matchExpressions: # 基于集合匹配
            - {key: name, operator: In, value: [web-app]}
    template: # Pod模版
        metadata:
            labels: # Pod副本拥有的标签，上面的selector即选择包含标签app:nginx的Pod。有了它我们的deployment控制器才能知道匹配的标签已经有一个Pod在运行了
                app: nginx
                name: web-app
        spec: # Pod实现的功能
            cpntainers:
            - name: nginx
              image: nginx:latest

方式2: 通过annotations的方式也能进行标签选择匹配

资源对象注解-annotations

描述：上面我们说过除了使用标签将元数据附加到k8s对象，你还可以使用k8s注解为对象附加任意的非标识的元数据，客户端程序能获取这些原数据


哪些信息可以使用注解来记录？
1，由声明性配置所管理的字段。将这些字段附加为注解，能够将他们与客户端或者服务端设置的默认值，自动生成的字段以及通过自动调整大小或者自动伸缩系统设置的字段区分开
2，构建，发布或者镜像信息，如时间戳，发布ID,Git分支，PR数量，镜像哈希，仓库地址
3，指向日志记录，监控，分析或者审计仓库的指针
4，可用于调试目的客户端或者工具信息，例如名称，版本和构建信息
5，用户或者工具的来源信息，例如来自其他生态系统组件的相关对象Url
6，负责人的电话，或指定在何处可以找到该信息的目录条目，如团队网站
7，轻量级上线工具的元数据信息，例如配置或者检查点
8，从用户到最终运行的指令，以修改行为或使用非标准功能


注解中的元数据，可以很小也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符，请注意注解语法和标签一样都是键值对，必须是字符串，换句话说，你不能使用数字，布尔值，列表或者其他类型的键值。例如：

“metadata”: {
    "annotations": {
        "key1": "value1"
    }
}

再一个例如：

apiVersion: v1
kind: Pod
metadata:
    name: annotations-demo
    annotations:
        imageregistry: "https://hub.docker.com/"
spec:
    containers:
    - name: nginx
      image: nginx:1.7.9
      ports:
      - containerPort: 80

Service

Q:什么是Service服务发现，为什么需要Service?

A:在k8s中Service服务是分布式集群架构的核心，一个Service对象主要拥有如下功能特征拥有一个唯一的名称以及拥有一个虚拟IP(ClusterIP/ServiceIP或者VIP)和端口号将Pod中的服务进程服务（容器）进行映射以便客户端访问；简单的说，Service通常有多个相关的服务进程来提供服务并且每个服务进程都拥有一个独立的Endpoint访问点，k8s能够让我们通过Service(虚拟ClusterIP+ServicePort)链接到指定的Service上，并且Service本身一旦创建将不再改变；作用：通过K8s内建的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否会由于发生故障而重新部署到其他Node上，都不会影响我们对服务的正常调用，就不必再为服务IP地址的变化而无法访问的头疼问题

Q:K8s如何使用Service服务发现原理？

A:为了建立Service与Pod之间的关联关系，K8s首先会给每个Pod贴上一个Label，它也是k8s中非常重要，例如app=redis标签，然后给相应的Service定义标签选择器；例如Redis Service的标签选择器的选择条件为app=redis，意思就是为该Service要作用于所有包含app=redis的label的Pod上，这样就解决了Service和Pod的关联问题

 NetWork

描述：在k8s的网络模型假定了所有的Pod都在一个可以直接连通扁平化的网络空间中，例如在GCE里面是现成的网络模型，而在私有云单肩部署k8s集群的时候需要我们自己设置网络通信，将不同节点上的docker容器之间的互相访问先打通然后再运行k8s这是因为Pod Service间的网络是私有虚拟的网络

Q:Pod间的网络通讯模式？

A:各Pod之间的通讯是采用Overlay Network覆盖网络即虚拟网桥Bridge实现Pod与Service之间的通信是通过iPtables底层一队的转换机制实现

Q:不同情况下的网络通信方式我们以Flannel为例

A:1,同一个Pod内部通信：前面我们说过同一个Pod共享同一个网络命名空间与共享一个Linux协议栈，简单的说就是同一个Pod的多个容器之间通过lo回环网卡实现访问；2,不同的Pod的通信：假设Pod1和Pod2不再同一台主机上，Pod的地址是与Docker0在同一个网段的，但是Docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同的Node之间的通信只能通过宿主机的物理网卡进行，将Pod的IP与所在的IP关联起来通过它将会让Pod进行互相访问；假设Pod1与Pod2在同一台机器上由Docker0网桥直接转发至Pod2而无需经过Fannel；Pod与Service网络：目前全部采用iptables维护和转发，但是可以利用LVS组件进行替换；Pod到外网：Pod向外网发送请求查找路由表然后转发数据包到宿主机的网卡，宿主机网卡完成路由选择后Iptables执行Masquerade把源IP地址更改为宿主机网卡的IP(NAT转发)然后再向外网服务发送请求；外网访问Pod:通过Service映射的端口

K8S网络解决方案

A. K8s + Fannel

B. K8s + Calico