K8S 最佳实践-映射外部服务
大多数 Kubernetes 用户都有可能用到集群外部的服务。例如,您可能使用 Twillio API 发送短信,或使用 Google Cloud Vision API 进行图像分析。
如果位于不同环境中的应用连接相同的外部端点,并且您不打算将外部服务引入 Kubernetes 集群,那么在代码中直接使用外部服务端点是完全可以的。然而,很多时候情况并非如此。
数据库就是一个很好的例子。虽然一些云原生数据库(如 Cloud Firestore 或 Cloud Spanner)对所有访问均使用一个端点,但大多数数据库对不同实例都有单独的端点。
说到这里,您可能会认为,就查找端点而言,ConfigMap 是个不错的解决方案。只需将端点地址存储在 ConfigMap 中,并将其作为环境变量用于代码中。此解决方案的确有效,但也存在一些缺点。您需要修改部署以包含 ConfigMap 并编写额外的代码以从环境变量中读取。但最重要的是,如果端点地址发生变化,您可能需要重启所有正在运行的容器以获取更新后的端点地址。
在本集的 “Kubernetes 最佳实践” 中,我们会学习如何将 Kubernetes 内置服务发现机制运用于集群外部运行的服务,像使用集群内的服务一样使用外部服务!通过这种方式,您可以在开发环境和生产环境中实现相同的功能,如果您最终将服务移入集群内,则不需要更改任何代码。
场景 1:具有 IP 地址的集群外数据库
其中一个常见场景是在集群外部托管自己的数据库,例如在 Google 计算引擎实例中。如果您在 Kubernetes 内部和外部分别运行一些服务,或者需要在 Kubernetes 允许的基础上获得更多定制或控制,通常可采用上述这种方式。
希望未来某个时候您可以将所有服务都移入集群内,但在此之前将是“内外混用”的状态。幸运的是,您可以使用静态 Kubernetes 服务来缓解上述痛点。
在本例中,我使用 Cloud Launcher 创建了一个 MongoDB 服务器。由于此服务器在与 Kubernetes 集群相同的网络(或 VPC)中创建,因此可以使用高性能的内部 IP 地址访问。在 Google Cloud 中,这是默认设置,因此无需进行任何特殊配置。
现在我们有了 IP 地址,那么第一步就是创建服务:
kind: Service
apiVersion: v1
metadata:
name: mongo
Spec:
type: ClusterIP
ports:
– port: 27017
targetPort: 27017
您可能会注意到此服务没有 Pod 选择器。此操作将创建一个服务,但它不知道往哪里发送流量。这样一来,您可以手动创建一个将从此服务接收流量的 Endpoints 对象。
kind: Endpoints
apiVersion: v1
metadata:
name: mongo
subsets:
– addresses:
– ip: 10.240.0.4
ports:
– port: 27017
您可以看到 Endpoints 手动定义了数据库的 IP 地址,并且使用的名称与服务名称相同。Kubernetes 将 Endpoints 中定义的所有 IP 地址视为与常规 Kubernetes Pod 一样。现在您可以用一个简单的连接字符串访问数据库:
mongodb://mongo
> 根本不需要在代码中使用 IP 地址!如果以后 IP 地址发生变化,您可以为端点更新 IP 地址,而应用无需进行任何更改。
场景 2:具有 URI 的远程托管数据库
如果您使用的是来自第三方的托管数据库服务,它们可能会为您提供可用于连接的统一资源标识符 (URI)。如果它们为您提供 IP 地址,则可以使用场景 1 中的方法。
在本例中,我在 mLab 上托管了两个 MongoDB 数据库。一个是我的开发数据库,另一个是生产数据库。
这些数据库的连接字符串如下所示:
mongodb://<dbuser>:<dbpassword>@ds149763.mlab.com:49763/devmongodb://<dbuser>:<dbpassword>@ds145868.mlab.com:45868/prodmLab
为您提供了动态 URI 和动态端口,您可以看到两者都不同。我们来使用 Kubernetes 基于这些差异创建一个抽象层。在本例中,我们将连接开发数据库。
您可以创建一个 “ExternalName” Kubernetes 服务,此服务为您提供将流量重定向到外部服务的静态 Kubernetes 服务。此服务在内核级别执行简单的 CNAME 重定向,因此对性能的影响非常小。
服务的 YAML 如下所示:
kind: Service
apiVersion: v1
metadata:
name: mongo
spec:
type: ExternalName
externalName: ds149763.mlab.com
现在,您可以使用更简化的连接字符串:
mongodb://<dbuser>:<dbpassword>@mongo:<port>/dev
由于 “ExternalName” 使用 CNAME 重定向,因此无法执行端口重映射。对于使用静态端口的服务来说,这可能不成问题,然而本例中使用的是动态端口。mLab 免费版为您提供了动态端口号,并且不允许更改。这意味着您需要对开发和生产数据库使用其他连接字符串。
但如果您可以获取 IP 地址,就可以执行端口重映射,关于此内容,我将在下一部分进行介绍。
场景 3:具有 URI 和端口重映射功能的远程托管数据库
CNAME 重定向对于每个环境均使用相同端口的服务非常有效,但如果每个环境的不同端点使用不同的端口,CNAME 重定向就略显不足。幸运的是我们可以使用一些基本工具来解决这个问题。
第一步是从 URI 获取 IP 地址。
对 URI 运行 nslookup、hostname 或 ping 命令即可获取数据库的 IP 地址。
您现在可以创建一个重新映射 mLab 端口的服务,并为此 IP 地址创建端点。
kind: Service
apiVersion: v1
metadata:
name: mongo
spec:
ports:
– port: 27017
targetPort: 49763
—
kind: Endpoints
apiVersion: v1
metadata:
name: mongo
subsets:
– addresses:
– ip: 35.188.8.12
ports:
– port: 49763
注:URI 可以使用 DNS 在多个 IP 地址之间进行负载平衡,因此,如果 IP 地址发生变化,这个方法可能会有风险!如果您通过上述命令获取多个 IP 地址,则可以将所有这些地址都包含在 Endpoints YAML 中,并且 Kubernetes 会在所有 IP 地址之间进行流量的负载平衡。
通过这种方式,您无需指定端口即可连接到远程数据库。Kubernetes 服务重映射端口的过程完全透明!
mongodb://<dbuser>:<dbpassword>@mongo/dev
结论
将外部服务映射到内部服务可让您未来灵活地将这些服务纳入集群,同时最大限度地减少重构工作。即使您今天不打算将服务加入集群,以后可能也会这样做!而且,这样一来,您可以更轻松地管理和了解组织所使用的外部服务。
如果外部服务具有有效域名,并且您不需要重新映射端口,那么使用 “ExternalName” 服务类型将外部服务映射到内部服务十分简便、快捷。如果您没有域名或需要执行端口重映射,只需将 IP 地址添加到端点并使用即可。
本文转自中文社区-K8S 最佳实践-映射外部服务
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Kubernetes-基于EFK进行统一的日志管理
1、统一日志管理的整体方案 通过应用和系统日志可以了解Kubernetes集群内所发生的事情,对于调试问题和监视集群活动来说日志非常有用。对于大部分的应用来说,都会具有某种日志机制。因此,大多数容器引擎同样被设计成支持某种日志机制。对于容器化应用程序来说,最简单和最易接受的日志记录方法是将日志内容写入到标准输出和标准错误流。 但是,容器引擎或运行时提供的本地功能通常不足以支撑完整的日志记录解决方案。例如,如果一个容器崩溃、一个Pod被驱逐、或者一个Node死亡,应用相关者可能仍然需要访问应用程序的日志。因此,日志应该具有独立于Node、Pod或者容器的单独存储和生命周期,这个概念被称为群集级日志记录。群集级日志记录需要一个独立的后端来存储、分析和查询日志。Kubernetes本身并没有为日志数据提供原生的存储解决方案,但可以将许多现有的日志记录解决方案集成到Kubernetes集群中。在Kubernetes中,有三个层次的日志: 基础日志 Node级别的日志 群集级别的日志架构 1.1 基础日志 kubernetes基础日志即将日志数据输出到标准输出流,可以使用kubectl logs...
- 下一篇
Kunbernetes-容器云应用的安装部署工具Helm
1、Helm介绍 在Kubernetes中部署容器云的应用也是一项有挑战性的工作,Helm就是为了简化在Kubernetes中安装部署容器云应用的一个客户端工具。通过helm能够帮助开发者定义、安装和升级Kubernetes中的容器云应用,同时,也可以通过helm进行容器云应用的分享。在Kubeapps Hub中提供了包括Redis、MySQL和Jenkins等参见的应用,通过helm可以使用一条命令就能够将其部署安装在自己的Kubernetes集群中。 helm的整体架构如下图所示,Helm架构由Helm客户端、Tiller服务器端和Chart仓库所组成;Tiller部署在Kubernetes中,Helm客户端从Chart仓库中获取Chart安装包,并将其安装部署到Kubernetes集群中。 Helm是管理Kubernetes包的工具,Helm能提供下面的能力: 创建新的charts 将charts打包成tgz文件 与chart仓库交互 安装和卸载Kubernetes的应用 管理使用Helm安装的charts的生命周期 在Helm中,有三个需要了解的重要概念: chart:是创建K...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS8编译安装MySQL8.0.19
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS8安装Docker,最新的服务器搭配容器使用
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS关闭SELinux安全模块
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程