kubernetes 社群分享 QA 汇总

README

内容主要来自在社群里有关企业 Kubernetes 实践过程的直播分享,下面截取聊天记录的自 QA 部分 。由于提问链接在石墨文档上协作编辑,而石墨文档里的内容是无法被搜索引擎检索到的。这些问题不整理起来就永远地躺尸在石墨文档了,所以就把这些提问的问题汇总到一起,方便大家自查。

Kubernetes 在信也科技的落地实战

提问链接

Q:dns记录是如何维护的,还有maclvlan的记录的维护?谢谢老师回答

A:dns系统我们实现了2个服务,一个是监听在53端口提供dns查询的服务,一个是前台管理站点,前台站点负责dns记录的增删改查。支持单独设置和批量导入功能。这2个服务共享同一个数据库。内容的话是由信也科技各个研发团队共同维护的。macvlan是在每台宿主机上创建的。我们一般会在每台宿主机上创建多个macvlan网段。

Q:Macvlan是没有service,选择MacVLan是基于哪些考虑呢?MacVLan使用过程中,对于不同的内核版本,不同的高可用组网,是存在兼容性问题的,这一块实践能分享下么?

A:选择macvlan一是因为它的简单,使用docker命令就可以创建出来,不需要其他配套的服务或数据库来管理。二是因为它有独立的IP和MAC地址,这样可以让信也科技之前跑在虚拟机上的服务能够快速的迁移到容器。我们对于宿主机的内核版本是严格控制的,不存在内核版本不同的情况。但是macvlan的缺点也比较明显,它依赖于硬件,宿主机需要连到交换机trunk口。并且它的灵活性也不够高,不适合大规模的组网。由于目前信也科技内部的网络结构还是比较简单的,并没有遇到兼容性的问题。

Q:为什么不试着对k8s自动更新呢,每一次手动更新都需要一定的时间成本吧?

A:目前我们认为手动更新比较稳妥,并且更新不是一个频繁的操作,时间成本还好。

Q:请问下,这个是自建机房环境上的集群?是否适用公有云环境?外部访问流量是如何接入的呢?ingress controller基于什么考虑来选择的,谢谢。

A:这个是自建机房环境上的集群。外部的流量会先经过F5,然后经过nginx集群,所有的容器实例和虚拟机都是通过nginx负载均衡的。在nginx上面我们使用了新浪微博的nginx-upsync-module模块,可以从consul同步upstream中的实例。我们并没有使用ingress controller,而是通过用户在我们的容器发布平台上去手动的拉入和拉出流量。用户拉入流量的操作会在consul里面添加实例的IP和端口,nginx自动从consul同步实例后该实例就接入流量了。

Q:直接使用Pod的话,副本控制是如何做的

A:副本控制目前是比较静态的。用户在容器发布平台部署可以选择副本数。此后如果用户不添加和删除实例那么副本数是不会变的。

Q: 如何更新证书

A:先重新生成证书,然后先在master节点上更新,需要依次重启etcd、apiserver、controller-manager和scheduler服务。master更新完毕后,再把所有的node节点上证书更新一下,需要重启kubelet。证书的更新过程中除了造成集群的短暂不可用之外不会影响已经运行的容器的,所以是安全的。

Q:蓝绿发布和灰度发布是如何实现的?

A:这2个都是通过我们的容器发布平台实现。蓝绿发布是通过创建2个发布组,每个发布组含有相同的实例数。通常一个发布组含有当前版本的实例并且是接入流量的,另外一个发布组包含上一版本的实例或者是即将上线版本的实例。通过在2个发布组切换流量来上线新版本或回滚到旧版本。灰度发布可以先上线一个实例的流量,没问题之后可以把剩下的实例都接入流量。这些操作目前都是平台上用户手动操作实现的。

Q:集群平台的高可用是怎么做了?有没有做多集群多活或者灾备?

A:我们生产环境有部署多个k8s集群,也有2个不同的机房部署。我们的容器发布平台会把实例均衡分发到不同的k8s集群。

Q:开发测试环境的镜像仓库如何同步到生产镜像仓库?

A:镜像仓库我们测试和生产用的是同一套。 公司使用的是阿里云的托管版k8s与,发现托管版的k8s并没有多个主节点,问一下阿里的托管版k8s与标准版k8s

Q:问一个细节问题,请问k8s集群扩容是通过什么手段实现的?

A:我们实现了一套ansible脚本去实现自动添加node节点。

Q:我们也是用的macvlan,这个模式下,你们为什么没用cni配置网络,而是用的docker来配置,这样维护成本高一些。另外,macvlan模式,主机无法访问本机内的容器,这个怎么解决的?

A:我们是用docker命令去创建macvlan,实际还是使用k8s的cni。使用vlan之后可以解决主机无法访问本机内的容器。

Q:ingress用的什么,为什么选择它?

A:见Q5问题的回答

Q:刚才提到节点证书过期导致集群异常,k8s本身会在节点异常以后,调度迁移非正常节点的实例的。我的问题是,如果证书更新需要一个过程,那么,节点恢复也是一个过程,这个时候,仍在异常的节点实例,会迁移到正常节点,而且,因为coredns和ingress对接的是apiserver,那么,节点异常基本上等同于这个节点上的实例,都会被apisercer摘掉,虽然容器也还在,但是流量入口和dns侧实例不在了,这样一来,证书过期,不就等同于所有实例全部不可用嘛?

A:因为我们只用了k8s中的pod,并且关闭了k8s中的异常节点自动迁移实例的功能。这些高可用功能我们自己实现了一个类似的,这样可以按我们的需要去定制。coredns我们只是简单的用来作为dns服务器,并没有和apiserver对接,也没有使用ingress,见Q5的回答。

Q:想问下老师你们目前是前后端完全分离的么?目前的前端应用部署方式是怎样的?如何控制一些前端的发布工作流?以及与前端相关的后端微服务部分,是如何保证发布顺序以及关联性的。

A:目前我们上容器的还是以java为主的后端服务偏多。目前能了解到的是前端应用都是放到nginx中来对外提供服务的。对于前端发布的工作流以及如何保证发布顺序以及关联性的目前都是通过人肉去控制和完成的,没有做到自动化。

基于云原生日志分类处理方案与落地实践

提问链接

Q:filebeat 与flunted的区别大不?该如何选择

A:Fluentd 针对结构化的数据,灵活性是一个考量。

Q:filebeat单纯采集docker日志发现不能获取docker.container.name,docker.container.image信息不知为何?

A:filebeat支持多种采集方式,可以将filebeat以进程运行在docker容器中,收集容器日志,也可以单独部署filebeat采集docker生成的日志文件,可以参考filebeat官方yaml配置文件。

Q:能否对采集到的日志信息做到告警处理?

A:告警需要分场景,入库ES可以通过sentinl插件接入告警。 规范处理方式应将各类落地日志对接中心告警平台。

Q: es的机器学习功能是否有实际价值?

A:在机器学习方面没有太多接触。

Q:采集agent是sidecar还是daemon模式?

A:守护进程与二进制部署。分场景部署,大部分采集场景使用daemonset,部分集群外中间件等组件以systemd部署。

Q:有没有EFKoperator相关项目推荐?

A:暂时没有相关推荐。

Q:对于日志采集系统占用资源过多,怎么解决?

A:需要从各方面优化,技术层面也是优化项,如提取偏移量方式对流量有很大影响,如文件扫描频率,对cpu有很大影响。 优化点首先从原生参数根据业务场景进行适配调整,特殊场景考虑原生扩展。

Q:能用filebeat采集journald日志吗?怎么将系统日志和pod日志用同一个filebeat采集?

有journalbeat 开源插件可以采集journald日志。系统日志和pod日志都落地文件,以多源目录采集,一般采用对接logstash做区分处理,若转发不采用logstash,需要扩展filebeat组件支持多目录指定不同的输出采集。
A:有没有调研过阿里开源的log-pilot来采集pod日志?
没有做过相关调研。

Q:beats组件之间是否会有互相影响?比如filebeat MySQL的采集器 redis的采集器 docker的各种,部署很多是否会相互之间有影响

A:你指的是filebeat内置module模块和对外部采集方式如何统一一套部署采集而不相互有影响么? 如果是这样,通过filebeat配置文件指定module采集以及docker产生的文件配置进行采集。

Q:日志告警是用的开源项目还是自研的呢?

A:根据自身的平台确定方案,本案例的场景可以通过开源方案做一些简单告警,如ES通过sentinl做告警,Loki通过grafana告警,若自有大数据平台或者单独的告警平台,按照平台规则对接告警。

Q:日志系统接入消息队列的意义是什么?

A:消息队列是缓冲,重要日志接入消息队列可以提供缓冲存储,多次消费。

Q:都是默认json日志么,有没比较其他log driver 使用场景

A:

Q:用loki主要目的是什么?是某些场景下es的替代品吗?二次开发考虑开源吗?promtail的性能瓶颈具体表现在哪里?和filebeat相比有什么优缺点?

A:

Q: 我看loki现在还是在beta阶段,为什么考虑用?

1121 社群直播:给 K8s API “做减法”:阿里云原生应用管理的挑战和实践

提问链接

Q: rudr是有某公司实际线上使用后开源的,还是纯开源项目?

A1:rudr是一个reference项目,意思是用来做OAM实现的一个参考,目前是纯开源项目,不排除以后会演进为生产可用的项目。

Q:oam spec中目前还没有看到属于infra operator的管理对象(补充:Component是面向app developer, Traits和AppConfiguration面向app operator,哪个对象是面向infra operator的?)

A2:OAM本身就是基础设施运维手里的武器,包括Kubernetes、Terraform等一系列平台层的开源项目,基础设施运维可以通过这些开源项目构建OAM的实现(如rudr基于Kubernetes)。所以OAM的实现层就是基础设施运维提供的,他们不需要额外的对象来使用OAM。

Q:oam controller和admission controller的分工标准是什么

A3:OAM项目中的 admission controller用于转换和检验spec,定位完全等价于K8s中admission controller。目前实现的功能包括转换 [fromVariable(VAR)] 这种spec中的函数,检验AppConfig、Component、Trait、Scope等CR是否符合规范,是否合法等。
OAM Controller,即目前的开源项目rudr,就是整个OAM的实现层,它负责解释OAM的spec并转换为真实运行的资源,这里的资源可以是K8s原有的一些,也可以是像阿里云上的RDS这类云资源。目前rudr项目是Rust语言写的,考虑到K8s生态大多数都是用Go语言写的,我们后续也会开源一个go语言编写的OAM-Framework,用于快速实现像rudr这样的OAM实现层。

Q:计划啥时候开源go的oam-framework呀?

A4: 已经在走内部流程了。同时我们也需要进一步打磨oam-framework,让它适配大家的场景。

Q:想问个问题,阿里是如何降低k8s的复杂度来满足运维和研发一些共性诉求的?在k8s中的用户user角色可能是开发也可能是运维。

A5:目前我们遇到的大多数场景都能区分哪些是运维要关心的,哪些是研发要关心的。OAM降低K8s复杂度的主要方法就是关注点分离,给K8s的API 做减法,尽量让某一方可以少关注一些内容。如果你有这样一个无法分割的场景,其实我们也很感兴趣,欢迎把case提出来一起探讨。另一方面,我们并不是屏蔽掉K8s,OAM spec预留了充足的扩展性,完全可以把K8s原有的能力提供给用户。

Q:我认为OAM是基于k8s针对于不同应用上的抽象层,现在我们有很多应用都是用Helm包包装好的,如果切换成OAM的话,我们需要注意哪些地方呢?

A6:其实我们上半年一直在推广helm在国内的使用,包括提供了阿里的helm镜像站等,所以OAM跟helm也是相辅相成的。简单的说,OAM其实就是helm包里面template文件夹里面的内容。Helm是OAM做参数渲染(template)和打包(chart)的工具。如果切换到OAM,helm的使用方式不需要变,里面的spec换成OAM的spec即可。

Q:请问,rudr 用起来了吗,效果如何。rudr 的架构有没更丰富的资料

A7: rudr一直是可以用的,大家要是用不起来可以提issue,想要什么方面的资料或者疑问也可以提issue,我们也在完善文档。目前相关的材料都在这里:link

Q:rudr的hello world没跑起来,是不是k8s版本需要>1.14 ?

A8:具体这个问题就在github上提issue吧,我们每天都会关注issue,可以贴一些错误日志之类的。

Q:我们一直在用helm打包我们的应用,去做gitops ,一个通用的chart 对应不同的values.yaml 做到了复用。听了分享,很期待OAM,当然还有openkruise。

A9:openkruise 是开源的哈,大家可以关注 openkruise kruise 我们也一直在迭代。

Q:oam有哪些公司在用?实际体验反馈如何?

A10:OAM刚刚发布一个月左右,具体有哪些公司已经在使用我们还没有来得及统计。阿里和微软内部都已经在使用,并且都有对外的产品使用OAM。就我们接触到的用户来说,无论是社区的用户还是阿里内部,都对OAM的关注点分离等理念非常认同,也都在积极落地。

Q: rust 内部有哪些场景和业务使用了?贵司后续会继续运用在哪些场景?

目前有一些小的场景在使用,具体还没有统计过,后续会继续用在一些需要较高性能的场景。

10.10 社群文字直播:超大规模商用 K8s 场景下,阿里巴巴如何动态解决容器资源的按需分配问题?

提问链接

Q:请问heapster中采集到的MetricMemoryWorkingSet指标与ps命令获取到的RSS有何区别?heapster的源码中对该指标的描述是“Total working set usage. Working set is the memory being used and not easily dropped by the kernel”,同时heapster也采集了MetricMemoryRSS,kubectl top为何采用MetricMemoryWorkingSet而不采用MetricMemoryRSS?在Kubernets 1.10版本下,部分运行Java应用的pod出现kubectl top值超过ps RSS值的情况。

A1:阿里巴巴内部并不使用heapster,我们是通过直接去读取容器cgroup值,获取容器实时资源使用情况。据我所知,社区对于heapster完全废弃。建议通过主流工具采集,汇聚,聚合数据。试试 custom-metrics-apiserverkube-state-metrics 。在大规模场景下社区的很多开源工具都存在性能问题,一般这类工具我们倾向于自研。

Q:如何看待suse 放弃openstack?

A2:Openstack是款伟大的软件,它给IaaS的研发和周边生态带了很多意想不到的成果,例如ceph等。SUSE放弃OpenStack可能出于多种原因。或许是技术选型,或许是财政收益等等。顺便说说,SUSE目前在Kubernetes相关领域的投入还是挺多的。最近的Kubecon上,SUSE均展示了相关技术成果。

Q:直接修改 cgroup 容器一定会获得资源吗?

A3:容器技术隔离的技术基础就是cgroup层面。在宿主机腾出足够资源的情况下,给cgroup设置更大的值可以获取更多的资源。同理,对于一般优先级不高的应用,设置较低的cgroup资源值就会达到抑制容器运行的效果。

Q:底层是如何区分在线和离线优先级的?

A4:底层是无法自动获取谁是在线,谁是离线,或者谁的优先级高,谁的优先级低的。这个我们可以通过各种Kubernetes提供的扩展实现。最简单的是通过label,Annotation标识。当然通过扩展QoS class也是一种思路。社区版本的QoS class设置太过于保守,给予用户发挥的空间不大。我们通过这些方面也进行了增强。在合适的时候或许会推向社区。自来来来动感知是个方向,感知谁是干扰源,感知谁是某种资源型应用,这块我们还在研发中。做到真正的动态,肯定是具备自动感知的智能系统。

Q: “与社区版 Vertical-Pod-Autoscaler 不同,Policy engine 不主动驱逐腾挪容器,而是直接修改容器的 cgroup 文件;“,想问一下,不主动驱逐的话,如果Node的资源达到上线了会怎么处理?

A5:这是一个好问题。首先这里要先区分是哪种资源,如果是CPU型的,我们可以调整低优先级容器的cgroup下cpu quota的值,首先抑制低优先级的容器对于CPU的争抢。然后再适当上调高优先级容器的相关资源值。如果是内存型资源,这个不能直接去缩小低优先级容器的cgroup值,否则会造成OOM,对于学习学习内存型资源的调整,我们会在其他分享中继续讨论。这个技术比较特殊。

Q: 只修改cgroup,怎么保证k8s 对单个物理机能够分配更多的容器

A6:文字直播有了一定说明,容器的资源消耗并非是一成不变的,很多时候它们的资源消耗呈现潮汐现象,相同的资源条件下部署更多应用,完成更多作业就是达到资源利用的最大化的效果。资源出现超卖才是我们这个主题讨论的最大价值。

Q:也就是说 低优先级的容器,request 设置的比limit 小很多,然后你们再动态的调整cgroup?

A7:在现有QoS场景下,你可以理解被调整的Pod都是burstable的。但是我们并不是直接调整Pod元数据的limit的值,而是调整limit在cgroup反映的值,这个值在资源竞争缓和的时候还会被调整回去的。我们并不建议单机的cgroup数据和etcd的中心数据割裂太久。如果长期偏离,我们会像VPA发出警报,联动VPA做调整。当然在容器运行的高峰期,任何重建容器的操作都是不明智的。

Q:你们现在cpu 超卖的比例是多少?

A8:这个不方便回答,哈哈。等我确认可以回答的时候再修改这里。

Q:谢谢了,整体的理解就是你们开始就让物理机超配了一定比例的pod,然后通过策略动态调整容器的cgroup值

A9:如果资源完全是富足冗余的,这个动态调整也有一定意义。就是并非资源用满场景下,高优先级应用会被干扰,实际上,当主机的CPU达到一定比例,打个比方例如50%,应用的时延就变大。为了完全确保高优先级应用的SLO,牺牲低优先级的CPU正常运行也是有价值的。

Q:如何确保一定是低优先级的容器和高优先级的服务部署在一起的,而不都是高优先级或者不都是低优先级,只用packing 算法就可以?

A10:这个方法比较多,可以配置亲和性和非亲和性。可以通过预编排等手段。预编排就是在应用部署前,首先规划好各个应用部署在哪些node上。

Q:Policy engine 有没有考虑开源?

A12:有计划进行开源,Policy engine更多的是和自身的应用属性相关,电商应用或者大数据处理应用的策略都是不相同的,我们开源会首先开源框架和附带一些简单的策略,更多的策略可以用户自定义。

Q:只是调整 Cgroup 的配置,对于应用中的配置如何改变?比如 JVM 根据中的一些参数?如果不重启 jvm 如何让 Cgroup 的限制生效?

A8: Java进程还是比较特殊的。很多时候容器重启才能适配的参数才能生效。我们这里针对的是一种通用的方式。对于你提到的这类应用,压制低优先级的容器有效,但是给高优先级应用再分配资源应该无效。

Q:我之前遇到的大部分应用都无法正确感知 cgroup 的配置,因此很多情况都需要在启动参数里面根据 cpu 或者 mem 设置参数,那么也就是说即使改变了 cgroup 对于他们来说都无效,那么使用场景也就有限了

A14:限制容器的资源使用这个还是有价值的。限制低优先级应用本身也可以提升高优先级应用的SLO,虽然效果没有那么明显。稳定性的考量同样也很重要。

Q:Policy engine 目前在阿里的使用如何?在生产上有多上的规模使用这种方式进行动态调整?是否和社区的 HPA VPA 配合使用?

A15: Policy engine在阿里某些集群已经使用。至于规模暂时无法透漏。涉及到很多组件之间的联动,社区的HPA和VPA目前都不太能满足我们的需求。因此阿里的HPA和VPA都是我们自行开发的,但是和社区的原理是一致的。阿里HPA的开源可以关注 openkruise社区。VPA开源计划我这里还没有确切消息。

Q:data aggregator 通过什么方式采集数据?

A16:类似cadvisor方式直接从node的cgroup获取实时资源消耗数据。然后根据容器,node为单位再进行聚合。

Q:当单机节点资源不足以提供容器扩容时,目前是否可以进行HPA或VPA扩容呢

A17:单机节点不足的时候,应用可以通过HPA进行增加副本应对。但是VPA如果选择原节点进行更新的话,是失败的。只能调度到其他资源丰富的节点。在流量陡升的场景下,重建容器未h h必能满足需求,很可能导致雪崩,即重建过程中,整个应用其他未升级的副本接受更多流量,OOM掉,新启动的容器再瞬间被OOM,所以重启容器需要慎重。快速扩容(HPA)或者快速提升高优先级资源,抑制低优先级容器资源的方式效果更明显。

1107 社群直播:如何实现 K8s 一键部署?开发部署提速 8 倍?带你上手一款下载超 10 万次的 IDEA 插件

提问链接

Q: k8s各组件,比如etcd,建议部署在容器内还是物理机?有什么区别或者优劣吗?

A1:etcd可以部署在容器里,物理机的话就是性能更好一点。

Q:如果登录是堡垒机,并且是动态密码,那个配置保存必须要密码,所以不方便吧!能动态密码登陆局域网服务器吗?

A2:这是个非常好的建议,我们需要在后续的版本中开发这些能力。

Q:如何在本地电脑(如mac)部署k8s玩玩,以及写Go代码增删改查k8s资源,这块有啥玩一玩的优良经验嘛?目的是想本地开发测试k8s,更加去熟悉k8s内部机制。

A3:本地mac要玩k8s可以去搜一下minikube。

Q:k8s一键部署是用kubeadm部署么,本地虚拟机部署多节点k8s集群,虚拟机网络应该怎么处理。由于是自己部署着玩玩,在公司里虚拟机网络不能使用桥接的方式。而使用网络地址转换NET+hostonly 在起calico网络的时候worker节点calico起不来,提示网络冲突。谢谢

A4: nat模式两个机器会用同一个IP,所以会冲突,可以给虚拟机配两个网卡,1个网卡用NET+hostonly用来访问外部网络,1个网卡用private network用来节点间Pod的网络

Q:对于后端开发者来说(写Go),有必要去更加熟悉k8s么?毕竟k8s就是个运维工具,为了更爽的去部署软件以及扩容等等,有必要去深入了解k8s内部机制么,这块有没有什么建议和见解?

A5:首先,Kubernetes 本身是用 Go 语言写的,就是一个最好的 Go 语言开发和架构的最佳学习物。

Q:k8s 网络组件calico和自带的flannel,请问建议采用哪一个?

A6:简单上手选flannel,看重功能选calico

Q:有哪些开源的管理k8s Web UI 软件,这样可以部署在公司内,所有团队直接在该软件内傻瓜式操作k8s资源,自己部署上线代码?

A8:K8s自带的dashboard可以试试

Q:我想深入学k8s,但是k8s内部使用了 etcd/coredns,以及监控这块使用 prometheus,这些技术是不是先深入学习下,再去深入学习 k8s呢,毕竟 k8s 太大了,一上来就深入会容易找不到门路,这块大大有啥经验没?

A9:建议从K8s核心开始学习,再学习周边组件。从中心到外围的顺序。推荐学习下CNCF和阿里云联合做的这个免费公开课:link

Q:若k8s集群服务器宕机,请问如何快速恢复集群能力(除拉起kubelet等待其他组件自动拉起,是否还有其他方式)?

A10:配置3master高可用可降低宕机带来的损失,另外备份组件的配置文件。

Q:Master节点如果同时作为node节点,请问存在哪些风险?

A11:master节点不宜作为node节点部署应用,会导致集群不稳定。

Q: 您好!现在使用了jenkins pipeline做为ci工具,cd1: helm chart 对每个应用编写对应的chart,通过questions.yaml在rancher定制化接口. cd2: 通过argocd 和helm chart 形成的git ops ,请问有没有更好的工具推荐? 想解决批量升级,现在每次升级都需要人工干预.

A12:

Kubernetes在SHAREit的落地实战

提问链接

Q:直接采用物理机还是有先做IaaS层虚拟化?

A:我们做的是出海业务,基本上考虑到合规等问题,我们主要项目全部运行在公有云上。

Q:有没有碰到调度的问题,某台服务器CPU或内存高了仍调度到这台上?

A:遇到过,一般情况下,需要考虑你的应用是否加了很多亲和性或是nodeselector。正常的调度器,是会优先考虑资源平衡的。

Q:请问一下coredns如何反解析pod的IP地址?不用svc的情况下,是否可以解析pod的名字?是否有用coredns的rewrite插件。

A:这个不清楚,我们没有这样的场景。但是coredns,支持编写自己的插件。

Q:请问下,不同云之间的延时怎么解决?你们是一朵云就部署一个完整的业务么?

A:我们会在不同云之间通过专线打通。基本上相关联的业务会部署在一家云上。但是我们会尽量保证同一个业务部署在不同的AZ。

Q:告警策略上有没有最佳实践分享?

A:我们的统一报警平台基于alertmanager实现,基本上用到了它提供的静默,分组,抑制等特性。只不过我们对接了它的api,也集成到scmp当中。

Q:配置管理是怎么做到不同环境,不同配置?

A:我们的配置是在configmap结合数据库来实现版本管理,本质上每个集群都需要单独设置。所以不同的环境,设置不同的configmap即可。

Q:业务的数据库是在k8s里面运行,还是单独搭集群?

A:我们除了prometheus和一些mq,我们目前还没有尝试有状态应用。

Q:linux内核参数优化具体你们碰到过哪些坑呢,怎么优化的呢?线上使用的centos版本和内核如何选择的?

A:我们使用的是公有云,内核版本一般公有云提供版本中最新的。其实不同的主机类型,相应的参数不一样,需要在选型主机的时候,做大规模测试。比如 net.netfiletr 下的参数。我们会基于公有云镜像,做优化,然后利用pakcer打成新的镜像使用。

Q:自研组件,可以开源吗?比如日志的那个

A:SHAREit 是一个技术非常open的单位。我们从上到下,鼓励技术人员去分享。所以如果大家有需要,我们会做一下内部的整理,开源出去。同时,我也会写一些具体的文章,来讲具体的细节。

Q:alertmanager报警,我使用的prometheus operator安装的,使用默认的微信报警,这个报警时区问题,是修改源码解决,还是使用一个webhook?报警的模板文件是如何管理的?

A:我觉得你应该需要重新定制alertmanager的镜像,在dockerfile中修改时区。其实我们这边也fork了alertmanager,做了一些优化和功能增强,比如直接将dingtalk集成进来,避免引入webhook组件,所以我们也是自己打的镜像。至于报警模板,我们这边先把报警模板数据存放到数据库当中,然后结合confd来实现altermanager 配置文件刷新的。

Q:hpa部分你们怎么做到根据不同业务选择不同的策略?

Jenkins X:基于 Kubernetes 的 Serverless Jenkins

提问链接

Q:这是干嘛的

A:在分享有关 Kubernetes 之上的 DevOps 产品 Jenkins X,有兴趣的话可以了解一下。可以加速软件的交付速度与可靠性。

Q:有实际应用案例吗?自己怎么快速体验JenkinsX的特性?

A:现在国内的应用案例相对较少,是属于下一代的 CI/CD 产品,在国外的用户会更多一些。jenkins x 支持一键在大型云厂商/现有 kubernetes 集群上进行部署,可以参考官网文档安装一下。

Q:和gitlab ci相比有什么优势

A: 和 gitlab ci 相比的优势可以参考下 jenkins 与 jenkins x的对比。在用户角度来说,以应用为视角使用起来会更加方便,也方便利用社区资源。从架构和可维护性来说,Jenkins X 的架构会相对更加先进(与诞生年代有直接关系)。

Q:prow现在支持gitlab了吗?现在大多数企业的代码仓库其实更多使用gitlab。

A:prow 目前还没有支持gitlab,这也是jenkins x目前最大的一个问题,据我所知目前 jenkins x项目组在主要解决这部分问题,现在在 jenkins x当中开发最活跃的模块 lighthouse 是做这部分工作的,有兴趣的话可以了解一下。

Q:从Jenkins迁移到X似乎需要大量功夫?

A:现在 Jenkins X 是有两个版本的,其中一种是使用传统的 Jenkins 架构,这个迁移过去相对平滑一些,但具体也和组织情况相关。
不过社区主推的是基于 tekton 的方案,也被称为下一代 CI/CD 产品,如果是迁移到这种方案的话可以忘掉原来 Jenkins 所带来的经验,重新开始。

Q:KubeSphere 计划把 Jenkins X 用进去吗?

A:在目前版本当中还没有计划把 jenkins x 用进去,很大的原因是因为 Q4,现在 prow 支持的scm 类型太过于单一了,不太适合企业客户。

Q:Jenkins X可以直接用于生产环境的CD吗?可以结合公司的审批流吗?与kubnetes如何协作?

A:Jenkins X 是可以用于生产环境CD的,结合审批流应该有一定的开发量。可以看下分享有关 Jenkins X 的环境管理部分,Jenkins X 本身就是和 k8s 深度融合的。

Q:KubeSphere DevOps 对比原生的 Jenkins 有哪些优势呢?

A:KubeSphere DevOps 没有对原生 Jenkins 进行很大的改造。但是用户如果自己搭建 Jenkins 需要自己去了解 Jenkins 的原理以及各种和 k8s结合的方案、如何运行的更稳定。
如果使用 KubeSphere 的话用户可以直接使用流水线,避免掉了自己搭积木的过程。
并且对于一些普遍的问题,我们会向 Jenkins 提交 PR 来改进 Jenkins的功能。
例如下面链接所对应的 PR 让 kubernetes 的 agent 调度从10s 左右优化到了 10ms 左右
link

Q:谢谢

A:所有人都在这里提问。

Q:其实gitops完全落地在一般企业是有难度的,考虑到有一些上线审批等流程。gitops落地有什么好的建议和思考?

A:个人认为理想状况下最好的方案还是利用 PR/MR 的方式进行开发,在 PR/MR 里面进行审核,这可能和很多企业的现状不太符合,但其实这种方案在某种程度上也是可以落地上线审批流程的。
可以先推行开发过程利用 PR/MR,用数据证明这种方式是可行的,再去推动生产环境部署切换工作方式。

Q:jenkins如何做备份恢复

A: Jenkins 的备份有很多种方案。其中一种最常见也是比较暴力的方案就是备份下整个 Jenkins Home 目录,恢复的时候直接恢复整个目录就可以了。
另外一种常见方案是 jenkins kubernetes operator 所采用的方案,在这个方案里面把 jenkins 的配置和操作历史记录进行了分离,配置(包括流水线的创建)都存储在 git 仓库中,而构建记录、日志等信息单独进行备份,有兴趣的话可以在 github 上找到这个项目了解一下。

Q: jenkins X能支持jenkins现有的插件嘛?

k3s在边缘计算中的应用实践

提问链接

Q:一台阿里云杭州服务器,一台阿里云美国服务器,都有公网IP,如何方便,快捷的(并且不购买网络带宽费用)的搭建一个2台服务器的K3S集群?

A:你这个问题的话主要就是你的这个路由的问题,pod网络和service网络的一个拉平的问题,涉及到这个路由的跳转需要你自己去去配置的。

Q:边缘节点的K3S集群可以很方便的被中心节点的K8S集群来管理吗?如何 管理?数据如何同步?中心节点需要存放边缘节点的数据吗?边缘节点挂了之后中心节点能拉起或管理吗?现在我们也计划做这放面的工作。我们有多个分公司?想在分公司部署集群,但没有维护人员,还有一个问题就是,现在集群 联邦不成熟,也不能很好纳管多个集群做资源调度?

A:这个k3s集群和k8s集群,它是一个平级的关系。他属于多个集群如果要管理多个集群我们可以采用向rancher这样的集群管理平台去管理它,我们现在就是这么做的在阿里云上有一个rancher的平台,然后管着我们在阿里云平台的业务集群和我们的多个边缘集群。
然后你的第二个问题就是中心节点会存储我整个集群的所有的数据,因此我们应该周期性的对这个中心节点的这个数据进行一个备份,而且在未来的版本当中,k3s会支持HA,它是,它是通过实现后端存储,如postgresql、MySQL的一个高可用性保证我们的集群的可靠性的,这个现在已经是实验的特性了,估计在未来很快就会发布了。工作节点挂了的话分两种情况吧一种是你这个节点直接就不能工作了,还有一种情况点跟我的指甲想不通啊,那么前一种情况的话肯定是我的业务也不能正常工作了,后一种情况的话,其实我的业务还是在正常运行的,只不过是不能通过我的主节点去调度了,但是一旦它恢复这个通信的话,所有的都会自动恢复,因为这个边缘的这个设备的他有个特点就是网络不稳定,还有,还有就是经常会掉件这种情况,我们这个集群已经在跑了有两三个月了,表现一直是很好的。

Q:k3s 去哪获取 资料了?

A:k3s相关的文档我们可以在rancher的官方网站上获取的。也可以到它的github主页上面去获取相关的材料。
补充:这题我会!k3s的官网是:k3s.io,GitHub的主页是:k3s,最新开始运营的官方微信公众号ID是:Dockerlab

Q:K3s的list-watch请求没有走tunel-proxy吗?

A:k3s的主节点和agent节点之间通信都是走的tunnel通道的。

Q:边缘网络不稳定的场景,list-watch请求会有问题吗?K3s有针对边缘网络不稳定场景做优化不?

A:这个场景其实就是kubelet跟我的主节点失联,一旦这个通信恢复的话,主节点他会直接把状态重新传到这个工作节点上去。

Q:k3s在使用上和k8s相比有什么限制和优势?目前我理解来看主要就是占用较少资源。

A:对,因为边缘设备的话都是很小的工,一般都是公用的,工业用的工控机,工控机一般都是一个低压的CPU啊,然后还有一个就是内存比较小。实际上来讲的话我目前没有发现根k8s有太大的区别,基本上在我k8s上部署的应用全部可以部署在我的边缘端。

Q:k3s的主节点和agent节点之间通信都是走的tunnel通道的。 List-watch请求也走tunnel通道的吗,据我看源码,并没有走tunnel,只有logs和exec接口走了tunnel。

A:这里相关的源代码我没有深入去研究过,下来我详细去了解下k3s这里的机制。
补充:list-watch就是直接访问kube-apiserver的端口。

Q:k3s集群直接更改设备IP是否可用,如果不支持更改IP,对于更改IP的需求有什么应对方案?

A:这里分两种情况,在集群部署完成后,如果要更改server节点的IP,那么我们需要重新去将所有的agent节点重新加入到集群中,如果更改agent的节点IP,那么可能导致agent节点对应存储在server节点中的身份凭证失效,也就是需要移除失效的节点,将修改后的节点重新加入,当然这种情况是在同一个子网内的情况,如果跨网段的话,那就会更复杂一些了。

Q:Rancher管理k3s集群,k3s的master要暴露公网IP吗?主讲人的多个边缘

A:server节点不需要暴露公网IP,只需要能从server节点内部访问rancher即可。通过import的形式将k3s集群导入到Rancher中即可管理起来,也可以管理应用和配置。

Q:k3s server 也支持docker吧

A:是的,agent节点提供了–docker参数,可以指定它的容器运行时为docker

Q:rancher 可以自己部署,管理自己的 k3s?

A:是的,我们的rancher是部署在阿里云端,同时管理了我们的中枢业务k8s集群和多个客户的k3s边缘集群。

Q:有在Android上成功运行的经验或者案例么

A:我们暂时还没有涉及到arm的设备,也没有可供测试的arm设备,因此暂时没有这方面的实践。

Q:运行单个Docker容器来安装Ranche?可以满足管理吗?

A:可以,但是这样可靠性会不好,推荐还是多实例通过负载均衡的形式来部署。

Q: k3s 支持master高可用吗?

A:暂时还不支持,但是已经发布了实验特性的版本,通过对k3s集群数据存储的高可用来实现的,我们可以部署高可用的postgresql作为k3s集群的管理节点的数据存储。这个特性应该不久就会GA了。

Q:边缘资源充足,是否可以直接用k8s?

A:如果边缘设备资源充足的情况下,也可以使用k8s来维护,但是需要考虑的是边缘设备网络的复杂性和不稳定性。

Q: K3s针对边缘设备网络的复杂性和不稳定性做了哪些改进

A:譬如刚刚有同学提到的list-watch问题,k3s的我没有深入研究过,但是之前在调研kubeedge的时候,了解到其实就是在断网的情况下仍旧能够实现区域内自治,保证业务的稳定和持续性。

Q:针对kubeedge实现的区域内自治,K3s当前没有实现的话,商用是否有风险呢,在边缘网络不稳定

A:这个还是还是得从那个边缘端的得从那个边缘端的这个特点来说。边缘端设备比较分散,每个节点的责任其实很有限,当然肯定有一些非常重要的节点,那这一部分我们可以采取一些额外的措施来保证可靠性,譬如直接从硬件上冗余来保证这一个区域的业务不中断。不是说k3s不能实现区域自治,譬如worker节点在于主节点失联不受控了之后,我怎么管理这台节点的应用,这种情况一般发生有两种情形,一种是断网,一种是断电,当然,断电的情形就不说了,断网的情况下。

Q:请问k3s,k8s,kube,openflow,现在名词越来越多了,有没有办法在去区别这些名词是处在哪些的阶段,用于什么功能?

A:这个问题的话,首先还是根据项目需求来做对比调研工作,新技术层出不穷,不需要追求最新的,当下比较流行的一定是适应性最好的,一般经过了众多的验证。

Q:k3s 启动个helm的时候,由于众所周知的原因,经常下载不到镜像,怎么解决呢?

A:官方提供了离线镜像包,大约200MB不到,这个镜像包包含了我们启动server和agent节点所需的所有镜像,能够保证集群自身功能正常。helm 我们可以使用国内的charts源来代替,例如azure的源。

Q:containerd可以配置morror么?

A:可以配置,但是比较麻烦,docker提供了比较好的人际接口,所以推荐使用docker。

Q:k3s和k8s搭建的容器系统是否可以无缝的相互切换,如果不是,应该怎么做适配才能相互转化?

A:我不太清楚你这个无缝切换是什么意思,是业务迁移还是?首先这个需求可能并不常见,而且两者面向的场景不同。

Q:备份k3s的集群数据为什么是备份那几个目录而不是备份sqlite的db文件?k3s的server支持类似rke对etcd定期自动备份配置吗?

A:因为还涉及到一些认证文件,譬如agent节点在server端存储有一个身份标记,agent节点的恢复是会判断这些身份的。一旦丢失,重新注册相当于是一个新的节点了。

Q:请教老师,不管是基于containerd还是docker,它们都是共享内核的,那么如何做到安全隔离呢?

A:在底层的资源隔离上,还是依赖于系统的各种命名空间,这块建议可以详细研究一下pod的安全策略。

Q:离线镜像文件是否只要放在images目录即可,文件名并不重要,都可以被识别出来?

A:是的,使用containerd作为runtime时,不需要手动导入,启动时会自动从这里获取镜像,如果使用docker作为运行时,需要手动load镜像,因为国内直接访问不了gcr.io下面的镜像。

Q:请问一个问题,单机版K3S,容器内访问本机的一个服务端口,无法访问,这个问题官方测试过吗?

A:这个可能有很多种情形了,看是否是主机安全策略限制。例如selinux或者iptables规则限制了。

Q:centos在边缘设备小内存设备上能装吗?也是有内存限制的吧,最小支持多少?

A:k3s server官方给的需求是512MB就能满足,但是实际的观察中,一般情况下用到200多MB,剩下的就看你部署的应用的资源需求了。另外我们需要保证应用不能把系统资源全部抢占了。

Q:k8与k3在api上使用上有啥具体差别比如是否支持crd?另外k8的网络组网方案有flannel和calico,k3是怎么组网的?

A:K3s默认使用的是flannel网络。
补充:k3s也支持手动指定其他的CNI,都是比较灵活的配置。

Q:k3s可以用来部署安全网关么?

A:暂时没有进行过相关的实践。

Q:iot client设备没有固定公网ip下如何进行部署?需要自行组网吗?

A:这里是一个大家都会遇到的问题,一般来说,IOT设备都是客户内网的,不可能给你在防火墙上打洞,我们现在是自己开发了一套系统,只用来偶尔维护边缘设备的后台,类似ssh反向代理就可以实现。

Q:容器运行时的查看的资源怎么跟宿主技做区分,比如我在运行的容器里面,free -h看到的是宿主技的,怎么做饭只能看到容器本身的呢?

A:是否对容器做了资源限制。

Q:边缘设备是怎么被监控的,有的什么方案呢?是否也有监控的实时界面??

A:我们可以考虑采取prometheus pushgateway的形式来在边缘内网部署监控代理,然后再介入到统一的监控平台。

Q:内网环境(可通过代理上网),需要为containerd配制代理吗?还是containerd可以识别主机的代理配制?如果需要配制的话应该如何配制?

A:如果是全局代理的话,应该是支持的。

Q:k3s跟k8s的迭代关系是什么,每发布新版k8s,k3s都要修剪出相应的版本,还是增量开发?用k3s需不需要定期升级?

A:我们一直在持续关注相关release notes,当有重大新特性和安全问题、功能Bug修复时我们会考虑升级版本。

Q:Kubeedge提供的设备管理能力,K3s是否有相应的计划?

A:已经有了相应的计划,明年会在k3s的辅助产品中体现。不过,我们会更专注核心引擎k3s的迭代。

Q:Dind 中创建出来的容器 MTU 不正常,什么原因导致的?

A:Dind不是本次分享的讨论范畴。dind内部的docker也是可以指定mtu的,都是灵活的配置。

Q:请问一个问题,单机版K3S,容器内访问本机的一个服务端口,无法访问。这个端口是我服务器上一个加密狗端口,程序需要从容器中调用这个加密狗。补充一下,我加密狗调用包含tcp和UDP

A:没有在社区中收到过类似反馈,这里不适合讨论这种很细节技术的问题,建议您提一个issue到k3s,我们在comment中讨论。

Q:我尝试给containerd配了代理,单独安装的containerd可以拉镜像,但是k3s内嵌的containerd确一直没法拉镜像。这个需要怎么解决

A:不确定你在k3s的containerd中如何配置的,k3s的containerd中的配置文件会被重置,你需要以模版方式配置containerd-and-docker。详细问题可以提issue到k3s来讨论。

Q:centos在边缘设备小内存设备上能装吗?也是有内存限制的吧,最小支持多少?

A:官方给出的内存需求是512MB,据我观察,在没有部署很多应用的情况下,内存占用一般在200多MB,占用的内存会随着部署的应用增加而增加,但是一般边缘用的工控机内存最大一般8GB,而且边缘不宜过重。

Q: 边缘设备上做 k3s ,岂不是增加运维人员工作量吗?本来是个简单应用,变成系统了!

A:因为边缘设备分散、网络情况不好,要统一管理和运维的话,是有难度的,后期的应用维护更新、配置变更、升级等等都是需要考虑的。如果采用传统的部署形式,虽然可以采用类似Ansible这样的自动化工具来做,但是要考虑到网络不稳定,部分设备离线情形的运维工作。所以采用类似k3s这样的统一管理平台是比较好的方案,在实践过程中发现,工作量下降了很多。如果不使用,你需要自己去watch你的应用的运行情况。自己去做类似supervisord这样的守护等等。

Q: 边缘设备及应用,监控用的是什么方案

A:采用在节点上部署prometheus exporter, 然后再部署一个pushgateway来做。

Q: 最大支持多少个agent,一个server带多少agent

A:这个没有真正的去验证过,不过我们目前的集群状态已经达到100+(1 server,剩余的全是agent),

Q: k3s 和 k8s 具体有多大的差别,有实例吗 ?或者数据对比。

A:在实际的应用部署中,几乎没有任何差异,至少到目前为止,我所遇到的场景,k8s能满足的,k3s也能满足,相信,通过不断的迭代,k3s在未来会更完善边缘场景。

来自 18群 的无痕 2019-11-07 22:38:44,睡觉了拜拜!

扇贝 Service Mesh 发展历程

提问链接

Q:istio 相关的ymal配置文件,比如流量百分比,在哪里配置,直接操作文件吗?

A:你是指单纯使用 Envoy 的时候如何如何实现 Istio 里流量百分比的功能吗?这个可以通过给 endpoints 配置不同的权重来做到

Q:这个现在是在哪里操作的是运维手工修改ymal文件?

不是的,举个例子,你可以在 xds 服务端实现根据不同 deployment pod数量来下发新的配置

Q:service mesh 有对mq 相关研究吗

A:我们的 mq 没有部署在集群里,Envoy 对这块协议也没有相应的支持
A: istio应该暂时还不支持kafka和amqp,gRPC/websocket等可以实现异步调用。

Q:为啥自己实现xds服务器?有现成的为啥不用?例如istio-pilot/rotor? istio-pilot可以单独使用的。

A:其实是早期遗留问题,一开始我们用的 Istio 不稳定,后续的选择就趋于保守了。当时rotor应该还没有 release 版本

A:好吧,Rotor一年前也没有更新了,他们团队好像被twitter招安了

Q:你们只用envoy做front-proxy吗?如果是这样,这就不叫service mesh了

A:分享里说了哈,既有front-proxy,也有服务间的

Q:如何保证envoy对业务性能影响最小?

A:envoy 本身性能没什么问题,要注意的是配置的 filter这些跟外部服务交互的地方,比如 ratelimit 之类的,要配置好超时时间以及失败后的策略

Q:被sidecar inject过的prometheus如何去scrap每个pod的metrics?服务是基于springboot的。这个研究过吗?

A:抱歉,这个没有研究过。你是要抓取 sidecar 的数据?
A: 谢谢,没关系。我目前只能让prometheus直接去抓pod的metrics。sidecar的数据不用抓:)

Q:把istio mixer里的jaeger暴露出来,给k8s外部的服务使用,这个需要考虑些什么?

A:我们单纯的使用的 Envoy 哈

Q:istio的配套监控体系如何,是直接用开源搭建还是自建?

A:我们的监控是 Prometheus 那一套技术栈

Q:你们的服务是基于gRPC还是REST/http1.1的?gRPC要求至少http2,如果需要把gRPC服务暴露给外部,对于ingress controller你有什么推荐?你们服务部署的是阿里云吗?Edge Proxy用的阿里的服务?

A:我们对外的 rest,内部服务是 gRPC。Envoy 也是有做ingress controller 的产品的,比如Contour,不过我们没有实践过,谈不上推荐。是的,阿里云。最外面有一层阿里云的 slb
A: cool

Q: 你们目前网关怎么做健康检查的?lstio,第二个问题,sidecar如何实现链路监控,自己日志文件怎么处理的?麻烦分享一下你们的监控指标和维度针对service me sh

A:既可以让 Envoy 对 cluster 做主动健康检查,也可以在 xDS 服务端那边主动更新 envoy的 endpoints,比如依赖 pod 配置的探活指针。我们日志都是到 pod 的标准输出,然后 ELK 那一套做收集处理
A:日志是怎么收集的呢?链路监控目前怎么用的呢?那个技术栈

Q:nginx+consul+consul-template这个用nginx做edge proxy?nginx这一层如何做cluster?

A:nginx 我们是部署多台,前面还有一层阿里云的 slb对 nginx做主动健康检查

Q:daemonset模式下,如果一个服务挂掉了例如timeout,如果实现circuit-breaker? 服务挂了。

A:服务熔断我们最近刚开始调研,现在给不出实践经验
Q: 哦,那只好还是编码在代码里面

Q:网关怎么处理健康检查的,pod日志怎么处理,统一收集吗?链路监控又是如何接入的?

不好意思,问题重复了

Q: istio不好用,为什么不考虑sofa mesh来代替?

A:早期 0点几版本的时候不稳定哈。现在不是特别在意大集群性能问题的话,istio 是可用的
A: 实测过一下,istio sidecar injection大概平均一次增加1ms的latency,感觉不是很厉害。一般远程调用都是十毫秒以上的返回。

Q:请问如何实现的灰度发布和蓝绿部署

A:灰度发布也是基于配置不同 endpoints 权重这个思路来的,也可以部署不同的deployment,基于 pod 比例来做。蓝绿部署实践不多哈

Q: 你们服务tracing和流量监控是怎么做的呢?

A: traceing 目前还是原始的日志方式,在研究替代方案,后续有进展可以再分享一下。流量监控我们有做 pod 的进出流量统计,也有从 Envoy metrics 获取的请求统计

基于CDN的边缘计算平台设计和思考

提问链接

Q:阿里的edge 有用在阿里的cdn上吗

A:目前我们以及有对外的产品ENS,形态上就是在CDN节点售卖虚拟机。另外我们在做的另一见事情,就是把CDN业务迁移到容器里面,这样到目的就是最大化释放CDN的资源和能力。

Q:能否介绍一下,目前cdn节点改造成边缘计算节点,主要涉及哪些方面改造,阿里的实践情况,谢谢。

A:目前CDN改造有3个部分:基础设施到改造(交换机、机型),软件层面的改造(容器化),CDN节点架构的改造(比如把传统的7层负载均衡改成K8S的Ingress Controller)

Q:目前在边缘的ENS节点,有提供GPU,物理机等产品吗?

A:ENS能力上是对齐阿里云ECS的,目前提供CPU和GPU,神龙裸金属如果有需要也是可以支持的。

Q:CDN场景的落地场景来说,形态上就是在云中心部署Kuberentes Master,将云中心所在Region附近的CDN节点接入到Kubrentes中 ,指的是在各个Region 里面的节点当作k8的node 处理吗 ?

A:比如我们在阿里云中心的杭州Region创建一个K8S Master,然后会把杭州整个省的CDN节点,全部接入到这个K8S Master里面,CDN节点指的是一个机房,一个机房会有1~100台机器,整个CDN节点的机器都会接入。

Q:请问阿里边缘计算有和5g结合的计划吗?具体有哪些结合点?

A:在今年云栖大会上,我们以及发布了5G边缘计算战略,这个可以网上找下视频回放。具体的结合点目前来看是城市大脑和城市云。不过因为5G还未大规模商用,所以我们也在探索。
link

Q:请问未来docker会向安全容器转型嘛?安全容器是趋势,作为开发者要注意哪些点?

A:其实kata和普通runc容器,在行为上没有太大差别,如果非要说关注点的话,目前我觉得是内核部分,因为kata容器对于内核要求是比较高的,稳定性方面还需要打磨。

Q:目前阿里有没有什么比较成熟的或者已经在计划中的边缘计算相关项目?公司内部对于边缘计算的支持程度是怎么样的?(落点很多,结合5g等新形式,相对感觉视频分析等传统cv方面可能应用性更强一点

A:ENS就是我们成熟的对外产品,我们对于边缘计算的投入也是不惜代价的。具体场景我们现在也在跟我们的客户、运营商都有广泛合作。只要有需求或者合作意向都可以找我沟通。

Q:在云上部署k8s master节点,cdn节点作为边缘节点。对k8s来说,节点之前的网络通讯要求会比较高,那当网络不稳定时,边缘节点和master节点断开,这时如何实现边缘节点上的服务自治呢?

A:这个就是[email protected]解决的问题了,[email protected]在边缘测机器上部署了一个Edgehub的组件,kubelet并不是直接请求kube-apiserver,而是通过edgehub然后再请求到APIServer。edgehub做了缓存和代理的能力,即使在断网的情况下,也能保障边缘节点的kubelet正常工作。这个能力叫做边缘自治,是ACK加强的能力。

Q:请谈谈阿里看到的边缘计算cover的真实价值场景或者客户群,感觉很多现有场景中心计算也能满足,不一定要用边缘计算。特别是边缘计算节点也卖虚机,价值不大。谢谢。

A:以cdn为例,cdn就是通过边缘做加速来提高用户体验。虚拟只是一种形态,比如你购买虚拟机自建cdn。所以边缘的场景肯定是跟中心不一样,比如城市大脑,就是需要在就近有个节点可以做接入,如果全部回中心,对中心的压力也很大。

Q:阿里在边缘存储上有什么计划吗,能介绍一下是否有业务会需要把大量数据存储在边缘?

A:ENS节点的虚拟机提供云盘的,但是并不建议把大量存储放在 边缘。因为边缘的存储冗余并没有中心那么高,就像我说的,目前不建议在边缘部署对数据可靠性要求非常高的业务。

Q:请问安全容器的存储性能有考虑过么?接入点在边缘还是放云端?

A:安全容器最终是跑着边缘上的,安全容器的存储目前是一个大的问题,kata开源的存储方案性能并不好。阿里云的内核团队做了大量的优化,目前应该有了比较大的性能改进。

Q:请问[email protected]是开源的吗?

A:[email protected]是阿里云上的产品,目前已经在公测中,可以直接在阿里云官网开通使用。

Q: 容器安全方面有什么需要注意的?除了kata之外,使用dockerd 与k8s有什么安全建议psp之类的?

A:安全容器的使用,第一K8S需要做适配runtimeClass,第二内核也要求比较高(应该是要4.*内核比较文档)
安全建议:就是加证书、改端口,不然容易被外部注入容器。其他的安全建议:就是直接使用云上产品,云上产品具备了比较高的安全能力。

Q: 接Q8问题,如果云上master和边缘节点网络恢复了,但master节点上的pod的状态和边缘节点上的服务的状态不一致(断开时间长后,云上pod的状态通常是terminating状态,而边缘节点上的服务仍能正常工作),这时候如何解决呢?网络恢复后,会将边缘节点的服务重启吗?比如pod重建?

A:网络恢复后,就是继续往K8S设置的终态变化了,比如中心把Pod删了,那么网络恢复后自然相应的Pod就会被删除。因为有edghub的存在,pod是不会处于terminating状态的。不过具体细节可以仔细ACK的同学,场景和需求可能不大一样。

Q:CDN的流量分配是在哪里做的?是DNS还是GSLB那种?异地灾备也可以用同样的方式?

A:CDN的流量分配就有DNS、HTTPDNS、302调度,CDN 本身就是成熟的技术了,调度这块都是非常成熟的技术。

Q: 想问edge节点的升级问题?比如有了重大CVE 或者 0day?或者和master版本差太多?

A:升级的话,我们目标保持跟ACK中心同步的节奏。主要根据ACK提供的信息。
q18请问您那块容器主要跑在虚拟机还是物理机上?
都有

蔚来汽车的Kubernetes实践

提问链接

Q:请问Kubernetes数据备份与恢复,这个是包括kubectl-proxy,etcd,网络配置等吗?如果进行多集群下的数据备份?

A:备份的其实就是etcd中的数据,我们网络是用的flannel,一些关键网段信息也是存在etcd中的,对于多集群来看的话,还是要针对数据存放对应的etcd集群数据去进行备份

Q:请问一下业务日志太多,一天一个节点的业务日志有200G,怎么做日志收集及监控告警。

A:一天一个节点200G的话,这个要看你们集群节点多不多,我们上百个节点,一个节点的量大概在100G左右,线上日志量都是几十T的数据,用我分享的方案去落地应该是没问题的,ELK的整体性能还是非常不错的,filebeat现在最高的性能分配是占用500m cpu 1G内存,收集起来也是能应对的,这个根据你的量再调整,监控的话肯定就用prometheus就好,官方都是有自动发现的配置,很便利,当然如果你要对日志进行分析,这块就比较复杂了,可以通过es接口去聚合数据,当然日志的字段也要规范好。

Q:生产环境 k8s 采用二进制方式搭建还是 kubeadm ,还是其他方案?

A:线上采用的是二进制的方法,因为我们上k8s的时候 kubeadm还是测试版本,当然现在高版本的kubeadm应该已经是正式版本,但是觉得还是二进制更方便一些,你改配置,以及自定义一些参数会方便一些。

Q:生产环境k8s都用哪种网络模式

A:我们用的是flannel,不过后续会考虑打算换成calico,现在发现线上有一定网络限制的需求,calico的性能相对也会更好,但是维护的复杂度比较高,在集群节点多的情况下,要添加路由反射器,这个比较关键,而且网络选型前一定对未来的规模有个规划,规划好使用的网段。

Q:请问生产环境中etcd的数据需要备份吗?怎么备份?还有二进制安装etcd集群由3个节点增加到5个节点,需要重新生e成证书后再重启etcd服务吗?增加节点重启策略是一个一个节点依次重启吗

A:建议备份,其实主要用到的就是etcd的snapshot功能,不复杂,看下我分享的脚本即可,扩容的话需要修改server端证书对应的host,逐台重启没有问题的,官方的方法也是要一台一台执行的,线上etcd节点我做过测试,即使操作失误都down掉的话也不会影响你现有服务的运行,而且保证法定节点的存在就更好。

Q:你分享的prometheus是operator方式吗?你的监控数据是有经过二次开发后作为标准格式输出吗?对于nginx和java监控如何实现呀?

A:prometheus没有用operator的方式,是用的官方的yaml文件创建的,我们线上java服务居多,都是通过spring官方的prometheus插件就可以自定义监控数据,nginx的话我们还真的不多,这个估计你要用相应的exporter就好,监控数据是开发自定义上传的,我们没有做限制。

Q:pod挂掉之后如何保留现场,比如做内存dump有什么好的方案没?

A:我们这边是这样,对于健康检查没有添加liveness的检查,也是防止容器的重启,尤其是在第一次项目上线,难免无法正常启动,如果加了liveness就会一直,重启,不太方便查问题,所以只加了readiness,只是保证不影响线上访问,对于生产中,java项目遇到最多的就是OOM问题,这个我们也对POD重启的原因加了报警,至于dump我们还没这方面的操作,需要开发自行检查了。

Q:传统系统架构如何改造成k8s架构?

A:这个问题有点宽泛呢,还是得看您这边实际的场景,我觉得更多的也是得需要开发一起的配合,尽量保证服务模块都能够做到微服务话,不要耦合的太紧,您可以先搭建一个测试集群,然后从开发那边找一个模块进行docker化的转换,然后一点一点再去试吧。

Q:是否有ingress tcp/udp应用的生产级网络方案?

A:我们没有用ingress,我们的用法也算是一种比较简单的用法,我们是把网关直接加入到k8s集群中,这样网关就可以调用到k8s的service,因为我们以网关为中心,做了一些安全及认证功能,所以之前的网关必须要用到,而且加了ingress相当于多加了一层性能消耗,所以也没有用,最后我们把之前部署在虚拟机上的网关也变成docker化去部署到集群内部。

Q:传统数据库负载过高时查询缓慢,但是会有结果,k8s架构数据库负载过高直接pod重启,导致没有结果返回,请问应该如何处理的。

A:我们集群还没有跑数据库这种有状态的服务,但是听您描述,还是得看看pod重启的具体原因,如果pod都重启了,理论上跑在机器上一定也会有问题,还是在上云之前做好充分的性能压测,并且您可以考虑取消liveness的健康检查,只保留readness访问的检查。

Q:采集日志过程中,fluentd或fluent bit通过读取node节点docker log目录采集日志,该目录包含了所有服务的日志。请问如何在output阶段中根据namespace和container_name创建elasticsearch的index,并作为index的命名前缀?

A:首先不建议通过docker目录的方式采集,日志还是落盘到具体路径为好,因为我也碰到过您这个困惑,因为docker的目录都是软链接,而且当docker 重启后路径会改变,当然我们线上用的是filebeat采集,不知道fluentd能不能解决这个问题,由于是软链接,很难用相对路径,必须用绝对路径采集到真正存放的那个目录日志,我们对于es index名称的创建是通过日志提供的一个index名称字段去匹配的,索引名称会引用这个变量进行区分不同的index。

Q:fileneat node模式采集,多个相同pod在同一节点情况下,如何映射日志目录耳不互相干扰,另外如何配置filebeat做到pod变动时的采集

A:您这个情况我们也遇到过,多个pod跑在同一个节点确实存在这个问题,因为你的deploy yaml是定死的,很难处理这种情况,我们的解决方法是添加pod的亲和性,保证每个节点都尽量只跑一个pod,当然如果节点非常小的情况下,这种做法有一定问题,以生产使用上来看,我们最初多个pod跑在一个节点同时写一个文件的话也是还可接受。

Q:持续集成系统具体的细节可以透露下吗?基于gitlab ci,jekins?或者小公司可以直接用Spinnaker 这些吗?

A:ci cd的话因为我们有自己现有的发布平台,背后的原理实际上还是调用jenkins去处理

Q:日志收集的sidectar模式具体是咋部署的。filebeat和应用部署在一个pod里吗

A:对的,部署在一个pod里,相当于你的deploy yaml里会有两个image配置,一个是你的服务,另一个是filebeat,具体的配置看下我的截图,把这部分配置放到你的服务配置后面即可,但是就像我分享说的,这种方式可能会比较消耗资源,但是确实自定义比较方便,但也增加了yaml配置

Q:我司测试环境搭建的Harbor版本是1.5,使用docker-compose来按照Harbor各个组件的依赖顺序来启动的,但是当系统或者docker重启后,Harbor的容器就无法按照依赖顺序来启动,经常会有容器启动失败。请问下这个该如何优化呢?

A:其实你需要在docker中注意一个参数,live-restore : true,这个参数很有用,你可能没有添加,这个参数能保证在你维护重启docker的时候,还能保证不影响正在运行的docker 容器,另外你可以对harbor进行监控,如果down了的话大不了做个自动重启的操作也不妨大碍。

Q:(1)k8s平台上线前有什么测试?如何测试?可以上线的依据?(2)常见互联网架构的业务,需要改造才可以在k8s跑吗?需要如何改造?有什么坑?(3)你们多个业务线都共用同一套k8s?如何实现不会因为一个业务的高峰影响其他业务?(4)有什么方案可以实现最大限度的不丢日志?

A:1.因为我不是测试,对于测试这块可能干涉的不是很多,对于运维来讲可能更多的是比较关注上线之前的压力测试,这块会跟后续的稳定性有很大关系 2. 常见的架构业务理论上改造应该不需要很大,最主要的是解决docker镜像化,遇到的坑可能更多的是对于dockerfile打镜像理解的不好,导致一些启动问题以及配置的丢失等等,3. 我们是通过namespace区分业务线,需要提前规划好业务,指定的业务线只跑在对应的机器上比较关键。 4. 我使用的ELK过程中还真的很少遇到过丢日志,只要你架构足够健壮应该是没什么问题的,另外ELK中一定要用消息队列,降低你消息传递的压力,保证每个组件都不要出现性能瓶颈,如果实在怕丢日志,可以让logstash在消费的时候把消息落盘,es也要合理配置好刷新的频率以及内存多大落盘等参数,提前做好各个组件的压测是保障。

Q: 你好,我是蔚来es8车主,很高兴看到蔚来的分享。我想了解下你们存储的方案,之前听说是用的portworx,具体方案透露一下。你们这个team在北京还是上海? 用aws的话有没有考虑直接使用aws的k8s服务?es也运行在k8s里吗?

A: 您好,我们team在北京,因为我们的集群还未上有状态服务,所以暂时还未考虑分布式存储的问题,这块确实是很重要的一个环节,我们线上的服务基本也是通过S3去存储一些数据使用,portworx这个好像也出了很久了,当时在还没有k8s的时候调研过,不过想大面积使用貌似是要花钱用商业版,建议还是用现在比较流行的ceph可能会更好一些吧,我们还未用到aws自己的k8s服务,es有运行在k8s里的业务,但是不是通过operator部署,后端数据也没用到分布式存储,由于量不大,只是落在本地了,后期会进一步调研ceph以支持后期的有状态服务的迁移。

Q: 请问是否考虑过 fluent-bit ,目前 filebeat 有没有性能上的问题呢?

A: 因为在虚拟机的时候我们就用的filebeat,就沿用下去了,filebeat暂时还未发现性能问题,可以直接使用,总日志量我们应该有几十T的样子,在生产使用的过程中感觉filebeat还是比较靠谱的。

Q:k8s一年的证书问题,你们怎么解决的呢?

A: k8s的证书我们的时间都设置的是十年,kubelet可能是一年,这个我们最初疏忽了,碰到过一次,最终通过删除现有的配置,让kubelet重启自动生成,当然如果您是最初规划的话,可以加上证书自动到期认证的功能,据了解好像现在高版本的k8s已经不存在这个问题,我还没了解的那么多,您可以再查查

Q:k8s生产环境上的安全相关的配置有哪些呢?

A: 安全的话这个比较宽泛啊,这个还是要从各个方面完善,首先起码要保证流量流入方向的各个环节的安全限制,以及服务接口调用上的安全认证,以及开发人员使用时候的权限控制等等。

Q:prometheus自定义监控具体怎么搞得,比如想要监控容器的端口连接数?

A:容器端口的连接数监控确实还未添加,在原来宿主机的时候是有的,这块有些忽略了,加的话也不是很费劲,可以通过你们自己自定义的exporter去监控。

Q:落盘的日志怎么定期清理

A: 落盘的日志通过写好的清理任务进行清理,因为我们的日志都是规范的落到统一的目录,并且目录名称也是很规范的,所以清理起来很方便,写个简单的脚本就可以啦,定时清理就OK

Q:k8s里java服务,你们是怎么做资源限制的?

A: 我们是在yaml注入了能获取设置资源的env参数,然后在ci打镜像的时候统一规范了服务启动的start脚本,jvm里配置的是k8s配置的资源,所以java服务的使用也不会超过我们分配资源的使用。

Q:想了解下你们日志收集 你们的服务数也就是日志数大概多少?每个k8s节点分配到的pod大概多少 因为是daemonset部署想了解一下filebeat的配置文件是怎么管理的? 后端日志分析完全靠es么?日志有没有入hadoop的需求?有MR或spark

A: 我们一天的日志量最多能达到近10T的数据,当然这不全是k8s这边的日志,1个节点最多的话大概能跑到30多个pod,filebeat我们是走的统一的一份配置,因为日志都是json规范好字段传输,也无需做过多处理,因为日志分析主要不在这个场景做,我们这个场景只是提供开发看日志,当然其中一些网关数据我们会做报警和具体的图示,需要分析的大数据专门走我们的hadoop集群,我们这边有用到MR 和 spark,但是大数据相关的东西都没有在K8S上面。

基于 Ceph 的 Kubernetes 数据持久化

提问链接

Q:k8s 里面使用 ceph,假设 ceph 出问题。这样会导致节点 hang 住吗?导致集群不可用情况。如果会,那该如何避免。谢谢。

A: 并不会,因为Ceph 本身是分布式高可用的,而且即使Ceph节点全挂, 也仅仅会影响使用Ceph 的Pod,而不是节点。

Q:ceph是通过k8s部署还是原生部署。ceph和k8s节点超融合吗,还是分开。

A:一般生产环境中都是独立部署的,3 或 5 Monitor, 3 ~ 60+ OSD 等规模。

Q:K8S中如果使用RBD作为数据库的存储,如果库比较大的情况下,对于数据日常的备份和维护是怎么做的?

A:可以利用快照,快速备份和恢复。在去年的KubeCon 上,华为和谷歌的小姐姐们演示过。
ceph与glusterfs的优缺点

Q:在K8S中对于需要共享的存储,使用CephFS需要注意什么,会不会存在一些坑?

A:目前存在一种说法,就是CephFS不稳定,不推荐使用。具体如何不稳定、如何触发、怎么避免就很少有人知道了,另外还有,如果CephFS不稳定,那么我们还有其它哪些替代品呢?

Q:学习ceph有什么比较好的方式?以及如何比较有效率的实践?

A:快速阅读一下官方文档,然后自己安装一套,再结合文档深入研究。模仿需求场景测试使用。多实践。

Q:K8S对外暴露服务用的是那种方式呢? 如果在一个集群里面跑不同的业务,在对他们做对外的域名解析,访问控制是怎样实现的,会不会存在一些性能问题或端口的冲突?

A: 一般比较常见的就是单节点访问的NodePort, 配置高可用模式的Ingress等等。
由于每个Pod/Service端口都是独立的,所以并不用担心会跟其它冲突。除非使用了NodePort且指定了端口。

Q:rook 和 原生的Ceph 部署方式在性能和维护上是否有区别,这两种方式如何选择?

A:抱歉, rook还没有使用过,不过相对来说,Ceph 集群维护的重点一般都在OSD。
在生产环境,一般也会独立部署Ceph, 毕竟即使快速的重新调度Monitor,也可能会对集群产生轻微影响。

Q:对于小中型公司来说ceph是个好选择么?自行维护,可以从多个方面说说k8s下如何进行存储选型么?谢谢!

A:相对可以接受,运维并不复杂。目前k8s 上存储还是以rbd比较多一些。当然也有一些NFS,不过因为其性能与稳定性,所以不推荐使用。

Q:如果使用BlueStore的方式,osd磁盘文件的划分是怎样的,比如WAL, DB这种文件是单独存放在SSD盘中吗,还是都存储在SAS盘中?

A:有条件的话,且存储需求性能高的情况下,使用更高性能的SSD通常都会有更好的效果。

Q:Ceph 中pool 数量是如何设定的,如果对集群进行扩容,PG的数量是否需要调整,调整的时候需注意什么? 网络方面怎么去规划比较合理,谢谢

A:目前PG的限制多一些,因为Pool里面PG是存在一定数量的,而PG数量又跟硬盘数量挂钩,所以调整时需要计算Pool的数量与OSD数量。
网络方面的话,在生产环境,推荐使用至少10Gbps网络,双网卡以便分离业务和集群网络,提升性能。

Q:1.osd 是否需要做阵列?20台物理机,单台物理机1个OSD阵列还是单台物理机8个OSD裸盘?2.当大量osd出现slow ops如何处理?3.纠删码和三副本,应该如何选择

A:磁盘数量较少时,不推荐RAID,建议由Ceph直接管理磁盘,通过并行获取更好性能。另外PG的数量计算方式也跟OSD数量有关,所以需要综合考虑。
这个可能需要结合监控系统,及时发现异常情况,是设备还是服务或者节点呀网络原因等等判断处理。
可以结合业务场景需求与集群规模和硬件配置等情况来综合考虑决定采用哪种方式。

Q:rbd分配给具体应用比如挂载到mysql后,如果空间不足,该如何扩容?谢谢

A:目前支持在线动态扩容。

Q:分布式存储应用于hdfs是否可行,相对于本地存储,分布式存储的读写性能如何提高,另外ceph的bluestore效果怎么样呢?

这个不太合适,因为HDFS本身自己就是做分布式的文件系统,且业务场景也不相同。
Ceph 的性能提升无外乎两个方面:更快的磁盘/SSD 和 更大带宽的网络。
由于直接管理了硬盘,所以其性能还是很好的。

Q:块存储模式下,磁盘在宿主机上的数据是加密的,如果要在容器外部操作这部分持久化的数据,需要怎么操作呢?

可以挂载操作。

Q:ceph图形管理界面需安装什么软件?

A: 现在不需要额外安装软件了,已经内置。

Q:请问怎样在k8s中,实现多个容器共享一个ceph文件系统,共享文件存储建议用哪种方式?

A: 这种需求就需要用 cephfs了。
共享文件存储的话,看最终客户场景,如果是给Windows等客户端使用的共享,那么可以通过ISCSI来挂载RBD到Windows共享服务器。

Q: Cephfs 之前在海量小文件读写测试时性能非常差,性能问题目前有没有解决?

A:性能需要靠硬件去堆。

Q: Ceph最大支持多大的存储容量不影响性能,与分布式存储HDFS的区别有哪些?pgp和pg什么关系

官方号称是PB级的。HDFS适合大文件,上白G的那种单个文件。
PG 是指定存储池存储对象的目录有多少个,PGP 是存储池 PG 的 OSD 分布组合个数。

Q: kubernes 中现在的块存储是一个部署绑定一个块,能否做成一个pod绑定一个块,有过这方便的实践吗?可否分享一下。

使用 StatefulSet即可,会自动创建和绑定PVC。

Q: 目前业界ceph集群的最大规模能达到多少个节点(大致的数量级)?是怎样的一种应用场景?

目前最大的不太清楚,不少大公司可能不会公布。存储日志、备份数据等等。

小公司如何优雅地推进应用上Kubernetes容器云

提问链接

Q:有状态springcloud 微服务如何进行管理和版本控制的?

A:微服务尽量做到无状态好。

Q:如何开发微服务应用operator?

A:这个我看了三次,不太懂想问的问题是啥,我理解微服务应用与operatorr貌似没有什么必然的联系。

Q:Grafana相比Zabbix有哪些优势和不足呢?

A:这两者是互补的,应该是问普罗米修斯吧。

Q:helm如何落地?是否有方案开发替代的系统完成版本管理功能?

A:暂时没有使用helm,公司使用版本管理是通过调用官方API接口来实现更新、回滚、重启等操作。

Q5你们部署k8s应用 是有用到通用的yaml模板结合helm使用嘛 ?
A:是的,使用通用的yaml模板,但是并没有使用helm。首先再运维平台网页上配置相关参数,发布时候传入变量值,例如启动参数、镜像地址、等生成yaml配置,然后通过API方式调用来实现部署应用。

Q:promethues server 后端存储tsdb高可用有做么 promethues server起了多个么 ?有遇到过server会偶尔挂掉么

A:没有做高可用,server端主动挂情况并没有出现,检查下日志看看是否有报错。

Q:请问从虚拟机正式环境迁移到k8s正式环境,需要做些什么准备,迁移过程会不会中断业务,数据库如何切换

A:不需要中断任务,应用部署后验证没有问题才切换负载,数据库其实不需要做啥操作,除非你是问数据库上容器的话,数据库这块暂时还没有迁移上去。

Q:前端和后端是不是改造完全分离的,有没有耦合在一起的项目,这些项目能用ingress吗

A:大部分项目前后端分离,耦合一起的也能用,关键如何做好转发,现在逻辑上是SLB–>负载层–>ingress->-service–>pod

Q:开发环境中需要提供给开发使用的一些有状态的公共服务,在k8s,网络部分如何处理,如注册在zookeeper的服务等等?

A:容器外访问容器内采取路由跳转,暂时通过node节点网络转发,这块后继需要优化。容器内访问容器外的,可以基于内网DNS配置公共服务地址即可。

Q:生产部署二进制还是kubeadm?

A:开发、测试、预发布、生产环境都是使用二进制安装,主要基于ansible剧本安装,只需要修改部分地址变量(例如vip、etcd地址等)即可

Q:自建的k8s集群,当node节点资源不足时,你们公司是如何做自动扩展node节点的?

A:还没有实现自动扩容,暂时提供网页版扩容方案,这个也是下一步需要实现的功能之一。

Q:老师你们公司有做蓝绿发布或金丝雀部署吗?在容器云平台上是通过什么方式去实现的?

A:金丝雀部署功能已提供,容器这块暂时还没有开放出去,跑在原来服务器的已开发,不过公司有点特殊,金丝雀暂时只开放给测试人员测试使用。、方式以下两种:
a、不同的入口,测试人员可以通过切换hosts。
b、浏览器设置header参数即可,负载层会判断来源实现不同转发。

Q:平时这么多微服务的yml文件是如何管理的?通过什么方式编辑和修改

A:文件其实是不存在的,是直接脚本生成yaml数据,通过api调用,python脚本会写好基本变量,只需要传值即可,脚本截取部分你应该能看明白。

-

Q:听说你们汇桔网大裁员啊!还有几个运维??

A: 现在运维1个

Q:一个微服务yml文件是deployment和svc配置一起,还是分开的2个文件?

A:文件其实是不存在的,是直接脚本生成yaml数据,通过api调用。

Q:etcd看到v2的数据和v3的数据备份方式不一样。如何一起备份?是直接拷贝任意节点的数据文件备份就行了么?

A:备份需要了解网络和pod数据存放在v2还是v3,明白了就可以确定那些需要备份了,容器的IP对业务应该来说是不影响的,也就是说网络地址变更后,业务还是可以正常运行。

Q: 网络用的canal还是flannel?有测试过性能么。能否满足需求?

A:网络使用flannel,测试过暂时满足性能需要,后继这块有考虑替换其他,但短时间先不动为主。

Q: 有让开发人员看监控么?比如说资源使用情况?

A: 监控平台是会开放出去的,开发人员能看到对应的pod使用情况。

Q: 请问,我们是java项目,在业务代码打成war包后,war包很大的情况下,在发布流程中,如何完成pod中的容器的代码更新,是采用挂载代码后重启容器方式,还是采用每次重新构建代码镜像,直接更新容器,或者有什么更好的建议吗

A:配置分离(上配置中心),参数通过启动鉴权下载配置文件启动,这样子环境的更新只需要基于通过一个包即可。

Q:请问,那个管理告警并发送告警监控平台是怎么设计和实现的?

A:告警发送到监控平台不难,监控平台提供接口,数据过来做过滤存库处理,监控平台通过调用微信企业通讯录,绑定工号,发送也是调用api接口,并没有其他,只是简单做了合并收敛,5分钟内非级别为高的,统一合并发送。

Q:有没有使用volume,集成分布式存储场景?

A:volume这块后面会上分布式,暂时文件上传暂时上传到oss上。

Q:持续化存储推荐用的是什么,ceph可以吗,这个数据做过持久化后,怎么做高可用

Q:redis有跑在k8s上么?主从或者集群有在k8s有跑么?传统的主从跑到k8s上需要做redis主从么?

Q: K8S PYTHON client 的对象如何转json的?自己实现decoder?

Prometheus架构与实践分享

提问链接

Q:您好,我们prometheus监控系统需要持久化监控数据,目前约存储了1.8T数据,严重影响了查询速度,gafana基本无法刷新数据了,请问有优雅的解决办法吗?

A:1.8T都是保存在本地吗?SSD有一定的加速作用。如果数据量比较大建议使用m3db、clickhouse、opentsdb等。

Q:如何登录prometheus数据库?

A:prometheus本地tsdb没有登录入口,只有go的api。

Q:企业级的promtheus监控的数据存储是基于什么呢?ES吗,还是其他的存储?

A:我们使用m3db,集群版本的influxdb、opentsdb等都支持

Q:现在有高可用方案吗?

A:prometheus的联邦或者Improbable开源的Thanos都是高可用方案

Q:promethues占用内存很好,我们的环境下45w指标大概要占用8G左右的内存,经常出现prometheus容器OOM,请注意有什么办法可以优化内存占用吗?

A:数据指标如果确实比较大可以考虑prometheus的hash采集,分摊压力。在生产过程中很多指标都是可以省去的,譬如kubernetes中的sandbox容器的指标。

Q:面对海量微服务,好上千个k8s节点,日钧上千上万亿的时序点数据,如何解决prometheus高可用,如何选择和解决远程存储问题?宜信目前有多大规模?有多少指标,一天大概有多少量数据

A:目前宜信的容器大约4000左右,规模还并不大,很多服务都还部署在虚拟机里面。每天的监控数据量不到100G。历史数据通过M3db存储。

Q:选择普通远程存储,面对持久化数据相对prometheus本地数据几十倍放大的问题如何解决,如何处理日TB级海量存储,后期如何取出数据进行分析?

A:prometheus设计的初衷并非解决大容量存储。如果是TB数据建议保存到远端的opentsdb中。

Q:目前prometheus能否支持对网络设备的监控,如何支持采用snmp ssh 等协议方式的监控;能否实现与Zibbix的对接?

A:prometheus有snmp的exporter可以实现网络监控。目前还没听说可以对接zabbix。

Q:目前prometheus的报警rules规则是怎么管理的?报警阀值是否可动态调整?

A:rules也是通过yaml文件配置,可以动态调整,但需要reload配置。

Q:Prometheus的push方式(push推送给pushgateway)和pull正常的方式方式的性能比较,谁更好呢?

A:pushgateway本身作为数据转发的代理,本身性能损耗很少。建议直接提供prometheus的pull支持

Q: 联邦配置时,实测抓取多个job的metrics存在延迟现像极其严重,不知道有没有好的解决办法?目前我是通过grafana直接获取两个prometheus集群作为后端数据库

A:这个主要看延迟的原因,是下面的prometheus采集慢还是联邦节点二次汇聚的慢。具体情况后续可以一起加微信排查一下。
2次汇聚,本地prometheus与线上prometheus,本地配置联邦,本地汇聚线上job的metrics,当job数量多了就会出现”federation failed” err=”write tcp 192.168.243.145:9090->10.0.0.12:33508: write: broken pipe”

Q:针对于一些公司自有业务的进程数据监控是依赖于自研 的go-clent上报吗?还是说一些三方的client?

A:如果可以二次开发建议直接在代码里面加入prometheus采集的支持,处理go 以外还有java
Python的sdk支持。如果不能二次开发也可以在外部通过exporter方式。

Q:如果有多个副本 CPU利用率 还是用container_name来算就有问题了吧?另外问一下 不同版本的pod(比如发版之后)怎么比较其CPU利用率?另外histogram的metrics有分析过吗?另外 查询一个月的数据应该蛮有压力的吧还是做了优化是否有必要?

A:嗯,多副本需要group。不同版本数据都在prometheus存储,可以通过容器名称汇聚查询出来,一个月数据step可以调整的大一些。目前看一个月内的查询基本控制在2s以内。
发版之后 pod name名字是不一样的
一种方式是通过保持container name,另外一种方式是通过前缀,正则匹配
我用得后者 不过会出现很多空线条 因为前面版本不存在这个pod name标签的metrics,这个和多副本的container_name 也算是有点冲突,暂时用正则的方式 多谢
metric名称应该是固定的啊,你用正则匹配,不会有问题的,历史都会查出来
另外我发现histogram的metrics超过7天之后就没有什么参考价值了 所以对于查询一个月感觉意义不大,比如 prometheus_http_request_duration_seconds, metrics还是重在实时性

Q:Prometheus的数据不知道宜信是否有存储,是存到opentsdb还是influxdb呢?

A:本地+m3db

Q:prometheus告警延时比较高,如果要做到秒级告警有什么方案!调整抓取频率不太靠谱

A:目前告警都是在几秒,你说的延迟是多长时间?

Q: 请问针对Prometheus 不能监控日志的瑕疵,有什么好的方案可以和Prometheus 形成互补呢?

A:公司自研了watchdog日志采集。社区常用filebeat + es+kibana方案

Q:宜信目前用Prometheus监控了多少个服务target了?Prometheus使用的资源大概是多少?

A:宜信正在从zabbix迁移到prometheus,目前是三台物理机。

Q:m3db数据存储有没有放大?相对prometheus 的tsdb,有 大概有多少倍?

A:放大是啥意思?
比如一天的数据pro 的tsdb存储是多少g,通过远程存储,就会放大几十倍,比如100个变成1t

Q:请问应用进程http接口的性能监控是怎么实现的?

A:有java和go、Python的sdk

Q:怎么过滤掉不需要的metrics?通过prom

A:这个可以在pro配置里面drop

Q:本地存储用来做查询吗?多个prometheus是如何统一查询的?数据都存在汇聚的prometheus上吗

A:

Q:怎么实现tsdb历史数据保存到别的地方的?通过什么技术方式分开的?

A:remote write read

Q:时序数据库跟传统数据库的优势在哪?应该如何进行选型?

A:时序数据是保存随时间变化的量,查询也是时间维度,从而实现高压缩比。关系型数据有事在于数据管理。

Q:请问m3db能不能满足ha prometheus 的数据去重?还是存两份?

A:m3db不需要存两份

Q:比如要做每日用户登录数统计,具体应该怎么做?需要哪些流程和步骤?

A:需要程序里面集成sdk,并提供查询累计登录用户的http接口,并在prometheus配置这个target。

Q: 选型的时候为什么选择m3?没考虑其他远程存储吗,是有什么考虑。远程存储你们只是用来备份一份吗还是也会一起从远程读数据?之前远程读的性能比较烂,目前prom新版本的stream远程读你们有试验吗

eBay Kubernetes集群的存储实践

提问链接

Q:分布式数据库例如MongoDB在k8s上有实现方案吗?

A:有的,我们内部NoSQL就是完全运行在容器云上的,pod部署由应用自己管理,通过svc暴露服务,存储上使用local PV,并实现了backup restore。社区应该也有比较多的实现参考。

Q:由于环境,如网络因素,出现短时间暂时大规模掉node的情况怎么处理?

A:如网络问题导致node连不通,对于网络存储来说,需要在网络恢复之后重连,比如cephfs kernel client和fuse都实现了reconnect

Q:etcd集群中,v2和数据和v3的数据备份方式不一样,如何备份整个etcd数据呢?

A:etcd server只能有一种版本,不会并存,所以按照各自版本的方式备份即可

Q:PVC的anti affinity调度特性是k8s原生支持的吗?自研方案有计划贡献到k8s仓库吗?

A:不是,我们是在使用MongoDB的过程中,发现master pod的io load很高,所以基于此自己开发了这个功能。

Q:数据如何做容灾

A:网络存储自己有多replica和rack awareness的分布,本地存储需要应用自己实现多拷贝,对于可靠性要求比较高的数据,需要做备份还原。

Q:本地存储能说的更清楚点么?比如registar是怎么把信息同步到kubernetesnode中的。pv的删除是csi那个组件来做的?信息有哪些信息。谢谢。

A:registar在注册节点的时候会将vg的相关信息以annotation的方式写到node对象中,pv的删除由csi-provisioner sidecar完成,大体思路可参考社区的design doc。

Q:容器镜像如何存储和管理?

A:我们目前用的是quay,用swift存储镜像层

Q:redis集群,3主3从这种,如何跑在k8s上

A:可以用statefulset的方式,具体可以参考社区的做法

Q:使用ceph rbd会出现multiattach error,导致新pod一直处于creating状态,需要人工介入,有无自动处理方案?比如,kubelet挂掉

A:如出现kubelet挂掉或者node hung导致kubelet不工作,有可能出现这种情况,需要实现节点的remediation,监控这些情况,重启或者下架节点,保证原来的连接断掉。

Q:请问日志存储是在专有的节点吗?如果不是会和业务数据存储产生影响吗?空间占用,cpu,内存方面的影响。

A:每个节点组件本身的日志和容器的日志都是通过beats来收集并上报到监控系统,不会和业务数据冲突或干扰。

Q:存储限制是怎么做的?

A:对于emptydir,我们使用xfs quota限制。对于PV/PVC,我们在controller层面做了每个namespace的quota limit。

Q:ceph rbd和本地磁盘有做过benchmark么?cg v2应该只能限制本地盘吧?

A:-

Q:kernel network storage有没有什么好的学习材料?

A:具体是哪类存储类型,可以参见 linux-device-drivers

Q:有没有可能通过StatfulSet 实现分布式存储?来做异地容灾

A:异地容灾是federation层面的部署,感觉和用哪类workload api没太大关系

Q:本地存储不需要另外的scheduler-extender么?用原有的scheduler就可以了?

A:我们是直接在原有的scheduler基础上做了修改,当时还没有extender机制,后续会考虑以extend方式放到外部

基于Kubernetes的DevOps平台实战

提问链接

Q:请问老师是通过 Jenkinsfile 来控制版本管理吗,是否使用了 jenkins library,多个环境的情况下,是部署一个Jenkins master,还是每个K8s集群都带有一个 jenkins master?

A:jenkinsfile实现整个CICD流程,使用git对jenkinsfile代码进行版本管理;目前没有使用jenkins library,但是jenkins library的方式正在重写过程中,还没有完成;多环境的实现是只在一个集群部署一套jenkins master+jenkins agent,不同的环境通过不同agent实现

Q:我想知道这个分享有什么用?文字直播?

A:这个我来答一下,感觉没用可以不看,没有强制要求。

Q:每个jenkins的job里写一个jenkinsfile的repo?这样是不是太浪费了。每个repo就一个jenkinsfile文件(多环境可能有多个分支)。我们是直接写成了jenkinsfile模板,然后jenkins 构建参数传入的。不知道老师是如何权衡的

A:不是的,所有job使用一个jenkiJenkinsnsfile。每个job就是传递一些基础参数,大多数配如编译命令,部署配置等,都是在devops平台先行配置好之后,触发job构建之后从devops拉取参数配置)

Q:为什么拉取代码后就要进行Sonar代码扫描呢?研发的代码都没有集成编译验证,扫描代码有什么意义?

A:不是拉取代码前进行的扫描,是拉取代码完成后进行的扫描。方便对接多语言。这个看取舍的,我们因为涉及语言种类比较多,不太容易顾全所有的语言,而且前期我们php语言的业务较多。

Q:你们生产环境也关闭防火墙了吗?不用防火墙吗?还是你们用的其他的安全措施

A:我们生产环境防火墙是关闭的,因为我们使用的是公有云环境,策略都是通过公有云安全组实现的。

Q:同ansible集成那部分怎么实现的?中间涉及到传参数,例如IP地址,端口号,服务名称,是通过什么控制的?

A:基础环境信息,都在inventory里维护。其他的一些参数放在一个group_vars中

Q:node节点使用的是动态token还是apiserver内置的静态的token进行bootstrap的?

A:动态token,不在apiserver的配置里指定token.csv

Q:你们master节点和node节点都部署了多少台

A:master节点3台,16c64G的。node有600台,配置种类比较多

Q:能否提供一下你们基于pipeline的jenkinsfile示例?

A:这个因为涉及公司隐私,不方便提供。但是后期基于jenkins library的代码完成后,会进行开源,请后续关注。

Q:knative和istio现在未来前景咋样,国内有用到生产上去的吗?

A:我们暂时还没有使用到生产上去,只是调研阶段

Q:600个node calico用的反射模式还是node mesh?有做pod带宽限制么,谢谢!

A:node-mesh,目前没有对带宽做任何限制,calico也遇到了不少坑,暂时也没精力进一步的使用功能

Q:感谢老师分享。想请问下您们的运维团队是怎么配置的,谢谢?!

A:我们分业务运维、系统运维、dba

Q:Jenkinsfile 使用文档较少,可以提供在此遇到的坑列举几个典型吗?谢谢!

A:使用的话,可以去参考有一本groovy的书。遇到的坑的话,大多数是CICD逻辑的问题,比如说,我们会有一个容器运行用户的配置,实际业务场景中有使用root的,有使用普通用户的,还会针对不同的环境适配不同的用户配置,逻辑处理出错就会导致实际部署后,pod运行异常。

Q:请问 主机系统初始化 这一块对系统的发行版和内核版本有什么要求和建议?看到一些docker的问题是因为系统内核版本太低 (3.10 内核 kmem account 泄漏 bugs 导致节点 NotReady),请问你们是如何选择的?

A:目前仅支持Redhat、CentOS,内核版本是3.10,没有进行升级。以我们集群运行这么长时间看,虽然有NotReady现象,但是概率比较小,固没对考虑对内核升级

Q: 请问下集群规模是怎么样的,node节点是怎么做资源保护的?

A:目前600个node节点,我们目前是监控整体集群水位,在达到60%左右就会对集群进行扩容

Q:如何实现灰度发布以及蓝绿部署

A:基于ingress实现的,部分是使用公有云的负载均衡,通过api实现切换

Q: 目前我们使用的gitlab-ci-runner 部署于k8s之外实现ci/cd。发现gitlab-ci在实际使用中,经常会遇到卡死报错。请问下,相比jenkins 做ci/cd 是会有什么优势,之前并没有使用过jenkins.

A:gitlab-ci生产环境中,我们也没有使用,我们调研的结果是1、有侵入性 2、pipeline功能较弱,但是有一个好处是遇到错误好像还可以继续执行。jenkins遇到错误会中断流程。
基于kubeadm+calico,空闲时CPU占用达到30-40%是否正常?
实际使用中没有使用过kubeadm部署,因为封装东西太多,不易于排查问题。空闲时cpu到30-40,需要具体情况分析。

Q:600个node节点都遇到过什么问题, 有什么需要注意的?

A:前期网络上遇到的问题比较多,还包含calico bug。后面多数是一些业务使用上导致的问题,还有业务增量之后引发的各种问题。

Q:请问是怎么配置的多个不同功能的jenkins-slave pod的还有jenkins-slave镜像怎么做的,还有一个任务中有发布和回滚怎么做呢,老师的cicd人工干预的地方在哪里?

A:jenkins-slave镜像实际就是把jenkins的agent.jar运行在容器中。发布就如同前面所讲。回滚最终是调用helm rollback。cicd人工干预的话都是通过配置项来控制的。

Q: 容器web应用,有没有做安全防护呢 有遇到用户恶意模拟XFF,频繁访问接口么?

A:这个我们是在入口去做的,因为使用的公有云,直接就上了waf、各种安全产品。

Q: k8s的编排资源是怎么弄到cmdb上的

–anonymous-auth=false 设置后,liveness 访问报401错误,我Kube-apiserver在不停重启,这个需要怎么配置?用insecure ip和port,有不符合安全要求

这个是没有通过验证,要确认证书或者相关配置,具体的配置可以参考我的文档

云原生可观察性之日志管理

提问链接

Q:fluentd bit 在收集的容器pod中 启用fluentd.io/parser选项 采用正则表达式匹配,发现一个正则很难试用全部场景,而且发现匹配不到日志内容的时候 节点会hung住 再重启会无法启动 一直报404启动不了 请问这个如何解决的

A: 这个问题可以给 fluentbit 提 issue。KubeSphere 目前只用到 Parser 插件的 Decorders,主要是用 fluentbit 添加/删除/修改日志接收者,也会进行一些日志的过滤

Q:如何debug Prometheus

A:如果您是要参与 Prometheus 的开发,可以参考 Prometheus Github 的开发指南。如果是使用中遇到问题可以结合日志,或者查看 Prometheus Console UI 有一些直观的异常提示,到 Prometheus 社区 slack 或 Google group 请教。

Q:Loki你们在生产上有用到吗?有没有什么最佳实践?

A: 我们正在调研 Loki,Grafana Labs 已经用 loki 提供日志服务了。他们的部署方式参考 ksonnet 。建议就是几个组件要分开部署,每个组件可以有多个副本以实现高可用;另外就是根据情况选择 index 和 chunk 分别使用适合的存储。

Q:请问一下,用户想自定义日志解析,如何实现?目前我们实现方式是 fluentd parser作为agent以deamonset的方式部署到k8s的每个节点上,一边收集一边解析,缺点是占用节点资源太多,请问咋们这边如何实现的呢?

A:收集日志的 agent 最好用比较轻量一点的比如 fluentbit,可以把 fluentd 作为 fluentbit 的接收者,用 fluentd 实现集中的解析后再发到最终的存储,这样就不用每个节点去部署 fluentd 了。类似这样的架构

-

Q:请问一下,单台日志量多少?

A:这个不太好说,看工作负载输出日志的情况。

Q:日志展示? 是kibana 还是自己单独

A:日志展示KubeSphere 没用 kibana,是我们自己开发的日志 console

Q:接Q4,谢谢您的答疑,目前我们想的是用户自定义解析策略不用通知任何人,日志就可以以流的方式输出到es或者其它终端,目前的问题就是如果用fluentd解析 如果添加一个解析规则就要修改fluentd的配置 就要重启下 这些感觉很不好,请问这边有什么建议吗?之所以用fluentd bit解析就是因为可以在 pod上用annotation 自定义fluentd.io parser 解析策略

A:如果想每个节点都有自己的解析方式,而且不想频繁重启的话, 并且想用一个比较轻量的 agent 的话 可以试试 filebeat,filebeat 有自动加载配置的功能,解析日志也比较强大。

Q:KubeSphere 的日志系统看起来很漂亮啊,也是开源的吧

A: 目前后端是开源的,前端也即将开源。目前的所有版本都是免费安装可用的。安装下载链接:link

Q:KubeSphere的日志在多集群设计上是会用 Thanos 去实现吗?优点是什么

A:Thanos 适用于监控的多集群实现,可用实现多个 Prometheus 的全局查询。日志多集群的话用 es 实现的话 Elasticsearch 较新版本支持的。link

Q:fluent和filebeat有做过压测吗?还是因为fluentd是cncf的项目才选择这个的?

ruby也有GIL锁,只能压榨单核性能
A:选择 fluentbit 主要是因为内存占用少。filebeat 也很流行,go 写的,内存占用据我说知会比 fluentbit 多一些。fluentbit 是完全用 C 写的,不是用 ruby。Fluentd 核心用的 c,插件用的 ruby

Q:不同服务的日志都是混在一起的?而不是不同的index?容器内的日志怎么采集呢?

A:目前是不同服务的日志每天一个index,如果想不同index的话应该要用filter加tag实现。容器内没有输出到stdout 落盘的日志可以用在容器内添加sidecar的方式将落盘日志转发到stdout。kubesphere 2.1 即将发布,自带了收集落盘日志sidecar自动注入的功能

Q:标准输出,数据回落盘吗?怎么清理?

标准输出,日志不会落到容器内挂载的盘,但是会落到容器所在的节点的盘上,通常这个节点的容器日志会有 rotation 设置,定期清理

9.19 社群文字直播:当 K8s 集群达到万级规模,阿里巴巴如何解决系统各组件性能问题?

提问链接

Q:calico网络中,如果节点跨三层,路由器不支持BGP,RR同步如何实现?

A:这个不清楚。

Q:由于节点IO,网络,负载过高等问题,etcd频繁选主,导致kube-apiserver方向超时。如何应对这种问题?

A:最重要的,我们需要为 etcd 配置相对稳定的资源,CPU/Mem 视集群规模而定,Disk 最好是 SSD,因为 disk io 性能对 etcd 写性能影响巨大。我们需要检查 etcd heartbeat timeout 和 election timeout,是否适合当前集群的环境。如果有条件,建议大家能去实践 etcd 3.4,pre-vote 的引入能有效减小异常情形下的抖动。此外,今天也给大家提到了 kube-apiserver 层面的优化,通过在 kube-apiserver cache 上实现 linearizable read,避免大量的读请求打到 etcd,从而可以大幅降低 kubernetes 集群中 etcd 的压力。

Q:当集群需要进行版本升级时,k8s各组件应该怎么操作。需要遵循顺序吗?为什么?

A:一般遵循先升级 Server,再升级 Client 的做法。对 kubernetes 来说,先升级 kube-apiserver,再升级 controllers,最后灰度升级 kubelet。先升级 kube-apiserver 的原因是 server 是对外提供服务(接口)的,kubernetes 遵循向前兼容两个版本的机制,确保集群的兼容性,最后升级 kubelet 是因为在节点数非常多的情况下,kubelet 的升级需要一个较长的观察周期去灰度。同时提醒大家,一定要注意 kubelet 升级对节点上运行容器的影响。

Q:在etcd里面有三个Instance,比如发生了以下场景:

A作为leader,B和C作为follower,这时候用户通过curl指令发送了一个Put操作,A收到后通知了B和C,然后B,C回了response,这个时候A提交日志到状态机,然后回复给用户,但在回复用户的过程中挂掉了。这时候假设用户不再发起请求,但B和C选出主机后会提交该日志,也就说用户认为失败了,但etcd内部已经提交了该操作。这种情况下etcd是怎么处理的?

A:这种情况只是告诉用户超时了(结果未知),并未告诉用户你的请求成功或者失败了(结果已知)。理解了分布式系统调用的三态,用户系统为了确保正确性,可以选择重试或者其他的方式确认自身状态的推进。

Q:能否讲解以下etcd的幂等性的实现?

A:幂等简单理解多次调用同一个操作不会破坏系统的正确性,典型的 put key value 操作是幂等的,delete key 也是幂等的,因为这不会破坏系统的数据状态。试想一下如果提供一个操作叫做 inc key 对 key 做 +1 操作(比如 redis 提供了类似的操作),用户很难“正确”的使用该 API 构建正确、一致的分布式系统。当然并不是说 redis inc 不好,它可以很好的应用于某一些对一致性要求不高的场景,一个典型的例子是统计微博的点赞次数。

Q:etcdctl在最新版本中get一个不存在的key的时候为什么不返回key not found了(标准输出中),没有任何的提示和返回,版本3.5。

A:因为真实语意实际上是一个 range 操作,既然是 range,当然不存在 key not found 的错误了,如果需要可以根据返回的条目确定结果。

Q:在3.3etcd中有一个etcd处于故障状态,集群api暂时不可用这个问题除了升级etcd还有其余解决方案嘛

A:生产环境一定要配置定期的数据备份策略,用于极端情况下的集群恢复。当然对于超过 quorum 节点,理论上我们可以扩展支持 “不安全” 的 member 调整方案,用于最大可能的恢复最近的数据,欢迎到社区发起类似 issue 的讨论,或许它就会成为我们的下一个增强。

Q:Objects是什么呢

A: 指 kubernetes 中的 pod/node/configmap 等资源对象

Q:能不能整理出三个东西:名词列表、问题场景、解决办法图解版😃👍

A: 敬请期待

Q:kubelet 升级对节点上运行容器的影响大致有哪些呢?

A: 比如因 spechash 的兼容性问题导致容器被意外重启

Q:为什么acs上node节点的最大pod数量是110,和性能有关系吗?阿里云容器服务不是acs吗?

A: acs?还是 ack,大规模的 ack 集群也是支持的,非常欢迎提工单骚扰

Q:etcd 集群的dbsize 的存储空间和pod等数量是正比增长吗?我们一个集群400个pod db竟然达到2G,感觉不正常,另外一个集群才几十M?

A: 也和单个 pod 的数据量大小,etcd compaction 策略有关系,etcd 会储存数据的多个版本。一般从经验上,400 pod 2G 是不太正常的,确认是否存在其他用户数据(比如超大的 configmap),确认 compaction 正常工作。

Q:k8s的调度时延都和什么有关系?

A: 和集群中的节点数量,节点的 label 数量和 affinity/anti-affinity 复杂性,以及集群的资源空闲层度有关系。前两者比较好理解,最后一个是因为对于一个资源分配较满的集群,从中找到可以容纳待调度的节点需要更多的尝试次数。

Q:目前您讲到的特性中有是否有贡献给社区的? 如果有的话,能简单说说吗?

A: etcd 增强已经回馈社区并且在 etcd 3.4 中发布,kubernetes bookmark 已经发布到 1.15,后续版本请保持关注。我们的策略是尽最大的努力回馈到社区中,请大家放心。

Q:请问在k8s中,遇到同一个接口对数据库查询时快时慢,然后整个系统中有很多应用都出现时快时慢的情况。这种情况下有什么好的方法去定位问题吗?感觉问题主要在statefulset的性能,和k8s内部网络上,但是却没有什么好的方法去定位.

A:不是特别明白你的问题。

Q:对于一个JAVA应用的pod的资源限制有什么好的经验?不知道到底应该限制多少合适?

A:这是一个比较复杂的话题(VPA),一般来说我们可以通过放宽 resource limit 来观察应用实际的运行情况,并通过实际经验来判断应该采用多少的 request 值。

Q:如果kube-apiserver/kube-controller-manager/kube-scheduler是static pod形式部署的,那对这些pod做资源预留的方式,除了request/limit还有其他方法吗?

A:一般建议隔离 control planes 节点与其他 worker 节点,避免运维上的风险。如果一定要这么做,目前没有好的方法来确保他们。

Q:针对etcd集群,如何进行有效的监控,阿里云采用什么的方案监控集群的cpu和网络流量等,如果单节点冲高,有什么预警和排查思路吗?

A:阿里云一般采用 kubernetes on kubernetes 的方案,用户的 kubernetes 集群部署在一个叫做管控的 kubernetes 集群之上,因此用户集群上应用的监控采用典型的 Prometheus 的方案即可。kubernetes 到 etcd 流量不均衡问题,导致单个 etcd 流量偏高,实际上我们已经做了修复方案,这一块大家也可以关注 etcd 3.4 中的 load balancer 机制。

Q: 能否再多介绍一些apiserver上实现

linearizable read以及通过cache实现的对客户端查询的优化那部分
2.etcd、API server、Controller及调度器优化实例

Porter:面向裸金属环境的 Kubernetes 的开源负载均衡器

提问链接

Q1:Porter 和calico有啥区别,简单了看了下都是用的BGP

A:Porter是一个负载均衡器,而calico是CNI插件,用途不一样。

Q2:porter有没有竞品?

A:有一个metallb,以及基于F5的负载均衡器插件

Q3:leaf节点是不是也需要部署服务?

A:不需要,只需要开启BGP就可以了

Q5:公司服务器就十台左右,部署的 Node 节点也比较少,网络方案使用静态路由是不是最好的选择?就是直接在上级路由器上添加 pod 的路由规则。性能方面是不是最好的选择?

A:pod会有漂移情况的发生,手动更新一是比较麻烦,二是延迟较大。静态配置路由相比于开启BGP的路由器性能上会有一点优势,但是在pod漂移到手动更新路由中间,可能会出现服务中断,如果能承受应该是没问题的

1205 社群直播:Knative Serverless 之道 - 如何 0 运维、低成本实现应用托管?

提问链接

Q1:开发怎么远程调试k8s中的应用

A1:Kubernetes 底层首先是一个容器,那咱们就从容器谈起。容器相对于宿主机来说其实只是把业务进程限制在一个更合理的权限范围内。在调试容器里面的业务进程时可以直接 docker exec 到容器内。到了容器内部就和一个 vm 没有什么差别了。而 Kubernetes 的 Deployment 可以认为是编排很多容器,每一个 容器都可以通过 宿主机 docker exec 进去。当然也可以通过 Kubernetes 的方式 kubectl exec 到容器内进行调试。如果实在初期调试阶段建议使用比较完整的 CentOS 或者 Ubuntu 镜像,基础镜像内要有一些基本的调试工具。摸索熟悉了之后可以使用精简的基础镜像,这样更经济。

Q2:knative的build和开发流程管理可以代替jenkins吗

A2:Knative 的 Build 现在长大了,单独开启了一个项目就是 Tekton。Tekton 的定位不是替换 Jenkins ,这两者在使用方式上差别还是很大的。对于比较习惯 Jenkins 的用户来说切换成 Tekton 是需要一个适应过程的。那么为什么要搞一个 Tekton 呢,Jenkins 不是已经很好了吗?具体 Tekton 的详细设计和实现咱们以后可以单独说明,这里选几个重要的介绍一下区别:
Tekton 的 Kubernetes 原生特性体现在如下几点:
Tekton 的所有 Task 都是以 Pod 的粒度执行的,每一个 Task 可以包含很多个 Step。一个 Task 的所有 Step 在同一个 Pod 内串行执行。不同的 Task 通过 Tekton Controller 编排,是跨 Node 节点执行的;
Tekton 的最基本的执行单元是 Pod,这和 Kubernetes 云原生操作系统是非常契合的。一个人如果掌握了 Kubernetes,再学习 Tekton 就是一件非常容易的事情。但是想一下如果掌握了 Kubernetes 会对学习 Jenkins 有所帮助吗?不太可能。随着 Kubernetes 的流行这种影响也会变的越来越明显;
再说一下被集成的特性,Tekton 如果现在和 Jenkins 拼生态现在资历还不够,但是他的设计和云原生生态位决定了他可以很容易的通过 Kubernetes api 被集成,而 Jenkins 的 API 需要单独学习,这些都是成本;
Kubernetes 生态的很多已有的工具,比如 Chart 等等都可以和 Tekton 非常容易的契合在一起,Jenkins 的生态自己比较孤单。长远看 Tekton 是有优势的,但 Tekton 自己的领域能力也需要不断完善;

Q3:knative编排和K8S应用编排的区别及应用场景?

A3:Kubernetes 的最大价值是把对 IaaS 资源的操作标准化了,比如无论是在 aws 还是在阿里云上面使用计算、存储、网络等资源都可以直接通过 Kubernetes 语义完成,不需要关心不同厂商底层差异化的实现。而 Knative 才是面向应用的编排。Knative 对应用的 Serverless 编排主要体现在对:流量的管理、灰度策略和弹性的管理。并且流量、灰度和弹性这三者是完美的契合在一起的。从另一个角度来说 Knative 是建立在 Kubernetes 之上的,Knative 需要使用 Kubernetes 提供的对 IaaS 的标准化服务。这二者是上下层的依赖和被依赖的关系,不是竞争关系。

Q4:knative有哪些成功的行业应用实践?

A4:在阿里云上面已经有很多用户在使用了。另外 Google 的 CloudRun 产品完全是建立在 Knative 之上的。

Q5:knative的现状和预期达到的目的?

A5:Knative 现在已经被众多厂商开始支持了,Knative 的目标是标准化应用 Serverless 编排模型。比如:
通过 Knative 对应用进行编排
通过 Knative 支撑上层 faas 系统实现
这里说的应用其实不限于在线服务,很多 AI 任务也是通过 Knative 驱动的,比如分享中提到的 KFServing

Q6:缩容时,怎么才能当pod内的流量消耗完?在销毁?

A6:Kubernetes 中 Pod 是可以设置 Prestop 的,Prestop 可以保证先卸载流量,然后再摘除服务

Q7:k8s 应用服务器内网无网络,入口只有一台nginx 在dmz区域可以出公网(nginx 与应用服务器网络只开放访问31380/31390),当pods 容器直接回调第三方域名时,该如何解决这个问题。

A7:这个涉及到了具体业务模型和系统架构,可以单独联系我下线沟通

Q8:感觉knative就是另一种形式的配置即服务,和jenkins X发展的异同?

A8:Knative 是一个应用 Serverless 编排引擎,可以快速给普通应用赋予 Serverless 能力。比如流量、灰度和弹性的完美结合。另外 Knative 的事件模型可以对接外部事件做基于事件驱动的 Serverless 模型。

Q9:在企业私有云环境部署knative会有哪些挑战?

A9:只要是标准的 Kubernetes 集群之上就能部署 Knative,不过很多镜像需要翻墙

Q10:阿里云上的容器镜像服务是如何处理鉴权的?

A10:可以参考阿里云镜像仓库的官方文档:

link

link

Q11: istio层面的管控和维护成本比较高,如envoy性能问题,网络问题等,这部分工作是由云平台负责的吗,knative这边有没有相应措施

A11: 目前阿里云容器服务 Kubernetes 集群控制台可以通过 UI 管理 Istio 和 Knative,可以快速上手。控制台也提供了很多便捷操作降低运维成本。Knative 主要依赖了 Istio 的 Gateway,Gateway 本身是可以横向扩展的,不会有太大影响。

Q12:容器的冷启动问题如何解决,第一个流量岂不是延时很高?

A12: 如果缩容到零以后,到一个请求的延时是会很高。第一个请求冷启动的问题是一个公认的业界难题,这也是各大云厂商在竞相解决的问题。相比使用云的客户而言,云厂商自己其实更迫切解决这个问题,敬请关注….

Q13: knative的组件本身怎么部署?如何保证HA?谢谢

A13: Knative 是建立在 Kubernetes 之上的,Knative 组件其实就是 CRD 的 Controller。在 Kubernetes 中 Controller 是可以部署多个实例,通过抢锁保证只有一个 Controller 可以执行写操作。HA 的问题容易解决。

————–以下内容请勿随意修改————

本周直播主题:《Knative Serverless 之道:如何 0 运维、低成本实现应用托管?》

下一场直播时间:12.19 (周四)敬请期待!