niggl
/
kubecon24
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Day 3 typos

This commit is contained in:
Nicolai Ort 2024-03-26 15:09:33 +01:00
parent 7b1203c7a3
commit daf83861af
Signed by: niggl
GPG Key ID: 13AFA55AF62F269F
7 changed files with 85 additions and 74 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
.vscode/ltex.dictionary.en-US.txt vendored
View File

@ -82,3 +82,14 @@ traefik
Vercel
Isovalent
CNIs
Ivanti
envs
CoreDNS
Istio
buildpacks
Buildpack
SBOM
Tekton
KPack
Multiarch
Tanzu

24
content/day3/01_stop_leaing_dns.md
View File

@ -11,8 +11,8 @@ A talk by Google and Ivanti.
## Background
* RBAC is ther to limit information access and control
* RBAC can be used to avoid interfearance in shared envs
* RBAC is there to limit information access and control
* RBAC can be used to avoid interference in shared envs
* DNS is not really applicable when it comes to RBAC
### DNS in Kubernetes
@ -26,11 +26,11 @@ A talk by Google and Ivanti.
* Specially for smaller, high growth companies with infinite VC money
* Just give everyone their own cluster -> Problem solved
* Smaller (<1000) typicly use many small clusters
* Smaller (<1000) typically use many small clusters
### Shared Clusters
* Becomes imporetant when cost is a question and engineers don't have any platform knowledge
* Becomes important when cost is a question and engineers don't have any platform knowledge
* A dedicated kube team can optimize both hardware and deliver updates fast -> Increased productivity by utilizing specialists
* Problem: Noisy neighbors by leaky DNS
@ -45,14 +45,14 @@ A talk by Google and Ivanti.
### Leak mechanics
* Leaks are based on the `<service>.<nemspace>.<svc>.cluster.local` pattern
* You can also just reverse looku the entire service CIDR
* You can also just reverse lookup the entire service CIDR
* SRV records get created for each service including the service ports
## Fix the leak
### CoreDNS Firewall Plugin
* External plugin provided by the coredns team
* External plugin provided by the CoreDNS team
* Expression engine built-in with support for external policy engines
```mermaid
@ -67,19 +67,19 @@ flowchart LR
### Demo
* Firwall rule that only allows queries from the same namespace, kube-system or default
* Firewall rule that only allows queries from the same namespace, `kube-system` or `default`
* Every other cross-namespace request gets blocked
* Same SVC requests from before now return NXDOMAIN
* Same SVC requests from before now return `NXDOMAIN`
### Why is this a plugin and not default?
* Requires `pods verified` mode -> Puts the watch on pods and only returns a query result if the pod actually exists
* Puts a watch on all pods -> higher API load and coredns mem usage
* Puts a watch on all pods -> higher API load and CoreDNS memory usage
* Potential race conditions with initial lookups in larger clusters -> Alternative is to fail open (not really secure)
### Per tenant DNS
* Just run a cporedns instance for each tenant
* Use a mutating webhook to inject the right dns into each pod
* Just run a CoreDNS instance for each tenant
* Use a mutating webhook to inject the right DNS into each pod
* Pro: No more pods verified -> Aka no more constant watch
* Limitation: Platform services still need a central coredns
* Limitation: Platform services still need a central CoreDNS

40
content/day3/02_poduct_market_misfit
View File

@ -6,7 +6,7 @@ tags:
- dx
---
Mitch from aviatrix -a former software engineer who has now switched over to product managment.
Mitch from aviatrix -a former software engineer who has now switched over to product management.
## Opening Thesis
@ -14,19 +14,19 @@ Opening with the Atari 2600 E.T. game as very bad fit sample.
Thesis: Missing user empathy
* A very hard game aimed at children without the will to trail and error
* Other aspect: Some of the devalopers were pulled together from throughout the company -> No passion needed
* Other aspect: Some devalopers were pulled together from throughout the company -> No passion needed
### Another sample
* Idea: SCADA system with sensors that can be moved and the current location get's tracked via iPad.
* Result: Nobody used the iPad app - only the desktop webapp
* Problem: Sensor get's moved, location not updated, the measurements for the wrong location get reported until update
* Idea: SCADA system with sensors that can be moved, and the current location gets tracked via iPad.
* Result: Nobody used the iPad app - only the desktop Web-app
* Problem: Sensor gets moved, location not updated, the measurements for the wrong location get reported until update
* Source: Moving a sensor is a pretty involved process including high pressure aka no priority for iPad
* Empathy loss: Different working endvironments result in drastic work experience missmatch
* Empathy loss: Different working environments result in drastic work experience mismatch
## The source
* Idea: A software engineer writes software, that someone else has to use, not themselfes
* Idea: A software engineer writes software, that someone else has to use, not themselves
* Problem: Distance between user and dev is high and their perspectives differ heavily
## User empathy
@ -37,43 +37,43 @@ Thesis: Missing user empathy
## Stories from Istio
* Classic implementation: Sidecar Proxy
* Question: Can the same value be provided without a sidecar anywhers
* Question: Can the same value be provided without a sidecar anywhere
* Answer: Ambient mode -> split into l4 (proxy per node) and l7 (no sharing)
* Problem: After alpha release ther was a lack of exitement and feedback
* Problem: After alpha release there was a lack of excitement and feedback
* Result: Twitter Space event for feedback
### Ideas and feedback
* Idea: Sidecar is somewhat magical
* Feedback: Sidecars are a pain, but after integrating istio can be automated -> a problem gets solved, that already had a solution
* Feedback: Sidecars are a pain, but after integrating Istio can be automated -> a problem gets solved, that already had a solution
* Result: Highly overvalued the pain of sidecars
* Idea: Building istio into a platform sounds easy
* Idea: Building Istio into a platform sounds easy
* Feedback: The platform has to be changed for the new ambient mode -> High time investment while engineers are hard
* Result: The cost of platform changes was highly undervalued
* Idea: Sidecar compute sound expensive and networking itself pretty cheap
* Feedback: Many users have multi-region clusters -> Egress is whery expoenive
* Feedback: Many users have multi-region clusters -> Egress is very expensive
* Result: The relation between compute and egress cost was pretty much swapped
### What now?
* Ambient is the right solution for new users (fresh service mesehes)
* Existing users probaly won't upgrade
* Result: They will move forward with ambient mdoe
* Ambient is the right solution for new users (fresh service meshes)
* Existing users probably won't upgrade
* Result: They will move forward with ambient mode
## So what did we lern
## So what did we learn
### Basic questions
* Who are my intended users?
* What exites/worries them?
* What excites/worries them?
* What do they find easy/hard?
* What is ther biggest expense and what is inexpensive?
* What is the biggest expense and what is inexpensive?
### How to get better empathy
1. Shared perspective comes from proximity
1. Where they are
2. What they do -> Dogfood everything related to the platform (not just your own products)
2. What they do -> Dog food everything related to the platform (not just your own products)
2. Never stop listening
1. Even if you love your product
2. Especially if you love your product
@ -81,4 +81,4 @@ Thesis: Missing user empathy
### Takeaways
* Don't ship a puzzlebox (landscape) but a picture (this integrates with this and that)
* Don't ship a puzzle box (landscape) but a picture (this integrates with this and that)

38
content/day3/03_oss_business_value.md
View File

@ -6,25 +6,25 @@ tags:
- business
---
Bob a Program Manager at Google and Kubernetes steering commitee member with a bunch of contributor and maintainer experience.
Bob a Program Manager at Google and Kubernetes steering committee member with a bunch of contributor and maintainer experience.
The value should be rated even higher than the pure business value.
## Baseline
* A öarge chunk of CNCF contrinbutors and maintainers (95%) are company affiliated
* Most (50%) of the people contributed in professional an personal time )(and 30 only on work time)
* A large chunk of CNCF contributors and maintainers (95%) are company affiliated
* Most (50%) of the people contributed in professional personal time (and 30 only on work time)
* Explaining business value can be very complex
* Base question: What does this contribute to the business
## Data enablement
* Problem: Insufficient data (data collection is often an afterthought)
* Example used: Random CNCF slection
* 50% of issues are labed consistentöy
* Example used: Random CNCF selection
* 50% of issues are labeled consistently
* 17% of projects label PRs
* 58% of projects use milestones
* Labels provide: Context, Prioritization, Scope, State
* Milestones enable: Filtering outside of daterange
* Milestones enable: Filtering outside date range
* Sample queries:
* How many features have been in milestone XY?
* How many bugs have been fixed in this version?
@ -37,36 +37,36 @@ The value should be rated even higher than the pure business value.
* Thought of as overhead
* Project is too small
* Tools:
* Actions/Pipelines for autolabel, copy label sync labels
* Prow: The label system for kubernetes projects
* People with high project but low code knowlege can triage -> Make them feel recognized
* Actions/Pipelines for auto-label, copy label sync labels
* Prow: The label system for Kubernetes projects
* People with high project, but low code knowledge can triage -> Make them feel recognized
### Conclusions
* Consistent labels & milestones are critical for state analysis
* Data is the evidence needed in messaging for leadershiü
* Recruting triage-specific people and using automations streamlines the process
* Data is the evidence needed in messaging for leadership
* Recruiting triage-specific people and using automations streamlines the process
## Communication
### Personas
* OSS enthusiast: Knows the ecosystem and project with a knack for discussions and deep dives
* Maintainer;: A enthusiast that is tired, unter pressure and most of the time a one-man show that would prefer doint thechnical stuff
* CXO: Focus on ressources, health, ROI
* Product manager: Get the best project, user friendly
* Leads: Employees should meet KPIs, with slightly better techn understanding
* Maintainer;: A enthusiast that is tired, under pressure and most of the time a one-man show that would prefer doing technical stuff
* CXO: Focus on resources, health, ROI
* Product manager: Get the best project, user-friendly
* Leads: Employees should meet KPIs, with slightly better tech understanding
* End user: How can tools/features help me
### Growth limits
* Main questions:
* What is theis project/feature
* What is this project/feature
* Where is the roadmap
* What parts of the project are at risk?
* Problem: Wording
### Ways of surfcing information
### Ways of surfacing information
* Regular project reports/blog posts
* Roadmap on website
@ -76,8 +76,8 @@ The value should be rated even higher than the pure business value.
* What are we getting out? (How fast are bugs getting fixed)
* What is the criticality of the project?
* How much time is spent on maintainance?
* How much time is spent on maintenance?
## Conclusion
* Ther is significant unrealized valze in open source
* There is significant unrealized value in open source

34
content/day3/04_towards_great_docs.md
View File

@ -10,7 +10,7 @@ A talk about the backstage documentation audit and what makes a good documentati
## Opening
* 2012 the year of the mayan calendar and the mainstream success of memes
* 2012 the year of the Maya calendar and the mainstream success of memes
* The classic meme RTFM -> Classic manuals were pretty long
* 2024: Manuals have become documentation (hopefully with better contents)
@ -18,9 +18,9 @@ A talk about the backstage documentation audit and what makes a good documentati
### What is documentation
* Docs (the raw descriptions, qucikstart and how-to)
* Website (the first impression - what does this do, why would i need it)
* REAMDE (the github way of website + docs)
* Docs (the raw descriptions, quick-start and how-to)
* Website (the first impression - what does this do, why would I need it)
* README (the GitHub way of website + docs)
* CONTRIBUTING (Is this a one-man show)
* Issues
* Meta docs (how do we orchestrate things)
@ -30,10 +30,10 @@ A talk about the backstage documentation audit and what makes a good documentati
* Who needs this documentation?
* New users -> Optimize for minimum context
* Experienced users
* User roles (Admins, end users, ...) -> Seperate into different pages (Get started based in your role)
* User roles (Admins, end users, ...) -> Separate into different pages (Get started based in your role)
* What do we need to enable with this documentation?
* Prove value fast -> Why this project?
* Educate on fundemental aspects
* Educate on fundamental aspects
* Showcase features/uses cases
* Hands-on enablement -> Tutorials, guides, step-by-step
@ -43,24 +43,24 @@ A talk about the backstage documentation audit and what makes a good documentati
* Documented scheduled contributor meetings
* Getting started guides for new contributors
* Project governance
* Who is gonna own it?
* Who is going to own it?
* What will happen to my PR?
* Who maintains features?
### Website
* Single source for all pages (one repo that includes landing, docs, api and so on) -> Easier to contribute
* Single source for all pages (one repo that includes landing, docs, API and so on) -> Easier to contribute
* Usability (especially on mobile)
* Social proof and case studies -> Develop trust
* SEO (actually get found) and analytics (detect how documentation is used and where people leave)
* Plan website maintenance
### What is great documetnation
### What is great documentation
* Project docs helps users according to their needs -> Low question to answer latency
* Contributor docs enables contributions in a predictable manner -> Don't leave "when will this be reviewed/mered" questions open
* Website proves why anyone should invest time in this projects?
* All documetnation is connected and up to date
* Project docs help users according to their needs -> Low question to answer latency
* Contributor docs enables contributions predictably -> Don't leave "when will this be reviewed/merged" questions open
* Website proves why anyone should invest time in these projects?
* All documentation is connected and up to date
## General best practices
@ -72,11 +72,11 @@ A talk about the backstage documentation audit and what makes a good documentati
## Examples
* Opentelemetry: Split by role (dev, ops)
* OpenTelemetry: Split by role (dev, ops)
* Prometheus:
* New user conent in intro (concept) and getting started (practice)
* Hierarchie includes concepts, key features and guides/tutorials
* New user content in intro (concept) and getting started (practice)
* Hierarchies includes concepts, key features and guides/tutorials
## Q&A
* Every last wednesday in the month is a cncf echnical writers meetin (cncf slack -> techdocs)
* Every last Wednesday in the month is a CNCF technical writers meeting (CNCF slack -> `#techdocs`)

10
content/day3/05_buildpacks.md
View File

@ -9,11 +9,11 @@ tags:
A talk by Broadcom and Bloomberg (both related to buildpacks.io).
And a very full talk at that.
## Baselinbe
## Baseline
* CN Buildpack provides the spec for buildpacks with a couple of different implementations
* Pack CLI with builder (collection of buildopacks - for example ppaketo or heroku)
* Output images follow oci -> Just run them on docker/podman/kubernetes
* Pack CLI with builder (collection of Buildpacks - for example Paketo or Heroku)
* Output images follow OCI -> Just run them on docker/Podman/Kubernetes
* Built images are `production application images` (small attack surface, SBOM, non-root, reproducible)
## Scaling
@ -47,7 +47,7 @@ flowchart LR
* Goal: Just a simple docker full that auto-detects the right architecture
* Needed: Pack, Lifecycle, Buildpacks, Build images, builders, registry
* Current state: There is an RFC to handle image index creation with changes to buildpack creation
* Current state: There is an RFC to handle image index creation with changes to Buildpack creation
* New folder structure for binaries
* Update config files to include targets
* The user impact is minimal, because the builder abstracts everything away
@ -56,5 +56,5 @@ flowchart LR
* kpack is slsa.dev v3 compliant (party hard)
* 5 years of production
* scaling up to tanzu/heroku/gcp levels
* scaling up to Tanzu/Heroku/GCP levels
* Multiarch is being worked on

2
content/day3/_index.md
View File

@ -4,4 +4,4 @@ title: Day 3
weight: 3
---
Spent most of the early day with headache therefor talk notes only start at noon.
Spent most of the early day with headache therefore talk notes only start at noon.