Skip to content

Latest commit

 

History

History
78 lines (57 loc) · 4.18 KB

File metadata and controls

78 lines (57 loc) · 4.18 KB

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.

The oscommon offers a generic controller that operates on the OperatingSystemConfig resource in the extensions.gardener.cloud/v1alpha1 API group. It manages those objects that are requesting for an specific operating system.

---
apiVersion: extensions.gardener.cloud/v1alpha1
kind: OperatingSystemConfig
metadata:
  name: pool-01-original
  namespace: default
spec:
  type: <os type>
  units:
    ...
  files:
    ...

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:

...
status:
  ...
  cloudConfig:
    secretRef:
      name: osc-result-pool-01-original
      namespace: default
  command: <machine configuration command>
  units:
  - docker-monitor.service
  - kubelet-monitor.service
  - kubelet.service

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

The generation of this operating system representation is executed by a Generator. A default implementation for the generator based on go templates is provided in template.

In addition, oscommon provides set of basic tests which can be used to test the operating system specific generator.

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


How to use oscommon in a new operating system configuration controller

When implementing a controller for a specific operating system, it is necessary to provide:

  • A command line application for launching the controller
  • A template for translating the cloud-config to the format requried by the operating system.
  • Alternatively, a new generator can also be provided, in case the transformations required by the operating system requires more complex logic than provided by go templates.
  • A test that uses the test description provided in [pkg/generator/test]
  • A directory with test files
  • The helm Chart for operator registration and installation

Please refer to the os-suse-chost controller for a concrete example.

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: