Kube-slack is a monitoring service for Kubernetes. When a pod has failed, it will publish a message in Slack channel. Slack requires registration, but the Kubernetes team is open invitation to anyone to register here. Feel free to come and ask any and all questions. Once registered, browse the growing list of channels for various subjects of interest. For example, people new to Kubernetes may also want to join the #kubernetes-novice channel.

KubeCon + CloudNativeCon Europe 2021 – Virtual sponsored post by Lauri Apple, Staff Technical Program Manager; and Anna Jung, Open Source Engineer, VMware

As the “feature development” aspect of Kubernetes, the Enhancements process is arguably one of the most important engines driving the project’s continued evolution and growth. SIG Architecture maintains a subproject explicitly for the purpose of helping make sure that major development is documented, discoverable, and easy to track. Over the last few release cycles, the subproject has been working hard to make the process simpler and more automated. It’s part of our continuing efforts to make the contributor experience as excellent as possible for everyone. Please read on to learn about ways you can help us!

During the 1.21 release cycle, Kubernetes Special Interest Groups (SIGs) submitted 51 Kubernetes Enhancements Proposals (KEPs) for inclusion—an increase compared to the last few release cycles. KEPs are the primary artefacts of the Enhancements process. They’re design documents, inspired by the Python Enhancements Proposal and Rust RFCs, that enable SIGs to “propose, communicate, and coordinate” nontrivial changes, such as new features, deprecations, or policies with broad impact to the project. Helping to ship these KEPs in 1.21 were VMware’s Anna Jung, who served as Enhancements lead, and Release Team lead Nabarun Pal. Alongside SIG Release Co-Chair Stephen Augustus and SIG Release Program Manager Lauri Apple, Anna and Nabarun help drive the Enhancements subproject as process and tooling reviewers.

The Receipts process

Until recently, the Enhancements team has shepherded KEPs through the release cycle by relying on a process that requires several manual updates to spreadsheets and repetitive outreach to SIGs. This method required the team to clarify SIGs’ plans and expectations, and to look through GitHub issues in search of comments indicating recent development activity. This method has worked, but it has involved friction and toil.

Enter the receipts process, a Git-based artefact and tooling that supports automated Enhancement collection, validation, and tracking processes for Kubernetes releases. Through this method, SIGs will now opt in to a release using a specified file format—the receipt—that contains metadata about the KEP being enrolled. After a SIG opts into the release, all tracking will occur via Git commits rather than via issue comments, PR references, and other non-auditable mechanisms. Nabarun is one of the key developers of the receipts tooling, which is expected to debut for use in 1.22.

Not only is the receipts process simpler than the manual process, it reduces the risk of a KEP not being tracked due to miscommunication. We believe it will encourage SIGs to update KEPs proactively and plan for release cycles, which offers the benefit of encouraging sustainable planning. It also facilitates better KEP implementation history updates and overall transparency.

During the 1.21 release cycle, we began shifting toward the receipts process by introducing the opt-in process aspect. This required SIG leads and individual KEP contributors to proactively inform the Enhancements team of their plans by logging in the tracking spreadsheet all of the KEPs they planned for the 1.21 cycle, while gaining approval from both the sponsoring and participating SIG leads. Despite this change, we were able to achieve the highest number of KEPs submitted during a specific cycle in the project’s history—66 KEPs opted in by SIGs. The 15 KEPs that won’t make it this time around faced issues unrelated to the Enhancements process. The number of enhancements tracked for the release highlights good communication around the process change.

Requiring the Production Readiness Review

Introduced in 2020, the Production Readiness Review (PRR) is an approval process for KEPs aimed at ensuring that features for Kubernetes can be safely operated in production environments. During the 1.21 release cycle, PRRs became a requirement for KEPs.

Streamlining the entire Enhancements process

During the 1.21 release cycle, the Enhancements subproject received feedback that the KEPs process was getting too complex. In addition to diagramming the current process, subproject members discussed how to resolve some notorious pain points—suggesting a glossary to clarify ambiguous terminology and establishing a lighter review process for enhancements that are not release-impacting. This work is still in the early stages and will continue in 1.22.

Get involved!

Over the course of the past year, the Enhancements subproject has doubled in membership and increased engagement in its efforts. The group maintains a GitHub project board with items available for contributors to work on, and meets every two weeks to discuss process improvements. We also have a Slack channel (#enhancements), where we asynchronously plan and discuss activities. We’re always looking for new perspectives and feedback, so even if process change isn’t your specialty, you’re still likely to have valuable insights for us.

If you’re a new contributor to Kubernetes or simply looking for a new way to help the project, consider acting as an Enhancements liaison. This is an unofficial “pilot” role for contributors who would like to act as point person for a specific SIG during one release cycle—coordinating and communicating with the Enhancements Team and the Release Communications Team. Onboarding for this role will be provided so that you can get started right away. We hope to hear from some of you soon!

Profile

Anna Jung is an open source engineer at VMware, contributing to Kubernetes and other open source projects related to machine learning. Anna has been involved in the Kubernetes ecosystem for about two years as a member of the Release Team, the Enhancement subproject, and Sig Docs. She believes in the importance of giving back to the community and is passionate about increasing diversity in open source by making contributions easier for newcomers. When away from the keyboard, Anna is often at film festivals supporting independent filmmakers.

Lauri Apple is a staff technical program manager at VMware, where she drives the planning and execution of business-aligned upstream Kubernetes contributions and downstream Kubernetes core releases. Lauri also serves as program manager of Kubernetes’ SIG Release and is a co-owner of the Enhancements subproject. She lives in Berlin, Germany, and outside of work enjoys biking, vegan cooking, and listening to podcasts.

The Slack trigger is used to send a custom message to a desired Slack channel in a Slack workspace. The intended use is for notifications for a build pipeline, but can be used for any notification scenario.

Prerequisite¶

1. Deploy the eventbus in the namespace.

2. Make sure to have a Slack workspace setup you wish to send a message to.

3. Create a webhook event-source.

4. Set up port-forwarding to expose the http server. We will use port-forwarding here.

Kubernetes Slack Integration

Create a Slack App¶

We need to create a Slack App which will send messages to your Slack Workspace. We will add OAuth Permissions and add the OAuth token to the k8s cluster via a secret.

1. Create a Slack app by clicking Create New App at the Slack API Page. Name your app and choose your intended Slack Workspace

2. Navigate to your app, then to Features > OAuth & Permissions

3. Scroll down to Scopes and add the scopes channels:join, channels:read, groups:read and chat:write to the Bot Token Scopes

4. Scroll to the top of the OAuth & Permissions page and click Install App to Workspace and follow the install Wizard

5. You should land back on the OAuth & Permissions page. Copy your app's OAuth Access Token. This will allow the trigger to act on behalf of your newly created Slack app.

6. Encode your OAuth token in base64. This can done easily with the command line

7. Create a kubernetes secret file slack-secret.yaml with your OAuth token in the following format

8. Apply the kubernetes secret

Slack Trigger¶

We will set up a basic slack trigger and send a default message, and then a dynamic custom message.

1. Create a sensor with Slack trigger. We will discuss the trigger details in the following sections.

2. Send a http request to the event-source-pod to fire the Slack trigger.

   Note: The default slack-trigger will send the message 'hello world' to the #general channel. You may change the default message and channel in slack-trigger.yaml under triggers.slack.channel and triggers.slack.message.

3. Alternatively, you can dynamically determine the channel and message based on parameterization of your event. 2010 honda civic radio unlock code.

4. Great! But, how did the sensor use the event to customize the message and channel from the http request? We will see that in next section.

Parameterization¶

The slack trigger parameters have the following structure,

Kubernetes Slack Channel

The src is the source of event. It contains,

1. dependencyName: name of the event dependency to extract the event from.
2. dataKey: to extract a particular key-value from event's data.
3. contextKey: to extract a particular key-value from event' context.

The dest is the destination key within the result payload.

So, the above trigger paramters will generate a request payload as,

Note: If you define both the contextKey and dataKey within a paramter item, thenthe dataKey takes the precedence.

Kubernetes Sig

You can create any paramater structure you want. To get more info on how to generate complex event payloads, take a look at this library.

Kubernetes Slack

The complete specification of Slack trigger is available here.