75 lines
4.9 KiB
Markdown
75 lines
4.9 KiB
Markdown
|
---
|
|||
|
title: " Managing Kubernetes Pods, Services and Replication Controllers with Puppet "
|
|||
|
date: 2015-12-17
|
|||
|
slug: managing-kubernetes-pods-services-and-replication-controllers-with-puppet
|
|||
|
url: /blog/2015/12/Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet
|
|||
|
---
|
|||
|
_Today’s guest post is written by Gareth Rushgrove, Senior Software Engineer at Puppet Labs, a leader in IT automation. Gareth tells us about a new Puppet module that helps manage resources in Kubernetes. _
|
|||
|
|
|||
|
People familiar with [Puppet](https://github.com/puppetlabs/puppet) might have used it for managing files, packages and users on host computers. But Puppet is first and foremost a configuration management tool, and config management is a much broader discipline than just managing host-level resources. A good definition of configuration management is that it aims to solve four related problems: identification, control, status accounting and verification and audit. These problems exist in the operation of any complex system, and with the new [Puppet Kubernetes module](https://forge.puppetlabs.com/garethr/kubernetes) we’re starting to look at how we can solve those problems for Kubernetes.
|
|||
|
|
|||
|
|
|||
|
### The Puppet Kubernetes Module
|
|||
|
|
|||
|
The Puppet Kubernetes module currently assumes you already have a Kubernetes cluster [up and running](http://kubernetes.io/gettingstarted/). Its focus is on managing the resources in Kubernetes, like Pods, Replication Controllers and Services, not (yet) on managing the underlying kubelet or etcd services. Here’s a quick snippet of code describing a Pod in Puppet’s DSL.
|
|||
|
|
|||
|
|
|||
|
```
|
|||
|
kubernetes_pod { 'sample-pod':
|
|||
|
ensure => present,
|
|||
|
metadata => {
|
|||
|
namespace => 'default',
|
|||
|
},
|
|||
|
spec => {
|
|||
|
containers => [{
|
|||
|
name => 'container-name',
|
|||
|
image => 'nginx',
|
|||
|
}]
|
|||
|
},
|
|||
|
```
|
|||
|
}
|
|||
|
|
|||
|
|
|||
|
If you’re familiar with the YAML file format, you’ll probably recognise the structure immediately. The interface is intentionally identical to aid conversion between different formats — in fact, the code powering this is autogenerated from the Kubernetes API Swagger definitions. Running the above code, assuming we save it as pod.pp, is as simple as:
|
|||
|
|
|||
|
|
|||
|
```
|
|||
|
puppet apply pod.pp
|
|||
|
```
|
|||
|
|
|||
|
Authentication uses the standard kubectl configuration file. You can find complete [installation instructions in the module's README](https://github.com/garethr/garethr-kubernetes/blob/master/README.md).
|
|||
|
|
|||
|
Kubernetes has several resources, from Pods and Services to Replication Controllers and Service Accounts. You can see an example of the module managing these resources in the [Kubernetes guestbook sample in Puppet](https://puppetlabs.com/blog/kubernetes-guestbook-example-puppet) post. This demonstrates converting the canonical hello-world example to use Puppet code.
|
|||
|
|
|||
|
One of the main advantages of using Puppet for this, however, is that you can create your own higher-level and more business-specific interfaces to Kubernetes-managed applications. For instance, for the guestbook, you could create something like the following:
|
|||
|
|
|||
|
|
|||
|
```
|
|||
|
guestbook { 'myguestbook':
|
|||
|
redis_slave_replicas => 2,
|
|||
|
frontend_replicas => 3,
|
|||
|
redis_master_image => 'redis',
|
|||
|
redis_slave_image => 'gcr.io/google_samples/gb-redisslave:v1',
|
|||
|
frontend_image => 'gcr.io/google_samples/gb-frontend:v3',
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
You can read more about using Puppet’s defined types, and see lots more code examples, in the Puppet blog post, [Building Your Own Abstractions for Kubernetes in Puppet](https://puppetlabs.com/blog/building-your-own-abstractions-kubernetes-puppet).
|
|||
|
|
|||
|
|
|||
|
### Conclusions
|
|||
|
|
|||
|
The advantages of using Puppet rather than just the standard YAML files and kubectl are:
|
|||
|
|
|||
|
|
|||
|
- The ability to create your own abstractions to cut down on repetition and craft higher-level user interfaces, like the guestbook example above.
|
|||
|
- Use of Puppet’s development tools for validating code and for writing unit tests.
|
|||
|
- Integration with other tools such as Puppet Server, for ensuring that your model in code matches the state of your cluster, and with PuppetDB for storing reports and tracking changes.
|
|||
|
- The ability to run the same code repeatedly against the Kubernetes API, to detect any changes or remediate configuration drift.
|
|||
|
|
|||
|
It’s also worth noting that most large organisations will have very heterogenous environments, running a wide range of software and operating systems. Having a single toolchain that unifies those discrete systems can make adopting new technology like Kubernetes much easier.
|
|||
|
|
|||
|
It’s safe to say that Kubernetes provides an excellent set of primitives on which to build cloud-native systems. And with Puppet, you can address some of the operational and configuration management issues that come with running any complex system in production. [Let us know](mailto:gareth@puppetlabs.com) what you think if you try the module out, and what else you’d like to see supported in the future.
|
|||
|
|
|||
|
- Gareth Rushgrove, Senior Software Engineer, Puppet Labs
|