Tabla de contenido
2. Implementar el controlador de ingreso y el servicio de ingreso
3. Crear servicio e implementación de servicios externos
6. Prueba de nombre de dominio público
1. Introducción al ingreso
La función del servicio se refleja en dos aspectos: para el interior del clúster, realiza un seguimiento de los cambios de pod, utiliza sondas de preparación de pod para actualizar los objetos de pod correspondientes en el punto final y proporciona un mecanismo de detección de servicios para pods con direcciones IP cambiantes. Fuera del clúster, como un equilibrador de carga, se puede acceder a los pods dentro y fuera del clúster.
Hay dos formas principales para que k8s exponga los servicios al mundo exterior: NotePort y LoadBalance. Además, las direcciones IP externas también pueden habilitar varios servicios para proporcionar servicios al mundo exterior. Sin embargo, cuando hay muchos servicios de clúster, la mayor desventaja de la El método NodePort es que ocupará muchos puertos de la máquina del clúster. Cuando hay decenas o cientos de servicios ejecutándose en el clúster, la gestión de puertos de NodePort es un desastre; la mayor desventaja del método LB es que se necesita un LB para cada servicio. un poco derrochador, problemático y costoso, y requiere una nube que no sea compatible con la plataforma k8s; mientras que el ingreso solo necesita un NodePort o un LB para cumplir con los requisitos de servicio externo de todos los servicios.
Ingress proporciona una forma de exponer los servicios en la dimensión del clúster. Ingress puede entenderse simplemente como un servicio de un servicio. Utiliza un objeto de ingreso independiente para formular reglas para reenviar solicitudes de nombres de dominio y reenvía solicitudes a uno o más servicios. De esta forma, las reglas de servicio y solicitud se desacoplan, y la exposición del negocio se puede considerar de manera uniforme desde la dimensión comercial, en lugar de considerar cada servicio por separado.
Ingress es equivalente a un balanceador de carga de 7 capas , que es una abstracción del proxy inverso de k8s. El principio de funcionamiento general es de hecho similar a Nginx, que puede entenderse como el establecimiento de reglas de mapeo en Ingress, y el controlador de ingreso escucha las reglas de configuración en Ingress y las convierte en configuraciones de Nginx, y luego proporciona servicios al exterior. Ingress incluye: Hay dos conceptos básicos aquí:
Ingreso : un objeto en Kubernetes, que define las reglas sobre cómo se reenvían las solicitudes al servicio.
controlador de ingreso : el núcleo es una implementación, y hay muchas formas de implementarlo, como nginx, Contour, Haproxy. El yaml que debe escribirse incluye: Implementación, Servicio, ConfigMap, ServiceAccount (Auth), donde el tipo de El servicio puede ser NodePort o LoadBalancer.
El principio de funcionamiento de Ingress (tomando nginx como ejemplo) es el siguiente:
1. El usuario escribe una regla de Ingress, indicando que el nombre de dominio corresponde al Servicio en el clúster de kubernetes
2. El Controlador de Ingress percibe dinámicamente el cambio de Ingress service rule, y luego genera una configuración de proxy inverso Nginx correspondiente
3. El controlador de ingreso escribirá la configuración nginx generada en un servicio Nginx en ejecución y la actualizará dinámicamente 4.
Hasta este punto, el Nginx de trabajo real es un Nginx con usuario Reglas de reenvío de solicitudes definidas y configuradas internamente.
2. Implementar el controlador de ingreso y el servicio de ingreso
Implementar controlador de ingreso, servicio de ingreso
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
mandato.yaml es una colección de varios archivos yaml, incluidos todos los recursos del controlador de entrada. Dado que el yaml es demasiado largo, aquí solo se muestra la parte de implementación importante para crear quay.io/kubernetes-ingress-controller/nginx-ingress -controller:0.30 .0 crea una implementación denominada nginx-ingress-controller en el espacio de nombres ingress-nginx para la imagen.
La sección de implementación de obligatorio.yaml
---
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
---servicio-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-nginx3. Crear servicio e implementación de servicios externos
crear espacio de nombres
[root@k8s-master ingress]# kubectl create ns dev
namespace/dev createdCree tomcat-nginx.yaml, cree los recursos de implementación y servicio de tomcat y nginx, y vincúlelos según las etiquetas: aplicación = nginx-pod y etiquetas: aplicación = tomcat-pod.
Tenga en cuenta que este es un tipo especial de Servicio, Servicio sin cabeza. Siempre que clusterIP: Ninguno esté establecido en la definición de Servicio, se define un Servicio sin cabeza. La diferencia clave entre este y el Servicio normal es que no tiene una dirección ClusterIP. Si analiza el nombre de dominio DNS del servicio Headless, devuelve la lista de puntos finales de todos los pods correspondientes al servicio, lo que significa que el cliente establece directamente una conexión TCP/IP con el pod de backend para comunicarse sin reenviar a través de la dirección virtual ClusterIP. por lo que el rendimiento de la comunicación es el más alto. Equivalente a la "comunicación de red nativa".
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 devEn comparación con los servicios ordinarios, los servicios aquí no tienen clusterIP .
4. Crear proxy HTTP yaml
Cree el proxy HTTP ingress-http.yaml. Este archivo es más importante. Cada campo de host representa un nombre de dominio y servicePort representa el puerto de servicio del contenedor. El nombre de dominio se puede cambiar solo , siempre que sea coherente con lo siguiente archivo de 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
Aquí se asigna automáticamente el puerto 30022 y se exponen aleatoriamente los puertos 30000 a 32767. El rango de selección del puerto se puede definir, pero el puerto específico no se puede definir.
#查看svc端口
kubectl get svc -n ingress-nginx
5. prueba
Agregue dos líneas al archivo /etc/hosts
172.18.60.77 nginx.itheima.com
172.18.60.77 tomcat.itheima.com
Éxito de la prueba
Si usa directamente el ClusterIP de ingress-nginx para acceder, 404Not Found, porque un puerto de una IP tiene múltiples servicios, por lo que no se puede acceder directamente por IP, y aparecerá 404.
6. Prueba de nombre de dominio público
Si no tiene un nombre de dominio público, puede omitir este paso y realizar una prueba de nombre de dominio público.
#编辑HTTP代理yaml
kubectl edit ingress ingress-http -n dev
No es necesario configurar hosts, se puede probar directamente en cualquier dispositivo en red
Si usa directamente la IP de red pública: 30022 para acceder, aparecerá 404. Se puede ver que usar la IP de red pública: 30022 en la red externa es equivalente a usar ingress-nginxIP: 80 en la red interna .
Si desea cambiar el puerto 30022, edite la propiedad nodePort de service-nodeport.yaml, que debe estar en el rango de 30000-30656 de forma predeterminada. Pero el número de puerto modificado debe estar en el atributo --service-node-port-range en la configuración de kube-apiserver. Debido a que k8s tiene miedo de ocupar otros puertos, el puerto predeterminado es 30000-32767. Puede cambiar el kube-apiserver configuración Se recomienda utilizar 1-65535.
kubectl edit svc ingress-nginx -n ingress-nginx
Cambiar a 30023
