mirror of
				https://github.com/k3s-io/kubernetes.git
				synced 2025-11-03 23:40:03 +00:00 
			
		
		
		
	
		
			
				
	
	
		
			37 lines
		
	
	
		
			1.7 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
			
		
		
	
	
			37 lines
		
	
	
		
			1.7 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
# Legacy Cluster add-ons
 | 
						|
 | 
						|
For more information on add-ons see [the documentation](https://kubernetes.io/docs/concepts/cluster-administration/addons/).
 | 
						|
 | 
						|
## Overview
 | 
						|
 | 
						|
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.
 | 
						|
 | 
						|
There are currently two classes of add-ons:
 | 
						|
- Add-ons that will be reconciled.
 | 
						|
- Add-ons that will be created if they don't exist.
 | 
						|
 | 
						|
More details could be found in [addon-manager/README.md](addon-manager/README.md).
 | 
						|
 | 
						|
## Cooperating Horizontal / Vertical Auto-Scaling with "reconcile class addons"
 | 
						|
 | 
						|
"Reconcile" class addons will be periodically 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,
 | 
						|
leave `resources` for container unset for Vertical Scaling. The periodic reconcile
 | 
						|
won't clobbered these fields, hence they could be managed by Horizontal / Vertical
 | 
						|
Auto-scaler.
 | 
						|
 | 
						|
## Add-on naming
 | 
						|
 | 
						|
The suggested naming for most of the resources is `<basename>` (with no version number).
 | 
						|
Though resources like `Pod`, `ReplicationController` and `DaemonSet` are exceptional.
 | 
						|
It would be hard to update `Pod` because many fields in `Pod` are immutable. For
 | 
						|
`ReplicationController` and `DaemonSet`, in-place update may not trigger the underlying
 | 
						|
pods to be re-created. You probably need to change their names during update to trigger
 | 
						|
a complete deletion and creation.
 | 
						|
 | 
						|
[]()
 |