外网如何访问 Service?- 每天5分钟玩转 Docker 容器技术(139)

除了 Cluster 内部可以访问 Service,很多情况我们也希望应用的 Service 能够暴露给 Cluster 外部。Kubernetes 提供了多种类型的 Service,默认是 ClusterIP。

ClusterIP 
Service 通过 Cluster 内部的 IP 对外提供服务,只有 Cluster 内的节点和 Pod 可访问,这是默认的 Service 类型,前面实验中的 Service 都是 ClusterIP。

NodePort 
Service 通过 Cluster 节点的静态端口对外提供服务。Cluster 外部可以通过 <NodeIP>:<NodePort> 访问 Service。

LoadBalancer 
Service 利用 cloud provider 特有的 load balancer 对外提供服务,cloud provider 负责将 load balancer 的流量导向 Service。目前支持的 cloud provider 有 GCP、AWS、Azur 等。

下面我们来实践 NodePort,Service httpd-svc 的配置文件修改如下:

添加 type: NodePort,重新创建 httpd-svc

Kubernetes 依然会为 httpd-svc 分配一个 ClusterIP,不同的是:

  1. EXTERNAL-IP 为 nodes,表示可通过 Cluster 每个节点自身的 IP 访问 Service。
  2. PORT(S) 为 8080:323128080 是 ClusterIP 监听的端口,32312 则是节点上监听的端口。Kubernetes 会从 30000-32767 中分配一个可用的端口,每个节点都会监听此端口并将请求转发给 Service。

下面测试 NodePort 是否正常工作。

通过三个节点 IP + 32312 端口都能够访问 httpd-svc

接下来我们深入探讨一个问题:Kubernetes 是如何将 <NodeIP>:<NodePort> 映射到 Pod 的呢?

与 ClusterIP 一样,也是借助了 iptables。与 ClusterIP 相比,每个节点的 iptables 中都增加了下面两条规则:

规则的含义是:访问当前节点 32312 端口的请求会应用规则 KUBE-SVC-RL3JAE4GN7VOGDGP,内容为:

其作用就是负载均衡到每一个 Pod。

NodePort 默认是的随机选择,不过我们可以用 nodePort 指定某个特定端口。

现在配置文件中就有三个 Port 了:
nodePort 是节点上监听的端口。
port 是 ClusterIP 上监听的端口。
targetPort 是 Pod 监听的端口。

最终,Node 和 ClusterIP 在各自端口上接收到的请求都会通过 iptables 转发到 Pod 的 targetPort

应用新的 nodePort 并验证:

nodePort: 30000 已经生效了。

小结

本章我们讨论访问应用的机制 Service,学习了如何创建 Service;Service 的三种类型 ClusterIP、NodePort 和 LoadBalancer,以及它们各自的适用场景。

下一节我们开始学习 Rolling Update。

书籍:
1.《每天5分钟玩转Docker容器技术》
https://item.jd.com/16936307278.html

2.《每天5分钟玩转OpenStack》
https://item.jd.com/12086376.html

原文地址:http://blog.51cto.com/cloudman/2084432

时间: 2024-11-05 13:33:04

外网如何访问 Service?- 每天5分钟玩转 Docker 容器技术(139)的相关文章

DNS 访问 Service - 每天5分钟玩转 Docker 容器技术(138)

在 Cluster 中,除了可以通过 Cluster IP 访问 Service,Kubernetes 还提供了更为方便的 DNS 访问. kubeadm 部署时会默认安装 kube-dns 组件. kube-dns 是一个 DNS 服务器.每当有新的 Service 被创建,kube-dns 会添加该 Service 的 DNS 记录.Cluster 中的 Pod 可以通过 <SERVICE_NAME>.<NAMESPACE_NAME> 访问 Service. 比如可以用 htt

运行第一个 Service - 每天5分钟玩转 Docker 容器技术(96)

上一节我们创建好了 Swarm 集群, 现在部署一个运行 httpd 镜像的 service,执行如下命令: docker service create --name web_server httpd 部署 service 的命令形式与运行容器的 docker run 很相似,--name 为 service 命名,httpd 为镜像的名字. 通过 docker service ls 可以查看当前 swarm 中的 service. REPLICAS 显示当前副本信息,0/1 的意思是 web_

如何访问 Service?- 每天5分钟玩转 Docker 容器技术(99)

前面我们已经学习了如何部署 service,也验证了 swarm 的 failover 特性.不过截止到现在,有一个重要问题还没有涉及:如何访问 service?这就是本节要讨论的问题. 为了便于分析,我们重新部署 web_server. ① docker service rm 删除 web_server,service 的所有副本(容器)都会被删除. ② 重新创建 service,这次直接用 --replicas=2 创建两个副本. ③ 每个 worker node 上运行了一个副本. 好了,

Service IP 原理 - 每天5分钟玩转 Docker 容器技术(137)

Service Cluster IP 是一个虚拟 IP,是由 Kubernetes 节点上的 iptables 规则管理的. 可以通过 iptables-save 命令打印出当前节点的 iptables 规则,因为输出较多,这里只截取与 httpd-svc Cluster IP 10.99.229.179 相关的信息: 这两条规则的含义是: 如果 Cluster 内的 Pod(源地址来自 10.244.0.0/16)要访问 httpd-svc,则允许. 其他源地址访问 httpd-svc,跳转到

如何滚动更新 Service?- 每天5分钟玩转 Docker 容器技术(102)

在前面的实验中,我们部署了多个副本的服务,本节将讨论如何滚动更新每一个副本. 滚动更新降低了应用更新的风险,如果某个副本更新失败,整个更新将暂停,其他副本则可以继续提供服务.同时,在更新的过程中,总是有副本在运行的,因此也保证了业务的连续性. 下面我们将部署三副本的服务,镜像使用 httpd:2.2.31,然后将其更新到 httpd:2.2.32. 创建服务: docker service create --name my_web --replicas=3 httpd:2.2.31 将 serv

用 Label 控制 Service 的位置 - 每天5分钟玩转 Docker 容器技术(106)

上一节我们讨论了 Service 部署的两种模式:global mode 和 replicated mode.无论采用 global mode 还是 replicated mode,副本运行在哪些节点都是由 Swarm 决定的,作为用户我们有没有可能精细控制 Service 的运行位置呢? 答案是:能,使用 label. 逻辑分两步: 为每个 node 定义 label. 设置 service 运行在指定 label 的 node 上. label 可以灵活描述 node 的属性,其形式是 ke

神奇的 routing mesh - 每天5分钟玩转 Docker 容器技术(100)

接上一节案例,当我们访问任何节点的 8080 端口时,swarm 内部的 load balancer 会将请求转发给 web_server 其中的一个副本. 这就是 routing mesh 的作用. 所以,无论访问哪个节点,即使该节点上没有运行 service 的副本,最终都能访问到 service. 另外,我们还可以配置一个外部 load balancer,将请求路由到 swarm service.比如配置 HAProxy,将请求分发到各个节点的 8080 端口. ingress 网络 当我

k8s 核心功能 - 每天5分钟玩转 Docker 容器技术(116)

本节带领大家快速体验 k8s 的核心功能:应用部署.访问.Scale Up/Down 以及滚动更新. 部署应用 执行命令: kubectl run kubernetes-bootcamp \      --image=docker.io/jocatalin/kubernetes-bootcamp:v1 \      --port=8080 这里我们通过 kubectl run 部署了一个应用,命名为 kubernetes-bootcamp. Docker 镜像通过 --image 指定. --p

Swarm 如何实现 Failover?- 每天5分钟玩转 Docker 容器技术(98)

故障是在所难免的,容器可能崩溃,Docker Host 可能宕机,不过幸运的是,Swarm 已经内置了 failover 策略. 创建 service 的时候,我们没有告诉 swarm 发生故障时该如何处理,只是说明了我们期望的状态(比如运行3个副本),swarm 会尽最大的努力达成这个期望状态,无论发生什么状况. 以上一节我们部署的 Service 为例,当前 3 个副本分布在 swarm-worker1 和 swarm-worker2 上. 现在我们测试 swarm 的 failover 特