k8s部署ingress-nginx步骤
k8s部署ingress应用 部署ingress 部署ingress-nginx ingress详细解析
目录
二、部署ingress controller、ingress-service
一、ingress简介
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
部署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
三、创建对外服务deployment和service
创建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代理yaml
创建 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博客
更多推荐
所有评论(0)