Fabricio Sanchez's Blog https://docs.microsoft.com/archive/blogs/fabriciosanchez/feed.xml Wed, 17 Apr 2019 04:10:39 GMT en-US hourly 1 Kubernetes - Overview https://docs.microsoft.com/archive/blogs/fabriciosanchez/kubernetes-overview Mon, 01 May 2017 23:16:05 GMT https://blogs.msdn.microsoft.com/fabriciosanchez/?p=185 "Containerization of applications" undoubtedly is one of the most recurrent subjects discussed during meeting tables with customers. The reasons for this are clear. Just to mention some of those: infrastructure costs reduction, improvement on the applications maintenance process, division of system responsibilities in small and cooperative parts, more efficiency on the autoscaling process, etc. Of course there are many advantages to breaking applications in small parts and put it together running in containers, however, there problems too. Orchestrate microservices distributed across containers inside a cluster isn't a easy task. There's a lot of technical challenges that rises from this scenarios and therefore, must be surpassed. Only to mention some of those, take a look in the following questions:
  • What's is the best approach to dispatch containers?
  • How can we scale containers in a dynamic way inside the cluster?
  • How can we build an efective load balancing between containers inside a cluster?
  • What's the best security model to be applied in container-based applications?
So, in order to help professionals and companies with demands regarding distributed environments based in containers, a lot of orchestrating solutions was developed. Currently are considered the majors:
  • Kubernetes. Orchestrator built by Google engineers. The solution is almost a unanimity between professionals that has been working in a professional (production environments) way with containers. Kubernetes will be the technology target of our studies not only in this post, but along the entire posts serie.
  • DC/OS. Orchestrator built by Apache Foundation. Robust solution, however, bring a great complexity and needs a lot of beside solutions to work appropriately. Used widely in professional environments container-based as well. To know more about DCOS, follow this link.
  • Swarm. Orchestrator built and sustained by Docker. Whether compared with the other two ones, is the one that presents more simplicity regarding the management of the clustered environment itself. Swarm uses the same dictionary that Docker does, so, this is the "why" Swarm is considerable more easy to use. If you would like to learn more about Swarm, follow this link.
There's a lot of other orchestration mechanisms available in the market, however, this three are the most popular among them. Just as quick reminder: starting here (and along the entire posts serie), we will keep our focus exclusively in Kubernetes. We will pass through the plenty resources available in that solution in practical way. So, fasten your seat belt! First things first, right? This way, today we will talk about what Kubernetes is, how it works, we'll understand what kind problems it solves and we'll configure our local environment to start with some "kidding". Let's go?

Why Kubernetes is so cool?

Scaling applications is the kind of task that, in general, the cloud platforms are currently solving very well with platform services (PaaS) or virtual machines (IaaS). However, in a container level, execute this task becomes a bit more complex. This is due the model through the container processes (sharing resources and generating coupling between the "containerized" applications, etc.). In addition, there are other issues, some of which we mentioned earlier in this post. Kubernetes is very interesting because it provides efficient answers to each of these technical challenges and beyond, provides a very useful graphical interface for those professionals who prefer to monitor the behavior of the environment in a visual way. Some critical problems inherent to the cluster of containers solved by Kubernetes:
  • Allows deploy of applications in Docker containers (but not restricted to it) in a efficient and easy way.
  • Efficient auto-scaling across containers.
  • Built-in features for updating existing applications.
  • Debugging of applications already "containerized" in the cluster.
  • Load balancing between equivalent containers.
An important concept at this point: Kubernetes implements all the mechanisms of high availability, isolation and high performance of traditional clusters but this time, applied to containers environment. This way, Kubernetes makes possible the creation of critical and highly concurrent environment (from the perspective of microservices, of course) 100% on top of containers. Not cool? Another very interesting feature regarding Kubernetes: it implements a high level of abstraction. This abstraction (called Pods - don't worry, we'll talk about it with details in a future article) makes the containers completely independent of the machine node. Among the many other advantages, this approach makes ease having one container "see" the other (s) within the cluster. Kubernetes is also open source and its code is available on GitHub: https://github.com/kubernetes/kubernetes.

How Kubernetes works?

A cluster managed by Kubernetes basically has two large operational units: Master and Nodes. Figure 1 presents a conceptual view of a cluster managed by Kubernetes. kubernetes-1

Figure 1. General view about Kubernetes cluster

The "Master" is the element in charge for orchestrating all activities related to containers that run on top of nodes. He is responsible, for example, for scheduling a requested deploy from a clustered application, obtaining information about nodes and pods, among many other occurrences. "Nodes" are machines (which can be either physical or virtual) where effectively the containers managed by Kubernetes run. To be managed by Kubernetes (and therefore be part of the cluster), the nodes must "run" Kubernetes agents (or client extensions) in each instance. It is through this agent that all communication with the master is performed and as a consequence, cluster operations are performed. It's important to mention that each node have at least two memory process:
  1. Kubelet (Kubernetes agent process).
  2. Docker (or other container hypervisor that you want).
We'll talk more about Kubelets in more detail soon, don't worry. The Figure 2 provides an overview of the master upgrade when a new container deployment is requested. kubernetes-2

Figure 2. Containers being delivered by master on the cluster

In the figure above, each of the "rectangles" in olive green and with solid arrows pointing to the Kubernetes master, represents an containerized application that must be delivered in the cluster by the orchestrator. The colored rectangles pointing to the master with dotted arrows are the deployment requests that are made to the master. With these requests, the master is able, in a continuous deployment flow, to schedule the publishing process of the incoming containers. After receiving the deployment request and indicating the containers, the master then schedules and synchronizes their publication in Pods on available nodes (yes, there is an availability check that is also performed by Kubernetes). An important observation at this point: each cluster node communicates with the master by consuming a Kubernetes API exposed by master itself. Who connects to this API is the agent that runs on the node.

Preparing a local environment to run Kubernetes

As mentioned earlier, Kubernetes is a container orchestration solution that implements cluster behavior. As you already know, a cluster must necessarily have nodes (physical or virtual) below it. Only then, above these nodes, can we put the Kubernetes to run. In this way, we need to emulate a cluster-like environment on our local machine to perform the first tests with Kubernetes.

Disclaimer: the process described here will not work for virtualized environments. That's because Minikube does not support nested virtualization. If you running in a environment like this, you should check out another ways to install Kubernetes in your computer.

1. Minikube

In order to emulate such environment, we will use an open source solution called Minikube. Basically what it does is create a virtual cluster with only 1 node using Kubernetes on it to perform the management of the containers at local machine. We can say that Minikube is for the Kubernetes stack just as Lamp is for the PHP stack. Got it? Let's move forward.

2. Setting up Minikube

For this article I will use Linux Ubuntu 16.04 LTS as local operating system environment. If you prefer, you can use other operating environments such as Windows and Linux. These are the minimum requirements for Minikube to work properly on Ubuntu:
  • Mac
  • VT-x/AMD-v virtualization support must be enabled at BIOS.
  • kubectl must be configured in your path. Currently Minikube does support any version of kubectl as long this version is higher than 1.0, however, Minikube team's do recommend the last stable version. You can install kubectl in your computer as pre-req following this steps.
  • Robust internet connection (remember: you'll need to execute images pulling from Docker Hub or other private registry if you do prefer).

3. Installing KVM

Let's start with the KVM installation process on local machine. I'll start verifying if my machine has the virtualization features described in the earlier pre-req list enabled. I'll do that running the command presented by listing 1. If the answer to execution to this command is the number "0" it means that features are not available. If the response is the number "2" , it means that these features are available and enabled.

egrep -c ‘(svm|vmx)’ /proc/cpuinfo

Listing 1. Verifying if virtualization support is enabled on local machine

In order to install KVM and associated packages, run the command presented by Listing 2.

sudo apt-get install qemu-kvm libvirt-bin bridge-utils virt-manager

Listing 2. Installing KVM on Ubuntu

Only admin users in "libvirtd" group has permission to manipulate KVM (creating VMs, etc.). In a general way, when KVM installs, the installation process automatically adds the current user as admin in that group, however, if you would like to add another user as admin in "libvirtd" group, uses the command below (Listing 3) to do that.

sudo adduser {your-user} libvirtd

Listing 3. Adding a new admin user to libvirtd group

Done. Now we can test KVM in order to know if the installation process ran correctly. To do that, execute the command presented by Listing 4.

virsh -c qemu:///system list

Listagem 4. Verifying if KVM installation ran correctly

If everything went well, as a result of executing the command above, you will see a table in the shell indicating that doesn't exist machine created or in execution at this time, as illustrated by Figure 3.

kubernetes-3

Figure 3. KVM installed successfully

4. Installing and configuring kubectl

Kubectl is a CLI (Command Line Interface) for Kubernetes. This means that it brings with a broad vocabulary of commands and associated parameters to interact with the Kubernetes APIs. We will use Kubectl to do practically everything in our cluster with Kubernetes: creating deployments, publishing containers, getting information about the environments, etc. In order to install Kubectl on Ubuntu we will use the "curl" method, traditionally known from Linux users. Listing 5 shows the command to perform this task.

curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl

Listing 5. Installing Kubectl

Done. Kubectl was successfully installed. Now, we need to give the "execute" permission to the Kubectl (which is in the current user directory structure) and also put this executable in the system PATH. Listing 6 presents this process.

chmod +x ./kubectl sudo mv ./kubectl /usr/local/bin/kubectl

Listing 6. Giving permissions to kubectl executable

Once again, done. To verify that Kubectl is working properly, go to the terminal and type "kubectl cluster-info". You should receive the following error message in response: "The connection to the localhost server: 8080 was refused - did you specify the right host or port?". The occurrence of this error is completely normal since we haven't deployed the emulated cluster with Minikube yet. To know which cluster it should manage, kubectl expects a configuration file called "kubeconfig". This file is generated at cluster deployment time. Since we don't have the cluster yet, we don't have this file as well and therefore, we receive the previous error message.

5. Installing Minikube cluster

Now we have the prerequisites already in place, it's time to install Minikube, a tool that will emulate the Kubernetes cluster in my computer. To do this, use the command provided by Listing 7.

curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.18.0/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/

Listagem 7. Installing Minikube

Done. Minikube installed. Now, to check if tool is operational, go to the terminal and enter the "minikube start" command. By doing this, you can see minikube download the default image to the cluster and perform it startup flow.

I will stop here for while. In the next post we will see in a practical way some fundamental resources related to Kubernetes and so that it is possible to orchestrate the container cluster in an effective way. See you there!

]]> Welcome to MVP Reconnect Program https://docs.microsoft.com/archive/blogs/fabriciosanchez/welcome-to-mvp-reconnect-program Tue, 01 Nov 2016 20:54:44 GMT https://blogs.msdn.microsoft.com/fabriciosanchez/?p=135 this link to learn more. You must know - The MVP program is based in cycles. After 1st nomination process, the MVP must maintain the regularity, quantity and quality of his contributions. if by either one reason or other the MVP can't accomplish this commitment, that professional must leave the formal program (he leaves it benefits as well) however, he never lost his MVP status. Today's post isn't technical but is equally important, especially for those that as you are passionate by technical communities and by either reason or other doesn't be part of MVP team. I'm talking about this because we just had an important announcement few minutes ago: a new global program for communities called "MVP Reconnect".

About the newest program

mvp-reconnect-logo As the name already suggests, this new program intent to bring former MVPs once again to communities universe creating a new environment to exchange information and keep in touch with Microsoft. As the MVPs says: "Once MVP, ever MVP". You can see the oficial announcement accomplished on Scott Guggs blog's following this link. As a community formal program (following examples as MVP, MSP, etc) the Reconnect will offer some exclusive benefits for all those who chose be part. Some featured benefits are: welcome kit including a medal of honor (see Figure 1), exclusive access to a private social network designed to this group and another stuff. For me as a former MVP, the most important benefit is keep in touch with global MVP program and the reason to say this is "We don't know anything about the future, right?!" (if you know what I mean).

20161101_083349

Figure 1. Medal of honor from welcome kit

We know that a great number of professional has had left the program a long ago, however, they would like to come back to the communities environment. Personally I believe that this program can redeem that community spirit and bring themselves to game once again.

Yes, Reconnect program is an official program and therefore managed by Microsoft but with a nature completely different itself. The program has an advisory board compound by community members. This board will evaluate the whole aspects of the program itself and propose (if applicable) changes, new features, etc. Every person inside the program is eligible to be part of the board through an "application process" to this.

How to participate

Microsoft is requiring basically two aspects in order to accept a new member:
  1. Person must being an MVP at least for one complete cycle
  2. The candidate mustn't have any problem with NDA while MVP
Whether you attend to this combined requirement, you are eligible to join. To do this you must follow the steps below:
  • Access the oficial Reconnect program website through this link
  • Click @ "Join" tab
  • Fill all requested fields and click @ "Send".
Microsoft will return with the (dis)approval up to 5 business days. Stay tuned: Microsoft could reach you in order to get additional information about you application to the program.

FAQ

Wearing the t-shirt of a former MVP and thinking about this new program, few questions came to my mind. As I already know its answers (I personally verified it with the global program staff) I've decided share this here.
  1. I was MVP in the past. I'd love to participate in the Reconnect but right now I've been working in a company that competes directly with Microsoft (AWS, Oracle, etc.). Can I join the program? Yes, you can. There is no NDA in MVP Reconnect program thus, all discussions and interactions can be shared by all. You are more than welcome.
  2. I was MVP in the past but in a technology/category that today is doesn't officially supported in the program anymore. Can I participate? Yes, absolutely. The MVP Reconnect program is completely agnostic in terms of technology. Any eligible former MVP in whatever company and technology, can join to the other professionals in this new community.
If you have any further questions, feel free to send it to me. I'll update this post with the respective answers. That's it. You guys welcome to MVP Reconnect program. Enjoy!]]> Welcome to my new personal project: An english blog https://docs.microsoft.com/archive/blogs/fabriciosanchez/fabricio-blog-english Wed, 26 Oct 2016 16:41:14 GMT https://blogs.msdn.microsoft.com/fabriciosanchez/?p=35 Welcome to the english version of my personal blog. For along time I've been thinking about the creation of a english version for my blog posts in order to amplify the spread of message. This way, with this post I'm inaugurating this new content channel. I don't have the intention translate portuguese content available in fabriciosanchez.com.br. This website (fabriciosanchez.com.br) will be continuously updated, this way, if you like the content available there, you can stay calm, I will continuing publishing new articles there. The initial idea with this new blog (this can be changed in the future, who knows :-)) is maintain two different environments with different contents and goals. To delivery this new project I opted up by the MSDN Blogs platform (exclusive for Microsoft FTEs). This decision was made by different and important reasons. Featured: is 100% based on Wordpress, is automatically scalable and is auto-managed by Microsoft. This blog is accessible through two different endpoints (as you can see it below): Cool? Take note about it.

About the content and frequency

Regarding the content themes, they will continue the same. I will write a lot about cloud computing (focusing in Azure platform of course), development scenarios, DevOps, etc. Occasionally I intent to write about career, entrepreneurship and another things that I've been wanting. Regarding frequency, I'll don't have one and don't intent to have it. The same occurs with my portuguese blog. Depending of availabily of time, I will produce the content so, don't wait a pattern in terms of frequency of new content here, ok? This way, you are invited to add this blog to your feed reader or inside your preferred blogs list :-). This blog]]>