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

前面我们已经学习了如何部署 service,也验证了 swarm 的 failover 特性。不过截止到现在,有一个重要问题还没有涉及:如何访问 service?这就是本节要讨论的问题。

为了便于分析,我们重新部署 web_server。

① docker service rm 删除 web_server,service 的所有副本(容器)都会被删除。

② 重新创建 service,这次直接用 --replicas=2 创建两个副本。

③ 每个 worker node 上运行了一个副本。

好了,现在 service 已经在那里了,我们如何访问呢?

要访问 http 服务,最起码网络得通吧,服务的 IP 我们得知道吧,但这些信息目前我们都不清楚。不过至少我们知道每个副本都是一个运行的容器,要不先看看容器的网络配置吧。

在 swarm-worker1 上运行了一个容器,是 web_server 的一个副本,容器监听了 80 端口,但并没有映射到 Docker Host,所以只能通过容器的 IP 访问。查看一下容器的 IP。

容器 IP 为 172.17.0.2,实际上连接的是 Docker 默认 bridge 网络。

我们可以直接在 swarm-worker1 上访问容器的 http 服务。

但这样的访问也仅仅是容器层面的访问,服务并没有暴露给外部网络,只能在 Docker 主机上访问。换句话说,当前配置下,我们无法访问 service web_server。

从外部访问 service

要将 service 暴露到外部,方法其实很简单,执行下面的命令:

docker service update --publish-add 8080:80 web_server

如果是新建 service,可以直接用使用 --publish 参数,比如:

docker service create --name web_server --publish 8080:80 --replicas=2 httpd

容器在 80 端口上监听 http 请求,--publish-add 8080:80 将容器的 80 映射到主机的 8080 端口,这样外部网络就能访问到 service 了。

大家可能会奇怪,为什么 curl 集群中任何一个节点的 8080 端口,都能够访问到 web_server?

这实际上就是使用 swarm 的好处了,这个功能叫做 routing mesh,我们下一节重点讨论。

书籍:

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

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

时间: 2024-10-12 04:45:46

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

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 容器技术(139)

除了 Cluster 内部可以访问 Service,很多情况我们也希望应用的 Service 能够暴露给 Cluster 外部.Kubernetes 提供了多种类型的 Service,默认是 ClusterIP. ClusterIP Service 通过 Cluster 内部的 IP 对外提供服务,只有 Cluster 内的节点和 Pod 可访问,这是默认的 Service 类型,前面实验中的 Service 都是 ClusterIP. NodePort Service 通过 Cluster 节

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

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

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

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

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

Swarm 如何存储数据?- 每天5分钟玩转 Docker 容器技术(103)

service 的容器副本会 scale up/down,会 failover,会在不同的主机上创建和销毁,这就引出一个问题,如果 service 有要管理的数据,那么这些数据应该如何存放呢? 选项一:打包在容器里. 显然不行.除非数据不会发生变化,否则,如何在多个副本直接保持同步呢? 选项二:数据放在 Docker 主机的本地目录中,通过 volume 映射到容器里. 位于同一个主机的副本倒是能够共享这个 volume,但不同主机中的副本如何同步呢? 选项三:利用 Docker 的 volum