Kubernetes: Advanced Q&A

I’d like to share with you some questions we did to the Google Kubernetes team and that might be useful for others. Enjoy it

  1. Does each pod only have access to one node resources? (the node in which it lives?
    • Yes
  2. If I have two node pools, one with low memory and one with high memory, is Kubernetes smart to put the pods that use a lot of memory in the pool with high memory? Can it do it on-the-fly?
    • You can define requests and limits to ensure that pods are scheduled on nodes with sufficient resources. You can also utilize node affinity/anti-affinity to influence where pods go, or taint/toleration to block pools from accepting pods unless explicitly specified. More details on how Kubernetes handles resourcescan be found here.
  3. How do preemptive nodes in the cluster work? If I have two nodes in the cluster and each node has 4 pods, when one node is preempted, will Kubernetes move the 4 pods to another node? And when the other node is available again will the Kubernetes rebalance the location of the pods?
    • Preemptive nodes are created as a node pool. If your node pool is preempted and becomes unavailable, GKE will attempt to reschedule your pods in other available nodes (unless you set it up in your deployment spec to only deploy to preemptive nodes). When the node pool becomes available, GKE will schedule appropriate pods there (it will not rebalance automatically).
  4. How does in-memory disk cache work in the cluster? I’m referring to this cache. Each pod will have its cache or the cache is shared between all the pods in the node?
    • Pods have their own storage/cache isolated from each other when created, emptydir. By default, emptyDir volumes are stored on whatever medium is backing the node – that might be disk or SSD or network storage, depending on your environment. However, you can set the emptyDir.medium field to “Memory” to tell Kubernetes to mount a tmpfs (RAM-backed filesystem) for you instead. While tmpfs is very fast, be aware that
      unlike disks, tmpfs is cleared on node reboot and any files you write will count against your Container’s memory limit.
  5. We have an application that uses the name of the machine on which it is running to decide what it will do. The machine name must form a sequence from 0 to the total number of machines minus 1. Example: maq-0, maq-1, maq-2. Each application also needs to know the total number of machines. How to do this in kubernetes? I was able to do this using a statefulSet, but the total number of pods got hardcoded in the application. Any suggestion?
    • Assuming that we are looking at machines as pods, then StatefulSets are required. StatefulSets provide a stable network ID which allows for the naming convention specified. The current number of replicas can be acquired using the StatefulSetStatus v1 apps Kubernetes API.
  6. Is it possible to do a statefulSet without a headlessService? I am asking this because the application I want to run in the statefulSet does not need to be accessed by anyone (neither inside nor outside the cluster).
    • No, StatefulSets require a headlessService. You can use network policies to deny Ingress

Go up to the cloud

Prioritizing existing cloud solutions for features non-core to your business

When Daniel started to work in Elo7, the company website infrastructure was installed in two bare metal servers. Local SMTP server application was responsible for mail delivery. Server logs were stored in local drive. Managing and scaling bare metal servers was difficult, so everything was migrated to cloud instances. The mail delivery was decoupled from the application server and migrated to a service provider. Server logs were also migrated to a cloud PaaS, so developers would not need to log in the application servers to search in log files. These and other changes to the cloud lead to a lower cost and more flexible systems architecture, enabling the Startup to grow fast and solid.

Startups do not have time to build their own physical server infrastructure. They need to focus on their own product or service development. Nowadays, there are a lot of services that provide almost everything a Startup
needs to setup its business online. There are hundreds of offerings on Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS) layers. Moreover, most providers offer very low costs for low usage, as well as free tiers for beginners.

Today it is possible to build a technology company just by sticking together existing solutions. There are thousands of different Software as a Service (SaaS) platforms, most of them offering free tier for small companies
to solve a wide range of problems a company has, from file sharing applications to accounting software and communications tools. Almost everything is available freely online.

Software running into production is much more complex than running on developers machines. There are many cloud providers that offer simple solutions to deploy software in a mater of a mouse click, without needing any knowledge on system administrations. These Platform as a Service (PaaS) environments save a lot of precious time for startups, which in the beginning don’t have any specific requirement that justifies building its own

Building a physical server infrastructure is hard, time consuming, and expensive. Developing commodity software is also a waste of time. Startups do not have time to spend on tasks other than their core business.

Startups usually have few software developers to do the entire job. It is impossible for a small team to be competent in all technologies. In a software startup, its product codebase is the most important place developers should spend they hours, learning about the business domain and creating inexistent and innovative solution to the startup customers. Moreover, every line of code deployed into production increases the maintenance costs. If developers spend time maintaining software non-core for the business, they have less time to work on core functionalities. It is a matter of cost benefit between building and buying. Building software non-core to your business will make you loose focus from your customers.


Use ready-made infrastructures over building your own solution. Prefer SaaS to PaaS, prefer PaaS to IaaS, prefer IaaS to ‘building your own infrastructure’, except for features core to your business.

The more non-core software you delegate to the cloud, the more time your team will have to work on what really matters: your customer. When you spend more time on your business software, you deliver more value and learn faster from your clients. By continuously delivering software to your customers you are bound to become competitive and profitable.

If you need a communication tool to keep the startup remote team together, you can use HipChat or Slack. For documents and spreadsheets creation, there is Google Drive, Microsoft Office 360. Virtual machines infrastructure
monitoring can be achieved with New Relic. Systems log processing and analysis can be done with Loggly or Splunk. Do remote pair programming with Screen Hero.

Most of these SaaS, PaaS and IaaS solutions were a startup someday. Off course if your startup product is a cloud system, developing a cloud service is core to you, so you won’t delegate these core functionalities to third
party companies. But even cloud service providers use third party software. IaaS companies use SaaS. SaaS companies use IaaS, and so on. The DevOps for Startups pattern can help you to choose the right balance between different cloud layers. A bad consequence of choosing the wrong cloud solution is that you can get stuck to a specific provider, so take care, preferring standard and replaceable solutions instead of proprietary hard to migrate architectures.

Comparing cloud services for Startups

nuvemEvery Startup that has services online needs a cloud provider. Startups do not have time to build their own physical server infrastructure. They need to focus on their product or service development. But what cloud to use? There are so many different options, and CTOs do not have time to test each one of them. Maybe this post will help new Startups  to choose between all cloud providers available.

The experience that I had with Playax was not typical, for two reasons: the first was that I have a lot of experience working with cloud. After working at Locaweb for 5 years, and developing software for internal cloud team, I spent one year in my PhD studying cloud services. The second reason is that Playax product is highly dependent from cloud. We are a BigData company. We needed a big infrastructure from day one. Our MVP needed a lot of cloud resources to be useful to our customers. Most of Startups do not need that much infrastructure, at least not before it starts growing fast.

Continue reading

Small EC2 cloud usage demo for choreographies

The CHOReOS middleware must be capable of providing the required runtime support to deploy, enact, monitor, and dynamically reconfigure large-scale choreographies. These choreographies might be large scale in one or more of the following dimensions: number of requests, users, roles, services, nodes, and communication among services. For instance, the middleware should be scalable enough to accommodate choreography with 1 thousand simultaneous users or with 100 different roles, or with 100 services for a given role, or with thousands of messages exchanged per second.

Continue reading

Cloud Computing x Grid Computing

We all already know that Cloud Computing is a buzzword since its unknown origin. Moreover, we also know that many concepts of cloud computing are not as knew as some companies and their marketing department pretend they are. Specially when compared to Grid Computing, which is a more than 13 year old paradigm, there are many similarities (and also some differences). I’ll try to expose some of these points here.

Question no. 1: Is “Cloud Computing” just a new name for Grid?

YES, in the sense that both aim to reduce cost of computing, increase reliability and flexibility

But NO: Grid is more than 10 years ago, when we didn’t have the computer power available today. They context and scale it was made to operate (expensive hundreds of machines clusters) is different of today’s available infrastructure (hundreds of thousands of “low cost” computers and virtual machines created within them). Grid and Cloud operate in different scales.

Nevertheless, YES: Cloud and Grid problems are mostly the same. The details are different, but both deal with the same issues.

Question no. 2: What is Cloud Computing?

Yes, I know, there are a lot of different definitions of what Cloud Computing is and not much consensus between those definitions [2]. Then, I choose the best and most complete definition I found til now. It is the US National Institute of Standards and Technology (NIST) definition. Their definition is short and complete, when they say that Cloud Computing is

 “a model for enabling convenient, on-demand network access to a shared pool of configurable resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction” [1]

In other words, Cloud is meant to be:

  1. Massively scalable
  2. Encapsulated as an abstract entity that delivers different levels of services
  3. Driven by economies of scale [3]
  4. Dynamically configured

Question no. 3: What is Grid Computing?

Grid Computing, through well defined standard protocols, aims to

“enable  resource sharing and coordinated problem solving in dynamic, multi-institutional virtual organizations” [4][5]

this means that Grid:

  1. Is distributed computing
  2. Operates across multiple federated organizations
  3. Coordinates resources that are not subject to centralized control
  4. Uses standards, open, and general-purpose protocols
  5. Delivers non-trivial QoS
While points 1, 2 and 3 holds true also for Cloud Computing, points 4 and 5 are still a challenge in the Cloud area.

Question no. 4: How to compare Cloud and Grid side-by-side? [6]

The following Figure is an insightful overview when we try to compare Grid and Cloud:


[1] MELL, P. and GRANCE, T. 2009. Draft NIST Working Definition of Cloud Computing.
[2] “Twenty Experts Define Cloud Computing”, SYS-CON Media Inc, 2008.
[3] J. Silvestre. “Economies and Diseconomies of Scale,” The New Palgrave: A Dictionary of Economics, v. 2, pp. 80–84, 1987.
[4] I. Foster, C. Kesselman, S. Tuecke. The anatomy of the Grid: Enabling scalable virtual organization. The Intl. Jrnl. of High Performance Computing Applications, 15(3):200–222, 2001.
[5] I. Foster. What is the Grid? A Three Point Checklist, July 2002.
[6] FOSTER, I., ZHAO, Y., RAICU, I. and LU, S. 2008. Cloud Computing and Grid Computing 360-Degree Compared. In Grid Computing Environments Workshop (GCE ’08), Austin, Texas, USA, November 2008, 1-10.