防火墙环境下部署和治理 Kubernetes 的可行战略
随着 Kubernetes 和云原生系统成为部署和治理现代运行程序的理想规范，它们裁减到受限或防火墙环境带来了共同的应战。这些环境通常受监管合规性、安保疑问或组织政策驱动，这些要素带来了架构、运营和安保方面的阻碍。本文深化讨论了在防火墙后部署 Kubernetes 集群的复杂性，提供了克制这些阻碍的处置打算和战略。
防火墙或受限环境限度了外部互联网访问以确保数据安保并包全系统免受未经授权的入侵。这些环境在金融、医疗保健和政府等具备严厉监管要求的行业中很经常出现。在这些环境中，通常只准许特定类型的流量，并且须要严厉的监视。只管这些控制措施增强了安保性，但它们为 Kubernetes 等现代云原生基础设备带来了严重应战，而 Kubernetes 依赖于互联网访问能力成功集群治理、镜像拉取和外部 API 通讯等性能。
在防火墙环境中部署 Kubernetes 的应战
处置打算：为了处置这个疑问，企业可以使用具备存储库复制或拉取缓存性能的注册表，在防火墙内本地托管容器镜像。这些注册表可以以受控模式复制或从外部注册表拉取镜像，确保必要的容器镜像可用，而无需继续访问互联网。Harbor 等注册表为这些环境提供了安保的外部镜像存储库。此外，应用镜像优化上班流可以确保只要经过验证的外部起源镜像能力进入安保注册表。
我经常使用过的另一种方法是经过网关或代理主机复制镜像，该主机与源注册表和目的注册表都具备衔接性。当源注册表和目的注册表的 capabilities 未知时，此处置打算或许有效。imgpkg、crane 或 skopeo 等工具可以在超过防火墙边界的注册表之间复制镜像。例如，imgpkg 打包格局将运行程序的 helm 图表及其容器镜像捆绑为一个单元。imgpkg 捆绑包可以从源注册表导出为 tar 存档到代理主机的本地文件系统。而后，此 tar 存档可以推送到防火墙后的注册表，imgpkg 确保捆绑包中运行程序的 helm 图表中的注册表援用会智能更新为指向目的注册表。
处置打算：组织可以建设反向代理和 VPN 隧道技术来克制这个疑问。部署在非军事化区域 (DMZ) 中的反向代理可以处置来自防火墙内的 API 恳求，同时提供安保的入口点。此外，堡垒主机和 VPN 网关可以准许对 Kubernetes 控制平面启动受控的、安保的访问。这些主机位于外部网络之外，但充任受限环境和外部服务之间的桥梁，准许治理员与集群交互，而不会违犯防火墙战略。
例如，Azure 准许创立部署在企业私有网络中的“私有” AKS 集群。出于安保要素，自动状况下，对私有 AKS 集群的控制平面的访问遭到限度。但 Azure 还提供 Azure Bastion 等处置打算，该处置打算提供从外部环球安保访问私有集群。用户经过本地计算机上的 RDP 或 SSH 衔接到 Azure Bastion，并可以经过代理访问私有集群。Bastion 担任包全到私有集群的流量。
处置打算：在 CoreDNS 中经常使用 DNS 转发。CoreDNS 是 Kubernetes 集群中的自动 DNS 解析器，可以性能为从防火墙外部解析外部 DNS 查问。可以修正 CoreDNS 以将 DNS 查问转发到特定主机名（如www.example.com）到外部解析器，并将一切其余查问解析到防火墙内。这可以经过经常使用“forward”CoreDNS插件来成功，将www.example.com的查问转发到 Google 或 CloudFlare DNS，并将一切其余内容（用“.”示意）转发到本地解析器，只需将它们指向 /etc/resolv.conf 即可。这确保了关键的 DNS 解析不会被防火墙战略阻止，并且还准许防火墙治理员经过仅准许特定外部查问来坚持网络安保。
处置打算：经常使用本地镜像和外部容器注册表来更新集群。Kubernetes 装置工具（如 Kubespray）准许在离线环境中启动集群治理。经过 Kubespray 装置和修补 Kubernetes 须要访问静态文件（如 kubectl 和 kubeadm）、操作系统包以及** Kubernetes 组件的一些容器镜像。静态文件可以经过在防火墙内运转 nginx/HAproxy 主机来提供。操作系统包可以经过部署 yum 或 Debian 存储库的本地镜像来失掉。Kubespray 所需的容器镜像可以经过运转本地实例的“kind”或 docker 注册表来提供，这些注册表中预先填充了镜像。此外，公司可以经常使用继续集成/继续交付 (CI/CD) 管道以受控模式处置更新，在将更改推行到消费集群之前，在暂存集群上启动本地测试和验证。GitOps 是 CI/CD 的一个子类别，它会智能将更改部署到目的环境，这些更改由对 Git 存储库的提交触发。暂存和消费集群可以映射到不同的 Git 分支，并且可以经过首先将更改提交到暂存分支，对其启动彻底测试，而后才将相反的更改提交到消费分支来战略性地推出更新和补丁。这确保了集群即使没有智能更新也能经常使用最新的安保补丁。
处置打算：组织可以在其防火墙环境中部署自托管的代替打算来保养可观察性和监控。例如，可以在外部部署 Prometheus 和 Grafana 来处置目的和可视化，而散布式存储处置打算（如 Ceph 或 MinIO）可以交流外部云存储。这些工具可以复制外部服务的功，同时确保一切数据安保地保管在防火墙内。自托管代替打算的容器镜像和 helm 图表可以经常使用前面概述的镜像治理和散发技术拉取到隔离的环境中。
处置打算：Kubernetes 的原生性能，例如 Pod 安保战略 (PSP)、基于角色的访问控制 (RBAC) 和网络战略，可以用来增强防火墙环境中 Kubernetes 集群的安保性。此外，部署像 Istio 这样的服务网格或 Linkerd 可以提供细粒度的流量控制和安保性，确保只要授权的服务能力启动通讯。这些网格还提供双向 TLS (mTLS) 用于加密微服务之间的流量，进一步增强安保性并合乎法规。
处置打算：为了在集群外部地下服务，像 Istio 或 Contour 这样的入口网关可以充任代理，将流量路由到这些服务。它们包全对外部服务的访问，由于它们可以终止 TLS 流量并充任一切须要地下的服务的繁多入口点。
私有负载平衡处置打算，如 MetalLB，可以部署以提供入口网关的 IP/主机名的高可用性。经常使用 MetalLB 和入口网关的组合可以提高安保性。只要一个 IP 地址/主机名须要包全，并且一切泄露服务的网络流量都将被加密。
在防火墙环境中部署和治理 Kubernetes 会带来共同的应战，从镜像治理和控制平面访问到 DNS 解析和第三方集成。然而，经过正确的战略和工具，组织可以应用 Kubernetes 的弱小性能，同时坚持防火墙基础设备所需的安保性、合规性和运营稳固性。容器注册表镜像复制、特定查问的 DNS 转发、VPN 隧道、入口网关和自托管监控工具等技术确保 Kubernetes 即使在最受限度的环境中依然是一个可行的处置打算。
旨在驳回云原生技术的组织必定细心设计其基础设备，确保满足安保要求，而不会就义 Kubernetes 提供的可裁减性和灵敏性。经过应用上述处置打算，Kubernetes 集群即使在高度受限的环境中也能有效运转。