weaveworks / eks-quickstart-app-dev

Example flux manifests for eksctl gitops
Other
56 stars 43 forks source link

Add kubernetes dashboard component #1

Closed martina-if closed 5 years ago

martina-if commented 5 years ago

closes https://github.com/weaveworks/aws-workstream/issues/16

martina-if commented 5 years ago

What do you think about the folder layout?

cPu1 commented 5 years ago

Based on our discussion of cloning the base repo (eks-gitops-example) and generating overlays, the content of this repo is meant to go inside a base directory under the user's git repo:

├── base (upstream git repo containing base configuration cloned locally)
│   ├── kube-system
│   │   ├── aws-alb-ingress-controller
│   │   │   ├── deployment.yaml
│   │   │   └── rbac-role.yaml
│   │   ├── tiller-cluster-role-binding.yaml
│   │   ├── tiller-deploy-dep.yaml
│   │   ├── tiller-deploy-svc.yaml
│   │   └── tiller-service-account.yaml
│   ├── kustomization.yaml
│   ├── monitoring
│   │   ├── 0-namespace.yaml
│   │   ├── metrics-server.yaml
│   │   └── prometheus.yaml
│   └── system
│       ├── flux-helm-release-crd.yaml
│       └── helm-operator-deployment.yaml
├── overlays (generated by `eksctl install gitops` using cluster-specific information)
│   └── cluster-components
│       ├── alb-patch.yaml
│       ├── grafana-patch.yaml
│       ├── kustomization.yaml
│       └── prometheus-rules-patch.yaml
└── README.md

To achieve this structure, the directory cluster-components in this PR should be removed to make kube-system (and other namespaces) the top-level directory. Although I can see that having these manifest directories at the top level may result in inconsistency if we were to add files other than Kubernetes and Helm manifests later.