Deployment to Kubernetes namespace with Git based Manifest
Last updated
Last updated
A Kubernetes manifest is a text file that details a deployment. Deployment manifests however are usually stored in a repository like Github or bitbucket.
To deploy a manifest from ISD follow the steps below:
Go to Application Dashboard: When you log in to ISD the application dashboard is displayed with the list of applications. You can create a new application also as given in create a new application.
Click on the application for which you want to build this pipeline.
Pipeline Builder: Once you click on an application, it will redirect you to the Pipelines page. Click +Create button to create a new pipeline. Users can also view the existing pipelines displayed on the left.
Click on Add stage: The add stage button is displayed below the diagrammatic representation of the created pipeline. When you click this button, you can select the different types of stages that ISD supports.
Select Deployment: You can add a host of different stages from the Type drop down. They are all alphabetically sorted. Scroll down and select Deploy(Manifest).
Select your account: An account is the name given to a kubernetes cluster.
Select your namespace: A namespace is a specific address within a Kubernetes cluster, select the checkbox that says Override Namespace and you will be able to select the namespace in which your manifest will deploy.
Define the file and the repository you are going to deploy the artifact from: Select Artifact, and you will be prompted to select the repository which you are deploying from. In addition you must specify the URL of the artifact and the branch it is located in.
Manifest Artifact: The artifact that is to be applied to the Kubernetes account for this stage. The artifact should represent a valid Kubernetes manifest.
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 be successfully completed. Artifacts specified will be bound to the deployed manifest.
Rollout Strategy Options: If enabled, 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.
8. After updating the above details, Click Save Changes to deploy the Git based manifest.
