Евгений Штольц - Облачная экосистема

Successfully removed 1 resource instance(s).

essh@kubernetes-master:~/node-cluster$ ./terraform state rm module.nodejs.kubernetes_service.nodejs

Removed module.nodejs.kubernetes_service.nodejs

Successfully removed 1 resource instance(s).

essh@kubernetes-master:~/node-cluster$ ./terraform apply

module.Kubernetes.google_container_cluster.node-ks: Refreshing state… [id=node-ks]

module.Kubernetes.google_container_node_pool.node-ks-pool: Refreshing state… [id=europe-west2-a/node-ks/node-ks-pool]

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Надежность и автоматизация кластера на Terraform

В общих черта автоматизация рассмотрена в https://codelabs.developers.google.com/codelabs/cloud-builder-gke-continuous-deploy/index. html #0. Мы остановимся подробнее. Теперь, если мы запустим удаление ./terraform destroy и попытаемся воссоздать инфраструктуру целиком сначала, то у нас появятся ошибки. Ошибки получаются из-за того, что порядок создания сервисов не задан и terraform, по умолчанию, отравляет запросы к API в 10 параллельных потоков, хотя это можно изменить, указав при применении или удаление ключ -parallelism=1. В результате Terraform пытается создать Kubernetes сервисы (Deployment и service) на серверах (node-pull), которых пока ещё нет, та же ситуация и при создании сервиса, которому требуется , проксирующего ещё не созданный Deployment. Указывая Terraform запрашивать API в один поток ./terraform apply -parallelism=1 мы снижаем возможные ограничения со стороны провайдера на частоту обращений к API, но не решаем проблему отсутствия порядка создания сущностей. Мы не будем комментировать зависимые блоки и постепенно раскомментировать и запускать ./terraform apply, также не будем запускать по частям нашу систему, указывая конкретные блоки ./terraform apply -target=module.nodejs.kubernetes_deployment.nodejs. Мы укажем в коде сами зависимости на инициализации переменной, первая из которой уже определена как внешняя var.endpoint, а вторую мы создадим локально:

locals {

app = kubernetes_deployment.nodejs.metadata.0.labels.app

}

Теперь мы можем добавить зависимости в код depends_on = [var.endpoint] и depends_on = [kubernetes_deployment .nodejs].

Таже может появляться ошибка недоступности сервиса: Error: Get https://35.197.228.3/API/v1…: dial tcp 35.197.228.3:443: connect: connection refused, то скорее превышено время подключения, которое составляет по умолчанию 6 минут (3600 секунд), но тут можно просто попробовать еще раз.

Теперь перейдём к решению проблемы надёжности работы контейнера, основной процесс которого мы запускаем в командной оболочке. Первое, что мы сделаем, отделим создание приложения от запуска контейнера. Для этого нужно весь процесс создания сервиса перенести в процесс создания образа, которых можно протестировать, и по которому можно создать контейнер сервиса. Итак, создадим образ:

essh@kubernetes-master:~/node-cluster$ cat app/server.js

const http = require('http');

const server = http.createServer(function(request, response) {

response.writeHead(200, {"Content-Type": "text/plain"});

response.end(`Nodejs_cluster is working! My host is ${process.env.HOSTNAME}`);

});

server.listen(80);

essh@kubernetes-master:~/node-cluster$ cat Dockerfile

FROM node:12

WORKDIR /usr/src/

ADD ./app /usr/src/

RUN npm install

EXPOSE 3000

ENTRYPOINT ["node", "server.js"]

essh@kubernetes-master:~/node-cluster$ sudo docker image build -t nodejs_cluster .

Sending build context to Docker daemon 257.4MB

Step 1/6 : FROM node:12

––> b074182f4154

Step 2/6 : WORKDIR /usr/src/

––> Using cache

––> 06666b54afba

Step 3/6 : ADD ./app /usr/src/

––> Using cache

––> 13fa01953b4a

Step 4/6 : RUN npm install

––> Using cache

––> dd074632659c

Step 5/6 : EXPOSE 3000

––> Using cache

––> ba3b7745b8e3

Step 6/6 : ENTRYPOINT ["node", "server.js"]

––> Using cache

––> a957fa7a1efa

Successfully built a957fa7a1efa

Successfully tagged nodejs_cluster:latest

essh@kubernetes-master:~/node-cluster$ sudo docker images | grep nodejs_cluster

nodejs_cluster latest a957fa7a1efa 26 minutes ago 906MB

Теперь положим наш образ в реестр GCP, а не Docker Hub, потому что мы получаем сразу приватный репозиторий с которому автоматом есть доступ у наших сервисов:

essh@kubernetes-master:~/node-cluster$ IMAGE_ID="nodejs_cluster"

essh@kubernetes-master:~/node-cluster$ sudo docker tag $IMAGE_ID:latest gcr.io/$PROJECT_ID/$IMAGE_ID:latest

essh@kubernetes-master:~/node-cluster$ sudo docker images | grep nodejs_cluster

nodejs_cluster latest a957fa7a1efa 26 minutes ago 906MB

gcr.io/node-cluster-243923/nodejs_cluster latest a957fa7a1efa 26 minutes ago 906MB

essh@kubernetes-master:~/node-cluster$ gcloud auth configure-docker

gcloud credential helpers already registered correctly.

essh@kubernetes-master:~/node-cluster$ docker push gcr.io/$PROJECT_ID/$IMAGE_ID:latest

The push refers to repository [gcr.io/node-cluster-243923/nodejs_cluster]

194f3d074f36: Pushed

b91e71cc9778: Pushed

640fdb25c9d7: Layer already exists

b0b300677afe: Layer already exists

5667af297e60: Layer already exists

84d0c4b192e8: Layer already exists

a637c551a0da: Layer already exists

2c8d31157b81: Layer already exists

7b76d801397d: Layer already exists

f32868cde90b: Layer already exists

0db06dff9d9a: Layer already exists

latest: digest: sha256:912938003a93c53b7c8f806cded3f9bffae7b5553b9350c75791ff7acd1dad0b size: 2629

essh@kubernetes-master:~/node-cluster$ gcloud container images list

NAME

gcr.io/node-cluster-243923/nodejs_cluster

Only listing images in gcr.io/node-cluster-243923. Use –repository to list images in other repositories.

Теперь мы можем посмотреть его в админке GCP: Container Registry –> Образы. Заменим код нашего контейнера на код с нашим образом. Если для продакшна нужно обязательно версионировать запускаемый образ во избежание автоматического их обновления при системных пересозданиях POD, например, при переносе POD с одной ноды на другую при выводе машины с нашей нодой на техническое обслуживание. Для разработки лучше использовать тег latest, который позволит при обновлении образа обновить сервис. При обновлении сервиса его нужно пересоздать, то есть удалить и заново создать, так как иначе terraform просто обновит параметры, а не пересоздаст контейнер с новым образом. Также, если обновим образ и пометим сервис как изменённый с помощью команды ./terraform taint ${NAME_SERVICE}, наш сервис будет просто обновлён, что можно увидеть с помощью команды ./terraform plan. Поэтому для обновления, пока, нужно пользоваться командами ./terraform destroy -target=${NAME_SERVICE} и ./terraform apply, а название сервисов можно посмотреть в ./terraform state list:

essh@kubernetes-master:~/node-cluster$ ./terraform state list

data.google_client_config.default

module.kubernetes.google_container_cluster.node-ks

module.kubernetes.google_container_node_pool.node-ks-pool

module.Nginx.kubernetes_deployment.nodejs

module.Nginx.kubernetes_service.nodejs

essh@kubernetes-master:~/node-cluster$ ./terraform destroy -target=module.nodejs.kubernetes_deployment.nodejs

essh@kubernetes-master:~/node-cluster$ ./terraform apply

А теперь заменим код нашего контейнера:

container {

image = "gcr.io/node-cluster-243923/nodejs_cluster:latest"

name = "node-js"

}

Проверим результат балансировки на разные ноды(нет переноса строк в конце вывода):

essh@kubernetes-master:~/node-cluster$ curl http://35.246.85.138:80

Nodejs_cluster is working! My host is terraform-nodejs-997fd5c9c-lqg48essh@kubernetes-master:~/node-cluster$ curl http://35.246.85.138:80

Nodejs_cluster is working! My host is terraform-nodejs-997fd5c9c-lhgsnessh@kubernetes-master:~/node-cluster$ curl http://35.246.85.138:80

Nodejs_cluster is working! My host is terraform-nodejs-997fd5c9c-lhgsnessh@kubernetes-master:~/node-cluster$ curl http://35.246.85.138:80

Nodejs_cluster is working! My host is terraform-nodejs-997fd5c9c-lhgsnessh@kubernetes-master:~/node-cluster$ curl http://35.246.85.138:80

Nodejs_cluster is working! My host is terraform-nodejs-997fd5c9c-lhgsnessh@kubernetes-master:~/node-cluster$ curl http://35.246.85.138:80

Nodejs_cluster is working! My host is terraform-nodejs-997fd5c9c-lhgsnessh@kubernetes-master:~/node-cluster$ curl http://35.246.85.138:80

Nodejs_cluster is working! My host is terraform-nodejs-997fd5c9c-lqg48essh@kubernetes-master:~/node-cluster$ curl http://35.246.85.138:80

Nodejs_cluster is working! My host is terraform-nodejs-997fd5c9c-lhgsnessh@kubernetes-master:~/node-cluster$ curl http://35.246.85.138:80

Nodejs_cluster is working! My host is terraform-nodejs-997fd5c9c-lhgsnessh@kubernetes-master:~/node-cluster$ curl http://35.246.85.138:80

Nodejs_cluster is working! My host is terraform-nodejs-997fd5c9c-lhgsnessh@kubernetes-master:~/node-cluster$ curl http://35.246.85.138:80

Nodejs_cluster is working! My host is terraform-nodejs-997fd5c9c-lqg48essh@kubernetes-master:~/node-cluster$

Автоматизируем процесс создания образов, для этого воспользуемся сервисом Google Cloud Build (бесплатен для 5 пользователей и трафике до 50Гб) для создания нового образа при создании в репозитории Cloud Source Repositories (бесплатно на Google Cloud Platform Free Tier) новой версии (тэга). Google Cloud Platform –> Menu –> Инструменты –> Cloud Build –> триггеры –> Включить Cloud Build API –> Начать –> Создать хранилище, которое будет доступно по Google Cloud Platform –> Menu –> Инструменты —> Хранилища исходного кода (Cloud Source Repositories):