Currently kir has hardcoded instructions of which kinds it supports and where inside each's structure that the PodSpec could be found:
|
// GetPodSpec extracts the PodSpec from a Kubernetes object |
|
func GetPodSpec(obj interface{}) (*corev1.PodSpec, error) { |
|
switch resource := obj.(type) { |
|
case *corev1.Pod: |
|
return &resource.Spec, nil |
|
case *appsv1.Deployment: |
|
return &resource.Spec.Template.Spec, nil |
|
case *appsv1.DaemonSet: |
|
return &resource.Spec.Template.Spec, nil |
|
case *appsv1.ReplicaSet: |
|
return &resource.Spec.Template.Spec, nil |
|
case *appsv1.StatefulSet: |
|
return &resource.Spec.Template.Spec, nil |
|
case *batchv1.Job: |
|
return &resource.Spec.Template.Spec, nil |
|
case *batchv1.CronJob: |
|
return &resource.Spec.JobTemplate.Spec.Template.Spec, nil |
|
default: |
|
return nil, fmt.Errorf("object does not have a PodSpec") |
|
} |
|
} |
I'm imagining that it could be possible to "look for the PodSpec" in the YAML, and when it matches, extract the images from there.
Possible benefits could be:
- Less hardcoded kinds/structures.
- Easier to use with other (custom) resources that include a
PodSpec.
Possible drawbacks:
- Slower.
- Easier to get wrong.
- More brittle.
Currently
kirhas hardcoded instructions of whichkinds it supports and where inside each's structure that thePodSpeccould be found:kir/k8s/k8s.go
Lines 11 to 31 in 26fef45
I'm imagining that it could be possible to "look for the PodSpec" in the YAML, and when it matches, extract the images from there.
Possible benefits could be:
PodSpec.Possible drawbacks: