Spinnaker Stage Deploy (Manifest): Difference between revisions
| Line 38: | Line 38: | ||
====Service(s)==== | ====Service(s)==== | ||
Select one or more services to be associated with the workload. <font color=darkkhaki>Spinnaker will add a <code>traffic.spinnaker.io/load-balancers</code> annotation listing the selected services. TO PROCESS: https://spinnaker.io/docs/guides/user/kubernetes-v2/traffic-management/#attach-a-service-to-a-workload</font> | |||
====Traffic==== | ====Traffic==== | ||
Send client requests to new pods | Send client requests to new pods | ||
Revision as of 01:51, 26 February 2022
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
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.
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. TO PROCESS: https://spinnaker.io/docs/guides/user/kubernetes-v2/traffic-management/#attach-a-service-to-a-workload
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.