All Posts By

cncf

CNCF Meetups Grow to Over 100,000 Members

By | Blog

CNCF Meetup groups cover topics around cloud-native computing and CNCF-hosted projects throughout the year. Through the passion of our community, and the help of the Cloud Native Ambassador (CNA) program, CNCF meetups across the globe have grown to more than 100,000 members.

Meetup Stats:

  • 105,647 total Meetup members
  • 2,019 total events to date
  • 186 groups
  • 47 countries

These meetups discuss CNCF related technologies like Kubernetes, Prometheus, or any of our current hosted projects. Topics range from container networking and application services to multi-cloud engineering, scalability, microservices, and much more.

CNCF supports the worldwide community of cloud native meetups and provides a number of resources for both existing and new groups looking to become an official meetup:

  • Meetup Best Practices provide guidance on starting a new meetup group based on the experience of existing ones. This includes everything from naming the group, attendee booking, scheduling, and finding a venue, sponsors and speakers.
  • Presentations are available from the CNCF community to share and reuse. There are a variety of topics available, including CNCF projects and presentations from industry events. Content is also available in Chinese and Japanese and members can request to have their own presentations added.
  • Speaker’s Bureau helps connect event organizers with speakers with a variety of expertise within the cloud native ecosystem. Speakers consist of CNCF meetup organizers, ambassadors, and prominent community members who are willing to speak at local events on certain topics they are proficient in. Event organizers are welcome to reach out to speakers to invite them to participate in your event.

CNCF is continually working to expand the cloud native community around the globe and looking for new meetup communities to join our network. Do you have a Meetup that might be a good fit? Learn more about applying.

With 186 groups in 47 countries, chances are there is a meetup near you. Find your local CNCF meetup.

Setting up Kubernetes Network Policies – A Detailed Guide

By | Blog

This guest post was written by Viswajith Venugopal, Member Of Technical Staff at StackRox and was originally posted on Stackrox.

The container orchestrator war is over, and Kubernetes has won. With companies large and small rapidly adopting the platform, security has emerged as an important concern — partly because of the learning curve inherent in understanding any new infrastructure, and partly because of recently announced vulnerabilities.

Kubernetes brings another security dynamic to the table — its defaults are geared towards making it easy for users to get up and running quickly, as well as being backward compatible with earlier releases of Kubernetes that lacked important security features. Consequently, many important Kubernetes configurations are not secure by default.

One important configuration that demands attention from a security perspective is the network policies feature. Network policies specify how groups of pods are allowed to communicate with each other and other network endpoints. You can think of them as the Kubernetes equivalent of a firewall.

On a side note, if you haven’t already done so, upgrade to the latest Kubernetes version because some of the most critical Kubernetes security issues have been addressed by recent Kubernetes updates.

How to Set Up Network Policies

We lay out here a step-by-step guide on how to set up network policies. The network policy spec is intricate, and it can be difficult to understand and use correctly. In this guide, we provide recommendations that significantly improve security. Users can easily apply these recommendations without needing to know the spec in detail.

A quick note: this guide focuses just on ingress network policies. When starting out, the biggest security gains come from applying ingress policies, so we recommend focusing on them first, and then adding egress policies. We will discuss egress policies in detail and provide recommendations in a subsequent post in this series.

Use a network plugin that supports network policies

First things first — use a network plugin that actually enforces network policies. Although Kubernetes always supports operations on the

NetworkPolicy
resource, simply creating the resource without a plugin that implements it will have no effect. Example plugins include Calico, Cilium, Kube-router, Romana and Weave Net.

“Isolate” your pods

Each network policy has a podSelector field, which selects a group of (zero or more) pods. When a pod is selected by a network policy, the network policy is said to apply to it.

Each network policy also specifies a list of allowed (ingress and egress) connections. When the network policy is created, all the pods that it applies to are allowed to make or accept the connections listed in it. In other words, a network policy is essentially a whitelist of allowed connections — a connection to or from a pod is allowed if it is permitted by at least one of the network policies that apply to the pod.

This tale, however, has an important twist: based on everything described so far, one would think that, if no network policies applied to a pod, then no connections to or from it would be permitted. The opposite, in fact, is true: if no network policies apply to a pod, then all network connections to and from it are permitted.

This behavior relates to the notion of “isolation”: pods are “isolated” if at least one network policy applies to them; if no policies apply, they are “non-isolated”. Network policies are not enforced on non-isolated pods. Although somewhat counter-intuitive, this behavior exists to make it easier to get a cluster up and running — a user who does not understand network policies can run their applications without having to create one.

Therefore, we recommend you start by applying a “default-deny-all” network policy. The effect of the following policy specification is to isolate all pods, which means that only connections explicitly whitelisted by other network policies will be allowed.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress

 

Without such a policy, it is very easy to run into a scenario where you delete a network policy, hoping to forbid the connections listed in it, but find that the result is that all connections to some pods suddenly become permitted — including ones that weren’t allowed before. Such a scenario occurs when the network policy you deleted was the only one that applied to a particular pod, which means that the deletion of the network policy caused the pod to become “non-isolated”.

Important Note: Since network policies are namespaced resources, you will need to create this policy for each namespace. You can do so by running kubectl -n create -f for each namespace.

Explicitly allow Internet access for pods that need it

With just the default-deny-all policy in place in every namespace, none of your pods will be able to talk to each other or receive traffic from the Internet. For most applications to work, you will need to allow some pods to receive traffic from outside sources. One convenient way to permit this setup would be to designate labels that are applied to those pods to which you want to allow access from the Internet and to create network policies that target those labels. For example, the following network policy allows traffic from all (including external) sources for pods having the `networking/allow-internet-access=true` label:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: internet-access
spec:
  podSelector:
    matchLabels:
      networking/allow-internet-access: "true"
  policyTypes:
  - Ingress
  ingress:
  - {}

 

For a more locked-down set of policies, you would ideally want to specify more fine-grained CIDR blocks as well as explicitly list out allowed ports and protocols. However, this policy provides a good starting point, with much greater security than the default.

Explicitly allow necessary pod-to-pod communication

After taking the above steps, you will also need to add network policies to allow pods to talk to each other. You have a few options for how to enable pod-to-pod communications, depending on your situation:

If You Don’t Know Which Pods Need To Talk To Each Other

In this case, a good starting point is to allow all pods in the same namespace to talk to each other and explicitly whitelist communication across namespaces, since that is usually more rare. You can use the following network policy to allow all pod-to-pod communication within a namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}

If You Know The Sources and Sinks for Communication

Often, communication between pods in an application follows a hub-and-spoke paradigm, with some central pods that many other pods need to talk to. In this case, you could consider creating a label which designates pods that are allowed to talk to the “hub.” For example, if your hub is a database pod and has an app=db label, you could allow access to the database only from pods that have a networking/allow-db-access=true label by applying the following policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-db-access
spec:
  podSelector:
    matchLabels:
      app: "db"
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          networking/allow-db-access: "true"

You could do something similar if you have a server that initiates connections to many other pods. If you want to explicitly whitelist the pods that the server is allowed to talk to, you can set the networking/allow-server-to-access=true label on them, and apply the following network policy (assuming your server has the label app=server) on them:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-server-to-access
spec:
  podSelector:
    matchLabels:
      networking/allow-server-to-access: "true"
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: "server"

If You Know Exactly Which Connections Should Be Allowed

Within the same namespace

Advanced users who know exactly which pod-to-pod connections should be allowed in their application can explicitly allow each such connection. If you want pods in deployment A to be able to talk to pods in deployment B, you can create the following policy to whitelist that connection, after replacing the labels with the labels of the specific deployment:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-server-to-access
spec:
  podSelector:
    matchLabels:
      deployment-b-pod-label-1-key: deployment-b-pod-label-1-value
      deployment-b-pod-label-2-key: deployment-b-pod-label-2-value
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          deployment-a-pod-label-1-key: deployment-a-pod-label-1-value
          deployment-a-pod-label-2-key: deployment-a-pod-label-2-value

Across Namespaces

To allow connections across namespaces, you will need to create a label for the source namespace (unfortunately, Kubernetes does not have any labels on namespaces by default) and add a namespaceSelector query next to the podSelector query. To label a namespace, you can simply run the command: kubectl label namespace networking/namespace=

With this namespace label in place, you can allow deployment A in namespace N1 to talk to deployment B in namespace N2 by applying the following network policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-n1-a-to-n2-b
  namespace: N2
spec:
  podSelector:
    matchLabels:
      deployment-b-pod-label-1-key: deployment-b-pod-label-1-value
      deployment-b-pod-label-2-key: deployment-b-pod-label-2-value
  policyTypes:
  - Ingress
  ingress:
  - from:
    -  namespaceSelector:
        matchLabels:
          networking/namespace: N1
       podSelector:
        matchLabels:
          deployment-a-pod-label-1-key: deployment-a-pod-label-1-value
          deployment-a-pod-label-2-key: deployment-a-pod-label-2-value

What About New Deployments?

Although explicitly whitelisting connections in this manner is great for security, this approach does affect usability. When you create new deployments, they will not be able to talk to anything by default until you apply a network policy. To mitigate this potentially frustrating user experience, you could create the following pair of network policies, which allow pods labelled networking/allow-all-connections=true to talk to all other pods in the same namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-from-new
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          networking/allow-all-connections: "true"
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-to-new
spec:
  podSelector:
    matchLabels:
      networking/allow-all-connections: "true"
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}

You can then apply the networking/allow-all-connections=true label to all newly created deployments, so that your application works until you create specially crafted network policies for them, at which point you can remove the label.

Summary

While these recommendations provide a good starting point, network policies are a lot more involved. If you’re interested in exploring them in more detail, be sure to check out the Kubernetes tutorial as well as some handy network policy recipes.

Meet the Ambassador: Diane Mueller

By | Blog

Diane Mueller, Director of Community Development  at Red Hat, sat down with Kaitlyn Barnard, Cloud Native Computing Foundation(CNCF), to talk about cloud native, trends in the industry, and being an Ambassador. Below is their interview. You can also view the video.

Kaitlyn: Hi Diane.

Diane: Hey there.

Kaitlyn: Thank you so much for joining me today.

Diane: It’s a pleasure to be here.

Kaitlyn: We’re gonna chat a little bit about some of your community involvement, some Cloud Native trends and a little bit about what you do outside of that.

Diane: Oh yes.

Kaitlyn: So can you start off by giving us a brief introduction about yourself?

Diane: All right, well, my name is Diane Mueller, I work at Red Hat. I’ve been there about five years now and I’m the Director of Community Development for starting out with Open Shift for all the cloud platform. I’m doing a lot of work extensively with the operator in the operator framework initiatives at Red Hat and in the Kubernetes community. I do a lot of the cross collaboration with upstream projects like Prometheus and ACD and all the wonderful projects under the CNCF and how they integrate with Open Shift and OKD, which is Open Shift’s Kubernetes distribution.

Kaitlyn: So you have some great insight into the Cloud Native ecosystem, what do you think is the next big thing?

Diane: The past six months I’ve been sort of deeply immersed in it, the operator framework, the operator SDK, the operator life cycle manage, everything operations, K-Native is really popular too. The server lists and STO stuff but now it’s really about who do we manage them and build them and I think operator solves a lot of that.

Kaitlyn: Yes, so kind of going off of that, what do you think is the biggest challenge right now to building, adopting and scaling Cloud Native applications?

Diane: Scaling stuff, patching stuff, we’ve seen a few security things and making sure that you have enough automation build into your infrastructure, into Kubernetes so that, that is seamless and totally automated. That’s the challenge. I think coordinating all of the release schedules and the project features and functions is something that takes a lot of concentrated brain power on the part of all the project leads and the companies that are working on it and the contributors. It’s a big coordination thing so yeah.

Kaitlyn: It really is. So you’re part of our ambassador program for CNCF.

Diane: Yes.

Kaitlyn: Can you talk a little bit about why you want to be part of the program and some of your work in the community?

Diane: I think every community needs to realize that it’s not just the people writing the code or the documentation. There’s a lot of other people, like with the coordination of the release cycles and release management and all of that stuff, plus all of the interactions with the communities and things and I think the ambassador’s program really recognizes people’s contributions on that level it gives CNCF a way to scale your machine I host two meet ups, one in Vancouver and Victoria with other people.

Diane: The meet ups give us another way to interact with the community to bring new people on board and to get that fire hose of information out.

Diane: It’s an awesome community. It’s pretty rocking awesome.

Kaitlyn: Awesome. Well, thank you so much for joining me today.

Diane: All right, take care and thanks.

Kaitlyn: Thanks.

CNCF and Alibaba Offer Free Cloud Native Course for Chinese Developers

By | Blog

In partnership with Alibaba, we are pleased to offer the first, free Chinese-language cloud native technology online course, available today.

The goal of the “CNCF x Alibaba Cloud Native Course” is to guide developers in their use of cloud native technologies, including Kubernetes, etcd, containerd, and Envoy. The course also touches on the factors driving the rise of cloud computing.

Since early 2019, Alibaba has been migrating its entire e-business platform to a cloud native based infrastructure, providing additional motivation for launching an online education program focusing on these technologies.

The content of the course is in Chinese and fully tailored for Chinese-speaking developers. It is completely free and does not have any requirements for registering.

Course Overview

This is the first in a series of Chinese-language courses from CNCF and Alibaba that will focus on the cloud native technology stack, with both technical deep dives and hands-on lab sessions. This course is geared toward helping and mentoring developers to use cloud native technologies in production environments and understand its use cases and benefits.

Course lecturers include Xiang Li (CNCF Technical Oversight Committee Member), Lei Zhang (CNCF Ambassador) and other highly experienced engineers from Alibaba and other members of the cloud native community in China.

Course Outline

The course is designed to be fully aligned with CNCF’s CKA/CKAD exams.

  • Container Fundamentals
    1. Container core concepts
    2. Understand value of container: Immutable Infrastructure
  • Kubernetes Fundamentals
    1. Core concepts
    2. Understand Pod and Pod design patterns
    3. Stateless application management
    4. App configuration
    5. Observability
    6. Services & networking
  • Container Advances
    1. Linux container deep dive
  • Kubernetes Advances
    1. Understand etcd
    2. Scheduling & resource management
    3. Storage & persistent volume
    4. Stateful application management
    5. Kubernetes API programing
    6. Service & networking Advanced
    7. Installation, Configuration & Validation
    8. Security
    9. CRI & Sandboxed Container Runtime

The course targets beginner and intermediate-level developers, including:

  • Software engineers and college students in the field of computer science and software engineering.
  • Application developers using or trying to use container and Kubernetes technology.
  • Software engineers and administrators with basic server-side knowledge and now exploring container technology world.
  • Managers and engineers trying to understand the fundamental of cloud native technology stack.

Interested in this course? Please visit the official website to get more detailed information. 


云原生计算基金会 (CNCF) 与阿里巴巴联手为中国开发人员提供免费云原生课程

 

我们很荣幸能与阿里巴巴合作,联手推出第一个免费云原生技术中文在线课程,这个课程已于今日上线。

CNCF x 阿里巴巴云原生课程”的目标在于指导开发人员使用云原生技术,包括 Kubernetes、etcd、containerd 和 Envoy。 此外,这门课程还将介绍促进云计算兴起的各方面因素。

自 2019 年初以来,阿里巴巴一直在努力将其整个电子商务平台迁移到基于云原生的基础架构,这为推出专注于这些技术的在线教育计划提供了额外动力。

本课程的内容将以中文讲授,为以中文为母语的开发人员量身定制。 它完全免费,不要求注册。

课程概述

这是 CNCF 与阿里巴巴联手推出的系列中文课程中的第一课,这些课程将专注于云原生技术堆栈,包括技术深度探索与动手实验课程。 本课程旨在帮助和指导开发人员在生产环境中使用云原生技术,并了解其用例和优势。

课程讲师包括李响(CNCF 技术监督委员会成员)、张磊(CNCF 大使)以及经验丰富的阿里巴巴工程师和中国云原生社区的其他成员。

课程大纲

本课程由 CNCF 与阿里巴巴共同设计,完全与 CNCF 的 CKA/CKAD考试要求相符。

  • 容器基础知识
    1. 容器核心概念
    2. 理解容器的价值:不可变基础设施
  • Kubernetes 基础知识
    1. 核心概念
    2. 理解 Pod 和 Pod 设计模式
    3. 无状态应用管理
    4. 应用配置
    5. 可观测性
    6. 服务与网络
  • 容器技术进阶
    1. 深入剖析 Linux 容器
  • Kubernetes 进阶
    1. 理解 etcd
    2. 调度与资源管理
    3. 存储和持久化数据卷
    4. 有状态应用管理
    5. Kubernetes API 编程
    6. Service 和网络进阶
    7. 安装、配置和验证
    8. 安全性
    9. CRI 和沙盒容器运行时

本课程面向初级和中级开发人员,包括:

  • 软件工程师和计算机科学与软件工程领域的大学生。
  • 使用或尝试使用容器和 Kubernetes 技术的应用开发人员。
  • 已掌握基本服务器端知识并且目前正在探索容器技术领域的软件工程师和管理员。
  • 尝试了解云原生技术堆栈基础知识的管理人员和工程师。

对本课程感兴趣? 请访问官方网站获取更多详细信息。

Meet the Ambassador: Ayrat Khayretdinov

By | Blog

Ayrat Khayretdinov, Cloud Architect at CloudOps sat down with Kaitlyn Barnard, Cloud Native Computing Foundation(CNCF), to talk about cloud native, trends in the industry, and being an Ambassador. Below is their interview. You can also view the video.

Kaitlyn: Good. So we’re gonna chat a little bit about the Ambassador program, some of your community work. So, you can start off just by introducing yourself.

Ayrat: All right. My name is Ayrat Khayretidnov. People in the community know and as Archie. I’m based in CanadaI work for a company called CloudOps. we help developers and SLE teams to own their destiny in the cloud. So our idea is use as much as possible cloud native applications and CNCF projects, so it’s a big part of our daily job.

Kaitlyn: Awesome. So what was the first cloud native project that you participated in?

Ayrat: Maybe four years ago, I was very actively working with another open source community called OpenStack. So my first engagement with Kubernetes project was with a sig OpenStack, where we help to integrate Kubernetes with OpenStack basically, to using their load balancers and storages from OpenStack. That’s how it’s actually started.

Ayrat: And then I’ve noticed that I’m probably the only representative from Canada. So I went back home and started to present at docker meetups, OpenStack meetups. And that actually lead me to start the Kubernetes meetup in Montreal. And it was very successful. So I decided to run those meetups across multiple cities. I pretty much know all the developers. I know all the companies involved, So it’s a lot of interest in the area with regards to Kubernetes.

Kaitlyn: Great, that’s awesome. So what do you see is the next big thing in the cloud native or container ecosystem?

Ayrat: Going forward in the future, I think server less with Kubernetes. We want a really simplified application developer’s workflow in Kubernetes. So projects like K-native is going to be definitely very, very interesting. And we see the whole industry, different companies adopting it and starting to contribute.

Ayrat: In CNCF we have a trail map, where we have different areas of interest. And we have something called a CACD part. Right now it’s like a missing. There’s no project there. So there is another interesting open source project started by Netflix called Spinnaker. I’m really hoping it’s going to be closer to Cloud Native Foundation, yeah.

Kaitlyn: That’ll be awesome. So we talked a little bit about some of your work with the Meetups, and the community and all of that. Why did you want to be part of the Ambassador program?

Ayrat: So pretty much in my case, it was like a call for me. I’ve been doing this, but I didn’t know that this Ambassador program exist. So, somebody contacted me and saying, “Hey, you’re doing great job. Why don’t you apply for Ambassador?” So yeah, why not? Pretty much the people who were Ambassadors are all my friends, So I’m so excited to be part of this team.

Kaitlyn: Yeah, I think that’s one of my favorite things about the Ambassador program, is there’s so many individuals in the community doing this work already. I think it’s great to bring them together and recognize that.

Ayrat: Absolutely. And we have not only Meetup organized, we have people who really made a lot of investment in the community itself. So it’s both sides of the wall. We’re helping each other and supporting. So it’s great.

Kaitlyn: Definitely. We’ve talked a lot about work. Tell us a fun fact about yourself.

Ayrat: One fact is that I’m wearing the Kubernetes hoodie or Ambassador hoodie pretty much everywhere. Recently I was taking flight. The guys in the security border, they’re like, “Are you using Kubernetes?” I was like “Wow, how you guys know?” Guy was like, “We heard about the Meetup” and everything. So, just seeing how many people are familiar with Kubernetes, it’s just fantastic.

Kaitlyn: Very cool. Well thank you so much for joining me today.

Ayrat: Absolutely. Thank you very much.

 

How CNCF Is Tackling Diversity in Open Source—and at KubeCon

By | Blog

With KubeCon + CloudNativeCon + OSS China 2019 Diversity scholarship applications due next week –April 15 at 11:59pm PT — we’re proud to provide this update on CNCF’s efforts to improve diversity in open source.

According to GitHub, the gender imbalance in open source is overwhelming—with only 3% of contributors identifying as female and 1% as non-binary. To help address this massive gap, CNCF has been working to improve gender parity and inclusivity throughout the community.

“Well sure we all know we need more diversity, but the problem is that the majority isn’t showing up and helping the minorities! We need the community to collectively come together and make this a priority by providing opportunities for the minority to be present and heard, both at events and within our companies.” – Kris Nova, Senior Developer Advocate, VMware

Since 2016, CNCF has offered more than 485 diversity scholarships to traditionally underrepresented and/or marginalized groups in the technology and/or open source communitiesincluding, but not limited to persons identifying as LGBTQ, women, persons of color, and/or persons with disabilities—to attend KubeCon + CloudNativeCon events.

For the Seattle event in 2018 alone, CNCF and the following sponsors invested a total of $300,000 to help fund 147 diversity scholarships: MongoDB, Twistlock, Two Sigma, Aspen Mesh, and VMware.

To read more about the experiences of previous scholarship recipients, read their blog posts here. CNCF also funded the beacon project, a code of conduct reporting and management system.

CNCF has also partnered with The Chasing Grace Project, a documentary series about women in tech, to help highlight the lack of diversity within open source. “It’s important to show how men’s and women’s day-to-day experiences are quite different,” Cloer says. “Having a voice in communities like CNCF and getting access to conferences like KubeCon also have a big impact for women.”

To that end, more than 40% of keynote speakers at KubeCon + CloudNativeCon North America 2018 in Seattle were female, a jump from 29% female speakers at KubeCon + CloudNativeCon Europe 2017. In addition, the co-chairs for KubeCon + CloudNativeCon CHina 2018  in Shanghai, as well as for the conference in Seattle, are both women (Janet Kuo & Liz Rice). It’s part of an effort that CNCF hopes will encourage and increase the participation of a diverse community for future events.

In addition, the Foundation is committed to making KubeCon + CloudNativeCon an inclusive event through the following initiatives:

  • Free child care and nursing rooms;
  • All-gender restrooms;
  • Communication stickers to support social interaction for people with a variety of disabilities and communication needs;
  • EmpowHER Reception, a fun evening event for attendees to network with other women in the tech industry and discuss ways to increase inclusivity in our fast-growing ecosystem;
  • Diversity Luncheon (a recording from the May event can be found here) is a lunch and panel for the open source community and diversity champions to connect around ways to promote inclusivity;
  • Support of the Inclusive Speaker Orientation course, created in collaboration with the National Center for Women & Information Technology; and
  • Strict policy around no all-male panels or keynote lineups.

Anyone interested in applying for the CNCF diversity scholarship to attend KubeCon + CloudNativeCon + OSS China 2019 in Shanghai June 24-26, can submit an application hereapplications are due April 15th at 11:59pm PT.

Yoav Landman, CTO and Co-Founder of JFrog discuss Why GoCenter is Important to Developers

By | Blog

Yoav Landman is the CTO and co-founder of JFrog.  sat down with Cloud Native Computing Foundation(CNCF), to talk about GoCenter.

Yoav Landman: GoCenter is a public, free repository for Go open source modules. Basically, Go is going through some transition period by introduction of Go modules, which is a standard for managing packaged artifacts for Go, so basically immutable versions for Go that are reusable. Today the community is lacking metadata about Go modules. What we did at JFrog is, we took those popular open source projects and we created those metadata descriptors and packaged those versions of popular Go modules and offered that in a public repository that anyone can use.

CNCF: Why is this important for developers?

Yoav Landman: I you want to have trust in your build pipeline, then you have to have trust coming from the very beginning, from basically the source that you use to build your software. So, when relying on pure source code with Go or vendoring in your dependencies, you do not guarantee that your Go packages are going to be immutable, meaning that if somebody overwrites a tag or completely wipes out the project, that means that you and I can look at different times and get totally different sources for the same Go module.

And then there’s the question of efficiency. So, if you are doing git checkout or you are doing git clone, essentially, whenever you’re building, that’s not what GitHub, for example, was made for, so you are being inconsiderate and putting a lot of effort with concurrent requests doing your builds against the source repositories. Instead, you can have those package pre-made Go modules offered for you in a reusable fashion, and everyone pointing at the same version, same checksum, of the same Go module, so that’s why.

CNCF: How does JFrog use Go?

Yoav Landman: We are using Go a lot internally. We are using Go to build JFrog Xray, which is a scanning tool. Our open source JFrog CLI is written in Go. Many internal microservices that are actually running inside Artifactory, that is itself written in Java, are Go-based. And we felt this pain ourselves. The fact that our developers, a lot of time, vendored in dependencies or just relied on a certain snapshot in time of the master, no common base and no common dependency manager for Go modules. It was a big pain for us in managing trust and being able to offer reproducible builds across different products and across different teams, so we were very happy to see Go modules coming.

We introduced support for it first in Artifactory, and then we saw that we solved the technical problem of being able to serve Go modules in Artifactory, but we were lacking the ecosystem to support that because all the popular libraries that we know are not modularized yet. So we decided to pick up this task and share it with others.

Everything around the cloud is happening with Go. Kubernetes is written in Go. It’s called the language of the cloud.

Being here at KubeCon NA in Seattle has been great. We get to see so many different customers and to hear from existing customers and new customers about how they’re adopting Kubernetes. We are seeing a lot of our big financial services customers that are going into Kubernetes for production, so that’s usually a good sign that something is catching up very strongly as a standard in the industry.

Watch the video to learn more about howJFrog is using Go.

 

Cloud Native Computing Foundation Announces Fluentd Graduation

By | Announcement

Open source logging tool has been adopted by over 5,000 community users

SAN FRANCISCO, Calif. – April 11, 2019 – The Cloud Native Computing Foundation® (CNCF®), which sustains open source technologies like Kubernetes® and Prometheus™, today announced that Fluentd is its sixth project to graduate, following Kubernetes, Prometheus, Envoy, CoreDNS and containerd. To move from the maturity level of incubation to graduation, projects must demonstrate thriving adoption, a documented, structured governance process, and a strong commitment to community sustainability and inclusivity.

“In the two and a half years since Fluentd became a part of CNCF, we’ve seen it grow beyond a project to a full ecosystem of integrations and third party components,” said Chris Aniszczyk, CTO/COO of the Cloud Native Computing Foundation. “With an active community of contributors and users, the CNCF TOC felt Fluentd was ready for graduation and we look forward to cultivating their community.”

Fluentd was created in 2011 by Sadayuki “Sada” Furuhashi, co-founder of Treasure Data, Inc., as an open source data collector for building a Unified Logging Layer, which unifies the data collection and consumption for a better use and understanding of data. In November 2016, Fluentd was accepted as CNCF’s sixth hosted project after Kubernetes, Prometheus and OpenTracing.

Fluentd solves logging problems at scale, not just for standalone applications, but it streamlines components of distributed architectures, making it an integral tool for any cloud native organization” said Masahiro Nakagawa, Principal Engineer at Arm®Treasure Data and core Fluentd Maintainer. “We’re thrilled to have had the opportunity to collaborate with the CNCF community and to grow our user base, and are honored to graduate.”

With more than 900 plugins connecting to its many data sources and data outputs; including Docker, Google Cloud, Kubernetes, etc., Fluentd was the 2016 Bossie Awards winner for the best open source datacenter and cloud software. More than 5,000 data-driven community users rely on Fluentd to differentiate their products and services through a better use and understanding of their log data, including Atlassian, Amazon Web Services, Backplane, Change.org, CyberAgent, DeNa, Drecom, GREE, GungHo, LINE Corp, Nintendo, Microsoft, Slideshare and many others.

“Fluentd has earned its place as the industry standard for log collection and shipping, and I am excited to see it as a graduated CNCF project,” said Gabe Monroy, Lead Program Manager for Containers, Microsoft Azure. “At Microsoft, we are proud to use Fluentd to power our cloud native logging subsystems and we look forward to working with the growing the open source community around Fluentd.”

Fluentd now has 4 active maintainers, over 160 contributors and more than 4,400 commits. It also has 189 official releases, more than 48 Million Docker Hub pulls, 941 plugins available made by the community and over 7500 Github Stars.

“As one of the longest standing incubating projects within CNCF, Fluentd has demonstrated impressive growth, adoption, and numerous integrations within the broader community,” said Brian Grant, Principal Software Engineer at Google and CNCF TOC representative. “We have no doubt that Fluentd is ready to move to this next stage, and are excited to see what the project continues to accomplish.”

To officially graduate from incubating status, the project also adopted the CNCF Code of Conduct, earned a Core Infrastructure Initiative Best Practices Badge. Completed in August 2017, the CII badge shows an ongoing commitment to code quality and security best practices.  

Fluentd Background

Fluentd collects events from various data sources and writes them to files, RDBMS, NoSQL, IaaS, SaaS, Hadoop and so on. Fluentd helps you unify your logging infrastructure. All components are available under the Apache 2 License, and are overseen by a self-selected team of active contributors to the project. For downloads, documentation, and how to get involved, visit https://github.com/fluent/fluentd, https://www.fluentd.org/ and https://twitter.com/fluentd.

The Linux Foundation is developing an elearning course titled Cloud Native Logging with Fluentd, which will be available in May 2019. This self-paced, hands-on course is designed to introduce individuals with a technical background to the Fluentd log forwarding and aggregation tool for use in Cloud Native Logging and provide them with the skills necessary to deploy Fluentd in a wide range of production settings.

Additional Resources

About Cloud Native Computing Foundation

Cloud native computing uses an open source software stack to deploy applications as microservices, packaging each part into its own container, and dynamically orchestrating those containers to optimize resource utilization. The Cloud Native Computing Foundation (CNCF) hosts critical components of cloud native software stacks, including Kubernetes and Prometheus. CNCF serves as the neutral home for collaboration and brings together the industry’s top developers, end users and vendors – including the world’s largest public cloud and enterprise software companies as well as dozens of innovative startups. CNCF is part of The Linux Foundation, a nonprofit organization. For more information about CNCF, please visit www.cncf.io.

###

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

Media Contact

Natasha Woods

The Linux Foundation

nwoods@linuxfoundation.org