博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
1-kubernetes-基本了解
阅读量:6375 次
发布时间:2019-06-23

本文共 1874 字,大约阅读时间需要 6 分钟。

hot3.png

1.kubernetes基本知识了解

    在kubernetes中,Service服务是分布式集群的架构的核心

    1.1

        一个Service对象拥有如下关键特征

            拥有一个唯一的名字

            拥有一个虚拟IP(cluster IP,Service IP,VIP)和端口号

            能够提供某种远程服务能力

            被映射到了提供这种服务能力的一组容器上

    1.2

        Service的服务进程都基于socket通信方式对外提供服务,虽然一个Service通常由多个相关服务进程来提供服务,每个服务进程都有一个独立Endpoint(IP+Port)访问点,但kubernetes内建的透明负载均衡和故障恢复机制,不管后端有多少服务进程,也不管某个服务进程是否用于发生故障而重新部署到其他机器,都不会影响对服务的正常访问,更重要的是Service本身一旦创建就不再变化,意味着在kubernetes集群中,再也不用为了服务的IP地址变化的问题而蛋疼了

    1.3 

        容器提供了强大的隔离功能,所以有必要把为Service提供服务的这组进程放入容器中进行隔离,为此kubernetes涉及Pod对象,将每个服务进程包装到Pod中,使其成为Pod中运行的一个容器,为了建立Service和Pod之间的关联关系,kubernetes首先给每个Pod贴上一个标签Label,给运行Nginx的Pod贴上name=nginx标签,给运行php的Pod贴上name=php标签,然后给相应的Service定义标签选择器Label Selector,例如nginx标签选择器的条件为name=nginx,意为该Service要作用于所有包含name=nginx Label的Pod上,这样以来就解决了Service和Pod关联问题

    1.4

        Pod首先运行在kubernetes中定义的节点Node中,节点可以是物理机也可以是虚拟机,通常一个节点上运行几百个Pod

        Pod里与运行着一个特殊的被称之为Pause的容器,其他容器则为业务容器,这些业务容器共享Pause容器的网络栈和volume挂载卷,因此他们之间的通信和数据交换更为高效,在设计的时候可以利用这一特性将一组密切相关的服务进程放入一个Pod中,

    最后需要注意的是并不是每个Pod和它里面运行的容器都能映射到一个Service上,只有那些提供服务无论是对外和对内的一组Pod才会被映射成一个服务

    1.5

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

    1.6

        最后看看传统IT系统服务中扩容和服务升级这两个难题,以及kubernetes所提供的全新解决思路,服务的扩容涉及资源分配,实力部署和启动等环节,在一个复杂业务系统中,这两个问题基本靠人工一步步操作得以完成

        在kubernetes集群中,只需要为需要扩容的Service关联的Pod创建一个Replication Controller简称RC,则该Service的扩容以至于后来的Service升级等问题都可以解决

        一个RC定义文件中包含3个关键信息

                目标Pod的定义

                目标Pod需要运行的副本数量Eplicas

                需要监控的目标Pod标签Label

        在创建好RC后,kubernetes会通过RC定义的Label筛选出对应Pod实例并实时监控其状态和数量,如果实例少于定义的副本数量Replicas,则会根据RC中定义的Pod模版来创建一个新的Pod,然后将此Pod调度到合适的Node上启动运行,直到Pod实例数量达到预定目标,这个过程完全自动化的,有了RC服务的扩容就变成一个数字游戏了,只要修改RC中的副本数量即可,后续的Service升级也可以通过修改RC来自动完成

这里有张图方便理解

 

转载于:https://my.oschina.net/eddylinux/blog/956532

你可能感兴趣的文章
Dockerfile构建Nginx1.14环境
查看>>
bash 交互与非交互
查看>>
介绍Kubernetes监控Heapster
查看>>
linux的free、ps、netstat、tcpdump命令工具介绍
查看>>
javascript学习笔记:DOM节点关系和操作
查看>>
分布式事务
查看>>
怎么提高自身技术
查看>>
HTML5简介,C/S与B/S架构
查看>>
北京游泳馆
查看>>
linux利用rpm包安装jdk,mysql
查看>>
第三方登录原理和流程
查看>>
cacti安装与配置
查看>>
Mac 安卓模拟器打开 ONS
查看>>
完全卸载Oracle 11g教程
查看>>
Oracle调整表空间大小——ORA-03297: 文件包含在请求的 RESIZE 值以外使用的数据
查看>>
二叉树(一)
查看>>
[Windows Azure]Windows Azure Identity
查看>>
Java 技术新手入门
查看>>
【运维囧事】显卡而引起的事故
查看>>
我的友情链接
查看>>