All Collections
User Guide
Extensions
Import an existing Kubernetes project to gopaddle
Import an existing Kubernetes project to gopaddle
Onboard an existing Kubernetes project to gopaddle
Vinothini Raju avatar
Written by Vinothini Raju
Updated over a week ago

If you already have a kubernetes project that contains the YAML files for deploying a service, you can use gopaddle command line utility to onboard a pre-existing source code project from github to gopaddle.

By importing a pre-exisiting project to gopaddle, you get out-of-the-box DevOps automation and monitoring in minutes.

A Kubernetes project can be imported either from a gitOps setup where the YAML files are maintained in a git repository or from a running Kubernetes deployment.

Pre-requisite

1. Download and configure gopaddle command line utility by following the steps mentioned here;

2. Kubernetes specifications can be imported to gopaddle in two ways. (a) You can import YAML files from your local folder (b) You have the YAML files checked in to your source control repository like github. In case of (b), Register the source control repository from the gopaddle UI by following the steps mentioned here. Only github private repositories are supported currently.

3. Register the Docker registry from the gopaddle UI

(a) Migrate from plain YAML files in a local folder:

3. If you wish to export the YAML files from a namespace already deployed in your cluster, you can optionally follow the below steps.

3.1 Ensure you have kubectl installed in your local machine and have connectivity to your kubernetes cluster.

kubectl config view

3.2 Down the export script from the below link.

Download export.sh

3.3 Set the script permissions

chmod +x export.sh

3.4 Execute the export script by passing the namespace as the input parameter. This will create a folder in the name of the namespace and export all the namespace specific resource YAML files. This folder can be used in the next gpctl import command.

sh export.sh <namespace>

4. Using gpctl, run the import to import the YAML files from source code repository to gopaddle.

gpctl import --yamlFolder=<pathToYAMLFolder> [--templateID=<templateID>]

  • yamlFolder - Path to the folder where the YAML files exist

  • templateID - Add the imported services to a pre-existing Deployment Template.

(b) Migrate from Source Control Repository:

4. Using gpctl, run the import to import the YAML files from source code repository to gopaddle.

gpctl import --url=<gitcloneURL> --provider=github --path=<pathToYAML> --originName=<originName> --originType=<originType> --scmID=<scmGopaddleRepoID> [--templateID=<templateID>]

  • gitCloneURL - git clone URL where the source code resides. eg: https://github.com/honestbee/flask_app_k8s.git

  • pathToYAML - path in the source code where the kubernetes YAML files reside. For example "kubernetes" folder in the above project.

  • originName - branch or the tag name. Eg. "master"

  • originType - "branch" (or) "tag".

  • scmGopaddleRepoID - You can get the repo ID from the gopaddle UI once the SCM repo is registered.

  • templateID - Add the imported services to a pre-existing Deployment Template.

Ignored Fields:

Below is the list of fields that will be ignored during the import.

Kind

Kube Spec fields

Supported ?

Custom Conversion

Selectors (all level)

No

Labels (all level)

No

Pod

spec.containers[].env[].valueFrom.resourceFieldRef

No

Pod

spec.containers[].command

Partial

Ignored if the container is onboarded as Codebased container in gopaddle. Can be added later while adding the build script to the codebased container.

Pod

spec.containers[].args

Partial

Ignored if the container is onboarded as Codebased container in gopaddle. Can be added later while adding the build script to the codebased container.

Pod

spec.containers[].resources

Yes

if one of the resource.request or resource.limits is omitted, then it is set based on what is provided in the resource.request or resource.limits field. If both the values are omitted, then gopaddle default policy is assigned.

Pod

spec.containers[].livenessProbe.failureThreshold

No

Pod

spec.containers[].livenessProbe.successThreshold

No

Pod

spec.containers[].livenessProbe.timeoutSeconds

No

Pod

spec.containers[].livenessProbe.tcpSocket

No

Pod

spec.containers[].livenessProbe.httpGet.httpHeaders

No

Pod

spec.containers[].readinessProbe

Partial

Readiness probe set in the source spec is ginored. If Liveness probe is specified in the source spec, then its values are copied as the Readiness probe at the time of deployment. gopaddle UI does not have support for readiness probe.

Pod

spec.containers[].startupProbe

No

Pod

spec.containers[].securityContext

runAsUser & runAsGroup are set to 0 when not present

Pod

spec.containers[].securityContext.seccompProfile

Pod

spec.containers[].securityContext.seLinuxOptions

Pod

spec.containers[].securityContext.allowPrivilegeEscalation

No

Pod

spec.containers[].securityContext.capabilities

No

Pod

spec.containers[].imagePullPolicy

No

Pod

spec.containers[].terminationMessagePolicy

No

Pod

spec.containers[].terminationMessagePath

No

Pod

spec.containers[].lifecycle

No

Pod

spec.containers[].volumeDevices

No

Pod

spec.securityContext.fsGroupChangePolicy

Pod

spec.volumes[].downwardAPI

No

Pod

spec.volumes[].volumeSource

Supported:

  • csi (storidge CIO)

  • emptyDir

  • gcePersistentDisk

  • awsElasticBlockStore

  • azureDisk

  • nfs

Unsupported :

  • Glusterfs

  • RBD

  • ISCSI

  • Cinder

  • CephFS

  • FC

  • Flocker

  • FlexVolume

  • AzureFile

  • VsphereVolume

  • Quobyte

  • PhotonPersistentDisk

  • PortworxVolume

  • ScaleIO

  • StorageOS

StatefulSet

spec.podManagementPolicy

No

ConfigMap

data

Partial

<key>: <value> 
<key>: |
     <data1>
     <data2>

Both <key,value> and <key, data1/data2> get mapped to a file entry in gopaddle within the configuration, but while creating the kubernetes resources, these entries will be translated to the original format.

NetworkPolicy

spec.ingress.from[].namespaceSelector.matchLabels

No

NetworkPolicy

spec.ingress.from[].podSelector.matchLabels

No

NetworkPolicy

spec.egress.to[].namespaceSelector.matchLabels

No

NetworkPolicy

spec.egress.to[].podSelector.matchLabels

No

NetworkPolicy

spec.ingress.from[].cidr.ipBlock.except[]

No

NetworkPolicy

spec.egress.to[].cidr.ipBlock.except[]

No

NetworkPolicy

spec.ingress.ports[] & spec.egress.ports[]

Partial

Converts to gopaddle networkpolicy with multiple ports, but gopaddle UI will show only the first port in the ports array.

HorizontalPodAutoscaler

spec.metrics[].type

Only "Resource" type is supported. Pods, Objects and External are not supported

metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50


is converted to autoscaling/v1 API spec.

spec: minReplicas: 1 maxReplicas: 10 targetCPUUtilizationPercentage: 50

Ingress

metadata.annotations

Note : 

If a configMap or secret file location is not available in the project, a new configMap or secret will be created in gopaddle. Later, it can be edited with actual content from the gopaddle console.

If a configMap or secret specification is represent in the source control repository but is not used within a Deployment or a Stateful set, then it will not be imported in to gopaddle.

If networkPolicy alone is present and there is no associated deployment/stateful set in the source project then the network policy will not be imported to gopaddle.

Did this answer your question?