Spinnaker – Providers

Docs: Amazon ECS

Mon, 01 Jan 0001 00:00:00 +0000

Resource mapping

Server group

A Spinnaker server group maps to an Amazon ECS service .

There are two ways to specify server group settings for Amazon ECS:

Inputs (default): Specify the container image, resource limits, and other settings needed to create an Amazon ECS task definition and service directly in the server group. This option supports deploying one container per Amazon ECS task (equivalent to a Spinnaker “instance”).
Artifact (supported as of 1.15.0): Specify a pipeline artifact to use as an Amazon ECS task definition for the service. The artifact should be a JSON file in the format of an Amazon ECS Register Task Definiton request . This option also requires that you specify containerName:imageDescription mappings for each image in your pipeline that you want to be deployed within the service. You can deploy multiple containers (up to 10) per Amazon ECS task using this option.

Instance

A Spinnaker instance maps to an Amazon ECS task . Amazon ECS services manage tasks to ensure desired capacity is reached.

Cluster

An Amazon ECS cluster does not map to any core Spinnaker concept. You can choose what cluster you deploy to in your deploy stage parameters.

Operation mapping

Deploy

Deploys a new Amazon ECS service to the specified server group(s). For load balanced services, the previous service will be drained after the new service is considered healthy.

Deployments to Amazon ECS take two actions in regards to Amazon ECS resources:

Register a new Amazon ECS task definition that contains the specified container(s), their image(s), and other information needed for your application to run.
Create a new Amazon ECS service that runs the registered task definition with the desired instance (task) count, load balancer, and scaling policies.

Destroy

Scales the desired count for the Amazon ECS service down to 0 instances (tasks), then deletes the service.

Disable

Scales the desired count for the Amazon ECS service down to 0 instances (tasks), so no instances are running.

Resize

Scales the Amazon ECS service up or down to the desired number of instances (tasks).

Resource Naming

From Spinnaker 1.24 the ECS provider can be configured to use either Frigga or a tag based naming strategy which Spinnaker manages using its Moniker library. The naming strategy is configurable per-account or applied as a default across all accounts.

ecs:
  enabled: true
  defaultNamingStrategy: "default"   <--- 'default' naming used by default (field absent) or if specified
  accounts:
    - name: "ecs-moniker-acct"
      awsAccount: "ec2-aws-acct"
      namingStrategy: "tags"         <--- 'tags' specified for specific account

`default` Naming Strategy

The default naming strategy uses the Frigga naming convention to parse information about resources. This derives all values for application, stack, detail, etc from the name of the resource.

`tags` Naming Strategy

The tags naming strategy uses information from tags on the resource to derive information like application, stack, detail, etc.

To use ECS service tags, your Amazon ECS account must be opted into using the long Amazon Resource Name (ARN) format . In addition, your AWS SpinnakerManaged role will need to call <code>ecs:ListAccountSettings</code> in order to validate whether your account is compatible with tags.

Currently these tags are only applied at the ECS service level which is then configured to propagate the tags to any tasks created by the service scheduler.

Reserved Tags

Several tags are used as metadata by Spinnaker to describe a resource. Tags listed below followed by a 📝 symbol may also be written by Spinnaker.

moniker.spinnaker.io/application 📝

The application this resource belongs to.

This affects where the resource is accessible in the UI, and depending on your Spinnaker Authorization setup, can affect which users can read/write to this resource.
moniker.spinnaker.io/cluster 📝

The cluster this resource belongs to.

This is purely a logical grouping for rendering resources in the UI and to help with dynamic target selection in Pipeline stages. For example, some stages allow you to select “the newest workload in cluster X”. How you set up these groupings depends on your delivery needs.
moniker.spinnaker.io/stack 📝, and moniker.spinnaker.io/detail 📝

These provide ways to group resources using Spinnaker’s cluster filters as well as apply policies such as Traffic Guards .
moniker.spinnaker.io/sequence 📝

The sequence number of the release this resource belongs to.

Each modification of a resource is deployed with a new sequence number in the format vNNN. This allows for multiple versions to be running and provides for rollback.

Docs: Amazon Web Services

Mon, 01 Jan 0001 00:00:00 +0000

Reference documentation coming soon!

See setup here

Docs: Azure

Mon, 01 Jan 0001 00:00:00 +0000

If you are not familiar with Azure or any of the terms used below, please consult the Azure reference documentation .

Resource mapping

Account

In Azure (AZ), an Account maps to a credential able to authenticate against a given Azure (AZ) project - see the setup guide .

Load Balancer

A Spinnaker load balancer maps to an Azure Application Gateway .

Server Group

A Spinnaker server group maps to an Azure Virtual Machine Scale Set .

Instance

A Spinnaker instance maps to an Azure Virtual Machine Instance .

Instances in a Virtual Machine Scale set all use the same standard/custom VHD.

Linux VM sizes WIndows VM sizes

Firewall

A Spinnaker firewall maps to an Azure Network Security Group .

Operation mapping

Deploy

Deploys a new Azure Virtual Machine Scale set.

Clone

Clones an Azure Virtual Machine Scale Set into a new Virtual Machine Scale set.

Destroy

Destroys an Azure Virtual Machine Scale set.

Resize

Not supported

Enable

Enables an Azure Virtual Machine Scale Set to receive traffic.

Disable

Disables an Azure Virtual Machine Scale set from receiving traffic.

Create Load Balancer

Creates a new Application Gateway in Azure.

Edit Load Balancer

Edits the properties of an Application Gateway.

Delete Load Balancer

Deletes an Application Gateway. Delete will fail if the App Gatway is connected to a Virtual Machine Scale Set.

Create Firewall

Creates a Network Security Group in the specified Virtual Network.

Clone Firewall

Clones a Network Security Group in the same virtual Network.

Edit inbound rules

Edit the inbound traffic rules on the corresponding Network Security Group.

Delete Firewall

Deletes the Network Security Group.

Docs: Cloud Foundry

Mon, 01 Jan 0001 00:00:00 +0000

If you are not familiar with Cloud Foundry (CF) or any of the terms used below, please consult Cloud Foundry’s reference documentation .

Resource mapping

Account

In CF, an Account maps to a user account on a CF foundation (where a foundation is a BOSH Director and all the VMs it deploys). This user account is provided via configuration to Spinnaker, and Spinnaker’s privileges are determined by the CF user account’s permissions; for example, Spinnaker can manage CF apps across all of the orgs and spaces which its CF user account can access.

A Spinnaker instance can use multiple CF user accounts to access one or multiple CF foundations.

Load Balancer

A Spinnaker Load Balancer maps to a CF route , which is associated with a CF app and does not have a separate resource name. The name of the route is the fully-qualified path, including host, domain, port, and path. A Load Balancer is created as part of a Server Group definition.

Example:

<host>.<domain>:<port>/<path>

Server Group

A Spinnaker Server Group maps to a deployment of a CF app in a specific foundation, org, and space. The CF app is named as APPNAME_STACK_DETAIL_VERSION, where APP_NAME is the app’s name in Spinnaker. If the app was deployed by Spinnaker, the CF app name will also include an appended -V with a version number.

When configuring a Server Group, you can either provide a manifest for your CF app or enter the parameters directly into the form (direct).

Region

A Spinnaker Region maps to a CF space . The Region is named as “ORG > SPACE”, where “ORG” is the name of the CF org and “SPACE” is the name of the CF space.

Instance

A Spinnaker Server Group Instance maps to a CF app instance.

Operation mapping

Deploy

Deploys a CF app (cf push). A deployment of a Server Group in Spinnaker causes a new CF app deployment.

Destroy

Deletes a CF app (cf delete). Deletion of a Server Group in Spinnaker causes deletion of a CF app.

Resize

Scales a CF app up or down (cf scale).

Enable

Starts a CF app (cf start). Enabling a Server Group in Spinnaker causes a stopped CF app to start.

Disable

Stops a CF app (cf stop). Disabling a Server Group in Spinnaker causes a CF app to stop.

Rollback

Starts the previous version of the Server Group (cf start) and disables the current running Server Group (cf stop).

Terminate Instance

Restarts a CF app instance. In CF, “Terminate Instance” is index-based. In the Spinnaker Server Group Instance name, the last digit is the CF app instance index .

Load Balancer Create

A Load Balancer is created as part of a Server Group definition.

Load Balancer Delete

Deletes a CF route.

Docs: Google App Engine

Mon, 01 Jan 0001 00:00:00 +0000

If you are not familiar with App Engine or any of the terms used below, please consult App Engine’s reference documentation .

Resource mapping

Account

A Spinnaker account maps to a single App Engine application, a top-level resource that contains services, versions, and instances. Spinnaker authenticates itself with App Engine using service account credentials for a Google Cloud Platform project - see the setup guide .

Load Balancer

A Spinnaker load balancer maps to an App Engine service.

A service has many versions (discussed below ), and a version’s app.yaml determines the service it belongs to. If a version’s app.yaml does not specify the name of a service, it will be deployed to the service named default.

Spinnaker cannot create a service, but if a service does not exist when a version is deployed, it will be created automatically.

A service’s traffic split determines how incoming traffic is allocated between versions.

Server Group

A Spinnaker server group maps to an App Engine version. An app.yaml file (which typically lives alongside your application source code) determines a version’s configuration. If necessary, you can provide Spinnaker with the contents of an app.yaml file when you deploy a version.

Instance

A Spinnaker instance maps to an App Engine instance.

Operation mapping

Deploy

Deploys an App Engine version.

At a high level, deploying to App Engine using Spinnaker has three steps:

You provide Spinnaker with a reference to a git repository, and some information about where your application lives inside that repository (e.g., branch).
Spinnaker clones your repository and finds your application.
Spinnaker deploys your application to a new version by executing gcloud app deploy.

If your pipeline includes a Deploy stage and has been triggered by a webhook or Jenkins job, you can dynamically resolve the git repository branch that Spinnaker uses to deploy.

Destroy

Destroys a version.

If a version is serving traffic, it will first be disabled .

You cannot destroy a version if it is the only version serving traffic from a service.

Enable

Sets a version’s traffic allocation to 100%.

This operation is provided as a convenience method. If you would like more fine-grained control over your versions’ traffic allocations, see Edit Load Balancer .

Disable

Sets a version’s traffic allocation to 0%, and sets the other enabled versions’ allocations to their relative proportions before the disable operation.

This operation is provided as a convenience method, and because it is used implicitly when destroying a version. If you would like more fine-grained control over your versions’ traffic allocations, see Edit Load Balancer .

You cannot disable a version if it is the only version serving traffic from a service.

Start

Starts an App Engine version - i.e., allows a version to scale according to its scaling policy.

This operation is only available if the version uses manual or basic scaling, or is running in the flexible environment.

Stop

Stops an App Engine version - i.e., scales a version down to zero instances.

This operation is only available if the version uses manual or basic scaling, or is running in the flexible environment.

Edit Load Balancer

Edits a service’s traffic split - i.e., the relative proportion of traffic that each version receives.

If your pipeline includes an Edit Load Balancer stage, you can resolve the targets of a traffic split dynamically.

Delete Load Balancer

Deletes a service. Deleting a service will also delete all of its versions.

You cannot delete the default service. However, you can disable your App Engine application from within the Google Cloud Console .

Terminate instance

Deletes an instance.

Docs: Google Cloud Run

Mon, 01 Jan 0001 00:00:00 +0000

If you are not familiar with Cloud Run or any of the terms used below, please consult Cloud Run’s reference documentation .

Resource mapping

Account

A Spinnaker account maps to a single Cloud Run application, a top-level resource that contains services, versions, and instances. Spinnaker authenticates itself with Cloud Run using service account credentials for a Google Cloud Platform project - see the setup guide .

Load Balancer

A Spinnaker load balancer maps to an Cloud Run service.

Spinnaker cannot create a service, but if a service does not exist when a version is deployed, it will be created automatically.

A service’s traffic split determines how incoming traffic is allocated between versions.

Server Group

A Spinnaker server group maps to an Cloud Run version. An app.yaml file (which typically lives alongside your application source code) determines a version’s configuration. If necessary, you can provide Spinnaker with the contents of an app.yaml file when you deploy a version.

Instance

A Spinnaker instance maps to an Cloud Run instance.

Operation mapping

Deploy

Deploys an Cloud Run version.

At a high level, deploying to Cloud Run using Spinnaker has three steps:

You provide Spinnaker with a reference to a git repository, and some information about where your application lives inside that repository (e.g., branch).
Spinnaker clones your repository and finds your application.
Spinnaker deploys your application to a new version by executing gcloud run deploy.

If your pipeline includes a Deploy stage and has been triggered by a webhook or Jenkins job, you can dynamically resolve the git repository branch that Spinnaker uses to deploy.

Destroy

Destroys a version.

If a version is serving traffic, it will first be disabled .

You cannot destroy a version if it is the only version serving traffic from a service.

Enable

Sets a version’s traffic allocation to 100%.

This operation is provided as a convenience method. If you would like more fine-grained control over your versions’ traffic allocations, see Edit Load Balancer .

Disable

Sets a version’s traffic allocation to 0%, and sets the other enabled versions’ allocations to their relative proportions before the disable operation.

You cannot disable a version if it is the only version serving traffic from a service.

Start

Starts an Cloud Run version - i.e., allows a version to scale according to its scaling policy.

This operation is only available if the version uses manual or basic scaling, or is running in the flexible environment.

Stop

Stops an Cloud Run version - i.e., scales a version down to zero instances.

This operation is only available if the version uses manual or basic scaling, or is running in the flexible environment.

Edit Load Balancer

Edits a service’s traffic split - i.e., the relative proportion of traffic that each version receives.

If your pipeline includes an Edit Load Balancer stage, you can resolve the targets of a traffic split dynamically.

Delete Load Balancer

Deletes a service. Deleting a service will also delete all of its versions.

You cannot delete the default service. However, you can disable your Cloud Run application from within the Google Cloud Console .

Terminate instance

Deletes an instance.

Docs: Google Compute Engine

Mon, 01 Jan 0001 00:00:00 +0000

If you are not familiar with Google Compute Engine or any of the terms used below, please consult Compute Engine’s reference documentation .

Resource mapping

Account

In Google Compute Engine (GCE), an Account maps to a credential able to authenticate against a given Google Cloud Platform (GCP) project - see the setup guide .

Load Balancer

A Spinnaker load balancer maps to a GCE load balancer .

GCE supports many different types of load balancers, including: HTTPS(S), SSL Proxy, Network and Internal. Each of these is supported by Spinnaker.

Server Group

A Spinnaker server group maps to a GCE Managed Instance Group .

GCE allows for both zonal and regional Managed Instance Groups, and Spinnaker supports both types.

Instance

A Spinnaker instance maps to a GCE Virtual Machine Instance .

GCE supports predefined machine types as well as custom machine types , and Spinnaker has support for the full range.

Firewall

A Spinnaker firewall maps to a GCE Firewall .

Spinnaker has user-friendly support for associating a new server group with a set of firewalls, and the correct target tags will be set on the newly-provisioned server group.

Operation mapping

Deploy

Deploys a GCE managed instance group.

A new GCE instance template is created for each new managed instance group.

If a deployed server group is load-balanced, Spinnaker uses instance metadata to store the relationship between the server group and load balancer. This is necessary to represent the object models in Spinnaker’s UI and to remember server group to load balancer relationships during server group enable and disable operations. Note that manipulating infrastructure (MIGs, load balancers) in GCE directly does not create the relationship metadata, and will most likely cause Spinnaker to misbehave.

Clone

Clones a GCE managed instance group.

Similar to a deploy operation, except that most of the attributes are optional. Any elided attributes will be inherited from the source managed instance group being cloned.

Destroy

Destroys a GCE managed instance group and its instance template.

If a managed instance group is serving traffic, it will first be disabled .

Resize

Resizes a GCE managed instance group.

If the managed instance group has an autoscaler configured, resize affects its min/max settings.

Enable

Registers a GCE managed instance group with its associated load balancers and discovery service so that it can receive traffic.

Disable

Deregisters a GCE managed instance group from its associated load balancers and discovery service so that it no longer receives traffic.

Rollback

Enables one server group and disables another. The disable is only initiated once the newly-enabled server group’s instances are all determined to be healthy.

Reboot instance

Performs a hard reset on an instance.

Terminate instance

Deletes an instance. In most cases, the managed instance group will provision a new instance to replace the terminated instance.

Terminate instance and shrink Server Group

Atomically deletes an instance and shrinks the target size of the managed instance group.

Create Load Balancer

Upserts and wires together all of the necessary resources to support Network, HTTP(S), Internal or SSL load balancing.

Depending on the type of load balancing desired, an assortment of regional/gobal forwarding rules, target pools/proxies, URL maps, backend services and health checks are required to be assembled. The create load balancer operation performs all of this configuration implicitly.

Edit Load Balancer

Modifies the attributes of an existing load balancer.

Delete Load Balancer

Deletes a load balancer and all of its resources.

This operation is not permitted unless there are no instances associated with the load balancer.

Create Firewall

Creates a firewall rule.

Target tags can be explicitly specified, or one can be automatically generated. Supports source filtering based on both tags and CIDRs.

Clone Firewall

Clones a firewall rule.

Supported only via the ui. The create firewall wizard is pre-populated with the attributes of the firewall

Edit inbound rules

Modifies the source filters, target tags and ingress rules of an existing firewall rule.

Delete Firewall

Deletes a firewall rule.

Docs: Kubernetes Provider Overview

Mon, 01 Jan 0001 00:00:00 +0000

If you’re unfamiliar with Kubernetes terminology, see the Kubernetes documentation .

This article describes how the Kubernetes provider works and how it differs from other providers in Spinnaker. If you’re unfamiliar with Kubernetes terminology, see the Kubernetes documentation .

The manifest-based approach

The Kubernetes provider combines the strengths of Kubernetes’s declarative infrastructure management with Spinnaker’s workflow engine for imperative steps when you need them. You can fully specify all your infrastructure in the native Kubernetes manifest format but still express, for example, a multi-region canary-driven rollout.

This is a significant departure from how deployments are managed in Spinnaker using other providers (including the legacy Kubernetes provider ). The rest of this doc explains the differences.

No restrictive naming policies

You can deploy existing manifests without rewriting them to adhere to Frigga . Resource relationships (for example between applications and clusters) are managed using Kubernetes annotations , and Spinnaker manages these using its Moniker library.

The policies and strategies are configurable per account. See Reserved Annotations for more details.

Accommodating level-based deployments

See the Kubernetes API conventions for a description of edge-based vs. level-based APIs.

Other providers in Spinnaker track operations that modify cloud resources. For example, if you run a resize operation, Spinnaker monitors that operation until the specified resize target is met. But because Kubernetes only tries to satisfy the desired state, and offers a level-based API for this purpose, the Kubernetes provider uses the concept of “manifest stability.”

A deployed manifest is considered stable when the Kubernetes controller-manager no longer needs to modify it, and it’s deemed “ready.” This assessment is different, obviously, for different kinds of manifests: a Deployment is stable when its managed pods are updated, available, and ready (running your desired container and serving traffic). A Service is stable once it is created, unless it is of type LoadBalancer, in which case it is considered stable once the underlying load balancer has been created and bound to the Service.

This manifest stability is how Spinnaker ensures that operations have succeeded. Because there are a number of reasons why a manifest never becomes stable (lack of CPU quota, failing readiness checks, no IP for a service to bind…) every stage that modifies or deploys a manifest waits until your affected manifests are stable, or it times out after a configurable period (30-minute default).

Using externally stored manifests

You can store and version your manifest definitions in Git (or elsewhere outside of the Spinnaker pipeline store).

With Spinnaker’s Artifact mechanism, file modifications/creations are surfaced as artifacts in pipeline executions. For example, you can configure a pipeline that triggers either when…

a new Docker image is uploaded, or
your manifest file is changed in Git

Reserved annotations

Several annotations are used as metadata by Spinnaker to describe a resource. Annotations listed below followed by a 📝 symbol may also be written by Spinnaker.

You can always edit or apply annotations using the <code>kubectl annotate</code> command .

Moniker

moniker.spinnaker.io/application 📝

The application this resource belongs to.

This affects where the resource is accessible in the UI, and depending on your Spinnaker Authorization setup, can affect which users can read/write to this resource.
moniker.spinnaker.io/cluster 📝

The cluster this resource belongs to.

This is purely a logical grouping for rendering resources in the UI and to help with dynamic target selection in Pipeline stages. For example, some stages allow you to select “the newest workload in cluster X”. How you set up these groupings depends on your delivery needs.
moniker.spinnaker.io/stack 📝, and moniker.spinnaker.io/detail 📝

These simply provide ways to group resources using Spinnaker’s cluster filters as well as apply policies such as Traffic Guards .

Caching

caching.spinnaker.io/ignore

When set to 'true', tells Spinnaker to ignore this resource. The resource is not cached and does not show up in the Spinnaker UI.

Strategy

strategy.spinnaker.io/versioned

When set to 'true' or 'false', this overrides the resource’s default “version” behavior described in the resource management policies . This can be used to force a ConfigMap or Secret to be deployed without appending a new version when the contents change, for example.
strategy.spinnaker.io/use-source-capacity

When set to 'true' or 'false', this overrides the resource’s replica count with the currently deployed resource’s replica count. This is supported for Deployment, ReplicaSet or StatefulSet. This can be used to allow resizing a resource in the Spinnaker UI or with kubectl without overriding the new size during subsequent manifest deployments.
strategy.spinnaker.io/max-version-history

When set to a non-negative integer, this configures how many versions of a resource to keep around. When more than max-version-history versions of a Kubernetes artifact exist, Spinnaker deletes all older versions. Resources are sorted by the metadata.creationTimestamp kubernetes property rather than the version number.

Keep in mind, if you are trying to restrict how many copies of a ReplicaSet a Deployment is managing, that is configured by <code>spec.revisionHistoryLimit</code> . If instead Spinnaker is deploying ReplicaSets directly without a Deployment, this annotation does the job.
strategy.spinnaker.io/recreate

As of Spinnaker 1.13, you can force Spinnaker to delete a resource (if it already exists) before creating it again. This is useful for kinds such as <code>Job</code> , which cannot be edited once created, or must be re-created to run again.

When set to 'true' for a versioned resource, this will only re-create your resource if no edits have been made since the last deployment (i.e. the same version of the resource is redeployed).

The default behavior is 'false'.
strategy.spinnaker.io/replace

As of Spinnaker 1.14, you can force Spinnaker to use replace instead of apply while deploying a Kubernetes resource. This may be useful for resources such as ConfigMap which may exceed the annotation size limit of 262144 characters.

When set to 'true' for a versioned resource, this will update your resources using replace. Refer to Kubernetes Object Management for more details on object configuration and trade-offs.

As of Spinnaker 1.35, deploy manifest stages support label selectors. However, label selectors don’t work with kubectl replace, so deploy manifest stages that specify label selectors to deploy resources with the replace strategy fail.

The default behavior is 'false'.
strategy.spinnaker.io/server-side-apply

As of Spinnaker 1.33, you can force Spinnaker to use server-side apply instead of the default client-side apply while deploying a Kubernetes resource. Server-side apply is a new merging algorithm, which allows calculating the final patch to update resources in the Kubernetes api-server instead of the client. This may be useful for CustomResourceDefinition or ConfigMap which may exceed the annotation size limit and cannot tolerate the replace strategy. Additionally, it will better identify and handle conflicts during merge by analyzing the managedFields annotation instead of the last-applied-configuration annotation.

When set to 'true' for a resource, this will update your resources using server-side apply. Refer to Kubernetes Server Side Apply for more details.

When set to 'force-conflicts' for a resource, this will update your resources using server-side apply and becomes the sole manager. Refer to Conflicts for more details.

Server-side apply feature was introduced as beta in Kubernetes 1.18 and graduated to GA in Kubernetes 1.22 .

The default behavior is 'false'.

Traffic

traffic.spinnaker.io/load-balancers

As of Spinnaker 1.10, you can specify which load balancers ( Services ) a workload is attached to at deployment time. This will automatically set the required labels on the workload’s Pods to match that of the Services’ label selectors .

This annotation must be supplied as a list of <kind> <name> pairs where kind and name refer to the load balancer in the same namespace as the resource. For example:
- traffic.spinnaker.io/load-balancers: '["service my-service"]' attaches to the Service named my-service.
- traffic.spinnaker.io/load-balancers: '["service my-service", "service my-canary-service"]' attaches to the Services named my-service and my-canary-service.
As of Spinnaker 1.14, instead of manually adding the traffic.spinnaker.io/load-balancers annotation, you can select which load balancers to associate with a workload from the Deploy (Manifest) stage. Spinnaker will then add the appropriate annotation for you.

Reserved labels

In accordance with Kubernetes’ recommendations on common labels , Spinnaker applies the following labels as of release 1.9:

app.kubernetes.io/name

This is the name of the Spinnaker application this resource is deployed to, and matches the value of the moniker.spinnaker.io/application annotation desribed here .
app.kubernetes.io/managed-by

Always set to "spinnaker".

This labeling behavior can be disabled by setting the property kubernetes.v2.applyAppLabels: false in clouddriver-local.yml.

How Kubernetes resources are managed by Spinnaker

Resource mapping between Spinnaker and Kubernetes constructs, as well as the introduction of new types of resources, is a lot more flexible in the Kubernetes provider than for other providers, because of how many types of resources Kubernetes supports. Also the Kubernetes extension mechanisms—called Custom Resource Definitions (CRDs) —make it easy to build new types of resources, and Spinnaker accommodates that by making it simple to extend Spinnaker to support a user’s CRDs .

Terminology mapping

It is worth noting that the resource mapping exists primarily to render resources in the UI according to Spinnaker conventions. It does not affect how resources are deployed or managed.

There are three major groupings of resources in Spinnaker:

server groups
load balancers
firewalls

These correspond to Kubernetes resource kinds as follows:

Server Groups ≈ Workloads
Load Balancers ≈ Services, Ingresses
Firewalls ≈ NetworkPolicies

Resource management policies

How you manage the deployment and updates of a Kubernetes resource is dictated by its kind, via the policies that apply to a particular kind. Below are descriptions of these policies, followed by a mapping of kinds to policies.

Operations

There are several operations that can be implemented by each kind:
- Deploy: Can this resource be deployed and redeployed? It’s worth mentioning that all deployments are carried out using kubectl apply to capitalize on kubectl’s three-way merge on deploy. This is done to accommodate running against your cluster, alongside Spinnaker, other tools that rely on the three-way merge semantics.
- Delete: Can this resource be deleted?
- Scale: For workloads only, can this resource be scaled to a desired replica count?
- Undo Rollout: For workloads only, can this resource be rolled back/forward to an existing revision?
- Pause Rollout: For workloads only, when rolling out, can the rollout be stopped?
- Resume Rollout: For workloads only, when the rollout is paused, can it be started again?
Versioning

If a resource is “versioned”, it is always deployed with a new sequence number vNNN, unless no change has been made to it. This is important for resources like ConfigMaps and ReplicaSets, which don’t have their own built-in update policy like Deployments or StatefulSets do. Making an edit to the resource in place, rather than redeploying, can have unexpected results and can delete history. Regardless, whatever the policy is, it can be overriden during a deploy manifest stage.

This policy can be overriden per-manifest using the strategy.spinnaker.io/versioned annotation described here .
Stability

This describes under what conditions this kind is considered stable after a new spec has been submitted.

Workloads

Anything classified as a Spinnaker server group is rendered on the Clusters tab in Spinnaker. If possible, any pods owned by the workload are rendered as well.

Resource	Deploy	Delete	Scale	Undo Rollout	Pause Rollout	Resume Rollout	Versioned	Stability
`DaemonSet`	Yes	Yes	No	Yes	Yes	Yes	No	The `status.currentNumberScheduled`, `status.updatedNumberScheduled`, `status.numberAvailable`, and `status.numberReady` must all be at least the `status.desiredNumberScheduled`.
`Deployment`	Yes	Yes	Yes	Yes	Yes	Yes	No	The `status.updatedReplicas`, `status.availableReplicas`, and `status.readyReplicas` must all match the desired replica count for the Deployment.
`Pod`	Yes	Yes	No	No	No	No	Yes	The pod must be scheduled, and pass all probes.
`ReplicaSet`	Yes	Yes	Yes	No	No	No	Yes	The `status.fullyLabledReplicas`, `status.availableReplicas`, and `status.readyReplicas` must all match the desired replica count for the ReplicaSet.
`StatefulSet`	Yes	Yes	Yes	Yes	Yes	Yes	No	The `status.currentRevision`, and `status.updatedRevision` must match, and `status.currentReplicas`, and `status.readyReplicas` must match the spec’s replica count.

Services, ingresses

Resource	Deploy	Delete	Versioned	Stability
`Service`	Yes	Yes	No	The `status.loadBalancer` field reports that a load balancer was found if and only if the service type is `LoadBalancer`.
`Ingress`	Yes	Yes	No	The `status.loadBalancer` field reports that a load balancer was bound.

NetworkPolicies

Resource	Deploy	Delete	Versioned	Stability
`NetworkPolicy`	Yes	Yes	No	Automatically stable .

ConfigMaps, secrets

Resource	Deploy	Delete	Versioned	Stability
`ConfigMap`	Yes	Yes	Yes	Automatically stable .
`Secret`	Yes	Yes	Yes	Automatically stable .

Docs: Oracle Cloud

Mon, 01 Jan 0001 00:00:00 +0000

For more information about Oracle Cloud or any of the terms used below, please consult Oracle Cloud Infrastructure Documentation .

Resource mapping

Account

The Oracle Cloud provider in Spinnaker maps a Spinnaker Account to an Oracle Cloud Infrastructure user in Oracle Cloud Infrastructure (OCI). Spinnaker authenticates itself with Oracle Cloud using OCI user credentials - see the setup guide .

Load Balancer

A Spinnaker load balancer maps to an OCI Load Balancer .

The OCI Load Balancing service offers a load balancer with your choice of a public or private IP address, and provisioned bandwidth. The essential components for load balancing include:

A load balancer with pre-provisioned bandwidth.
A backend set with a health check policy. See Managing Backend Sets .
One or more listeners . See Managing Load Balancer Listeners .
Optionally, you can associate your listeners with SSL server certificates to manage how your system handles SSL traffic. See Managing SSL Certificates .

Server Group

A Spinnaker server group maps to a group of OCI Virtual Machine Instances .

Instance

A Spinnaker instance maps to an OCI Virtual Machine Instance .

When you launch an instance, you choose the most appropriate shape which is a template describing the number of CPUs, amount of memory, and other resources allocated to a newly created instance. See Compute Shapes for a list of available VM shapes.

Firewall

In OCI, a security list provides a virtual firewall for an instance, with ingress and egress rules that specify the types of traffic allowed in and out. Each security list is enforced at the instance level.

The Oracle Cloud provider in Spinnaker currently does not support the ability to create firewalls for Oracle Cloud from Spinnaker. You can use the Oracle Cloud console to create and manage Security Lists to provide a virtual firewall for an instance.

Operation mapping

Deploy

Deploys a group of VM instances in OCI.

The Oracle Cloud provider in Spinnaker creates an Oracle Object Storage bucket named _spinnaker_server_group_data in the user’s tenancy to keep track of all the server groups created.

If a deployed server group is configured with load balancer, all VM instances of the server group are added to the backend set of corresponding listener in the load balancer.

Destroy

Destroys a server group and terminates all its VM instances. This also removes the server group information stored in _spinnaker_server_group_data bucket. If the server group is configured with a load balancer, all the VM instances of the server group are removed from the backend set.

Resize

Resizes a server group. If the server group is configured with load balancer, Oracle Cloud provider adds launched VM instances to the backend set, and removes terminated VM instances from the backend set.

Create Load Balancer

Creates a new Load Balancer in OCI.

Before you can implement a working OCI Load Balancer, you need:

A VCN with at least two public subnets for a public load balancer. Each subnet must reside in a separate availability domain. For more information on subnets, See VCNs and Subnets and Public vs. Private Subnets .
A VCN with at least one subnet for a private load balancer.

Delete Load Balancer

Deletes a load balancer and all of its resources.

Spinnaker – Providers

Docs: Amazon ECS

Resource mapping

Server group

Instance

Cluster

Operation mapping

Deploy

Destroy

Disable

Resize

Resource Naming

default Naming Strategy

tags Naming Strategy

Reserved Tags

Docs: Amazon Web Services

Docs: Azure

Resource mapping

Account

Load Balancer

Server Group

Instance

Firewall

Operation mapping

Deploy

Clone

Destroy

Resize

Enable

Disable

Create Load Balancer

Edit Load Balancer

Delete Load Balancer

Create Firewall

Clone Firewall

Edit inbound rules

Delete Firewall

Docs: Cloud Foundry

Resource mapping

Account

Load Balancer

Server Group

Region

Instance

Operation mapping

Deploy

Destroy

Resize

Enable

Disable

Rollback

Terminate Instance

Load Balancer Create

Load Balancer Delete

See Also

Docs: Google App Engine

Resource mapping

Account

Load Balancer

Server Group

Instance

Operation mapping

Deploy

Destroy

Enable

Disable

Start

Stop

Edit Load Balancer

Delete Load Balancer

Terminate instance

Docs: Google Cloud Run

Resource mapping

Account

Load Balancer

Server Group

Instance

Operation mapping

Deploy

Destroy

`default` Naming Strategy

`tags` Naming Strategy