When you think about preparing to use Kubernetes to manage your production infrastructure, you shouldn't think about Kubernetes as your end goal. It is a foundation for building a platform on which to run systems.
When you think about building a platform to meet the needs of the different people in your organization, it becomes much simpler to define the requirements you will place on Kubernetes. When trying to plan for a production environment, you need to understand the requirements that your organization has. Clearly, the technical requirements of the software you want to manage is important. But it is also key to understanding the operational process that your organization needs to support.
Adopting Kubernetes offers a lot of benefits to organizations that have complex requirements for the software that they run. Unfortunately, this complexity can also lead to challenges in safely adopting Kubernetes in a successful way.
You should consider where you will focus your efforts for your initial roll out. You should look for an application that will both deliver valuable results quickly, as well as having a lower risk profile. If we think about the example at GitHub, they initially focused their efforts on building an infrastructure for internal users to quickly test changes to their software. By focusing on a review or staging infrastructure, they found an application for Kubernetes that would both provide value quickly to developers in their organization, as well as an area that had low risks to their business as it was only accessed by internal users.
Applications like these that have a combination of immediate usefulness and a lower impact of downtime are very useful. They allow your organization to gain valuable operational experience using Kubernetes, as well as to drive out bugs and other issues well before you attempt to handle production workloads.
When getting started with Kubernetes, it can be tempting to choose the simplest application that your organization operates and start building processes and tooling around this. However, this can be a mistake because it might lead to you making assumptions about how your applications should be operated, that might make it much harder to later apply the same processes and configuration to more complex applications.
If you choose to start building your platform to support a simple application that doesn't require any backend services, such as a database, you might miss a number of things you need to consider as part of your deployment process. For example, applications that are backed by a database often need to run migration scripts to update the schema when a new version of an application is deployed. If you start by designing a deployment process to meet the needs of a very simple application, you might not surface these requirements until later. Remember, it will always be much simpler to deploy a simple application that only needs a subset of the features that your platform provides, than a more complex application that needs facilities you didn't consider when designing it.
If you choose to focus your efforts on a single application for your initial adoption of Kubernetes, make sure that you choose an application that is representative of your organization's needs. It can be tempting to start using Kubernetes for a greenfield project, as you can take application development decisions with the platform in mind. But remember that a new application may well be significantly simpler than an application that has been in use for a longer time. In the example from GitHub, the application they chose to deploy first was their largest application operated by their organization providing many core services.
If your organization has an application that requires a lot of operational time and effort every time it is deployed, it could be that this would be a good choice for an initial adoption of Kubernetes. Applications like these will be well known for their needs by your development and operational teams, and they will immediately be able to start to utilize Kubernetes to address the issues that previously cost time and effort.
![]()
There are a few things that you should try to avoid in order to deliver successfully on a project to adopt Kubernetes.
One trap that can be all too easy to fall into is to change too much too quickly. If you are taking the decision to adopt containerization and Kubernetes, it can be very tempting to adopt a lot of new processes and tools alongside this. This can slow down your progress quite significantly, because what started as a project to run your applications in containers can quickly grow to encompass many other tools and processes that your organization would like to adopt.
You should aim to avoid scope creep and try to change as little as possible in order to deliver your initial adoption of Kubernetes as quickly as possible. It is important to not try to deliver too many of the promises of containerization in one go, as they will hold your adoption back, and may indeed lead to failure of your whole project.
Try to consider the environment you are currently deploying your applications to and aim to replicate its facilities at first, later adding additional functionality. Many of the tools and procedures that we discuss in the rest of this book might indeed be optional for your Kubernetes cluster, items that you can add at a later date to provide additional valuable services, but not to be viewed as blockers to adoption.
If you have the opportunity to reduce the scope of the infrastructure your Kubernetes deployment provides at the time of your additional roll out, you should consider doing so. It reduces the scope of new tools and processes that your organization needs to understand. And it will give you the opportunity to focus on that topic in greater detail at a later time, with reference to the operational experience you will have gained running your applications on Kubernetes.
Consider log management as an example of this—if your current procedure is to log into servers with SSH and tail log files, you can provide the same functionality to operators of your Kubernetes cluster with the kubectl logs command. Implementing a solution to aggregate and search logs generated by your cluster might be desirable, but shouldn't necessarily be a blocker to using Kubernetes.
If you currently deploy your applications onto servers running a Linux distribution that is readily available as a container image, you should stick with that distribution, rather than looking for alternatives at this stage, as your developers and operational staff will already be knowledgeable about how it works, and you won't have to invest time fixing incompatibilities. Learning to operate your applications on Kubernetes should be your focus, rather than learning how to configure a new operating system distribution.
![]()
It can be tempting to shake up the processes and responsibilities in your organization. But trying to do this as part of adopting a new tool like Kubernetes can be risky. For example, if in your organization you have an operations team responsible for deploying and monitoring your applications, the point at which you adopt Kubernetes is not the correct time to hand this responsibility to someone else, such as your development team, or to attempt to automate a manual process.
This can be frustrating because, often, adoption of Kubernetes comes as part of wider plans to improve the processes and tooling that your organization uses. You should wait to successfully establish the use and operation of Kubernetes first. This will put you in a much better position to introduce new tools and processes once you have a stable foundation to build upon. You should view the adoption of Kubernetes as building a foundation that will be flexible enough to implement whatever changes to tools and processes you want to make in the future.
You will discover that implementing new tools, services, and processes becomes much simpler once your application infrastructure is running on Kubernetes. Once you have a Kubernetes cluster at your disposal, you will discover that the barriers to trying out a new tool are significantly reduced. Instead of spending lots of time planning and provisioning, you can quickly evaluate and try out a new tool just by submitting a new configuration to your cluster.
![]()
The designing requirements are shown in the following diagram:
Availability, capacity, and performance are key properties that we should consider when preparing for production. When gathering the functional requirements for your cluster, it can help to categorize which requirements imply some consideration of these properties.
It is important to understand that it might not be possible to optimize for all three properties without making some trade-offs. For example, for applications that depend on very high network performance, AWS provides a tool called a cluster placement group. This ensures that the best network performance is available by provisioning the EC2 VMs in such a way that fast network interconnection...
