Kubernetes at Production Scale: A CNCF Webinar
“Somebody who has stood up a cluster on three Raspberry PIs in their basement and writes an article about how Kubernetes is great and how it’s changing the world has a very different perspective than somebody who has run it at scale in a production environment,” said Kendall Miller, president of the Fairwinds Kubernetes consultancy, warning against the false prophets of online Kubernetes expertise, in a recent webinar from the Cloud Native Computing Foundation on best practices for the open source orchestration engine.
Nonetheless, the hard work can pay off, given that Kubernetes brings the enterprises to the ideal state of development — having an industry-supported Platform-as-a-Service (PaaS) personalized to the company’s specific workload needs.
Kubernetes “is not a PaaS itself because it requires tremendous configuration, but with the right configuration sorted the right way it feels like a PaaS that’s customized for your needs,” Miller said. “It’s really the framework for getting you there.” Developers can specify the specific resources (memory and CPU limits, etc) they need for their apps, and the operational engineers get an API to control the infrastructure.
What pointers does Fairwinds offer for a running a robust Kubernetes deployment? Here are a few:
Versioning: Implement everything as infrastructure-as-code, with the setting captured in a git repository. It should be table stakes, now. “It makes sure it is easy to track changes in your configuration over time,” noted Robert Brennan, Fairwinds director of open source. The code is the documentation. Through regular auditing, a tool such as Fairwinds’ own Polaris can easily spot configuration errors.
Dashboards: Not everything has to be managed through the CLI, or an API call. With infrastructure-as-code in place, a dashboard provides the ability to adjust settings, as well as expose them for later inspection. “You see a dropdown list of options you have, and that’s really nice,” Miller said. “Some of these tools actually do a really good job of taking what you implement in a dashboard and applying it in code in your infrastructure.”
Set Up Disaster Recovery (DR): Another advantage of Infrastructure-as-Code is that, should you cluster disappear for some reason, you can quickly recreate it, merely by running a CI/CD process or by a set of applying a set of kubectl commands. Kubernetes shouldn’t be the full DR plan, but it’s a good start.
Don’t put your database in the cluster: Unlike everything else in a Kubernetes cluster, databases are not ephemeral. You’ll want to save the data should the cluster go down. While Kubernetes does provide features such as Persistent Volumes and Stateful Sets to store persistent data, the technology is still error-prone and generally still not ready for prime time. “This functionality is not as well supported in Kubernetes as we’d like and it’s something that we tend to push people away from. We would rather see them use say Amazon’s RDS service in order to run their databases rather than putting it in the cluster,” Brenna said.
Turn the Knobs: Running everything at full capacity is wasteful spending. Use the best fitting instance type to the workload. Is the workload CPU heavy or memory-heavy? The ideal is to have the spend match the workload. Tweaking your instance to save $5 a month is probably not worth the time, but having a configuration setting slightly off can cost thousands of dollars, Miller said. Fairwinds offers a tool here as well, Goldilocks, which can offer suggestions for matching the workload to the optimal resource.
There is more good info in the Q&A portion of the talk as well. Check out the full presentation here:
Amazon Web Services and The Cloud Native Computing Foundation are sponsors of The New Stack.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: feedback@thenewstack.io.
