查看集群

图中有三个集群,集群区域为华北2 状态运行中,节点数为每个集群的worker数.

集群扩容 选择 更多>集群扩容 来为集群扩容节点 也可选择 更多>添加已有节点 来扩容(把ecs添加到集群) 选择 专有网络和交换机 付费方式 选择扩容节点数和规格(规格>内存型>ecs.r5.xlarge) 设置密码提交即可

节点详情

图中test集群有两个worker节点,可查看对应的ip地址 计费方式 内存大小 到期时间 内存CPU使用
如需更细微的监控,请点击右边的监控可查看负载网络等情况
移除worker节点:更多>移除 即可,如需批量移除,请勾选worker节点的选项,点击批量移除即可

无状态

可查看应用数量,容器数量显示应用的节点数和状态
🌰举例:1/1代表1个节点启动成功.0/1代表1个节点但启动失败.1/2代表2个节点但只有一个启动成功

💁🏻详情 查看应用名称,应用的来源(镜像仓库地址),应用的状态,pod的ip,pod所在worker的ip 创建时间 🔎详情 查看该应用所在pod的资源情况 📋日志 选择显示的行数,是否自动刷新日志,可下载日志文件 ⚙️更多 编辑可查看该应用的yaml文件 终端可连接到pod里进行操作 删除可删除当前的pod,但会自动再创建一个 🚪访问方式 可查看和编辑 服务代表pod对外映射的端口 路由代表进来的域名地址转发到pod里的应用地址 🎛容器水平伸缩器 可按照规则进行自动的扩容和减少节点数 最小副本决定该应用的最小节点数 📷历史版本 出现问题时可使用进行回滚(运维配置该回滚有点问题,请勿使用) 🧭触发器 与容器镜像服务的触发器相对应,检测到镜像变化则更新应用
💁🏻编辑 **镜像名称**: 镜像仓库地址 **镜像Tag**: 镜像的版本 **总是拉取镜像**: 当出现删除或扩容时拉取镜像 **所需资源**: 定义的pod内存和cpu **资源限制**: pod共享的内存和cpu (此为pod的最大内存和cpu值) 存活检查 就绪检查 挂载目录到worker节点(当pod重启时,对应目录的数据会保留)
💁🏻伸缩 可增加和减少当前应用的节点数(⚠️当配置容器伸缩水平时,当前此配置无效)
💁🏻监控 可查看应用所在容器的监控,分组为整个组的资源使用,实例可查看单个节点的资源使用
💁🏻更多 可查看yaml文件,重新部署应用,回滚到相应版本,删除应用

有状态

一、在阿里云Kubernetes中运行的服务分为:无状态和有状态
  • 无状态: K8S使用RC(或更新的Replica Set)来保证一个服务的实例数量,如果说某个Pod实例由于某种原因Crash了,RC会立刻用这个Pod的模版新启一个Pod来替代它,由于是无状态的服务,新启的Pod与原来健康状态下的Pod一模一样。在Pod被重建后它的IP地址可能发生变化,为了对外提供一个稳定的访问接口,K8S引入了Service的概念。一个Service后面可以挂多个Pod,实现服务的高可用。

  • 有状态: K8S开发了一套以Pet Set为核心的全新特性,方便了有状态集群服务在K8S上的部署和管理。具体来说是通过Init Container来做集群的初始化工作,用 Headless Service 来维持集群成员的稳定关系,用动态存储供给来方便集群扩容,最后用Pet Set来综合管理整个集群。
    (在 Kubernetes 1.5 或更高版本之后,PetSet 不再可用。改名为 StatefulSet)

二、什么是Init Container?

Init Container就是用来做初始化工作的容器,可以是一个或者多个,如果有多个的话,这些容器会按定义的顺序依次执行,只有所有的Init Container执行完后,主容器才会被启动。

Init Container主要是来做初始化容器工作的应用场景:

  • 等待其他模块Ready:这个可以用来解决服务之间的依赖问题,比如我们有一个 Web 服务,该服务又依赖于另外一个数据库服务,但是在我们启动这个 Web 服务的时候我们并不能保证依赖的这个数据库服务就已经启动起来了,所以可能会出现一段时间内 Web 服务连接数据库异常。要解决这个问题的话我们就可以在 Web 服务的 Pod 中使用一个InitContainer,在这个初始化容器中去检查数据库是否已经准备好了,准备好了过后初始化容器就结束退出,然后我们的主容器 Web 服务被启动起来,这个时候去连接数据库就不会有问题了。
  • 做初始化配置:比如集群里检测所有已经存在的成员节点,为主容器准备好集群的配置信息,这样主容器起来后就能用这个配置信息加入集群。
  • 其它场景:如将Pod注册到一个中央数据库、配置中心等。
三、什么是Pet Set?
  • Pet是一个有状态应用程序,本质上它是一个具有确定性名称以及唯一身份的Pod,身份内容包括:
    DNS中可以识别的固定hostname
    顺序化索引(Pet名称组成:PetSetName-Ordinal)
    链接到索引与hostname的固定存储

  • Pet Set就是Pet集合,它具有特定数量的Pet,其目的就在于解耦集群化有状态应用程序,例如MySQL、PostgreSQL等数据库应用程序,或者Zookeeper、Etcd以及Elasticsearch等集群化应用程序。一般集群化应用程序都是部署在固定的结点上,具有永久性存储以及静态的IP地址,并且在部署过程中需要在结点之间建立一定的关联联系。而Pet Set会给每个应用程序实例分配一个身份,这样应用程序实例就不必固定在物理基础服务上,实例之间依靠身份建立联系。

一个Pet有三个特征。
  1. 是有稳定的存储,这是通过PV/PVC 来实现的。

  2. 是稳定的网络身份,这是通过一种叫 Headless Service 的特殊Service来实现的。Service可以为多个Pod实例提供一个稳定的对外访问接口。这个稳定的接口是通过Cluster IP来实现的,Cluster IP是一个虚拟IP,不是真正的IP,所以稳定。K8S会在每个节点上创建一系列的IPTables规则,实现从Cluster IP到实际Pod IP的转发。同时还会监控这些Pod的IP地址变化,如果变了,会更新IP Tables规则,使转发路径保持正确。所以即使Pod IP有变化,外部照样能通过Service的ClusterIP访问到后面的Pod。

    普通Service的Cluster IP 是对外的,用于外部访问多个Pod实例。而Headless Service的作用是对内的,用于为一个集群内部的每个成员提供一个唯一的DNS名字,这样集群成员之间就能相互通信了。所以Headless Service没有Cluster IP,这是它和普通Service的区别。

    Headless Service 会为关联的每一个 pod 提供对应的 DNS 地址,格式为.。这样,客户端就可以自由地选择想要访问的应用实例,同时也能够解决分布式环境下不同实例之间身份识别的问题。

    样例包含一个名为mysql的 Headless Service,该 service 与 StatefulSet 中的 pod 相关联,这些 pod 将被分配如下 DNS 地址mysql-0.mysql、mysql-1.mysql、mysql-2.mysql。这样,客户端就可以通过mysql-0.mysql访问 master 节点,通过mysql-1.mysql或mysql-2.mysql访问 slave 节点。

  3. 是序号命名规则。Pet是一种特殊的Pod,那么Pet能不能用Pod的命名规则呢?答案是不能,因为Pod的名字是不稳定的。Pod的命名规则是,如果一个Pod是由一个RC创建的,那么Pod的名字是RC的名字加上一个随机字符串。为什么要加一个随机字符串,是因为RC里指定的是Pod的模版,为了实现高可用,通常会从这个模版里创建多个一模一样的Pod实例,如果没有这个随机字符串,同一个RC创建的Pod之间就会由名字冲突。

    如果说某个Pod由于某种原因死掉了,RC会新建一个来代替它,但是这个新建里的Pod名字里的随机字符串与原来死掉的Pod是不一样的。所以Pod的名字跟它的IP一样是不稳定的。
    为了解决名字不稳定的问题,K8S对Pet的名字不再使用随机字符串,而是为每个Pet分配一个唯一不变的序号,比如 Pet Set 的名字叫 mysql,那么第一个启起来的Pet就叫 mysql-0,第二个叫 mysql-1,如此下去。

    当一个Pet down 掉后,新创建的Pet 会被赋予跟原来Pet一样的名字。由于Pet名字不变所以DNS名字也跟以前一样,同时通过名字还能匹配到原来Pet用到的存储,实现状态保存。
    在Kubernetes中,其将容器部署划分成多个Pet,并保证每个Pet都有确定性的唯一身份,身份内容包括DNS域名、一致性存储以及顺序化pod索引。在此之前,使用Deployments和Replication Controllers进行部署,只会给应用程序分配一个非耦合的弱身份。弱身份比较适合微服务等应用程序,这类应用程序不关心pod的名称,其重点在于服务发现,并且这些应用程序是无状态的。然而有很多软件应用程序是需要强身份,例如多种不同类型的分布式有状态系统。Cassandra就是一个比较好的例子,它需要一致的网络标识以及固定的存储。

    Pet Sets提供了如下功能:
    在DNS中具有固定的hostname,同一个Pet Set中的Pet hostname以Pet Set名称为基础,加上从0开始的顺序化数字,例如cassandra-0。
    顺序化索引,例如0、1、2、3。
    链接到Pet序列以及hostname的固定存储。
    通过DNS发现同伴,在Pet创建之前,同伴的名称是已知的。
    顺序启动与销毁Pet,通过Pet编号,下一个需要被创建的Pet是已知的,并且当Pet Set规模减小时,哪些Pet需要被销毁也是已知的。当缩减集群规模时,对于从一个Pet中抽取数据这类管理任务来说,该功能是非常有用的。

四、创建有状态的容器
  • 指定应用名称,集群,命名空间,节点数,类型

  • 选择拉取的镜像的仓库地址

  • 单击选择镜像Tag选择镜像的版本。若不指定,默认为最新版。

  • 勾选总是拉取镜像,表示每次部署或扩容都会从容器镜像服务重新拉取镜像,而不会从本地拉取镜像。

  • 配置应用的cpu和内存

  • 存活检测和就绪检测可按照上篇文章进行配置

  • 配置数据卷挂载本机目录到pod

  • 创建服务,服务名对应应用名

  • 勾选实例间服务发现

  • 端口映射

  • 创建后查看应用的主机名后是否有序号

  • 在pod终端时候尝试是否能通过.:访问应用

服务

名称: 自定义(应用名即可)
关联: 应用的的无状态名称
端口映射: 需要外放的端口

路由

名称: 自定义(可填写域名名称)
域名: 域名(tdev.gzlplink.com)
路径: 要访问的地址(如/api)
服务: 选择服务对应的容器名
勾选开启TLS,使用密钥,既可使用https,如未有密钥可点击新建密钥进行创建