精华内容
参与话题
问答
  • K8s简介

    千次阅读 多人点赞 2018-10-25 10:54:02
    基本概念: POD: Pod是kubernetes的最小操作单元,一个Pod可以由一个或多个容器组成; 同一个Pod只能运行在同一个主机上,共享相同的volumes、network、namespace。 ReplicationController(RC): ...

    基本概念:

    POD:

    Pod是kubernetes的最小操作单元,一个Pod可以由一个或多个容器组成;

    同一个Pod只能运行在同一个主机上,共享相同的volumes、network、namespace。

    ReplicationController(RC):

    RC用来管理Pod,一个RC可以由一个或多个Pod组成,在RC被创建后,

    系统会根据定义好的副本数来创建Pod数量。

    在运行过程中,如果Pod数量小于定义的,就会重启停止的或重新分配Pod,

    反之则杀死多余的。当然,也可以动态伸缩运行的Pods规模或熟悉。

    Service:

    Service定义了一个Pod逻辑集合的抽象资源,Pod集合中的容器提供相同的功能。

    集合根据定义的Label和selector完成,当创建一个Service后,

    会分配一个Cluster IP,这个IP与定义的端口提供这个集合一个统一的访问接口,并且实现负载均衡。

    Label:

    Label是用于区分Pod、Service、RC的key/value键值对;

    Pod、Service、RC可以有多个label,但是每个label的key只能对应一个;

    主要是将Service的请求通过lable转发给后端提供服务的Pod集合;

    kubectl:

    客户端命令行工具,将接受的命令格式化后发送给kube-apiserver,作为整个系统的操作入口。

    kubelet:

    运行在每个计算节点上,作为agent,接受分配该节点的Pods任务及管理容器,周期性获取容器状态,反馈给kube-apiserver。

    Kubeadm:

    Google官方提供的k8s安装工具

    kube-apiserver:

    作为整个系统的控制入口,以REST API服务提供接口。

    kube-controller-manager:

    用来执行整个系统中的后台任务,包括节点状态状况、Pod个数、Pods和Service的关联等。

    kube-scheduler:

    负责节点资源管理,接受来自kube-apiserver创建Pods任务,并分配到某个节点。

    etcd:

    负责节点间的服务发现和配置共享。

    kube-proxy:

    运行在每个计算节点上,负责Pod网络代理。定时从etcd获取到service信息来做相应的策略。

    DNS:

    一个可选的DNS服务,用于为每个Service对象创建DNS记录,这样所有的Pod就可以通过DNS访问服务了。

     

     

    框架流程:

     

    展开全文
  • k8s 超详细总结,面试必问

    万次阅读 多人点赞 2018-09-04 10:00:09
    相如无亿,K8s有亿:亿级日服务人次。 一个目标:容器操作 Kubernetes(k8s)是自动化容器操作的开源平台。这些容器操作包括:部署,调度和节点集群间扩展。 具体功能: 自动化容器部署和复制。 实时弹性收缩容器...

    一个目标:容器操作;两地三中心;四层服务发现;五种Pod共享资源;六个CNI常用插件;七层负载均衡;八种隔离维度;九个网络模型原则;十类IP地址;百级产品线;千级物理机;万级容器;相如无亿,K8s有亿:亿级日服务人次。

    一个目标:容器操作
    Kubernetes(k8s)是自动化容器操作的开源平台。这些容器操作包括:部署,调度和节点集群间扩展。
    具体功能:
    自动化容器部署和复制。
    实时弹性收缩容器规模。
    容器编排成组,并提供容器间的负载均衡。
    调度:容器在哪个机器上运行。
    组成:
    kubectl:客户端命令行工具,作为整个系统的操作入口。
    kube-apiserver:以REST API服务形式提供接口,作为整个系统的控制入口。
    kube-controller-manager:执行整个系统的后台任务,包括节点状态状况、Pod个数、Pods和Service的关联等。
    kube-scheduler:负责节点资源管理,接收来自kube-apiserver创建Pods任务,并分配到某个节点。
    etcd:负责节点间的服务发现和配置共享。
    kube-proxy:运行在每个计算节点上,负责Pod网络代理。定时从etcd获取到service信息来做相应的策略。
    kubelet:运行在每个计算节点上,作为agent,接收分配该节点的Pods任务及管理容器,周期性获取容器状态,反馈给kube-apiserver。
    DNS:一个可选的DNS服务,用于为每个Service对象创建DNS记录,这样所有的Pod就可以通过DNS访问服务了。
    下面是K8s的架构拓扑图:
    图片描述

    两地三中心
    两地三中心包括本地生产中心、本地灾备中心、异地灾备中心。
    图片描述
    两地三中心要解决的一个重要问题就是数据一致性问题。k8s使用etcd组件作为一个高可用、强一致性的服务发现存储仓库。用于配置共享和服务发现。
    它作为一个受到Zookeeper和doozer启发而催生的项目。除了拥有他们的所有功能之外,还拥有以下4个特点:
    简单:基于http+json的api让你用curl命令就可以轻松使用。
    安全:可选SSL客户认证机制。
    快速:每个实例每秒支持一千次写操作。
    可信:使用Raft算法充分实现了分布式。

    四层服务发现
    先一张图解释一下网络七层协议:
    图片描述
    k8s提供了两种方式进行服务发现:
    环境变量:当创建一个Pod的时候,kubelet会在该Pod中注入集群内所有Service的相关环境变量。需要注意的是,要想一个Pod中注入某个Service的环境变量,则必须Service要先比该Pod创建。这一点,几乎使得这种方式进行服务发现不可用。
    比如,一个ServiceName为redis-master的Service,对应的ClusterIP:Port为10.0.0.11:6379,则对应的环境变量为:
    图片描述
    DNS:可以通过cluster add-on的方式轻松的创建KubeDNS来对集群内的Service进行服务发现。
    以上两种方式,一个是基于tcp,众所周知,DNS是基于UDP的,它们都是建立在四层协议之上。

    五种Pod共享资源
    Pod是K8s最基本的操作单元,包含一个或多个紧密相关的容器,一个Pod可以被一个容器化的环境看作应用层的“逻辑宿主机”;一个Pod中的多个容器应用通常是紧密耦合的,Pod在Node上被创建、启动或者销毁;每个Pod里运行着一个特殊的被称之为Volume挂载卷,因此他们之间通信和数据交换更为高效,在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。
    图片描述
    同一个Pod里的容器之间仅需通过localhost就能互相通信。一个Pod中的应用容器共享五种资源:
    PID命名空间:Pod中的不同应用程序可以看到其他应用程序的进程ID。
    网络命名空间:Pod中的多个容器能够访问同一个IP和端口范围。
    IPC命名空间:Pod中的多个容器能够使用SystemV IPC或POSIX消息队列进行通信。
    UTS命名空间:Pod中的多个容器共享一个主机名。
    Volumes(共享存储卷):Pod中的各个容器可以访问在Pod级别定义的Volumes。
    Pod的生命周期通过Replication Controller来管理;通过模板进行定义,然后分配到一个Node上运行,在Pod所包含容器运行结束后,Pod结束。
    Kubernetes为Pod设计了一套独特的网络配置,包括:为每个Pod分配一个IP地址,使用Pod名作为荣期间通信的主机名等。

    六个CNI常用插件
    CNI(Container Network Interface)容器网络接口,是Linux容器网络配置的一组标准和库,用户需要根据这些标准和库来开发自己的容器网络插件。CNI只专注解决容器网络连接和容器销毁时的资源释放,提供一套框架,所以CNI可以支持大量不同的网络模式,并且容易实现。
    下面用一张图表示六个CNI常用插件:
    图片描述

    七层负载均衡
    提负载均衡就不得不先提服务器之间的通信。
    IDC(Internet Data Center),也可称 数据中心、机房,用来放置服务器。IDC网络是服务器间通信的桥梁。
    图片描述
    上图里画了很多网络设备,它们都是干啥用的呢?
    路由器、交换机、MGW/NAT都是网络设备,按照性能、内外网划分不同的角色。
    内网接入交换机:也称为TOR(top of rack),是服务器接入网络的设备。每台内网接入交换机下联40-48台服务器,使用一个掩码为/24的网段作为服务器内网网段。
    内网核心交换机:负责IDC内各内网接入交换机的流量转发及跨IDC流量转发。
    MGW/NAT:MGW即LVS用来做负载均衡,NAT用于内网设备访问外网时做地址转换。
    外网核心路由器:通过静态互联运营商或BGP互联美团统一外网平台。
    先说说各层负载均衡:
    二层负载均衡:基于MAC地址的二层负载均衡。
    三层负载均衡:基于IP地址的负载均衡。
    四层负载均衡:基于IP+端口的负载均衡。
    七层负载均衡:基于URL等应用层信息的负载均衡。
    这里用一张图来说说四层和七层负载均衡的区别:
    图片描述
    上面四层服务发现讲的主要是k8s原生的kube-proxy方式。K8s关于服务的暴露主要是通过NodePort方式,通过绑定minion主机的某个端口,然后进行pod的请求转发和负载均衡,但这种方式有下面的缺陷:
    Service可能有很多个,如果每个都绑定一个node主机端口的话,主机需要开放外围的端口进行服务调用,管理混乱。
    无法应用很多公司要求的防火墙规则。
    理想的方式是通过一个外部的负载均衡器,绑定固定的端口,比如80,然后根据域名或者服务名向后面的Service ip转发,Nginx很好的解决了这个需求,但问题是如果有的心得服务加入,如何去修改Nginx的配置,并且加载这些配置?Kubernetes给出的方案就是Ingress。这是一个基于7层的方案。

    八种隔离维度
    图片描述
    K8s集群调度这边需要对上面从上到下从粗粒度到细粒度的隔离做相应的调度策略。

    九个网络模型原则
    K8s网络模型要符合4个基础原则,3个网络要求原则,1个架构原则,1个IP原则。
    每个Pod都拥有一个独立的IP地址,而且假定所有Pod都在一个可以直接连通的、扁平的网络空间中,不管是否运行在同一Node上都可以通过Pod的IP来访问。
    K8s中的Pod的IP是最小粒度IP。同一个Pod内所有的容器共享一个网络堆栈,该模型称为IP-per-Pod模型。
    Pod由docker0实际分配的IP,Pod内部看到的IP地址和端口与外部保持一致。同一个Pod内的不同容器共享网络,可以通过localhost来访问对方的端口,类似同一个VM内不同的进程。
    IP-per-Pod模型从端口分配、域名解析、服务发现、负载均衡、应用配置等角度看,Pod可以看做是一台独立的VM或物理机。
    所有容器都可以不用NAT的方式同别的容器通信。
    所有节点都可以在不同NAT方式下同所有容器心痛,反之亦然。
    容器的地址和别人看到的地址是同一个地址。
    要符合下面的架构:
    图片描述

    由上图架构引申出来IP概念从集群外部到集群内部
    图片描述

    十类IP地址
    大家都知道IP地址分为ABCDE类,另外还有5类特殊用途的IP。

    1. A类
      1.0.0.0-1226.255.255.255,默认子网掩码/8,即255.0.0.0
      2.B类
      128.0.0.0-191.255.255.255,默认子网掩码/16,即255.255.0.0
      3.C类
      192.0.0.0-223.255.255.255,默认子网掩码/24,即255.255.255.0
      4.D类
      224.0.0.0-239.255.255.255,一般用于组播
      5.E类
      240.0.0.0-255.255.255.255(其中255.255.255.255为全网广播地址),E类地址一般用于研究用途
    2. 0.0.0.0
      严格来说,0.0.0.0已经不是一个真正意义上的IP地址了。它表示的是这样一个集合:所有不清楚的主机和目的网络。这里的不清楚是指在本机的路由表里没有特定条目指明如何到达。作为缺省路由。
      7.127.0.0.1
      本机地址
    3. 224.0.0.1
      组播地址。如果你的主机开启了IRDP(internet路由发现,使用组播功能),那么你的主机路由表中应该有这样一条路由。
    4. 169.254.x.x
      使用了DHCP功能自动获取了IP的主机,DHCP服务器发生故障,或响应时间太长而超出了一个系统规定的时间,系统会为你分配这样一个IP,代表网络不能正常运行。
    5. 10.xxx、172.16.x.x~172.31.x.x、192.168.x.x
      私有地址,大量用于企业内部。保留这样的地址是为了避免亦或是哪个接入公网时引起地址混乱。

      百级产品线接入;千级物理机部署;万级容器储备;亿级日服务人次是我们的近期目标,欢迎新美大兄弟部门试用(^__^)

    展开全文
  • docker与k8s实战

    2019-12-05 12:31:51
    本节为docker与k8s详解,详细讲解了docker与k8s的概念、理论、操作,并通过实例来说明其特性。
  • Kubernetes是一个开源的,用于管理云... 通过本教程的学习,你可以掌握K8S的简介、K8S的集群搭建(三种部署方式)、K8S企业应用案例( SpringBoot和K8S的实战、SpringCloud的客户端案例等),胜任企业级的开发工作。
  • 啥叫K8s?啥是k8s

    万次阅读 多人点赞 2018-10-25 16:59:24
    •Kubernetes介绍 1.背景介绍  云计算飞速发展  - IaaS  - PaaS  - SaaS  Docker技术突飞猛进  - 一次构建,到处运行  - 容器的快速轻量  - 完整的生态环境 ...Kubernetes(k8s)是Googl...

    •Kubernetes介绍

    1.背景介绍

      云计算飞速发展

        - IaaS

        - PaaS

        - SaaS

      Docker技术突飞猛进

        - 一次构建,到处运行

        - 容器的快速轻量

        - 完整的生态环境

    2.什么是kubernetes

      首先,他是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统(谷歌内部:Borg)。在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性。

      Kubernetes是一个完备的分布式系统支撑平台,具有完备的集群管理能力,多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具,涵盖了包括开发、部署测试、运维监控在内的各个环节。

    Kubernetes中,Service是分布式集群架构的核心,一个Service对象拥有如下关键特征:

    • 拥有一个唯一指定的名字
    • 拥有一个虚拟IP(Cluster IP、Service IP、或VIP)和端口号
    • 能够体统某种远程服务能力
    • 被映射到了提供这种服务能力的一组容器应用上

      Service的服务进程目前都是基于Socket通信方式对外提供服务,比如Redis、Memcache、MySQL、Web Server,或者是实现了某个具体业务的一个特定的TCP Server进程,虽然一个Service通常由多个相关的服务进程来提供服务,每个服务进程都有一个独立的Endpoint(IP+Port)访问点,但Kubernetes能够让我们通过服务连接到指定的Service上。有了Kubernetes内奸的透明负载均衡和故障恢复机制,不管后端有多少服务进程,也不管某个服务进程是否会由于发生故障而重新部署到其他机器,都不会影响我们队服务的正常调用,更重要的是这个Service本身一旦创建就不会发生变化,意味着在Kubernetes集群中,我们不用为了服务的IP地址的变化问题而头疼了。

      容器提供了强大的隔离功能,所有有必要把为Service提供服务的这组进程放入容器中进行隔离。为此,Kubernetes设计了Pod对象,将每个服务进程包装到相对应的Pod中,使其成为Pod中运行的一个容器。为了建立Service与Pod间的关联管理,Kubernetes给每个Pod贴上一个标签Label,比如运行MySQL的Pod贴上name=mysql标签,给运行PHP的Pod贴上name=php标签,然后给相应的Service定义标签选择器Label Selector,这样就能巧妙的解决了Service于Pod的关联问题。

      在集群管理方面,Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node,其中,在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler,这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力,并且都是全自动完成的。Node作为集群中的工作节点,运行真正的应用程序,在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的kubelet、kube-proxy服务进程,这些服务进程负责Pod的创建、启动、监控、重启、销毁以及实现软件模式的负载均衡器。

      在Kubernetes集群中,它解决了传统IT系统中服务扩容和升级的两大难题。你只需为需要扩容的Service关联的Pod创建一个Replication Controller简称(RC),则该Service的扩容及后续的升级等问题将迎刃而解。在一个RC定义文件中包括以下3个关键信息。

    • 目标Pod的定义
    • 目标Pod需要运行的副本数量(Replicas)
    • 要监控的目标Pod标签(Label)

      在创建好RC后,Kubernetes会通过RC中定义的的Label筛选出对应Pod实例并实时监控其状态和数量,如果实例数量少于定义的副本数量,则会根据RC中定义的Pod模板来创建一个新的Pod,然后将新Pod调度到合适的Node上启动运行,知道Pod实例的数量达到预定目标,这个过程完全是自动化。

      架构资料领取地址:895244712

     Kubernetes优势:

        - 容器编排

        - 轻量级

        - 开源

        - 弹性伸缩

        - 负载均衡

    •Kubernetes的核心概念

    1.Master

      k8s集群的管理节点,负责管理集群,提供集群的资源数据访问入口。拥有Etcd存储服务(可选),运行Api Server进程,Controller Manager服务进程及Scheduler服务进程,关联工作节点Node。Kubernetes API server提供HTTP Rest接口的关键服务进程,是Kubernetes里所有资源的增、删、改、查等操作的唯一入口。也是集群控制的入口进程;Kubernetes Controller Manager是Kubernetes所有资源对象的自动化控制中心;Kubernetes Schedule是负责资源调度(Pod调度)的进程

     

    2.Node

      Node是Kubernetes集群架构中运行Pod的服务节点(亦叫agent或minion)。Node是Kubernetes集群操作的单元,用来承载被分配Pod的运行,是Pod运行的宿主机。关联Master管理节点,拥有名称和IP、系统资源信息。运行docker eninge服务,守护进程kunelet及负载均衡器kube-proxy.

    • 每个Node节点都运行着以下一组关键进程
    • kubelet:负责对Pod对于的容器的创建、启停等任务
    • kube-proxy:实现Kubernetes Service的通信与负载均衡机制的重要组件
    • Docker Engine(Docker):Docker引擎,负责本机容器的创建和管理工作

      Node节点可以在运行期间动态增加到Kubernetes集群中,默认情况下,kubelet会想master注册自己,这也是Kubernetes推荐的Node管理方式,kubelet进程会定时向Master汇报自身情报,如操作系统、Docker版本、CPU和内存,以及有哪些Pod在运行等等,这样Master可以获知每个Node节点的资源使用情况,冰实现高效均衡的资源调度策略。、

     

    3.Pod

      运行于Node节点上,若干相关容器的组合。Pod内包含的容器运行在同一宿主机上,使用相同的网络命名空间、IP地址和端口,能够通过localhost进行通。Pod是Kurbernetes进行创建、调度和管理的最小单位,它提供了比容器更高层次的抽象,使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。

      Pod其实有两种类型:普通Pod和静态Pod,后者比较特殊,它并不存在Kubernetes的etcd存储中,而是存放在某个具体的Node上的一个具体文件中,并且只在此Node上启动。普通Pod一旦被创建,就会被放入etcd存储中,随后会被Kubernetes Master调度到摸个具体的Node上进行绑定,随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器冰启动起来,在。在默认情况下,当Pod里的某个容器停止时,Kubernetes会自动检测到这个问起并且重启这个Pod(重启Pod里的所有容器),如果Pod所在的Node宕机,则会将这个Node上的所有Pod重新调度到其他节点上。

    架构资料领取地址:895244712

    4.Replication Controller

      Replication Controller用来管理Pod的副本,保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量,则会停止指定数量之外的多余容器数量,反之,则会启动少于指定数量个数的容器,保证数量不变。Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。

     

    5.Service

      Service定义了Pod的逻辑集合和访问该集合的策略,是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制,关联多个相同Label的Pod,用户不需要了解后台Pod是如何运行。

    外部系统访问Service的问题

      首先需要弄明白Kubernetes的三种IP这个问题

        Node IP:Node节点的IP地址

        Pod IP: Pod的IP地址

        Cluster IP:Service的IP地址

      首先,Node IP是Kubernetes集群中节点的物理网卡IP地址,所有属于这个网络的服务器之间都能通过这个网络直接通信。这也表明Kubernetes集群之外的节点访问Kubernetes集群之内的某个节点或者TCP/IP服务的时候,必须通过Node IP进行通信

      其次,Pod IP是每个Pod的IP地址,他是Docker Engine根据docker0网桥的IP地址段进行分配的,通常是一个虚拟的二层网络。

      最后Cluster IP是一个虚拟的IP,但更像是一个伪造的IP网络,原因有以下几点

    • Cluster IP仅仅作用于Kubernetes Service这个对象,并由Kubernetes管理和分配P地址
    • Cluster IP无法被ping,他没有一个“实体网络对象”来响应
    • Cluster IP只能结合Service Port组成一个具体的通信端口,单独的Cluster IP不具备通信的基础,并且他们属于Kubernetes集群这样一个封闭的空间。

    Kubernetes集群之内,Node IP网、Pod IP网于Cluster IP网之间的通信,采用的是Kubernetes自己设计的一种编程方式的特殊路由规则。

     

    6.Label

     Kubernetes中的任意API对象都是通过Label进行标识,Label的实质是一系列的Key/Value键值对,其中key于value由用户自己指定。Label可以附加在各种资源对象上,如Node、Pod、Service、RC等,一个资源对象可以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象上去。Label是Replication Controller和Service运行的基础,二者通过Label来进行关联Node上运行的Pod。

    我们可以通过给指定的资源对象捆绑一个或者多个不同的Label来实现多维度的资源分组管理功能,以便于灵活、方便的进行资源分配、调度、配置等管理工作。

    一些常用的Label如下:

    • 版本标签:"release":"stable","release":"canary"......
    • 环境标签:"environment":"dev","environment":"qa","environment":"production"
    • 架构标签:"tier":"frontend","tier":"backend","tier":"middleware"
    • 分区标签:"partition":"customerA","partition":"customerB"
    • 质量管控标签:"track":"daily","track":"weekly"

      Label相当于我们熟悉的标签,给某个资源对象定义一个Label就相当于给它大了一个标签,随后可以通过Label Selector(标签选择器)查询和筛选拥有某些Label的资源对象,Kubernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制。

    架构资料领取地址:895244712

      Label Selector在Kubernetes中重要使用场景如下:

      •   kube-Controller进程通过资源对象RC上定义Label Selector来筛选要监控的Pod副本的数量,从而实现副本数量始终符合预期设定的全自动控制流程
      •   kube-proxy进程通过Service的Label Selector来选择对应的Pod,自动建立起每个Service岛对应Pod的请求转发路由表,从而实现Service的智能负载均衡
      •   通过对某些Node定义特定的Label,并且在Pod定义文件中使用Nodeselector这种标签调度策略,kuber-scheduler进程可以实现Pod”定向调度“的特性

     

    Kubernetes架构和组件

     

      - 服务分组,小集群,多集群

      - 服务分组,大集群,单集群

    架构资料领取地址:895244712

    Kubernetes 组件:

      Kubernetes Master控制组件,调度管理整个系统(集群),包含如下组件:

      1.Kubernetes API Server

        作为Kubernetes系统的入口,其封装了核心对象的增删改查操作,以RESTful API接口方式提供给外部客户和内部组件调用。维护的REST对象持久化到Etcd中存储。

      2.Kubernetes Scheduler

        为新建立的Pod进行节点(node)选择(即分配机器),负责集群的资源调度。组件抽离,可以方便替换成其他调度器。

      3.Kubernetes Controller

        负责执行各种控制器,目前已经提供了很多控制器来保证Kubernetes的正常运行。

      4. Replication Controller

        管理维护Replication Controller,关联Replication Controller和Pod,保证Replication Controller定义的副本数量与实际运行Pod数量一致。

      5. Node Controller

        管理维护Node,定期检查Node的健康状态,标识出(失效|未失效)的Node节点。

      6. Namespace Controller

        管理维护Namespace,定期清理无效的Namespace,包括Namesapce下的API对象,比如Pod、Service等。

      7. Service Controller

        管理维护Service,提供负载以及服务代理。

      8.EndPoints Controller

        管理维护Endpoints,关联Service和Pod,创建Endpoints为Service的后端,当Pod发生变化时,实时更新Endpoints。

      9. Service Account Controller

        管理维护Service Account,为每个Namespace创建默认的Service Account,同时为Service Account创建Service Account Secret。

      10. Persistent Volume Controller

        管理维护Persistent Volume和Persistent Volume Claim,为新的Persistent Volume Claim分配Persistent Volume进行绑定,为释放的Persistent Volume执行清理回收。

      11. Daemon Set Controller

        管理维护Daemon Set,负责创建Daemon Pod,保证指定的Node上正常的运行Daemon Pod。

      12. Deployment Controller

        管理维护Deployment,关联Deployment和Replication Controller,保证运行指定数量的Pod。当Deployment更新时,控制实现Replication Controller和 Pod的更新。

      13.Job Controller

        管理维护Job,为Jod创建一次性任务Pod,保证完成Job指定完成的任务数目

      14. Pod Autoscaler Controller

        实现Pod的自动伸缩,定时获取监控数据,进行策略匹配,当满足条件时执行Pod的伸缩动作。

     

     Kubernetes Node运行节点,运行管理业务容器,包含如下组件:

      1.Kubelet

        负责管控容器,Kubelet会从Kubernetes API Server接收Pod的创建请求,启动和停止容器,监控容器运行状态并汇报给Kubernetes API Server。

      2.Kubernetes Proxy

        负责为Pod创建代理服务,Kubernetes Proxy会从Kubernetes API Server获取所有的Service信息,并根据Service的信息创建代理服务,实现Service到Pod的请求路由和转发,从而实现Kubernetes层级的虚拟转发网络。

      3.Docker

        Node上需要运行容器服务

    展开全文
  • 一文带你深入了解K8S实战部署SpringBoot项目

    1.前言

    云原生可以说是当下互联网行业最火爆的概念和技术,云原生从字面意思上来看可以分成云和原生两个部分。
    是和本地相对的,传统的应用必须跑在本地服务器上,现在流行的应用都跑在云端,云包含了IaaS,、PaaS和SaaS。
    原生就是土生土长的意思,我们在开始设计应用的时候就考虑到应用将来是运行云环境里面的,要充分利用云资源的优点,比如️云服务的弹性和分布式优势。
    聊到云原生,避不开的就是容器技术,而docker作为最流行的容器技术,已经经过很多年的线上实战。今天我们不深入聊云原生,docker这些技术概念,今天我们聊一聊时下最火的容器编排技术:K8S-实战部署SpringBoot项目。

    2.简介

    2.1.为什么写这篇文章

    前言中提到云原生dockerK8S,我是18年第一次docker,也是在18年接触K8S,相对这门技术来说,我接触的时候已经有些晚了,因为在之后的面试中,已经感受到这些技术在大厂已经用的很成熟了,之前都在小公司,并不了解这些技术是什么,干什么用,加上国内这方面的资料又比较少,学起来是相当吃力。而到大厂之后,发现这些技术无处不在,并且基础设施建设已经很完备,一键部署云端的骚操作,让开发只需要关心业务而无需关心安装部署等繁琐的工作。祸兮福之所倚;福兮祸之所伏,大厂的技术设施完备的同时,另一方面也消弱了你去了解基础设施背后的技术原理能力。正是认识到这一点,今天才写这篇文章,为迷途中的孩子找到回家的路。废话不多,撸起袖子,干就完了!

    这里没有任何马后炮套话,只有粗暴的干货。写大家看得懂、用得着、赚得到的文章是唯一宗旨!

    2.2.需求描述

    我有一个简单的Springboot项目,想部署在K8S集群中,能够实现扩缩容,负载均衡,同时我有一个互联网域名,我想把这个域名绑定在这个服务上,能够在有网络的地方访问。

    2.3.需求分析

    这个需求我想在很多刚开始接触docker,k8s等技术的老铁身上都会遇到过,真正实现起来,并不是那么容易,听我一一道来:

    1. image—Springboot项目一般是以jar包的形式跑在像centos等服务器上,运行nohup java -jar xxx.jar &命令就能启动起来。但是在k8s中,运行起来的的并不是jar,而是image,因此我们需要把jar打包成image;
    2. 自动扩缩—最基础的image有了,接下来就要考虑的是自动扩缩:顾名思义,比如说就是在服务访问量大的时候,我可以添加实例,来减少每个服务实例的压力,在访问量小的时候,我可以删除一部分实例,来实现资源的高效利用。
    3. 负载均衡—当我们的实例越来越多,我并不希望把所有的请求都落在一个实例上,如若不然,我们自动扩缩也就没了意义,传统方法我们可以用Nginx等实现负载均衡,待会来看看K8S能做些什么
    4. 域名绑定—这个就没什么好说的了。

    3. 部署实战

    3.1 环境准备

    工欲善其事,必先利其器:

    1. Springboot jar包
    2. K8S集群环境

    K8S集群环境部署我就不在这里展开讲了,我们准备一个最简单的Springboot项目,里面只有一个接口,访问localhost:8088,返回服务器的hostname,当整个部署工作完成之后,我们通过域名访问这个接口,返回的应该是不同的containerhostname,那我们的任务就完成了。

    	@GetMapping("/")
        public String sayHello() throws UnknownHostException {
            String hostname = "Unknown";
            InetAddress address = InetAddress.getLocalHost();
            hostname = address.getHostName();
            return hostname;
        }
    

    3.2 image准备

    我们都知道,所有image的生成都离不开Dockerfile技术,我们有了一个jar包,要利用Dockerfile技术生成一个image。废话不多,上代码:

    #使用jdk8作为基础镜像
    FROM java:8
    #指定作者
    MAINTAINER ***
    #暴漏容器的8088端口
    #EXPOSE 8088
    #将复制指定的docker-demo-0.0.1-SNAPSHOT.jar为容器中的job.jar,相当于拷贝到容器中取了个别名
    ADD docker-demo-0.0.1-SNAPSHOT.jar /job.jar
    #创建一个新的容器并在新的容器中运行命令
    RUN bash -c 'touch /job.jar'
    #设置时区
    ENV TZ=PRC
    RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
    #相当于在容器中用cmd命令执行jar包  指定外部配置文件
    ENTRYPOINT ["java","-jar","/job.jar"]
    

    Dockerfile文件里面有注释,具体的每一行代码什么意思我就不展开多讲了,这不是今天的重点,接下来,我们把docker-demo-0.0.1-SNAPSHOT.jarDockerfile文件放在同一个目录,上传到K8S的master 节点上,在目录内执行如下命令生成images

    $ docker build .
    

    我们可以看到生成image的过程,通过docker images 查看镜像
    在这里插入图片描述
    生成一个 docker-demo:latest的image镜像。
    注意:我们部署的是集群,要想K8S集群中都能拉到这个镜像,那我们有以下两种方式:

    1. 方法一:我们把这个docker-demo:latest上传到远端仓库,这个仓库可以是我们自己的,或者是像我一样注册一个阿里云的账号,上传到阿里云自己的容器镜像服务仓库,如下图:
      在这里插入图片描述
      具体步骤
      1.1 docker登陆阿里云容器镜像服务,需要输入密码
    $ docker login --username=24k不怕(写自己的用户名) registry.cn-hangzhou.aliyuncs.com
    

    1.2 在阿里云上创建命名空间:例:cuixhao-docker-demo
    在这里插入图片描述
    1.3 镜像打标签

    $ docker tag docker-demo:latest registry.cn-hangzhou.aliyuncs.com/cuixhao-docker-demo/docker-demo:latest
    

    1.4 push到阿里云

    $ docker push registry.cn-hangzhou.aliyuncs.com/cuixhao-docker-demo/docker-demo:latest
    

    1.5 删除掉docker-demo:latest

    $ docker rmi docker-demo:latest
    
    1. 方法二 把刚才创建image的过程,在集群中每一台节点上都执行一遍,保证集群中每一台都有这个镜像。我采用的是二者的结合:先在master上把镜像生成,上传到阿里云,然后在另外的节点上,通过docker pull registry.cn-hangzhou.aliyuncs.com/cuixhao-docker-demo/docker-demo:latest 命令,从阿里云上拉到本地,然后在通过 docer tag registry.cn-hangzhou.aliyuncs.com/cuixhao-docker-demo/docker-demo:latest docker-demo:latest命令打标签,然后删掉拉取到的镜像:docker rmi registry.cn-hangzhou.aliyuncs.com/cuixhao-docker-demo/docker-demo:latest,
      为什么这么做因为我阿里云建的命名空间中的image都是私有,K8S拉取image的时候是需要集群中都配置ca证书的,如果设置为公开则不存在这个问题。所以我用docker-demo:latest这个镜像,直接用本地的,部署的时候不用再去阿里云拉取。

    3.3 部署2个实例

    3.3.1 编写yaml文件

    基础镜像准备好了,那我们就开始部署吧。我们知道,k8s有deployment ,service等概念,这里不详细讲,简单描述一下:deployment(命名空间),管理pod集群,service,管理pod中的服务。我们在master 节点编辑一个 ingress-docker-docker-deployment.yaml 文件

    $ vi ingress-docker-docker-deployment.yaml
    

    键入以下内容

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ingress-docker-demo-deployment
      labels:
        app: ingress-docker-demo
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: ingress-docker-demo
      template:
        metadata:
          labels:
            app: ingress-docker-demo
        spec:
          containers:
          - name: docker-demo
            image: docker-demo
            imagePullPolicy: Never
            ports:
            - containerPort: 8088
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: ingress-docker-demo-service
    spec:
      ports:
      - port: 80
        protocol: TCP
        targetPort: 8088
      selector:
        app: ingress-docker-demo
    

    由yaml文件内容我们可以读出:我们创建了一个 名字我为ingress-docker-demo-deployment的deployment,里面有2个 docker-demo 的pod (replicas: 2),和一个名字为ingress-docker-demo-service的service,管理名字为ingress-docker-demo的pod服务,目标端口8088,即我们的springboot服务所用端口,对外提供80端口。

    3.3.2 启动

    在master执行如下命令启动deployment 和service:

    $ kubectl apply -f ingress-docker-docker-deployment.yaml
    

    查看启动结果:

    $ kubectl get pod -o wide
    

    在这里插入图片描述
    我们可以看到启动结果,两个container分别在 worker01,worker02这两个节点上,可以看到,K8S集群给我们分配了两个IP:192.168.14.11,192.168.221.73。我们思考以下三个问题:
    a. 在集群中,我们通过以上访问这两个服务,能访问通吗,是通过8088端口还是80端口?
    我们不妨尝试一下,在集群中任何一个节点执行如下命令:

    $ curl 192.168.14.11:8088
    $ curl 192.168.221.73:8088
    

    在这里插入图片描述
    我们可以看到,接口返回了各自container的hostname,说明我们的服务是部署启动成功了,访问80端口是不通的,有兴趣的老铁可以试一下,因为80是我们对外的端口,所以用container ip是访问不通的。
    b. 在集群内部访问,我们如何做到负载均衡?
    有老铁可能会考虑一个问题,K8S集群中的pod有可能销毁或者重启,每次重启之后的ip不能保证一致,那以上访问方式肯定是不可采用的。想法很对,我们想访问一个固定的地址,不管pod如何重启,ip如何变化,我只访问这一个ip,这岂不美哉?那我们能不能做到呢?且看如下骚操作:

    $ kubectl get svc
    

    在这里插入图片描述
    通过以上命令,我们找到了ingress-docker-docker-deployment.yaml中定义的名字为 ingress-docker-demo-service的service,它有一个 CLUSTER-IP,PORT为80,那我们根据K8S中的service的作用,做一个大胆的猜测:我们是不是可以固定的通过 10.103.19.71 (省略默认80端口)或者 10.103.19.71:80 来永久访问这两个服务呢?

    $ curl 10.103.19.71
    $ curl 10.103.19.71:80
    

    在这里插入图片描述
    答案是肯定的!,它给我们做了负载均衡!

    c. 在集群外部我们如何访问这两个服务并且负载均衡?
    集群内访问服务,负载均衡都已经做好了。有的老铁会问:集群外服想访问集群内的服务,该如何做呢?别急,还没完!

    3.3.3 引入Ingress

    3.3.3.1 Ingress简介

    我们传统的集群负载均衡做法是在一台机器上安装Nginx,把我们的服务配置在Nginx上,外部直接访问你Nginx,它帮我们做负载,做限流,但是今天我们玩了K8S,就不能在用这种方法了,我们大胆的想一下,我们把所有的东西都在K8S做了,岂不美哉!想法很好,"好事者"已经替我们想到了,并且替我们做到了。
    kubernetes ingress 文档
    我来简单介绍一下:
    在这里插入图片描述
    如图:在K8S中,Ingress 提供 controller接口,由各个负载均衡厂家实现,传统Nginx是配置在nginx.conf 中,在K8S中,我们只需要配置Ingress 资源yaml就可以,听起来是不是方便多了,我们可以像管理deployment,servicepod一样管理Ingress
    在这里插入图片描述

    3.3.3.2 Ingress 安装

    我们使用 Nginx Ingress Controller 来一波骚操作:
    编写 ingress-nginx.yaml

    $ vi  ingress-nginx.yaml
    

    键入以下内容:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: ingress-nginx
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
    
    ---
    
    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: nginx-configuration
      namespace: ingress-nginx
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
    
    ---
    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: tcp-services
      namespace: ingress-nginx
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
    
    ---
    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: udp-services
      namespace: ingress-nginx
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
    
    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: nginx-ingress-serviceaccount
      namespace: ingress-nginx
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1beta1
    kind: ClusterRole
    metadata:
      name: nginx-ingress-clusterrole
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
    rules:
      - apiGroups:
          - ""
        resources:
          - configmaps
          - endpoints
          - nodes
          - pods
          - secrets
        verbs:
          - list
          - watch
      - apiGroups:
          - ""
        resources:
          - nodes
        verbs:
          - get
      - apiGroups:
          - ""
        resources:
          - services
        verbs:
          - get
          - list
          - watch
      - apiGroups:
          - ""
        resources:
          - events
        verbs:
          - create
          - patch
      - apiGroups:
          - "extensions"
          - "networking.k8s.io"
        resources:
          - ingresses
        verbs:
          - get
          - list
          - watch
      - apiGroups:
          - "extensions"
          - "networking.k8s.io"
        resources:
          - ingresses/status
        verbs:
          - update
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1beta1
    kind: Role
    metadata:
      name: nginx-ingress-role
      namespace: ingress-nginx
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
    rules:
      - apiGroups:
          - ""
        resources:
          - configmaps
          - pods
          - secrets
          - namespaces
        verbs:
          - get
      - apiGroups:
          - ""
        resources:
          - configmaps
        resourceNames:
          # Defaults to "<election-id>-<ingress-class>"
          # Here: "<ingress-controller-leader>-<nginx>"
          # This has to be adapted if you change either parameter
          # when launching the nginx-ingress-controller.
          - "ingress-controller-leader-nginx"
        verbs:
          - get
          - update
      - apiGroups:
          - ""
        resources:
          - configmaps
        verbs:
          - create
      - apiGroups:
          - ""
        resources:
          - endpoints
        verbs:
          - get
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1beta1
    kind: RoleBinding
    metadata:
      name: nginx-ingress-role-nisa-binding
      namespace: ingress-nginx
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: nginx-ingress-role
    subjects:
      - kind: ServiceAccount
        name: nginx-ingress-serviceaccount
        namespace: ingress-nginx
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1beta1
    kind: ClusterRoleBinding
    metadata:
      name: nginx-ingress-clusterrole-nisa-binding
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: nginx-ingress-clusterrole
    subjects:
      - kind: ServiceAccount
        name: nginx-ingress-serviceaccount
        namespace: ingress-nginx
    
    ---
    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-ingress-controller
      namespace: ingress-nginx
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
    spec:
      replicas: 1
      selector:
        matchLabels:
          app.kubernetes.io/name: ingress-nginx
          app.kubernetes.io/part-of: ingress-nginx
      template:
        metadata:
          labels:
            app.kubernetes.io/name: ingress-nginx
            app.kubernetes.io/part-of: ingress-nginx
          annotations:
            prometheus.io/port: "10254"
            prometheus.io/scrape: "true"
        spec:
          # wait up to five minutes for the drain of connections
          terminationGracePeriodSeconds: 300
          serviceAccountName: nginx-ingress-serviceaccount
          hostNetwork: true
          nodeSelector:
            name: ingress
            kubernetes.io/os: linux
          containers:
            - name: nginx-ingress-controller
              image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.26.1
              args:
                - /nginx-ingress-controller
                - --configmap=$(POD_NAMESPACE)/nginx-configuration
                - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
                - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
                - --publish-service=$(POD_NAMESPACE)/ingress-nginx
                - --annotations-prefix=nginx.ingress.kubernetes.io
              securityContext:
                allowPrivilegeEscalation: true
                capabilities:
                  drop:
                    - ALL
                  add:
                    - NET_BIND_SERVICE
                # www-data -> 33
                runAsUser: 33
              env:
                - name: POD_NAME
                  valueFrom:
                    fieldRef:
                      fieldPath: metadata.name
                - name: POD_NAMESPACE
                  valueFrom:
                    fieldRef:
                      fieldPath: metadata.namespace
              ports:
                - name: http
                  containerPort: 80
                - name: https
                  containerPort: 443
              livenessProbe:
                failureThreshold: 3
                httpGet:
                  path: /healthz
                  port: 10254
                  scheme: HTTP
                initialDelaySeconds: 10
                periodSeconds: 10
                successThreshold: 1
                timeoutSeconds: 10
              readinessProbe:
                failureThreshold: 3
                httpGet:
                  path: /healthz
                  port: 10254
                  scheme: HTTP
                periodSeconds: 10
                successThreshold: 1
                timeoutSeconds: 10
              lifecycle:
                preStop:
                  exec:
                    command:
                      - /wait-shutdown
    
    ---
    

    这个文件并不是我胡编乱造自己写的,是"好事者"帮我们做好了,我只是稍作修改:设置网络模式为hostNetwork:true,我希望我在集群中一台机器上开一个80端口,用这台机器作为负载均衡入口,因此:nodeSelector: name: ingress。这是节点选择器配置参数,设置这个,ingress服务会在节点名字为ingress的机器上部署。
    在这里插入图片描述
    接下来我们在集群中的除master节点之外的一个机器上执行下个命令:给这台hostname为worker01-kubeadm-k8s的机器取个别名ingress

    $ kubectl label node worker01-kubeadm-k8s name=ingress
    

    接下来,我们在master节点执行安装ingress操作

    $ kubectl apply -f ingress-nginx.yaml
    

    安装过程有点儿慢,因为有个镜像比较难拉取:quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.26.1,建议执行 docker pull 先拉取到本地,上传到阿里云,然后在各个节点从阿里云拉取,然后在打tag的骚操作,都是有经验的程序员,你们知道我在说什么!

    3.3.3.3 Ingress 配置启动

    编写Ingress yaml资源:

    $ vi nginx-ingress.yaml
    

    键入以下内容:

    #ingress
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: nginx-ingress
    spec:
      rules:
      - host: test.test.com
        http:
          paths:
          - path: /
            backend:
              serviceName: ingress-docker-demo-service
              servicePort: 80
    

    文件定义了一种Ingress的资源,配置host为:test.test.com,代理K8S中名字为ingress-docker-demo-service的 Service, Service端口为80.看起来是不是和Nginx配置有点儿类似?
    最后一步:启动

    $ kubectl apply -f nginx-ingress.yaml
    

    3.3.3.4 验证

    因为test.test.com是不存在的域名,我们都是有经验的开发人员,很自然的想到去修改本地host : 添加 ip test.test.com,ip为K8S节点中设置的别名为ingress的ip地址
    浏览器访问:
    在这里插入图片描述
    在这里插入图片描述
    完美!

    3.3.3.4 自动扩缩

    使用如下命令,可以然服务实现自动扩缩:

    $ kubectl autoscale ingress-docker-docker-deployment.yaml --min=2 --max=5 --cpu-percent=80
    

    还有很多自动扩缩的规则,老铁们自己探讨!

    4. 总结

    K8S实战还有很多玩法,我今天只是讲了最简单的服务部署,在不同的生产环境中,需求也是不一样的,比如说:一个简单的web应用,有mysql数据库,有redis,有springboot应用,都要在K8S中实践,这又是另一种部署方法,但万变不离其宗核心都是要深入了解K8S网络,只有网络打通了,各个组件才会畅通无阻的运行。有兴趣的老铁可以关注一波,一起Hello World!

    下一篇:K8S实战进阶篇:一文带你深入了解K8S持久化存储解决方案

    展开全文
  • K8S 集群实战

    千人学习 2019-09-03 10:30:42
    本课程主要包含k8s集群的安装,k8s各种资源详细介绍和使用,k8s各种扩展组件的部署和使用,k8s核心功能弹性伸缩演示,k8s持久化存储,k8s代码自动发布,让你真正的能够让你的业务在k8s中落地运行!
  • k8s

    2020-11-23 10:21:16
    K8s框架: Api server:所有服务访问统一入口 Node节点需要安装三个软件:kubelet、kube proxy、docker 高可用集群副本一般单数,3个以上(以免产生单节点故障),选举机制 在k8s中它的资源调度可以人为选择,并不是...
  • k8s介绍以及结构

    万次阅读 2019-03-24 22:46:50
    功能: 数据卷:pod中容器之间共享数据,可以使用数据卷 应用程序健康检查:容器内服务可能进程堵塞无法处理请求,可以设置监控检查保证应用健壮性 复制应用程序实例:控制器维护着pod副本数量,保证一个pod或一组...
  • 一、下面我们开始搭建K8S集群 配置K8S的yum源(自v1.6.0起,Kubernetes默认启用了CRI,Container Runtime Interface,详情请查看官网:...
  • k8s重要概念及部署k8s集群(一)

    万次阅读 多人点赞 2019-06-22 18:15:43
    cluster是 计算、存储和网络资源的集合,k8s利用这些资源运行各种基于容器的应用。 2.master master是cluster的大脑,他的主要职责是调度,即决定将应用放在那里运行。master运行linux操作系统,可以是物理机...
  • k8s基本概念

    万次阅读 多人点赞 2018-02-06 15:08:28
    前期对springboot、springcloud的config、eruka、fein、hystrix以及docker都有了一定的了解,后边想重点学习一下k8s,个人认为前边这些最后再加上k8s才是微服务最好的实践方案,这也是学习k8s的最初原因。...
  • k8s docker集群搭建

    万次阅读 多人点赞 2017-12-05 13:09:39
    一、Kubernetes系列之介绍篇   •Kubernetes介绍 1.背景介绍  云计算飞速发展  - IaaS  - PaaS  - SaaS  Docker技术突飞猛进  - 一次构建,到处运行  - 容器的快速轻量 ... 首先,他是一个全新的基于容器技术...
  • 40道常见的 K8S 面试题总结

    万次阅读 多人点赞 2019-09-07 10:00:00
    点击上方“民工哥技术之路”选择“星标”每天10点为你分享不一样的干货读者福利!多达 2048G 各种资源免费赠送作者:fiisio译文:https://zhuanlan...
  • k8s node节点重新加入master集群

    万次阅读 2020-07-10 11:49:20
    k8s使用过程中,有时需要将现有的node节点删除,并且从新加入。
  • public static void Proccess() { int port = 2018; string host = "127.0.0.1"; IPAddress ip = IPAddress.Parse(host);... Socket sSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, Pr
  • Ubuntu下k8s安装教程

    万次阅读 2019-09-03 23:10:29
    官网:https://kubernetes.io/docs/setup/independent/install-kubeadm/ 1 我的主机是在aliyun上,默认配置了阿里源 配置阿里源: 修改/etc/apt/source为: deb http://mirrors.aliyun.com/ubuntu/ xenial main...
  • (Kubernetes)k8s简介 docker安装

    万次阅读 多人点赞 2018-09-16 20:32:43
    Kubernetes 简介 Kubernetes 是一个自动化部署、伸缩和操作应用程序容器的开源平台。 使用 Kubernetes,你可以快速、高效地满足用户以下的需求: 快速精准地部署应用程序 即时伸缩你的应用程序 ...
  • 从零开始搭建K8S--搭建K8S Dashboard

    万次阅读 多人点赞 2018-08-29 09:38:31
    一、K8S Dashboard简介 简单的说,K8S Dashboard是官方的一个基于WEB的用户界面,专门用来管理K8S集群,并可展示集群的状态。K8S集群安装好后默认没有包含Dashboard,我们需要额外创建它。 Dashboard的搭建过程中...
  • k8s常见面试

    千次阅读 2019-04-01 18:40:26
    如何在 Kubernetes 中实现负载均衡? 在生产中,你如何实现 Kubernetes 自动化? 你如何扩展 Kubernetes 集群? 你能解释 Deployment、ReplicaSets、StatefulSets、Pod、CronJob 的不同用途吗?...
  • 最新Kubernetes(k8s)服务集群安装部署

    万次阅读 2020-07-10 11:10:21
    1、服务器环境 节点CPU核数必须是 :>= 2核 ,否则k8s无法启动 DNS网络: 最好设置为 本地网络连通的DNS,否则网络不通,无法下载一些镜像 linux内核: linux内核...k8s-node02: 此机器用来安装k8s node节点的环境
  • k8s-集群搭建 k8s介绍 什么是k8s k8s是一个舵手,专门用来进行给docker掌管方向的,换句话说,就是用来控制docker运行容器的 和docker 是一样的功能。所以就有一个概念cluster 为什么要使用k8s 因为当docker容器异常...
  • k8s如何部署项目 什么是微服务 我们开发一个项目,这个项目有很多很多的模块,如果是一个单体项目,我们所有的模块一起部署,这个时候如果一个模块需要进行升级和维护,那我们必须停止这个项目,修改后再进行部署,...
  • k8s相关的面试

    2019-09-28 15:44:48
    k8s相关的面试题 https://blog.csdn.net/huakai_sun/article/details/82378856 posted on 20...
  • 运维面试题之k8s

    2019-10-05 22:18:19
    我干嘛要知道这些,能用不就行了k8s真香 Kubernetes有哪些特性? Kubernetes是自动化容器编排的开源平台,目标是让部署容器化的应用简单并且高效,提供了应用部署,规划,更新,维护的一种机制 Kubernetes一个...
  • 从零开始搭建K8S--搭建K8S Ingress

    万次阅读 2018-08-29 10:23:07
    Ingress是个什么鬼,网上资料很多(推荐官方),大家自行研究。简单来讲,就是一个负载均衡的玩意,其主要用来解决使用NodePort暴露Service的端口时Node IP会漂移的问题。...这是因为在K8S集群中,如...
  • k8s基础概念

    万次阅读 2019-03-11 18:39:30
    k8s集群示意图master节点 1.1 etcd(数据库) 作为apiServer的数据库,保存了整个集群所有资源的状态 1.2kube-apiserver(暴露k8s资源api的服务) apiServer实现了k8s的所有资源(Node/Pod/RC/Service等)的...
  • 安装 首先咱们简单的介绍一下Docker三个重要的概念: ...那么清楚了上面的概念,就容易给K8s定位了,简单来说K8s是开源的容器集群管理系统,与Docker Swarm组成目前主流的两大开源的容器集群管理系...
  • docker+k8s+jenkins相关面试 转载于:https://www.cnblogs.com/sxdcgaq8080/p/10709057.html
  • K8s上部署Redis 集群

    万次阅读 热门讨论 2019-06-04 14:32:51
    一、前言 架构原理:每个Master都可以拥有多个Slave。当Master下线后,Redis集群会从多个Slave中选举出一个新的Master作为替代,而旧Master重新上线后变成新Master的Slave。 二、准备操作 本次部署主要基于该...S...

空空如也

1 2 3 4 5 ... 20
收藏数 120,946
精华内容 48,378
关键字:

k8s