k8s通过service访问pod(五)--技术流ken

service

每个 Pod 都有自己的 IP 地址。当 controller 用新 Pod 替代发生故障的 Pod 时,新 Pod 会分配到新的 IP 地址。这样就产生了一个问题:

如果一组 Pod 对外提供服务(比如 HTTP),它们的 IP 很有可能发生变化,那么客户端如何找到并访问这个服务呢?

Kubernetes 给出的解决方案是 Service。

创建 Service

Kubernetes Service 从逻辑上代表了一组 Pod,具体是哪些 Pod 则是由 label 来挑选。Service 有自己 IP,而且这个 IP 是不变的。客户端只需要访问 Service 的 IP,Kubernetes 则负责建立和维护 Service 与 Pod 的映射关系。无论后端 Pod 如何变化,对客户端不会有任何影响,因为 Service 没有变。

第一步:创建下面的这个 Deployment:

查看支持的apiversion使用命令kubectl api-versions

第二步:部署并查看pod

我们启动了三个 Pod,运行 httpd 镜像,label 是 run: httpd,Service 将会用这个 label 来挑选 Pod。

[root@ken ~]# kubectl apply -f httpd.yml
deployment.apps/httpd created
[root@ken ~]# kubectl get pod -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
httpd-8c6c4bd9b-ljvlb   1/1     Running   0          41s   10.244.1.27   host1   <none>           <none>
httpd-8c6c4bd9b-ngxqv   1/1     Running   0          41s   10.244.1.28   host1   <none>           <none>
httpd-8c6c4bd9b-wxblj   1/1     Running   0          41s   10.244.2.18   host2   <none>           <none>

第三步:集群内部测试连通性

Pod 分配了各自的 IP,这些 IP 只能被 Kubernetes Cluster 中的容器和节点访问。

[root@ken ~]# curl 10.244.1.28
<html><body><h1>It works!</h1></body></html>
[root@ken ~]# curl 10.244.1.27
<html><body><h1>It works!</h1></body></html>
[root@ken ~]# curl 10.244.2.18
<html><body><h1>It works!</h1></body></html>

第四步:接下来创建 Service,其配置文件如下:

① v1 是 Service 的 apiVersion。

② 指明当前资源的类型为 Service。

③ Service 的名字为 httpd-svc。

④ selector 指明挑选那些 label 为 run: httpd 的 Pod 作为 Service 的后端。

⑤ 将 Service 的 8080 端口映射到 Pod 的 80 端口,使用 TCP 协议。

第五步: 执行 kubectl apply 创建 Service httpd-svc。

[root@ken ~]# kubectl apply -f service.yml
service/httpd-svc created
[root@ken ~]# kubectl get service
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
httpd-svc    ClusterIP   10.106.64.97   <none>        8080/TCP   17s
kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP    11h

httpd-svc 分配到一个 CLUSTER-IP 10.106.64.97。可以通过该 IP 访问后端的 httpd Pod。

[root@ken ~]# curl 10.106.64.97:8080
<html><body><h1>It works!</h1></body></html>

根据前面的端口映射,这里要使用 8080 端口。另外,除了我们创建的 httpd-svc,还有一个 Service kubernetes,Cluster 内部通过这个 Service 访问 kubernetes API Server。

通过 kubectl describe 可以查看 httpd-svc 与 Pod 的对应关系。

[root@ken ~]# kubectl describe service httpd-svc
Name:              httpd-svc
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"httpd-svc","namespace":"default"},"spec":{"ports":[{"port":8080,"...
Selector:          run=httpd
Type:              ClusterIP
IP:                10.106.64.97
Port:              <unset>  8080/TCP
TargetPort:        80/TCP
Endpoints:         10.244.1.27:80,10.244.1.28:80,10.244.2.18:80
Session Affinity:  None
Events:            <none>

Endpoints 罗列了三个 Pod 的 IP 和端口。

DNS访问service

在 Cluster 中,除了可以通过 Cluster IP 访问 Service,Kubernetes 还提供了更为方便的 DNS 访问。

第一步:查看coredns

kubeadm 部署时会默认安装 coredns 组件。

[root@ken ~]# kubectl get deployment --namespace=kube-system
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
coredns   2/2     2            2           11h

coredns 是一个 DNS 服务器。每当有新的 Service 被创建,coredns 会添加该 Service 的 DNS 记录。Cluster 中的 Pod 可以通过 <SERVICE_NAME>.<NAMESPACE_NAME> 访问 Service。

第二步:dns访问

比如可以用 httpd-svc.default 访问 Service httpd-svc。

[root@ken ~]# kubectl run busybox --rm -it --image=busybox /bin/sh
/ # wget httpd-svc:8080
Connecting to httpd-svc:8080 (10.106.64.97:8080)
index.html           100% |*************|    45  0:00:00 ETA
/ # ls
bin         home        root        usr
dev         index.html  sys         var
etc         proc        tmp
/ # cat index.html
<html><body><h1>It works!</h1></body></html>

由于这个 Pod 与 httpd-svc 同属于 default namespace,可以省略 default 直接用 httpd-svc 访问 Service。

第三步:查看namespace

如果要访问其他 namespace 中的 Service,就必须带上 namesapce 了。kubectl get namespace 查看已有的 namespace。

[root@ken ~]# kubectl get namespace
NAME          STATUS   AGE
default       Active   11h
kube-public   Active   11h
kube-system   Active   11h

第四步:在 kube-public 中部署 Service httpd2-svc

配置如下:

第五步:创建资源

通过 namespace: kube-public 指定资源所属的 namespace。多个资源可以在一个 YAML 文件中定义,用 --- 分割。执行 kubectl apply 创建资源:

[root@ken ~]# kubectl apply -f service.yml
deployment.apps/httpd2 created
service/httpd2-svc created

第六步:查看 kube-public 的 Service:

[root@ken ~]# kubectl get service --namespace=kube-public
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
httpd2-svc   ClusterIP   10.111.175.138   <none>        8080/TCP   63s

第七步:在 busybox Pod 中访问 httpd2-svc:

[root@ken ~]# kubectl run busybox --rm -it --image=busybox /bin/sh
/ # wget httpd2-svc:8080
wget: bad address ‘httpd2-svc:8080‘
/ # wget httpd2-svc.kube-public:8080
Connecting to httpd2-svc.kube-public:8080 (10.111.175.138:8080)
index.html           100% |*************|    45  0:00:00 ETA

因为属于不同的 namespace,必须使用 httpd2-svc.kube-public 才能访问到。

外网访问service

除了 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。

第二步:创建service

[root@ken ~]# kubectl apply -f service.yml
service/httpd-svc created
[root@ken ~]# kubectl get service httpd-svc
NAME        TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
httpd-svc   NodePort   10.108.118.202   <none>        8080:31785/TCP   12s

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

EXTERNAL-IP 为 nodes,表示可通过 Cluster 每个节点自身的 IP 访问 Service。

PORT(S) 为 8080:31785。8080 是 ClusterIP 监听的端口(每个节点都有该端口),31785 则是节点上监听的端口。Kubernetes 会从 30000-32767 中分配一个可用的端口,每个节点都会监听此端口并将请求转发给 Service。

[root@ken ~]# ss -tnl | grep 31785
LISTEN     0      128         :::31785                   :::*

第三步:测试nodeport是否正常工作

[root@ken ~]# curl 172.20.10.2:31785
<html><body><h1>It works!</h1></body></html>
[root@ken ~]# curl 172.20.10.7:31785
<html><body><h1>It works!</h1></body></html>
[root@ken ~]# curl 172.20.10.9:31785
<html><body><h1>It works!</h1></body></html>

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

第四步:指定特定端口

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

现在配置文件中就有三个 Port 了:

nodePort 是节点上监听的端口。

port 是 ClusterIP 上监听的端口。

targetPort 是 Pod 监听的端口。

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

第四步:应用新的 nodePort 并验证:

[root@ken ~]# kubectl apply -f service.yml
service/httpd-svc configured

[root@ken ~]# kubectl get service httpd-svc
NAME        TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
httpd-svc   NodePort   10.108.118.202   <none>        8080:30000/TCP   6m8s

[root@ken ~]# curl 172.20.10.2:30000
<html><body><h1>It works!</h1></body></html>
[root@ken ~]# curl 172.20.10.7:30000
<html><body><h1>It works!</h1></body></html>
[root@ken ~]# curl 172.20.10.9:30000
<html><body><h1>It works!</h1></body></html>

nodePort: 30000 已经生效了。

原文地址:https://www.cnblogs.com/kenken2018/p/10335998.html

时间: 2024-10-08 21:15:03

k8s通过service访问pod(五)--技术流ken的相关文章

五分钟彻底学会iptables防火墙--技术流ken

iptables简介 IPTABLES 是与最新的 3.5 版本 Linux内核集成的 IP 信息包过滤系统.如果 Linux 系统连接到因特网或 LAN.服务器或连接 LAN 和因特网的代理服务器, 则该系统有利于在 Linux 系统上更好地控制 IP 信息包过滤和防火墙配置. iptables 组件是一种工具,也称为用户空间(userspace),它使插入.修改和除去信息包过滤表中的规则变得容易.除非您正在使用 Red Hat Linux 7.1 或更高版本,否则需要下载该工具并安装使用它.

Jenkins+Git+Gitlab+Ansible实现持续集成自动化部署动态网站(二)--技术流ken

项目前言 在上一篇博客<Jenkins+Git+Gitlab+Ansible实现持续化集成一键部署静态网站(一)--技术流ken>中已经详细讲解了如何使用这四个工具来持续集成自动化部署一个静态的网站. 如果大家可以熟练掌握以上内容,势必会在工作中减轻不小的工作量. 本篇博客将再次使用这四个工具结合freestyle和pipeline来完成动态网站的部署. 为了拓宽知识点,本篇博客将使用jenkins的两种常用方法来进行部署,如果你对pipeline还不熟悉,请参考我之前的博客<Jenki

Jenkins+Git+Gitlab+Ansible实现持续集成自动化部署静态网站(一)--技术流ken

前言 在之前已经写了关于Git,Gitlab以及Ansible的两篇博客<Git+Gitlab+Ansible剧本实现一键部署Nginx--技术流ken>,<Git+Gitlab+Ansible剧本实现一键部署动态网站(二)--技术流ken>,以及关于jenkins的简单使用<Jenkins持续集成介绍及插件安装版本更新演示(一)--技术流ken>.相信大家也已经完全掌握了这三项工具的使用,也可以使用这几项工具可以部署静态以及动态网站了. 以前的博客可以实现一键部署网站

cobbler批量安装系统使用详解-技术流ken

1.前言 cobbler是一个可以实现批量安装系统的Linux应用程序.它有别于pxe+kickstart,cobbler可以实现同个服务器批量安装不同操作系统版本. 2.系统环境准备及其下载cobbler 一.系统环境 系统版本:CentOS release 6.7 (Final) 内网IP:192.168.232.7/24    #用来对内通信,提供cobbler服务 外网IP:10.220.5.166/24      #连接外网 二. 关闭安全服务 [[email protected] ~

NFS企业级实战应用详解-技术流ken

1.简介 在上一篇博文中讲述了samba的实战应用,samba使得window和linux共享文件成为可能.NFS则实现了linux与linux之间的文件共享. 2.系统环境 系统版本:centos6.7 服务器IP: 10.220.5.166/24 客户端IP: 10.220.5.188/24 3.关闭安全服务 [[email protected] ~]# service iptables stop [[email protected] ~]# setenforce 0 4.下载NFS 当nf

samba企业级实战应用详解-技术流ken

1.简介 Samba是一套使用SMB(Server Message Block)协议的应用程序, 通过支持这个协议, Samba允许Linux服务器与Windows系统之间进行通信,使跨平台的互访成为可能. 2.系统环境 系统版本:centos6.7 服务器IP: 10.220.5.166/24 3.关闭安全服务 [[email protected] ~]# service iptables stop [[email protected] ~]# setenforce 0 4. 安装samba

网站集群架构实战(LVS负载均衡、Nginx代理缓存、Nginx动静分离、Rsync+Inotify全网备份、Zabbix自动注册全网监控)--技术流ken

前言 最近做了一个不大不小的项目,现就删繁就简单独拿出来web集群这一块写一篇博客.数据库集群请参考<MySQL集群架构篇:MHA+MySQL-PROXY+LVS实现MySQL集群架构高可用/高性能-技术流ken>下面是项目的一些简单介绍. WEB集群项目简介 随着网站访问量的激增,势必会导致网站的负载增加,现需求搭载一套高性能,高负载,高可用的网站集群架构以保障网站的持续.高效.安全.稳定的运行. 针对以上需求,我们采用了如下的技术: 使用负载均衡技术来实现网站请求的调度分发,减小后端服务器

zabbix实现百台服务器的自动化监控--技术流ken

前言 最近有小伙伴通过Q联系到我说:公司现在有百多台服务器,想要部署zabbix进行监控,怎么实现自动化全网监控? 本篇博客就把我告诉他的解决方案写出来,供大家以后参考. 实现自动化全网监控,需要用到脚本,以及zabbix的自动注册或者自动发现的功能.以前也写过一篇关于两者的博客<分布式系统监视zabbix讲解八之自动发现/自动注册--技术流ken>,但是内容可能没有那么详尽,本篇博客将详细完整的演示如何使用zabbix实现百台服务器的自动化监控. zabbix自动注册 活动的Zabbix a

实战!基于lamp安装Discuz论坛-技术流ken

1.简介 我前面的博客已经详细介绍了lamp采用yum安装以及编译安装的方式,这篇博客将基于yum安装的lamp架构来实战安装Discuz论坛,你可以任选其一来完成. 2.系统环境 centos7.5 服务器IP:172.20.10.7/28 客户端IP:172.20.10.4/28 3.关闭安全服务 [[email protected] ~]# setenforce 0 4.安装lamp [[email protected] ~]# yum install httpd php php-mysq