This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

CoreOS/FlatCar OS

Gardener extension controller for the CoreOS/FlatCar Container Linux operating system

Gardener Extension for CoreOS Container Linux

REUSE status CI Build status Go Report Card

Project Gardener implements the automated management and operation of Kubernetes clusters as a service. Its main principle is to leverage Kubernetes concepts for all of its tasks.

Recently, most of the vendor specific logic has been developed in-tree. However, the project has grown to a size where it is very hard to extend, maintain, and test. With GEP-1 we have proposed how the architecture can be changed in a way to support external controllers that contain their very own vendor specifics. This way, we can keep Gardener core clean and independent.

This controller operates on the OperatingSystemConfig resource in the API group. It supports CoreOS Container Linux and Flatcar Container Linux (“a friendly fork of CoreOS Container Linux”).

The controller manages those objects that are requesting CoreOS Container Linux configuration (.spec.type=coreos) or Flatcar Container Linux configuration (.spec.type=flatcar):

kind: OperatingSystemConfig
  name: pool-01-original
  namespace: default
  type: coreos

Please find a concrete example in the example folder.

After reconciliation the resulting data will be stored in a secret within the same namespace (as the config itself might contain confidential data). The name of the secret will be written into the resource’s .status field:

      name: osc-result-pool-01-original
      namespace: default
  command: /usr/bin/coreos-cloudinit -from-file=<path>
  - docker-monitor.service
  - kubelet-monitor.service
  - kubelet.service

The secret has one data key cloud_config that stores the generation.

An example for a ControllerRegistration resource that can be used to register this controller to Gardener can be found here.

Please find more information regarding the extensibility concepts and a detailed proposal here.

How to start using or developing this extension controller locally

You can run the controller locally on your machine by executing make start. Please make sure to have the kubeconfig to the cluster you want to connect to ready in the ./dev/kubeconfig file.

Static code checks and tests can be executed by running make verify. We are using Go modules for Golang package dependency management and Ginkgo/Gomega for testing.

Feedback and Support

Feedback and contributions are always welcome. Please report bugs or suggestions as GitHub issues or join our Slack channel #gardener (please invite yourself to the Kubernetes workspace here).

Learn more!

Please find further resources about out project here:

1 - Usage

Using the CoreOS extension with Gardener as end-user

The resource declares a few fields that must be considered when this OS extension is used.

In this document we describe how this configuration looks like and under which circumstances your attention may be required.

AWS VPC settings for CoreOS workers

Gardener allows you to create CoreOS based worker nodes by:

  1. Using a Gardener managed VPC
  2. Reusing a VPC that already exists (VPC id specified in InfrastructureConfig]

If the second option applies to your use-case please make sure that your VPC has enabled DNS Support. Otherwise CoreOS based nodes aren’t able to join or operate in your cluster properly.

DNS settings (required):

  • enableDnsHostnames: true (necessary for collecting node metrics)
  • enableDnsSupport: true