k8s集群外访问集群内pod服务的几种方式

已于 2022-05-25 17:18:59 修改
阅读量6.6k 收藏 9
点赞数 3
分类专栏： k8s 文章标签： kubernetes 容器 云原生
于 2022-05-25 16:09:12 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/tuonian/article/details/124966730
版权

一、hostPort或hostNetwork

此种方式直接将pod内部端口映射到部署pod的主机上，外部访问通过主机IP+端口直接访问pod；

  • hostPort
vim nginx-test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app.name: nginx-test
  template:
    metadata:
      labels:
        app.name: nginx-test
    spec:
      containers:
      - image: nginx:1.21.1
        imagePullPolicy: IfNotPresent
        name: nginx-test
        ports:
        - containerPort: 80
          name: http
          protocol: TCP
          hostPort: 40080                        # 指定hostPort，关键配置
kubectl apply -f nginx-test.yaml

访问测试：

curl http://127.0.0.1:40080
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

  • hostNetwork
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app.name: nginx-test
  template:
    metadata:
      labels:
        app.name: nginx-test
    spec:
      hostNetwork: true                # 使用主机网络
      containers:
      - image: nginx:1.21.1
        imagePullPolicy: IfNotPresent
        name: nginx-test
        ports:
        - containerPort: 80
          name: http
          protocol: TCP

使用主机IP+端口访问；

说明

        此种方式访问集群内pod，需要使用标签固定部署服务的节点，需要关注pod漂移的问题；如果需要关注pod内的负载均衡的话，需要结合外部的LB使用；

二、NodePort

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app.name: nginx-test
  template:
    metadata:
      labels:
        app.name: nginx-test
    spec:
      containers:
      - image: nginx:1.21.1
        imagePullPolicy: IfNotPresent
        name: nginx-test
        ports:
        - containerPort: 80
          name: http
          protocol: TCP

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-test-nodeport
  labels:
    app: nginx-test-nodeport
spec:
  type: NodePort  # Service 类型指定为NodePort,其它如ExternalName,ClusterIP,LoadBalancer
  ports:
  - port: 80      # Service 在集群内部的服务端口                      
    targetPort: 80 # 关联pod对外开放的端口
    nodePort: 31080 # 集群外访问端口，范围为：30000-32767
  selector:
    app.name: nginx-test    # 关联pod的标签

NodePort 访问方式，集群内任意node的ip+NodePort端口号，即可访问；

如上，则为ip:31080 即可访问；

该方式集群内pod已实现负载均衡；

三、云服务器场景（LoadBalancer）

        k8s的service服务包含ClusterIP,NodePort,LoadBalancer,ExternalName,ingress这几种暴露服务的方式；默认只支持4层负载均衡的能力，结合ingress可以实现7层的负载均衡能力；

        LoadBalancer类型的Service，在NodePort类型的基础上，借助cloud provider创建一个外部的负载均衡器，并将请求转发到<NodeIP>:<NodePort>上，此模式只能在云服务器上使用；

        Service是有kube-proxy组件，加上iptables共同作用实现的；kube-proxy通过iptables处理Service的过程中，需要再宿主机上设置很多的iptables规则，如果宿主机有大量的Pod，不断刷新iptables的规则，会消耗大量的CPU资源；可以开始IPVS模式的Service，以支持更多量级的Pod。

apiVersion: v1
kind: Service
metadata:
  name: nginx-test-loadbalancer
  namespace: default
spec:
  externalTrafficPolicy: Cluster
  ports:
  - name: http
    nodePort: 80
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app.name: nginx-test
  sessionAffinity: None
  type: LoadBalancer
#  externalIPs:                # 也可以指定一个外部的IP地址
#  - 192.168.0.6

四、Ingress

        Ingress 生产环境建议使用，作用于nginx类似，需要部署一个ingress-controller的服务，该服务使用以上几种方式提供集群外的访问；再根据业务配置路由规则，访问集群内的其它服务。

1、 安装ingress

下载官方提供的两个问题

https://github.com/kubernetes/ingress-nginx/blob/nginx-0.30.0/deploy/static/mandatory.yaml
https://github.com/kubernetes/ingress-nginx/blob/nginx-0.30.0/deploy/baremetal/service-nodeport.yaml

mandatory.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - "extensions"
      - "networking.k8s.io"
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
      - "networking.k8s.io"
    resources:
      - ingresses/status
    verbs:
      - update

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-nginx"
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - get

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: nginx-ingress-role-nisa-binding
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress-clusterrole-nisa-binding
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      # wait up to five minutes for the drain of connections
      terminationGracePeriodSeconds: 300
      serviceAccountName: nginx-ingress-serviceaccount
      nodeSelector:
        kubernetes.io/os: linux
      containers:
        - name: nginx-ingress-controller
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
          args:
            - /nginx-ingress-controller
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          securityContext:
            allowPrivilegeEscalation: true
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            # www-data -> 101
            runAsUser: 101
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
            - name: https
              containerPort: 443
              protocol: TCP
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          lifecycle:
            preStop:
              exec:
                command:
                  - /wait-shutdown

---

apiVersion: v1
kind: LimitRange
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  limits:
  - min:
      memory: 90Mi
      cpu: 100m
    type: Container

service-nodeport.yaml

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
spec:
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
    - name: https
      port: 443
      targetPort: 443
      protocol: TCP
  externalTrafficPolicy: Cluster

上述编排中的镜像，请根据实际情况更改；如私有镜像仓库的情况下需要进行调整；

在集群master执行

kubectl apply -f mandatory.yaml
kubectl apply -f service-nodeport.yaml

等待安装完成后，将会新增一个命名空间ingress-nginx，请查询该命名空间下pod的svc是否运行正常；

2、部署测试应用

部署以上章节中NodePort 的测试应用即可；

新建Deployment nginx-test 和Service nginx-test-nodeport

Service 类型可调整为ClusterIP

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app.name: nginx-test
  template:
    metadata:
      labels:
        app.name: nginx-test
    spec:
      containers:
      - image: nginx:1.21.1
        imagePullPolicy: IfNotPresent
        name: nginx-test
        ports:
        - containerPort: 80
          name: http
          protocol: TCP

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-test-nodeport
  labels:
    app: nginx-test-nodeport
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 80
  selector:
    app.name: nginx-test

3、新增路由规则

编辑文件ing-test.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  labels:
    nginx.org/client-max-body-size: 50m
  name: nginx-test-ing
  namespace: default
spec:
  rules:
  - host: xxx.xxx.xxx                    # 绑定的域名
    http:
      paths:
      - backend:
          serviceName: nginx-test-nodeport       # Service的名称
          servicePort: 80                        # Service的端口
        path: /test                              # 路径
        pathType: ImplementationSpecific

将域名绑定到master IP，即可通过域名访问: http://xxx.xxx.xxx/test/

tuonian
关注
  • 3
    点赞
  • 踩
  • 9
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
k8s集群外的主机访问pod的解决方案.docx
10-26
k8s集群外的主机访问pod的解决方案.docx
从外部访问K8s中Pod的五种方式
热门推荐
MansonRi
02-13 2万+
hostNetwork、hostPort、NodePort、LoadBalancer、Ingress 暴露Pod与Service一样，因为Pod就是Service的backend     1、hostNetwork：true    在pod中使用该配置，在这种Pod中运行的应用程序可以直接看到pod启动的主机的网络接口。     注：每次pod的IP是会变化的     2、hostPort...
详解k8s集群内外的访问方式
最新发布
tigerhhzz的博客
03-31 1898
Ingress、NodePort和LoadBalancer都是Kubernetes中用于将Service公开到外部的方法，但它们之间有一些区别和适用场景。Ingress：如果需要在同一IP地址和端口上公开多个服务，并根据请求路径或主机名进行路由，则可以使用Ingress。Ingress是Kubernetes中的一个抽象层，它可以将多个Service公开到同一个IP地址和端口上，并根据请求路径或主机名进行路由，非常适合用于Web应用程序。NodePort。
promethues（普罗米修斯）监控k8s集群——详细文档
06-19
promethues（普罗米修斯）监控k8s集群——详细文档，超详细文档总结
MongoDB-in-Kubernetes:在K8s集群中部署的MongoDB Sharded集群
05-02
MongoDB-in-Kubernetes 在K8s集群中部署的MongoDB Sharded集群 用于Shard和Config服务器的Pod的部署： 此处，分片副本集存储实际数据或块（文档集合），而配置服务器副本集存储mongodb集群的元数据和配置信息。 在k8s集群中，我们创建了无头服务和状态集，用于部署分片和配置服务器Pod。 当无头服务与状态集结合使用时，k8s为每个Pod提供一个唯一的DNS名称，该名称解析为Pod的IP地址，即使重新安排Pod的时间，这些名称也不会更改，因此分片或配置服务器中的所有副本集仍然可以互相交流。 在yaml定义中还有其他配置，例如指定pod亲和力，定义就绪/活跃性探针，用于持久卷的卷声明模板以及用于mongodb集群的其他特定于容器的配置。 #shards kubectl create -f mongodbShardReplicaset.y
K8S从懵圈到熟练–集群服务的三个要点和一种实现
02-24
以我的经验来讲，理解K8S集群服务的概念，是比较不容易的一件事情。尤其是当我们基于似是而非的理解，去排查服务相关问题的时候，会非常不顺利。这体现在，对于新手来说，ping不通服务的IP地址这样基础的问题，都很难理解；而就算对经验很丰富的工程师来说，看懂服务相关的iptables配置，也是相当的挑战。概念上来讲，K8S集群的服务，其实就是负载均衡、或反向代理。这跟阿里云的负载均衡产品，有很多类似的地方。和负载均衡一样，服务有它的IP地址以及前端端口；服务后边会挂载多个容器组Pod作为其“后端服务器”，这些“后端服务器”有自己的IP以及监听端口。当这样的负载均衡和后端的架构，与K8S集群结合的时候
【云原生】k8s 中的 hostNetwork 和 NetworkPolicy（网络策略）讲解与实战操作
匠人精神，持之以恒！
11-19 4559
在k8s中，若pod使用主机网络，也就是。则该pod会使用主机的dns以及所有网络配置，默认情况下是无法使用k8s自带的dns解析服务，但是可以修改DNS策略或者修改主机上的域名解析（），使主机可以用k8s自身的dns服务。一般通过DNS策略（Default： 继承Pod所在宿主机的DNS设置，hostNetwork的默认策略。ClusterFirst（默认DNS策略）：优先使用kubernetes环境的dns服务，将无法解析的域名转发到从宿主机继承的dns服务器。
k8s集群外访问集群内部服务的几种方式
椰汁菠萝
06-03 6645
前言 目前k8s+docker算是运维必修了，docker能让我们的环境一键迁移，k8s能自动编排还能保证服务高可用，两者结合自然是无敌了，当然任何技术的使用，都需要根据具体环境来定，就像你要杀鸡，却非要选牛刀，牛刀是很锋利，但还不够你折腾的 本文重点介绍k8s集群外如何访问集群内的服务 一、hostPort或hostNetwork hostPort和host...
在k8s中 ，数据包是怎么从外部流转进入到pod的？
wlzx059的博客
10-24 1026
总之，NodePort Service 将流量路由到集群中的一个节点，然后再根据 Service 的选择器将流量路由到符合条件的 Pod 上，以实现负载均衡。在 Kubernetes 中，当您创建 NodePort 类型的服务时，流量不会直接从主机的 IP 和端口转发到特定 Pod 的 IP 和端口。相反，流量被转发到集群中的一个节点，然后从那里转发到相应的 Pod。总之，发往 NodePort 服务的流量首先发送到集群中的节点，然后根据服务的内部负载均衡机制将其路由到服务后面的某个 Pod。
k8s外部访问pod内部容器的端口-NodePort
生有涯，知无涯
03-20 4671
k8s外部访问pod内部容器的端口-NodePort
K8s集群搭建ansible部署脚本
04-21
我个人给公司开发的使用ansible部署k8s的脚本，支持vagrant调用ansbile，和直接ansible执行两种方式。k8s二进制组件使用最新的1.23.5 部署以下模块内容包括： preinstall 安装前准备，主机环境初始化，二进制文件拷贝 certs 生成集群所需要的ssl证书 master 主节点服务部署，使用systemd服务方式 worker 工作节点服务部署，使用systemd服务方式 addon 包括calico网络dns域名解析服务，dashboard, glusterfs+heketi和nfs存储部署 smoke_test 对环境做冒烟测试，包括 pod访问测试，dns访问测试，pv存储访问测试
企业级容器技术与K8S集群技术实战视频.zip
07-01
目录网盘文件永久链接 01_1_1_docker介绍_安装及要素讲解 02_1_2_Django应用容器化实践 03_1_3_docker实现原理与网络 04_2_1_kubernetes架构_ 05_2_2_使用pod管理业务应用_上_ 06_2_3_使用pod管理业务应用_下_ 07_2_4_kubernetes_workload的使用 08_2_5_kubernetes调度策略 09_2_6_集群服务发现及Ingress的实现服务访问 10_2_7_Kubernetes集群的认证和授权及 11_3_1_使用efk实现k8s集群服务日志采集 12_3_2_fluentd工作原理及参数详解 13_4_1_DevOps及CICD介绍 14_4_2_Jenkins_on_k8s的部署 15_4_3_Jenkins与Gitalb集成示例 16_4_4_Jenkins的Master_Slaves 17_4_5_Pipeline及Jenkinsfile实现 18_4_6_老司机将给运维同学们的话 19_4_7_Jenkinsfile凭据的使用 20_4_8_多分支流水线的使用及........
k8s：使用Ansible Playbook部署Kubernetes高可用性集群
01-31
使用Ansible Playbook进行生产级别的高可用kubernetes扩展部署，包括初始化系统配置，自动签发证书，安装配置等的配置，安装配置haproxy＆keepalive，calico，coredns，metrics-server等，并使用bootstrap方式认证以及kubernetes组件健康检查。额外的支持扩展索引扩展容错，替换证书，kubernetes版本升级等。本Playbook使用二进制方式部署。 配合kubernetes剔除dockershim，本Playbook将运行时修改为containerd。 一，准备文件服务器 1.1，下载二进制包 wget https://storage.googleapis.com/kubernetes-release/release/v1.20.2/kubernetes-server-linux-amd64.tar.gz url中v1.20.2替换为需要下载的版本即可。 1.2，配置文件服务器 安装nginx yum -y install nginx 将文件拷贝nginx目录 tar zxvf kubernetes-server
K8S集群 问题排查解决秘诀
11-18
K8S 集群问题排查解决秘诀主要包括以下几个方面： 理解 K8S 架构：首先，对 Kubernetes 集群的基本架构要有清晰的认识，包括 master 节点、worker 节点、pod、service 等组件之间的关系。了解各个组件的功能和运行原理有助于分析问题。 监控和日志：监控和日志是排查问题的两大法宝。通过查看集群内的监控数据，如 CPU 使用率、内存使用率、网络流量等，可以初步了解哪些节点或容器存在问题。同时，查看容器和节点的日志，可以帮助定位问题根源。 网络通信排查：K8S 集群的网络通信问题较为常见，主要包括 Pod 间通信、Service 通信和跨集群通信等。通过使用网络抓包工具，如 Wireshark，可以捕捉到容器间的通信数据包，进一步分析网络问题。 DNS 排查：DNS 问题可能导致服务无法正常访问。检查 Coredns 或其他 DNS 服务的运行状态，确认 DNS 设置是否正确。
k8s集群pod经常重启问题排查总结.doc
10-29
k8s集群pod经常重启问题排查总结
K8S监控模板，用于k8S集群Pod监控
03-08
K8S监控模板，用于k8S集群Pod监控
kubernetes pod间通信,跨namespace互访
qq_37369726的博客
12-08 8126
这篇文章从原理和操作两部分讲解. 原理 kubernetes pod间通信,也就是pod里面的docker应用之间需要通信,首先就需要互相发现对方. kubernetes使用dns服务作为服务注册中心,kubernetes提供了一个内部的dns服务,集群里面的所有pod和容器都知道它的地址. ...
k8s pod hostNetwork网络模式
qq_15138049的博客
12-03 9142
问题： 往 k8s 搭建的 fastdfs集群上传文件报错、、 ################## fastdfs 参数配置 ################## fdfs: so-timeout: 1501 connect-timeout: 601 tracker-list: # tracker地址 - 192.168.153.131:32122 ### [hadoop@k8s-node-01 fastdfs]$ kubectl get pod -n fastdfs-ns -o
外网访问k8s内部pod
08-24
要使外部网络能够访问 Kubernetes 集群中的 Pod，通常可以使用 Kubernetes Service 和 Ingress Controller。 1. 首先，创建一个 Service 对象来公开 Pod。Service 可以将流量从集群外部路由到 Pod 内部。可以通过以下 YAML 示例创建一个 Service： ```yaml apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 8080 ``` 上述示例将名为 `my-service` 的 Service 创建为 TCP 协议的端口映射，将集群外部的流量路由到具有标签 `app: my-app` 的 Pod 上的端口 8080。 2. 安装和配置 Ingress Controller。Ingress Controller 是负责将外部流量路由到 Service 的组件。常见的 Ingress Controller 有 Nginx Ingress Controller、Traefik、HAProxy 等。 3. 创建一个 Ingress 资源对象，用于定义请求的入口点和路由规则。以下是一个示例 Ingress YAML： ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: myapp.example.com http: paths: - pathType: Prefix path: / backend: service: name: my-service port: number: 80 ``` 上述示例将 Ingress 创建为将流量路由到名为 `my-service` 的 Service 上的规则。可以根据需要自定义 Host、Path 和其他路由规则。 4. 配置 DNS，将 Ingress 路由的域名解析到 Kubernetes 集群的外部 IP 地址或负载均衡器上。 完成上述步骤后，外部网络就可以通过访问 Ingress 定义的域名，从而访问到 Kubernetes 集群内部的 Pod。请注意，具体的实现方式可能因集群环境和网络架构而有所不同。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值