7 ms·

I probably wouldn't do this, but what problem does this cause?

ryapric 4y ago
The same problems any imperative management within declarative config causes -- drift. If the tool you're using supports declarative configuration, all changes should be made exclusively via the declarative interface to prevent that drift. In this example, the new image should be added to the original manifest itself, not via a CLI update.
- throwaway894345 4y ago
  It depends on how you manage your changes. A lot of people don't have their infra-as-code manage the deployment's image field--rather, that's updated by the application's CD pipeline. There's no drift to worry about.
  - xbar 4y ago
    So upon deploy the CD pipeline calls kubectl with the proper deployment image and that's ok?
    - throwaway894345 4y ago
      Yes.
sgarland 4y ago
Drift, as the other child comment mentions, but also loss of version control. I do not want to have to trawl through someone's shell history to figure out what they changed, nor do I want to have to redirect `kubectl get foo -o yaml` output into diff. If everything is in code, and you have a reasonable branching strategy, it's much easier to control change, to rollback bad merges, to run pre-hooks like security checks and configuration validation tools, etc.
- thinkmassive 4y ago
  You know kubectl has a built in diff subcommand?
  - sgarland 4y ago
    I do now! Thank you.
- throwaway894345 4y ago
  It's not drift, because the infra-as-code doesn't manage the image field (the application's CD pipeline does). You don't trawl through someone's shell history', you look at the CD pipeline history. Rollbacks are easy--you just deploy the prior version via your CD tool. I think you're assuming that invoking kubectl means invoking it directly from a user's command line, but kubectl can also be called in a CD script.
  - sgarland 4y ago
    If you're using ArgoCD or something then sure, but bear in mind the original statement you made was directed at someone who is new to K8s, and given a command that can be executed from their shell, they would likely assume that's what you meant.
    - throwaway894345 4y ago
      It doesn’t have to be Argo, it can be Jenkins. Whether or not you use a CD pipeline is orthogonal to whether or not you use k8s. The best practice is to use a pipeline whether you’re targeting k8s or bare VMs or a higher level PaaS abstraction.
    - I_dev_outdoors 4y ago
      I'm not new to Kubernetes and I've been using containers since Solaris zones were introduced.
alias_neo 4y ago
The declarative approach is a more sustainable way to run Kubernetes. If you define some desired state in manifests and apply them to a cluster, they can be applied again to new clusters or the same one and Kubernetes will attempt to maintain the desired state. This state can be version controlled, written in stone, whatever you prefer and it can always be attained. When administrators start issuing imperative commands to a cluster, state starts being changed and there is no record[0] of the state Kubernetes is being asked to maintain. [0] Not entirely true, the state can always be retrieved from the cluster so long as it hasn't failed.
- jen20 4y ago
  I find this to be a common misconception, stemming from a misunderstanding of what "declarative" means (especially common when people are discussing tools like Terraform). Firstly as you point out, there is a record of the state Kubernetes is being asked to maintain: it's in the API server as the spec of each resource. Secondly, using `kubectl` "patch" in the manner described is not making changes to the cluster state directly, it's making changes to the specification of what should be maintained, and the various controllers effect the state changes. Fundamentally, the argument seems to come down to "you don't have a record of what you once asked the API server to do", and that's fair enough - you don't. But that has nothing to do with imperative or declarative models. I'm not advocating actually doing this on a day-to-day basis, but the arguments against it are not ones of imperative vs declarative.
  - sgarland 4y ago
    Given that Kubernetes' docs[0] discuss using imperative commands, I think it's a fairly reasonable way to describe it. [0] https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-command/ https://kubernetes.io/docs/tasks/manage-kubernetes-objects/i...
    - throwaway894345 4y ago
      Why is applying a full manifest “declarative” but applying a patch is “imperative”? That’s clearly an error.

The same problems any imperative management within declarative config causes -- drift. If the tool you're using supports declarative configuration, all changes should be made exclusively via the declarative interface to prevent that drift. In this example, the new image should be added to the original manifest itself, not via a CLI update.

throwaway894345 4y ago
It depends on how you manage your changes. A lot of people don't have their infra-as-code manage the deployment's image field--rather, that's updated by the application's CD pipeline. There's no drift to worry about.
- xbar 4y ago
  So upon deploy the CD pipeline calls kubectl with the proper deployment image and that's ok?
  - throwaway894345 4y ago
    Yes.

sgarland 4y ago

Drift, as the other child comment mentions, but also loss of version control. I do not want to have to trawl through someone's shell history to figure out what they changed, nor do I want to have to redirect `kubectl get foo -o yaml` output into diff. If everything is in code, and you have a reasonable branching strategy, it's much easier to control change, to rollback bad merges, to run pre-hooks like security checks and configuration validation tools, etc.

thinkmassive 4y ago
You know kubectl has a built in diff subcommand?
- sgarland 4y ago
  I do now! Thank you.
throwaway894345 4y ago
It's not drift, because the infra-as-code doesn't manage the image field (the application's CD pipeline does). You don't trawl through someone's shell history', you look at the CD pipeline history. Rollbacks are easy--you just deploy the prior version via your CD tool. I think you're assuming that invoking kubectl means invoking it directly from a user's command line, but kubectl can also be called in a CD script.
- sgarland 4y ago
  If you're using ArgoCD or something then sure, but bear in mind the original statement you made was directed at someone who is new to K8s, and given a command that can be executed from their shell, they would likely assume that's what you meant.
  - throwaway894345 4y ago
    It doesn’t have to be Argo, it can be Jenkins. Whether or not you use a CD pipeline is orthogonal to whether or not you use k8s. The best practice is to use a pipeline whether you’re targeting k8s or bare VMs or a higher level PaaS abstraction.
  - I_dev_outdoors 4y ago
    I'm not new to Kubernetes and I've been using containers since Solaris zones were introduced.

alias_neo 4y ago

The declarative approach is a more sustainable way to run Kubernetes. If you define some desired state in manifests and apply them to a cluster, they can be applied again to new clusters or the same one and Kubernetes will attempt to maintain the desired state. This state can be version controlled, written in stone, whatever you prefer and it can always be attained. When administrators start issuing imperative commands to a cluster, state starts being changed and there is no record[0] of the state Kubernetes is being asked to maintain. [0] Not entirely true, the state can always be retrieved from the cluster so long as it hasn't failed.

jen20 4y ago
I find this to be a common misconception, stemming from a misunderstanding of what "declarative" means (especially common when people are discussing tools like Terraform). Firstly as you point out, there is a record of the state Kubernetes is being asked to maintain: it's in the API server as the spec of each resource. Secondly, using `kubectl` "patch" in the manner described is not making changes to the cluster state directly, it's making changes to the specification of what should be maintained, and the various controllers effect the state changes. Fundamentally, the argument seems to come down to "you don't have a record of what you once asked the API server to do", and that's fair enough - you don't. But that has nothing to do with imperative or declarative models. I'm not advocating actually doing this on a day-to-day basis, but the arguments against it are not ones of imperative vs declarative.
- sgarland 4y ago
  Given that Kubernetes' docs[0] discuss using imperative commands, I think it's a fairly reasonable way to describe it. [0] https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-command/ https://kubernetes.io/docs/tasks/manage-kubernetes-objects/i...
  - throwaway894345 4y ago
    Why is applying a full manifest “declarative” but applying a patch is “imperative”? That’s clearly an error.