Gardener Dashboard Documentation
Copyright 2020 The Gardener Authors
Web-based GUI for Gardener installations.
License: Apache License 2.0
Gardener Dashboard Documentation
Copyright 2020 The Gardener Authors
When the displayed clusters receive many events, the rendering clogs the CPU. If possible (limited investment), let's find out whether we can defer the rendering for e.g. 200ms (after the first new event hits the backend).
To be spec'ed:
By @vlerenc: We want to offer trial clusters, but we need quota/limits for those.
Per IaaS account (which we model today, maybe not ideally, as a secret):
Alternatively, for now, we could simplify that by a VMs quota, but then we would need to restrict the machine types (since they differ significantly in their resources and prices, especially when looking at the GPU-based machine types).
Per Gardener project (which we model as namespace):
Note: We may have/want to add more resource types over time. Some are infrastructure specific (if not abstracted) like e.g. the disk type.
This way we could achieve the following:
gp2
and 1 TB io1
Disk, 4 LB services and 200 GB gp2
and 50 GB io1
PVCs per cluster, cluster auto-termination after 28 daysgp2
Disk, cluster auto-termination after 7 daysio1
disks, or yet another to extend the lifetime of their clustersNote: See also #101.
Note: Most of these quotas can be enforced by an admission controller in the garden cluster, but the LBs and PVC size quotas will require similar controllers in the respective shoot clusters themselves, which we can handle with lower priority/later. Actually, it would be nice if LBs and PVC size quotas could be specified on the IaaS account level for the entire IaaS account, but that would require the shoot cluster admission controller to call back to the garden cluster, which is currently not possible (not reachable), so let's go with the per-cluster simplification.
Note: We support worker count min/max, i.e. cluster auto-scaling. Check the max requirements against the quota, i.e. assume the worst case.
Note: If quotas are set for the IaaS account and the Gardener project, both must comply (simplest strategy for now).
Note: Make sure a cluster member can't change these quotas. Later we may allow that, e.g. in a non-trial use case a customer purchases a certain quantity of resources and allots it to its projects.
Note: Secrets are currently placed into the Gardener project and must be readable, but we don't want that. They should be "somewhere else" outside the namespace, so that their contents are protected (not be directly visible in the project, but when a cluster is created, they appear in the tf-vars of the infrastructure terraform files, which is bad, but acceptable for now). That would also ease setting the overal quota (per IaaS account). One possible solution to refer them is described in #102, but it's not ellegant as it requires two different code paths in the operator and UI to handle these cases. It would be better if we find a solution where the secret feels the same, whether its shared or not.
Implementation Proposal:
ResourceQuota
s, but in our API group (see 1 and 2) to describe quotas per IaaS account and Gardener project.ResourceQuota
s and admission controllers (per quota) or combine them into one in the first step, but this may make later extensions, especially when we open source, somewhat harder (still, if it speeds us up, let's go with a combined ResourceQuota
and admission controller)dashboardUrl should now be pointing to /api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
Background: several incompatible changes were put forth by the community:
a) change to proxy subresource (with v1.8.0)
b) change to https (with v1.7.1)
for ref, see history of https://github.com/kubernetes/dashboard/commits/master/src/deploy/recommended/kubernetes-dashboard.yaml
(we probably can expect further incompatible changes, which might require some kubernetes-dashboard version dependant configmap)
Let's please remove the username and password from the endpoint URLs as this isn't working anymore anyways with the new dashboard and is considered a security issue.
Help ease the work of the operator (of the week) to drop https://github.wdf.sap.corp/kubernetes/kube-docs/wiki/Operator-of-the-Week-Journal which is hard to maintain.
As long as we use the dashboard also as front-end to our self-service/canary users, we might want to hide the journal and labels from the users. Later, this distinction and double-use (self-service and ops frontend) won't be necessary anymore and the journal can be shown to the operators in general.
As a practical and quick solution, let's use GitHub for issues, journal (in the form of issue comments) and labels (in the form of issue labels). That way we do not have to implement much on our own. We only read the data conveniently from GitHub with a technical user and delegate to GitHub for editing with the true actual/human user.
See also #5 and #33. This resolves two thirds of #8 s well.
In order for the landscape deployment, the Gardener packages itself as Helm chart, see https://github.com/gardener/gardener/tree/master/charts. When this is stable, it would be great to also have a Helm chart for the dashboard (one or two, depending on whether we should package dex separately), so that a landscape can be set up using the same means.
Previously, closed journal issues were not visible in the Dashboard, but they seem to be shown now?
As evident from some internal Slack communication, users struggle to set up their Azure, GCP and OpenStack technical users and permissions. Let's contact @AndreasBurger and @dkistner (for Azure), @DockToFuture and @mliepold (for GCP) and @mandelsoft and @afritzler (for OpenStack) to improve the descriptions with their feedback.
However, it may well be, that we should also give some internal advice/hints (how to apply for a technical user within our company - or any other for that matter), so maybe we have to pull that configuration out? If possible we should avoid it at first (given the other backlog), but the time will come that this may become necessary for the community and us.
With the advent of the machine controller manager and the machine API, we should rename:
workers
into machines
WORKER
into MACHINES
Group Name
into Pool Name
cpu-worker
(default) into cpu-pool
At present everybody at SAP has access to all our landscapes (SAP IdP, in contrast to LDAP, doesn't give us groups). However, that means that everybody has access to our dev, staging, and live landscapes.
Maybe we could help us with some cluster role on dev, staging and live, that would allow only a dedicated set of users? The basis of that user list could be the users list in landscape-dev-garden#5.
Prerequisite is gardener/gardener#84 that introduces maintenance time windows into the shoot cluster resources.
The dashboard does no longer need to create the Terraformer ClusterRoleBinding
when creating a project/namespace:
dashboard/backend/lib/kubernetes/Client.js
Lines 455 to 477 in 4a059ce
The Terraform jobs are running in the Seed clusters and the Gardener creates the required (Cluster)RoleBinding
s itself.
For performance reasons we have disabled "some seconds/minutes ago". Let's take a look whether we can enable it with a smarter time and where it would make sense to do so (in some cases the date may be sufficient, e.g. when it happened long ago).
This is a mid-term mitigation for #23: Can we please allow the user in the creation dialog and later in the details view to create/edit (ideally in-place) the yaml definition of the shoot cluster (spec only ?).
Help ease the work of the operator (of the week) to drop https://github.wdf.sap.corp/kubernetes/kube-docs/wiki/Operator-of-the-Week-Journal which is hard to maintain.
As long as we use the dashboard also as front-end to our self-service/canary users, we might want to hide the journal from the users. Later, this distinction and double-use (self-service and ops frontend) won't be necessary anymore and the journal can be shown to the operators in general.
When I press the copy kubeconfig button in the cluster details view, nothing seems to get copied into my clipboard?
We as provider want to motivate our users to run the latest Kubernetes version, so that we have less issues with the clusters, offer the latest features and can faster drop support for older Kubernetes versions.
grep
the information out of the overall/global Gardener logs.We like to improve the way how we interact/access the Gardener/cluster logs. As an operator (of the week) I frequently have to check what the Gardener says/logs on a certain cluster and operation. Now with the reconciler, the logs grew and with all the other planned features, they will even grow more. Usually, we need to know something specific about a particular cluster, for a particular operation at a particular date/time (gardener/gardener#49). A central logging stack and UI (e.g. in the Garden cluster) will help me, but we can only expose it to project members if it supports multi-tenancy.
We could use the Kubify-deployed logging stack and instead of showing the logs for an operation directly in the dashboard, the dashboard could generate a query for said logging stack that shows the right logs in the logging UI. Of course, as long as the logging stack doesn't support multi-tenancy, this would mean that the feature would be only available to the core team/admins, not to project members. This would be acceptable. The primary goal is to help our operators (of the week) and that solution would fully serve that purpose.
Integrate tests into CI pipeline:
Clusters that are created with trial secrets will usually self-terminate (default is 7 days, but it depends). The user should know of this.
Issue by rfranzke
Monday Dec 04, 2017 at 07:03 GMT
Originally opened as https://git.removed/kubernetes-attic/gardener-ui/issues/151
When a Shoot cluster has reached state "Create Failed" and I try to delete it (clicking on the bin, entering its name and clicking on confirm), the Shoot cluster overview does not reload automatically (i.e. I don't see that my delete request succeeded).
When I refresh the page, I can see that the cluster has state "Delete processing".
Let's please prepare and make a real (CI pipeline) release of the Dashboard for the new landscapes:
@rfranzke and @mandelsoft implemented a cluster operation retry in the Gardener that can be initiated with an annotation at the shoot resource. To expose this functionality to our users, we can now add some retry button or similar means to the Dashboard for failed shoot clusters (operations).
With the advent of the automated cluster updates and the machine controller manager, we will be able to change an existing shoot cluster, so let's expose this functionality.
Replace cluster creation dialog with a page similar to cluster details. That page can then be used to create a cluster, see its configuration and change it. Also make the yaml view editable, so that users can e.g. tweak the network settings (expert mode) and more directly in yaml (and the dashboard doesn't need to implement these complex scenarios).
In the shoot list, when trying to search for a shoot, nothing happens.
This seems to be related to this issue: vuetifyjs/vuetify#3475
We probably have to filter in the vuex store.
When working with large projects or when using the "all projects" view as administrator, we are currently facing frontend performance issues. A first analysis showed that this is caused by re-rendering every single row in the table when a shoot in the client store changes. The root cause is probably bad / wrong usage of computed properties.
We should
Other changes may be necessary in order to get this to work properly.
Help ease the work of the operator (of the week) to drop https://github.wdf.sap.corp/kubernetes/kube-docs/wiki/Operator-of-the-Week-Journal which is hard to maintain.
As long as we use the dashboard also as front-end to our self-service/canary users, we might want to hide the labels from the users. Later, this distinction and double-use (self-service and ops frontend) won't be necessary anymore and the labels can be shown to the operators in general.
Let's please hide the monitoring endpoints for non-admins (like seed and journal), so that "normal" users can't see our monitoring.
Gardener shall not only become the technical means to operate Kubernetes clusters, but also a collaboration platform. Some of the above ideas were proposed by @vasu1124, while others were driven by others like the operators (of the week) (e.g. #5).
Replace hard-coded visualisations of clusters and inner entities (like pods and more) and lists of the same with a wiki engine and render templates we store as third party resources in the Garden cluster. Add a ticketing system.
Hi,
I've noticed that once you've created a cluster, you cannot find any information about the worker you've defined (apart from looking into the yaml config). For me it would be interesting to see the VM types (and maybe autoscaler and disk information) of my worker groups.
Any thoughts on that?
Best regards
Daniel
We have dropped the network sections from the cluster creation dialog (in the old UI, long since before the self-service), but it would make sense to (re-)expose that functionality/flexibility again in an export mode:
Issue by vlerenc
Saturday Aug 05, 2017 at 07:07 GMT
Originally opened as https://git.removed/kubernetes-attic/gardener-ui/issues/28
Newly hired or joined colleagues or contributors from outside the group of colleagues who primarily work on a repo/subject/topic have a hard time contributing, especially when sitting in remote locations, but in order to sustainably grow, we need everybody to be happy and help our cause.
kubectl
to the downloaded kubeconfig.kubectl
to the downloaded kubeconfig and correct namespace.Ops and debugging, constrained by security considerations.
kubectl
pointing to the project namespace in the garden cluster for which the web console was opened (scope: project)kubectl
pointing to the shoot cluster control plane namespace in the seed cluster for which the web console was opened (scope: shoot cluster)kubectl
pointing to the kube-system namespace in the shoot cluster for which the web console was opened (scope: shoot cluster)chroot
ing into the host with full host access) nodeSelector
ed by node/host name or same node that runs a particular garden podchroot
ing into the host with full host access) nodeSelector
ed by node/host name or same node that runs a particular shoot cluster control plane pod (scope: shoot cluster)chroot
ing into the host with full host access) nodeSelector
ed by node/host name or same node that runs a particular shoot cluster pod (scope: shoot cluster)By default (for the self-service) we manage the cluster domain automatically. In this case, we do not ask for a hosted zone ID and also not for a domain name (though the latter may be shown as read-only/FYI). In this fully managed case (default), the hosted zone is ours and the domain is created via the following pattern, e.g. <shoot_name>.<project_name>.shoot.example.com
. The Gardener supports this and detects the case if no hosted zone ID is found in the shoot cluster resource and the target domain matches a pre-defined one (like above). That means we only lack the UI part now.
The previous DNS Settings (in the old UI, long since before the self-service) shall become something like the non-default expert mode that the user can choose in the cluster creation dialog. If he chooses the expert mode, he must supply a hosted zone ID (AWS) or zone name (GCP) and the domain name (like today, except that we should no longer give any proposal/default domain name) as well as a DNS secret that must include the Route53FullAccess policy for AWS and whatever is necessary for Google Cloud DNS (the user should be informed about that requirement, if possible).
Issue by kubernetes-jenkins
Wednesday Jul 19, 2017 at 18:44 GMT
Originally opened as https://git.removed/kubernetes-attic/gardener-ui/issues/12
Newly hired or joined colleagues or contributors from outside the group of colleagues who primarily work on a repo/subject/topic have a hard time contributing, especially when sitting in remote locations, but in order to sustainably grow, we need everybody to be happy and help our cause.
ℹ️ Migrated from Jira issue KUBE-148
Multiple users complained about a missing confirmation dialog and final confirmation button, i.e. some users do not want to get the cluster by pressing create, but they want to get an overview, what they have configured and ideally (technically even more important) also the IaaS resources that would be created (e.g. so that they can ensure proper quotas/limits and have a better feeling what happens under the hood in their IaaS account).
Should the current cluster creation dialog become a wizard again, we should at least list:
The UI doesn't have this information and even the Gardener can only extract the information indirectly by inspecting and counting the Terraform resources that are rendered and would be created.
See gardener/gardener#50 in which the required Gardener functionality was implemented.
We can either do nothing (basically only do #23, which we like to do anyways) and leave it to the user to find out that by scaling down all pools manually he can effectively hibernate a cluster or we can offer some convenience function in the dashboard that does that across all pools, clearly labeled "Hibernate". The reverse operation, "Wake-Up", is harder, but maybe the former pool sizes could be written as annotations into the shoot resource by the dashboard, in which case "Wake-Up" would know how to scale up again.
Companies may want to "brand" their supported infrastructures, e.g. internal OpenStack installations. Historically the Dashboard used SAP Gold for "SAP Cloud Platform" (now "OpenStack"), but we should change this. Also the other infrastructures use not the right logos/colors, so it's time for a cleanup.
Let's make the following bits configurable at Garden cluster resource level (not hard-coded):
If we have this, it should be possible to support also multiple AWSes (e.g. general and government cloud), multiple OpenStacks or whatnot. It will also be possible to "brand" them, e.g. "OpenStack" could become "OpenStack (SAP Cloud Platform on Converged Cloud Industry Edition)" or we could integrate "special" discriminators/qualifiers like "Office Network" into the configurable name.
Let's also change the following:
As an Administrator, I navigation from the "Shoots with issues" list to the details page of a shoot. If this shoot becomes healthy, it will be removed from the shoots with issues list and thus remove from the local vuex store. In this case, I will be left with a broken page as all shoot information i gone but I'm still on the details page.
We should join a dedicated room for this shoot while viewing it, so that it will not be removed from the store while viewing it. In addition, we should inform the user or navigate away in the unlikely event of an actual shoot deletion.
The Gardener allows to tweak the configurations of API server, controller manager, scheduler and kube-proxy as well as allowing privileged containers or not, but we haven't exposed that yet (unless we are fine with #34).
To be defined in more detail. We need to investigate first (with Rafael F.), whether we can offer some pre-selection or how to actually allow the configuration (outcome can also be to leave it at #34, but then we need some documentation and it will not be very convenient).
See Gardener.
By @petersutter: When upgrading the vuetify version to >= 1.0.0, add the attach property to the projectFilter v-menu in the MainNavigation so that the menu does not scroll with the main page.
See also related vuetify github issue:
vuetifyjs/vuetify#2981 (comment)
Our current IdP SAML-based authentication solution works only from the dashboard. There are limitations to expand that to technical users and programmatic access.
Note: Scripting solution is already available internally at https://github.wdf.sap.corp/kubernetes/garden-setup/tree/master/utils (by @RaphaelVogel).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.