嘉宾文章作者:Rob Richardson(@rob_rich),技术布道者,MemSQL;KavyaPearlman(@KavyaPearlman),全球网络安全策略师,Wallarm
大图 了解 Calico 支持的不同网络选项,以便您可以根据需要选择最佳选项。 价值 Calico 灵活的模块化架构支持广泛的部署选项,因此您可以选择适合您特定环境和需求的最佳网络方法。这包括使用各种 CNI 和 IPAM 插件以及底层网络类型以非覆盖或覆盖模式运行的能力,无论是否使用 BGP。 概念 如果您想全面了解可供您选择的网络,我们建议您确保熟悉并理解以下概念。如果您想跳过学习并直接获得选择和建议,您可以跳到网络选项。 Kubernetes 网络基础知识 Kubernetes 网络模型定义
覆盖网络(overlay network)是将TCP数据包装在另一种网络包里面进行路由转发和通信的技术。Overlay网络不是默认必须的,但是它们在特定场景下非常有用。比如当我们没有足够的IP空间,或者网络无法处理额外路由,抑或当我们需要Overlay提供的某些额外管理特性。一个常见的场景是当云提供商的路由表能处理的路由数是有限制时,例如AWS路由表最多支持50条路由才不至于影响网络性能。因此如果我们有超过50个Kubernetes节点,AWS路由表将不够。这种情况下,使用Overlay网络将帮到我们。
网络策略(NetworkPolicy)是一种关于 Pod 间及与其他Network Endpoints间所允许的通信规则的规范。NetworkPolicy资源使用 标签 选择 Pod,并定义选定 Pod 所允许的通信规则。网络策略通过网络插件来实现。要使用网络策略,用户必须使用支持 NetworkPolicy 的网络解决方案。默认情况下,Pod间是非隔离的,它们接受任何来源的流量。Pod 可以通过相关的网络策略进行隔离。一旦命名空间中有网络策略选择了特定的 Pod,该 Pod 会拒绝网络策略所不允许的连接(命名空间下其他未被网络策略所选择的 Pod 会继续接收所有的流量)。网络策略不会冲突,它们是附加的。如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的 ingress/egress 规则的并集。因此策略的顺序并不会影响策略的结果。
在开始之前,让我们先谈谈什么是 eBPF。该首字母缩写词代表可扩展伯克利包过滤器。我不认为这很有帮助。您真正需要知道的是,eBPF 允许您在内核中运行自定义代码。它使内核可编程。让我们稍作停顿,确保我们都在同一个页面上了解内核是什么。内核是操作系统的核心部分,分为用户空间和内核。我们通常编写在用户空间中运行的应用程序。每当这些应用程序想要以任何方式与硬件交互时,无论是读取还是写入文件、发送或接收网络数据包、访问内存,所有这些都需要只有内核才能拥有的特权访问权限。用户空间应用程序必须在想要做任何这些事情时向内核发出请求。内核还负责诸如调度这些不同的应用程序之类的事情,以确保多个进程可以同时运行。
这篇详细的博文探讨了 Kubernetes 网络的复杂性,提供了关于如何在容器化环境中确保高效和安全通信的见解。
在我的职业生涯中,我有机会参与许多次面试,也进行过许多次面试。这种独特的位置让我对招聘过程有了更深入的理解,尤其是在DevOps领域。在这篇文章中,我渴望通过概述一些关键的面试问题,分享我积累的见解和知识,这些问题对于致力于推进职业生涯的DevOps工程师来说可能非常宝贵,无论您是准备进入就业市场还是希望提高面试技巧。
使用服务网格并非与 Kubernetes 决裂,而是水到渠成的事情。Kubernetes 的本质是通过声明配置对应用进行生命周期管理,而服务网格的本质是提供应用间的流量和安全性管理,以及可观察性。假如已经使用 Kubernetes 构建了稳定的微服务平台,那么如何设置服务间调用的负载均衡和流量控制?
通过本文,你将了解在 Kubernetes 内外,数据包是如何转发的,从原始的 Web 请求开始,到托管应用程序的容器。
Service Mesh(服务网格)诞生于云原生生态领域的潮流中,虽然大家对这一技术生态充满不确定性,甚至难以接受,然而,如果我们消除外面的“杂声”,细心洞察里面的细节,或许能有不一样的收获,毕竟,所有新技术的出现是为了解决业务痛点,而非是为了一些没用意义的炒作。
听说过服务网格并试用过Istio的人可能都会有以下5个疑问。 (1)为什么Istio 要绑定Kubernetes呢? (2)Kubernetes和服务网格分别在云原生中扮演什么角色? (3)Istio扩展了Kubernetes的哪些方面?解决了哪些问题? (4)Kubernetes、xDS协议(Envoy、MOSN等)与Istio之间是什么关系? (5)到底该不该使用Service Mesh? 本文将带读者梳理清楚 Kubernetes、xDS协议与Istio服务网格之间的内在联系。此外,本文还将介绍Kub
在2022年的KubeCon会议上,来自Palo Alto Networks的安全研究员Yuval Avrahami和Shaul Ben Hai分享了议题《Trampoline Pods:Node to Admin PrivEsc Built Into Popular K8s Platforms》[1] ,介绍了攻击者在容器逃逸之后如何利用节点上“TrampolinePods”的权限来接管集群,其中涉及的技术和思路十分值得学习与思考,本文主要介绍该技术的原理和步骤,扩展了同一类型的方法,希望云安全人员在深入了解攻击技术之后,能够发现并缓解生产环境中存在的类似风险,共同建设云环境安全。
自从7月份发布Kubernetes 1.3以来,用户已经能够在其集群中定义和实施网络策略。这些策略是防火墙规则,用于指定允许流入和流出的数据类型。如果需要,Kubernetes可以阻止所有未明确允许的流量。本文针对K8s的网络策略进行介绍并对网络性能进行测试。 网络策略 K8s的网络策略应用于通过常用标签标识的pod组。然后,可以使用标签来模拟传统的分段网络,这些网络通常用于在多层应用程序中隔离层:例如,您可以通过特定的“段”标签来标识前端和后端pod。策略控制这些段之间的流量,甚至控制来自外部源的流量。
Kubernetes (简称K8s)是是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效,Kubernetes提供了应用部署、规划、更新、维护的一种机制。K8s 最早是由谷歌开发的,目前由Cloud Native Computing Foundation 基金会维护。
在我们多年使用kubernetes的经验中,我们有幸看到了很多集群(在GCP,AWS和Azure上都是托管的和非托管的),并且我们看到一些错误在不断重复。
Istio 是一个服务网格,它允许在集群中的 pods 和服务之间进行更详细、复杂和可观察的通信。
目前 Kubernetes 在容器编排市场中占据了主导地位,与此同时,众多组织在使用 Kubernetes 时或多或少遇到了安全问题。本文深入探讨使用 Kubernetes 时可能遇到的风险和挑战,并给出了对应的安全实践。
设计可扩展的云原生应用程序需要深思熟虑,即便拥有大量云来部署我们的应用程序,仍然有许多挑战需要克服。以复杂而臭名昭著的分布式计算仍然是真实的。另外网络会导致速度变慢和意外错误。因为云原生应用程序通常是微服务,所以必须专门设计和部署以克服这些挑战。
书籍英文版下载链接为 https://developers.redhat.com/books/introducing-istio-service-mesh-microservices/,作者 Burr Sutter 和 Christian Posta。
感谢 CNI(容器网络接口),Kubernetes 提供了大量选项来满足您的网络需求。在多年依赖简单的网络解决方案之后,我们面临着对以客户需求为后盾的高级功能的日益增长的需求。Cilium 将我们 K8s 平台中的网络提升到了一个新的水平。
云原生不但可以很好的支持互联网应用,也在深刻影响着新的计算架构、新的智能数据应用。以容器、服务网格、微服务、Serverless 为代表的云原生技术,带来一种全新的方式来构建应用。笔者是一名云原生狂热信徒,长期以来我都不知道该怎么整理自己的收藏夹。最近想到,为了让大家能够掌握云原生最新资讯,我决定把我的收藏夹共享出来,大家一起嗨~~
服务网格(Service Mesh)这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长,服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。
Kubernetes 是为运行分布式集群而建立的,分布式系统的本质使得网络成为 Kubernetes 的核心和必要组成部分,了解 Kubernetes 网络模型可以使你能够正确运行、监控和排查应用程序故障。
最近,Linkerd社区一直在花时间处理多集群Kubernetes的挑战。如何在多个Kubernetes集群之间应用Linkerd的零配置自动mTLS或流量分割等特性?服务网格应该做什么,而更重要的是:服务网格不应该做什么?
kubernetes 已经成为云原生的行业标准,现在几乎所有行业所有公司的所有业务都在基于云进行部署,拓展。但是很多咨询学员其实对于云原生并不太感冒,觉得挺没技术含量的,yml 文件或者 yaml 文件相较于市面上存在的其它语言,它属于声明式的,不需要太多逻辑,就是一个通过不断使用就可以熟练的过程,纯记忆的东西,毫无艺术可言,掌握这些东西,并不会对自己的开发思维和编码能力带来影响。
Hello folks,我是 Luga,接着上一篇博文,我们继续来解析 Kubectl 安全插件相关内容...
这篇文章将带你了解使用 Kubernetes 和 Istio Service Mesh 构建多集群及混合云的过程和需要考虑的问题。
从5.0版本开始(版本更迭时间和具体内容),Tungsten Fabric支持使用防火墙安全策略框架实现Kubernetes 1.9.2网络策略。虽然Kubernetes网络策略也可以使用TF中的其它安全对象(如安全组和TF网络策略)来实现,但TF防火墙安全策略对标签的支持,有助于简化和抽象Kubernetes的工作负载。
漏洞概述 2020年12月4日,Kubernetes产品安全委员会披露了一个新的Kubernetes漏洞,即CVE-2020-8554。这是一个中危漏洞,所有的Kubernetes版本都会受到该漏洞的影响。该漏洞允许Kubernetes服务将集群流量拦截至任意IP地址,任何可以管理服务的用户可以利用此漏洞对群集中的Pod和节点执行中间人(MITM)攻击。 攻击者可以利用MITM攻击伪装成内部或外部节点,然后从网络流量中获取凭证,在将目标用户的数据发送到其预期目标之前篡改目标用户的数据,或完全阻止其与特定IP
随着微服务架构的日渐盛行,Serverless框架的逐步落地,应用上云后带来了模块间网络调用需求的大规模增长,Kubernetes 自 1.3 引入了 Network Policy,其提供以应用为中心, 基于策略的网络控制,用于隔离应用以减少攻击面。
API gateway 位于应用程序的前面,旨在解决身份验证和授权、速率限制以及为外部消费者提供公共访问点等业务问题。相比之下,service mesh 专注于提供应用程序组件之间的操作(而非业务)逻辑。
DevOps从提出到现在,已经走过了一段很长的路。包括Docker和Kubernetes在内的多种平台也已经帮助企业用前所未有的速度实现了软件应用的交付。同时,随着应用的容器化构建和发布比率不断上升,作为事实上的容器编排工具,Kubernetes在企业用户中备受欢迎和广泛认可。
Kubernetes(又名K8s)是Google开源的容器集群管理系统(谷歌内部:Borg),现在由Cloud Native Computing Foundation维护,旨在帮助提升Docker容器化工作负载、服务、应用程序的部署、扩展和管理的自动化程度和便捷性。
SIGTERM(信号 15)在基于 Unix 的操作系统(如 Linux)中用于终止进程。SIGTERM 信号提供了一种优雅的方式来终止程序,使其有机会准备关闭并执行清理任务,或者在某些情况下拒绝关闭。Unix/Linux 进程可以以多种方式处理 SIGTERM,包括阻塞和忽略。
k8s中的网络策略主要分为原生 NetworkPolicy 和第三方网络插件提供的网络策略。本文将主要分析原生Networkpolicy的网络策略。
为了了解 Kubernetes 网络的不同方面,我们首先描述在 Pod 中创建服务一直到在公共云和私有云中访问该服务时会发生什么。同时,我们强调了对 Ingress 的需求以及它如何适应整个 Kubernetes 集群网络模型。
自从服务上云引入K8S后,我们开发模式也发生了改变。我们最能想到的一种开发流程就是:
本文重点介绍Kubernetes的更新,以及Tungsten Fabric中相应支持的功能。
Kubernetes是用于构建高度可扩展系统的强大工具。结果,许多公司已经开始或正在计划使用它来协调生产服务。不幸的是,像大多数强大的技术一样,Kubernetes也很复杂。我们整理了以下清单,以帮助你生产环境最佳实践Kubernetes。
该博客描述了 Cilium 如何在不使用 Sidecar 的情况下提供服务网格。在这篇博客中,我们将扩展 mTLS 的主题,并研究 Cilium 如何提供具有出色安全性和性能特征的基于 mTLS 的无边车身份验证。
在 Kubernetes 中,Pod 是最小的调度单元。应用程序实际是以 Pod 在运行的,通常情况下出于可扩展性和降低爆炸半径等方面的考虑,只会给 Pod 设置有限的资源。那么对于大流量的场景,一般都是通过水平扩容的方式进行应对。
从较高的层次上看,Linkerd 由一个控制平面(control plane) 和一个 数据平面(data plane) 组成。
NetworkPolicy 的 .spec.ingress.from 和 .spec.egress.to 字段中,可以指定 4 种类型的标签选择器:
什么是Kubernetes网络策略? 有几家公司正在将他们的整个基础设施转移到Kubernetes。Kubernetes的目标是抽象通常在现代IT数据中心中找到的所有组件。因此,pods表示计算实例,
众所周知,Kubernetes很难! 以下是在生产中使用它应遵循的一些最佳实践。遵循这些步骤能够确保更高的安全性和生产效率。
感谢 CNI(容器网络接口),Kubernetes 提供了许多选项来满足你的网络需求。在多年依赖简单的解决方案后,我们面临着由客户需求支持的高级功能的日益增长的需求。Cilium 将我们的 K8s 平台的网络提升到了新的水平。
领取专属 10元无门槛券
手把手带您无忧上云