K8S networks

一个 POD 中的容器通信

同一个 POD 里面的容器，在同一个共享网络中 可以通过的 localhost，前提是容器将端口映射到了宿主机 也就是 POD

开启共享网络空间后 Container1 和 Container2 可以通过 localhost 直接访问

集群内部之间 POD 的通信

跨容器和跨节点的 POD 通过 K8S 分配的集群内部的 IP 进行通讯

172.25.34.23 可以直接和 172.25.34.29 通信

然后 POD 之间可以直接访问，但是项目不会直接写 POD 的 IP ，主要是有如下问题

1. POD 的生命周期不定，会随时的重建 导致 IP 不定
2. 同一个服务会存在多个 POD，需要进行负载均衡。

解决这个问题 k8s 通过 Service 来抽象一层，当 Service 创建成功后 k8s 就会给 Service 分配一个 Cluster 的 IP，在集群内部服务之间相互调用通过集群 IP 访问，当时 k8s 也提供的集群内部的 DNS 服务，将集群 IP 映射成为 serviceName.namespace:port

服务注册流程

我们会想如何通过的 Cluster IP 访问到具体的 POD 呢？其实 Service 只是对一组 POD 的抽象，没有真实代理和转发服务。我的理解就是将 Cluster IP 和 POD 的关系注册时 k8s 的 master 上去。然后 Client POD 访问具体 POD 时使用客户端负载均衡和路由查找。具体流程如下图

集群外部通信

k8s 有三种方式对外提供服务

port-forward

这种模式直接暴露 POD 的端口，用于测试，不在生产中使用

kubectl port-forward <资源类型>/<资源名> <本机端口>:<资源端口>

Nodeport

将指定端口负载均很转发到 k8s 所有的其中一个 POD,只有一个 POD 接收到请求

apiVersion: v1
kind: Service
metadata:
  name: kubia-nodeport
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30123
  selector:
    app: kubia

Ingress

Ingress 是暴露的 k8s 集群外部的服务

Ingress Controller 负责动态更新配置和负载均衡，通常情况下 Ingress Controller 作为流量的入口，也需要考虑高可用的部署方案

可以选择固定几台 Node 或者为每个 Node 上都部署 IngressController, 在通过其他的负载方案进行 localbalance