-
Notifications
You must be signed in to change notification settings - Fork 15
Open
Labels
Description
Summary
Initial design should be a wrapper around kubectl. This will result in kubectl being a dependency on this module. However, the design should provide an abstraction so that in the future we can introduce the dotnet sdk for k8s or a powershell sdk if one is created.
Stories
- As a user, I would like to instantiate a new Kubernetes client so that I can fetch data.
- The ability to use a .kubeconfig file for authorization
- The ability to use a KUBECONFIG environment variable for authorization
- As a user, I would like to list pods in a namespace.
- As a user, I would like to list namespaces.
- As a user, I would like to list services.
- As a user, I would like to list ingresses.
- As a user, I would like to set up a port-forward tunnel so that the test is able to get to internal Api calls.
- As a user, I would like to verify that a Kubernetes secret exist. Note, this should NOT retrieve the secret value and only ensure that a secret is present in k8s.
- As a user I would like to verify that PVC and PV exist.
- Spike initial Module Surface with stub methods for implementation.
- Design K8sClient abstract interface that will abstract underlying calls.
- Implement Kubectl K8sClient concrete class to interact with k8s.
- Spike dotnet k8s sdk integration with powershell
AC
- BenchPress tests should be able to verify k8s resources (pods, ingresses, services etc)
- BenchPress tests should be able to set up a tunnel into k8s in order to access internal resources via http calls
- Module should target kuberenetes native and avoid any aks specificities.