TuxLabs LLC

All things DevOps

Tag: Google Cloud Platform

Setting up Kubernetes to manage containers on the Google Cloud Platform

Published / by tuxninja / Leave a Comment

These days the pace of innovation in DevOps can leave you feeling like you’re jogging on a treadmill programmed to run faster than Usain Bolt. Mastery requires hours of practice and the last decade in DevOps has not allowed for it. Before gaining 10 years of experience running virtual machines using VmWare in private data-centers, private cloud software like Openstack and Cloudstack came along, and just when you and your team painfully achieved a stable install you were told running virtual machines in public clouds like AWS, GCP, and Azure is the way forward. By the time you got there it was time to switch to containers, and before you can fully appreciate those, server-less functions are on the horizon, but I digress. If you want to know more about server-less functions, see my previous article on AWS Lambda. Instead, this article will focus on running Docker containers inside of a Kubernetes cluster on Google’s Cloud Platform.

Linux Containers, which were recently popularized by Docker need something to help manage them and while there are many choices, Kubernetes the open-sourced container management system from Google is the undisputed king at this time. Given that Kubernetes was started by Google, it should be expected that the easiest way to install it is using Google’s Cloud Platform (GCP). However, Openshift from Redhat also provides a nice batteries included abstraction if you need to get up and running quickly as well as kops.

Pre-Requisites

The main pre-requisites you need for this article is a Google Cloud Platform account and installing the gcloud utility via the SDK.

In addition, you need some form of a computer with Internet connectivity, some typing skills, a brain that can read, and a determination to finish…For now I will give you the benefit of the doubt and assume you have all of these. It is also nice to have your beverage of choice while you do this, a fine tea, ice cold beer, or glass of wine will work, but for Cancer’s sake please skip the sugar.

Here is where I would normally insert a link to facts on sugar and Cancer’s link, but I literally just learned I would be spreading rumors… Fine drink your Kool-Aid, but don’t blame me for your calories.

The Build Out of our Self Healing IRC Server Hosting Containers

I lied dude, IRC is so 1995 and unfortunately, ICQ’s been dead and Slack won’t let me host their sexy chat application with game like spirit and better jokes than Kevin Heart. So…sorry to excite you… but I guess I will fallback to the docs here and install Nginx like us newb’s are supposed to.

Numero Uno (Step 1 dude)

As part of the installation of the gcloud / SDK you should have ran gcloud init, which requires you to login with your Google account via a web browser.

After clicking allow in your browser you will be logged in…and asked about creating an initial Project. Say yes (type Y and hit enter).

Sweet your Project is now created. In order to use the Google Cloud API’s you must first enable access by visiting https://console.developers.google.com/apis/api/replicapool.googleapis.com/overview and clicking enable.

That will take a minute. Once completed you will be able to run gcloud commands against your Project. We can set the default region for our project like so:

If you get an error here, stop being cheap and link your project to your billing account in the console.

Additionally, we want to set the default region/zone for gcloud commands like so:

Numero Dos Equis

We need to install kubectl so we can interact with Kubernetes.

Once that is done, quickly realize someone spent an obscene amount of time making that install as pretty as it was without using ncurses. Shout out to that geek.

Numero Tres Deliquentes

Time to create our Kubernetes cluster. Run this command and “it’s going to be LEGEND….Wait for it….

And I hope you’re not lactose intolerant cause the second half of that word is DAIRY.” – NPH

Numero (Audi) Quattro

Now you should be able to see all running Kubernetes services in your cluster like so:

And we can see the pods like so:

Numero Cinco (de Mayo)

You now have an active Kubernetes cluster. That is pretty sweet huh? Make sure you take the time to check out what’s running under the hood in the Google Compute Engine as well.

Ok, for our final act, I promised Nginx…sigh…Let’s get this over with!

Step 1, create this nifty YAML file:

Save it as deployment.yaml, then apply it!

We can describe our deployment like this:

And we can take a gander at the pods created for this deployment

To see info about a specific pod run: 

Finally it’s time to expose Nginx to the Internet

Check the status of our service

Note the EXTERNAL-IP is in a pending state, once the LoadBalancer is created, this will have an IP address.

And were all done, congratulations! 🙂

In Closing…

Kubernetes is cool as a fan, and setting it up on GCP is almost as easy as pressing the big EASY button. We have barely scraped the surface here so for continued learning I recommend buying Kubernetes Up & Running by Kelsey Hightower, Brendan Burns and Joe Beda. I would follow these folks on twitter, and in addition follow Kubernetes Co-Founder Tim Hockin as well as former Docker, Google, and now Microsoft employee/guru of all things containers Jessie Frazelle.

After you are done following these inspirational leaders in the community go to youtube and watch every Kelsey Hightower video you can find. Kelsey Hightower is perhaps the tech communities best presenter and no one has done more to educate and bring Kubernetes to the mainstream than Kelsey. So a quick shout out and thank you to Kelsey for his contributions to the community. In his honor here are two of my favorite videos from Kelsey. [ one ] [ two ].

AWS, Google Cloud, Azure and the singularity of the future Internet

Published / by tuxninja / Leave a Comment

I have just left AWS re-invent and I wanted to give my brief thoughts on the future of cloud computing. I believe in the next few years the shift we have been witnessing will be completed. That is to say that the thousands of enterprises and small businesses alike will finish their migrations to public clouds, simply because the benefits are far too great. Less people, less hardware, less glue code, more functionality, more value etc. AWS will be the dominant public cloud for the next couple of years minimum due to their first to market advantage and If you look at the announcements at re-invent 2016, you see a series of products that solve common problems. In fact a lot of the “innovations” AWS announced today, replace many SaaS solutions who ironically (or maybe not so much) are hosted on AWS. None of this concerns me, this is great disruption. AWS is teaching these businesses to move even further up and away from creating tooling for DevOps as products (they will take care of that) and focus on products that provide value differently, like sifting through massive amounts of data, increasing the quality and providing intelligence from that data. This is all great, and it’s definitely where things are headed, kudos to Amazon for guiding folks.

BUT here is what is disturbing it to me, and it’s seems like no one talks about it. It’s as if they can’t see the elephant in the room.

The elephant in the room is that every company in the world is converging on a fewer number of physical devices, paths, datacenters etc. This means the global failure domains that should be distributed in nature are actually becoming more centralized.

If you really think about it, Cloud was always the return of Utility computing (mainframes) etc and as we go down this journey it’s becoming more evident it’s simply a more distributed version of mainframe, and in my opinion, at the moment that is giving people a false sense of comfort.

Early in my career almost 20 years ago, I was working at an ISP, and one of the core services for the Internet (DNS) was directly attacked. There was of course a widespread failure and what we soon realized was the Internet had more of a shared fate than most believed.

Fast forward to present, and it just happened again with Dyn who hosted DNS for some very critical companies. This problem hasn’t been solved, it is getting worse.

This is the same problem we are going to have with AWS, Google Cloud and Azure.

As companies & governments converge on datacenters, and those datacenters connect to common interconnected fabrics (aka the Internet itself) and resources.

The Internet is becoming far more grouped…far more shared & central…and thus the shared fate of the Internet will lie solely on the shoulders of giants or as we like to call them in our industry monoliths.

Public cloud monoliths, monopolies…etc

Perhaps my worries will be mitigated by fantastic diversification and investment in truly distributed, distinct network paths, independent power plants, etc…BUT my fear is the convergence is happening so fast, the providers won’t be able to make that a reality fast enough and what’s the incentive for them ? They have to invest a tremendous amount of capital when they are already successful and this problem has not publicly and visibly humiliated us yet. But I fear that it will in the next few years…

So Godspeed to journey men of the cloud, as we enjoy the luxuries that AWS, Azure, & Google Cloud offer us. We are entering a beautiful and dangerous time. Beware, and hedge your company & product by distributing it as much as you can to avoid these central dependencies. Avoid these massive shared, global failure domains.