Designing Kubernetes on Google Cloud – Blog Series

Today, containerized applications is one of the most common topics of every applications and data center discussion. We all know, that a containers’ orchestrator is the key component to provision and manage a successful dynamic containerized solution at scale. Such orchestrator, can be seen as the tool that groups multiple entities (Nodes, Pods, Containers, etc.) together to form a system (containers’ cluster), that typically aims to fulfill the intended requirements, along with many other important functions like; fault tolerance, elasticity, resources’ utilization, versioning and control.

Although there are a few containers’ orchestrators available today, it is obvious from the blog series title, the focus will be on Kubernetes, in particular in Google Cloud aka referred to Google Container Engine GKE.

To better understand the logic and operational model of Kubernetes as a containers orchestrator in an oversimplified way, let’s look at it from different perspective, by looking at the similarities between Kubernetes and the musician Yanni and his famous orchestra team. I know, it might sound strange, but let’s see how and where they have similarities, how this can provide an oversimplified way to introduce this topic.

I am sure some of you might think that Yanni is a Greek musician and Kubernetes name comes from the Greek word κυβερνήτης:, which means helmsman or ship pilot. Although it’s a true similarity, but what we are interested in here, is the operational model.

Yanni’s orchestra team is one the most famous in the world not only by the quality and creativity of the music, but also by the unique wide range of variety of instruments they use. In which the role in the overall music performance they play may vary to large extend based on the music, and the used instrument per musician.

Yanni is the man who compose the music, so you can think of him as the application developer or system admin who set the targeted goal and the expectations. Also, as part of the team, he has an orchestrator, who’s one of his or her main responsibilities, taking the composer’s notes to arrange and prepare the music to be performed, and make sure that each team member (musician) is playing the expected part of the music, and the assigned role to them and ensuring everything is in sync and harmony in real time.

However, no one tells the team members (the musicians) how to do their part, because, each musician knows what needs to be done (based off a composer’s drafts, notes, etc.) combined with their talent and skills, where each can perform the required part of the overall music performance.

In a similar fashion, Kubernetes, offer the ability to system admins and application developers to specify the required end goal or solution architecture of an application (applications’ tiers, minimum scale, minimum performance, connectivity etc.) in a declarative approach, like the music composer. Then, Kubernetes, takes these requirements and apply it to the system (containers cluster) to create, monitor and manage the containers’ infrastructure for the containerized applications with the pre-defined requirements.

Also, like with the musicians, Kubernetes as the orchestrator, dose not tell each node how to apply the required setup and provisioning, instead it will specify what each node required to do, and it’s the node’s responsibility to do it in its own way (Docker/Container engine, IPTables, Linux kernel etc.), these nodes like the different musician who use varieties of tools, containers can service many different services and functions in a cluster depnding on the applications architectures and tires deployed.

That being said, you might be wondering:

  • Why do we need containers or containerized applications?
  • What are the architecture elements of Kubernetes?
  • What are the key design considerations?
  • What about networking and connecting to, containerized applications?

There are many resources to answer these question, however, this blog series will cover it in a simplified way, yet, detailed and visualized enough to be able (to a high extent) to discuss and architect containerized solutions using Kubernetes on Google Cloud Platform. The following are the specific blogs’ topics covered in this series:

Last but 100% not least, special thanks to the wonderful technical reviewer Kareem Alsawaf from GCP, for taking the time to review, validate the content and become a part of this knowledge sharing blog series.

Note: even though this blog series focuses on Kubernetes on GCP, Kubernetes architecture and concepts still the same no matter where its deployed, except some specific functions, services and some connectivity features, that may be deployed and performed differently depending on the used environment.

Categories :
Marwan Al-shawi – CCDE No. 20130066, Google Cloud Certified Architect, AWS Certified Solutions Architect, Cisco Press author (author of the Top Cisco Certifications’ Design Books “CCDE Study Guide and the upcoming CCDP Arch 4th Edition”). He is Experienced Technical Architect. Marwan has been in the networking industry for more than 12 years and has been involved in architecting, designing, and implementing various large-scale networks, some of which are global service provider-grade networks. Marwan holds a Master of Science degree in internetworking from the University of Technology, Sydney. Marwan enjoys helping and assessing others, Therefore, he was selected as a Cisco Designated VIP by the Cisco Support Community (CSC) (official Cisco Systems forums) in 2012, and by the Solutions and Architectures subcommunity in 2014. In addition, Marwan was selected as a member of the Cisco Champions program in 2015 and 2016.