IT Cloud. Eugeny Shtoltc

Чтение книги онлайн.

СКАЧАТЬ READY STATUS RESTARTS AGE

      liveness-exec 0/1 Running 0 15s

      NAME READY STATUS RESTARTS AGE

      liveness-exec 1/1 Running 0 26s

      esschtolts @ cloudshell: ~ / bitrix (essch) $ kubectl get pods

      NAME READY STATUS RESTARTS AGE

      liveness-exec 0/1 Running 0 53s

      esschtolts @ cloudshell: ~ / bitrix (essch) $ kubectl get pods

      NAME READY STATUS RESTARTS AGE

      liveness-exec 0/1 Running 0 1m

      esschtolts @ cloudshell: ~ / bitrix (essch) $ kubectl get pods

      NAME READY STATUS RESTARTS AGE

      liveness-exec 1/1 Running 1 1m

      Kubernetes also provides a startup, which remakes the moment when you can turn the readiness and liveness of the sample into work. This is useful if, for example, we are downloading an application. Let's consider in more detail. Let's take www.katacoda.com/courses/Kubernetes/playground and Python for the experiment. There are TCP, EXEC and HTTP, but HTTP is better, as EXEC spawns processes and can leave them as "zombie processes". In addition, if the server provides interaction via HTTP, then it is against it that you need to check (https://www.katacoda.com/courses/kubernetes/playground):

      controlplane $ kubectl version –short

      Client Version: v1.18.0

      Server Version: v1.18.0

      cat << EOF> job.yaml

      apiVersion: v1

      kind: Pod

      metadata:

      name: healt

      spec:

      containers:

      – name: python

      image: python

      command: ['sh', '-c', 'sleep 60 && (echo "work"> health) && sleep 60 && python -m http.server 9000']

      readinessProbe:

      httpGet:

      path: / health

      port: 9000

      initialDelaySeconds: 3

      periodSeconds: 3

      livenessProbe:

      httpGet:

      path: / health

      port: 9000

      initialDelaySeconds: 3

      periodSeconds: 3

      startupProbe:

      exec:

      command:

      – cat

      – / health

      initialDelaySeconds: 3

      periodSeconds: 3

      restartPolicy: OnFailure

      EOF

      controlplane $ kubectl create -f job.yaml

      pod / healt

      controlplane $ kubectl get pods # not loaded yet

      NAME READY STATUS RESTARTS AGE

      healt 0/1 Running 0 11s

      controlplane $ sleep 30 && kubectl get pods # not loaded yet but image is already zipped

      NAME READY STATUS RESTARTS AGE

      healt 0/1 Running 0 51s

      controlplane $ sleep 60 && kubectl get pods

      NAME READY STATUS RESTARTS AGE

      healt 0/1 Running 1 116s

      controlplane $ kubectl delete -f job.yaml

      pod "healt" deleted

      Self-diagnosis of micro service application

      Let's consider how the probe works on the example of the microservice application bookinfo, which is part of Istio as an example: https://github.com/istio/istio/tree/master/samples/bookinfo. The demo will be at www.katacoda.com/courses/istio/deploy-istio-on-kubernetes. After deployment, it will be available

      Infrastructure management

      Although Kubernetes also has its own graphical interface – a UI dashboard, it does not provide other than monitoring and simple actions. More possibilities are given by OpenShift, providing a combination of graphic and text creation. A full-fledged product with a formed Google ecosystem in Kubernetes does not provide, but provides a cloud solution – Google Cloud Platform. However, there are third-party solutions, such as Open Shift and Rancher, that allow you to use it fully through a graphical interface at its own facilities. If desired, of course, you can sync with the cloud.

      Each product is often not API compatible with each other, the only known exception being Mail. Cloud, which claims support for Open Shift. But, there is a third-party solution that implements the infrastructure as code approach and supports the API of most well-known ecosystems – Terraform. He, like Kubernetes, applies the concept of infrastructure as code, but not to containerization, but to virtual machines (servers, networks, disks). The Infrastructure as Code principle implies a declarative configuration – that is, a description of the result without explicitly specifying the actions themselves. Upon activation, the configuration (in Kubernetes it is kubectl apply -f name_config .yml , and in Hashicorp Terraform it is terraform apply ) of the system is brought into line with the configuration files, when the configuration or infrastructure changes, the infrastructure in the conflicting parts is brought into line with its declaration, when the system itself decides how to achieve this, and the behavior can be different, for example, when the meta information in the POD changes, it will be changed, and when the image changes, the POD will be deleted and created as a new one. If, before that, we created the server infrastructure for containers in an imperative form using the gcloud command of the Google Cloud Platform (GCP) public cloud, now we will consider how to create a similar configuration using the configuration in the declarative description of the pattern infrastructure as code using the universal Terraform tool that supports cloud GCP.

      Terraform did not appear out of nowhere, but became a continuation of the long history of the emergence of software products for configuring and managing server infrastructure, I will list in the order of appearance and transition:

      ** CFN;

      ** Pupet;

      ** Chef;

      ** Ansible;

      ** Cloud AWS API, Kubernetes API;

      * IasC: Terraform does not depend on the type of infrastructure (it supports more СКАЧАТЬ