本篇按顺序简单介绍 Kubernetes内部Service， Kubernetes Ingress， Kubernetes Istio。
Kubernetes内部Service
ClusterIP, NodePort, ExternalIPs 和 LoadBalancer服务是由kube-proxy或者CNI比如Cilium，Calico提供的。参考 Cilium完全替换kube-proxy
如果创建一个 NodePort 服务，它也会创建一个 ClusterIP 服务。如果创建一个 LoadBalancer，它会创建一个 NodePort，然后创建一个 ClusterIP。
为何要有 Kubernetes内部Service：
上图的情况，若pod-python被销毁并创建了一个新的。（在本文中，我们不讨论如何管理和控制 pod。）突然pod-nginx无法再到达1.1.1.3，有了Service或者说Cluster IP，情况就不一样了。
现在服务只能被集群内部访问了，为了能被外部访问，可以配置NodePort。这样内部服务 python 现在也可以从端口 30080 上的每个节点内部和外部 IP 地址访问。
Kubernetes Ingress
Kubernetes Ingress 不是 Kubernetes 服务。它是一个将请求重定向到其他内部（ClusterIP）服务的 Nginx Pod。
Kubernetes Ingress 能做什么：
和 Kubernetes Service 的工作有点类似。和传统的Nginx工作内容一样，HTTP 协议接收对特定文件路径的请求 和 将 HTTP 协议的请求进行重定向转发并返回他们的响应。
例如可以配置不同的 url /folder /other转发到不同的 Kubernetes Service。
代码语言：javascript复制apiVersion: networking.k8s.io/v1beta1kind: Ingressmetadata:
annotations:
kubernetes.io/ingress.class: nginx
namespace: default
name: test-ingressspec:
rules:
- http:
paths:
- path: /folder
backend:
serviceName: service-nginx
servicePort: 3001
- http:
paths:
- path: /other
backend:
serviceName: service-python
servicePort: 3002 
Kubernetes Istio
Istio 是服务网格，它允许在集群中的 pod 和服务之间进行更详细、复杂和可观察的通信。它将代理容器注入所有 pod，然后控制集群中的流量。
Kubernetes 中的服务由kube-proxy运行在每个节点上的组件实现。该组件创建将请求重定向到 pod 的 iptables 规则。因此，服务只不过是 iptables 规则。（还有其他不使用 iptables 的代理模式可用，但过程相同。参考 Cilium完全替换kube-proxy ）
上图显示了已安装的 Istio，它与 Istio 控制平面一起提供。同样普遍的是，每个 pod 都有一个名为 的第二个容器istio-proxy，它会在创建过程中自动注入到 pod 中。具有 的 pod istio-proxy将不再使用这些kube-proxy组件。
istio-proxy每当配置或服务的 pod 发生更改时，Istio 控制平面都会对所有sidecar 进行配置。类似于 Kubernetes API 对kube-proxy进行配置。Istio 控制平面利用pod ip实现了自己的路由。Istio 会将 Kubernetes 服务声明转换为自己的路由声明。
接下来看看如何使用 Istio 发出请求：
上图中，所有istio-proxy容器都已由 Istio 控制平面进行了配置，并包含所有必要的路由信息。nginx 容器 from pod1-nginx向 service 发出请求service-python。
请求被istio-proxy容器拦截pod1-nginx并重定向到istio-proxy 一个python pod的容器，然后将其重定向到python容器。
可见，Istio 和 Kubernetes内部Service 和 Kubernetes内部Service 有很多重叠的功能，或者说可以是相同需求的多种实现。Istio 相对于 Kubernetes Service 和 Kubernetes Ingress的优势是什么？
所有流量都通过istio-proxy每个 pod 中的容器进行路由。每当istio-proxy接收和重定向请求时，它也会将有关它的信息提交给 Istio 控制平面。因此，Istio 控制平面确切地知道请求来自哪个 pod、存在哪些 HTTP 标头、从一个请求istio-proxy到另一个请求需要多长时间等等。在具有许多相互通信的服务的集群中，这可以提高可观察性并更好地控制所有流量。
具体点的优势有：
- 高级路由：Kubernetes 内部服务只能将服务请求轮询或随机分发到 Pod。使用 Istio 可以实现更复杂的方法。就像根据请求标头重定向一样，如果发生错误或使用最少的服务。
- 部署：它允许将某些百分比的流量路由到某些服务版本，因此允许绿/蓝和金丝雀部署。
- 加密：可以加密pod 之间的集群内部流量 from istio-proxy 到 istio-proxy。
- 监控/图表生成：Istio 连接到 Prometheus 等监控工具。它还可以与 Kiali 一起很好地显示所有服务及其流量。
- 追踪：由于 Istio 控制平面有大量关于请求的数据，因此可以使用 Jaeger 等工具对这些数据进行跟踪和检查。
- 多集群网格：Istio 有一个内部服务注册中心，可以使用现有的 Kubernetes 服务。也可以从集群外部添加资源，甚至可以将不同的集群连接到一个网格中。
总结
综上，所以Istio不是取代 Kubernetes内部服务 的，Istio 使用现有的 Kubernetes 服务来获取其所有端点/pod IP 地址。Istio 是可以取代Kubernetes Ingress的，Istio 提供了新的资源，例如 Gateway 和 VirtualService，甚至还附带了 ingress 转换器istioctl convert-ingress。
