would be nice to target this feature for the next release
HTTP Add-On
Update
Questions from Hieu
Attendees (add yourself)
Aaron Schlesinger (Microsoft)
Ahmed ElSayed (Microsoft)
Ajanth Kumarakuruparan (WSO2)
Jorge Turrado (Docplanner)
Hieu (Microsoft)
Jatin Sanghvi (Microsoft)
Shivam Rohilla (Microsoft)
Terry Humphries (HTTP Services)
Tom Kerkhove (Codit)
Notes
Azure Blob Storage Scaler & list blobs recursively
Discussed and issue updated
Reuse connection for some scalers, potential perf improvement
v2.5 is being targetted by Ahmed, issue updated
HTTP Add-on
Multi-tenant scaler allowing end-users to have less infrastructure containers running in the cluster and will be faster for scaling / CRUD HTTP ScaledObject
Almost finished and being reviewed by Yaron
Targetting v0.2
Dedicated scaler based on HTTP ScaledObject will be part of v0.3
Thinking being we can continue to parallelize Docker Hub for the next 2 or 3 releases and then omit Docker Hub for latest releases. Potentially updating the announcement to say we will do until something like Aug 31
Just to be clear, Microsoft is not abusing their position at them moment but we just want to have this improved to align with other project's their governance
Integrating with existing resources and/or automatically creating new resources?
Aaron his plan is to build a layer on top of it, that could include the pieces that we move out
Ryan mentions that options would be nice so that the full experience makes it easier for you to learn, but majority of it will go through self-managed services, etc
Operator can also create deployments for you, but maybe we should leave that out?
We will move this out for now and is maybe more part of a CLI on top of this
Aaron will write a more thorough scope which focusses on where the traffic starts and where it ends
Aaron will add some use-cases explaining the scenario and how you can apply HTTP autoscaling on those, how it works and what the impact is.
Ahmed was curious about our next release since he wanted to get a few things in
He need a week, which is fine, so we'll discuss the release next time
Jeff had a few customers with asks for Cosmos DB
The PG will check if they can build a Cosmos DB scaler
Feb 16th Meeting
Proposed Agenda
Alibaba Reference Case (Tom)
Finalizing the blog post and checking with CNCF to publish it is up next
CNCF (Tom)
Started working on annual review
Incubation proposal is coming after that
Would it be useful if we would document all our integrations? (Tom)
we have a lot of improvements, fixes and new scalers, I think that we are good to go with a new release, once KEDA docs are up to date and the e2e tests are stabilized (Z)
KEDA 2.0 support in Azure Function CLI (get started)
EKS, Calico, and CNI - and how we can support that
HTTP Add-on
CNCF Incubation
Things to note
For ARM support we'd need an ARM machine to build, wondering if Google Cloud could provide with CNCF credits? Tom may check into this
Astronomer has a customer running in EKS, but they have replaced the EKS CNI and added Calico. Calico is handling all the traffic, but the control plane using CNI.
Pods that need to talk to control plane need to run on host network
Scaling events (calling Postgres for events), which needs access to the database via the network policies.
Should support multiple ingresses, Prometheus metrics can give us universality in some cases.
Design document is updated in the issue.
SMI: we could support if needed, it is been taken in the account in the proposal. So far nothing is tightly coupled with KEDA, scaler could be swapped by SMI, the same applies to Interceptor.
Tom will prepare a repo for HTTP add on
The scaler will be external one first
IBM e2e tests are in the progress, no issues
Pause scaling option
will use annotation/label to on ScaledObject/ScaledJob. KEDA will skip scaling for the target Deployment when the label is present (HPA will be probably removed), there will be option to specify the number of replicas on the target Deployment during this phase.
Nov 10th Meeting
Proposed Agenda
KEDA 2.0
Roadmap Review
Attendees
Ahmed
Jeff
Liam
Richard
Bimsara
Shubham
Zbynek
Notes
Congrats on the KEDA 2.0 Release 🎉
Reviewed roadmap, bubbled a few items up to the top of the list we'd consider for 2.1
@Tom to work on document and help to share plan with Slack / maintainers
Rename master to main, and merge v2 to main (and make a v1 branch). @Zbynek can help do this
Rename keda-docs to main
Moving standup on Nov 10 (tuesdays) at 16:00 UTC which is an hour earlier for folks who have daylight savings.
Aaron spent some time using KEDA, and wanting to enable HTTP scaling workloads
Discussed a design to set a minimum threshold, specifically for Kafka, but felt it was a useful pattern to build in a way other scalers could mirror this functionality
Might be good if we define a longer-term roadmap for KEDA
It should be flexible so that we can easily pivot
Requested by community
Attendees
Jeff Hollan (Microsoft)
Tsuyoshi (Microsoft)
Anirudh Garg (Microsoft)
Zbynek Roubalik (Red Hat)
Travis Bickford (Shutterstock)
Ritika Sharma (NEC)
Shubham Kuchhal (NEC)
Notes
KEDA 2.0 beta going well, a few minor things to do before KEDA beta 2, Tsuyoshi working on some push stuff with scaled jobs (working to repro and fix) and some minor stuff in helm chart
Tom was able to do the Azure podcast about KEDA
Alibaba cloud was looking to do a blog post around how they are integrating with KEDA, and hopefully get logo on website
Travis has a PR for the helm chart that has the API CRD changes - though a bug in helm 3.3 with linting, and blocked on that for now.
Wanting to revert to older version of helm (< 3.3) for now so we can get it out there
Preference is whatever is easiest / most convenient
High availability
Current state is that we DO have readiness and liveness probes, so Kubernetes should detect that it is down if it locked up
The bottleneck currently is the metrics server. We can deploy multiple operators per namespace to partition in that regard, but are restricted to only have a single metrics server per cluster.
Relying on a library for K8s that doesn't allow us to deploy multiple metrics servers
If we did this it would require significant changes in the library
Other potential ineffeciency is that we open and close connection each polling interval. Could do some better pooling / connection re-use to reduce the amount of outbound connections we are making
Best practice may be to do the multiple namespaces to partition it a bit
Should create roadmap
EVERYONE should take a bit of time to review some slack / issue stuff that's popped up around v2
Jeff to add travis to have permission for GH actions on repos
Jeff and Tom to start building out a roadmap
Tom to help push out the KEDA 2.0 RC
Sep 17th Meeting
Proposed Agenda
KEDA 2.0 release - no major issues
Support for Helm 2.x - Travis has a solution for this, will follow up with him.
New Logo is in mockup stage (Tom)
Created an issue for CNCF incubation stage but a bit of work required for that (Tom)
Have to do some process level stuff
Pod Identity support in Azure Event Hubs - (Anirudh) to see if he can help get that implemented
Ask for Pod Identity support for Log Analytics - the person who implemented the Scaler for this will do it.
Since the v2 Beta is out - we need to decide how long should be wait before moving out of Beta - Tentatively early October if we dont hear any significant issues
Usage
Issues - If we dont hear anything significant her
Open Items
Question on how we construct the Scalers from the Golang code (Zbynek)
Better connection management for the event sources
Docker Hub's new policy limiting image retention & Announcement for GitHub Container Registry (Tom - #995)
Docker Hub is applying throttling on pulls (user-level) and automatically removing image tags that are no longer used (6m)
GitHub Container Registry is announced which stores all images in our org
Do we move or not? What is the benefit?
I believe this will give us more metrics and centralizes everything in one place, but not a must
Personally, I would move the CIs to GH CR and explore what it looks like. After that, evaluate if we should move our official images with a migration period
Hackmd- Zbynek mentioned that sometimes it lags for him as well (it's doing it for me right now). We're cool with google docs
Just need to clean up formatting on the FromEnv and LGTM
I think the best course of action is take the Travis fix. Pending closure on when /if 2.x charts get published and how the repo is structured but that approach for Helm 2 support seems good.
On the docker registry one Jeff will email CNCF to see what other projects are doing.
Group action item to mark items with Hacktoberfest / Good first issu / help wanted.
Provide some useful description in the issues with hacktoberfest so people know where to start. So we need to revie w all issues and add clear action items / what's expected.
Jeff will poke in jest the person who needed a few weeks before tweaking the SVG. In the meantime Tomasz mentioned he can give a shot
Jeff will ad a password this week
Event Hubs
v2, just need to merge PRs and the Helm chart and migration guide for scaled jobs. Also update the migration guide with the table of metadata name changes from Ahmed
Would love to bring KEDA Dashboard back to life and make it a scaling dashboard which could optionally even show cluster autoscaler and other non-KEDA things
Would love to bring KEDA Dashboard back to life and make it a scaling dashboard which could optionally even show cluster autoscaler and other non-KEDA things
Tom will start working on the blog post next week (WIP)
We should try to get the samples up-to-date based on the alpha version and assign an owner or archive them
Number of replicas remains the same after deleting ScaledObject
People agree that it should scale back to the original number
However, Kubernetes & HPA without KEDA use the same approach
Tom will update the issue to keep current approach and give option to scale back to the original instance count
Maintain last known state if prometheus is unavailable
Prometheus metric adapter will maintain the same instance count, while KEDA will scale back to 0 if it doesnt' have the count
HPAs receiving errors from metric servers stop taking any action; this seems liek a safe aproach for us. Otherwise we can create autoscaling loops flooding whole cluster.
This is how it works today so we are good to go
We shouldn't do 1 -> 0 nor 0 -> 1 scaling if we cannot fetch metrics
Would be nice for 2.0, otherwise afterwards
Migrate to the new Kubebuilder based Operator SDK framework
We are using Operator SDK which is being merged with Kubebuilder, we should check if we can migrate
Has no functionality changes but just reshuffling of the code
Will be done for 2.0 stable release
Any volunteer to implement Script to do the migration from v1 to v2?
Travis will look at this
Aiming for full release
Standup authentication changes with Zoom
We need to migrate before Sept 21st
We'll use password for meetings
Cluster Autoscale
A few folks at Amazon are managing EKS and looking at KEDA for event-driven autoscaling
It won't be easy for cluster autoscaler as they don't provide APIs