When comparing Chef vs Kubernetes, the Slant community recommends Kubernetes for most people. In the question“What are the best WordPress deployment tools?” Kubernetes is ranked 1st while Chef is ranked 6th. The most important reason people chose Kubernetes is:
Kubernetes is free and open source.
Ranked in these QuestionsQuestion Ranking
Pro Large community
Chef has a relatively large community. One of the reasons for it is the fact that it's a pretty old and mature tool. Chef, originally released in 2009, is a more mature product. Being popular and with a large and dedicated community means that Chef has lots and lots of resources and guides from third party sources out there for beginners to pick up. Not only that, there are also many plugins and configuration recipes made by the community.
Chef is cross-platform. Offering support for the biggest platforms out there: Linux, Windows and *nix.
Pro Popular choice among large companies
Chef has an impressive list of companies using it's automation service. Among them is Facebook, Etsy, Ancestry.com, PharmMD and Yahoo.
Pro Strong version control capabilities
Chef is centered around Git for it's configuration and deployments. Because of this, Chef also has great version control capabilities through Git.
Chef was released in 2009, which is relatively a long time ago for software. Since then it has been through several versions and many bug fixes and tests. All of this can make Chef more appealing to teams who are looking for stability and maturity, which are things that Chef brings on the table.
Pro Open Source
Kubernetes is free and open source.
Pro Built on several years of experience with containers
Kubernetes was built on top of several years of experience from Google working on containers in production. It's a little opinionated on how containers should work and behave, but if used correctly it can help you achieve fault-tolerant systems.
Pro Fault tolerant
Almost everything in Kubernetes is designed to handle if parts of it fail or if your service crashed for whatever reason. So it's particularly adapted if you've a cluster (even a very small one).
Pro Works well with modern operating systems
Kubernetes works very well with modern environments (such as CoreOS or Red Hat Atomc) which offer lightweight computing nodes that you don't have to manage, since they are managed for you.
Pro Supported on several PaaS
Kubernetes is currently supported by Google Compute Engine, Rackspace, Microsoft Azure, and vSphere. Work is being done to support Kubernetes on OpenShift and CloudFoundry.
Pro Easy to do grouping tasks
Kubernetes uses labels which are key-value pairs that are attached to objects, usually pods. They are used to specify the characteristics of an object like the version, tier, etc. Labels are used to identify objects or groups of objects according to different characteristics that they may have, for example they can be used to identify all the pods that are included in the backend tier.
Through labels it's easier to do grouping tasks for pods or containers, like moving pods to different groups or assigning them to load-balanced groups.
Pro Great starting point for beginners
Kubernetes great for beginners who are just starting to work on clustering. It's probably the quickest and easiest way to start experimenting and learning cluster oriented development.
Con Ties you to Ruby
Chef is written in Ruby and its CLI uses a Ruby-based DSL. In order to fully use and customize it you need to use Ruby as Chef does not give users any other choice when it comes to languages to use to configure it.
Con Steep learning curve
Chef has a steeper learning curve than many of its competitors, making it a more difficult tool for the non-devs of a team (such as sysadmins) to work with. For some teams, the added cost of teaching Chef to the team may outweigh the benefits.
Con Cannot define containers through the Docker CLI
Kubernetes was not written for docker clustering alone. It uses a different API, configuration and different YAML definitions. So you can't use the Docker CLI or Docker Compose to define your containers. Everything has to be done from scratch.
Con Windows restrictions
Windows compatibility rules, the host OS version must match the container base image OS version. Only Windows containers with Windows Server 2019 are supported. Also other restrictions are present.
Con If used on an existing system, some re-organizing may be needed
Because of how opinionated Kubernetes is, it may be necessary to change some things if you decide to use Kubernetes as an orchestration tool in an existing application.
Con Sometimes Pods refuse to (re)start automatically
It happens that a Pod needs a manual kick before it runs properly, especially if you're near full utilisation of your machine resources. Sometimes it is just a long delay.