Kubernetes架构全图

7-1回顾总结

介绍部署模式变迁，体验k8s集群

介绍k8s架构：maset,nodes

介绍k8s对象，具体介绍了pod和控制器；configMap和secret

6-4  常用的工作负载类、配置和存储类对象讲解

Pod的生命周期

phase:是Pod生命周期所处位置的概括，从phase的值可以反映Pod生命周期形态

Pending:挂起，创建,部署阶段,pod已经被k8s集群接受，但有一个或多个容器镜像尚未创建，即Pending阶段是通过网络下载容器镜像，调度Pod等 等待时间

Running Pod已经绑定到一个节点上，Pod中所有容器已经被创建，并且至少有一个容器正在启动或运行或重启

Succeed 此时Pod所有容器被成功终止，并且不会再重启

Failed Pod容器都已经被终止了，并且至少有一个容器因失败而终止，即容器以非0状态退出导致系统终止的

（被废除的unknown:以未知原因无法取得Pod状态）

---

Service：服务发现，负载均衡Load balance的核心对象

前言：Pod是一个非持久性的实体对象，通常会由各种原因被终止，每次重启ip地址都会改变，所以Pod的ip地址是不能被稳定依赖的；问题来了，pod的ip地址不可靠前提下，我们怎么发现并连接到Pod呢，于是有了Service抽象概念。

Service：与云原生应用的“微服务”概念一一对应

    k8s为每个Service分配一个集群唯一的IP地址，在Service生命周期内，ip地址不变；在内部DNS支持下，能轻松实现服务发现机制。

    Service通过label seletor关联到实际支撑业务的pod上，并通过集群内置的服务负载均衡将服务请求分发到后端Pod；即调用者无需关心pod状态如何，是否创建，pod的ip是否发生了变化。

    通过nodeport或者设置load balancer（负载均衡？）还可以实现将service暴露到集群外部。

k8s还支持多重昂service，比如没有seletor的service，比如不需要分配ip不需要负载均衡的service（高级话题）

---

Controllers：与Pod关联最为紧密的控制器对象，控制器对象就是为Pod保驾护航的。

    各种控制器就是为了保证一组Pod始终保证处于期望状态（desired state）正常运行。期望状态包括：Pod副本数量，节点选择，资源约束，持久化数据维持等...

    常用的控制器：deployment、replicaset、statefulset、daemonset等

        replicaset：副本集合控制器，确保健康Pod数量始终满足用户定义的数量。

            它的前身是ReplicationController(rc),新版RS支持集合式的label selector标签筛选（等优势？）

            虽然想Pod一样可以手动创建，但官方推荐使用deployment创建并由其自动管理replicaset，这样就可以不用担心兼容问题，比如repllicaset不支持滚动更新，但deployment支持。

        deployment:是k8s最常用的控制器，它为Pod和ReplicaSet提供了声明式定义（yaml）。声明式的意思是，描述他们状态是怎么样的，而不是说描述他们的创建步骤和方法。

            用户在deployment描述Pod和ReplicaSet的期望状态，DeploymentControlller就会自动将他们改变到期望（不要尝试手动修改由deployment自动创建的ReplicaSet,否则可能会引发未知后果）

            周所周知，Deployment支持Pod的滚动更新，并自动管理背后的ReplicaSet,例如更新Pod模板、规格字段来升级Pod新状态时，Deployment会自动创建新的ReplicaSet,Deployment会根据控制速率将Pod旧的ReplicaSet移动到新的那里。以实现ReplicaSet的滚动更新。

            Deployment支持Pod回滚，但仅由pod模板（Pod-template）改动的行为触发的版本升级。

---

StatefulSet:Deployment,ReplicaSet等控制器,他们仅用于无状态应用的部署和管理，对于有状态应用，v1.5后k8s提供了StatefulSet提供支持

v1.9毕业，说明可以在环境中可以正常使用了。保证了产品的先后兼容。

为了解决有状态服务的部署问题，例如需要

稳定的的持久化存储，集合的Pod被重新调度后，还是能访问到相同的持久化存储的。

稳定的网络表示；Pod重新调度后，即PodName等标签不变，

有序部署扩展：Pod是有顺序的，Pod在部署或扩展的时候，要根据定义的顺序依次进行，

有序收缩，删除：Pod在被删除收缩等过程中，也要根据定义的顺序依次进行，

有序自动滚动升级等：和有序收缩一样，依据定义的顺序依次进行，每次升级一个Pod，只有一个Pod完成升级才会进行下一个。

Pod的存储必须由RersistentVolume Provisioner根据请求的Storage Class进行配置，或由管理员预先配置好。

考虑到数据安全性，伸缩或删除StatefulSet不会删除关联的存储；另外StatefulSet要求没有class ip的Headless Service负责Pod的网络身份，用户有责任创建此类服务。（高级话题）

---

DaemonSet:特殊的控制器，保证在每个Node上都运行一个Pod副本，当增加/溢出Node，会自动增加/收回Pod副本，删除DaemonSet会删除它创建的所有Pod

    适用于：系统Daemon程序sifvillike组件，监控跟踪clkD，日志收集runD等

    1.6以后支持滚动更新

    支持通过nodeSelector、nodeAffinity、podAffinity来选择需要部署的Node，当Node的标签发生变化时，DaemonSet会重新匹配Node，并在新匹配的Node上部署Pod副本并将原有的但此次为匹配到的Node的Pod副本删除。

---配置和存储类对象

ConfigMap：允许我们将配置信息与容器镜像内容解耦，这样可以保持容器化应用镜像的可移植性，没有必要因为配置的变动而重新制作容器镜像，常用来想Pod提供非敏感的配置信息。

    configMap用于保存配置数据的键值对，可用来保存单个属性、配置文件

    configMap可以用命令行基于字面值，文件或目录来创建或通过configMap对象定义文件yaml创建。

    configMap可以通过三种方式在Pod中使用：环境变量，容器命令行或以文件形式通过数据卷插件挂在到Pod中。

示例：configMap的常见和使用

定义kind:configMap的yaml，里面定义属性配置data.title,data.authtor

定义一个kind:Pod的yaml,并将之前的配置信息以环境变量的形式使用

启动pod，查看输出

---

Secret使用上与ConfigMap类似，不同的是它解决是集群内密码，token,密钥等敏感数据的配置问题

    应用场景：鲳鱼ServiceAccount关联，存储在tmpfs系统，Pod删除后Secret文件也会对应地删除。

    有三种Secret:

Opaque:64编码格式的secret,存储密码密钥，

Service Account：在pod中访问k8s api服务的，有k8s自动创建。并挂载在到Pod指定目录中去，

dockerconfigjson：用来存储私有docker镜像仓库的认证信息，

    secret可以以volume或环境变量方式使用。

6-3 k8s对象分类

工作负载类，k8s主要去管理和运营的对象。

发现和负载均衡类：与服务相关的类对象。

配置和存储类：向应用中注入初始化配置数据，或将数据持久化保存到容器外的对象

集群类cluster：定义了集群自身该如何配置的数据，通常由集群管理员进行操作。

---

工作负载：核心工作负载对象Pod，其他对象都是为Pod提供功能服务的。

controller控制器用于维护Pod状态，配置和存储对象为Pod注入了初始化数据，并持久化Pod运行时产生的数据；

Service将Pod聚合在一起，统一为集群内外提供服务。

Pod：集群调度基本单元。有特定关系的容器集合，比容器更高级别的抽象。是k8s中可以创建，部署的最小对象单元。

    一个Pod就代表了集群运行的一个进程

    一个Pod也是一种封装。应用容器，存储资源，独立网络IP和决定容器如何运行的策略选项。

    每个Pod内置一个Pause容器，它的名字空间，IPC自选，网络和存储资源被Pod内其他容器共享，是Pod实现容器资源共享的基础。Pod中的容器可以通过localhost相互访问，Pod作为一个整体被管理。

Pod生命周期：

     Pod是一个非持久性实体，节点故障，缺少资源等情况下Pod可能会被驱逐出存在节点，所以不建议手动创建Pod，而是用控制器创建，自动管理Pod，更加方便，而且自动管理还包括控制器对Pod的自动伸缩。

6-2 Metadata

k8s对象中Metadata是最常见的静态属性

    Name和UID：所有对象都由Name和UID明确标识。

        同一类的对象中，Name唯一；

        不同类的对象中，Name可以一样；

        不同名字空间在，Name可以一样；

        某个Pod叫“Hello k8s”，某个deployment也可以叫“Hello k8s”

        每个对象部署后，有一个唯一标识UID，该UID在k8s集群整个生命周期范围内都是唯一的，为了与历史部署过的同名对象做区分。

        API可以通过对象名字访问，通用路径：/api/{version}/namespaces/{namespace}/{object-kind}/name

如：/api/v1/namespaces/default/pods/hello-k8s

    Namespace：不仅是一个属性，本身还是一个object

        提供独立的命名空间，将物理集群划分为多个虚拟集群，对象的名称（spec.name）在同一个名字空间内是唯一的

        namspace间互相独立，所以常用来隔离不同的用户和权限

        k8s有三个内置的namespace,

            default:默认的

            kube-system:平台组件部署的，api server,dns插件,网关插件等

            kube-public:自动创建，供所有用户访问，包括未经过身份验证的用户访问，它主要还是为集群自用创建的，以便资源在集群中公开可见可读。

            Node,PersistentVolume不属于任何namespace。

    Label：k8s原对象都有的元数据属性，用于建立集群对象之间松耦合的关联关系。

        一个Label就是第一个键值对。只要符合标签语法规定即可

        label可以附着在任何对象上，任何对象都可以有任意标签；label既可以定义对象时附加，也可以管理对象时操作标签。标签不是唯一的，很多对象可能有相同的标签（这不废话吗？？？）

        label可以将结构映射到集群对象上，形成一个与现实管理结构同步的，松耦合的，多为的对象管理结构。因此我们不需要在客户端存放这些关系。通过selector的查询和筛选建立这种松耦合的管理关系。

        示例：生产环境服务service1,上线前测试的内部服务service2；

service1,service2分别通过selector关联了不同的pod(2)。pod2,3,4；pod1(pod提供后端服务支撑)

pod2,3,4；pod1分别通过selector关联了不同的node(s)。node2,3;node1（k8s普通节点提供服务调度运行）

    这样，通过多层次多维度的标签定义，一个对应现实管理结构的对象关系就建立起来了。不同角色可以在同集群完成不同工作，互不影响。

---

    Annotations：将任意非标识性元数据附加到对象上，这是与标签的区别，标签数据是用于标识对象的数据，用于选择对象，annotations不能用于标识，选择对象。

        annotations也是键值对形式出现，可以是结构化或者非结构化，甚至可以包含标签中不允许出现的字符。常见可以记录在数据的注解中的信息包括：创建，版本，debug后端信息等等。例如时间戳，版本号，对象哈希值.等等；用户，工具，系统信息等

        工具和库可以检索并使用这些Annotations元数据，以实现逻辑

        将数据作为注解注入对象，有利于创建用于部署，管理和内部检查的共享工具或客户端。

6-1 k8s基本概念

是深入学习k8s的基本条件

pod，deployment等，有一个共同的抽象称呼，k8s object

k8s对象：一种持久化，用于表示集群状态的实体

    声明式的记录，一般用yaml描述对象

    k8s对象的集合即表示当前k8s的状态。k8s对象可以表示，有哪些容器化应用在运行，容器运行在哪个node上，有哪些可以被应用使用的资源，应用的行为策略是这么样的，例如重启，升级，容错策略等

    k8s对象通过api来管理；kubectl其实也是调用api来实现命令功能的，通过api可以实现对象的增删改查；管理k8s对象的过程就是管理，运维k8s的过程；k8s controller manager就是通过对象控制器使对象保持在期望状态，换句话说，k8s的工作就是让k8s对象保持在期望状态，这样k8s集群本身就在期望状态了。

k8s对象模型，面向对象

静态属性：

    Kind：对象类型，如Pod,Service

    Metadata:元数据

    Spec：对象规格信息，不同对象的spec不同，可以参照面向对象基类与子类的关系

操作方法：

    增删改查，Create,Get,Update,Delete,每种对象都有这些方法，通过API可以对对象的方法进行调用

动态信息：

    k8s对象的创建就好比如一个类被实例化了，状态变成动态信息保存在etcd中，k8s状态的变化是触发k8s各组件工作的起点，k8s的工作就是讲k8s对象一直保持期望状态。

5-3 node组件

除了安装了master组件的Node，其余node都会承载工作负载，安装容器引擎和其他的组件kubelet,kube-proxy;master node上也安装了Node组件，它负责组件的生命周期 ，服务抽象的管理；

master组件自身也是运行在pod中的；

Node：是K8s集群中真正的工作负载节点

    （普通节点组件是每个节点必须安装的组件，master节点也不例外）

    k8s集群由多个node共同承担工作负载，pod被分配到某个node上执行（实例见识过了）

    k8s通过node controller对node资源进行监控管理，支持动态添加删除node

    每个集群的每个node上都会部署kubelet和kube-proxy

---

kubelet:节点的基础组件，无论是master还是普通node节点都会部署

    每个节点启动会拉起kubelet，管理组件的生命周期唯一一个非容器形式的服务进程组件；

    通过api server监听etcd的pod的数据变化，获取归属该节点的pod清单，本地容器引擎交互实现pod的生命周期管理，（master处理所有控制，所以所有指令都是从master过来的，即以kubelet为桥梁，通过master的etcd信息来伸缩一般nodes的pod）

    通过api server注册node信息

    监控node资源占用状况，定期向master汇报；

---

kube-proxy:他也是在节点启动时被拉起

    提供service抽象概念，将service的请求负载均衡到pod，即kube-proxy是service的代理和负载均衡器

    proxy分发策略从用户型代理功能编程了现在的iptables mode,不是在用户层监听端口了

    支持nodeport mode，将集群暴露，从外部访问集群内的service

5-2 Master组件

Master组件是K8s Pod集群逻辑上的控制中心（一个Pod有若干个master节点和若干个普通nodes节点）

master内基本组件：API Server;Scheduler;Controller Manager;Etcd;

Master组件是K8S的Pod集群的控制平面：

    每个pod集群的控制命令都会传递到master组件并执行；

    每个k8s的集群都至少有一套master组件，如果master组件失效，怎么失去对k8s pod集群的控制，所以一般会定义多个master组件实现k8s集群的高可用控制能力。

    每个master组件都包括api server, scheduler,controller manager三个组件和一个etcd配置中心数据库

---

API Server是master组件的中枢（之所以说控制命令都要经过master，最主要是因为master内的API Server），master中其他组件都通过API Server的API接口实现各自的功能，

    是提供k8s集群控制RESTFUL API的唯一组件，即集群控制的唯一入口；

    是集群内，各个组件通信的中枢；（不仅内外通讯，而且内内通讯也要经过API Server）

    只有API Server（master节点）才能与Etcd通讯（增删改），其他组件只能通过API Server访问执行状态？？？（非master访问Etcd只能得到状态信息？？？:查）

    API Server提供集群控制的安全机制

---

Scheduler

    先通过API Server的Watch接口监听到新建Pod副本信息后，通过调度算法为该Pod选择一个最合适的Node

    支持自定义调度算法

    默认调度算法先预选再优选

---

ControllerManager

    集群内部的管理控制中心，管理k8s对象模型之一Controller

    针对每一种具体资源都有相应的controller，而controllerManager管理每个controller，使旗下的资源始终处于“期望状态”；每个controller通过API Server提供的接口，实时监控每个资源对象的当前状态。

  （每个controller的运行逻辑：获取资源期望状态，获取资源当前状态，将当前状态转变成期望状态）

---

Etcd 是k8s集群主数据库，保存资源对象和状态信息

    默认与master组件部署在一个node上；如果希望在生产环境部署高可用的k8s集群，就要先部署高可用的Etcd集群，作为k8s的后端数据库

    Etcd的数据变更，安全管理通过API Server进行，k8s各个组件实时通过API Server的Watch接口跟踪比对Etcd资源期望状态和实际状态的差异，自动恢复资源到期望状态，实现资源控制的目的，手工修改Etcd的数据是不被推荐的

5-1 k8s架构全图解释

k8s集群是由一组节点nodes组成，节点可以是物理服务器，可以是虚拟机，k8s平台就运行在这些节点上面；

每个节点上都安装了node组件(kubelet,kube-proxy),

其中安装了master组件的叫作master node,老版本也成为miniNodes，他们是真正运行负载的节点。

miniNodes的node组件的kubelet跟master node交互，维护miniNodes的pod的生命周期。

数据存储中心 etcd,是一个数据库,存储了所有对象和状态

集群维护的命令行工具kubectl,用户以命令行方式与集群交互，操作集群

4-1 演示service,pod的部署，pod伸缩等功能

官方推荐先部署service再部署Pod，因为部署容器pod的时候，会把service信息以环境变量的形式注入到pod，

官方推荐用内部DNS域名访问service，而不推荐用环境变量访问，兼容了以前必须依赖环境变量访问的应用。

k8s常用yaml定义对象

（注意：k8s总是安装在linux,所以熟悉Linux命令是基础）

yaml常见键值对意义：

apiVersion:当前yaml使用的api版本

kind：声明对象类型

metadata：

    name:定义元数据的name

spec:规格说明

    type:声明kind的类型，NodePort将服务暴露到k8s集群之外

    selector：跟label xxx匹配后选项

        app:......

ports:一组poort,跟spec.type对象，用NodePort表示这里的port是每台node监听的端口，

    port：虚拟的端口，不真实存在

    targetPort：容器监听的端口，到达service的流量会被负载均衡到targetPort上

    nodePort：向外暴露的访问端口，外网访问的就是它

通过create命令创建service服务

kubectl create -f 配置文件.yaml --record

通过get命令查看命令是否创建成功了

kubectl get svc|grep 服务名

通过describe查看详细信息

kubectl describe svc/服务名

（如果没有部署pod，那么Endpoints对象为none）

如果此时访问：curl ip地址:nodePort/服务，就会被refused拒绝

---

k8s服务有自动注册，发现机制，通过内部DNS供多服务发现，交互

使用run命令启动busybox容器查看服务内部发现地址，即内部域名

kubectl run -i --tty busybox --image=busybox --restart=Never

在busybox使用nslookup命令查看DNS地址

nslookup 服务名

---

部署pod

官方推荐不直接部署pod，而是通过deployment controller部署pod,(怕我们配置得不完全吧？)

linux查看定义好的deployment controller的yaml配置文件

vi 文件名

spec:

    replicas:   部署后pod的个数

    template:pod的模板类型,子对象都是模板的具体配置信息

        metadata：模板元信息

            labels:  通过这个label匹配pod

                app:

        spec：是pod的规格信息，包括容器的名字，镜像信息，镜像拉取...

通过kubectl的create命令创建deployment

kubectl create -f hello-deployment.yaml --record=true

通过get命令查看deployment创建结果

kubectl get deployments

出现一个列表，desired:期望的pod的副本数，current：当前存在pod的副本数，up-to-date:升级到最新的副本数，available:可以给客户提供服务的pod副本数，age：部署了多久

再敲一次查看服务详情，可以发现EndPoint有两个pod的地址了

再访问一次service,接收请求并通过自动选择容器处理服务逻辑，并响应请求

---

测试pod的负载均衡

先查看pod信息

kubuctl get pods|grep 服务名

复制pod名，新开命令行，实时监测运行日志的查看pod在接收到请求后的处理信息

kubuctl logs -f pod名

再通过curl发起多次请求,

---

服务伸缩

根据服务流量大小改变pod的副本数，可以自动？

手动修改pod的副本数，直接修改depoloyment配置文件：

使配置文件生效命令：

kubectl apply -f 配置文件

查看pod副本命令：

发起多次请求

---

服务的版本升级和回退

spec.template.spec.containers.image是容器版本，可以手动修改，

保存，再apply生效

然后用rollout status命令升级容器

kubectl rollout status deployment/xxx-deployment

发出请求，查看pod的版本信息

undo命令是回退到上一版本：

kubectl rollout undo deployment/xxx-deployment

发出请求，查看pod的版本信息

4-1 k8s集群初体验

居然说这个DEMO相当于编程语言的Hello world?

这是一个单service的应用，service后面是若干个实际支撑的Pod，Pod由Deployment控制器进行部署 外部发送到Hello Service的某个请求被自动负载均衡到某个Pod业务容器，容器返回Hello Kubernetes字样的应答。

演示环境：一个master,两个node

kubernetes集群v1.7.3;镜像仓库hub.docker.com;

kubernetes 提供的kubectl命令kubectl get nodes获取集群的节点列表

3-3

云原生应用的k8s相当于传统云平台应用的linux，或者说，k8s就是云平台的linux

3-2

k8s是容器编排管理平台

相对于传统的虚拟化技术，容器技术在镜像大小，执行效率，资源利用率方面都有较大优势，但是单一容器并不能给开发者带来太大帮助，从虚拟机过度到容器显得没有必要，多容器需要并发协同工作，支持跨主机管理才有意义，我们需要一个多容器管理平台，k8s是解决方案之一。

管理特点：pod，controllers,configmap,secret等；资源配额与分配管理；健康检查，自愈，伸缩，滚动升级。

k8s是微服务支撑平台

k8s采用微服务架构，

支撑特点：服务发现，服务编排，路由支撑；快速部署，自动负载均衡；对有状态服务的支持。

k8s相当于新一代openstack,是可移植的云平台

docker将k8s集成到调度引擎等等，k8s成为通用层

平台特点：为用户提供简单一致的应用部署，伸缩，管理机制；云上应用可以跨云迁移或混用云供应商。

为什么选择k8s作为容器标准

生态角度：成熟先进；传统云供应商全面支持

功能角度：使应用摆脱锁定，支持跨云；先进的Pod，Controllers管理模式；支持微服务抽象：服务注册，发现和自动负载均衡

3-1 k8s是什么

功能角度，容器的管理平台；应用角度，微服务的支撑平台；生态圈角度，可移植的云平台。

2-1

模式变迁：

从前，以物理机为基本单元管理应用。想部署新应用，需要购买一台/一组新的物理机器,应用直接在物理机上构建部署，运行，大多数都是一对一定制版。

代表：IBM,Sun

然后，为了提高计算机资源利用率和降低使用应用成本，以拆分物理机，聚合离散计算机资源的方式，将一台物理机拆分成若干个虚拟机，即虚拟机作为基本计算单元管理应用。

解决方案代表：VMware,Xen,KVM

谷歌的基于虚拟化推出了AWS，开启了基础设施即服务IaaS的市场

接着，虚拟化成熟期，OpenStack发布，又称云计算时代，以云的形式部署应用，

解决方案代表：IaaS，PaaS平台即服务,SaaS软件即服务

全球企业有一半计算资源都放到了公有云上，

解决方案代表：AWS,Azure,阿里云,谷歌云

后来，云的弊端也凸显了，启动慢，效率低，每个云是定制的，移植性差，就在这时候，Docker公司整合了已有技术，推出内核容器技术的标准镜像，与虚拟机相比，效率高，移植性好，启动快，计算基本单元从虚拟机变成了Docker容器镜像，

但是光有容器不能完全体现虚拟机过渡到容器的优势，所以又提出了云原生概念，基于容器推出一整套原生环境，更加智能，敏捷地管理应用。