k8s 内部的kafka要映射到外网,直接把 kafka 通过 expose 把pod 映射成服务,使用nodeport 连接,出现超时问题, 解决思路: 1.  查看zk中,kafka的注册信息,PLAINTEXT://kafka-0.kafka-hs.sy-platform-demo.svc.cluster.local.:9093", 而应用代码中,必须使用这个域名+端口进行连接,由于k8s使用30000-32000,端口对外映射,所以9093端口必须修改 2.  kafka.yaml文件修

一  了解Statefulset 1.1  对比statefulset与RS以及RC的区别以及相同点 Statefulset是有状态的,而RC以及RS等是没有状态的 Statefulset是有序的,拥有规则的主机名和名称,而RS以及RC是无序的 通常为Statefulset提供的服务一般都是创建headless service,通过headless service可以为statefulset提供唯一的DNS记录,例如一个在default的命名空间里面名为A-0的pod,提供服务的为foo的hea

前面我写的一系列博客,如果你能够耐心看到这一篇,那你应该对一个概念就不是太陌生了:Deployment. 为什么提这个概念呢,这就要说到Deployment的一个不足了.Deployment不足以覆盖所有的应用编排问题,因为在它看来,一个应用的所有Pod,是完全一样的,所以它们之间就没有顺序,也无所谓运行在哪台宿主机上.需要时,Deployment就通过Pod模板创建新的Pod,不需要时,就"杀掉"任意一个Pod. 但是在实际场景中,并不是所有应用都满足这样的要求.比如:主从关系,主备

Deployment 实际上并不足以覆盖所有的应用编排问题. 造成这个问题的根本原因,在于 Deployment 对应用做了一个简单化假设. 它认为,一个应用的所有 Pod,是完全一样的.所以,它们互相之间没有顺序,也无所谓运行在哪 台宿主机上.需要的时候,Deployment 就可以通过 Pod 模板创建新的 Pod:不需要的时候, Deployment 就可以“杀掉”任意一个 Pod. 但是,在实际的场景中,并不是所有的应用都可以满足这样的要求. 尤其是分布式应用,它的多个实例之间,往往有依

什么是StatefulSet StatefulSet 是Kubernetes中的一种控制器,他解决的什么问题呢?我们知道Deployment是对应用做了一个简化设置,Deployment认为一个应用的所有的pod都是一样的,他们之间没有顺序,也无所谓在那台宿主机上.需要扩容的时候就可以通过pod模板加入一个,需要缩容的时候就可以任意杀掉一个.但是实际的场景中,并不是所有的应用都能做到没有顺序等这种状态,尤其是分布式应用,他们各个实例之间往往会有对应的关系,例如:主从.主备.还有数据存储类应用,它

之前一直docker-compose跑zk集群,现在把它挪到k8s集群里. docker-compose跑zk集群 zk集群in k8s部署 参考: https://github.com/kubernetes/contrib/blob/master/statefulsets/zookeeper/zookeeper.yaml https://kubernetes.io/docs/tutorials/stateful-application/zookeeper/ 我修改了下默认的yaml 1.zk.

1.statefulset.yaml apiVersion: apps/v1kind: StatefulSetmetadata:   name: webspec:    serviceName: "nginx"    replicas: 2    selector:     matchLabels:        app: nginx    template:        metadata:             labels:                  app: ngin

目录 一.statefulset简介 二.为什么要有headless?? 三.为什么要 有volumeClainTemplate?? 四.statefulSet使用演示 (1)查看statefulset的定义 (2)清单定义StatefulSet (3)删除前期的操作 (4)修改pv的大小为2Gi (5)创建statefulset 五.滚动更新.扩展伸缩.版本升级.修改更新策略 1.滚动更新 2.扩展伸缩 3.更新策略和版本升级 一.statefulset简介     从前面的学习我们知道使用D

   从前面的学习我们知道使用Deployment创建的pod是无状态的,当挂载了Volume之后,如果该pod挂了,Replication Controller会再启动一个pod来保证可用性,但是由于pod是无状态的,pod挂了就会和之前的Volume的关系断开,新创建的Pod无法找到之前的Pod.但是对于用户而言,他们对底层的Pod挂了是没有感知的,但是当Pod挂了之后就无法再使用之前挂载的存储卷.     为了解决这一问题,就引入了StatefulSet用于保留Pod的状态信息.     

PetSet首次在K8S1.4版本中,在1.5更名为StatefulSet.除了改了名字之外,这一API对象并没有太大变化. 注意:以下内容的验证环境为CentOS7.K8S版本1.5.2,并部署SkyDNS. http://blog.csdn.net/liyingke112/article/details/76685794 概念 在云原生应用的体系里,有下面两组近义词:第一组是无状态(stateless).牲畜(cattle).无名(nameless).可丢弃(disposable):第二组是

系列目录 概述 RC.Deployment.DaemonSet都是面向无状态的服务,它们所管理的Pod的IP.名字,启停顺序等都是随机的,而StatefulSet是什么?顾名思义,有状态的集合,管理所有有状态的服务,比如MySQL.MongoDB集群等. StatefulSet本质上是Deployment的一种变体,在v1.9版本中已成为GA版本,它为了解决有状态服务的问题,它所管理的Pod拥有固定的Pod名称,启停顺序,在StatefulSet中,Pod名字称为网络标识(hostname),还

一开始Kubernetes只是被设计用来运行无状态应用,直到在1.5版本中才添加了StatefulSet控制器用于支持有状态应用,但它直到1.9版本才正式可用.本文将介绍有状态和无状态应用,一个通过K8S StatefulSet来编排有状态应用的示例,以及当前有状态应用容器化现状及将来的发展趋势. 1. 有状态应用和无状态应用 无状态应用(Stateless Application)是指应用不会在会话中保存下次会话所需要的客户端数据.每一个会话都像首次执行一样,不会依赖之前的数据进行响应.有状态

一.kubernetes exposed servcie 暴露服务的几种方式: LoadBalancer NodePort Ingress HostNetwork HostPort LoadBalancer只能配置在serveice,需要云运营商提供支持.HostPort应用不是很多,特殊情况下可能会用到.HostNetwork用的时候设置为true. 本文主要介绍NodePort.ingress 1.NodePort NodePort是暴露在全局的方式,使用了NodePort整个集群的node

一.首先说headless Service和普通Service的区别 headless不分配clusterIP headless service可以通过解析service的DNS,返回所有Pod的地址和DNS(statefulSet部署的Pod才有DNS) 普通的service,只能通过解析service的DNS返回service的ClusterIP 二.statefulSet和Deployment控制器的区别 statefulSet下的Pod有DNS地址,通过解析Pod的DNS可以返回Pod的

复制有状态的Pod replicaSet通过一个pod模版创建多个pod副本.这些副本除了它们的名字和IP地址不同外,没有别的差异.如果pod模版里描述了一个关联到特定持久卷声明的数据卷,那么ReplicaSet的所有副本都将共享这个持久卷声明,也就是绑定到同一个持久卷声明. 因为是在pod模版里关联持久卷声明的,又会依据pod模版创建多个副本,则不能对每个副本都指定独立的持久卷声明.所以也不能通过一个ReplicaSet来运行一个每个实例都需要独立存储的分布式数据存储服务,至少通过单个Repl

StatefulSet介绍 前面使用Deployment创建的Pod是无状态的,当挂载了volume之后,如果该Pod挂了,Replication Controller会再启动一个Pod来保证可用性,但是由于Pod是无状态的,pod挂了就会和之前的Volume的关系断开,新创建的Pod无法找到之前的Pod.但是对于用户来说,他们对底层的Pod挂了是没有感知的,但是当Pod挂了之后就无法再使用之前挂载的存储卷.为了解决这一问题,就引入了StatefulSet用于保留Pod的状态信息. Statef

StatefulSet 简介 在Kubernetes中,Pod的管理对象RC.Deployment.DaemonSet和Job都是面向无状态的服务.但现实中有很多服务是有状态的,特别是一些复杂的中间件集群,例如MySQL集群.MongoDB集群.Akka集群.ZooKeeper集群等. 以上集群有几个共同点: 1.每个节点都有固定的身份ID,通过这个ID,集群中的成员可以互相发现并且通信 2.集群的规模是比较固定的,集群规模不能随意变动. 3.集群里的每个节点都是有状态的,通常会持久化数据到永久

一.概述 1.在应用程序中我们有两类,一种是有状态一种是无状态.此前一直演示的是deployment管理的应用,比如nginx或者我们自己定义的myapp它们都属于无状态应用. 2.而对于有状态应用,比如redis,mysql,还有etcd,还有zookeeper等等需要存数据的都属于有状态.它们不光有所谓的节点之分,每一个对应的pod还有角色之分,有的是主节点,有的是从节点.而后,从节点不光有所谓的从之分可能还有先后次序之分,我们不同的分布式系统它们的运维管理,逻辑和运维操作过程是不相同的,因

前提 至少需要三个node节点,否则修改亲和性配置 如果外部访问,需要自己暴露 需要有个storageClass,这样做的原因是避免手动创建pv了 部署zk和kafka 参考: https://www.cnblogs.com/ericnie/p/8562561.html https://github.com/kubernetes/contrib/blob/master/statefulsets/zookeeper/zookeeper.yaml 部署zookeeper zookeeper.yaml

DaemonSet 的使用 通过该控制器的名称我们可以看出它的用法:Daemon,就是用来部署守护进程的,DaemonSet用于在每个Kubernetes节点中将守护进程的副本作为后台进程运行,说白了就是在每个节点部署一个Pod副本,当节点加入到Kubernetes集群中,Pod会被调度到该节点上运行,当节点从集群只能够被移除后,该节点上的这个Pod也会被移除,当然,如果我们删除DaemonSet,所有和这个对象相关的Pods都会被删除. 在哪种情况下我们会需要用到这种业务场景呢?其实这种场景还