目录
一、ingress简介
二、部署ingress controller、ingress-service
三、创建对外服务deployment和service
四、创建HTTP代理yaml
五、测试
六、公网域名测试
七、参考博客
service的作用体现在两个方面,对集群内部,它不断跟踪pod的变化,利用pod就绪探针更新endpoint中对应pod的对象,提供了ip不断变化的pod的服务发现机制,对集群外部,他类似负载均衡器,可以在集群内外部对pod进行访问。
k8s 对外暴露服务(service)主要有两种方式:NotePort, LoadBalance, 此外externalIPs也可以使各类service对外提供服务,但是当集群服务很多的时候,NodePort方式最大的缺点是会占用很多集群机器的端口,当有几十上百的服务在集群中运行时,NodePort的端口管理是灾难;LB方式最大的缺点则是每个service一个LB又有点浪费、麻烦、烧钱,并且需要k8s之外的云平台支持; 而ingress则只需要一个NodePort或者一个LB就可以满足所有service对外服务的需求。
ingress提供了一种集群维度暴露服务的方式,ingress可以简单理解为service的service,他通过独立的ingress对象来制定域名请求转发的规则,把请求转发到一个或多个service中。这样就把服务与请求规则解耦了,可以从业务维度统一考虑业务的暴露,而不用为每个service单独考虑。
ingress相当于一个7层的负载均衡器,是k8s对反向代理的一个抽象。大概的工作原理也确实类似于Nginx,可以理解成在 Ingress 里建立一个个映射规则 , ingress Controller 通过监听 Ingress里的配置规则并转化成 Nginx 的配置 , 然后对外部提供服务。ingress包括:在这里有两个核心概念:
Ingress:kubernetes中的一个对象,作用是定义请求如何转发到service的规则
ingress controller: 核心是一个deployment,实现方式有很多,比如nginx, Contour, Haproxy,需要编写的yaml有:Deployment, Service, ConfigMap, ServiceAccount(Auth),其中service的类型可以是NodePort或者LoadBalancer。
Ingress(以nginx为例)的工作原理如下:
1、用户编写Ingress规则,说明那个域名对应kubernetes集群中的那个Service
2、Ingress Controller动态感知Ingress服务规则的变化,然后生成一段对应的Nginx反向代理配置
3、Ingress Controller会将生成的nginx配置写入到一个运行着的Nginx服务中,并动态更新
4、到此为止,其实真正在工作的就是一个Nginx了,内部配置了用户定义的请求转发规则
部署ingress controller、ingress-service
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml
mandatory.yaml是多个yaml文件的集合,包含ingress controller的全部资源,由于yaml过长,这里只展示重要的deployment部分,以创建quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0为镜像创建一个位于ingress-nginx命名空间的一个名为nginx-ingress-controller的deployment。
mandatory.yaml的deployment部分
--- apiVersion: apps/v1 kind: Deployment metadata: name: nginx-ingress-controller namespace: ingress-nginx labels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx spec: replicas: 1 selector: matchLabels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx template: metadata: labels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx annotations: prometheus.io/port: "10254" prometheus.io/scrape: "true" spec: # wait up to five minutes for the drain of connections terminationGracePeriodSeconds: 300 serviceAccountName: nginx-ingress-serviceaccount nodeSelector: kubernetes.io/os: linux containers: - name: nginx-ingress-controller image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0 args: - /nginx-ingress-controller - --configmap=$(POD_NAMESPACE)/nginx-configuration - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services - --udp-services-configmap=$(POD_NAMESPACE)/udp-services - --publish-service=$(POD_NAMESPACE)/ingress-nginx - --annotations-prefix=nginx.ingress.kubernetes.io securityContext: allowPrivilegeEscalation: true capabilities: drop: - ALL add: - NET_BIND_SERVICE # www-data -> 101 runAsUser: 101 env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace ports: - name: http containerPort: 80 protocol: TCP - name: https containerPort: 443 protocol: TCP livenessProbe: failureThreshold: 3 httpGet: path: /healthz port: 10254 scheme: HTTP initialDelaySeconds: 10 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 10 readinessProbe: failureThreshold: 3 httpGet: path: /healthz port: 10254 scheme: HTTP periodSeconds: 10 successThreshold: 1 timeoutSeconds: 10 lifecycle: preStop: exec: command: - /wait-shutdown ---
service-nodeport.yaml
apiVersion: v1 kind: Service metadata: name: ingress-nginx namespace: ingress-nginx labels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx spec: type: NodePort ports: - name: http port: 80 targetPort: 80 protocol: TCP - name: https port: 443 targetPort: 443 protocol: TCP selector: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx
创建namespace
[root@k8s-master ingress]# kubectl create ns dev namespace/dev created
创建tomcat-nginx.yaml,创建tomcat和nginx的deployment、service资源,根据labels:app=nginx-pod、labels:app=tomcat-pod绑定。
注意,这是一种特殊的 Service,Headless Service,只要在 Service 的定义中设置了 clusterIP: None,就定义了一个 Headless Service,它与普通 Service 的关键区别在于它没有 ClusterIP 地址, 如果解析 Headless Service 的 DNS 域名, 则返回的是该 Service 对应的全部 Pod 的 Endpoint 列表,这意味着客户端是直接与后端的 Pod 建立 TCP/IP 连接进行通信的, 没有通过虚拟 ClusterIP 地址进行转发, 因此通信性能最高,等同于 "原生网络通信"。
tomcat-nginx.yaml
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment namespace: dev spec: replicas: 3 selector: matchLabels: app: nginx-pod template: metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx:1.17.1 ports: - containerPort: 80 --- apiVersion: apps/v1 kind: Deployment metadata: name: tomcat-deployment namespace: dev spec: replicas: 3 selector: matchLabels: app: tomcat-pod template: metadata: labels: app: tomcat-pod spec: containers: - name: tomcat image: tomcat:8.5-jre10-slim ports: - containerPort: 8080 --- apiVersion: v1 kind: Service metadata: name: nginx-service namespace: dev spec: ports: - port: 80 name: nginx clusterIP: None selector: app: nginx-pod --- apiVersion: v1 kind: Service metadata: name: tomcat-service namespace: dev spec: ports: - port: 8080 name: tomcat clusterIP: None selector: app: tomcat-pod
kubectl apply -f tomcat-nginx.yaml
kubectl get svc -n dev
与普通的service相比,此处的services是没有clusterIP的。
创建 HTTP代理 ingress-http.yaml,这个文件比较重要,每一个host字段表示一个域名,servicePort表示容器服务端口,域名可以自行更改,与后面的hosts文件保持一致就行。
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: ingress-http namespace: dev spec: rules: - host: nginx.itheima.com http: paths: - path: / backend: serviceName: nginx-service servicePort: 80 - host: tomcat.itheima.com http: paths: - path: / backend: serviceName: tomcat-service servicePort: 8080
#创建HTTP代理 kubectl create -f ingress-http.yaml #查询HOST(域名) kubectl get ing ingress-http -n dev #查询详细信息 kubectl describe ing ingress-http -n dev
这里自动分配了30022端口,随机暴露端口30000 ~ 32767,可以定义端口选择范围,但无法定义具体端口。
#查看svc端口 kubectl get svc -n ingress-nginx
添加两行/etc/hosts文件
172.18.60.77 nginx.itheima.com 172.18.60.77 tomcat.itheima.com
测试成功
如果直接用ingress-nginx的ClusterIP访问,404Not Found,因为一个IP的一个端口有多项服务,所以不能直接用IP访问,会出现404。
如果你没有公网域名可跳过这一步,进行公网域名测试。
#编辑HTTP代理yaml kubectl edit ingress ingress-http -n dev
无需设置hosts,直接在任何有网的设备均可测试
如果直接用公网IP:30022访问,会出现404,可以看出外网使用公网IP:30022效果等同于内网使用ingress-nginxIP:80。
若想更改30022端口,编辑service-nodeport.yaml的nodePort属性,默认情况下必须在30000-30656区间。但更改的端口号必须在kube-apiserver配置中的- --service-node-port-range属性,k8s由于怕占用其他端口,默认端口为30000-32767,可以更改kube-apiserver配置,推荐使用1-65535。
kubectl edit svc ingress-nginx -n ingress-nginx
更改为30023
k8s ingress原理及ingress-nginx部署测试_ingrssnginx_GavinYCF的博客-CSDN博客
k8s部署ingress-nginx的方法步骤_人生匆匆的博客-CSDN博客
上一篇:MySQL——复合查询