Сервисы/Сеть

more

Шлет входящие запросы на поды с указанным селектором. В качестве targetPort можно использовать имена портов, если они определены в подах, это дает большую гибкость т.к. могут быть разные

Если targetPort (порт назначения) не указать то по умолчанию используется тот же что и port (входящий)

Создается сервис, присваивается IP и куб добавляет его в DNS, после чего к сервису можно обращаться по имени, к том же NS: «http://service-my-pods», если из другого то нужно указать NS: «service-my-pods.namespace.svc»

В деплойменте должен быть прописан порт, чтобы контейнер мог принимать на нем запросы, в т.ч от сервиса собсна

Стратегия распределения запросов между подами, по умолчанию «round robin»

Примеры

apiVersion: v1
kind: Service
metadata:
  name: tomcat-main
spec:
  selector:
    app: tomcat
  ports:
    - protocol: TCP
      port: 80
      targetPort: tomcat

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tomcat-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tomcat
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:10-jdk15
        ports:
        - containerPort: 8080
          name: tomcat
          protocol: TCP

Пару примеров как смотреть в консоли

kubectl get pods -o wide
 
kubectl get svc -o wide
 
  # Так виден назначенный IP
kubectl get svc <my-service> -o yaml

Пример

apiVersion: v1
kind: Service
metadata: 
 name: my-internal-service
selector:   
 app: my-app
spec:
 type: ClusterIP
 ports: 
 - name: http
   port: 80
   targetPort: 80
   protocol: TCP

В целях тестирования можно открыть доступ запустив Proxy в консоли

kubectl proxy --port=8080
 
  # Затем обратится по такому адресу
http://localhost:8080/api/v1/proxy/namespaces//services/<SERVICE-NAME>:<PORT-NAME>/
http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/

Создается сервис типа «NodePort»

apiVersion: v1
kind: Service
metadata:
  name: service-front
  namespace: my-namespace
spec:
  selector:
    app: my-front
  ports:
    - protocol: TCP
      port: 3000

На всех нодах открывается рандомный порт, по IP ноды и этому порту, будет доступен сервис. Порт виден в oc describe svc/my-service (NodePort)

Еще пример

apiVersion: v1
kind: Service
metadata: 
 name: my-nodeport-service
selector:   
 app: my-app
spec:
 type: NodePort
 ports: 
 - name: http
   port: 80
   targetPort: 80
   nodePort: 30036
   protocol: TCP

Сервисы для трафика

Revers proxy в Ingress Controller слушает порты с HTTP/HTTPS-соединениями, трафик может попадать на порты тремя способами:

• NodePort
• HostPort (можно повесить на порты 80 и 443)
• Host network (под повесит свои порты на публичном интерфейсе, т.е. будут открыты все порты контейнера)

Тут неясно, в рабочем варианте сервис был в дефолтном «ClusterIP», IC сам перенаправляет извне внутри кластера

Возможный вариант конфига

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: my-ingress
spec:
 backend:
   serviceName: other
   servicePort: 8080
 rules:
 - host: foo.mydomain.com
   http:
     paths:
     - backend:
         serviceName: foo
         servicePort: 8080
 - host: mydomain.com
   http:
     paths:
     - path: /bar/*
       backend:
         serviceName: bar
         servicePort: 8080

Два location на разные сервисы

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-test-site
  namespace: test-ingress-app
spec:
  ingressClassName: nginx
  rules:
  - host: es.moysite.ru
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: spa
            port:
              number: 80
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: frontend-api
            port:
              number: 80

Annotations

«nginx.ingress.kubernetes.io/»:
ssl-redirect - принудительное использование HTTPS на стороне сервера, с помощью перенаправления. По умолчанию контроллер перенаправляет на HTTPS если для этого входа включен TLS
force-ssl-redirect - принудительно перенаправлять на HTTPS, даже если TLS недоступен.

ssl-passthrough - передача данных по протоколу SSL. Указание контроллеру отправлять соединения по протоколу TLS непосредственно на серверную часть, вместо того чтобы позволять Nginx расшифровывать обмен данными
т.к. передача по протоколу SSL работает на уровне 4 модели OSI (TCP), а не на 7 (HTTP), то эта аннотация делает недействительными все остальные аннотации для входящего объекта
В том числе и маршрутизация на основе пути (т.е. Location фактически не работает, тк путь зашифрован)

Блок «TLS» вероятно по этой же причине не работает, тк подставляется дефолтный сертификат кубера

-

-

Мат. часть

Ingress работает на 7ом (прикладном) уровне OSI, для работы на третьем (сетевом) можно использовать другие методы публикации приложений:

• ClusterIP
• LoadBalancer
• NodePort
• ExternalName
• ExternalIP

Внутри Ingress Controller обычный Nginx, поэтому можно настроить распределение запросов по доменам или location

(?) Важно отметить, что Ingress Controller-ы должны быть запущены на каждом узле, где развернуты приложения, к которым нужно получить доступ извне кластера.

Терминирование TLS: если IC настроен на обработку HTTPS, он выполняет терминирование, те расшифровку входящего трафика и пересылку его во внутреннюю службу уже по нешифрованному соединению

Далее этот серт можно использовать в конфигурации Ingress

apiVersion: extensions/v1beta1
 kind: Ingress
 metadata:
   name: ingress-my-tls
 spec:
   tls:
   - hosts:
     - ingress.example.com
     secretName: my-tls
   rules:
   - host: ingress.example.com
     http:
       paths:
       - path: /
         backend:
           serviceName: nginx
           servicePort: 80

Пересылка шифрованного трафика через Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ing
  annotations:
    # указывает на использование nginx, зависит от настроек контроллера видимо
    kubernetes.io/ingress.class: nginx
 
    # Указываем контроллеру пересылать шифрованный трафик дальше, в приложение
    nginx.ingress.kubernetes.io/ssl-passthrough: 'true'

  labels:
    app: myapp
spec:
  rules:
    - host: "myapp.apps.url-cluster.ru"
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: myapp-svc
                port:
                  number: 9444

Вариант с Lets Encrypt

Есть статья по этому поводу
Еще статья
«Cert-manager» - утилита в кластере Кубера, которая умеет автоматически полуать и продлевать сертификаты, в том числе и от бесплатного «Lets Encrypt»

Суть в том что в кластер устанавливается объект «cert-manager», типа «issuer», он занимается выпуском/перевыпуском сертов
В манифесте Ingress, в блоке «tls», указывается этот объект, точнее секрет, куда эмитент сохраняет серт

Пример конфига ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-test-site
  namespace: test-ingress-app
  annotations:
    cert-manager.io/issuer: letsencrypt-production
spec:
  ingressClassName: nginx
  rules:
  - host: es.moysite.ru
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: spa
            port:
              number: 80
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: frontend-api
            port:
              number: 80
  tls:
  - hosts:
    - es.moysite.ru
    secretName: test-ingress-app-production

Еще пример

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-socks-tls
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt"
spec:
  rules:
  - host: kuber.zeroxzed.ru
    http:
      paths:
      - backend:
          serviceName: front-end
          servicePort: 80
  tls:
  - hosts:
    - kuber.zeroxzed.ru
    secretName: socks-tls-2

Еще про TLS

Хорошая инфа по этому поводу

Конфигурация с расшифровкой TLS на Ingress контроллере

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-name
  namespace: namespace-name 
  annotations:
    # это хз, возможно не обязательно
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  # блок, задающий терминацию на ингрессе, далее трафик не шифрованный, внутри кластера
  tls:
  - hosts:
    - app.myorg.com
    secretName: tls-secret 
  rules:
  - http:
      paths:
      - backend:
          serviceName: service
          servicePort: 9443
        path: /carbon
      - backend:
          serviceName: service2
          servicePort: 9443
        path: /oauth

тоже самое, только пересылка шифрованного трафика, расшифровка в приложении

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-name
  namespace: namespace-name 
  annotations:
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
  rules:
  - http:
      paths:
      - backend:
          serviceName: service
          servicePort: 9443
        path: /carbon
      - backend:
          serviceName: service2
          servicePort: 9443
        path: /oauth