wendu 发表于 2018-1-4 17:21:53

Kubernetes Ingress实战

  本节内容:


[*]服务发现与负载均衡
[*]Ingress实战

一、服务发现与负载均衡
  在前面的安装部署kubernetes集群中已经简单用示例来演示了Pod和Service,Kubernetes通过Service资源在Kubernetes集群内针对容器实现了服务发现和负载均衡。而Service就是kubernetes服务发现与负载均衡中的一种。
  目前,kubernetes中的负载均衡大致可以分为以下几种机制,每种机制都有其特定的应用场景:


[*]Service:直接用Service提供cluster内部的负载均衡,并借助cloud provider提供的LB提供外部访问
[*]Ingress Controller:还是用Service提供cluster内部的负载均衡,但是通过自定义LB提供外部访问
[*]Service Load Balancer:把load balancer直接跑在容器中,实现Bare Metal的Service Load Balancer
[*]Custom Load Balancer:自定义负载均衡,并替代kube-proxy,一般在物理部署Kubernetes时使用,方便接入公司已有的外部服务
  1. Service
  Service是对一组提供相同功能的Pods的抽象,并为它们提供一个统一的入口。借助Service,应用可以方便的实现服务发现与负载均衡,并实现应用的零宕机升级。Service通过标签来选取服务后端,一般配合Replication Controller或者Deployment来保证后端容器的正常运行。这些匹配标签的Pod IP和端口列表组成endpoints,由kube-proxy负责将服务IP负载均衡到这些endpoints上。
  Service有四种类型:


[*]ClusterIP:默认类型,自动分配一个仅cluster内部可以访问的虚拟IP
[*]NodePort:在ClusterIP基础上为Service在每台机器上绑定一个端口,这样就可以 通过 <NodeIP>:NodePort 来访问该服务
[*]LoadBalancer:在NodePort的基础上,借助cloud provider创建一个外部的负载均 衡器,并将请求转发到 <NodeIP>:NodePort
[*]ExternalName:将服务通过DNS CNAME记录方式转发到指定的域名(通 过 spec.externlName 设定)。需要kube-dns版本在1.7以上。
  另外,也可以将已有的服务以Service的形式加入到Kubernetes集群中来,只需要在创建 Service的时候不指定Label selector,而是在Service创建好后手动为其添加endpoint。
  Service虽然解决了服务发现和负载均衡的问题,但它在使用上还是有一些限制,比如


[*]只支持4层负载均衡,没有7层功能
[*]对外访问的时候,NodePort类型需要在外部搭建额外的负载均衡,而LoadBalancer要求kubernetes必须跑在支持的cloud provider上面。
  2. Ingress和Ingress Controller简介
  (1)Ingress
  Ingress就是为了解决这些限制而引入的新资源,主要用来将服务暴露到cluster外面,并且可以自定义服务的访问策略。比如想要通过负载均衡器实现不同子域名到不同服务的访问:
  

foo.bar.com --|               |-> foo.bar.com s1:80  
| 178.91.123.132|
  
bar.foo.com --|               |-> bar.foo.com s2:80
  

  可以这样来定义Ingress:
  

apiVersion: extensions/v1beta1  
kind: Ingress
  
metadata:
  
name: test
  
spec:
  
rules:
  

- host: foo.bar.com  
http:
  
paths:
  

- backend:  
serviceName: s1
  
servicePort:
80  
- host: bar.foo.com
  
http:
  
paths:
  
- backend:
  
serviceName: s2
  
servicePort: 80
  

  【注意】:Ingress本身并不会自动创建负载均衡器,cluster中需要运行一个ingress controller来根据Ingress的定义来管理负载均衡器。
  目前社区提供了 nginx和gce的参考实现
  简单的说,ingress就是从kubernetes集群外访问集群的入口,将用户的URL请求转发到不同的service上。Ingress相当于nginx、apache等负载均衡方向代理服务器,其中还包括规则定义,即URL的路由信息,路由信息得的刷新由Ingress controller来提供。
  (2)Ingress Controller
  Ingress Controller 实质上可以理解为是个监视器,Ingress Controller 通过不断地跟 kubernetes API 打交道,实时的感知后端 service、pod 等变化,比如新增和减少 pod,service 增加与减少等;当得到这些变化信息后,Ingress Controller 再结合下文的 Ingress 生成配置,然后更新反向代理负载均衡器,并刷新其配置,达到服务发现的作用。

二、Ingress实战
  在使用Ingress resource之前,有必要先了解下面几件事情。Ingress是beta版本的resource,在kubernetes1.1之前还没有。你需要一个Ingress Controller来实现Ingress,单纯的创建一个Ingress没有任何意义。
  目前社区提供了 nginx和gce的参考实现。当然还有其他实现,开源的 NGINX 和 NGINX Plus 开发了相应的 Ingress controller。


[*]GCE/GKE会在master节点上部署一个ingress controller。你可以在一个pod中部署任意个自定义的ingress controller。你必须正确地annotate每个ingress,比如 运行多个ingress controller 和 关闭glbc
[*]在非GCE/GKE的环境中,你需要在pod中部署一个controller。
  (1)使用 NGINX 和 NGINX Plus 的 Ingress Controller 进行 Kubernetes 的负载均衡
  https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/complete-example
  

# kubectl create -f nginx-ingress-rbac.yaml  
# kubectl create
-f default-server-secret.yaml  
secret
"default-server-secret" created  
# kubectl create
-f nginx-ingress-rc.yaml  
replicationcontroller
"nginx-ingress-rc" created  

  
# kubectl get pods
-l app=nginx-ingress -o wide  
NAME                     READY   STATUS    RESTARTS   AGE       IP            NODE
  
nginx
-ingress-rc-rs1vh   1/1       Running   0          37s       172.30.87.4   172.16.7.151  

  
# 查看pod日志
  
# kubectl logs nginx
-ingress-rc-rs1vh  
I0924
07:27:37.663514       1 main.go:58] Starting NGINX Ingress controller Version 1.0.0  
2017/09/24 07:27:37 20#20: signal process started
  
I0924 07:27:37.975349       1 event.go:218] Event(v1.ObjectReference{Kind:"Secret", Namespace:"default", Name:"default-server-secret", UID:"4e2d9567-9f5a-11e7-9acc-005056b7609a", APIVersion:"v1", ResourceVersion:"1019701", FieldPath:""}): type: 'Normal' reason: 'Updated' the default server Secret default/default-server-secret was updated
  
2017/09/24 07:27:37 26#26: signal process started
  
2017/09/24 07:27:38 30#30: signal process started
  
2017/09/24 07:27:38 34#34: signal process started
  
2017/09/24 07:27:38 38#38: signal process started
  
I0924 07:27:38.073475       1 event.go:218] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"kube-system", Name:"traefik-web-ui", UID:"5d604da9-9f61-11e7-9acc-005056b7609a", APIVersion:"extensions", ResourceVersion:"1024008", FieldPath:""}): type: 'Normal' reason: 'AddedOrUpdated' Configuration for kube-system/traefik-web-ui was added or updated
  
2017/09/24 07:27:38 44#44: signal process started
  
I0924 07:27:38.100887       1 event.go:218] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"traefik-ingress", UID:"5d693739-9f61-11e7-9acc-005056b7609a", APIVersion:"extensions", ResourceVersion:"1024009", FieldPath:""}): type: 'Normal' reason: 'AddedOrUpdated' Configuration for default/traefik-ingress was added or updated
  

  (2)配置需要测试的service
  部署两个服务nginx 1.7和nginx 1.8:

https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gifhttps://images.cnblogs.com/OutliningIndicators/ExpandedBlockStart.gif  

apiVersion: v1  
kind: Service
  
metadata:
  
name: frontend
  
spec:
  
ports:
  

- port: 80  
targetPort:
80  
selector:
  
app: nginx1
-7  
---
  
apiVersion: apps/v1beta1
  
kind: Deployment
  
metadata:
  
name: nginx1-7-deployment
  
spec:
  
replicas: 2
  
template:
  
metadata:
  
labels:
  
app: nginx1-7
  
spec:
  
containers:
  
- name: nginx
  
image: nginx:1.7.9
  
ports:
  
- containerPort: 80
  


nginx1-7.yaml
https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gifhttps://images.cnblogs.com/OutliningIndicators/ExpandedBlockStart.gif  

apiVersion: v1  
kind: Service
  
metadata:
  
name: my
-nginx  
spec:
  
ports:
  

- port: 80  
targetPort:
80  
selector:
  
app: nginx1
-8  
---
  
apiVersion: apps/v1beta1
  
kind: Deployment
  
metadata:
  
name: nginx1-8-deployment
  
spec:
  
replicas: 2
  
template:
  
metadata:
  
labels:
  
app: nginx1-8
  
spec:
  
containers:
  
- name: nginx
  
image: nginx:1.8
  
ports:
  
- containerPort: 80
  


nginx1-8.yaml  

# kubectl create -f nginx1-7.yaml  
service
"frontend" created  
deployment
"nginx1-7-deployment" created  
# kubectl create
-f nginx1-8.yaml  
service
"my-nginx" created  
deployment
"nginx1-8-deployment" created  

  (3)创建Ingress
  假设这两个服务要暴露到集群外部。要创建一个ingress:
  

# vim test-ingress.yaml  
apiVersion: extensions
/v1beta1  
kind: Ingress
  
metadata:
  
name: test
  
spec:
  
rules:
  

- host: n17.my.com  
http:
  
paths:
  

- backend:  
serviceName: nginx1
-7  
servicePort:
80  
- host: n18.my.com
  
http:
  
paths:
  
- backend:
  
serviceName: nginx1-8
  
servicePort: 80
  

  创建ingress:
  

# kubectl create -f test-ingress.yaml  
ingress
"test" created  
# kubectl get ing
  
NAME            HOSTS                                  ADDRESS   PORTS   AGE
  
test            n17.my.com,n18.my.com
80      52s  

  打开客户机的/etc/hosts,配置172.16.7.151和n17.my.com,n18.my.com的对应关系,然后在浏览器访问n17.my.com或n18.my.com就可以访问到对应的服务。
  如果想修改访问规则,修改test-ingress.yaml,使用kubectl replace -f更新就可以了。
页: [1]
查看完整版本: Kubernetes Ingress实战