{"id":1089,"date":"2019-01-18T11:27:57","date_gmt":"2019-01-18T11:27:57","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw93\/?p=1089"},"modified":"2019-01-24T03:50:58","modified_gmt":"2019-01-24T03:50:58","slug":"getting-microservices-deployments-on-kubernetes-with-rancher","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw93\/index.php\/2019\/01\/18\/getting-microservices-deployments-on-kubernetes-with-rancher\/","title":{"rendered":"Getting Microservices Deployments on Kubernetes with Rancher"},"content":{"rendered":"

Most people running Docker in production use it as a way to build and
\nmove deployment artifacts. However, their deployment model is still very
\nmonolithic or comprises of a few large services. The major stumbling
\nblock in the way of using true containerized microservices is the lack
\nof clarity on how to manage and orchestrate containerized workloads at
\nscale. Today we are going to talk about building a Kubernetes based
\nmicroservice deployment. Kubernetes<\/a> is the open
\nsource successor to Google\u2019s long running Borg project, which has been
\nrunning such workloads at scale for about a decade. While there are
\nstill some rough edges, Kubernetes represents one of the most mature
\ncontainer orchestration systems available today.<\/p>\n

[[Launching Kubernetes Environment ]]<\/h3>\n

[[You can take a look at the
\n]]Kubernetes
\nDocumentation<\/a>
\nfor instructions on how launch a Kubernetes cluster in various
\nenvironments. In this post, I\u2019m going to focus on launching Rancher\u2019s
\ndistribution of Kubernetes<\/a> as an
\nenvironment within the Rancher container management
\nplatform<\/a>. We\u2019ll start by setting up
\na Rancher server as described
\nhere<\/a> and
\nselect Environment\/Default > Manage Environments > Add Environment<\/em>.
\nSelect Kubernetes<\/em> from Container Orchestration options and create your
\nenvironment. Now select Infrastructure > Hosts > Add Host<\/em> and launch
\na few nodes for Kubernetes to run on. Note: we recommend adding at least
\n3 hosts, which will run the Rancher agent container. Once the hosts come
\nup, you should see the following screen, and in a few minutes your
\ncluster should be up and ready.<\/p>\n

There are lots of advantages to running Kubernetes within Rancher.
\nMostly, it just makes the deployment and management dramatically easier
\nfor both users and the IT team. Rancher automatically implements an HA
\nimplementation of etcd for the Kubernetes backend, and deploys all of
\nthe necessary services onto any hosts you add into this environment. It
\nsets up access controls, and can tie into existing LDAP and AD
\ninfrastructure easily. Rancher also automatically implements container
\nnetworking and load balancing services for Kubernetes. Using Rancher,
\nyou should have an HA implementation of Kubernetes in a few minutes.<\/p>\n

\"kubernetes\nlaunching\"<\/a><\/p>\n

Namespaces<\/h3>\n

Now that we have our cluster running, let\u2019s jump in and start going
\nthrough some basic Kubernetes resources. You can access the Kubernetes
\ncluster either directly through the kubectl CLI, or through the Rancher
\nUI. Rancher\u2019s access management layer controls who can access the
\ncluster, so you\u2019ll need to generate an API key from the Rancher UI
\nbefore accessing the CLI.<\/p>\n

The first Kubernetes resource we are going to look at is namespaces.
\nWithin a given namespace, all resources must have unique names. In
\naddition, labels used to link resources are scoped to a single
\nnamespace. This is why namespaces can be very useful for creating
\nisolated environments on the same Kubernetes cluster. For example, you
\nmay want to create an Alpha, Beta and Production environment for your
\napplication so that you can test latest changes without impacting real
\nusers. To create a namespace, copy the following text into a file called
\nnamespace.yaml and run the kubectl create -f namespace.yaml command to
\ncreate a namespace called beta.<\/p>\n

kind: Namespace
\napiVersion: v1
\nmetadata:
\nname: beta
\nlabels:
\nname: beta<\/p>\n

You can also create, view and select namespaces from the Rancher UI by
\nusing the Namespace menu on the top menu bar.
\n\"namespaces\"<\/a><\/p>\n

You can use the following command to set the namespace in for CLI
\ninteractions using kubectl:<\/p>\n

$ kubectl config set-context Kubernetes –namespace=beta.<\/p>\n

To verify that the context was set currently, use the config view
\ncommand and verify the output matches the namespace you expect.<\/p>\n

$ kubectl config view | grep namespace command
\nnamespace: beta<\/p>\n

Pods<\/h3>\n

Now that we have our namespaces defined, let\u2019s start creating
\nresources. The first resource we are going to look at is a Pod. A group
\nof one or more containers is referred to by Kubernetes as a pod.
\nContainers in a pod are deployed, started, stopped, and replicated as a
\ngroup. There can only be one pod of a given type on each host, and all
\ncontainers in the pod are run on the same host. Pods share network
\nnamespace and can reach each other via the localhost domain. Pods are
\nthe basic unit of scaling and cannot span across hosts, hence it\u2019s
\nideal to make them as close to single workload as possible. This will
\neliminate the side-effects of scaling a pod up or down as well as
\nensuring we don\u2019t create pods that are too resource intensive for our
\nunderlying hosts.<\/p>\n

Lets define a very simple pod named mywebservice<\/em> which has one
\ncontainer in its spec named web-1-10<\/em> using the nginx<\/em> container image
\nand exposing the port 80. Add the following text into a file called
\npod.yaml.<\/p>\n

apiVersion: v1
\nkind: Pod
\nmetadata:
\nname: mywebservice
\nspec:
\ncontainers:
\n– name: web-1-10
\nimage: nginx:1.10
\nports:
\n– containerPort: 80<\/p>\n

Run the kubectl create command to create your pod. If you set your
\nnamespace above using the set-context command then the pods will be
\ncreated in the specified namespace. You can verify the status of your
\npod by running the get pods<\/em> command. Once you are done we can delete
\nthe pod by running the kubectl delete command.<\/p>\n

$ kubectl create -f .\/pod.yaml
\npod “mywebservice” created
\n$ kubectl get pods
\nNAME READY STATUS RESTARTS AGE
\nmywebservice 1\/1 Running 0 37s
\n$ kubectl delete -f pod.yaml
\npod “mywebservice” deleted<\/p>\n

You should also be able see your pod in the Rancher UI by selecting
\nKubernetes > Pods<\/em> from the top menu bar.<\/p>\n

\"Screen<\/a><\/p>\n

Replica Sets<\/h3>\n

Replica Sets, as the name implies, define how many replicas of each pod
\nwill be running. They also monitor and ensure the required number of
\npods are running, replacing pods that die. Note that replica sets are a
\nreplacement for Replication Controllers – however, for most
\nuse-cases you will not use Replica Sets directly but instead use
\nDeployments. Deployments wrap replica sets and add the the
\nfunctionality to do rolling updates to your application.<\/p>\n

Deployments<\/h3>\n

Deployments are a declarative mechanism to manage rolling updates of
\nyour application. With this in mind, let\u2019s define our first deployment
\nusing the pod definition above. The only difference is that we take out
\nthe name parameter, as a name for our container will be auto-generated
\nby the deployment. The text below shows the configuration for our
\ndeployment; copy it to a file called deployment.yaml.<\/p>\n

apiVersion: extensions\/v1beta1
\nkind: Deployment
\nmetadata:
\nname: mywebservice-deployment
\nspec:
\nreplicas: 2 # We want two pods for this deployment
\ntemplate:
\nmetadata:
\nlabels:
\napp: mywebservice
\nspec:
\ncontainers:
\n– name: web-1-10
\nimage: nginx:1.10
\nports:
\n– containerPort: 80<\/p>\n

Launch your deployment using the kubectl create command and then verify
\nthat the deployment is up using the get deployments command.<\/p>\n

$ kubectl create -f .\/deployment.yaml
\ndeployment “mywebservice-deployment” create
\n$ kubectl get deployments
\nNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
\nmywebservice-deployment 2 2 2 2 7m<\/p>\n

You can get details about your deployment using the describe deployment
\ncommand. One of the useful items output by the describe command is a set
\nof events. A truncated example of the output from the describe command
\nis shown below. Currently your deployment should have only one event
\nwith the message: Scaled up replica set … to 2.<\/p>\n

$ kubectl describe deployment mywebservice
\nName: mywebservice-deployment
\nNamespace: beta
\nCreationTimestamp: Sat, 13 Aug 2016 06:26:44 -0400
\nLabels: app=mywebservice
\n…..
\n….. Scaled up replica set mywebservice-deployment-3208086093 to 2<\/p>\n

Scaling Deployments<\/h3>\n

You can modify the scale of the deployment by updating the
\ndeployment.yaml file from earlier to replace replicas: 2
\nwith replicas: 3 and run the apply command shown below. If you run
\nthe describe deployment command again you will see a second event with
\nthe message:
\nScaled up replica set mywebservice-deployment-3208086093 to 3.<\/p>\n

$ kubectl apply -f deployment.yaml
\ndeployment “mywebservice-deployment” configured<\/p>\n

Updating Deployments<\/h3>\n

You can also use the apply command to update your application by
\nchanging the image version. Modify the deployment.yaml file from earlier
\nto replace image: nginx:1.10 to image: nginx:1.11 and run the
\nkubectl apply command. If you run the describe deployment command again
\nyou will see new events whose messages are shown below. You can see how
\nthe new deployment (2303032576) was scaled up and the old deployment
\n(3208086093) was scaled down and the in steps. The total number of pods
\nacross both deployments is kept constant however the pods are gradually
\nmoved from the old to the new deployments. This allows us to run
\ndeployments under load without service interruption.<\/p>\n

Scaled up replica set mywebservice-deployment-2303032576 to 1
\nScaled down replica set mywebservice-deployment-3208086093 to 2
\nScaled up replica set mywebservice-deployment-2303032576 to 2
\nScaled down replica set mywebservice-deployment-3208086093 to 1
\nScaled up replica set mywebservice-deployment-2303032576 to 3
\nScaled down replica set mywebservice-deployment-3208086093 to 0<\/p>\n

If during or after the deployment you realize something is wrong and the
\ndeployment has caused problems you can use the rollout command to undo
\nyour deployment change. This will apply the reverse operation to the one
\nabove and move load back to the previous version of the container.<\/p>\n

$ kubectl rollout undo deployment\/mywebservice-deployment
\ndeployment “mywebservice-deployment” rolled back<\/p>\n

Health check<\/h3>\n

With deployments we have seen how to scale our service up and down, as
\nwell as how to do deployments themselves. However, when running services
\nin production, it\u2019s also important to have live monitoring and
\nreplacement of service instances when they go down. Kubernetes provides
\nhealth checks to address this issue. Update the deployment.yaml file
\nfrom earlier by adding a livenessProbe configuration in the spec
\nsection. There are three types of liveness probes, http<\/em>, tcp<\/em> and
\ncontainer exec<\/em>. The first two will check whether Kubernetes is able to
\nmake an http or tcp connection to the specified port. The container exec
\nprobe runs a specified command inside the container and asserts a zero
\nresponse code. In the snippet shown below, we are using the http probe
\nto issue a GET request to port 80 at the root URL.<\/p>\n

apiVersion: extensions\/v1beta1
\nkind: Deployment
\nmetadata:
\nname: mywebservice-deployment
\nspec:
\nreplicas: 3
\ntemplate:
\nmetadata:
\nlabels:
\napp: mywebservice
\nspec:
\ncontainers:
\n– name: web-1-11
\nimage: nginx:1.11
\nports:
\n– containerPort: 80
\nlivenessProbe:
\nhttpGet:
\npath: \/
\nport: 80
\ninitialDelaySeconds: 30
\ntimeoutSeconds: 1<\/p>\n

If you recreate your deployment with the additional helthcheck and run
\ndescribe deployment, you should see that Kubernetes now tells you that 3
\nof your replicas are unavailable. If you run describe again after the
\ninitial delay period of 30 seconds, you will see that the replicas are
\nnow marked as available. This is a good way to make sure that your
\ncontainers are healthy and to give your application time to come up
\nbefore Kubernetes starts routing traffic to it.<\/p>\n

$ kubectl create -f deployment.yaml
\ndeployment “mywebservice-deployment” created
\n$ kubectl describe deployment mywebservice
\n…
\nReplicas: 3 updated | 3 total | 0 available | 3 unavailable<\/p>\n

Service<\/h3>\n

Now that we have a monitored, scalable deployment which can be updated
\nunder load, it\u2019s time to actually expose the service to real users.
\nCopy the following text into a file called service.yaml. Each node in
\nyour cluster exposes a port which can route traffic to the replicas
\nusing the Kube Proxy.<\/p>\n

apiVersion: v1
\nkind: Service
\nmetadata:
\nname: mywebservice
\nlabels:
\nrun: mywebservice
\nspec:
\ntype: NodePort
\nports:
\n– port: 80
\nprotocol: TCP
\nname: http
\nselector:
\napp: mywebservice<\/p>\n

With the service.yaml file we create service using the create command
\nand then we can lookup the NodePort using the describe service command.
\nFor example, in my service I can access the application on port 31673 on
\nany of my Kubernetes\/Rancher agent nodes. Kubernetes will route traffic
\nto available nodes automatically if nodes are scaled up and down, become
\nunhealthy or are relaunched.<\/p>\n

$ kubectl create -f service.yaml
\nservice “mywebservice” created
\n$ kubectl describe service mywebservice | grep NodePort
\nNodePort: http 31673\/TCP<\/p>\n

In today\u2019s article, we looked some basic Kubernetes resources including
\nNamespaces, Pods, Deployments and Services. We looked at how to scale
\nour application up and down manually as well as how to perform rolling
\nupdates of our application. Lastly, we looked at configuring services in
\norder to expose our application externally. In subsequent articles, we
\nwill be looking at how to use these together to orchestrate a more
\nrealistic deployment. We will look at the resources covered today in
\nmore detail, including how to setup SSL\/TLS termination, multi-service
\ndeployments, service discovery and how the application would react to
\nfailures scenarios.<\/p>\n

Note: Part
\n2<\/a>
\nof this series is now available!<\/em><\/p>\n

Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Most people running Docker in production use it as a way to build and move deployment artifacts. However, their deployment model is still very monolithic or comprises of a few large services. The major stumbling block in the way of using true containerized microservices is the lack of clarity on how to manage and orchestrate … <\/p>\n

Continue reading “Getting Microservices Deployments on Kubernetes with Rancher”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-1089","post","type-post","status-publish","format-standard","hentry","category-kubernetes"],"_links":{"self":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/1089","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/comments?post=1089"}],"version-history":[{"count":1,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/1089\/revisions"}],"predecessor-version":[{"id":1120,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/1089\/revisions\/1120"}],"wp:attachment":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/media?parent=1089"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/categories?post=1089"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/tags?post=1089"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}