这段时间已经基本实现了产品应用层从原生的springboot微服务架构迁移到k8s上,过程可谓是瞎子过河一步一个坑,但是好在系统总体能跑起来了;今天研究了下产品计算层(spark集群)如何基于k8s部署操作,过程有些取巧了,但总的来说有些进展。 本次部署spark on k8s集群,基于kubeapps,简单便捷且一步到胃:
https://github.com/goharbor/harbor-helm https://www.hi-linux.com/posts/14136.html https://github.com/kubernetes-incubator/external-storage/tree/master/ceph/rbd https://github.com/kubernetes-incubator/external-storage/tree/master/ceph/rbd/deploy/rbac https://github.com/helm/helm/issues/3130 https://www.kancloud.cn/huyipow/kubernetes/531999 https://www.hi-linux.com/posts/14136.html https://li-sen.github.io/2018/10/08/k8s%E9%83%A8%E7%BD%B2%E9%AB%98%E5%8F%AF%E7%94%A8harbor/
debian 旧版本系统(2[hamm ]-7[wheezy])源都放在 debian-archive 中,
前面我们利用 Kubernetes 提供的弹性,在 Kubernetes 上动态创建 Jenkins Slave,本文主要是对 Jenkins 进行大规模构建的压力测试。
做自动化的同事今天居然问我 k8s 中为什么我部署的 pod 会跑到你们开发的节点上来?我可以去控制它吗?🧐🧐
在 Kubernetes 中,将 pod 调度到集群中特定节点的任务由 kube-scheduler 完成. 该组件的默认行为是根据创建的 pod 中每个容器的资源请求和限制来过滤节点。然后对可用节点进行评分,以找到最适合放置 pod 的节点。
Kubernetes是一个容器编排引擎,它被设计为在被称为集群的节点上运行容器化应用。通过系统建模的方法,本系列文章的目的是为了能够深入了解Kubernetes以及它的深层概念。
最近也一直在加班,处理项目中的事情,发现问题越多越是感觉自己的能力不足,希望自己能多学点。我觉得人生的意义就是在于能够不断的寻求突破吧。
上一篇文章中kubernetes系列教程(六)kubernetes资源管理和服务质量初步介绍了kubernetes中的resource资源调度和服务质量Qos,介绍了kubernetes中如何定义pod的资源和资源调度,以及设置resource之后的优先级别Qos,接下来介绍kubernetes系列教程pod的调度机制。
Kubernetes要求集群中的每个容器都具有唯一的可路由的IP。 Kubernetes本身不分配IP,将任务交给第三方解决方案。 在这项研究中,我们的目标是找到具有最低延迟,最高吞吐量和最低安装成本的解决方案。 由于我们的负载对延迟敏感,因此我们的目的是在相对高的网络利用率下测量高百分比的延迟。 我们特别关注性能低于最大负载的30-50%,因为我们认为这最好代表了非超载系统的最常见用例。 竞争对手 Docker与--net =主机 这是我们的参考设置。 所有其他的竞争对手都与这种设置进行比 -net =
如果你阅读过Kubernetes的任何文档、书籍或文章,那么毫无疑问,你会在“Pod被调度到下一个可用节点”之类的短语中看到调度“schedule”这个词。Kubernetes的调度不仅仅是在一个节点上放置一个pod。在本文中,我们将讨论Kubernetes在需要处理新pod时所遵循的不同机制,以及该过程中涉及的组件。
这次给大家介绍下k8s的亲和性调度:nodeSelector、nodeAffinity、podAffinity、Taints以及Tolerations用法。
priority 选项 描述: 优先级由一系列键值对组成,键是该优先级项的名称,值是它的权重(非常重要)一般得权重越高即优先级越高,通过算法对所有的优先级项目和权重进行计算得出最终的结果; 这些优先级选项包括:
这边肯定会有其他场景也会有对pod的调度有特殊要求,这边只是列举了其中几个情况,对于上述遇到的情况我们需要怎么处理,其实k8s给我们提供了丰富的调度策略来满足我们的需求。下面我们来一一说下这些调度策略。
通常情况下,Pod分配到哪些Node是不需要管理员操心的,这个过程会由scheduler自动实现。但有时,我们需要指定一些调度的限制,例如某些应用应该跑在具有SSD存储的节点上,有些应用应该跑在同一个节点上等等。
在Kubernetes中,Anti-Affinity是一种策略,用于控制Pod之间的调度,以便将它们分散在不同的节点上。这有助于提高应用程序的可靠性和可用性,因为当节点故障时,它们可以避免全部失效。
Kubernetes调度是确保集群中的Pod在适当节点上运行的关键组件。通过灵活配置调度策略,可以提高资源利用率、负载平衡和高可用性。
这里的背景是遇到了一个小问题:我目前有3台机器(1台ssd+40m 带宽高性能),有些服务对网络、机器都有较大的要求,而其他一些则没有,请问我如何才能让特定服务运行在特定 node 上。
version: kubernetes 1.6.2 ##kube-scheduler Configuration 下面是我梳理的kube-scheduler的完成配置: flag default valuecomments --address string0.0.0.0The IP address to serve on (set to 0.0.0.0 for all interfaces) (default "0.0.0.0") --algorithm-provide
公司企业面对不断变化的用户需求,对于应用的快速开发上线提出了新的挑战,一方面在功能性能方面要求越来越高,另一方面对安全性、稳定性、高可用性、可扩展性也越来越苛刻。当云计算重构整体IT产业的同时,也赋予了企业崭新的增长机遇,通过充分利用云计算的能力,释放更多精力专注于自己的业务。以容器为代表的云原生技术正在推动着整个商业世界飞速发展,企业数字化转型过程中,云原生成为企业持续发展和不断创新的必然选择,一款简单易用、灵活扩展、安全可靠的容器平台是众多企业的必由之选。
我们部署的 Pod 是通过集群的自动调度策略来选择节点的,默认情况下调度器考虑的是资源足够,并且负载尽量平均,但是有的时候我们需要能够更加细粒度的去控制 Pod 的调度,比如我们希望一些机器学习的应用只跑在有 GPU 的节点上;但是有的时候我们的服务之间交流比较频繁,又希望能够将这服务的 Pod 都调度到同一个的节点上。这就需要使用一些调度方式来控制 Pod 的调度了,主要有两个概念:亲和性和反亲和性,亲和性又分成节点亲和性(nodeAffinity)和 Pod 亲和性(podAffinity)。
通常情况下在Kubernetes 集群中部署一个Pod, 默认调度器将会自动进行合理的调度(例如, 将Pod分散到节点上, 根据节点上的资源情况进行分配), 但是有时候我们需要更加细粒度的控制pod的调度. 比如一组pod需要最终调度到拥有SSD/GPU的硬盘的机器上,或者将两个不同的服务(服务间直接通信比较频繁)的pod 调度到同样的节点上 (比如gitlab.这里就需要 Kubernetes里面的亲和性来解决,亲和性分为2类: nodeAffinity 和 podAffinity.
在上一篇文章中(使用腾讯云容器服务(TKE)实现应用跨可用区高可用部署之一),我们介绍了如何使用腾讯云容器服务的亲和性实现业务跨可用区高可用部署。通过控制台的简单操作,即可实现业务高可用部署。 控制台上实现的亲和性和反亲和性是通过节点亲和性(nodeAffinity)来实现的。
今天推荐一篇关于Kubernetes上服务滚动更新相关的配置选项的文章,文章列出了最常用的几个配置项,解释了他们是怎么影响调度器对服务进行滚动更新的,同时还带出了Kubernetes项目中Pod这个逻辑单元的Ready状态是怎么确定的,并不是容器运行起来后Pod就进入Ready状态的。总之个人觉得是篇非常好的普及Kubernetes基础的文章,文章由本人完全手工翻译,尽量做到通顺易懂,英文好的同学可以直接看原文。
我们现在有这样一个需求,就是集群中多台服务的配置是不一致的。这就导致资源分配并不是均匀的,比如我们需要有些服务节点用来运行计算密集型的服务,而有些服务节点来运行需要大量内存的服务。而在 k8s 中当然也配置了相关服务来处理上述的问题,那就是 Scheduler。
Kubernetes是一种流行的容器编排平台,它可以帮助用户简化和自动化部署、扩展和管理容器化应用程序。Kubernetes支持多节点集群,并提供了一组API和工具来管理这些集群中的容器和服务。
真的是,几乎没什么文章讲解helm安装jumpserver,jumpserver官方给的k8s安装方式就是helm
在Kubernetes中,Affinity是一种用于控制Pod如何被调度到Node的机制。通过设置Affinity规则,可以控制Pod是否被调度到特定的Node上,或者在同一个Node上运行相似的Pod。
Airflow是Apache用python编写的,用到了 flask框架及相关插件,rabbitmq,celery等(windows不兼容);、
Kubernetes针对不同服务质量的预期,通过QoS(Quality of Service)来对pod进行服务质量管理,提供了个采用requests和limits两种类型对资源进行分配和使用限制。对于一个pod来说,服务质量体现在两个为2个具体的指标:CPU与内存。实际过程中,当NODE节点上内存资源紧张时,kubernetes会根据预先设置的不同QoS类别进行相应处理。
在讲解本章之前,我先通过一个故事,来描绘一下 k8s 中 node 和 pod 的爱恨情仇。
故事的起因是朋友所在的部门最近基于auth2实现单点登录,他们在测试环境单点登录,运行得好好的,但他们把单点登录上到预发布环境,发现单点登录不好使了。他们有部分系统是以授权码式接入,发现第一次登录拿到授权码进行换取token时,会提示授权码失效。而他们测试环境和预发布环境的代码是一样的。
nodeSelector提供了一种非常简单的方法,将pods约束到具有特定标签的节点。而亲和性/反亲和性极大地扩展了可表达的约束类型。关键的增强是:
DaemonSet 确保全部(或者一些)Node 上运行一个 Pod 的副本。当有 Node 加入集群时,也会为他们新增一个 Pod 。当有 Node 从集群移除时,这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
在《研发工程师玩转Kubernetes——使用污点(taint)驱逐Pod》、《研发工程师玩转Kubernetes——使用Node特性定向调度Pod》和《研发工程师玩转Kubernetes——Node亲和性requiredDuringSchedulingIgnoredDuringExecution几种边界实验》中,我们介绍了Node的亲和性。后面几节我们将介绍Pod的亲和性和反亲和性。 Pod的亲和性和反亲和性通过Pod的标签来识别,而不是通过Node的标签。比如标题中“利用Pod反亲和性控制一个Node上只能有一个Pod”可以翻译成:只能将Pod调度到不存在该Pod标签的Node上。
在《研发工程师玩转Kubernetes——使用污点(taint)驱逐Pod》中我们提到亲和性(affinity)中的requiredDuringSchedulingIgnoredDuringExecution,它可以定向调度Pod。本节我们将使用相关特性完成定向调度的介绍。
前面的 nodeSelector 调度略显生硬,如果场景是:某个 Pod 最好调度到磁盘大的节点上,如果暂时没有,小点也行,比方说数据库; 如果场景是:某个 Pod,坚决不能调度到某类节点上,其余无所谓,比如说负载均衡不能调度到不对外开放端口的节点上; 诸如此类…
Jenkins是一个开源软件项目,是基于Java开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能
在《研发工程师玩转Kubernetes——Node失效后恢复的实验》中,有一次Pod被分配到Master Node——UbuntuA上。进一步的实验需要我们关闭其所在的Node,而Master Node又不能关闭,否则我们将无法对Kubernetes进行操作。这个时候我只能使用Pod调度技法来将其从Master Node上驱逐。
kubectl通过读取集群配置文件 ~/.kube/config 将请求发给apiserver,之后apiserver将创建pod的属性信息写入到etcd中,etcd会响应一个状态给apiserver,保存etcd成功会在控制台显示pod/<pod名称> created,之后调度组件scheduler上线,负责将新的pod分配到合适的节点上,调度之后,将结果响应给apiserver,apiserver再将结果保存到etcd中,kubelet当发现有个pod被绑定到自己的节点上时,就会调用docker的api去创建容器,容器创建之后,docekr会返回一个状态给kubelet,创建成功之后,kubelet再通知apiserver容器状态,之后apiserver再将状态写入到etcd中,之后就可以使用kubelet get pod去查看pod的状态了
描述: 我们在使用Jenkins的时候一般都会分为server节点与agent节点(也可以叫 slave 节点)。
项目描述: Jenkins流水线步骤,提供SSH工具,如命令执行或文件传输,以实现持续交付。 项目地址: https://github.com/jenkinsci/ssh-steps-plugin
DaemonSet保证在每个Node上都运行一个Pod,如果 新增一个Node,这个Pod也会运行在新增的Node上,如果删除这个DaemonSet,就会清除它所创建的Pod。常用来部署一些集群日志收集,监控等全局应用。
K8S 支持多副本部署,但不代表应用的高可用,因为多个副本可能部署到同一个节点上。
用 Gearman 搭建 Map/Reduce ,GearmanManager 来管理所有的 workers。启动多个 gearman-manager daemon,为了充分利用服务器资源,使其运行于不同的 CPU 内核上。 假设启动 10 个gearman-manager daemon,CPU 是 4核。 [root@www ~]# ps aux | grep gearman-manager | awk {'print $2;'} | sort -k1,1 | head -3 | xargs -n 1
考虑到我们这很多微服务依赖的redis的压力并不大(大量1-4G实例),轻量级的redis主从即可满足需求,使用社区现有解决方案,基本不会增加运维成本。
Scheduler 是 Kubernetes 的调度器,主要的任务是把定义的 pod 分配到集群的节点上。听起来非常简单,但有很多要考虑的问题:
kube-scheduler是K8S集群默认的调度器,如果你愿意,也可以自己写一个调度组件来替代kube-scheduler,在实际应用中,kube-scheduler也有许多不尽如人意的地方,很多大厂也或多或少的修改或开发自己的调度器。参见《美团点评Kubernetes集群管理实践》
领取专属 10元无门槛券
手把手带您无忧上云