Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2020 - Virtual, 4 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Birds of a Feather: Telecom User Group - Dan Kohn, CNCF & Taylor Carpenter, Vulk Coop

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Birds of a Feather: Telecom User Group - Dan Kohn, CNCF & Taylor Carpenter, Vulk Coop

CNCF hosts the Telecom User Group (TUG) for service providers and their vendors to discuss the adoption of cloud native technologies. The community is invited to join this birds-of-a-feather (BoF) session to discuss the status of various initiatives and white papers in this space as well as ideas, requirements and best practices to continue moving forward. Some topics to discuss include the TUG Whitepaper, Cloud Native Networking Principles, Cloud Native Network Functions (CNFs) conformance testing, gap analysis and demonstrating different approaches using the CNF Testbed.

https://sched.co/Zevr

A

Welcome to the session I'm taylor carpenter and I'm going to provide an introduction to cncs telcom initiatives.

A

We'll do a quick summary of each of the initiatives. Look at some of the guiding values, including cloud native principles, community collaboration go into some more details about each of the initiatives.

A

Talk about how you can get involved and then provide time for a q. A cncf would like to help telcos and those involved in telecommunication industry to navigate the cloud native and open source landscape and assist operators in obtaining the benefits touted by cloud native technologies.

A

It started three initiatives: the telcom user group, the cnf testbed and the cnf conformance to help reach these goals. With its end, users.

A

The telcom user group is a collaborative and open space, welcoming operators, vendors and telecom developers to come together to share ideas, ask questions, voice any needs and concerns, as well as work together to write up requirements, best practices and do gap analysis.

A

It meets regularly once a month on zoom calls and also has discussions on its mailing list.

A

The cnf testbed is an open source platform tool chain and framework that includes a set of examples, supporting review of emerging cloud native technology reproducing all of its test results and use cases, as well as building new prototypes and reference examples.

A

The cnf conformance initiative is an open source test, suite focused on validating cnf and platforms, adherence to cloud native principles, with the goal of helping operators to identify solutions and technologies which are observing cloud native capabilities and principles that are important to them.

A

It also enables cnf developers to demonstrate conformance to cloud-native best practices and provides a set of tools and feedback to help those same developers in improving the software they are developing.

A

Cncf provides a few telecom focused meetings, including a weekly developer meeting for the cnf conformance and testbed that meets on thursdays at 4, 14, 15 utc, as well as the telcom user group monthly meeting, which meets on the first monday at alternating times of 1500 and 1100 utc.

A

You can subscribe to the telco music group mailing list, as well as join cncs public slack channels for these initiatives and email, myself or dan khan directly.

A

We'd welcome your feedback on these initiatives as well as this introduction we'll provide the survey link at the end of the presentation as well a little bit about the cloud native guiding principles.

A

These cloud native principles are built on existing practices, processes and principles like those from devops service-based architecture and agile software development.

A

Cncf outlined some of these, such as using microservices immutable infrastructure and declarative apis in its definition, and how these can allow you to make high impact changes frequently and predictably, such as moving a security patch safely and confidently through production.

A

We have an extensive set of papers on the cloud native principles focused in networking and telecom with references. These allow us to answer questions like how are cloud native systems loosely coupled. How do you provision immutable infrastructure and how do you configure these cloud native systems once we've defined and identified? What we're talking about? With these cloud native principles, we can define what a cloud native network function is, which is a cloud native application implementing network functionality.

A

We expect it to consist of one or more microservice and to be developed following cloud native principles like immutable infrastructure, declarative configuration and apis. It should also have a repeatable deployment process.

A

A cloud native platform should also follow these type of principles and provide its services in a cloud-native way like using service discovery, a resource management and fault, tolerant capabilities.

A

It should have declarative configuration, and this should provide resiliency for the workloads, as well as the platform and underlying systems.

A

Another value for these initiatives that is shared is community collaboration, so we engage and contribute to communities like those from linux foundation, networking, including their opm, opnfv verification program or ovp, as well as onapp and cntt's community, including the work streams for the kubernetes architecture, like the reference architecture, reference implementation and their testing program, or reference certification, as well as the platform as service initiative, xg vela and many other cncf and kubernetes initiatives, groups and projects.

A

There's many efforts and initiatives collaborating together across requirements, implementation testing and certification and cnf testbed, cnf conformance and telcom user group are providing upstream value that can be used in many of these communities and projects.

A

We start with those guiding values: the cloud native principles, community collaboration.

A

We have output from all the initiatives and then the end users can take these and use them as needed, including directly with operators cnf developers, as well as all the way into programs like the ovp.

A

The telcom user group has many members, including vendors, such as kong, nokia intel as well as operators themselves like att charter, china, mobile and t-mobile.

A

While we're not expecting to do software development, we have been capturing requirements, doing gap, analysis and scoping.

A

We've created a white paper called the cloud native thinking for telecommunications, which is in the telecom user group github and we've contributed to the cloud native networking papers, as well as in communities like cnt and ovp, where we've provided feedback and direct improvements in the reference architecture. Requirements looked at gap analysis and helped with the reference implementation, as well as help provide feedback and learnings that we've had to the cncf and kubernetes projects from the telcom communities.

A

The cnf testbed we have many different contributors from different companies and communities like elephants, fdio project, samsung, intel the network service mesh sandbox project from cncf.

A

It's an open source test bed. It works out of the box for deployments on packet, a bare metal hosting provider. You can think of the testbed as an innovation review tool. It supports using different technology options, keeping things as simple as reasonably possible. So you can understand the components, the different parts of the examples, as well as an entire environment. It trusts use upstream community tooling as much as possible, like cubespray, a kubernetes project for bootstrap and kubernetes and nfv bench for the openfv project, and we try to follow cloud native principles wherever possible.

A

That includes all levels, including looking at immutable hardware, doing version control for everything, including the layer, 2 networking and allowing it all to be repeatable and automatable.

A

We highlight gaps where we find that difficult or potentially not available in the software and then highlight technology which provides good solutions that meet cloud native principles.

A

As I said, it's fully repeatable on packet from scratch. It currently uses inbound components as much as possible, such as helm and cube cuddle for the use cases. Examples cube spray for the boot strapping and kubernetes native replacements for many of the host setups. If they're available.

A

The examples themselves cover everything from minimal usage through more extensive use, cases and service chaining, there's technologies demonstrated like multis srv network service mesh.

A

You can replicate the environment and use cases by going to the testbed, creating an api key. If you'd like to try your own network functions, you can package them in containers and they should be runnable in the testbed we'd like to see pull requests and issues that improve the tool chain.

A

Add new examples support other labs, including your own. You can do that directly. On the github page, the cnf conformance has contributors from samsung intel and other places.

A

It's an open source test, suite based on the kubernetes conformance program and shows visibility on how well cns and the underlying platform are following cloud native principles.

A

This test results, as we mentioned earlier, should help in identifying technology that follows those principles based on what's important to operators or cnf developers.

A

The tests themselves are organized into categories based on feedback from end users, such as configuration lifecycle, installability and upgradeability principles like microservices statelessness, which is about how to use data in a cloud-native way resilience as well as security.

A

These categories apply to both workload and platform.

A

Here's an initial set of the workload tests. We can see some from microservice stateless, all the way over to resilience where we do some chaos, testing on the pods and the containers themselves.

A

When we take a look at platform test, it's important to say we're, starting with a focus on kubernetes space platform, and we expect that the platform will pass kubernetes conformance test suite and then from the cnf conformance. We care about all the layers. So that's add-ons and extensions to the platforms as well as thinking about the underlying hardware and network provisioning, and then we look at the integration between all those layers, all the way up to the workload, the requirements for these tests. We gather from many sources thinking about what's valuable to end users.

A

So we look to cndt community and the kubernetes reference architecture requirements. We talk directly to operators and cnf developers. We go to the kubernetes community for their best practices and then, of course, return to those cloud native principles.

A

Here's an initial set of the platform tests that we're working towards. They can go into those categories that we mentioned, so you can see microservice at the moment. Does it have some, but we have some for compatibility security all the way through to resilience where we're looking at chaos and interference on the nodes themselves or causing network traffic problems on the signaling or data plane.

A

We also include cnf examples such as core dns envoy, a vppp-based, ipforder and link.

A

We have other examples that we may implement, or others may implement with us, including a v-bang from onap bbs use case, as well as many different packet core examples: the go, gdp, a scaling packet gateway and others which you can see in the documentation link there.

A

If you'd like to use the cnf testbed, we have extensive documentation, including a install guide. That starts with a quick start for cnf developers, who would like to get feedback on the test results and then more extensive documentation for test developers or source based. Installs there's also extended documentation on running individual tests or test categories documentation going over prerequisites.

A

How you can run this in your own kubernetes, cluster or use kind, as well as how to use a cnf testbed to start up a cluster and then run the test.

A

We've included example configurations for testing a cnf which you can copy and modify.

A

Here's a quick snapshot of a workload test run in a terminal. You should see messages for each test that covers pass or fail a final score, and then all of these results are saved to a log.

A

The scoring system itself applies to both workload and platform, and it's based on soniboy's kubernetes conformance test suite. It has a yaml configuration file that applies to each test and the scores that those are given, as well as a yaml file. That's created for the logs, covering the test results for each test, the categories and then your final score.

A

This is an upstream upstream set of test results which could be used by other initiatives such as elephant's ovb2, badging program, cntt's rc-2, with testing efforts, as well as directly by operators and cnf developers.

A

If you'd like to get started, we'd love to have help and contributions creating new tests, we have a contributing doc. In addition to the install and usage guides, we'd like to see pull requests for any of the documentation, adding new examples or test ideas.

A

All of these initiatives we're going to continue collaborating with communities providing feedback and improvements to the requirement sources, helping with implementation efforts. We hope to provide a cloud native check box for testing and badging, and then we want to continue to help sharing all of these learnings across the communities.

A

If you'd like to get involved, we have some upcoming meetings, those weekly meetings for the cnf, testbed and conformance the next one will be on thursday august 20th at 14, 15 utc. The next telcom user group meeting is monday september 7th at 1100. Utc we'll also be at open networking and edge summit on september 30th at 14, 45 utc.

A

You can join us on the telecom user group mailing list in cncs public slack channels for these initiatives. You can email me directly: taylor, vault, dot, co-op or dan kahn via dan linuxfoundation.org. You can also book time to speak with dan directly by following this countling link.

A

You can reach us on the github pages for these initiatives via twitter we'd love to hear your feedback on this introduction to cncs telecom initiatives and how we can help you as a telecom operator or cnf developer.

A

We'll go to a q a now.

A

Thank you so much.