文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

在生产环境中,你可以遵循的那些Kubernetes优秀实践

2024-12-03 15:00

关注

总的说来,Kubernetes具有支持自动扩展、零停机时间部署、服务发现、自动部署、以及回滚等出色且丰富的功能,非常适合于大规模的容器部署与管理。虽然Kubernetes能够灵活地分配资源和工作负载,但是具有复杂而陡峭的学习曲线。为了省时省力,您当然可以将其外包给KaaS提供商。不过,如果您需要对生产环境中的Kubernetes具有全面的掌控能力,那么就需要花费一些时间,来掌握Kubernetes的可观察性、日志记录、集群监控、以及安全性配置等方面。

与此同时,由于在生产环境中运行容器往往需要大量的计算资源与能力,因此人们纷纷选用各种基于云的编排平台。不过,这其中也潜在着一些安全问题。例如:Kubernetes Pod虽然可以在所有基础架构中快速启动,但是随着其Pod之间内部流量的增加,Kubernetes的攻击面会逐渐增大,安全隐患随之增多。此外,Kubernetes固有的高度动态、且短暂的运行环境,往往无法与传统的安全工具完美融合。我们亟待开发出一种能够满足存储安全性、网络监控与治理、容器生命周期管理、以及平台选择等需求的Kubernetes配置策略。

下面,我将和您讨论在生产环境中,可遵循的Kubernetes各种优秀实践与探索。

使用就绪且存活的探针(Probes)进行健康检查

对于线上业务而言,保证服务的正常稳定是重中之重。而对于故障服务的及时处理,避免影响业务,以及快速恢复一直是DevOps的难点。在管理大型且分布式的系统时,为了确保应用实例的正常运行,我们需要提前设置好Kubernetes的运行状况检查。

您可以根据目标环境与需求,来创建并定制各种运行状况检查项。例如,我们可以用到WeaveWorks。它能够创建一个虚拟的网络,以网络交换机的方式,连接到部署在多台主机上的Docker容器,便于应用无需逐个配置端口映射和链接等信息。具体内容请参见--https://www.weave.works/blog/resilient-apps-with-liveness-and-readiness-probes-in-kubernetes。

值得注意的是,那些就绪(Readiness)的探针可以让Kubernetes知晓应用是否已准备好了为流量提供对应的服务。也就是说,在分配服务并将流量发送给Pod之前,Kubernetes需要始终确保拥有正常的就绪探针。

那么,我们又该如何获悉应用的有效性呢?在此,我们需要通过存活(Liveliness)探针,以确保应用一旦失效,Kubernetes会立即删除旧的Pod,并将其替换为新的Pod。

通过上述对于Kubernetes的健康检查,我们可以及时对于检测到的故障服务,采取自动下线,或重启服务的方式,使其自行恢复。

资源管理

通常,我们需要为单个容器指定或限制资源的请求数,将Kubernetes所处的环境分为不同的命名空间(namespace),以供不同的团队、部门、应用、以及客户来使用。具体请参见--http://blog.kubecost.com/blog/requests-and-limits/。

值得一提的是,此处的Kubernetes资源使用情况是指在生产环境中,容器与Kubernetes Pod的资源被使用的数量。据此,我们可以合理地控制好在转化时所需的成本。此外,通常运营团队还需要获悉容器的CPU平均使用率,以及Pod所消耗的资源百分比,进而判定目前的Kubernetes生产环境是否处于已被优化的最佳状态。

启用RBAC

RBAC(基于角色的访问控制)是一种许可或限制用户和应用,对于系统和网络访问的方法。Kubernetes从1.8版开始便引入了RBAC。我们可以通过rbac.authorization.k8s.io API组,来创建各种授权策略,限制能够访问目标生产环境和群集的用户与进程。

可以说,RBAC为Kubernetes集群增加了一个额外的安全层。您可以在Kubernetes中对某些帐户的权限进行添加或删除,以及设置具体的访问规则。具体内容请参见--https://medium.com/@danielckv/what-is-rbac-in-kubernetes-c54457eff2dc

群集配置和负载平衡

要满足生产环境级别,Kubernetes架构需要具备高可用性、multi-master、以及multi-etcd群集等特性。在实际应用中,我们往往会使用诸如Terraform、Ansible之类的工具,来配置群集。

一旦我们设置好了所有的集群,并为正在运行的应用创建了Pod,那么我们就该考虑为这些Pod配备负载平衡器,以便将各种网络流量路由到对应的服务处。不过,开源的Kubernetes项目并不会默认提供负载均衡器。因此,我们需要与诸如NGINX Ingress controller、HAProxy或ELB之类的工具,或是针对Kubernetes的插件,来实现负载平衡的功能。具体内容请参见--https://medium.com/avmconsulting-blog/external-ip-service-type-for-kubernetes-ec2073ef5442。

将标签附加到Kubernetes对象

我们可以将诸如键/值对(key/value pairs)之类的标签,作为某种属性附加到Pod等对象上。在生产环境中,我们可以通过标签,对Kubernetes对象进行识别,分组,批量查询,以及其他操作。例如:我们可以根据容器所属的应用,对容器进行分组。当然,团队可以事先建立好任意数量的标签约定。具体内容请参见--https://theithollow.com/2019/01/31/kubernetes-services-and-labels/。

设置网络策略

网络策略能够方便我们通过明确的声明,来决定哪些流量适合通过,进而让Kubernetes能够阻止所有不合格(non-conforming)或不需要的流量。例如,作为基本的安全措施,我们可以在群集中定义和限制某些网络流量。

实际上,Kubernetes中的每个网络策略都可以被定义为一个授权连接的列表。根据已创建的网络策略,只有满足条件的Pod才有资格接受既定的连接。简而言之,网络策略会根据白名单,来授权和允许“从”或“向”Pod建立的连接。具体内容请参见--https://theithollow.com/2019/10/21/kubernetes-network-policies/。

集群监控和日志记录

集群监控,对于确保生产环境中Kubernetes的配置、性能和流量等方面的安全性,都是至关重要的。同时,我们有必要在系统架构的每一层上设置日志功能。这些生成的日志将有助于我们通过安全工具,来执行分析和审计功能。可以说,没有日志和监控,我们就不可能诊断出发生的问题,也就无法确保合规性。具体内容请参见--https://dzone.com/articles/logging-amp-monitoring-of-kubernetes-applications。

从无状态的应用开始

由于运行无状态应用要比有状态的应用容易得多,因此对于刚上手K​​ubernetes的团队而言,他们可以使用无状态的后端,通过避免建立长期运行(long-running)的连接,轻松地根据业务的需求,按需进行灵活的迁移和扩展。此外,通过使用无状态,开发人员还可以在零停机时间状态下,更有效地部署应用程序。

启用自动扩展插件(Auto Scaler)

Kubernetes提供三种用于部署的自动扩展功能,即:水平Pod自动扩展插件(HPA)、垂直Pod自动扩展插件(VPA)、以及群集自动扩展。其中:

控制运行时(run times)的各种源头

如果您只允许Pod从公共资源中提取镜像,那么您可能对运行时一无所知。因此,我们需要对群集中的所有容器进行源头控制。通过在注册表上应用策略,我们就可以从受信任的注册表中提取安全、且经过认证的镜像。

持续评估

我们需要不断评估目标应用的状态,以及设置的合理性。例如,我们可以通过查看某个容器的历史内存使用情况,从长远的角度来分配更少、却又更加合理的内存数量,以节省成本。

保护那些重要的服务

通过使用Pod优先级,您可以对不同服务的重要程度进行设置。例如,为了获得更好的稳定性,您可以将RabbitMQ Pod设置得比其他应用Pod更为重要;或者通过把Ingress Controller Pod的重要性设置得优先于数据处理Pod,进而保持那些面对用户的服务的可用性。

零停机时间

说到可用性,我们还可以通过设置群集和服务的HA(高可用性),来确保零宕机时间。例如,使用Pod的反亲和性(Pod anti affinity),我们可以确保在不同节点上,分配一个Pod的多个副本,并通过计划内和计划外的群集节点中断,来确保服务的可用性。

此外,通过使用Pod的中断预算(Pod disruption budgets),我们也能够确保副本数量最少。

小结

综上所述,为了交付出平稳可靠的应用服务,我们从可用性、可扩展性、安全性、负载平衡、资源管理、以及监控等方面,深入讨论了在生产环境中,可以遵循的Kubernetes各种优秀实践。

原文Kubernetes in Production: Best Practices to Follow,作者: Pavan Belagatti

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

 

来源:51CTO内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯