Назад | Перейти на главную страницу

Как открыть веб-сервис, работающий как модуль в кластере K8s, развернутый на экземпляре ec2, для внешнего

Я развернул кластер Kubernetes (только с одним узлом в качестве главного) на экземпляре ec2. После этого я создал развертывание nginx и представил службу, используя «Тип» в качестве NodePort. Служба nginx доступна по адресу ec2 privateIP: 31336, а также может получить доступ через ec2 publicIP: 31336 с моего компьютера.

На этом этапе у меня возникают следующие вопросы: 1) что делать на следующем шаге, чтобы получить доступ к службе http извне кластера, то есть успешно выполнить операцию curl ec2publicIP: 80? Любое руководство было бы чрезвычайно полезно.

Примечание. - Мое правило безопасности ec2 настроено на разрешение HTTP-трафика. - После входа в модуль nginx я могу проверить связь с google.com, но время ожидания обновления apt-get истекает. - Я обновил переадресацию IP в моем экземпляре EC2.

2) Что было бы лучшим и простым вариантом среди NodePort, входящего контроллера или ELB в качестве типа для сервисов kube.

3) Также, где в него вписываются IPtables. Можно ли избежать изменения правила вручную с помощью любого из вышеперечисленных или других инструментов / pkgs, которые позаботятся о сети?

Ваш ответ будет очень признателен.

nginx-deployment.yaml:

apiVersion: apps/v1 kind: Deployment metadata: name: demo-nginx spec: selector: matchLabels: run: demo-nginx replicas: 1 template: metadata: labels: run: demo-nginx spec: containers: - name: demo-nginx image: k8s.gcr.io/nginx:1.7.9 ports: - containerPort: 80

nginx-services.yaml:

apiVersion: v1 kind: Service metadata: name: demo-nginx labels: run: demo-nginx spec: ports: - port: 80 protocol: TCP selector: run: demo-nginx type: NodePort

Я думаю, вы хотите создать Сервис Kubernetes что будет сидеть перед твоим Стручок. Модули прослушивают случайные порты, а Сервисы являются балансировщики нагрузки которые преобразуют случайные порты в известные внешние порты (например, 80 или 443).

Также вы не хотите запускать Pods самостоятельно. Лучше запустить их как часть Развертывание это позаботится о перезапуске их, если они умрут.

Вот очень простой одноподовое развертывание с обслуживание реализован как AWS ELB. Все само по себе пространство имен:

kind: Namespace
apiVersion: v1
metadata:
  name: demo
  labels:
    name: demo

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-deployment
  namespace: demo
  labels:
    app: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: demo
        image: 123456789012.dkr.ecr.ap-southeast-2.amazonaws.com/demo:latest    # <<< Update
        ports:
        - containerPort: 80
          name: backend-http
        env:
        - name: SOME_API
          value: https://example.com/some-api


---
kind: Service
apiVersion: v1
metadata:
  name: demo
  namespace: demo
  annotations:
    # The backend talks over HTTP.
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
spec:
  type: LoadBalancer
  selector:
    app: demo
  ports:
  - name: elb-http
    protocol: TCP
    port: 80
    targetPort: backend-http

Как вы заметите, это относится к порту 80 внутри шаблона, хотя на самом деле это будет случайный номер, присвоенный k8s. Но Pod думает, что он прослушивает порт 80, так что это то, что мы упоминаем в шаблоне.

Вы можете развернуть его с помощью kubectl apply и это создаст целую партию.

Надеюсь, это поможет :)