Spinnaker Stage Deploy (Manifest)
External
- https://spinnaker.io/docs/guides/user/kubernetes-v2/deploy-helm/
- https://spinnaker.io/docs/guides/user/kubernetes-v2/traffic-management/
- https://spinnaker.io/docs/guides/user/kubernetes-v2/rollout-strategies/
Internal
Overview
Deploy a Kubernetes manifest yaml/json file. This section refers to deploying a Helm chart rendered by a previous Bake (Manifest) stage.
Configuration
Add stage → Type: Deploy (Manifest)
Deploy (Manifest) Configuration
Basic Settings
Account
A Spinnaker account corresponds to a physical Kubernetes cluster. Must be previously configured.
Override Namespace
⚠️ There were (yet not elucidated) situations when even if a specific namespace configured in the Bake (Manifest) stage was ignored, and the deployment went to "default". That was fixed by overriding the namespace here.
Namespace
Manifest Configuration
Manifest Source
Artifact
Manifest Artifact
The display name of the manifest rendered at the Bake (Manifest) stage. If not explicitly configured, it will be generated to something similar to "tender-seahorse-98".
Expression Evaluation
Skip SpEL expression evaluation.
Skip SpEL expression evaluation of the manifest artifact in this stage. Can be paired with the "Evaluate SpEL expressions in overrides at bake time" option in the Bake Manifest stage when baking a third-party manifest artifact with expressions not meant for Spinnaker to evaluate as SpEL.
Required Artifacts to Bind
These artifacts must be present in the context for this stage to successfully complete. Artifacts specified will be bound to the deployed manifest. TO PROCESS: https://spinnaker.io/docs/reference/artifacts-legacy/in-kubernetes-v2/#binding-artifacts-in-manifests.
Rollout Strategy Options
The implementation behind the rollout strategies allows you to associate a new version of a workload with one or more services, decide whether the workload should receive traffic, and determine how Spinnaker should handle the previous version the workload currently being deployed in the same cluster and namespace. Because the implementation is based on the existing traffic management strategy, it is only valid for ReplicaSets workloads.
Also see:
Enable
Allow Spinnaker to associate each ReplicaSet deployed in this stage with one or more Services and manage traffic based on your selected rollout strategy options.
Service(s) Namespace
Select the namespace containing the service(s) to be associated with the workload.
Service(s)
Select one or more services to be associated with the workload.
Spinnaker will add a traffic.spinnaker.io/load-balancers annotation listing the selected services.
No service shows up in the Service(s) drop-down box.
Traffic
Send client requests to new pods
Strategy
The rollout strategy tells Spinnaker what to do with the previous version(s) of the ReplicaSet in the cluster.