Finding your path in Kubernetes and cloud native communities

Bart: Okay, first things first: Who are you? What's your role? And where do you work?

In this transcript, I would hyperlink the following:

• Solo.io (Lin's employer)

• CNCF Ambassador (potential reference to Lin's role)

The transcript doesn't provide enough context to definitively add more links, so I've kept the suggestions minimal and based on the known context.

Lin: My name is Lin Sun from Solo.io. I'm the head of open source and contribute primarily to open source. I wear a couple of different hats: I'm a CNCF TOC member, a CNCF ambassador, and a maintainer on the Istio project, serving on its technical oversight committee since the beginning. I'm also a maintainer on K-Gateway and KAgent, the new hot CNCF AI agent project. Additionally, I'm going to be KubeCon co-chair for Amsterdam, LA, and Barcelona. I'm very excited about that.

Bart: I'll have some follow-up questions about all that later on. First things first, Lin, how did you get into Kubernetes? How did that whole journey start?

Lin: That's a great question. I have a vague memory about starting to contribute to Kubernetes while working at IBM. I had a 19-year career at IBM before joining Solo.io. I was on the team responsible for shipping IBM Cloud Container Service. We were exploring OpenStack, Docker Swarm, and Apache Mesos when Kubernetes emerged. I still remember my boss, Jason McGee, who was the IBM Cloud CTO at the time, saying this was going to be the next big thing.

We started looking at Kubernetes and attended the first KubeCon when Kubernetes was donated to CNCF, which I believe was in 2016 in Seattle. Our leadership team flew over for the event. It was an exciting time. I was looking at the CNCF contributor card and was amazed to see my first contribution was in 2016 to Kubernetes. It wasn't just a simple typo fix, but a more complex configuration issue. I'm proud to have that record on my contributor card.

Bart: That is a lot to be proud of. You said 2016 feels like such a long time ago. As a reminder, this has been going on for quite a few years, and so much has happened during that period. I want to know how you stay up to date with the Kubernetes and cloud native ecosystem. How are you on top of all the things happening? You're in the CNCF TOC, involved in different projects like KAgent and Istio. How do you stay current with all the changes?

Lin: It is super hard. Honestly, there are a lot of moving parts in our community. I'm not super close to everything going on in the Kubernetes community, but I do try to read the release notes and check out what's exciting. I work on projects which build on top of Kubernetes. This allows me to focus on what's in Kubernetes that could be interesting or beneficial to the projects I participate in.

I mostly participate in projects related to connectivity, whether it's service mesh or gateways that control traffic into and out of the Kubernetes cluster. With the most recent work on KAgent, everybody is trying to stay relevant to AI. We want to keep pace with AI. We need to solve agent-to-agent connectivity problems, agent-to-MCP server connectivity, and agent-to-large language model connectivity.

As a community user, I love to play with different technologies. It would be boring to just talk about Istio, which I used to do. These days, when I get on stage—I recently gave a keynote at KCD DC—I talk about a wide range of projects like Kubernetes, Argo, Istio, Prometheus, and Kiali. This gives perspective, even if I'm not a contributor but a solid user of many key cloud native technologies.

Bart: And being involved in all these different projects, you must have come across so many different people. Who in the Kubernetes ecosystem or community helped you level up or get to the next level?

Lin: That's a really great question. I've been thinking about this hard. Certainly, there are many people who deserve shout-outs. For instance, there were times I was contributing to the community, working hard, and running for a lead position without being recognized. As everybody else experiences, there are many chances to do great work without recognition.

Some people have definitely lifted me up in the past. Emily Fox is a great example, whom I absolutely adore. She always makes time for others. Mala is amazing; I happened to sit at a table with her, and she helps and lifts me up, too. It's interesting how the community allies together.

What's most interesting is that as a female, I didn't ask for recognition. I didn't come in complaining about why I wasn't in a leadership position. People simply recognized my work. Another person I'd give a shout-out to is Chris Aniszczyk, who kindly reached out to me about KubeCon culture—an opportunity I didn't think I had a chance at. It's remarkable how at times when you don't think you have a chance, and you don't ask, people still recognize your work in the community.

Bart: Kubernetes, being part of this community that's so big with so many different people from different backgrounds, can mean many different things to different people. So, Lin, what does Kubernetes mean to you?

Lin: Kubernetes means providing the keys to easily access distributed systems. That's the core meaning for me. For instance, I know how to deploy things on my laptop, but that's not sufficient. When we talk about distributed systems, we're running everything in the cloud. What Kubernetes provides is the same interface: I'm interacting on my laptop with YAMLs declaratively, and I can take the same YAML and deploy it into my distributed system in the cloud. I think that's a powerful aspect of Kubernetes. The abstraction provided to me and many other users is truly remarkable.

Bart: You've already explained this a bit, but your path spans multiple archetypes—being on a CNCF TOC, being a co-chair in KubeCon, contributions dating back to 2016, community builder, speaking in all these different events. How do you move between these different roles?

Lin: That's a great question. I don't believe in multitasking. At a certain time, I'm 100% focused. When I'm traveling and speaking at events, I try to be most focused on those events. I won't participate in other activities, such as joining a weekly meeting while connecting with the local community.

If you look at the roles I'm serving, like the CNCF TOC member, it's a part-time role that demands a few hours per week. The maintainer role is also part-time. The community understands if you don't show up every single week because they aren't the ones paying you.

I participate in a few communities and don't necessarily appear every week, but I do show up when looking at a monthly or quarterly timeframe. I help people resolve issues, and they feel they can trust me to provide feedback about our project. I help connect them with other maintainers who can value the feedback and potentially resolve project issues.

One thing I've learned in tech is that you don't want to overwhelm yourself. I know my limits and always try to do my best when I focus on one thing.

Bart: For newcomers wanting to become contributors, they often struggle with finding the one thing they should focus on to get plugged into the community. Ideally, we don't want people just bouncing off open source projects. We want them to find something that works for them, have a positive experience, and know they can contribute meaningfully.

Looking at the contributor path, what is the most practical on-ramp for first meaningful contributions? Would you say it's more on the code side or the documentation side? It might depend on different factors. Could you share insights into these factors?

Lin: There's no one recipe that works for everybody. Ideally, it would be nice to have someone willing to fund your work, giving you more time to contribute to the project. But I understand not everyone has that luxury.

Many people I work with aim to become open source developers, full-time or part-time, and to achieve this, they need to show contributions to existing open source projects.

I recommend first thinking about what excites you and then finding one or two projects you would be passionate about. Choose something you would be proud to be part of and potentially speak about in public.

Next, look at your background and find where you would shine. Some people are great at:

• Finding bugs and submitting fixes (start with first-time labeled issues)

• Improving usability or documentation from a user's perspective

• Following project tutorials and identifying improvement areas

Another valuable path is being an advocate for the project. This doesn't mean direct code or documentation contributions, but rather:

• Writing blogs about the project

• Speaking at meetups or conferences

• Sharing project-related content

The key is to find a path you're most comfortable with. Additionally, it's important to promote your work - not in a sales-like way, but by sharing your contributions. Attend work group or community meetings, share what you've done, and ask how else you can help.

If you're doing speaking or blogging, post on social media and share with the project. Remember, recognition doesn't happen naturally; you must advocate for yourself.

Bart: Very good point. With a mentality of "offer, don't ask," think about what you can contribute. Take the time to consider this, and it'll be easier to decide which path to take. Moving on to the practitioner path, what mindset turns clusters into a reliable platform for connectivity?

Lin: That's a great question. In my experience, we've been relying on platform solutions. You could potentially solve problems in your microservices or agents, but that would likely bloat your services. Instead, you could delegate the work to the platform.

You might start by adopting a network policy for basic security. However, network policy typically identifies pods based on IP and labels, and it doesn't provide cryptographic identity or upgrade connections between pods to mutual TLS. That's where a service mesh comes in, providing security, observability, resilience, and traffic management.

For the longest time, we complicated Service Mesh with sidecars, and people understandably dislike them. When you add an application to the mesh, you not only need to restart your application initially but also restart it for every security patch and Envoy update. Additionally, the memory requirements for sidecars across microservices can be substantial.

I believe we've solved this problem with the sidecar-less mesh in Istio. I'm excited about Istio Ambient because it works so transparently. I haven't needed to check logs or metrics in a long time because it just works seamlessly.

I would definitely recommend delegating platform-level security for your microservices. Does that answer your question?

Bart: "I'm glad you touched on the part about sidecars, because in our podcast episodes, when we ask people about their biggest pain points in Kubernetes, people often mention sidecars and network policy management. Now, if we're focusing on the educator path: How do you make service mesh or gateway concepts click for different audiences? Everyone has a different background. Some people may be more familiar with these concepts, while others are less familiar, depending on their objectives. So how do you make those concepts resonate with different audiences?"

Lin: Marketing is very important in the world of tech. People care about two things: themselves and how others perceive them. When educating people on a particular topic, you have to consider how it relates to them and use a metaphor that resonates with their experience.

In the world of service mesh, here's a metaphor: Think about running a house. If you own a property where only immediate family members live, you secure the entrance with a lock. You control traffic into your property and trust your family members, so you don't need to check their identity.

However, if your property is large enough to operate like a boutique hotel with multiple rooms, you think differently. Not only do you secure the front door, but you also need to check every guest's identity. You provide government-issued ID verification, give them a key, and can reset or revoke that key when they leave.

This is where a service mesh becomes valuable. You want to validate everyone's identity, observe who occupies which space, and monitor if any guests attempt to access rooms they aren't authorized to enter.

The key is to provide value to your audience and not push solutions they don't need. By putting yourself in their shoes and understanding their perspective, you can effectively educate people.

Bart: That's a wonderful metaphor. I would love to see that in video form because it's a great way for people to relate to it if they don't have the technical background, but can imagine this idea of who's getting permission and access based on trust, familiarity, or the things they need to do in a given space.

With this in mind, imagine a house being welcoming. We've been talking about a diverse group of people from across the world. Everyone speaks different languages. For some people, English is their first language; for others, it's their third or fourth. We also have folks who communicate using sign language.

For people building communities, how do you keep contributor spaces welcoming and sustainable so that everyone feels they have an equal opportunity to participate?

Lin: That's a great question. I've been thinking a lot about it because I'm running some community meetings. One of the community meetings I run is Istio Gateway, and I used to run KAgent and Istio community meetings.

I think a key important factor is when you see a new face, it's important to ask them to introduce themselves for a minute so that they feel welcomed. It's like at conferences when people are chatting in a circle, and a new person comes by who may not know anybody but is curious about the conversation—perhaps they saw someone on stage and want to be part of it.

So you lean and open up space in the circle for that new person to join. I apply this to running community meetings, which are mostly virtual. When a new person comes in, you open up the circle and give them a chance to introduce themselves and tell others why they are part of the community and what their interests are.

This is tremendously beneficial for the new person and for everyone else in the circle, as they can understand the person's intention—are they a contributor, a user, or a potential community advocate?

Another technique I use is including a shout-out section in our community meetings, where anyone can recognize others. We also give a weekly spotlight to a community user—someone who submitted a merged PR, wrote a blog, spoke at a conference, contributed documentation, or even opened an issue identifying a problem. Having this spotlight can generate a very positive social effect for the project.

Bart: I love this message and want to share it with everyone. These experiences will keep people coming back. Yes, the technology is exciting and it's cool to work with open source projects. But when you have positive human experiences and receive recognition for your work, starting from the point that no contribution is too small and that all contributions will be celebrated—this is powerful. This is why I've been interacting with CNCF for the last five years as someone from a non-technical background. Because of things like this, I feel lucky to participate.

Now, our last question: When choosing a path, what is one question someone should ask to decide where to start? We've been talking about different ways to get involved, but it can still feel overwhelming. People might look at the CNCF landscape or Kubernetes documentation and feel intimidated. Those of us fortunate to know someone who helps us get involved—which was my case—are very grateful to those who made it easy. But for those without such guidance or resources, what questions should people ask to decide the best place to start and have the most rewarding experience possible?

Lin: That's a good question. I've personally gone through every single path. First, you want to think about what excites you. Second, look at what's available in the market. At the end of the day, it's hard to do meaningful work if you're not getting paid. When you get paid, you have more time, energy, and resources to do something impactful.

You want to consider both the market opportunity and what truly excites you. Find something that makes you want to wake up, be at your desk every day, and even speak at conferences. Focus on what genuinely excites you—that's most important. Ideally, find funding for your work because if you're putting in four hours while someone else is putting in 20, it will be challenging to compete.