You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 11, 2021. It is now read-only.
I know this isn't an ideal situation, but isn't unheard of, but can sometimes be necessary.
Essentially, there are some Kubernetes Resources that we might want to update, without creating, e.g. Updating the Default Service Account for a Namespace to modify the default pull credentials, adding a TCP Service to Nginx TCP Services for the Nginx Ingress.
Therefore, there might be 2 scenarios, which could be configured 2 ways.
With this approach, we bring this resource into Terraform management as if it was created by Terraform, and will be updated from there onwards, whenever anything changes in the configuration, and will be deleted (if possible), when you delete the resource.
Modify the Kubernetes Resource, with no future tracking.
With this approach, it is essentially performed like kubectl patch, or kubectl apply, it will update the resource, with no attempts to synchronise the resource, and if you delete the resource, it won't attempt to delete it from the Kubernetes Cluster.
This could be represented by a property called something like if_exists, which could be the values:
fail
attach
patch
The reason for these, without doing a manual import, is that it allows for dynamic creation, without having to break up the apply step into multiple parts.
Description
I know this isn't an ideal situation, but isn't unheard of, but can sometimes be necessary.
Essentially, there are some Kubernetes Resources that we might want to update, without creating, e.g. Updating the Default Service Account for a Namespace to modify the default pull credentials, adding a TCP Service to Nginx TCP Services for the Nginx Ingress.
Therefore, there might be 2 scenarios, which could be configured 2 ways.
Inherit control of the Kubernetes Resource.
As seen with default resources in the AWS Provider: https://www.terraform.io/docs/providers/aws/r/default_vpc.html
With this approach, we bring this resource into Terraform management as if it was created by Terraform, and will be updated from there onwards, whenever anything changes in the configuration, and will be deleted (if possible), when you delete the resource.
Modify the Kubernetes Resource, with no future tracking.
With this approach, it is essentially performed like
kubectl patch
, orkubectl apply
, it will update the resource, with no attempts to synchronise the resource, and if you delete the resource, it won't attempt to delete it from the Kubernetes Cluster.This could be represented by a property called something like
if_exists
, which could be the values:fail
attach
patch
The reason for these, without doing a manual import, is that it allows for dynamic creation, without having to break up the apply step into multiple parts.
Potential Terraform Configuration
Community Note
The text was updated successfully, but these errors were encountered: