Что такое Ingress и Ingress Controller?
Мы предоставляем услуги внутри кластера kubernetes внешнему миру для доступа к следующим проблемам:
1. Проблема смещения контейнера
Kubernetes имеет мощные возможности управления репликами, которые могут гарантировать, что новая реплика (Pod) автоматически запускается с других машин при зависании какой-либо реплики (Pod), а также ее можно динамически расширять. С точки зрения непрофессионала, этот Pod может появляться на любом узле. Он также может умереть на любом узле в любое время; тогда, естественно, когда Pod создается и уничтожается, IP-адрес Pod определенно будет динамически изменяться; тогда как раскрыть этот динамический IP-адрес Pod? Здесь, с помощью механизма Kubernetes Service, Service может выбрать группу Pod с указанными метками в форме меток, а также отслеживать и автоматически загружать их IP Pod, тогда мы только предоставляем IP Service для внешнего воздействия; это режим NodePort: Откройте порт на каждом узле, а затем перенаправьте его на внутренний IP-адрес модуля, как показано на следующем рисунке:
Метод доступа в это время: http: // nodeip : nodeport /
2. Проблемы управления портом
Проблема с раскрытием сервисов в методе NodePort заключается в том, что, когда станут доступны новые сервисы, порты, открытые NodePort на каждом узле, будут чрезвычайно большими и сложными в обслуживании; можем ли мы сейчас использовать Nginx для прямой пересылки их внутри? Как мы все знаем, Pod и Pod могут взаимодействовать друг с другом, и Pod может совместно использовать пространство сетевых имен хост-машины, то есть при совместном использовании пространства сетевых имен Pod слушает порт на узле. . Так как же этого достичь? Простая реализация состоит в том, чтобы использовать DaemonSet для мониторинга 80 на каждом узле, а затем написать правила, поскольку Nginx привязан к порту 80 хоста (точно так же, как NodePort) и находится в кластере, а затем перенаправляется непосредственно на соответствующий порт. IP-адрес службы. Вот и все, как показано на следующем рисунке:
3. Проблемы с выделением доменного имени и динамическим обновлением
Судя по описанному выше методу, использование Nginx-Pod, похоже, решило проблему, но на самом деле в нем есть большой недостаток: как изменять конфигурацию Nginx каждый раз при добавлении новой службы? Мы знаем, что с помощью Nginx можно различать различные службы по имени домена виртуального хоста, и каждая служба определяет разные пулы балансировки нагрузки через восходящий поток, а также обратный прокси-сервер местоположения для балансировки нагрузки. При повседневном использовании нужно изменять только nginx. Conf можно Достигнуто, то как добиться такого способа планирования в K8S? Предполагая, что первоначальной службой серверной службы является только ecshop, а службы bbs и участников добавляются позже, как добавить эти две службы в Nginx-Pod для планирования? Вы не можете вручную изменять или постоянно обновлять интерфейсный модуль Nginx Pod каждый раз! В это время появился Ingress.Если не считать вышеупомянутый Nginx, Ingress состоит из двух основных компонентов: Ingress Controller и Ingress.
Простое понимание Ingress заключается в том, что изначально вам нужно изменить конфигурацию Nginx, а затем настроить, какой службе соответствуют различные доменные имена. Теперь вы абстрагируете это действие и превращаете его в объект Ingress. Вы можете создать его с помощью yaml. Don ' • Меняйте Nginx каждый раз, просто меняйте его. yaml может быть создан / обновлен, тогда возникает вопрос: «Что должен делать Nginx?»
Ingress Controller - это решение «метода обработки Nginx»; Ingress Controoler взаимодействует с Kubernetes API, чтобы динамически воспринимать изменения в правилах Ingress в кластере, затем считывает его, генерирует часть конфигурации Nginx в соответствии со своим собственным шаблоном и записывает его в Nginx. В Pod, наконец, перезагрузите, рабочий процесс выглядит следующим образом:
Фактически, Ingress также является одним из стандартных типов ресурсов Kubernetes API. Фактически это набор правил, которые перенаправляют запросы к указанному ресурсу Сервиса на основе имени DNS (хоста) или URL-пути. Он используется для перенаправления трафика запроса за пределы кластера на публикацию службы, завершенную внутри кластера. Что нам нужно понять, так это то, что ресурс Ingress сам по себе не может выполнять «проникновение трафика». Это просто набор правил. Эти правила сбора также нуждаются в помощи других функций, таких как мониторинг сокета, а затем маршрутизация в соответствии с сопоставлением этих правил перенаправления, эти компоненты, которые могут отслеживать сокеты для ресурсов входа и перенаправления трафика, являются контроллерами входа.
Примечание. Контроллер Ingress отличается от контроллера развертывания тем, что контроллер Ingress не запускается напрямую как часть kube-controller-manager. Это только аксессуар для кластера Kubernetes, аналогичный CoreDNS, и его необходимо развернуть отдельно. на кластере.
4. Что такое контроллеры Ingress?
Ingress Controller - это семиуровневый планировщик балансировки нагрузки. Клиентские запросы сначала поступают в этот семиуровневый планировщик балансировки нагрузки, а семиуровневый балансировщик нагрузки переворачивает прокси-сервер на серверный модуль. Общие семиуровневые балансировщики нагрузки включают nginx и traefik. Подождите. , возьмите в качестве примера знакомый nginx. Если запрос поступает в nginx, он будет перенаправлен на серверный модуль через обратный прокси-сервер восходящего потока, но IP-адрес внутреннего модуля всегда меняется, поэтому службе требуется быть добавленным перед внутренним модулем. Эта служба играет только роль группировки, поэтому нам нужно только указать адрес службы для восходящего потока .
Каковы распространенные семислойные планировщики балансировки нагрузки:
nginx: необходимо вручную загрузить файл конфигурации
traefik: файл конфигурации автоматически загружается на регулярной основе без ручного вмешательства. Такой планировщик почти всегда используется в микросервисах.
5. Что такое Ingress?
Официально: https://kubernetes.io/docs/concepts/services-networking/ingress/
Официальное определение веб-сайта Ingress: ingress может пересылать запросы, поступающие в кластер, некоторым службам в кластере, чтобы служба могла быть доступна за пределами кластера. Ingress может настроить службу в кластере на URL-адрес, к которому можно получить доступ из внешней сети, балансировка нагрузки трафика и предоставление виртуальных хостов на основе доступа к имени домена. Ingress - это ресурс в k8s. Когда IP-адрес внутреннего модуля связан с изменениями службы, она изменится. Эти изменения сохраняются на входе и вводятся во входной контроллер планировщика с семью уровнями балансировки нагрузки по входу, то есть информация передается в файл конфигурации планировщика с семью уровнями балансировки нагрузки, и перезагружается, чтобы конфигурация действовала, можно использовать Ingress. Чтобы указать, в какую службу должен быть перенаправлен HTTP / S-запрос, например, пусть запрос попадет на другую службу в соответствии с разными путями хоста и URL-адреса в запросе.
6. Резюме:
Контроллер Ingress :
Ingress Controller можно понимать как контроллер. Он постоянно взаимодействует с Kubernetes API для получения в реальном времени изменений в серверной службе и Pod, таких как добавление и удаление, а затем генерирует конфигурацию на основе правил, определенных Ingress, и затем динамически обновляет вышеупомянутый Nginx или балансировщик нагрузки и обновляет конфигурацию, чтобы вступить в силу, для достижения роли автоматического обнаружения служб.
Ingress :
Ingress - это правило определения, с помощью которого запрос на определенное доменное имя пересылается указанной Службе в кластере. Его можно определить через файл Yaml, и одно или несколько правил Ingress могут быть определены для одной или нескольких служб.
7. Шаги по использованию семиуровневого планировщика балансировки нагрузки.
(1) Разверните входной контроллер, наш входной контроллер использует traefik
(2) Создайте сервис для группировки модулей.
(3) Создайте приложение для модуля, вы можете создать модуль через контроллер.
(4) Создайте входящий http, проверьте доступ к внутреннему модулю k8s через http
(5) Создайте входящий https, проверьте доступ к внутреннему модулю k8s через https
8. Способ доступа клиента к модулю серверной части через семислойный планировщик.
При использовании входящего контроллера планировщика с семиуровневой балансировкой нагрузки, когда клиент обращается к приложению внутри кластера Kubernetes, поток пакетов данных выглядит так, как показано в следующем процессе:
клиент ---> Nodeip: порт -----> IngressController ---> служба ---> pod
Как создавать ресурсы Ingress
Ресурсы Ingress - это правила пересылки, основанные на виртуальных хостах HTTP или URL-адресах. Следует подчеркнуть, что это правило пересылки . Он определяется вложенными полями, такими как правила, серверная часть и tls, в поле спецификации в списке конфигурации ресурсов. В следующем примере определяется ресурс Ingress, который содержит правило пересылки: запрос, отправленный на tomcat.lucky.com, передается через прокси на ресурс службы с именем myapp.
apiVersion: extensions / v1beta1 kind: Ingress metadata: name: ingress-myapp namespace: аннотации по умолчанию: kubernetes.io/ingress.class: спецификация "nginx": rules: - host: tomcat.lucky.com http: paths: - path: backend: serviceName: myapp servicePort: 80
Поле спецификации в Ingress является основным компонентом ресурсов Ingress и в основном содержит следующие 3 поля:
rules: список правил пересылки, используемых для определения текущего ресурса Ingress; когда правила определены правилами или правила не совпадают, весь трафик будет перенаправлен на серверную часть по умолчанию, определенную серверной частью.
backend:默认的后端用于服务那些没有匹配到任何规则的请求;定义Ingress资源时,必须要定义backend或rules两者之一,该字段用于让负载均衡器指定一个全局默认的后端。
tls:TLS配置,目前仅支持通过默认端口443提供服务,如果要配置指定的列表成员指向不同的主机,则需要通过SNI TLS扩展机制来支持该功能。
backend对象的定义由2个必要的字段组成:serviceName和servicePort,分别用于指定流量转发的后端目标Service资源名称和端口。rules对象由一系列的配置的Ingress资源的host规则组成,这些host规则用于将一个主机上的某个URL映射到相关后端Service对象,其定义格式如下:
spec: rules: - hosts: <string> http: paths: - path: backend: serviceName: <string> servicePort: <string>
需要注意的是,.spec.rules.host属性值,目前暂不支持使用IP地址定义,也不支持IP:Port的格式,该字段留空,代表着通配所有主机名。tls对象由2个内嵌的字段组成,仅在定义TLS主机的转发规则上使用。
hosts:包含 于 使用 的 TLS 证书 之内 的 主机 名称 字符串 列表, 因此, 此处 使用 的 主机 名 必须 匹配 tlsSecret 中的 名称。
secretName: 用于 引用 SSL 会话 的 secret 对象 名称, 在 基于 SNI 实现 多 主机 路 由 的 场景 中, 此 字段 为 可选。
Ingress资源类型
Ingress的资源类型有以下4种:
1、单Service资源型Ingress2、基于URL路径进行流量转发3、基于主机名称的虚拟主机4、TLS类型的Ingress资源
单Service资源型Ingress
暴露单个服务的方法有多种,如NodePort、LoadBanlancer等等,当然也可以使用Ingress来进行暴露单个服务,只需要为Ingress指定default backend即可,如下示例:
apiVersion: extensions/v1beta1kind: Ingressmetadata: name: my-ingressspec: backend: serviceName: my-svc servicePort: 80
Ingress控制器会为其分配一个IP地址接入请求流量,并将其转发至后端my-svc
Ingress Nginx部署
使用Ingress功能需要如下步骤:
1、安装部署ingress controller Pod2、部署后端服务3、部署ingress-nginx service4、部署ingress
1.安装Ingress Controller
1)把Ingress相关的yaml文件传到k8s的master节点的/root/test目录
mkdir /root/test
需要上传到这个目录下的yaml文件为
Ingress相关的yaml文件在百度网盘,地址如下:
链接:https://pan.baidu.com/s/1SF9Ni0CK0QmTFDEglmejiA 提取码:61co
2)创建ingress-nginx名称空间
kubectl apply -f namespace.yaml
3)创建ingress controller的pod
kubectl apply -f .
4)测试部署是否成功
kubectl get all -n ingress-nginx
显示如下,说明部署成功了:
NAME READY STATUS RESTARTS AGE
pod/default-http-backend-78d75577fd-g4b8n 1/1 Running 0 3m2s
pod/nginx-ingress-controller-7c7d57b55d-ng2gr 1/1 Running 0 3m2s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/default-http-backend ClusterIP 10.106.23.48 <none> 80/TCP 3m2s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/default-http-backend 1/1 1 1 3m2s
deployment.apps/nginx-ingress-controller 1/1 1 1 3m2s
NAME DESIRED CURRENT READY AGE
replicaset.apps/default-http-backend-78d75577fd 1 1 1 3m2s
replicaset.apps/nginx-ingress-controller-7c7d57b55d 1 1 1 3m2s
2.部署后端服务
1)部署后端服务
mkdir /root/test/ingress && cd /root/test/ingress
cat deploy-demo.yaml
apiVersion: v1kind: Servicemetadata: name: myapp namespace: defaultspec: selector: app: myapp release: canary ports: - name: http targetPort: 80 port: 80---apiVersion: apps/v1kind: Deploymentmetadata: name: myapp-backend-pod namespace: defaultspec: replicas: 3 selector: matchLabels: app: myapp release: canary template: metadata: labels: app: myapp release: canary spec: containers: - name: myapp image: ikubernetes/myapp:v2 ports: - name: http containerPort: 80
2)更新yaml文件
kubectl apply -f deploy-demo.yaml
3)查看pod是否部署成功
kubectl get pods
显示如下,说明部署成功:
myapp-backend-pod-559ff5c66-6jgjs 1/1 Running 0 6smyapp-backend-pod-559ff5c66-fthgt 1/1 Running 0 6smyapp-backend-pod-559ff5c66-xtz6z 1/1 Running 0 6s
3.部署ingress-nginx service
通过ingress-controller对外提供服务,现在还需要手动给ingress-controller建立一个service,接收集群外部流量。方法如下:
1)下载ingress-controller的yaml文件
cat service-nodeport.yaml
apiVersion: v1kind: Servicemetadata: name: ingress-nginx namespace: ingress-nginx labels: app: ingress-nginxspec: type: NodePort ports: - name: http port: 80 targetPort: 80 protocol: TCP nodePort: 30080 - name: https port: 443 targetPort: 443 protocol: TCP nodePort: 30443 selector: app: ingress-nginx
2)创建ingress-controller的service
kubectl apply -f service-nodeport.yaml
查看service是否创建成功
kubectl get svc -n ingress-nginx
显示如下,说明创建成功:
ingress-nginx NodePort 10.101.70.164 <none> 80:30080/TCP,443:30443/TCP 90s
3)浏览器访问ingress-controller的service
192.168.0.6:30080
注:192.168.0.6是k8s的master节点ip
此时应该是404 ,调度器是正常工作的,但是后端服务没有关联
4.部署ingress
(1)编写ingress的配置清单
cat ingress-myapp.yaml
apiVersion: extensions/v1beta1 #api版本kind: Ingress #清单类型metadata: #元数据 name: ingress-myapp #ingress的名称 namespace: default #所属名称空间 annotations: #注解信息 kubernetes.io/ingress.class: "nginx"spec: #规格 rules: #定义后端转发的规则 - host: tomcat.lucky.com #通过域名进行转发 http: paths: - path: #配置访问路径,如果通过url进行转发,需要修改;空默认为访问的路径为"/" backend: #配置后端服务 serviceName: myapp servicePort: 80
2)更新yaml文件
kubectl apply -f ingress-myapp.yaml
3)查看ingress-myapp的详细信息
kubectl describe ingress ingress-myapp
显示如下:
Name: ingress-myappNamespace: defaultAddress: Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)Rules: Host Path Backends ---- ---- -------- tomcat.lucky.com myapp:80 (10.244.1.57:80,10.244.1.58:80,10.244.1.59:80)Annotations: kubernetes.io/ingress.class: nginxEvents: Type Reason Age From Message ---- ------ ---- ---- ------- Normal CREATE 44s nginx-ingress-controller Ingress default/ingress-myapp
4)修改本地host文件,下面的ip是k8s的master节点ip
192.168.0.6 tomcat.lucky.com
5)浏览器访问tomcat.lucky.com:30080
出现如下:
5.部署ingress-测试代理tomcat服务
1)部署tomcat服务
cat tomcat-demo.yaml
apiVersion: v1kind: Servicemetadata: name: tomcat namespace: defaultspec: selector: app: tomcat release: canary ports: - name: http targetPort: 8080 port: 8080 - name: ajp targetPort: 8009 port: 8009---apiVersion: apps/v1kind: Deploymentmetadata: name: tomcat-deploy namespace: defaultspec: replicas: 3 selector: matchLabels: app: tomcat release: canary template: metadata: labels: app: tomcat release: canary spec: containers: - name: tomcat image: tomcat:8.5.34-jre8-alpine ports: - name: http containerPort: 8080 name: ajp containerPort: 8009
2)更新yaml文件
kubectl apply -f tomcat-demo.yaml
3)查看tomcat的pod是否部署成功
kubectl get pods
显示如下,说明创建成功:
tomcat-deploy-8655579b6c-5dfqw 1/1 Running 0 83stomcat-deploy-8655579b6c-9d79c 1/1 Running 0 83stomcat-deploy-8655579b6c-qmc62 1/1 Running 0 83s
4)编写tomcat的ingress规则,并创建ingress资源
cat ingress-tomcat.yaml
apiVersion: extensions/v1beta1kind: Ingressmetadata: name: tomcat namespace: default annotations: kubernetes.io/ingress.class: "nginx"spec: rules: - host: tomcat.lucky6.com #主机域名 http: paths: - path: backend: serviceName: tomcat servicePort: 8080
更新yaml文件:
kubectl apply -f ingress-tomcat.yaml
修改本地host文件,下面的ip是k8s的master节点ip
192.168.0.6 tomcat.lucky6.com
5)浏览器访问tomcat.lucky6.com:30080
可看到出现如下界面:
6)总结
从前面的部署过程中,可以再次进行总结部署的流程如下:
①下载Ingress-controller相关的YAML文件,并给Ingress-controller创建独立的名称空间;
②部署后端的服务,如myapp,并通过service进行暴露;
③部署Ingress-controller的service,以实现接入集群外部流量;
④部署Ingress,进行定义规则,使Ingress-controller和后端服务的Pod组进行关联。
构建TLS站点
(1)准备证书,在k8s的master节点操作
openssl genrsa -out tls.key 2048
openssl req -new -x509 -key tls.key -out tls.crt -subj /C=CN/ST=Beijing/L=Beijing/O=DevOps/CN=tomcat.lucky.com
(2)生成secret,在k8s的master节点操作
kubectl create secret tls tomcat-ingress-secret --cert=tls.crt --key=tls.key
(3)查看secret
kubectl get secret
显示如下:
tomcat-ingress-secret kubernetes.io/tls 2 56s
(4)查看tomcat-ingress-secret详细信息
kubectl describe secret tomcat-ingress-secret
显示如下:
Name: tomcat-ingress-secretNamespace: defaultLabels: <none>Annotations: <none>Type: kubernetes.io/tlsData====tls.key: 1679 bytestls.crt: 1294 bytes
(5)创建ingress
cat ingress-tomcat-tls.yaml
apiVersion: extensions / v1beta1kind: Ingressmetadata: name: ingress-tomcat-tls namespace: аннотации по умолчанию: kubernetes.io/ingress.class: спецификация "nginx": tls: - hosts: - tomcat.lucky.com secretName: tomcat-ingress- секретные правила: - host: tomcat.lucky.com http: paths: - path: backend: serviceName: tomcat servicePort: 8080
Обновить файл yaml
kubectl apply -f ingress-tomcat-tls.yaml
(6) Визит-тест:
https://tomcat.lucky.com:30443/
Вышеуказанный браузер является лучшим браузером Firefox для доступа, примите решение принять риск и продолжите, появится следующий интерфейс