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-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对象一直保持期望状态。

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的版本信息

逻辑控制中心

Master

Kubernetes集群大脑，控制平面∶

所有集群的控制命令都传递给Master组件并在其上执行

每个Kubernetes集群至少有一套Master组件（当前默认:一个)

每套master组件包括三个核心组件(apiserver, scheduler

和controller-manager)以及集群数据配置中心etcd

组件:API Server-核心

API Server :

集群控制的唯一入口，是提供Kubernetes集群控制RESTful API的核心组件

集群内各个组件之间数据交互和通信的中枢

提供集群控制的安全机制(身份认证、授权以及admission control)

组件:Scheduler

Scheduler :

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

支持自定义调度算法provider

默认调度算法内置预选策略和优选策略，决策考量资源需求、服务质量、软硬件约束、亲缘性、数据局部性等指标参数

组件:ControllerManager

ControllerManager :

集群内各种资源controller的核心管理者

针对每一种具体的资源，都有相应的Controller

保证其下管理的每个Controller所对应的资源始终处于“期望状态”。

组件:Etcd

Etcd :

Kubernetes集群的主数据库，存储着所有资源对象以及状态

默认与Master组件部署在一个Node上

Etcd的数据变更都是通过API Server进行

Google Borg

Kubernetes对象常用的Metedata属性-Name&UID

5-1 k8s架构全图解释

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

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

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

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

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

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

Service 可以直接为后方的Deployment配置负载均衡，取代传统Nginx的作用，还可以提供地址代理。

Pod 的生命周期

Pｏｄ　Lｉｆｅ Cｙｃｌｅ

summary:

Kube-proxy

组件