Это 12-й день моего участия в Gengwen Challenge, Подробную информацию о мероприятии см.:Обновить вызов
Девять входных контроллеров
Если k8s должен предоставить веб-сайт, и доступ к этому сайту должен осуществляться по протоколу https, а iptables/ipvs работает на уровне 4, запрос ssl, отправленный клиентом, отправляется на серверную часть POD без какого-либо анализа. Есть два обходных пути:
-
SSL-сертификат можно настроить на балансировщике нагрузки в общедоступном облаке.
-
Создайте POD балансировщика нагрузки, например nignx, этот POD разделяет сетевое пространство имен хоста, что означает, что к балансировщику нагрузки можно получить доступ напрямую через nodeip, на этом балансировщике нагрузки настроен сертификат ssl, а внешнее соединение https и внутренний Прокси — это протокол http для POD в сети POD.
- существующие проблемы
- 负载均衡器 POD 使用节点的网络名称空间, 那么它只 能在这个 node 节点上运行一个了,否则就出现端口冲突
- 负载均衡器是代理 POD 卸载 ssl 证书的关键节点, 它不能只运行一个, 它需要在所有节点运行一个
- Решение
- 负载均衡器使用 DaemonSet 在每个 node 节点运行一个,代理请求至 POD 网络的中的 POD 上
- 如果集群节点非常的多,其实不必在每个 node 节点都必须运行一个负载均衡器 POD
- 控制负载均衡器 POD 运行的数量可以通过 lables 指定运行那几个 node 节点上
- 然后可以在负载均衡器 POD 所在的 node 节点上打上 "污点" 使其他的 POD 不会再被调度上来, 而只有负载均衡器 POD 可以容忍这些 "污点"
- Дополнительный балансировщик нагрузки, отсортированный по приоритету
Envoy # 云原生高性能服务代理,已从cncf毕业
Traefik # 为微服务而生的反向代理
Nginx # 改造后可以适用于微服务环境
HAproxy # 不推荐使用
Создайте новую службу для классификации модулей различных служб, которые необходимо проксировать.
Создайте новый входной ресурс, получите результат классификации от службы, сопоставьте его с Envoy и перезагрузите программное обеспечение Envoy.
9.1 Спецификация ingress.spec
- API и вид
apiVersion: extensions
kind: ingress
- ingress.spec
backend # 后端有哪些 POD
rules # 调度规则
host # 虚拟主机
http # http 路径
9.2 входной прокси-сервер nginx
- Бэкэнд-сервисы и модули
apiVersion: v1
kind: Service
metadata:
name: service-ingress-myapp
namespace: default
spec:
selector:
app: myapp
release: canary
ports:
- name: http
port: 80
targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
namespace: default
spec:
replicas: 4
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
- Создать вход-nginx
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.21.0/deploy/mandatory.yaml
- Сделать ingress-nginx доступным за пределами кластера
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.21.0/deploy/provider/baremetal/service-nodeport.yaml
- Создайте объект ingress, который может ассоциировать ingress-nginx с сервисом, чтобы при смене хоста после сервиса это отражалось в конфигурационном файле контейнера ingress-nginx
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-deploy-myapp
namespace: default
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: myapp.kaliarch.com # 基于主机名的访问
http:
paths:
- path: # 空的时候代表根,访问根的时候映射到 backend
backend: # 后端的 service 的配置
serviceName: service-ingress-myapp # 关联 service 从而获取到后端主机的变动
servicePort: 80 # 关联 service 的地址
- Проверьте порты, открытые ingress-nginx, вот 30080 и 30443.
kubectl get service -n ingress-nginx
- Используйте nodeip + ingress-nginx для предоставления доступа к порту.Поскольку созданный выше вход основан на имени хоста, при доступе его необходимо сопоставить с узлом в /etc/hosts.
http://myapp.kaliarch.com:30080/index.html
9.3 прокси-сервер на входе tomcat
- Бэкэнд-сервисы и модули
apiVersion: v1
kind: Service
metadata:
name: service-ingress-tomcat
namespace: default
spec:
selector:
app: tomcat
release: canary
ports:
- name: http
port: 8080
targetPort: http
- name: ajp
port: 8009
targetPort: ajp
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-tomcat
namespace: default
spec:
replicas: 4
selector:
matchLabels:
app: tomcat
release: canary
template:
metadata:
labels:
app: tomcat
release: canary
spec:
containers:
- name: tomcat
image: tomcat:8.5.32-jre8-alpine
ports:
- name: http
containerPort: 8080
- name: ajp
containerPort: 8009
- Создайте самозаверяющий сертификат и разрешите ingress-nginx получить к нему доступ с помощью сертификата.
# 生成 key
openssl genrsa -out tls.key 2048
# 生成自签证书,CN=域名必须要与自己的域名完全一致
openssl req -new -x509 -key tls.key -out tls.crt -subj /C=CN/ST=Beijing/L=Beijing/O=DevOps/CN=tomcat.kaliarch.com
- Создайте объект секретного сертификата, который является стандартным объектом k8s.
kubectl create secret tls tomcat-ingress-secret --cert=tls.crt --key=tls.key
- Создайте объект ingress с сертификатом, который может ассоциировать ingress-tomcat со службой, чтобы при смене хоста после службы это отражалось в файле конфигурации контейнера ingress-tomcat
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-deploy-tomcat-tls
namespace: default
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
tls:
- hosts:
- tomcat.kaliarch.com
secretName: tomcat-ingress-secret
rules:
- host: tomcat.kaliarch.com
http:
paths:
- path:
backend:
serviceName: service-ingress-tomcat
servicePort: 8080
- Проверьте порты, открытые ingress-nginx, вот 30080 и 30443.
kubectl get service -n ingress-nginx
- Используйте nodeip + ingress-nginx для предоставления доступа к порту.Поскольку созданный выше вход основан на имени хоста, при доступе его необходимо сопоставить с узлом в /etc/hosts.
https://tomcat.kaliarch.com:30443
разное
Публикуйте свои заметки по адресу:GitHub.com/RedHat Series/Арвин…Добро пожаловать в один клик