为了账号安全,请及时绑定邮箱和手机立即绑定

Kubernetes基础:开启云原生之门

难度中级
时长 1小时43分
学习人数
综合评分88.7
24人评价 查看评价
9.2 内容实用
8.7 简洁易懂
8.7 逻辑清晰
  • 7-1回顾总结

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

    介绍k8s架构:maset,nodes

    介绍k8s对象,具体介绍了pod和控制器;configMap和secret

    02:06
    看视频
  • 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或环境变量方式使用。

    01:01
    看视频
  • 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的自动伸缩。



    01:48
    看视频
  • 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元数据,以实现逻辑

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

    05:07
    看视频
  • 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对象一直保持期望状态。


    04:56
    看视频
  • 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


    00:20
    看视频
  • 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的数据是不被推荐的


    00:07
    看视频
  • 5-1 k8s架构全图解释

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

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

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

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

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

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

    02:56
    看视频
  • 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获取集群的节点列表

    01:18
    看视频
  • 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容器镜像,

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

    13:54
    看视频

举报

0/150
提交
取消
课程须知
1、熟悉基本Linux操作 2、了解Docker容器概念与原理 3、了解基本docker命令操作
老师告诉你能学到什么?
1、Kubernetes是什么? 2、为什么要使用Kubernetes? Kubernetes给开发者带来哪些好处? 3、如何在Kubernetes集群上部署和管理一个应用 4、Kubernetes的架构 5、Kubernetes的组件与功用 6、Kubernetes对象模型以及基础概念
意见反馈 邀请有奖 帮助中心 APP下载
官方微信