github
/
k3s
mirror of https://github.com/k3s-io/k3s
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
k3s/cluster/addons
History
Kubernetes Submit Queue 2fde8f8efe Merge pull request #41360 from enisoc/fluentd-audit-log 
Automatic merge from submit-queue

fluentd-gcp: Add kube-apiserver-audit.log.

**What this PR does / why we need it**:

Add `kube-apiserver-audit.log` from https://github.com/kubernetes/kubernetes/pull/41211 to fluentd config, so the audit log gets sent to the same place as `kube-apiserver.log`.

**Which issue this PR fixes**:

**Special notes for your reviewer**:

We would like to backport this to release-1.5 also.

**Release note**:
```release-note
The apiserver audit log (`/var/log/kube-apiserver-audit.log`) will be sent through fluentd if enabled.
```
 		2017-02-15 05:01:54 -08:00
..
addon-manager addonManager: Add note about labeling 2017-02-14 15:43:47 +01:00
calico-policy-controller Remove initialized annotation from statefulset examples 2016-11-23 10:40:42 -08:00
cluster-loadbalancing Migrates addons from using ReplicationControllers to Deployments 2016-11-09 09:17:05 -08:00
cluster-monitoring Bumped version of addon resizer 2017-01-30 21:42:36 +01:00
dashboard update dashboard version to v1.5.1 2017-01-10 11:57:21 +01:00
dns Send only cluster domain queries to kube-dns 2017-02-13 13:27:09 -08:00
dns-horizontal-autoscaler OWNERS: Update latest OWNERS files 2017-01-23 10:05:48 -08:00
e2e-rbac-bindings Update rbac data to v1beta1 2017-02-14 00:50:31 -05:00
etcd-empty-dir-cleanup Add cleanup addon pod to remove empty keys in etcd 2016-08-09 15:59:45 -07:00
fluentd-elasticsearch make fluentd a critical pod 2017-02-06 12:16:32 -08:00
fluentd-gcp fluentd-gcp: Add kube-apiserver-audit.log. 2017-02-14 14:23:36 -08:00
node-problem-detector Remove unnecessary configuration for apiserver host and port. 2016-06-09 17:56:57 -07:00
podsecuritypolicies default policy 2016-05-11 18:07:36 -04:00
python-image Always --pull in docker build to ensure recent base images 2017-01-10 16:21:05 -08:00
rbac Switch RBAC subject apiVersion to apiGroup in v1beta1 2017-02-13 15:33:09 -05:00
registry Always --pull in docker build to ensure recent base images 2017-01-10 16:21:05 -08:00
storage-class Add a default storage class for Azure Disk 2017-02-08 23:29:58 -08:00
BUILD Build release tarballs in bazel and add `make bazel-release` rule 2017-01-13 16:17:44 -08:00
README.md Bumps up Addon Manager to v6.0 with full support of kubectl apply --prune 2016-11-18 18:13:32 -08:00

README.md

Cluster add-ons

Cluster add-ons are resources like Services and Deployments (with pods) that are shipped with the Kubernetes binaries and are considered an inherent part of the Kubernetes clusters. The add-ons are visible through the API (they can be listed using kubectl), but direct manipulation of these objects through Apiserver is discouraged because the system will bring them back to the original state, in particular:

  • If an add-on is deleted, it will be recreated automatically.
  • If an add-on is updated through Apiserver, it will be reconfigured to the state given by the supplied fields in the initial config.

On the cluster, the add-ons are kept in /etc/kubernetes/addons on the master node, in yaml / json files. The addon manager periodically kubectl applys the contents of this directory. Any legit modification would be reflected on the API objects accordingly. Particularly, rolling-update for deployments is now supported.

Each add-on must specify the following label: kubernetes.io/cluster-service: true. Config files that do not define this label will be ignored. For those resources exist in kube-system namespace but not in /etc/kubernetes/addons, addon manager will attempt to remove them if they are attached with this label. Currently the other usage of kubernetes.io/cluster-service is for kubectl cluster-info command to recognize these cluster services.

The suggested naming for most types of resources is just <basename> (with no version number) because we do not expect the resource name to change. But resources like Pod , ReplicationController and DaemonSet are exceptional. As Pod updates may not change fields other than containers[*].image or spec.activeDeadlineSeconds and may not add or remove containers, it may not be sufficient during a major update. For ReplicationController, most of the modifications would be legit, but the underlying pods would not got re-created automatically. DaemonSet has similar problem as the ReplicationController. In these cases, the suggested naming is <basename>-<version>. When version changes, the system will delete the old one and create the new one (order not guaranteed).

Add-on update procedure

To update add-ons, just update the contents of /etc/kubernetes/addons directory with the desired definition of add-ons. Then the system will take care of:

  • Removing objects from the API server whose manifest was removed.
  • Creating objects from new manifests
  • Updating objects whose fields are legally changed.

Cooperating with Horizontal / Vertical Auto-Scaling

As all cluster add-ons will be reconciled to the original state given by the initial config. In order to make Horizontal / Vertical Auto-scaling functional, the related fields in config should be left unset. More specifically, leave replicas in ReplicationController / Deployment / ReplicaSet unset for Horizontal Scaling, and leave resources for container unset for Vertical Scaling. The periodical update won't include these specs, which will be managed by Horizontal / Vertical Auto-scaler.

Analytics