Starting with Kubernetes, I'm in front of two schools:

• the first one invites me to create deployment files through kubectl create commands, such as:

export SPARK_NAME="spark"
export SPARK_DEPLOYMENT_YAML="deployment_spark.yaml"
export SPARK_DOCKER_IMAGE=comptes-france_spark

{
  kubectl create deployment $SPARK_NAME --image=$SPARK_DOCKER_IMAGE --dry-run=client -o=yaml

  echo "---"
  echo -e "# Service Spark"

  kubectl create service clusterip $SPARK_NAME --tcp=8080:8080 --dry-run=client -o=yaml
} > $SPARK_DEPLOYMENT_YAML

generating this kind of yaml files :

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: spark
  name: spark
spec:
  replicas: 1
  selector:
    matchLabels:
      app: spark
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: spark
    spec:
      containers:
      - image: comptes-france_spark
        name: comptes-france-spark-hz942
        resources: {}
status: {}
---
# Service Spark
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: spark
  name: spark
spec:
  ports:
  - name: 8080-8080
    port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app: spark
  type: ClusterIP
status:
  loadBalancer: {}

and it's convenient not having everything to write.
But will I find every command available for every need, in the future?

• the second school recommend to create my deployment yaml files myself.

What is the best practice?

CodePudding user response：

Kubectl create become complicated to handle complex deployment plus it's not that clean, hard for nested structure deployment/resources. plus something that you will predicate after its generation. So even in the question above, a YAML block is more readable and looks like deployment file which tells whole story about the manifest while the create command is like a normal bash script.

With deployment file, you can validate, convert and you can version the deployment up to some extent but there is again limitation with the deployment file as well, it does not accept templates, even hard to update image tag just for very simple deployment file.

To extend the deployment file reusability and get more control over deployment and versioning, can work with a wide variety of tools and become a cloud-native project which is also known as package manager for Kubernetes

Helm resolves the issues that we have with the standard deployment file and kubectl create command.

helm create helm-chart
helm upgrade -i my-app helm-chart

that simple, plus a single chart can be use for dev, staging and production with different value file/values.

Helm also work with famous GitOps tool like ArgoCD, which sync Kubernetes resources with GitHub repo as a single source of truth. Helm also working with IAAC tool like terraform

There are many more that make helm winner, while the helm chart are simple Kubernetes deployment file but with more flexibility.

CodePudding user response：

Yes you can use the deployment.yaml file also however it's not much flexible compare to helm charts.

You can keep the deployment.yaml with placeholders also and replace it run as per the requirement with SED command in CI/CD.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: APP_NAME
  name: APP_NAME
spec:
  replicas: 1
  selector:
    matchLabels:
      app: APP_NAME

and further deployment file will get applied in CI/CD.

You can also use the Kustomize to manage the configuration and apply the changes to K8s.

With the GitOps approach apply changes to K8s, use the Flux it's also lightweight good tool to manage the and sync repos to k8s on changes.

Example : https://github.com/fluxcd/flux2-kustomize-helm-example

Ref article : https://medium.com/alterway/manage-your-kubernetes-clusters-with-flux2-82dd1cfe2a6a