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

Select Status

RSS

kubernetes-cluster (2) Versions 1.0.3

Application cookbook for installing and configuring a Kubernetes cluster.

Policyfile
Berkshelf
Knife
cookbook 'kubernetes-cluster', '~> 1.0.3', :supermarket
cookbook 'kubernetes-cluster', '~> 1.0.3'
knife supermarket install kubernetes-cluster
knife supermarket download kubernetes-cluster
README
Dependencies
Changelog
Quality 33%

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.
NOTE: Additional exposed attributes contain notes for usage in the appropriate attributes file.

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"
},
"master": {
"podmaster-source": "registry.example.com:5000/podmaster:1.1",
"scheduler-source": "registry.example.com:5000/scheduler:1.0.3",
"controller-manager-source": "registry.example.com:5000/controller-manager:1.0.3"
}
},
"docker": {
"environment": {
"docker-registry": "registry.example.com:5000",
"registry-insecure": "registry.example.com:5000",
"docker-basedir": "/kube/docker"
}
},
"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"
}
},
"docker": {
"environment": {
"docker-registry": "registry.example.com:5000",
"registry-insecure": "registry.example.com:5000",
"docker-basedir": "/kube/docker"
}
},
"kubelet": {
"pause-source": "registry.example.com:5000/pause:base",
"register": "true"
},
"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.

1.0.3

  • Bugfix with kube-proxy deployment
  • Fully tested in both secure and insecure mode for HA setup using Kubernetes 1.0.3 and Docker 1.8.2
  • Fixed pathing in mount points and templates for podmaster/controller/scheduler

1.0.0

  • Optional deployment of podmaster for master election of master services
  • Deployment of scheduler and controller-manager as pods to take advantage of podmaster election
  • Selection of podmaster, scheduler, and controller-manager container image source
  • Most likely not backwards compatible
  • Made library use TLS certificates for etcdctl if applicable

0.7.1

  • Bugfixes related to kube client config
  • Elimination of race condition caused by docker0 interface slow startup

0.7

  • Initial public release of the cookbook.

Collaborator Number Metric
            

1.0.3 failed this metric

Failure: Cookbook has 1 collaborators. A cookbook must have at least 2 collaborators to pass this metric.

Contributing File Metric
            

1.0.3 failed this metric

Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of https://github.com/user/repo, and your repo must contain a CONTRIBUTING.md file

Foodcritic Metric
            

1.0.3 passed this metric

No Binaries Metric
            

1.0.3 passed this metric

Testing File Metric
            

1.0.3 failed this metric

Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of https://github.com/user/repo, and your repo must contain a TESTING.md file

Version Tag Metric
            

1.0.3 failed this metric

Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of https://github.com/user/repo, and your repo must include a tag that matches this cookbook version number