K8s网络之Service

Kubernetes集群部署(三)——service,k8s网络通信,calico网络插件 一 service 1 服务 将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。 使用 Kubernetes,你无需修改应用程序即可使用不熟悉的服务发现机制。 Kubernetes 为 Pods 提供自己的 IP 地址,并为一组 Pod 提供相同的 DNS 名, 并且可以在它们之间进行负载均衡。 2 动机 创建和销毁 Kubernetes Pod 以匹配集群状态。 Pod 是非永久性资源。 如果你使用 Deployment 来运行你的应用程序,则它可以动态创建和销毁 Pod。 每个 Pod 阅读详情

K8s网络:服务发现与负载均衡

Ingress(七层) -> Service (SVC)(四层) > EndPoint -> kube-proxy -> Lvs/iptables

Ingress负责七层HTTP/HTTPS路由,将不同域名或路径的请求转发至对应Service;Service通过标签选择器关联后端Pod,创建Endpoints记录真实IP;kube-proxy监听Service变化,通过iptables或IPVS规则实现流量转发,确保请求精准到达目标Pod。整个过程实现解耦与动态更新,支撑应用弹性伸缩与高可用。

K8s网络解决的主要问题?

服务发现:如何找到Pod,Pod如何找到其他的Pod;

  • Pod内部通信:localhost:port
  • 用户查找Pod:Pod的ip:port
  • Pod与Pod通信:跨节点,但是不用NAT地址转换

CNI插件实现Pod间通信

  • Flannel:使用VXLAN“隧道”技术,适合中小型集群;
  • Calico:适合大规模集群;BGP 边界网关协议(Border Gateway Protocol,BGP)是互联网上一个核心的去中心化自治路由协议。BGP不使用传统的内部网关协议(IGP)的指标。

服务发现

通过Service实现:

  • 通过“标签”选中Pod,提供固定的入口(类似“VIP”),然后通过负载均衡;
  • 给Pod提供DNS服务,Pod通过域名访问Service;

Service -> EndPoint(动态的IP列表) -> Pod

创建Service时,自动创建EndPoints;

  • 网络和负载均衡:kube-proxy -> 系统内核(Lvs/iptables)

Service三大功能:

  1. 服务发现:通过DNS域名(如web-service.default.svc.cluster.local)

ServiceName.NameSpace.svc.cluster.local 替代动态Pod IP

      2、负载均衡:把请求平均分给背后的多个Pod,避免单个Pod过载;

      3、端口映射:隐藏Pod内部端口(如外部访问80端口,转发到Pod的8080端口)。

Service的四大模式/四种类型:

  • ClusterIP(默认):只允许集群内部访问,外部不可见,用于集群内部Pod间通信,例如:后端调用,数据库连接等;

前提是先拥有一个标签是app: my-app的Pod在运行,因为Service的Selector需要匹配Pod的标签,如果没有这样的标签,需要现添加一个,以下举例说明:

# 给名为my-nginx-66bf7cffd7-2vgl7的Pod添加标签

kubectl label pod my-nginx-66bf7cffd7-2vgl7 app=my-app

vim my-service.yaml

---

apiVersion: v1

kind: Service

metadata:

  name: my-clusterip-service

spec:

  type: ClusterIP #可省略,默认就是 ClusterIP

  selector:

    app: my-app   #匹配 Pod 的标签

  ports:

    - protocol: TCP

      port: 80    #Service 的端口,集群内的其他 Pod 通过该端口访问服务。

      targetPort: 80 #Pod 的端口,Service 将流量转发到该端口。

---

apiVersion: v1

kind: Service

metadata:

  name: my-clusterip-service

spec:

  type: ClusterIP

  clusterIP: 10.96.0.100  #手动指定 ClusterIP

  selector:

    app: my-app

  ports:

    - protocol: TCP

      port: 80

      targetPort: 80

# 应用yaml文件

kubectl apply -f my-service.yaml

# 验证svc运行情况并获取 ClusterIP 地址:

kubectl get svc my-clusterip-service

会出现以下:

NAME                   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE

my-clusterip-service   ClusterIP   10.110.83.243   <none>        80/TCP    16s

# 然后通过ClusterIP访问

curl 10.110.83.243

vim my-service.yaml

---

apiVersion: v1

kind: Service

metadata:

  name: my-clusterip-service

spec:

  type: ClusterIP #可省略,默认就是 ClusterIP

  selector:

    app: my-app   #匹配 Pod 的标签

  ports:

    - protocol: TCP

      port: 80    #Service 的端口,集群内的其他 Pod 通过该端口访问服务。

      targetPort: 80 #Pod 的端口,Service 将流量转发到该端口。

---

apiVersion: v1

kind: Service

metadata:

  name: my-clusterip-service

spec:

  type: ClusterIP

  clusterIP: 10.96.0.100  #手动指定 ClusterIP

  selector:

    app: my-app

  ports:

    - protocol: TCP

      port: 80

      targetPort: 80

# 应用yaml文件

kubectl apply -f my-service.yaml

# 验证svc运行情况并获取 ClusterIP 地址:

kubectl get svc my-clusterip-service

会出现以下:

NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE

my-clusterip-service   ClusterIP   10.110.83.243            <none>         80/TCP     16s

# 然后通过ClusterIP访问

curl 10.110.83.243

  • NodePort:外部通过任意Node的IP进行访问,NodePort的默认范围是30000-32767,但可以手动指定。简单服务、对外测试;

和上面同理,需要有一个标签和你的选择器写的标签一致。

vim 07-nodeport.yaml

apiVersion: v1

kind: Service

metadata:

  name: my-nodeport-service

spec:

  type: NodePort  #指定服务类型为 NodePort

  selector:       #用于匹配目标 Pod 的标签

    app: my-web   #匹配 Pod 的标签

  ports:

    - protocol: TCP

      port: 80         #Service 的端口,客户端通过该端口访问服务

      targetPort: 80 #Pod 的端口,Service 将流量转发到该端口

      nodePort: 30000  #可选,指定节点端口(范围 30000-32767)

# 应用yaml文件

kubectl apply -f 07-nodeport.yaml

# 验证Service

kubectl get svc

# 访问服务:使用节点 IP 和 NodePort 访问服务。(三个节点都可以)

​​​​​​http://<Node-IP>:30000

  • LoadBalancer:使用云厂商的负载均衡器,实现对外的服务,适合在生产环境云平台上使用;

# 先给Pod添加标签

kubectl label pod my-nginx-66bf7cffd7-4k5hc aihao=haha

# 下载插件,应用 MetalLB 资源

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.5/config/manifests/metallb-native.yaml

# 配置IP 地址池(示例为192.168.221.10-192.168.221.100)

vim metallb-ip-pool.yaml

apiVersion: metallb.io/v1beta1

kind: IPAddressPool

metadata:

  name: example

  namespace: metallb-system

spec:

  addresses:

  - 192.168.221.10-192.168.221.100

---

apiVersion: metallb.io/v1beta1

kind: L2Advertisement

metadata:

  name: example

  namespace: metallb-system

kubectl apply -f metallb-ip-pool.yaml

cat 08-loadbalancer.yaml

apiVersion: v1

kind: Service

metadata:

  name: my-service

spec:

  type: LoadBalancer #指定服务类型为 LoadBalancer

  selector:    

    aihao: haha

  ports:

    - protocol: TCP

      port: 80    #服务暴露的端口(外部访问的端口)

      targetPort: 80  #Pod中应用监听的端口

# 应用yaml文件

kubectl apply -f 08-loadbalancer.yaml

# 检查服务状态,# EXTERNAL-IP #表示负载均衡器的外部 IP 地址,外部用户可以通过该地址访问服务。PORT(S) #显示服务端口和映射的节点端口。

kubectl get svc

NAME         TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE

my-service   LoadBalancer   10.109.77.71    192.168.221.10   80:32179/TCP   26s

# 一旦 EXTERNAL-IP 可用,外部用户可以通过以下方式访问服务:

http://<EXTERNAL-IP>:80或者用自己节点IP+端口号也能访问

# Pod内部也可以用域名来访问

curl my-nodeport-service.default.svc.cluster.local

  • ExternalName:域名转换,给域名起别名,Service通过DNS解析将请求转发到指定的外部域名。

# 配置一个yaml文件

vim 03-externalname.yaml

apiVersion: v1

kind: Service

metadata:

  name: svc1

spec:

  type: ExternalName

  externalName: httpbin.org   #这个可以看到502页面

  ports:

  - name: http

    port: 80

    protocol: TCP

targetPort: 80

# 应用yaml文件

kubectl apply -f 03-externalname.yaml

# 先查看有什么运行的Pod,然后随便进入一个Pod

kubectl exec -it my-web-664c6fd8c-t77gw -- bash

# 验证网站,可以看到网页内容

curl svcl.default.svc.cluster.local

特殊模式:

  • Headless(无IP):Service没有IP,也不做负载均衡,仅返回Pod列表;

vim 09-headless.yaml

---

apiVersion: apps/v1

kind: Deployment

metadata:

  creationTimestamp: null

  labels:

    app: yourapp

  name: yourapp

spec:

  replicas: 3

  selector:

    matchLabels:

      app: yourapp

  strategy: {}

  template:

    metadata:

      creationTimestamp: null

      labels:

        app: yourapp

    spec:

      containers:

      - image: 192.168.57.200:8099/library/nginx:1.24

        name: nginx

---

apiVersion: v1

kind: Service

metadata:

  name: web-service  # Headless Service名称,会在svc显示

  namespace: default

spec:

  clusterIP: None  # 关键:设置为None,声明为Headless Service

  selector:

    app: yourapp  # 关联标签为app=myapp的Pod

  ports:

  - name: http

    port: 80  # 服务端口

targetPort: 80  # Pod内应用监听的端口

kubectl apply -f 09-headless.yaml

Kubernetes中的网络模型:Service、Ingress、Pod通信详解 Pod 间的直接通信、Service 的负载均衡和服务发现,以及 Ingress 的外部访问管理,共同构成了现代微服务架构的基石。这种设计不仅简化了容器的管理,也提高了应用的可扩展性和安全性,为企业级应用提供了强有力的支持。Kubernetes 支持多种网络插件(如 Calico、Flannel、Weave 等),它们实现了网络隔离、网络策略等功能,确保了 Pod 间的安全和效率。Service 是 Kubernetes 中用于抽象一组 Pod 的一种资源,提供了负载均衡和服务发现的功能。 阅读详情

相关推荐

Kubernetes(k8s)集群部署七、k8s网络通信+service扩展ingress(TLS,认证,地址重写)calico网络插件(允许指定pod访问服务,禁止其他namespace访问服务)

k8s网络通信k8s网络通信1.容器间通信2.pod之间的通信2.1同一节点的pod2.2不同节点的pod之间的通信flannel网络原理flannel支持多种后端:3.pod和service通信4.pod和外网通信5.Service与集群外部客户端的通信ingress创建ingress服务:Ingress TLS 配置Ingress 认证配置(认证之前做好加密)Ingress地址重写calico网络插件:能够解决策略 k8s网络通信 k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有fl

ninimino的博客 1302

K8s service

类型主要用于云平台(AWS、阿里云等),云厂商会自动提供外部负载均衡。在裸金属环境中,需要通过MetalLB提供 LoadBalancer 功能。工作原理:创建 LoadBalancer Service 后,MetalLB 会从配置的 IP 地址池中分配一个外部 IP,并通过ARP/NDP 广播宣告该 IP 所属节点。客户端访问该 IP 时,流量进入集群,再由 kube-proxy 转发到后端 Pod。MetalLB ARP 宣告Pod。

kuroomi的博客 206

【K8S系列】第六讲:Kubernetes的网络模型

iptables规则监视发往服务虚拟的流量IP,并从一组可用的Pod中随机选择一个Pod IP地址,并且iptables规则将数据包的目标IP地址从服务的虚拟IP更改为所选Pod的IP。第三个网络是Pod的网络, K8s中一个Pod由多个容器组成,但是一个pod只有一个IP地址,Pod中所有的容器共享同一个IP。为了解决Pod IP地址不是持久性的,可能会进行更改,k8s采用service对pod进行抽象,集群节点所在的网络,这个网络就是你的主机所在的网络,通常情况下是你的网络基础设施提供。

颜淡慕潇 9110

自动化运维之k8s——Kubernetes集群部署、pod、service微服务、kubernetes网络通信

在Docker 作为高级容器引擎快速发展的同时,在Google内部,容器技术已经应用了很多年Borg系统运行管理着成千上万的容器应用。Kubernetes项目来源于Borg,可以说是集结了Borg设计思想的精华,并且吸收了Borg系统中的经验和教训。Kubernetes对计算资源进行了更高层次的抽象,通过将容器进行细致的组合,将最终的应用服务交给用户。kubernetes的本质是一组服务器集群,它可以在集群的每个节点上运行特定的程序,来对节点中的容器进行管理。自我修复。

hyy2795227684的博客 1517

Openwork 入门指南:开源 AI 桌面助手快速上手

Openwork是一款开源的AI桌面代理工具,提供类似Claude Cowork的免费替代方案。它支持本地运行,确保隐私安全,并能高效处理文件整理、文档读写等任务。支持多种AI模型,通过MIT许可完全免费。安装简单,仅需运行命令行或下载桌面版,需配置API Key后即可使用。操作直观,支持多步骤规划和权限控制,适合自动化重复工作。目前主要支持macOS,未来将扩展至Windows/Linux。建议从简单任务入手,逐步掌握这一高效的数字助手工具。

3802

头歌 DNS协议分析第3关----DNS 报文分析

DNS 报文分析

qq_67667368的博客 4344

k8s第三节 Kubernetes网络、Service、Ingress

k8s第三节 Kubernetes网络

dazer的专栏 536

GitLab教程(四):分支(branch)和合并(merge)

命令进行合并时,Git具备一定的智能自动化处理能力:如果一个分支仅修改了文件A,而另一个分支独立地修改了文件B,Git能够无缝整合这些更改,自动完成合并过程——即最终的代码既包含了对A文件的修改也包含了对B文件的修改。同样地,若两个分支虽然都修改了同一个文件,但涉及的是文件中互不重叠的部分,比如一个改动发生在第一行,另一个则在第二行,Git同样能巧妙地自动合并这些非冲突性修改。获取了远程分支的最新变化,或者当你想要合并本地的一个分支到当前分支时,就会用到这个命令。,默认会尝试合并远程分支到当前分支。

TracyCoder的博客 7884

K8s网络实战分析之service调用

在上一篇文章K8s网络实战分析之Calico-ipip模式中,我们通过Pod之间进行ping操作,对基于Calico-IPIP模式的K8s网络进行了实战学习与分析。单单进行Pod-Pod的访问只是K8s的基础功能,基于Service的访问才是K8s的网络核心。本文将基于上一篇文章所搭建的K8s网络,与大家一起探讨,Service访问的IP报文在K8s集群内的流动与原理! #实验准备 为了方便操...

大德如危的博客 3666

基于TI C2000的CCS安装与工程创建完整示例

手把手演示基于TI C2000系列的CCS安装过程及首个工程创建步骤,涵盖环境配置与常见问题处理,助力快速上手嵌入式开发,ccs安装和工程搭建不再难。

weixin_42476987的博客 967

【测试】echo发送和接收TCP/UDP数据包|shell 发送TCP/UDP数据包

目录 通过/dev/tcp、/dev/udp shell给tcp或udp服务发送16进制报文指令 通过/dev/tcp、/dev/udp (https://blog.youkuaiyun.com/u010039418/article/details/86251470) 通过/dev/tcp、/dev/udp可以直接在shell脚本中发起tcp、udp连接,方便又高效,平时用于测试啥的还是挺方便的。 直接发送 格式 /dev/udp/ip/port 比如要向本地10001端口发送数据,可以使用 ec.

我的笔记本 1万+

Kubernetes网络之Service网络(2)

Kubernetes网络之Service网络(2)K8S服务网络实现原理Service网络概念模型DNS方案(Not Adopted)Service RegistryK8S服务发现原理服务发现之K8S方案vs Eureka+Ribbon方案 上一篇:Kubernetes网络之Pod网络(1) K8S服务网络实现原理 上一篇讲解了K8S中4层网络中的Pod网络,Pod网络可以让K8S集群中所有Pods在逻辑上都处于一个平面网络内,可以正常的做IP寻址和通信。 但是Pod是K8S集群中的虚拟机抽象,最终我们在

ryanlll3的博客 663

RK3568平台开发系列讲解(安卓篇)LED呼吸灯系统流程

1.app层封装后使用NotificationManager发出:NotificationManager.notify() 2.Android 系统架构中:一个manager类对应一个aidl接口,一个manager对应一个底层的服务,notification也是这个架构

内核笔记 3644

imaginary容器网络配置:Docker网络与K8s Service完整指南

imaginary是一个快速、简单、可扩展的HTTP微服务,专为高级图像处理而设计。作为Docker-ready的解决方案,它提供了强大的imaginary容器网络配置能力,让开发者能够轻松部署和管理图像处理服务。 ## 🚀 imaginary镜像处理服务简介 imaginary是一个高性能的图像处理微服务,支持智能裁剪、尺寸调整、格式转换等多种功能。通过[Dockerfile](https

gitblog_00989的博客 985

把数据库算力拉满的 ABAP CDS Table Function:从语法、权限到可运行样例的全景解析

文章摘要: 本文针对ABAP开发者探讨了CDS Table Function的应用场景与实现细节。当CDS View无法处理复杂计算(如窗口函数、递归等)时,可通过Table Function将逻辑下推到HANA数据库执行。关键点包括:1)CDS实体声明与AMDP实现的协作关系;2)多租户环境下的Client处理机制(@ClientHandling.type注解);3)激活与传输的阶段性特点可能导致的"暂不可用"问题;4)基于SFLIGHT的完整示例,展示如何定义Client依赖函数、实

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 299

TMS_WebGMaps_1.9.8.0_Full_Source

TMS_WebGMaps_1.9.8.0_Full_Source 全源码 delphi cbuilder

【云计算】【Kubernetes】 ⑤ K8S网络深度解析:从 CNI 到 eBPF,Service 如何实现百万 QPS?

Kubernetes网络是云原生应用的核心通信架构。本文通过“快递包裹”“客服总机”等类比,解析Pod独立IP的设计逻辑、CNI插件(Calico/Flannel/Cilium)的网络构建原理,以及Service如何通过iptables/eBPF实现百万QPS。结合代码示例与性能公式(如eBPF提升50% QPS的推导),系统拆解CNI标准、NetworkPolicy隔离机制及高并发场景的负载均衡策略。适合云原生开发者与运维工程师掌握K8s网络核心脉络。

xiezhiyi007的专栏 1885

jdk-8u144-linux-x64.tar.gz.

该资源为搭建Linux系统Java环境用,资源的后缀为tar.gz格式的压缩包

k8s中的Pod网络;Service网络;网络插件Calico

当执行到创建网络这一步骤时,它首先会读取刚才我们所说的配置目录中的配置文件,配置文件里面会声明所使用的是哪一个插件,然后去执行具体的 CNI 插件的二进制文件,再由 CNI 插件进入 Pod 的网络空间去配置 Pod 的网络。由于Calico是一种纯三层的方案,因此可以避免与二层方案相关的数据包封装的操作,中间没有任何的NAT,没有任何的overlay,所以它的转发效率是所有方案中最高的,因为它的包直接走原生TCP/IP的协议栈,它的隔离也因为这个栈而变得好做。而真正实现和落地这些规范的是CNI插件。

weixin_44681307的博客 2500

android 蓝牙通讯demo

android 下蓝牙通讯demo,实现了发现蓝牙,使能蓝牙,通过蓝牙发送消息。

Statistics and Machine Learning Toolbox

Statistics and Machine Learning Toolbox(带书签),MATLAB统计学习工具

14、k8s面试题(网络)-详细说明 Kubernetes 的网络模型,包括 Pod 网络和 Service 网络

Kubernetes 网络模型通过。

xuebo1129927648的博客 144

kubernetes(2)service、ingress、网络通信及calico

一、service Service可以看作是一组提供相同服务的Pod对外的访问接口。借助Service,应用可以方便地实现服务发现和负载均衡。Service 是由 kube-proxy 组件,加上 iptables 来共同实现的。kube-proxy 通过 iptables 处理 Service 的过程,需要在宿主机上设置相当多的 iptables 规则,如果宿主机有大量的Pod,不断刷新iptables规则,会消耗大量的CPU资源。 1.开启kube-proxy的ipvs模式 在 ipvs 模式下,

weixin_44743132的博客 1559

k8s部署zabbix_zabbix监控k8s(kubernetes)pod到service的网络

文章目录[隐藏]部署sa-tool监控脚本配置key配置监控项最近k8s测试环境不时地出现无法访问一些service endpoint的问题。排查发现是某些节点的kube-proxy没有同步最新的service来配置iptables,至于为什么没有同步service,目前还不知道。不过现在先加对service的监控来及时发现问题,争取到更多时间排查吧。部署sa-toolsa-tool其实就是一个c...

weixin_39814378的博客 814

Kubernetes Service网络层故障排错总结

查看发现kube-proxy中有错误日志如下 failed to list *v1.EndpointSlice: Get "6、该网络还可能会影响kubeedge的安装,会导致如下报错,其主要原因就是上面的路由缺失。curl -k https://10.96.0.1:443 # 连接失败。4、重建kube-proxy成功后可能出现calico错误。# 在所有节点执行(替换 eth0 为您的网卡名)#再次查看calic应创建成功并无报错日志。# 添加 API Server 访问规则。# 检查主机网络路由。

半卷书经的博客 1264

k8s的service网络模型

概述 在 k8s 中我们暴露服务通常需要借助Service来实现,当我们创建了service后,可以看到会分配一个ClusterIP ,本文主要是一个示例介绍ClusterIP 的网络原理 。 这个示例中会创建一个svc , 然后深入的跟踪一下这个svc的网络实现。ClusterIP是通过kube-proxy来维护的,在示例中 kube-proxy 是使用的iptables ,这个方便后续实验观察。 创建service并验证 创建一个nginx的deployment # 创建 deployment ku

俞兆鹏的博客 1万+

云原生技术公开课学习笔记:K8s网络概念及策略控制、Kubernetes Service

十、Kubernetes网络概念及策略控制 1、Kubernetes基本网络模型 因为容器的网络发展复杂性就在于它其实是寄生在Host网络之上的。从这个角度讲,可以把容器网络方案大体分为Underlay/Overlay两大派别: Underlay的标准是它与Host网络是同层的,从外在可见的一个特征就是它是不是使用了Host网络同样的网段、输入输出基础设备、容器的IP地址是不是需要与Host网络取得协同(来自同一个中心分配或统一划分)。这就是Underlay Overlay不一样的地方就在于它并不需要

hxt的博客 1206

深入解析 Kubernetes Service(SVC)网络

在 Kubernetes(k8s)集群中,Pod 是最小的可部署单元,但 Pod 的生命周期是短暂的,IP 也是动态分配的。Kubernetes 中 Pod 可能会被频繁销毁和重建,每次重新创建时,其 IP 地址都会改变。例如,一个微服务架构的 Web 应用,Service 是 Kubernetes 网络的核心,理解其工作机制对于搭建可靠的微服务架构至关重要!资源,它充当一组 Pod 的稳定访问入口,使得集群内部或外部的访问更加高效和稳定。的 Pod IP 是动态变化的,访问,提供稳定的内部服务发现。

XMYX-0 1832
上一篇: K8s资源控制器的实战
下一篇: K8s网络之Ingress
chen_note
博客等级 码龄1年 251粉丝 83原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值