The second section, instead, is dedicated to configure the service and, as such, you have less options. The expected outcome is that, like we have seen in the previous article when we have used the kubectl scale command, Kubernetes will take care of creating (and always keeping alive) 5 pods out of this deployment. We have also specified that we want 5 replicas of this application as desired state. We have defined a template with a single container, called web, which is based on the nginx image.
Since it's used to setup a deployment, the spec section contains all the information about the application we want to deploy and its desired state. Let's take a closer look at the first section. For example, you can notice how the spec section of the first resource ( Deployment) is different from the one of the second resource ( Service). The content of this section can be very different, based on the kind of resource.
#Docker for windows kubernetes cluster full
spec contains the full specification of the resource we want to deploy.In this case we're setting a name to make it easyer to identify the resource. metadata allows to specify some information that are helpful to describe the object.
We have to specify each Kubernetes object, which means that a single layer of application is typically composed by at least two objects: a deployment (with the app definition) and a service (to expose it to the other applications or to the outside world). This is a big difference compared to Docker Compose files. kind specifices which kind of Kubernetes resource we want to deploy.Let's create a YAML file to achieve the same goal: - apiVersion: apps/v1beta1 kind: Deployment metadata: name: web spec: replicas: 5 template: metadata: labels: app: web spec: containers: - name: web image: nginx ports: - containerPort: 80 - apiVersion: v1 kind: Service metadata: name: web spec: type: LoadBalancer ports: - port: 80 selector: app: webĮach definition is composed by three items: In the previous post, as first step, we have manually created a deployment using the kubectl run command, followed by kubectl expose to create a service so that we could connect to the web server from our machine. Then, we're going to see how can easily scale our application in case of heavy load.
In this post we're going to do exactly that: we're going to write a Kubernetes YAML definition to map our application and we're going to deploy it in the cloud, using Azure Kubernetes Service. When you use a real Kubernetes infrastructure, you can't leverage Docker Compose files, but you need to create a YAML file which follows the Kubernetes specification. However, it still wasn't completely realistic, because we were taking advantage of the Kubernetes engine built-in inside Docker, which allowed us to use a Docker Compose file to describe the deployment. The second sample was closer to the real world, since we have used a more formal definition (the Docker Compose file) to deploy the whole architecture of our application. However, in a real scenario, you will hardly have to manually create deployments and services. If you remember, as first step we have manually created a deployment using the NGINX image published on Docker Hub. However, the samples we used in the previous post have been helpful to understand the basics, but they aren't realistic. In the previous post we have learned some basic concepts of Kubernetes and how it helps us to leverage Docker containers in a better way.
0 kommentar(er)
