Adoptable Cookbooks List

Looking for a cookbook to adopt? You can now see a list of cookbooks available for adoption!
List of Adoptable Cookbooks

Supermarket Belongs to the Community

Supermarket belongs to the community. While Chef has the responsibility to keep it running and be stewards of its functionality, what it does and how it works is driven by the community. The chef/supermarket repository will continue to be where development of the Supermarket application takes place. Come be part of shaping the direction of Supermarket by opening issues and pull requests or by joining us on the Chef Mailing List.

Select Badges

Select Supported Platforms

RSS

kubernetes-cluster (2) Versions 0.7.0

Application cookbook for installing and configuring a Kubernetes cluster.

Berkshelf/Librarian
Policyfile
Knife
cookbook 'kubernetes-cluster', '= 0.7.0'
cookbook 'kubernetes-cluster', '= 0.7.0', :supermarket
knife cookbook site install kubernetes-cluster
knife cookbook site download kubernetes-cluster
README
Dependencies
Changelog
Quality

kubernetes-cluster cookbook

Build Status Code Quality Cookbook Version License

Application cookbook which installs and configures a Kubernetes cluster.

Supported Platforms

  • RHEL 7.1+ (CentOS 7.1+)

Basic Usage

Configure masters using kubernetes-cluster::master Configure minions using kubernetes-cluster::minion Configure Docker registry using kubernetes-cluster::registry

The purpose of this cookbook is to install and configure the proper sevices to create application container clusters. This includes etcd, Kubernetes, Flannel, and Docker- specifically aimed at operating on Enterprise Linux platforms. The best method to using this cookbook is to create a wrapper with specific configurations for your project, adding this cookbook as a dependency. This cookbook assumes you have access to a chef server- however, the cookbook will work fine without it if you override node['kubernetes']['etcd']['members'] in attributes/master.rb node['kubernetes']['master']['fqdn'] in attributes/minion.rb in insecure mode. Secure mode requires more configuration.

  • First, converge your masters, The first master converge may fail due to ETCD cluster sync oddities, I am working for a resolution for this. Just re-converge the masters that fail.
  • Second, converge your minions.

Example solo.json for master json { "kubernetes": { "etcd": { "members": ["master1.example.com", "master2.example.com", "master3.example.com"] } }, "run_list": ["recipe[kubernetes-cluster::master]"] }

Example solo.json for minion json { "kubernetes": { "master": { "fqdn": ["master1.example.com", "master2.example.com", "master3.example.com"] } }, "run_list": ["recipe[kubernetes-cluster::minion]"] }

Advanced Usage

As well as configuring a simple Kubernetes cluster, this cookbook also allows for far more advanced configurations. These configurations range from changing flannel network layout, to enabling secure communications, and adding additional Docker regestries. Secure mode will configure SSL and TLS connections for all endpoints for etcd and Kubernetes. This is HIGHLY recommended for production-like purposes. This will require large amounts of prep work. You can also set URLs for additional Docker registries for the minions to get container images from- as well as configuring said registry.

First, set node['kubernetes']['secure']['enabled'] = 'true' and read below:

I highly recommend you use a tool like CFSSL (CloudFlare SSL) to create your certificates, check out https://www.digitalocean.com/community/tutorials/how-to-secure-your-coreos-cluster-with-tls-ssl-and-firewall-rules and start at "Use CFSSL to Generate Self-Signed Certificates"

Masters: - node['kubernetes']['etcd']['peer']['ca'] - Certificate authority for managing authentication for master to master connections (etcd sync) - node['kubernetes']['etcd']['peer']['cert'] - Certificate the master identifies as for peer connections (Signed by peer CA) - node['kubernetes']['etcd']['peer']['key'] - Key matching peer certificate - node['kubernetes']['etcd']['client']['ca'] - Certificate authority for managing authentication for client to master connections (etcdctl/kubectl/kubelet) - node['kubernetes']['etcd']['client']['cert'] - Certificate the client identifies as for connections (Signed by client CA) - node['kubernetes']['etcd']['client']['key'] - Key matching client certificate

Minions: - node['kubernetes']['etcd']['client']['ca'] - Certificate authority for verifying cert validity for client to master connections - node['kubernetes']['etcd']['client']['cert'] - Certificate the client identifies as for connections (Signed by client CA) - node['kubernetes']['etcd']['client']['key'] - Key matching client certificate

NOTE: Peer and Client CA can be the same. This will allow for far simpler setup. However, you may use a different CA to more closely manage security if desired.

Example solo.json for master json { "kubernetes": { "etcd": { "members": ["master1.example.com", "master2.example.com", "master3.example.com"], "basedir": "/kube/etcd", "peer": { "ca": "-----BEGIN CERTIFICATE-----\ndatadata\n-----END CERTIFICATE-----", "cert": "-----BEGIN CERTIFICATE-----\ndatadata\n-----END CERTIFICATE-----", "key": "-----BEGIN KEY-----\ndatadata\n-----END KEY-----" }, "client": { "ca": "-----BEGIN CERTIFICATE-----\ndatadata\n-----END CERTIFICATE-----", "cert": "-----BEGIN CERTIFICATE-----\ndatadata\n-----END CERTIFICATE-----", "key": "-----BEGIN KEY-----\ndatadata\n-----END KEY-----" } }, "secure": { "enabled": "true" } }, "run_list": ["recipe[kubernetes-cluster::master]"] }

Example solo.json for minion json { "kubernetes": { "etcd": { "client": { "ca": "-----BEGIN CERTIFICATE-----\ndatadata\n-----END CERTIFICATE-----", "cert": "-----BEGIN CERTIFICATE-----\ndatadata\n-----END CERTIFICATE-----", "key": "-----BEGIN KEY-----\ndatadata\n-----END KEY-----" } }, "master": { "fqdn": ["master1.example.com", "master2.example.com", "master3.example.com"] }, "secure": { "enabled": "true" }, "minion": { "pause-source": "internalregistry.docker.example.com:5000/rhel7:pause", "docker-registry": "internalregistry.docker.example.com:5000", "registry-insecure": "internalregistry.docker.example.com:5000", "docker-basedir": "/kube/docker" } }, "run_list": ["recipe[kubernetes-cluster::minion]"] }

Example solo.json for registry json { "kubernetes": { "registry": { "port": "5000", "workers": "8", "storage": "/kube/docker-storage/" } }, "run_list": ["recipe[kubernetes-cluster::registry]"] }

Testing

This project will use Test Kitchen to execute the ChefSpec tests on a clean virtual machine. By default Test Kitchen will use Vagrant and attempt to start a new virtual machine up from a default Opscode box. shell bin/kitchen test default-centos-7.1 However, no meaningful tests are currently written. This will be fixed.

Dependent cookbooks

This cookbook has no specified dependencies.

Contingent cookbooks

There are no cookbooks that are contingent upon this one.

Change Log

All notable changes to this project will be documented in this file. This project will adhere to strict Semantic Versioning starting at v1.0.0.

0.7

  • Initial public release of the cookbook.

Foodcritic Metric
            

0.7.0 failed this metric

FC005: Avoid repetition of resource declarations: /tmp/cook/230dcc58106a15b37e790756/kubernetes-cluster/recipes/minion.rb:26
FC024: Consider adding platform equivalents: /tmp/cook/230dcc58106a15b37e790756/kubernetes-cluster/recipes/default.rb:9
FC024: Consider adding platform equivalents: /tmp/cook/230dcc58106a15b37e790756/kubernetes-cluster/recipes/master.rb:13
FC024: Consider adding platform equivalents: /tmp/cook/230dcc58106a15b37e790756/kubernetes-cluster/recipes/minion.rb:15
FC024: Consider adding platform equivalents: /tmp/cook/230dcc58106a15b37e790756/kubernetes-cluster/recipes/proxy.rb:11
FC024: Consider adding platform equivalents: /tmp/cook/230dcc58106a15b37e790756/kubernetes-cluster/recipes/registry.rb:11