Автоматически декларативно масштабировать бэкэнд-развертывание Google Cloud-Endpoint (в yaml)? - PullRequest
Новая
       53

Автоматически декларативно масштабировать бэкэнд-развертывание Google Cloud-Endpoint (в yaml)?

0 голосов
/ 04 декабря 2018

Я успешно следовал документации здесь и здесь , чтобы развернуть спецификацию API и серверную часть GKE на конечных точках облака.

Это оставило меня с развертыванием.yaml, который выглядит следующим образом: 

apiVersion: v1
kind: Service
metadata:
  name: esp-myproject
spec:
  ports:
  - port: 80
    targetPort: 8081
    protocol: TCP
    name: http
  selector:
    app: esp-myproject
  type: LoadBalancer
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: esp-myproject
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: esp-myproject
    spec:
      containers:
      - name: esp
        image: gcr.io/endpoints-release/endpoints-runtime:1
        args: [
          "--http_port=8081",
          "--backend=127.0.0.1:8080",
          "--service=myproject1-0-0.endpoints.myproject.cloud.goog",
          "--rollout_strategy=managed",
        ]
        ports:
        - containerPort: 8081
      - name: myproject
        image: gcr.io/myproject/my-image:v0.0.1
        ports:
        - containerPort: 8080

Это создает единственную копию приложения на серверной части.Пока все хорошо ...

Теперь я хочу обновить файл yaml до декларативно , указав параметры автоматического масштабирования, чтобы позволить нескольким репликам приложения работать рядом друг с другом при передаче трафика наконечная точка оправдывает более одного.

Я перечитал (книга О'Рейли: Kubernetes Up & Running, документы GCP, документы K8s), но есть две вещи, которые я озадачен:

  1. Я несколько раз читал о HorizontalPodAutoscaler, и мне не ясно, должно ли развертывание использовать , чтобы использовать преимущества автоматического масштабирования?
  2. Если это так, я видел примеры в документах о том, как определить спецификацию для HorizontalPodAutoscaler в yaml, как показано ниже - но как бы я совместил это с моим существующим развертыванием.пример ( из документов ): 
    apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

    Заранее спасибо всем, кто может пролить свет на это для меня.

1 Ответ

0 голосов
/ 04 декабря 2018
  1. Я несколько раз читал о HorizontalPodAutoscaler, и мне не ясно, должно ли развертывание использовать это, чтобы воспользоваться преимуществами автоматического масштабирования?

Не обязательно, но рекомендуется и уже встроено. Вы можете создать свою собственную автоматизацию, которая масштабируется вверх и вниз, но вопрос в том, почему, поскольку она уже поддерживается HPA.

Если это так, в документах я видел примеры того, как определить спецификацию для HorizontalPodAutoscaler в yaml, как показано ниже - но как бы я совместил это с моим существующим развертыванием.yaml?

Это должно быть просто.Вы в основном ссылаетесь на свое развертывание в определении HPA: 

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-esp-project-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: esp-myproject  <== here
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
...