更新 kubernetes-Service详解.md
This commit is contained in:
parent
276976f553
commit
07c52b76bf
@ -8,11 +8,11 @@
|
||||
|
||||
为了解决这个问题，kubernetes提供了Service资源，Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到后面的pod服务。
|
||||
|
||||
|
||||
|
||||
|
||||
Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行着一个kube-proxy服务进程。当创建Service的时候会通过api-server向etcd写入创建的service的信息，而kube-proxy会基于监听的机制发现这种Service的变动，然后它会将最新的Service信息转换成对应的访问规则。
|
||||
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
# 10.97.97.97:80 是service提供的访问入口
|
||||
@ -35,19 +35,19 @@ kube-proxy目前支持三种工作模式：
|
||||
|
||||
userspace模式下，kube-proxy会为每一个Service创建一个监听端口，发向Cluster IP的请求被Iptables规则重定向到kube-proxy监听的端口上，kube-proxy根据LB算法选择一个提供服务的Pod并和其建立链接，以将请求转发到Pod上。 该模式下，kube-proxy充当了一个四层负责均衡器的角色。由于kube-proxy运行在userspace中，在进行转发处理时会增加内核和用户空间之间的数据拷贝，虽然比较稳定，但是效率比较低。
|
||||
|
||||
|
||||
|
||||
|
||||
### 2. iptables 模式
|
||||
|
||||
iptables模式下，kube-proxy为service后端的每个Pod创建对应的iptables规则，直接将发向Cluster IP的请求重定向到一个Pod IP。 该模式下kube-proxy不承担四层负责均衡器的角色，只负责创建iptables规则。该模式的优点是较userspace模式效率更高，但不能提供灵活的LB策略，当后端Pod不可用时也无法进行重试。
|
||||
|
||||
|
||||
|
||||
|
||||
### 3. ipvs 模式
|
||||
|
||||
ipvs模式和iptables类似，kube-proxy监控Pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高。除此以外，ipvs支持更多的LB算法。
|
||||
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
# 此模式必须安装ipvs内核模块，否则会降级为iptables
|
||||
@ -222,7 +222,7 @@ Endpoint是kubernetes中的一个资源对象，存储在etcd中，用来记录
|
||||
|
||||
一个Service由一组Pod组成，这些Pod通过Endpoints暴露出来，Endpoints是实现实际服务的端点集合。换句话说，service和pod之间的联系是通过endpoints实现的。
|
||||
|
||||
|
||||
|
||||
|
||||
**负载分发策略**
|
||||
|
||||
@ -346,7 +346,7 @@ service-headliness.dev.svc.cluster.local. 30 IN A 10.244.2.2
|
||||
|
||||
在之前的样例中，创建的Service的ip地址只有集群内部才可以访问，如果希望将Service暴露给集群外部使用，那么就要使用到另外一种类型的Service，称为NodePort类型。NodePort的工作原理其实就是将service的端口映射到Node的一个端口上，然后就可以通过NodeIp:NodePort来访问service了。
|
||||
|
||||
|
||||
|
||||
|
||||
创建service-nodeport.yaml
|
||||
|
||||
@ -381,13 +381,13 @@ service-nodeport NodePort 10.104.5.98 <none> 80:30002/TCP 15s
|
||||
|
||||
LoadBalancer和NodePort很相似，目的都是向外部暴露一个端口，区别在于LoadBalancer会在集群的外部再来做一个负载均衡设备，而这个设备需要外部环境支持的，外部服务发送到这个设备上的请求，会被设备负载之后转发到集群中。
|
||||
|
||||
|
||||
|
||||
|
||||
### 7. ExternalName 类型的 Service
|
||||
|
||||
ExternalName类型的Service用于引入集群外部的服务，它通过externalName属性指定外部一个服务的地址，然后在集群内部访问此service就可以访问到外部的服务了。
|
||||
|
||||
|
||||
|
||||
|
||||
创建service-externalname.yaml
|
||||
|
||||
@ -423,7 +423,7 @@ www.a.shifen.com. 5 IN A 39.156.70.239
|
||||
|
||||
基于这种现状，kubernetes提供了Ingress资源对象，Ingress只需要一个NodePort或者一个LB就可以满足暴露多个Service的需求。工作机制大致如下图表示：
|
||||
|
||||
|
||||
|
||||
|
||||
实际上，Ingress相当于一个7层的负载均衡器，是kubernetes对反向代理的一个抽象，它的工作原理类似于Nginx，可以理解成在Ingress里建立诸多映射规则，Ingress Controller通过监听这些配置规则并转化成Nginx的反向代理配置 , 然后对外部提供服务。在这里有两个核心概念：
|
||||
|
||||
@ -437,7 +437,7 @@ Ingress（以Nginx为例）的工作原理如下：
|
||||
3. Ingress控制器会将生成的Nginx配置写入到一个运行着的Nginx服务中，并动态更新
|
||||
4. 到此为止，其实真正在工作的就是一个Nginx了，内部配置了用户定义的请求转发规则
|
||||
|
||||
|
||||
|
||||
|
||||
## 五：Ingress使用
|
||||
|
||||
@ -451,7 +451,7 @@ Ingress（以Nginx为例）的工作原理如下：
|
||||
|
||||
为了后面的实验比较方便，创建如下图所示的模型
|
||||
|
||||
|
||||
|
||||
|
||||
创建tomcat-nginx.yaml
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user