IT Cloud
Шрифт:
esschtolts @ gke-node-ks-default-pool-2dc50760-757p ~ $ docker exec -it 8d1cf9ef44e6 cat /usr/share/Nginx/html/index.html
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
The Balancers load balance between PODs that are filtered by matching their selectors in the meta information and the Selector specified in the balancer description in the spec section . All nodes are connected to one common network, so you can connect to any node (I did this via SSH of the GCP WEB interface in the section with Compute Engine virtual machines). You can address both the IP address in the container or node host, and the host of the terraform-nodejs service in the terraform-NodeJS: 80 curl container , which is created by the internal DNS by the name of the service. You can view the external IP address EXTERNAL -IP both using kubectl at the service and using the web interface: GCP -> Kubernetes Engine -> Services:
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
Now let's move on to implementing the NodeJS server:
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&&
/ usr / local / bin / node /usr/src/nodejs-hello-world/index.js'
firefox http: // localhost: 8222
Let's replace the block in our container with:
container {
image = "node: 12"
name = "node-js"
command = ["/ bin / bash"]
args = [
"-c",
"cd / usr / src / && git clone&& / usr / local / bin / node /usr/src/nodejs-hello-world/index.js "
]
}
If you comment out a Kubernetes module, and it remains in the cache, it remains to remove the excess from the cache:
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 Cluster Reliability and Automation
For a general overview of automation, seehtml # 0. We will dwell in more detail. Now if we run the ./terraform destroy and try to recreate the entire infrastructure from the beginning , we will get errors. Errors are received due to the fact that the order of creation of services is not specified and terraform, by default, sends requests to the API in 10 parallel threads, although this can be changed by specifying or removing the -parallelism = 1 switch during application or removal . As a result, Terraform tries to create Kubernetes services (Deployment and service) on servers (node-pull) that do not yet exist, the same situation when creating a service that requires proxying a Deployment that has not yet been created. By telling Terraform to request the API in a single thread ./terraform apply -parallelism = 1, we reduce possible provider-side restrictions on the frequency of API calls, but we do not solve the problem of lack of order in which entities are created. We will not comment out dependent blocks and gradually uncomment and run ./terraform apply , nor will we run our system piece by piece by specifying specific blocks ./terraform apply -target = module.nodejs.kubernetes_deployment.nodejs . We will indicate in the code the dependencies themselves on the initialization of the variable, the first of which is already defined as external var.endpoint , and the second we will create locally:
locals {
app = kubernetes_deployment.nodejs.metadata.0.labels.app
}
Now we can add dependencies to the code depends_on = [var.endpoint] and depends_on = [kubernetes_deployment .nodejs] .
The service unavailability error may also appear: Error: Get https: //35.197.228.3/API/v1 …: dial tcp 35.197.228.3:443: connect: connection refused , then the connection time has been exceeded, which is 6 minutes by default (3600 seconds), but here you can just try again.
Now let's move on to solving the problem of the reliability of the container, the main process of which we run in the command shell. The first thing we will do is separate the creation of the application from the launch of the container. To do this, you need to transfer the entire process of creating a service into the process of creating an image, which can be tested, and by which you can create a service container. So let's create an image: