Kubernetes,也缩写为 K8s,是一个用于自动化和协调容器化应用和工作负载的部署、扩展和管理的开源平台。 它为在任何环境(本地、云端和边缘)中作为容器运行的应用程序提供了具有内置灵活性、可扩展性、可靠性、高可用性和可移植性的计算基础设施。
Kubernetes 自动执行与大规模管理容器化工作负载相关的最常见任务,包括部署、负载均衡、水平扩展、推出和回滚以及自我修复。
许多组织已经在生产中使用 Kubernetes(无论是针对部分还是大多数应用程序),而其他组织正在对其进行评估。 它的流行使得 Kubernetes 成为容器编排和管理的事实标准。
Kubernetes 的采用正在快速增长,因为它可以帮助:
将传统的整体式应用重构为更小、松散耦合的部分(称为微服务)有助于提高业务敏捷性,因为新的应用程序功能和更新可以更快地发布且更轻松地扩展。 采用云原生、微服务架构推动了底层计算基础设施发展的需求,因此我们观察到从物理系统和虚拟机到容器的转变是运行微服务的最有效方式之一。
随着微服务和容器数量的增长,自动化容器管理的需求也在增长。 这就是 Kubernetes 发挥作用的地方。
Kubernetes 可以大规模协调和运行容器化应用程序;但是,它不提供将应用代码打包成容器化格式以供分发和执行的方法(容器镜像包括应用程序代码和必要的运行时、库和其他软件依赖项)。 为了使 pod 运行,Kubernetes 还要求在每个节点上安装一个容器运行时。 Kubernetes 最初使用 Docker Engine 作为容器运行时。 然而,从 Kubernetes 1.24 开始,容器运行时必须遵守容器运行时接口 (CRI),而 Docker Engine 则不需要。 两个流行的符合 CRI 的容器运行时是 CRI-O 和 containerd(最初是 Docker 项目)。
要将应用程序打包到容器中,您需要一个像Docker这样的工具,它是用于构建、共享和运行容器化应用程序的最流行的工具之一。 它简化并自动化了将应用程序打包成可移植容器映像的过程,这些映像可在本地、云端(包括 Kubernetes 环境)中执行和部署。 Docker 打包的容器可以在 containerd 和 CRI-O 运行时上本地运行。
Kubernetes 平台由连接在一起形成集群的节点组成,这些节点在集群中共享池化计算资源。 每个集群管理 Pod,它是 Kubernetes 架构中最小的可部署单元。 一个 pod 包含一个或多个应用容器。 Pod 被组合在一起以组成一项服务。 可以使用多种方法从外部访问 Kubernetes 集群内的应用程序,其中Ingress 控制器是最流行和最有效的方法之一。
让我们仔细看看 Kubernetes 环境中的组件:
Kubernetes pod是Kubernetes中可部署的最小可执行单元。 pod 是应用程序容器镜像的“虚拟主机”(类似于传统应用程序的物理服务器或虚拟机),它封装了一个或多个共享相同计算、存储和网络资源的容器(因此可以被认为是相对紧密耦合的)。 Pod 在 Kubernetes 节点上部署并执行。
Kubernetes 节点是计算基础设施的最小单元。 节点可以是虚拟机或物理服务器,它分配处理器、内存、存储和网络资源来部署、运行、扩展和管理 pod。 节点连接在一起形成集群。
Kubernetes 集群是一组节点,其中池化计算资源在各个 pod 之间共享。 集群中有两种类型的节点:
通常,Kubernetes 集群中每种类型都有多个节点,以实现高可用性和容错能力。
Kubernetes 部署描述了如何将应用程序作为集群中 pod 的一组副本(或实例)来运行。 部署定义:
Kubernetes 支持双 IPv4/IPv6 堆栈,为集群中运行的容器化应用提供网络连接。 Kubernetes 集群中应用程序之间的通信以及集群内服务之间的通信均在第 4 层(IP 地址、端口)和第 7 层(主机名、通用资源标识符 [URI])进行管理,并包括路由、负载均衡、安全性、监控和可见性功能。
在Kubernetes 网络模型中,每个 pod 都有一个唯一的 IP 地址,该地址是从集群的私有地址池中动态分配的。 同一集群中所有节点上运行的所有 pod 都属于同一个 IP 网络,并且可以通过该网络相互通信。 一个 pod 内的多个容器通过环回接口相互通信。
Kubernetes 服务使作为集群中一个或多个 pod 运行的应用程序或微服务可通过网络访问(“公开它”)。 Kubernetes 服务将应用程序表示为执行相同功能(例如 Web 服务)的指定 pod 的逻辑组。 相同的选择器(或标签)应用于服务中的所有 pod,以标记它们在该服务中的成员身份。 当部署新的 Pod 或终止正在运行的 Pod 时,Kubernetes 会使用标签来跟踪服务的 Pod 集。
Kubernetes 服务可以根据定义的连接策略在集群内相互通信,并且可以从集群外部访问,例如通过使用 Ingress 控制器。
Ingress 对象是 Kubernetes Ingress API 的一部分,可用于通过 HTTP 等第 7 层(应用层)协议向外部公开 Kubernetes 中运行的应用。 Ingress 网关和 Ingress 控制器是用于控制 Ingress 对象并管理用户与应用之间的通信(用户到服务或南北连接)的工具。
根据设计,Ingress 对象对定制的请求处理策略的支持有限;例如,您无法定义和附加安全策略。 因此,许多供应商使用自定义资源定义 (CRD) 来扩展其 Ingress 控制器的功能,以满足不断变化的客户需求。
举例来说, NGINX Ingress Controller定义自定义资源(VirtualServer、VirtualServerRoute、TransportServer 和 Policy)来增强 Kubernetes 集群边缘的 API 网关、负载均衡器和 Ingress 功能的性能、弹性、正常运行时间、安全性和可观察性。
NGINX 提供负载均衡、身份验证、授权、访问控制、加密、可观察性和流量分割(断路器、A/B 测试以及蓝绿和金丝雀部署)服务,以确保通信快速、可靠和安全。 为了支持频繁的应用程序发布,NGINX 自定义资源还支持跨多租户开发和 DevOps 团队的自助服务治理。
Gateway API是一个开源项目,旨在改进和标准化 Kubernetes 中的服务网络。 Gateway API 规范由 Kubernetes 社区管理,由 Kubernetes Ingress API 发展而来,旨在解决生产环境中 Ingress 资源的限制,包括定义请求处理的细粒度策略以及跨多个团队和角色委托配置控制的能力。
在我们的博客上了解有关 NGINX Gateway Fabric 的 5 件事中了解有关 NGINX 对 Gateway API 的实现的更多信息。
服务网格是一个基础设施层,控制 Kubernetes 集群中服务之间的通信(服务到服务或东西向连接)。 最常见的服务网格用例包括 mTLS 身份验证/加密以及 K8s 集群中服务之间通信的可观察性。
在我们的博客上发布 NGINX Gateway Fabric 版本 1.0 中了解有关使用NGINX Gateway Fabric实现统一应用交付的更多信息,该版本旨在有效地将 Ingress 控制器和服务网格用例结合到一个工具中。
Kubernetes 安全是一种分层方法,用于保护基础设施(本地和云计算资源、网络通信和管理平面)和在 Kubernetes 集群内运行的应用。
为了保护基础设施的安全,请遵循保护云和本地实施的一般安全建议、教程和最佳实践。
对于安全的应用,在边缘和 Kubernetes 集群内实施强大的安全控制,为往返于集群和集群内的所有通信提供身份验证、授权、访问控制、加密、监控和可见性,并提供可选的 Web应用防火墙和拒绝服务保护。
在我们的博客《使用流量管理工具保护 Kubernetes 的六种方法》中了解有关保护 Kubernetes 的更多信息。
在 Kubernetes 采用的早期阶段,DIY 方法占主导地位,但是对于许多组织来说,这种方法很复杂,并且难以构建和运营。 因此,对于生产部署,组织正在采用云管理的 Kubernetes 平台和预先打包的 Kubernetes 发行版,这些发行版集成了各种技术组件,简化了维护生命周期,并且可以在混合和多云环境中部署。
以下是一些托管和预打包的 Kubernetes 平台的示例:
云管理的 Kubernetes:
预先打包的 Kubernetes 发行版:
NGINX 的 Kubernetes 原生连接和安全堆栈有助于改善客户体验,降低复杂性,增加正常运行时间,并为在本地、云端和边缘运行的 Kubernetes应用提供大规模详细的实时可见性。
Kubernetes 的连接堆栈——在混合、多云环境中优化、扩展和保护 Kubernetes 应用程序。
首先申请 NGINX Ingress Controller 和 NGINX App Protect WAF 和 DoS 的30 天免费试用版。