"Fossies" - the Fresh Open Source Software Archive

Member "minikube-1.26.1/site/content/en/docs/contrib/addons.en.md" (2 Aug 2022, 4219 Bytes) of package /linux/misc/minikube-1.26.1.tar.gz:

As a special service "Fossies" has tried to format the requested source page into HTML format (assuming markdown format). Alternatively you can here view or download the uninterpreted source code file. A member file download can also be achieved by clicking within a package contents listing on the according byte size field.

A hint: This file contains one or more very long lines, so maybe it is better readable using the pure text view mode that shows the contents as wrapped lines within the browser window.

Creating a new addon

To create an addon, first fork the minikube repository, and check out your fork:

git clone git@github.com:<username>/minikube.git

Then go into the source directory:

cd minikube

Create a subdirectory:

mkdir deploy/addons/<addon name>

Add your manifest YAML's to the directory you have created:

cp *.yaml deploy/addons/<addon name>

Note: If the addon never needs authentication to GCP, then consider adding the following label to the pod's yaml:

gcp-auth-skip-secret: "true"

To make the addon appear in minikube addons list, add it to pkg/addons/config.go. Here is the entry used by the registry addon, which will work for any addon which does not require custom code:

    name:      "registry",
    set:       SetBool,
    callbacks: []setFn{EnableOrDisableAddon},

Next, add all required files using //go:embed directives to a new embed.FS variable in deploy/addons/assets.go. Here is the entry used by the csi-hostpath-driver addon:

    // CsiHostpathDriverAssets assets for csi-hostpath-driver addon
    //go:embed csi-hostpath-driver/deploy/*.tmpl csi-hostpath-driver/rbac/*.tmpl
    CsiHostpathDriverAssets embed.FS

Then, add into pkg/minikube/assets/addons.go the list of files to copy into the cluster, including manifests. Here is the entry used by the registry addon:

  "registry": NewAddon([]*BinAsset{
  }, false, "registry", "google"),

The MustBinAsset arguments are:

The boolean value on the last line is whether the addon should be enabled by default. This should always be false. In addition, following the addon name on the last line is the maintainer field. This is meant to inform users about the controlling party of an addon's images. In the case above, the maintainer is Google, since the registry addon uses images that Google controls. When creating a new addon, the source of the images should be contacted and requested whether they are willing to be the point of contact for this addon before being put. If the source does not accept the responsibility, leaving the maintainer field empty is acceptable.

To see other examples, see the addons commit history for other recent examples.

"addons open" support

If your addon contains a NodePort Service, please add the kubernetes.io/minikube-addons-endpoint: <addon name> label, which is used by the minikube addons open command:

apiVersion: v1
kind: Service
    kubernetes.io/minikube-addons-endpoint: <addon name>

NOTE: minikube addons open currently only works for the kube-system namespace: #8089.

Testing addon changes

Rebuild the minikube binary and apply the addon with extra logging enabled:

make && make test && ./out/minikube addons enable <addon name> --alsologtostderr

Please note that you must run make each time you change your YAML files. To disable the addon when new changes are made, run:

./out/minikube addons disable <addon name> --alsologtostderr

Sending out your PR

Once you have tested your addon, click on new pull request to send us your PR!