1. Conocimiento sobre Ingress
1.1 Introducción al ingreso
La función del servicio se refleja en dos aspectos. Dentro del clúster, realiza un seguimiento de los cambios de pod, actualiza 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, es similar a un equilibrador de carga, que puede acceder a los pods dentro y fuera del clúster .
En Kubernetes, la dirección IP del Pod y el ClusterIP del servicio solo se pueden usar dentro de la red del clúster y son invisibles para las aplicaciones fuera del clúster. Para permitir que las aplicaciones externas accedan a los servicios en el clúster, Kubernetes actualmente proporciona las siguientes soluciones:
● NodePort : expone los servicios en la red de nodos. Detrás de NodePort está Kube-Proxy, que es un puente para comunicar redes de servicios, redes de pods y redes de nodos.
El entorno de prueba está bien para usar, pero cuando docenas o cientos de servicios se ejecutan en el clúster, la administración de puertos de NodePort es un desastre. Debido a que cada puerto solo puede ser un servicio, el rango de puertos predeterminado solo puede ser 30000-32767.
● LoadBalancer : Asigne a la dirección LoadBalancer proporcionada por el proveedor de servicios en la nube configurando LoadBalancer. Este uso solo se utiliza en el escenario de configuración de un Servicio en la plataforma de nube de un proveedor de servicios de nube pública. Está limitado por la plataforma en la nube y, por lo general, se requieren tarifas adicionales para implementar LoadBalancer en la plataforma en la nube.
Una vez que se envía el servicio, Kubernetes llamará a CloudProvider para crear un servicio de balanceo de carga para usted en la nube pública y configurará la dirección IP del pod con proxy para el servicio de balanceo de carga como backend.
● IPexternas : El Servicio permite asignarle IPs externas.Si las IPs externas se enrutan a uno o más Nodos en el clúster, el Servicio estará expuesto a estas IPs externas. El tráfico que ingresa al clúster a través de la IP externa se enrutará al Endpoint del Servicio.
● Ingreso : con solo una o una pequeña cantidad de IP públicas y LB, se pueden exponer varios servicios HTTP a la red externa al mismo tiempo, proxy inverso de siete capas.
Un servicio que puede entenderse simplemente como un servicio es en realidad un conjunto de reglas que reenvían las solicitudes de los usuarios a uno o más servicios en función de los nombres de dominio y las rutas de URL.
1.2 Composición del Ingreso
●ingress:
ingress es un objeto API, que se configura a través de un archivo yaml.La función del objeto ingress es definir las reglas sobre cómo se reenvían las solicitudes al servicio, lo que puede entenderse como una plantilla de configuración.
Ingress expone los servicios internos del clúster a través de http o https y proporciona servicios con direcciones URL externas, equilibrio de carga, capacidades SSL/TLS y proxy inverso basado en nombres de dominio. El ingreso depende del controlador de ingreso para implementar las funciones anteriores.
●ingress-controller:
ingress-controller es un programa que implementa específicamente proxy inverso y equilibrio de carga, analiza las reglas definidas por el ingreso e implementa el reenvío de solicitudes de acuerdo con las reglas configuradas.
El controlador de entrada no es un componente integrado de k8s. De hecho, el controlador de entrada es solo un término general. Los usuarios pueden elegir diferentes implementaciones de controlador de entrada. Actualmente, los únicos controladores de entrada mantenidos por k8s son GCE e ingress-nginx de Google Cloud. Hay muchos otros controladores de entrada mantenidos por terceros. Para obtener más información, consulte los documentos oficiales. Pero no importa qué tipo de controlador de entrada, el mecanismo de implementación es similar, pero hay diferencias en las configuraciones específicas.
En términos generales, el controlador de ingreso tiene la forma de un pod, que ejecuta un programa daemon y un programa de proxy inverso. El daemon es responsable de monitorear continuamente los cambios en el clúster, generar configuraciones basadas en objetos de ingreso y aplicar nuevas configuraciones al proxy inverso.Por ejemplo, ingress-nginx genera dinámicamente configuraciones nginx, actualiza dinámicamente aguas arriba y recarga el programa para aplicar nuevas configuraciones cuando sea necesario. Para mayor comodidad, los siguientes ejemplos utilizan el ingreso-nginx mantenido oficialmente por k8s como ejemplo .
1.3 Principio de funcionamiento de Ingress-Nginx
(1) El controlador de ingreso interactúa con el APIServer de kubernetes para percibir dinámicamente los cambios en las reglas de ingreso en el clúster.
(2) Luego léalo, de acuerdo con las reglas personalizadas, las reglas son para especificar qué nombre de dominio corresponde a qué servicio y generar una pieza de configuración nginx.
(3) Luego escriba en el pod de nginx-ingress-controller, que ejecuta un servicio Nginx en el pod de ingress-controller, y el controlador escribirá la configuración de nginx generada en el archivo /etc/nginx.conf.
(4) Luego vuelva a cargar para que la configuración surta efecto. De esta manera, se puede lograr el papel de la configuración de distinción de nombres de dominio y la actualización dinámica.
1.4 Controlador de entrada de nueva generación ( Traefik )
Traefik es una herramienta moderna de equilibrio de carga y proxy inverso HTTP que nació para facilitar la implementación de microservicios. Admite múltiples backends (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file...) para aplicar de forma automática y dinámica los ajustes de su archivo de configuración.
Comparación simple de Ingress-nginx e Ingress-Traefik
ingreso-nginx
Utilice nginx como equilibrador de carga de front-end, interactúe continuamente con la API de kubernetes a través del controlador de entrada, obtenga cambios en el servicio de back-end, pod, etc. en tiempo real, luego actualice dinámicamente la configuración de nginx y actualice la configuración para que surta efecto y lograr el propósito del descubrimiento del servicio.
Ingreso-traefik:
Traefik en sí está diseñado para poder interactuar con la API de kubernetes en tiempo real, percibir cambios en los servicios de backend, pods, etc., actualizar configuraciones y recargar automáticamente. En términos relativos, traefik es más rápido y conveniente y, al mismo tiempo, admite más funciones, lo que hace que el proxy inverso y el equilibrio de carga sean más directos y convenientes. (Escrito en lenguaje GO, admite de forma nativa K8S y otras aplicaciones nativas de la nube, con mejor compatibilidad, pero la capacidad de concurrencia es el 60 % de la de ingreso-nginx)
1.5 Cómo se expone Ingress
Método 1: Servicio en modo Deployment+LoadBalancer
Si desea implementar el ingreso en la nube pública, este método es más apropiado. Use Deployment para implementar el controlador de ingreso, cree un servicio de tipo LoadBalancer y asocie este grupo de pods. La mayoría de las nubes públicas crearán automáticamente un equilibrador de carga para el servicio LoadBalancer y, por lo general, vincularán una dirección de red pública. Siempre que la resolución del nombre de dominio apunte a esta dirección, se realiza la exposición externa del servicio de clúster
por ejemplo: tome Alibaba Cloud como ejemplo
Método 2: DaemonSet+HostNetwork+nodeSelector
Use DaemonSet combinado con nodeselector para implementar el controlador de entrada en un nodo específico y luego use HostNetwork para conectar directamente el pod con la red del nodo host y use directamente el puerto 80/433 del host para acceder al servicio. En este momento, la máquina del nodo donde se encuentra el controlador de entrada es muy similar al nodo de borde de la arquitectura tradicional, como el servidor nginx en la entrada de la sala de computadoras. Este método es el más simple de todo el enlace de solicitud y su rendimiento es mejor que el del modo NodePort. La desventaja es que un nodo solo puede implementar un módulo de controlador de ingreso debido al uso directo de la red y el puerto del nodo host. Es más adecuado para grandes entornos de producción simultánea.
Método 3: el servicio en el modo Deployment+NodePort
también implementa el controlador de entrada en el modo de implementación y crea un servicio correspondiente, pero el tipo es NodePort. De esta forma, el ingreso se expondrá en el puerto específico de la ip del nodo del clúster. Dado que el puerto expuesto por nodeport es un puerto aleatorio, generalmente se construye un balanceador de carga al frente para reenviar las solicitudes. Este método generalmente se usa en escenarios donde la dirección IP de la máquina host es relativamente fija.
Si bien es simple y conveniente exponer el ingreso a través de NodePort, NodePort tiene una capa adicional de NAT, que puede tener cierto impacto en el rendimiento cuando el nivel de solicitud es grande.
2. Implemente DaemonSet+HostNetwork para exponer Ingress
2.1 Implementar nginx-Ingress-controller
(1) Descargue el método de configuración yaml del nginx-Ingress oficial
El archivo #mandatory.yaml contiene la creación de muchos recursos, incluido el espacio de nombres, ConfigMap, rol, ServiceAccount, etc. Todos los recursos necesarios para implementar el controlador de entrada.
Dirección oficial de descarga:
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.25.0/deploy/static/mandatory.yaml
puede no estar disponible para descargar, puede usar gitee doméstico
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.25.0/deploy/static/mandatory.yaml
wget https:// gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml
2.2 El proceso de implementación específico de DaemonSet+HostNetwork
Paso 1: Descargue e instale el pod del controlador de ingreso y los recursos relacionados
mkdir /opt/ingress
cd /opt/ingress
#Aquí, por conveniencia, usamos directamente la versión nginx-0.30.0 Si es nginx-0.25.0, puede modificarlo como se indica arriba
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml
Paso 2: agregue una etiqueta al nodo node02
Este paso se debe a que cuando se configura el controlador DaemonSet, se implementará un nodo de pod para cada nodo de nodo Aquí solo quiero hacer un controlador de ingreso
#Especifique que nginx-ingress-controller se ejecute en node02 node
kubectl label node node02 ingress=true
kubectl get nodes --show-labels
#Modifique la implementación a DaemonSet, especifique el nodo para ejecutar y abra la red hostNetwork. Especifique el pod en el nodo 02 a través del selector de etiquetas
vim obligatorio.yaml
...
apiVersion: apps/v1
# Modificar tipo
# tipo:
Tipo de implementación: DaemonSet
metadatos:
nombre: nginx-ingress-controller
espacio de nombres: ingress-nginx
etiquetas:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
spec:
# Delete Replicas
# replicas: 1
selector: etiquetas
de coincidencia:
app.kubernetes.io/name: ingreso-nginx
app.kubernetes.io/part-of: ingress-nginx
plantilla:
metadatos:
etiquetas:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
anotaciones:
prometheus.io/port: "10254"
prometheus.io/scrape: "true"
spec:
# use host network
hostNetwork: true
# Seleccione el nodo para ejecutar
nodeSelect o:
entrada: "true"
serviceAccountName: nginx-ingress-serviceaccount
…
Paso 3: Cargue el paquete de compresión de imágenes nginx-ingress-controller y cárguelo
#Cargue el paquete de compresión de imágenes nginx-ingress-controller inree.contro.tar.gz en el directorio /opt/ingress en todos los nodos, y descomprima y cargue la imagen #Cargue el paquete de compresión de imágenes en el nodo principal cd /opt/ingress tar zxvf inree.contro.tar.gz #Transfiera el paquete de imágenes a otros nodos a través de scp scp inree.contro.tar root@1 92. 168.73.106:/root scp ingree.contro.tar [email protected]:/root #Todos los nodos cargan
el
paquete
de
imágenes
docker
load
-i
ingree.contro.tar
Paso 4: Inicie nginx-ingress-controller y compruebe el estado del pod
kubectl apply -f obligatoria.yaml
//Nginx-ingress-controller se ha estado ejecutando node02 node
kubectl get pod -n ingress-nginx -o wide
kubectl get cm,daemonset -n ingress-nginx -o wide
//Ir al nodo node02 para ver
netstat -lntp | grep nginx
Dado que la red de host está configurada, nginx ya está en el nodo El host escucha localmente puerto 80/443/8181. Entre ellos, 8181 es un backend predeterminado configurado por nginx-controller de forma predeterminada (cuando el recurso de Ingress no tiene un objeto de regla coincidente, el tráfico se dirigirá a este backend predeterminado).
De esta forma, siempre que el host del nodo de acceso tenga una IP pública, puede asignar directamente el nombre de dominio para exponer el servicio a la red externa. Si desea que nginx tenga una alta disponibilidad, puede
implementarlo en varios nodos y crear un conjunto de LVS+keepalived frente a él para equilibrar la carga.
Paso 5: Crea reglas de ingreso
(1) Cree un pod de negocios y un recurso de servicio
vim service-nginx.yaml
apiVersion: apps/v1
tipo: Implementación de
metadatos:
nombre: nginx-app
spec:
réplicas: 2
selector:
matchLabels:
aplicación: nginx
plantilla:
metadatos:
etiquetas:
aplicación: nginx
spec:
contenedores:
- nombre: nginx
imagen: nginx:1.14
imagePullPolicy: IfNotPresent
puertos:
- containerPort: 80
---
apiVersion: v1
tipo: Servicio
metadatos:
nombre: nginx-app-svc
especificación:
tipo:
puertos ClusterIP:
- protocolo: puerto TCP
: 80
targetPort: 80
selector:
aplicación: nginx
kubectl apply -f service-nginx.yaml
2) Crear un recurso de ingreso
//Crear ingreso
#Método 1: (extensiones/v1beta1 Ingress quedará obsoleto en la versión 1.22 pronto)
vim ingress-app.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx-app-ingress
spec:
rules:
- host: www.test.com
http:
paths:
- path: /
backend:
serviceName: nginx-app-svc
service Puerto: 80 #
Método 2:
vim ingress-app.yaml
apiVersion: networking.k8s.io/v1
tipo: Metadatos de ingreso
:
nombre: nginx-app-ingress
spec:
reglas:
- host: www.test.com
http:
rutas:
- ruta: /
pathType: prefijo
backend:
servicio:
nombre: nginx-app-svc
puerto:
número: 80
kubectl apply -f ingress-app.yaml
Prueba de acceso:
#Seleccione un cliente, agregue directamente la IP del nodo de node02 y el nombre de dominio del pod para mapear
vim /etc/hosts
192.168.73.107 www.test.com
curl www.test.com
#Ingrese el pod del controlador de ingreso
kubectl exec -it nginx-ingress-controller-mvgn9 -n ingress-nginx /bin/bash
less /ect/nginx/nginx.conf
//Puede ver que este nombre de dominio se usa para la configuración del proxy inverso desde el servidor de inicio www.kgc.com hasta el servidor final www.kgc.com
3. Servicio en modo Deployment+NodePort
3.1 Implementar el Servicio en modo Implementación+NodePort
Paso 1: descargue las plantillas de entrada y de puerto de nodo de servicio relacionadas
mkdir /opt/ingress/test
cd /opt/ingress/test
#官方下载地址：
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml
#国内 gitee 资源地址：
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml
#在所有 node 节点上传镜像包 ingress-controller-0.30.0.tar 到 /opt/ingress-nodeport 目录，并加载镜像
docker load -i ingress-controller-0.30.0.tar
Paso 2: Inicie la plantilla oficial directamente y utilícela
kubectl apply -f obligatorio.yaml
kubectl apply -f service-nodeport.yaml
#//Si falla la programación de K8S Pod, cuando kubectl describe el recurso de pod:
Advertencia FailedScheduling 18s (x2 over 18s) default-scheduler 0/2 nodos disponibles: 2 nodos no coinciden Solución del selector de nodos: 1. Agregue la etiqueta correspondiente al nodo que debe programarse # En comparación con el ejemplo del archivo Yaml anterior, kubectl label nodes node_name kubernetes.io/os=linux 2. Elimine el nodeSelector en el archivo Yaml Si no hay ningún requisito para el nodo, simplemente
elimine
el
selector
de
nodo
3.2 Demostración del funcionamiento del acceso proxy Http de Ingress
#创建 deployment、Service、Ingress Yaml 资源
vim ingress-nginx.yaml
apiVersion: apps/v1
type: Deployment
metadata:
name: nginx-app
spec:
replicas: 2
selector:
matchLabels:
name: nginx
template:
metadata:
tags:
name: nginx
spec :
containers:
- name: nginx
image: nginx:1.14
imagePullPo licy: IfNotPresent
puertos:
- containerPort: 80
---
apiVersion: v1
tipo: Servicio
metadatos:
nombre: nginx-svc
spec:
puertos:
- puerto: 80
targetPort: 80
protocolo: TCP
selector:
nombre: nginx
---
apiVersion: networking.k8s.io/v1
tipo: Ingress
metadata:
nombre: nginx-test
spec:
reglas:
- host: www.test.com
http:
rutas:
- ruta: /
pathType: Prefijo
backend:
servicio:
nombre: nginx-svc
puerto:
número: 80
-------------------------------------------------------------------------------------------
#host El nombre de host puede ser una coincidencia exacta, o se puede hacer coincidir usando comodines, pero los comodines solo cubren una etiqueta DNS (p. ej., *.foo.com no coincide con baz.bar.foo.com).
Hay tres tipos de ruta compatibles con #pathType:
●ImplementationSpecific: para este tipo de ruta, el método de coincidencia depende de IngressClass. Las implementaciones pueden tratarlo como un pathType separado o de la misma manera que los tipos Prefix o Exact.
●Exacto: haga coincidir exactamente la ruta de la URL y distingue entre mayúsculas y minúsculas.
● Prefijo: coincidencias basadas en prefijos de ruta de URL separados por /. La coincidencia distingue entre mayúsculas y minúsculas. No coincidirá si el último elemento de la ruta es una subcadena del último elemento en la ruta solicitada (p. ej.: /foo/bar coincide con /foo/bar/baz, pero no con /foo/barbaz).
Para obtener más información, consulte: https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/#the-ingress-resource
----------------------------------------------------------------------------------------------
kubectl apply -f ingress-nginx.yaml
3.3 Host virtual de acceso de proxy HTTP de ingreso
Sabemos que nginx y apache pueden configurar tres hosts virtuales, a saber: según la IP, según el nombre de dominio y según el puerto. Del mismo modo, ingress-nginx también puede configurar estos tres hosts virtuales aquí. A continuación, se tomará el host virtual basado en nombre de dominio más utilizado como ejemplo para demostrar la operación.
（1）设置虚拟主机1资源
vim deployment1.yaml
apiVersion: apps/v1
tipo: Implementación de
metadatos:
nombre: deployment1
spec:
réplicas: 1
selector:
matchLabels:
nombre: nginx1
plantilla:
metadatos:
etiquetas:
nombre: nginx1
spec:
contenedores:
- nombre: nginx1
imagen: nginx:1.14
imagePullPo licy: IfNotPresent
puertos:
- containerPort: 80
---
apiVersion: v1
tipo: Servicio
metadatos:
nombre: svc-1
spec:
puertos:
- puerto: 80
targetPort: 80
protocolo: TCP
selector:
nombre: nginx1
kubectl apply -f deployment1.yaml
(2) Crear un recurso de host virtual 2
vim deployment2.yaml
apiVersion: apps/v1
tipo:
Metadatos de implementación:
nombre: deployment2
spec:
réplicas: 1
selector:
matchLabels:
nombre: nginx2
plantilla:
metadatos:
etiquetas:
nombre: nginx2
spec:
contenedores:
- nombre: nginx2
image: nginx:1.14
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
nombre : svc-2
spec:
puertos:
- puerto: 80
targetPort: 80
protocolo: TCP
selector:
nombre: nginx2
kubectl apply -f deployment2.yaml
(3) Crear recurso de ingreso
vim ingress-nginx.yaml
apiVersion: networking.k8s.io/v1
tipo: Ingress
metadata:
nombre: ingress1
spec:
rules:
- host: www.test.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: svc-1
port:
number: 80
---
apiVersion: networking.k8s.io/v1
type: Ingress
metadata:
name: ingress2
spec:
rules:
- host: www.abc.com
http:
rutas:
- ruta: /
pathType: prefijo
backend:
servicio:
nombre: svc-2
puerto:
número: 80
kubectl apply -f ingress-nginx.yaml
cliente para acceso de prueba
vim /etc/hosts
#Aquí puede completar cualquier IP de un nodo nodo
192.168.50.25 www.test.com www.abc.com
3.4 Acceso de proxy HTTPS de ingreso
(1) Cree un certificado SSL para el almacenamiento de recursos secretos
#yum install openssl
yum install -y openssl
#create ssl certificate
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginxsvc/O=nginxsvc" #create secret
resource for storage
kubectl create secret tls tls - secreto --key=tls.key --cert=tls.crt
(2) Crear recursos de despliegue, servicio e ingreso de Yaml
vim ingress-https.yaml
apiVersion: apps/v1
tipo:
Metadatos de implementación:
nombre: nginx-app
spec:
réplicas: 2
selector:
matchLabels: nombre: plantilla
nginx : metadatos: etiquetas: nombre: nginx spec: contenedores: - nombre: nginx imagen: nginx:1.14 imagePullPolicy: puertos IfNotPresent : - containerPort: 80 --- apiVersion: v1 tipo: Servicio metadatos: nombre: nginx-svc spec: puertos: - puerto: 80
targetPort: 80
protocol: TCP
selector:
name: nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nginx-https
spec:
tls:
- hosts:
- www.asd.com
secretName: tls-secret
rules:
- host: www.asd.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx-svc
port:
number: 80
kubectl apply -f ingreso-https.yaml
3.5 Autenticación nginxBasicAuth empresarial de pod de configuración de ingreso
(1) Genere un archivo de autenticación de contraseña de usuario y cree un recurso secreto para el almacenamiento
#Generar archivo de autenticación de contraseña de usuario, crear recurso secreto para almacenamiento
yum -y install httpd-tools
htpasswd -c auth zhangsan #El nombre del archivo de autenticación debe ser auth
kubectl create secret generic basic-auth --from-file=auth
(2) Crear un recurso de ingreso
vim ingress-auth.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
nombre: ingress-auth
anotaciones:
#Establecer el tipo de autenticación básico
nginx.ingress.kubernetes.io/auth-type: basic
#Establecer el nombre del recurso secreto basic-auth
nginx.ingress.kubernetes.io/auth-se cret: basic-auth
#Establecer la información de solicitud de la ventana de autenticación
nginx.ingres s.kubernetes.io/auth-realm: 'Autenticación requerida - zhangsan'
especificación:
reglas:
- host: www.asd.com
http:
rutas:
- ruta: /
pathType: Prefijo
backend:
servicio: nombre: puerto
nginx-svc :
número: 80
(3) Crear pods y recursos de servicio
apiVersion: apps/v1
tipo: Implementación de
metadatos:
nombre: nginx-app
spec:
réplicas: 1
selector:
matchLabels:
nombre: nginx
plantilla:
metadatos:
etiquetas:
nombre: nginx
spec:
contenedores:
- nombre: nginx
imagen: nginx:1.14
imagePullPolicy: IfNotPresent
puertos: -
containerPort: 80
---
apiVersion: v1
tipo: Service
metadata: nombre: nginx- especificación
de svc : puertos: - puerto: 80 targetPort: 80
protocolo: TCP
selector:
nombre: nginx
Haga una prueba de acceso de cliente:
3.6 Configurar la reescritura de nginx en Ingress
Instrucciones de configuración de #metadatos.anotaciones
nginx.ingress.kubernetes.io/rewrite-target: <cadena> #URI de destino donde se debe redirigir el tráfico
nginx.ingress.kubernetes.io/ssl-redirect: <boolean> #Indica si la parte de la ubicación solo es accesible para SSL (el valor predeterminado es verdadero cuando Ingress contiene un certificado) nginx.ingress.kubernetes.io/force-ssl-redirect: <bo olean> #incluso si Ingress no está habilitado para TLS, también fuerce la redirección a HTTPS nginx.ingress.kubernetes.io/app-root: <string> #Define la raíz de la aplicación que el controlador debe redirigir si está en un contexto '/' nginx.ingress.kubernetes.io/use-regex: <Boolean> #Indica si la ruta definida en Ingress usa
una
expresión
regular
Realice una demostración de demostración:
Agregamos un pod http y un recurso svc, ingreso (www.asd.com). Luego escriba el ingreso de reescritura
(1) Reescribir a la creación de recursos
vim ingress-nginx.yaml
apiVersion: apps/v1
tipo: Implementación
de metadatos:
nombre: nginx-app
spec:
réplicas: 1
selector:
matchLabels:
nombre: nginx
plantilla:
metadatos:
etiquetas:
nombre: nginx
spec:
contenedores:
- nombre: nginx
imagen: nginx:1.14
imagePullPolicy: puertos IfNotPresent : - containerPort: 80 --- apiVersion: v1 tipo : Metadatos del servicio : nombre: nginx-svc spec:
puertos : - puerto: 80
targetPort: 80
protocol: TCP
selector:
name: nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
name: nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nginx-test
spec:
rules:
- host: www.asd.com
http:
paths:
- path: /
pathType: Prefijo
backend:
servicio:
nombre: puerto nginx-svc
:
número: 80
kubectl apply -f ingreso-nginx.yaml
2) Reescribir la edición del recurso de ingreso
vim write-ingress.yaml
apiVersion: networking.k8s.io/v1
tipo: Ingress
metadata:
nombre: nginx-rewrite
anotaciones:
nginx.ingress.kubernetes.io/rewrite-target: http://www.asd.com:31019
spec:
rules:
- host: www.write.com http: path s: - path: / pathType: Prefix backend: #Since
www.rewrite.com is solo se usa para saltar y no requiere la existencia de un sitio real, el nombre del recurso svc se puede definir libremente servicio: nombre: nginx-svc puerto: número: 80 kubectl apply -f write - ingress.yaml
Realizar pruebas de acceso de clientes
#Agregar mapeo en el cliente
echo "192.168.73.107 www.write.com">>/etc/hosts
Resumir
ingress的使用：
DaemonSet + host网络模式 部署ingress-controller：
客户端(防火墙，前端负载均衡器) -> Node节点的80或443端口（ingress-controller，host网络模式下节点主机与Pod共享网络命名空间） -> 业务Pod的Service -> 业务Pod
Deployment + Service(NodePort) 部署：
客户端(防火墙，前端负载均衡器) -> ingress-controller的Service（NodeIP:NodePort） -> ingress-controller（以Pod形式运行） -> 业务Pod的Service -> 业务Pod
ingress的配置：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 资源名称
spec:
rules:
- host: 域名（可以精确匹配或通配符匹配，比如 *.kgc.com 可以匹配www.kgc.com或mail.kgc.com等，但不能匹配ky22.www.kgc.com）
http:
paths:
- path: 域名后的URL路径（比如 / 代表网页根路径，或者 /test）
pathType: Prefix|Exact (Exact se usa para la coincidencia exacta de la ruta URL; Prefix se usa para la coincidencia de prefijos y solo puede coincidir con cadenas de caracteres completas, /test/abc puede coincidir con /test/abc/123, pero no con /test/abc123) backend: servicio: nombre: especifique el nombre del puerto SVC: número: especifique el puerto del SVC especificación de reenvío de proxy basado en el nombre de dominio: reglas: - host: nombre de dominio 1 http: .... - host: nombre de dominio 2 http: .... Pro reenvío xy basado en la especificación de ruta de URL: reglas: - host: http: rutas: - ruta: ruta de URL 1 .... - ruta : ruta de URL
2 .... Reenvío de proxy https Emita primero el certificado TLS y el archivo de clave privada
创建 tls 类型的 Secret 资源，把证书和私钥信息保存到 Secret 资源中
创建 ingress 资源，调用 tls 类型的 Secret 资源
spec:
tls:
- hosts:
- 指定使用https的域名
secretName: 指定tls_Secret资源名称
rules:
....
basic-auth 访问认证
创建 Opaque 类型的 Secret 资源，把basic认证文件内容保存到 Secret 资源中
创建 ingress 资源
metadata:
annotations:
nginx.ingress.kubernetes.io/auth-type: basic
nginx.ingress.kubernetes.io/auth-secret: 指定保存basic认证文件内容的Secret资源
nginx.ingress.kubernetes.io/auth-realm: '指定提示信息'
rewrite 重写
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: 指定要跳转的目标域名或URL路径
http|https://<nombre de dominio>:<puerto de svc del controlador de entrada>