I am wondering what is the most “elegant” way to implement in a charm a kubernetes resource that is not supported by Juju’s pod_spec. For context, I am talking about charming with the operator framework. One idea would be to add in the charm a function that calls subprocess, to execute the manual command with kubectl. Any other ideas?
As for what type of resources that are not supported by pod_spec, one example is the Pod Security Policies. There is currently a bug opened for this (Bug #1886694 “Podspec for k8s charm does not support Pod Securit...” : Bugs : juju), and I am not expecting to see it included in the pod spec until the next release. However, if I have to charm an application that requires it, I am stuck. This is an example of a manifest for a Pod Security Policy :
Interacting with K8s API directly is not recommended because resources created in this way might not be cleaned up after application was removed for example.
But If you really want to do it, you can directly import k8s python client in the charm like this
from kubernetes import client, config
config.load_incluster_config()
v1 = client.CoreV1Api()
v1.list_namespace()
I don’t think that you can use load_incluster_config() from the charm code though, the charm is not running inside of a pod. Or is it? It failed when I tried to use that function.
hi @camille.rodriguez1 I think you should be able to just use the above code to do whatever I want to talk to the K8s API directly unless the service account mounted to the pod does not have sufficient permissions granted.
The charm usually runs in the k8s operator of the application, and it might run in the workload pod if you are talking to k8s in an action script.
For sure, you can use custom resources to create k8s resources if you already have any custom resources definitions deployed and custom resources definitions operators running.
