为了能够更全面的去理解k8s的原理
今天主要从k8s 几个基础的元件开始介绍
Pod: 在k8s中,代表的是最小的一个运行单位,是对於Container群集的一种抽象,
里面可以跑多个Container,但通常是一个Pod内只有一个 container
Node: 在k8s中,代表的是一台服务器,不论是虚拟机器或是一台实体的服务器
里面可以跑多个Pod
特别要注意的是每个Pod产生时都自动被赋予一个虚拟IP
而每个Pod可以透过这个虚拟IP来做沟通
以上图为例:my-app pod 就可以透过 DB pod的虚拟IP 来存取到 DB 这个container
虽然每个Pod可以透过虚拟IP来做沟通
然而当每个Pod重新被建立时所属的虚拟IP就重新被分配
加上Pod本身并非是稳定
所以透过虚拟IP来做Pod之间的沟通并非好方法
Service就是可以处理这个问题的元件
Service: 在k8s中, Service提供了一永久的IP让Pod可以挂载在上面,
并且生命周期跟Pod不相依
所以不担心Pod重建立之後存取点会变动
另外, Service会分位可以被外部存取与否分为, 外部Service还有内部Service两种
Service提供了一个永久IP 然而对实际上的应用来说
可是透过IP的方式仍然不够方便
Ingress元件提供了域名服务,让外部使用者可以透过域名来存取对外的Service
Ingress:在k8s, Ingress 提供了域名服务,让外部使用者可以透过域名来存取对外的Service,
并且能够提供平衡负载跟路由的能力来有效分配封包给对应的Service
如果需要更新Pod内部的container内容时,就会需要重新建立container的映像档
然而有时只是需要更新一些设定而已, 这样的代价会有点高
ConfigMap元件让Pod放置应用程序设定值,并且在整个pod可以共享设定值
因此当应用程序值做了修改,不需要经过整个重建container的过程
ConfigMap元件存储设定档的方式是明文,对一些敏感资料比如资料库连线使用者帐密
不建议存放於此
Secret元件提供了Pod存放机敏资料的功能,以base64编码存放资料
ConfigMap:在k8s中,ConfigMap提供存放Pod应用程序设定值的功能,
但是明码存放,不适合存放机敏资料
Secret:提供了Pod存放机敏资料的功能,以base64编码存放资料
在前面的架构中, DB Pod或是 APP Pod如果重新启动之时
如果没有另外挂载在container之外的存储系统
存在container内的资料会在重新启动後消失
所以如果希望container资料能够在重启後被保存
就需要用Volumes元件挂载资料到存储系统
这个存储系统可以在远端也可以是云端或是本地机器上
Volumes: 在k8s,提供Pod挂载存储系统的元件,
这个存储系统可以在远端也可以是云端或是本地机器上
要注意的是,k8s只维护状态,并不会维护Pod所挂载的存储系统状态
概念如下:
k8s为了达到高可用性,因此每个对於每个Pod都是采用Replica的方式
直接复制一份Pod到另一个Node
复制的时候并非重新建制一个,而是使用Deployment元件来建制
Deployment是Pod的蓝图
可是对於有状态的Pod,比如说Database,通常会挂载Volumes
在复制时需要考虑到写入Volumes资料的一致性
这时就需要使用StatefulSet这个元件来做复制
Deployment: 在k8s中,用来建构无状态Pod的蓝图
StatefulSet: 在k8s中,用来建构有状态Pod的蓝图
特别的是,建构有状态的Pod往往比无状态的Pod复杂许多
因此k8s倾向建制无状态的Pod
实体、身份和关联属性 所谓的实体(entity)是指任何具有身份(identity)的人或东西。例...
Computer vision - Process images is key to creatin...
新增表格 add_table() rows:列数 cols:栏数 doc = docx.Docume...
不足的丰富资源 未依团队性质配置的资源,会制造资源不足的假象 在IT团队最大的时候,有11人,分别是...
在 Day04 有提到在 JavaScript 里, 函式执行时会产生函式执行环境,在该执行环境中会...