kubenretes中暴露Pod及Service的6种方式 ，分别为port_forward、hostNetwork、hostPort、nodePort、loadBalancer、Ingress。

port_forward

将本地网络端口转发到pod中的端口
例如以下命令会将机器的本地端口 8888转发到我们的kubia-manual pod的端口8080:
kubectl port-forward kubia-manual 8888:8080

image.png

k8s-"hostNetwork: true"网络

这是一种直接定义Pod网络的方式。
如果在POD中使用"hostNetwork: true"配置网络，pod中运行的应用程序可以直接看到宿主主机的网络接口，宿主机所在的局域网上所有网络接口都可以访问到该应用程序及端口。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      # 使用主机网络
      hostNetwork: true
      # 该设置是使POD使用k8s的dns，dns配置在/etc/resolv.conf文件中
      # 如果不加，pod默认使用所在宿主主机使用的DNS，这样会导致容器
      # 内不能通过service name访问k8s集群中其他POD    
      dnsPolicy: ClusterFirstWithHostNet
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

可以看到pod IP和节点IP是相同的

image.png

一般情况下除非您知道需要某个特定应用占用特定宿主机上的特定端口时才使用hostNetwork: true的方式

hostPort

这是一种直接定义Pod网络的方式。
hostPort是直接将容器的端口与所调度的节点上的端口路由，这样用户就可以通过宿主机的IP加上端口来访问Pod

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      dnsPolicy: ClusterFirstWithHostNet
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
          hostPort: 80

image.png

因为Pod重新调度的时候该Pod被调度到的宿主机可能会变动，用户必须自己维护一个Pod与所在宿主机的对应关系。
这种网络方式可以用来做 nginx [Ingress controller]。外部流量都需要通过kubenretes node节点的80和443端口

nodePort

Kubernetes中的service默认情况下都是使用的ClusterIP这种类型，这样的service会产生一个ClusterIP，这个IP只能在集群内部访问，要想让外部能够直接访问service，需要将service type修改为 nodePort。
在某些场景下我们可以使用 Kubernetes 的 Proxy 模式来访问服务，比如调试服务时。网络模型如下：

image.png

NodePort 服务是引导外部流量到你的服务的最原始方式。NodePort，正如这个名字所示，在所有节点（虚拟机）上开放一个特定端口，任何发送到该端口的流量都被转发到对应服务。如果需要达到负载均衡，外面可能需要挂一个nginx
NodePort 服务特征如下：
每个端口只能是一种服务
端口范围只能是 30000-32767（用--service-node-port-range定义）
不在 YAML 配置文件中指定则会分配一个默认端口
网络模型如下所示：

image.png

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  type: NodePort
  ports:
  - name: http
    port: 80
    targetPort: 80
    protocol: TCP
    nodePort: 8400

集群外就可以使用kubernetes任意一个节点的IP加上8400端口访问该服务了。kube-proxy会自动将流量以round-robin的方式转发给该service的每一个pod。
这种服务暴露方式，无法让你指定自己想要的应用常用端口，不过可以在集群上再部署一个反向代理作为流量入口。

LoadBalancer

LoadBalancer 只能在service上定义。这是公有云提供的负载均衡器，如tke、AWS、Azure、CloudStack、GCE等。
LoadBalancer 服务是暴露服务到 Internet 的标准方式。所有通往你指定的端口的流量都会被转发到对应的服务。它没有过滤条件，没有路由等。这意味着你几乎可以发送任何种类的流量到该服务，像 HTTP，TCP，UDP，WebSocket，gRPC 或其它任意种类
网络模型如下所示：

image.png

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 80
    protocol: TCP

内部可以使用ClusterIP加端口来访问服务，如19.97.121.42:8086。
外部可以用以下两种方式访问该服务：
1、使用任一节点的IP加30051端口访问该服务
2、使用EXTERNAL-IP来访问，这是一个VIP，是云供应商提供的负载均衡器IP，如10.13.242.236:8086。

Ingress

Ingress是自kubernetes1.1版本后引入的资源类型。必须要部署Ingress controller才能创建Ingress资源，Ingress controller是以一种插件的形式提供。Ingress controller 是部署在Kubernetes之上的Docker容器。它的Docker镜像包含一个像nginx或HAProxy的负载均衡器和一个控制器守护进程。控制器守护程序从Kubernetes接收所需的Ingress配置。它会生成一个nginx或HAProxy配置文件，并重新启动负载均衡器进程以使更改生效。换句话说，Ingress controller是由Kubernetes管理的负载均衡器。
Kubernetes Ingress提供了负载平衡器的典型特性：HTTP路由，粘性会话，SSL终止，SSL直通，TCP和UDP负载平衡等。目前并不是所有的Ingress controller都实现了这些功能，需要查看具体的Ingress controller文档。
网络模型 如下所示：

image.png

腾讯tke支持的service方式

image.png

Ingress为管理对外服务到集群内服务之间规则的集合，能把集群内 Service 配置成外网能够访问的 URL，提供基于域名的访问

参考文档&链接

关于在kubenretes中暴露Pod及服务的5种方式
外部访问k8s内部网络的方式
Service如何对外提供服务-Ingress