terraform-nodejs-6bd565dc6c-mm7lh
esschtolts@gke-node-ks-node-ks-pool-07115c5b-bw15 ~ $ curl 10.4.2.6
terraform-nodejs-6bd565dc6c-mm7lh
esschtolts@gke-node-ks-node-ks-pool-07115c5b-bw15 ~ $ curl 10.4.5.13
terraform-nodejs-6bd565dc6c-hr5vg
esschtolts@gke-node-ks-node-ks-pool-07115c5b-bw15 ~ $ curl 10.4.3.15
terraform-nodejs-6bd565dc6c-8768b
Балансировщик балансируют нагрузку между POD, которые отфильтрованы по соответствию их селекторов в метаинформации и Селектора, указанного в описании балансировщика в секции spec. Все ноды связанны в одну общую сеть, поэтому можно подключиться к любой ноде (я это сделал через SSH WEB- интерфейса GCP в разделе с виртуальными машинами Compute Engine). Обратиться можно как по IP-адресу в контейнере или хосте ноды, так и по хосту сервиса terraform-nodejs в контейнере curl terraform-NodeJS:80, который создаётся внутренним DNS по названию сервиса. Посмотреть внешний IP-адрес EXTERNAL -IP можно как с помощью kubectl у сервиса, так и с помощью веб-интерфейса: GCP > Kubernetes Engine > Сервисы:
essh@kubernetes-master:~/node-cluster$ kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.7.240.1 none> 443/TCP 6h58m
terraform-nodejs LoadBalancer 10.7.246.234 35.197.220.103 80:32085/TCP 5m27s
esschtolts@gke-node-ks-node-ks-pool-07115c5b-bw15 ~ $ curl 10.7.246.234
terraform-nodejs-6bd565dc6c-mm7lh
esschtolts@gke-node-ks-node-ks-pool-07115c5b-bw15 ~ $ curl 10.7.246.234
terraform-nodejs-6bd565dc6c-mm7lh
esschtolts@gke-node-ks-node-ks-pool-07115c5b-bw15 ~ $ curl 10.7.246.234
terraform-nodejs-6bd565dc6c-hr5vg
esschtolts@gke-node-ks-node-ks-pool-07115c5b-bw15 ~ $ curl 10.7.246.234
terraform-nodejs-6bd565dc6c-hr5vg
esschtolts@gke-node-ks-node-ks-pool-07115c5b-bw15 ~ $ curl 10.7.246.234
terraform-nodejs-6bd565dc6c-8768b
esschtolts@gke-node-ks-node-ks-pool-07115c5b-bw15 ~ $ curl 10.7.246.234
terraform-nodejs-6bd565dc6c-mm7lh
essh@kubernetes-master:~/node-cluster$ curl 35.197.220.103
terraform-nodejs-6bd565dc6c-mm7lh
essh@kubernetes-master:~/node-cluster$ curl 35.197.220.103
terraform-nodejs-6bd565dc6c-mm7lh
essh@kubernetes-master:~/node-cluster$ curl 35.197.220.103
terraform-nodejs-6bd565dc6c-8768b
essh@kubernetes-master:~/node-cluster$ curl 35.197.220.103
terraform-nodejs-6bd565dc6c-hr5vg
essh@kubernetes-master:~/node-cluster$ curl 35.197.220.103
terraform-nodejs-6bd565dc6c-8768b
essh@kubernetes-master:~/node-cluster$ curl 35.197.220.103
terraform-nodejs-6bd565dc6c-mm7lh
Теперь перейдем к внедрению сервера NodeJS:
essh@kubernetes-master:~/node-cluster$ sudo ./terraform destroy
essh@kubernetes-master:~/node-cluster$ sudo ./terraform apply
essh@kubernetes-master:~/node-cluster$ sudo docker run -it rm node:12 which node
/usr/local/bin/node
sudo docker run -it rm -p 8222:80 node:12 /bin/bash -c 'cd /usr/src/ && git clone https://github.com/fhinkel/nodejs-hello-world.git &&
/usr/local/bin/node /usr/src/nodejs-hello-world/index.js'
firefox http://localhost:8222
Заменим блок у нашего контейнера на:
container {
image = "node:12"
name = "node-js"
command = ["/bin/bash"]
args = [
"-c",
"cd /usr/src/ && git clone https://github.com/fhinkel/nodejs-hello-world.git && /usr/local/bin/node /usr/src/nodejs-hello-world/index.js"
]
}
Если закомментировать модуль Kubernetes, а в кэше он остаётся, остаётся убрать из кэша лишнее:
essh@kubernetes-master:~/node-cluster$ ./terraform apply
Error: Provider configuration not present
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.nodejs.kubernetes_deployment.nodejs
module.nodejs.kubernetes_service.nodejs
essh@kubernetes-master:~/node-cluster$ ./terraform state rm module.nodejs.kubernetes_deployment.nodejs
Removed module.nodejs.kubernetes_deployment.nodejs
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