Kubernetes+Docker Microservice Practice Road — эластичное расширение

задняя часть Микросервисы сервер Docker

57355-20161124160443534-1985216280.jpg

Когда служба выйдет в онлайн, вы должны выдержать давление и испытание, иначе это будут делать наши братья.Помните сцену на картинке выше?

Старый метод заключается в развертывании сервисов в кластерах, но всегда есть верхний предел.Когда они раньше сотрудничали с Али, у них были эластичные вычисления, и они могли динамически расширять и сокращать вычислительную мощность, устанавливая порог ЦП.Это было очень убедительно при этом время, по крайней мере в то время. Наша обычная практика трудно сделать. Я не ожидал, что мы можем гордиться Kubernetes сегодня. Позвольте мне показать вам настоящее шоу.

Автоматическое расширение Kubernetes направлено на ReplicationController, который отслеживает загрузку ЦП всех подов.Если он превышает соотношение, для предоставления услуг запускается больше подов, в противном случае поды сокращаются.В общем случае мы не будем устанавливать ЦП Поды Верхний предел, но для использования автоматического расширения необходимо установить его порог, поэтому необходимо установить верхний предел использования ЦП подами, иначе Kubernetes не сможет рассчитать коэффициент его занятости, поэтому мы должны указать ЦП использование ресурсов каждого модуля при создании верхнего предела RC

настроить

apiVersion: v1
kind: ReplicationController
metadata:
  name: thrift-c
  namespace: thrift-demo
spec:
  replicas:1
  selector:
    app: thrift-c
  template:
    metadata:
      name: thrift-c
      labels:
        app: thrift-c
    spec:
      containers:
      - name: thrift-c
        resources:
          requests:
            cpu: 200m
        image: registry2.io/thrift/thrift-c:0.0.2
        imagePullPolicy: Always
        ports:
        - containerPort: 9091
      imagePullSecrets:
        - name: registry2key

Обратите внимание на конфигурацию ресурсов и укажите, что максимальное использование ЦП составляет 200 м. Если оно изменено, вы должны удалить RC, создать его заново и применить. Также обратите внимание, что наших реплик здесь 1.

Проверьте в Dashboard, чтобы увидеть, работает ли он,

57355-20161124160502034-1148528239.png

испытание давлением

После подтверждения того, что наша конфигурация вступит в силу, это зависит от эффекта эластичного расширения Kubernetes.Первый шаг — добавить возможность автоматического расширения нашей службы.Есть два метода: один — через файл конфигурации, а другой — через Команда Kubectl. , см. команду

kubectl autoscale rc thrift-c -nthrift-demo --max=10 --cpu-percent=10 --min=1

Параметр --max — максимальное количество Pod'ов для эластичного расширения, --min — естественное минимальное количество, а --cpu-percent — пороговое значение, выражающееся в процентах. Конфигурация здесь эквивалентна 10%. эта команда запущена, она нам будет дана.RC thrift-c добавляет возможность автоматического расширения, проверьте это

57355-20161124160518675-254229269.jpg

Вы можете увидеть такую ​​информацию, как цель, текущий и количество. В настоящее время у нас нет трафика

Второй шаг, давление, увеличение количества посещений и параллелизма, и дать вам простую команду

while true; do wget -q -O- http://test.k8s.io/hi?name=3213; done

Я выполнил эту команду на трех разных машинах, и давление резко возросло.

57355-20161124160537737-1202948857.jpg

Когда CPU превышает 10%, мы смотрим на количество Pod'ов.

57355-20161124160549346-732181430.png

Поды быстро расширяются с одного до четырех.Если емкость сервиса не соответствует требованиям, количество подов будет увеличено.Когда я завершал команду стресс-теста, когда процессор падал, Kubernetes уменьшал количество подов до исходного примерно через несколько минут.После повторного тестирования много раз, эта функция очень проста в использовании и очень стабильна.Он может реагировать вовремя в соответствии с давлением службы.Сжатие происходит с задержкой, что может предотвратить его повторение в течение короткого времени. После того, как ЦП стабилизируется в течение определенного периода времени, поды уменьшаются до настроенного нами --min.

С этой функцией нам больше не страшны внезапные перегрузки и простои серверов.Узкое место останется за сетевым и дисковым IO и базой данных.В случае простоя на стороне сервера Kubernetes переместит все поды на нем на другие узлов. Запустите его, чтобы убедиться, что ваши поды всегда работают, но есть момент, когда мастер Kubernetes работает в одной точке. Если у вас есть время изучить высокую доступность мастера позже, на самом деле, многие пользователи сети изучены и приведены решения.Если вам интересно, вы можете узнать сначала.


Категории