Containers require a new approach to networking. How are your containers communicating with each other? This talk will go through the different network topologies of Kubernetes. How Kubernetes addresses networking compared to traditional physical networking concepts. What are your options for networking using Kubernetes. What is the CNI (Container Network Interface) and how it affects Kubernetes networking.
A basic introductory slide set on Kubernetes: What does Kubernetes do, what does Kubernetes not do, which terms are used (Containers, Pods, Services, Replica Sets, Deployments, etc...) and how basic interaction with a Kubernetes cluster is done.
Slides for the OpenStack Newton Summit in Austin that cover the changes done during the Mitaka cycle and the direction we will take for Neutron. Swarm and Kubernetes integrations explained
- Introduction to Kubernetes features
- A look at Kubernetes Networking and Service Discovery
- New features in Kubernetes 1.6
- Kubernetes Installation options
To know more about our Kubernetes expertise, visit our center of excellence at: http://www.opcito.com/kubernetes/
WSO2Con US 2015 Kubernetes: a platform for automating deployment, scaling, an...Brian Grant
Kubernetes can run application containers on clusters of physical or virtual machines.
It can also do much more than that.
Kubernetes satisfies a number of common needs of applications running in production, such as co-locating helper processes, mounting storage systems, distributing secrets, application health checking, replicating application instances, horizontal auto-scaling, load balancing, rolling updates, and resource monitoring.
However, even though Kubernetes provides a lot of functionality, there are always new scenarios that would benefit from new features. Ad hoc orchestration that is acceptable initially often requires robust automation at scale. Application-specific workflows can be streamlined to accelerate developer velocity.
This is why Kubernetes was also designed to serve as a platform for building an ecosystem of components and tools to make it easier to deploy, scale, and manage applications. The Kubernetes control plane is built upon the same APIs that are available to developers and users, implementing resilient control loops that continuously drive the current state towards the desired state. This design has enabled Apache Stratos and a number of other Platform as a Service and Continuous Integration and Deployment systems to build atop Kubernetes.
This presentation introduces Kubernetes’s core primitives, shows how some of its better known features are built on them, and introduces some of the new capabilities that are being added.
A basic introductory slide set on Kubernetes: What does Kubernetes do, what does Kubernetes not do, which terms are used (Containers, Pods, Services, Replica Sets, Deployments, etc...) and how basic interaction with a Kubernetes cluster is done.
Slides for the OpenStack Newton Summit in Austin that cover the changes done during the Mitaka cycle and the direction we will take for Neutron. Swarm and Kubernetes integrations explained
- Introduction to Kubernetes features
- A look at Kubernetes Networking and Service Discovery
- New features in Kubernetes 1.6
- Kubernetes Installation options
To know more about our Kubernetes expertise, visit our center of excellence at: http://www.opcito.com/kubernetes/
WSO2Con US 2015 Kubernetes: a platform for automating deployment, scaling, an...Brian Grant
Kubernetes can run application containers on clusters of physical or virtual machines.
It can also do much more than that.
Kubernetes satisfies a number of common needs of applications running in production, such as co-locating helper processes, mounting storage systems, distributing secrets, application health checking, replicating application instances, horizontal auto-scaling, load balancing, rolling updates, and resource monitoring.
However, even though Kubernetes provides a lot of functionality, there are always new scenarios that would benefit from new features. Ad hoc orchestration that is acceptable initially often requires robust automation at scale. Application-specific workflows can be streamlined to accelerate developer velocity.
This is why Kubernetes was also designed to serve as a platform for building an ecosystem of components and tools to make it easier to deploy, scale, and manage applications. The Kubernetes control plane is built upon the same APIs that are available to developers and users, implementing resilient control loops that continuously drive the current state towards the desired state. This design has enabled Apache Stratos and a number of other Platform as a Service and Continuous Integration and Deployment systems to build atop Kubernetes.
This presentation introduces Kubernetes’s core primitives, shows how some of its better known features are built on them, and introduces some of the new capabilities that are being added.
Docker network performance in the public cloudArjan Schaaf
Presentation from Container Camp London 2015 which compares both the network performance of containers on both AWS and Azure. Included SDN solutions in these tests are Flannel, Weave and Project Calico.
Multi-Container Apps spanning Docker, Mesos and OpenStackDocker, Inc.
Roll up! Roll up! Before your very eyes Andrew will use Apache Brooklyn powered Clocker to deploy and manage multi-container applications transparently spanning - Docker, Mesos and OpenStack.
Kuryr-Kubernetes: The perfect match for networking cloud native workloads - I...Cloud Native Day Tel Aviv
The Kuryr project offers an interesting approach to network cloud native workloads, by enabling container orchestration engines to consume network services from OpenStack Neutron.With pod-in-VM support, Kuryr-Kubernetes enables a whole slew of new hybrid workloads, like bare metal or in-VM pods accessing services that run on VMs, multiple COEs (e.g. Docker Swarm to Kubernetes), and more. Unified networking simplifies deployment, configuration and provides single pane of glass into management and troubleshooting.
Let’s dive into Kuryr Kubernetes and learn how different open source technologies can complement each other in order to enable number of complicated deployment scenarios.
Tech Talk by Gal Sagie: Kuryr - Connecting containers networking to OpenStack...nvirters
These are slides from the Tech Talk at http://www.meetup.com/openvswitch/events/226518209/
Synopsis
Kuryr is a new project under Neutron's big tent that makes Neutron networking available to Docker containers by means of a Docker plugin.
In this session Gal will introduce Kuryr and show how it provides networking for containers in plain Docker environments and in mixed Docker, OpenStack environments. He will also present Kuryr's roadmap and integration with networking models in other orchestration engines like Kubernetes and Docker
About Gal Sagie
Gal Sagie is an open source software architect at Huawei European Research Centre, focusing work on OpenStack networking and containers networking. Working on various projects in the community like Dragonflow, OVN, Kuryr, and Multisite/Hybrid clouds in OpenStack. Blogging for anything SDN/NFV/OpenStack related at http://galsagie.github.io
KubeCon CloudNativeCon 2016 Seattle - a reportKrishna-Kumar
KubeCon / CloudNativeCon Seattle summary report - Just to recapture some of the items from the event - Few of the items are copied from other blogs from reference - pictures are just for FUN!
Gaetano Borgione's presentation from the 2017 Open Networking Summit.
Networking is vital for cloud-native apps where distributed computing and development models require speed, simplicity, and scale for massive number of ephemeral containers. Two of the most prevalent container networking models are CNI and CNM for developers using Docker, Mesos, or Kubernetes. This session will present an overview of distributed development, how CNI and CNM models work, and how container frameworks use these models for networking. Gaetano will also discuss the additional functions users need to consider in the control plane and data plane to achieve operational scale and efficiency.
Overlay/Underlay - Betting on Container NetworkingLee Calcote
Presented at Rackspace Austin (downtown) on July 27th, 2016.
An inherent to component to any distributed application, networking is one of the most complicated and expansive infrastructure technologies. Container networking needs to be developer-friendly. Application-driven and portable. With developers busily adopting container technologies, the time has come for network engineers and operators to prepare for the unique challenges brought on by cloud native applications. What container networking specifications bring to the table and how to leverage them.
Building stateful applications on Kubernetes with RookRoberto Hashioka
Deploying stateful applications such a Wordpress and Jenkins on top of Kubernetes or any other container orchestrator can be a challenging task. In this context, Rook will be used to showcase how to automatically manage the volume's lifecycle through the its Kubernetes operators (operator pattern approach) by leveraging the recently added CSI GA support.
Orchestrating Docker Containers with Google Kubernetes on OpenStackTrevor Roberts Jr.
Kubernetes, Docker, CoreOS, and OpenStack for container workload management.
No audio, but there are annotations to follow along with the workload.
A video accompanies a Microservices Meetup talk that I presented on February 18, 2015 at https://www.youtube.com/watch?v=RfyIYhOzyPY
Acknowledgements to Kelsey Hightower for the workflow that I used, and Google for the example application shown.
Secure Your Containers: What Network Admins Should Know When Moving Into Prod...Cynthia Thomas
This session offers techniques for securing Docker containers and hosts using open source network virtualization technologies to implement microsegmentation. Come learn real tips and tricks that you can apply to keep your production environment secure.
Docker network performance in the public cloudArjan Schaaf
Presentation from Container Camp London 2015 which compares both the network performance of containers on both AWS and Azure. Included SDN solutions in these tests are Flannel, Weave and Project Calico.
Multi-Container Apps spanning Docker, Mesos and OpenStackDocker, Inc.
Roll up! Roll up! Before your very eyes Andrew will use Apache Brooklyn powered Clocker to deploy and manage multi-container applications transparently spanning - Docker, Mesos and OpenStack.
Kuryr-Kubernetes: The perfect match for networking cloud native workloads - I...Cloud Native Day Tel Aviv
The Kuryr project offers an interesting approach to network cloud native workloads, by enabling container orchestration engines to consume network services from OpenStack Neutron.With pod-in-VM support, Kuryr-Kubernetes enables a whole slew of new hybrid workloads, like bare metal or in-VM pods accessing services that run on VMs, multiple COEs (e.g. Docker Swarm to Kubernetes), and more. Unified networking simplifies deployment, configuration and provides single pane of glass into management and troubleshooting.
Let’s dive into Kuryr Kubernetes and learn how different open source technologies can complement each other in order to enable number of complicated deployment scenarios.
Tech Talk by Gal Sagie: Kuryr - Connecting containers networking to OpenStack...nvirters
These are slides from the Tech Talk at http://www.meetup.com/openvswitch/events/226518209/
Synopsis
Kuryr is a new project under Neutron's big tent that makes Neutron networking available to Docker containers by means of a Docker plugin.
In this session Gal will introduce Kuryr and show how it provides networking for containers in plain Docker environments and in mixed Docker, OpenStack environments. He will also present Kuryr's roadmap and integration with networking models in other orchestration engines like Kubernetes and Docker
About Gal Sagie
Gal Sagie is an open source software architect at Huawei European Research Centre, focusing work on OpenStack networking and containers networking. Working on various projects in the community like Dragonflow, OVN, Kuryr, and Multisite/Hybrid clouds in OpenStack. Blogging for anything SDN/NFV/OpenStack related at http://galsagie.github.io
KubeCon CloudNativeCon 2016 Seattle - a reportKrishna-Kumar
KubeCon / CloudNativeCon Seattle summary report - Just to recapture some of the items from the event - Few of the items are copied from other blogs from reference - pictures are just for FUN!
Gaetano Borgione's presentation from the 2017 Open Networking Summit.
Networking is vital for cloud-native apps where distributed computing and development models require speed, simplicity, and scale for massive number of ephemeral containers. Two of the most prevalent container networking models are CNI and CNM for developers using Docker, Mesos, or Kubernetes. This session will present an overview of distributed development, how CNI and CNM models work, and how container frameworks use these models for networking. Gaetano will also discuss the additional functions users need to consider in the control plane and data plane to achieve operational scale and efficiency.
Overlay/Underlay - Betting on Container NetworkingLee Calcote
Presented at Rackspace Austin (downtown) on July 27th, 2016.
An inherent to component to any distributed application, networking is one of the most complicated and expansive infrastructure technologies. Container networking needs to be developer-friendly. Application-driven and portable. With developers busily adopting container technologies, the time has come for network engineers and operators to prepare for the unique challenges brought on by cloud native applications. What container networking specifications bring to the table and how to leverage them.
Building stateful applications on Kubernetes with RookRoberto Hashioka
Deploying stateful applications such a Wordpress and Jenkins on top of Kubernetes or any other container orchestrator can be a challenging task. In this context, Rook will be used to showcase how to automatically manage the volume's lifecycle through the its Kubernetes operators (operator pattern approach) by leveraging the recently added CSI GA support.
Orchestrating Docker Containers with Google Kubernetes on OpenStackTrevor Roberts Jr.
Kubernetes, Docker, CoreOS, and OpenStack for container workload management.
No audio, but there are annotations to follow along with the workload.
A video accompanies a Microservices Meetup talk that I presented on February 18, 2015 at https://www.youtube.com/watch?v=RfyIYhOzyPY
Acknowledgements to Kelsey Hightower for the workflow that I used, and Google for the example application shown.
Secure Your Containers: What Network Admins Should Know When Moving Into Prod...Cynthia Thomas
This session offers techniques for securing Docker containers and hosts using open source network virtualization technologies to implement microsegmentation. Come learn real tips and tricks that you can apply to keep your production environment secure.
Provided an overview about Hybrid Networking including Containers and VM. It also touches upon opensource solutions like Openstack Kuryr, Opendaylight.
Containers are changing the compute landscape and for NFVi support of Containers is key. Kubernetes is a well known Container Cluster Management software and this is slide deck from a talk given in Opendaylight Summit 2016. This slide gives an insight about Microservice architecture, Kuberentes and how it can be integrated with ODL. Session Video can be found at https://www.youtube.com/watch?v=a4_pkp2qiX8&list=PL8F5jrwEpGAiRCzJIyboA8Di3_TAjTT-2
Kubernetes has a very complex network architecture. It is the networking that enables Kubernetes to redefine the latest container technology.
1. Docker containers networks
2. Containers communication in a Pod
3. Pods communication cross different nodes
4. Pod to Service communication
Kubernetes as Orchestrator for A10 Lightning ControllerAkshay Mathur
A10 Lightning Application Delivery System (ADS) supports hybrid environments by providing secure application services and advanced analytics across the entire deployment – from traditional on-premise data centers, to public and/or private clouds, or any combination thereof. A10 Lightning employs a controller-based architecture that can self-managed on-premise or in a private cloud, or utilized as a SaaS offering managed by A10, to enable management of heterogeneous workloads across physical hardware-based environments, as well as public, private, and hybrid clouds.
This presentation talks about our journey from a VM based Controller to a Kubernetes based Controller
These slides were used during a technical session for the Cloud-Native El Salvador community. It covers the basic Kubernetes components, some installers and main Kubernetes resources. For the demo, it was used the capabilites provided by the Horizontal Pod Autoscaler.
Overview of kubernetes and its use as a DevOps cluster management framework.
Problems with deployment via kube-up.sh and improving kubernetes on AWS via custom cloud formation template.
DevNetCreate - ACI and Kubernetes IntegrationHank Preston
These are slides from my hands on lab workshop at DevNet Create 2019 in April. https://developer.cisco.com/devnetcreate/2019/agenda
Description:
Enterprises all over are embracing Kubernetes as the foundation for their cloud native, micro service applications. As they are, network security is becoming a top of mind question. The ACI CNI Plugin for Kubernetes brings the power of Application Centric Infrastructure (granular segmentation, robust operational visibility, and unsurpassed network performance) to the Docker container driven infrastructure of Kubernetes. In this session, you'll have a chance to see all of this in action through a guided exploration of your very own Kubernetes cluster integrated with an ACI fabric. You'll start by diving into how a typical application looks after being deployed to Kubernetes within the ACI fabric. See each individual container and pod show up within the ACI operational dashboards. Look at how the load balancing and traffic routing is handled within the network by ACI, just like any other application environment. Then begin to enhance the policies applied to the application by segmenting applications by name spaces for better isolation between running applications. But we won't stop there, before you're done you'll build contracts to explicitly control the flow of traffic between the tiers of your application to ensure business and security policies are applied to containerized applications running within Kubernetes with the same contracts and filters you're using for traditional workloads.
Kubernetes Introduction. The concepts you need to understand to effectively develop and run applications in a Kubernetes environment. Focusing primarily on application developers, but it also provides an overview of managing applications from the operational perspective. It’s meant for anyone interested in running and managing containerized applications on more than just a single server.
Simplify Your Way To Expert Kubernetes ManagementDevOps.com
Kubernetes is a deep and complex technology that is evolving fast with new functionality and a growing ecosystem of cloud-native solutions. While the public cloud delivers an almost frictionless user experience, configuring and managing a production Kubernetes environment is an enormous technical challenge for the majority of enterprises that choose to do so on premises. Without the right approach, operationalizing Kubernetes in the data center can take upwards of 6 months, jeopardizing developer productivity and speed-to-market.
In this webinar, you’ll learn from Nutanix cloud native experts on how to fast-track your way to operationalizing a production-ready Kubernetes environment on-prem.
Specifically, we’ll talk about:
How containerized applications use IT resources (and why legacy infrastructure isn’t built for Kubernetes);
The main advantages of running Kubernetes on prem (as part of a multi-cloud strategy);
Key aspects of Kubernetes lifecycle management that greatly benefit from automation.
OSDC 2017: Automating Kubernetes Cluster Operations with Operators by Timo De...NETWAYS
At Giant Swarm, we manage Kubernetes clusters for customers 24/7, both on-premises and in the cloud. That means we do not just set something up and hand it over, but we actually take care that it’s operational and up-to-date at all times.
In this talk Timo explains how Giant Swarm are using Operators to codify all operational tasks of managing Kubernetes cluster and distributed applications on top. The operators manage PKI infrastructures, networks, VMs and storage both on-premises and in the cloud. There have been a lots of challenges and learnings in the past year and Timo would like to share them with you.
OSDC 2017 - Timo Derstappen - Automating kubernetes cluster operations with o...NETWAYS
At Giant Swarm, we manage Kubernetes clusters for customers 24/7, both on-premises and in the cloud. That means we do not just set something up and hand it over, but we actually take care that it’s operational and up-to-date at all times.
In this talk Timo explains how Giant Swarm are using Operators to codify all operational tasks of managing Kubernetes cluster and distributed applications on top. The operators manage PKI infrastructures, networks, VMs and storage both on-premises and in the cloud. There have been a lots of challenges and learnings in the past year and Timo would like to share them with you.
Overview of OpenDaylight Container Orchestration Engine IntegrationMichelle Holley
Looking for a way to deploy a stable OpenStack Cloud Environment with Opendaylight at ease? This session is about learning to deploy a Cloud environment with OPNFV Fuel deployer. Fuel is a deployment tool which deploys a wide variety of distributions with third party plugins like OpenDayLight, while abstracting out complexities of the deployment. The intent of this session is to familiarize deployment of OpenStack with OpenDaylight.
About the presenter: Pramod Raghavendra Jayathirth is a software developer in OpenStack and OpenDayLight, working for OTC, SSG at Intel. His Area of Interest is in Cloud Networking and Applications. He has prior experience in Databases and his current focus is on developing features of Cloud Networking Platform. He holds Masters Degree from San Jose State University.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
2. Agenda
1 Kubernetes Overview
2 Kubernetes Network Topologies
3 Kubernetes Services
4 Kubernetes Endpoints
5 A word on CNI
3. What is Kubernetes?
[1] http://kubernetes.io/docs/whatisk8s/ [0] http://static.googleusercontent.com/media/research.google.com/de//pubs/archive/43438.pdf
• Kubernetes: Kubernetes or K8s in short is the ancient Greek word for
Helmsmen
• K8s roots: Kubernetes was championed by Google and is now backed by
major enterprise IT vendors and users (including VMware)
• Borg: Google’s internal task scheduling system Borg served as the
blueprint for Kubernetes, but the code base is different [1]
Kubernetes Roots
• Mission statement: Kubernetes is an open-source platform for
automating deployment, scaling, and operations of application containers
across clusters of hosts, providing container-centric infrastructure.
• Capabilities:
• Deploy your applications quickly and predictably
• Scale your applications on the fly
• Seamlessly roll out new features
• Optimize use of your hardware by using only the resources you need
• Role: K8s sits in the Container as a Service (CaaS) or Container
orchestration layer
What Kubernetes is [0]
4. Kubernetes Components
• API server: Target for all operations to the data model. External
API clients like the K8s CLI client, the dashboard Web-Service,
as well as all external and internal components interact with the
API server by ’watching’ and ‘setting’ resources
• Scheduler: Monitors Container (Pod) resources on the API
Server, and assigns Worker Nodes to run the Pods based on
filters
• Controller Manager: Embeds the core control loops shipped
with Kubernetes. In Kubernetes, a controller is a control loop that
watches the shared state of the cluster through the API Server
and makes changes attempting to move the current state
towards the desired state
Kubernetes Master Component
• Etcd: Is used as the distributed key-value store of
Kubernetes
• Watching: In etcd and Kubernetes everything is
centered around ‘watching’ resources.
Every resource can be watched in K8s on etcd
through the API Server
Distributed Key-Value Store
K8s master
K8s master
K8s
Master
Controller
Manager
K8s API
Server
> _
Kubectl
CLI
Key-Value
Store
dashboard
Scheduler
5. Kubernetes Components
• Kubelet: The Kubelet agent on the Nodes is watching for
‘PodSpecs’ to determine what it is supposed to run
• Kubelet: Instructs Container runtimes to run containers
through the container runtime API interface
Kubernetes Node Component
• Docker: Is the most used container runtime in K8s.
However K8s is ‘runtime agnostic’, and the goal is to
support any runtime through a standard interface (CRI-O)
• Rkt: Besides Docker, Rkt by CoreOS is the most visible
alternative, and CoreOS drives a lot of standards like CNI
and CRI-O
Container Runtime
K8s master
K8s master
K8s
Master
Controller
Manager
K8s API
Server
Key-Value
Store
dashboard
Scheduler
K8s node
K8s node
K8s node
K8s node
K8s Nodes
kubelet c runtime
Kube-proxy
> _
Kubectl
CLI
• Kube-Proxy: Is a daemon watching the K8s ‘services’ on
the API Server and implements east/west load-balancing
on the nodes using NAT in IPTables
Kube Proxy
6. Kubernetes Cluster
• Cluster that is built to run container workloads
• Made up of a Kubernetes Master and a number of worker Nodes
• Because it’s a cluster it makes networking that much more important so that applications can talk to each other
k8s-master k8s-node1 k8s-node2
ens32 ens32 ens32192.168.0.10 192.168.0.11 192.168.0.12
net.ipv4.ip_forward=1 net.ipv4.ip_forward=1 net.ipv4.ip_forward=1
Physical
Network
192.168.0.1
Linux-bridge
‚cni‘
10.4.0.0/24
Linux-bridge
‚cni‘
10.4.1.0/24 10.4.2.0/24
Linux-bridge
‚cni‘
7. Kubernetes Pod
Pod
pause container
(‘owns’ the IP stack)
10.24.0.0/16
10.24.0.2
nginx
tcp/80
mgmt
tcp/22
logging
udp/514
• POD: A pod (as in a pod of whales or pea pod) is a
group of one or more containers
• Networking: Containers within a pod share an IP
address and port space, and can find each other via
localhost. They can also communicate with each
other using standard inter-process communications
like SystemV semaphores or POSIX shared
memory
• Pause Container: A service container named
‘pause’ is created by Kubelet. Its sole purpose is to
own the network stack (linux network namespace)
and build the ‘low level network plumbing’
• External Connectivity: Only the pause container is
started with an IP interface
• Storage: Containers in a Pod also share the same
data volumes
• Motivation: Pods are a model of the pattern of
multiple cooperating processes which form a
cohesive unit of service
Kubernetes Pod
IPC
External IP Traffic
9. Node Wiring
Node
int
eth0
10.240.0.3
int
cbr0
10.24.1.1/24
10.24.1.4
vethzz
10.24.1.2
vethxx
10.24.1.3
vethyy
• IaaS Network: The IaaS network, which could
be a physical network or an overlay network, is
responsible to route between nodes
• NAT: No port-mapping or private IP’s.
• Node routing: Every Node is an IP Router and
is assigned a CIDR Block typically a /24
• Node Bridge: Container Bridge that vethxx
connect pods to the bridge
• Pods: Every Pod gets an IP Address from the
Node Subnet and can communicate with any
other pod in the cluster
• Node Network namespaces
• root netns (eth0, vethxx, cbr0)
• pod netns (eth0)
Node Wiring
11. Node 2int
eth0
10.240.0.4
int
cbr0
10.24.2.1/24
10.24.2.2 10.24.2.3 10.24.2.4
Kubernetes Networking Topologies
Flat routed topology
ip route 10.24.1.0/24 10.240.0.3
ip route 10.24.2.0/24 10.240.0.4
• Node routing: Every Node is an IP Router and
responsible for its Pod Subnet
• Pods: Every Pod gets an IP Address from the
Node Subnet
• IaaS Network: The IaaS network, which could
be a physical network or an overlay network, is
responsible to route between nodes
• Drawbacks:
• Orchestrating the routing from/to Nodes
gets complex especially when using
‘physical gear’
• The K8s Namespace doesn’t fall into a
Subnet boundary, making it difficult to
distinguish tenants based on IPs
• Benefits:
• Direct routing from/to Pods makes it easy
to integrate with existing VM based or
physical ‘services’
• Implementations: The flat routed topology is
the ‘default’ for a K8s deployment. It is also used
in some other technologies like Calico.
Kubernetes flat routed topology
Node 1int
eth0
10.240.0.3
int
cbr0
10.24.1.1/24
10.24.1.2 10.24.1.3 10.24.1.4
12. Another way to look at the cluster
• Physical routing required for each worker node’s CIDR Block
• Advertised across the physical network for each cluster
k8s-master k8s-node1 k8s-node2
ens32 ens32 ens32192.168.0.10 192.168.0.11 192.168.0.12
net.ipv4.ip_forward=1 net.ipv4.ip_forward=1 net.ipv4.ip_forward=1
Physical
Network
192.168.0.1
Linux-bridge
‚cni‘
10.4.0.0/24
Linux-bridge
‚cni‘
10.4.1.0/24 10.4.2.0/24
Linux-bridge
‚cni‘
k8s-master k8s-node1 k8s-node210.4.0.0/24 10.4.2.0/2410.4.1.0/24
13. Kubernetes Networking Topologies
Node-to-Node overlay topology
Nodeint
eth0
10.240.0.4
int
cbr0
10.24.2.1/24
10.24.2.2 10.24.2.3 10.24.2.4
Nodeint
eth0
10.240.0.3
int
cbr0
10.24.1.1/24
10.24.1.2 10.24.1.3 10.24.1.4
net.ipv4.ip_forward=1
net.ipv4.ip_forward=1
Overlay
• Node: Still every node is an IP Router, but now
has also has a global view of all Node Subnets
through a central topology view, usually
implemented using a key value store like etcd
• Pods: Every Pod gets an IP Address from the
Node Subnet like in the flat routed topology
• Encapsulation: Traffic between nodes is
encapsulated, e.g. in a proprietary UDP header or
into VXLAN. Every Node subnet is pointing to a
tunnel endpoint address learned through etcd
• Drawbacks:
• Routing in and out of the overlay is difficult,
and involves one or more ‘on-ramp’ nodes or
using services with ‘NodePort’
• Benefits:
• Very easy start, no need to deal with routing
in the Infrastructure
• Implementations: Overlays are used by Flannel,
Weave and OVS networking
Kubernetes Node-to-Node overlay
Key-Value
Store
16. Node 2int
eth0
10.240.0.4
int
cbr0
10.24.2.1/24
10.24.2.2 10.24.2.3 10.24.2.4
ip route 10.24.1.0/24 10.240.0.3
ip route 10.24.2.0/24 10.240.0.4
Kubernetes Pod to Pod flat routed
topology
Node 1int
eth0
10.240.0.3
int
cbr0
10.24.1.1/24
10.24.1.2 10.24.1.3 10.24.1.4
Kubernetes Networking Topologies
Flat routed topology
• Pod to Pod communication will leave
Node 1 and use the physical network to
route to Pod 2 via Node 2
• CIDR routes must be installed across
your physical network
17. Pod to Pod across Nodes
Node-to-Node overlay topology
Node 2int
eth0
10.240.0.4
int
cbr0
10.24.2.1/24
10.24.2.2 10.24.2.3 10.24.2.4
Node 1int
eth0
10.240.0.3
int
cbr0
10.24.1.1/24
10.24.1.2 10.24.1.3 10.24.1.4
net.ipv4.ip_forward=1
net.ipv4.ip_forward=1
Overlay
Key-Value
Store
Kubernetes Pod to Pod flat routed
topology
• Node 1 will encapsulate the traffic from
Pod 1oute to Pod 2 via Node 2
• Node to Node communication can be
accomplished via L2/L3/Overlay
• ETCD is used to store the mapping
between Node IP’s and Pods
19. Kubernetes Service
▶ kubectl describe svc redis-slave
Name: redis-slave
Namespace: default
Labels: name=redis-slave
Selector: name=redis-slave
Type: ClusterIP
IP: 172.30.0.24
Port: <unnamed> 6379/TCP
Endpoints: 10.24.0.5:6379,
10.24.2.7:6379
Redis Slave
Pods
redis-slave svc
10.24.0.5/16 10.24.2.7/16
172.30.0.24
• Gist: A Kubernetes Service is an abstraction which
defines a logical set of Pods
• East/West Load-Balancing: In terms of networking
a service usually contains a cluster IP, which is used
as a Virtual IP reachable internally on all Nodes
• IPTables: In the default upstream implementation
IPTables is used to implement distributed east/west
load-balancing
• DNS: A service is also represented with a DNS
names, e.g. ’redis-slave.cluster.local’ in the
Kubernetes dynamic DNS service (SkyDNS) or
through environment variable injection
• External Access: A K8s Service can also be made
externally reachable through all Nodes IP interface
using ‘NodePort’ exposing the Service through a
specific UDP/TCP Port
• Type: In addition to ClusterIP and NodePort, some
cloud providers like GCE support using the type
‘LoadBalancer’ to configure an external
LoadBalancer to point to the Endpoints (Pods)
Kubernetes Service
Web Front-End
Pods
20. Kubernetes N/S Load-Balancing
• N/S Load-Balancing: Can be achieved using various solutions in
K8s, this includes:
• K8s Service of type ‘LoadBalancer’ which is watched by
external logic to configure an external LoadBalancer
• Statically configured external LoadBalancer (e.g. F5) that
sends traffic to a K8s Service over ‘NodePort’ on specific
Nodes
• K8s Ingress; A K8s object that describes a N/S LoadBalancer.
The K8s Ingress Object is ’watched’ by a Ingress Controller
that configures the LoadBalancer Datapath. Usually both the
Ingress Controller and the LoadBalancer Datapath are
running as a Pod
Kubernetes N/S Load-Balancing
Redis Slave
Pods
redis-slave svc
10.24.0.5/16 10.24.2.7/16
172.30.0.24
Web Front-End
(e.g. Apache) Pods
Web Front-End
Ingress
Nginx || HAProxy || etc.
LB Pods
http://*.bikeshop.com
22. Kubernetes NSX Topology
Namespace: foo Namespace: bar
NSX/ K8s topology
• Namespaces: We are dynamically building a separate
network topology per K8s namespace, every K8s
namespace gets one or mode logical switches and one
Tier-1 router
• Nodes: Are not doing IP routing, every Pod has its own
logical port on a NSX logical switch. Every Node can have
Pods from different Namespaces and with this from
different IP Subnets / Topologies
• Firewall: Every Pods has DFW rules applied on its
Interface
• Routing: High performant East/West and North/South
routing using NSX’s routing infrastructure, including
dynamic routing to physical network
• Visibility and troubleshooting: Every Pod has a logical
port on the logical switch with:
• Counters
• SPAN / Remote mirroring
• IPFIX export
• Traceflow / Port-Connection tool
• Spoofguard
• IPAM: NSX is used to provide IP Address Management
by supplying Subnets from IP Block to Namespaces, and
Individual IPs to Pods
Kubernetes NSX Topology
10.24.0.0/24 10.24.1.0/24 10.24.3.0/24
Platform – Automating, scaling, operating container workloads across a cluster of hosts.
Functions as the CaaS or Container orchestration layer
Deploy’s applications quickly, and predictably
Little history lesson for today, k8s came from an internal project named Borg. Kubernetes greek word meaning Helmsmen
Pod to Pod communication is accessible by their IP address regardless of what VM they live on.
This is done through Linux network namespaces and virtual interfaces
IaaS network requirement can be satisfied by L2/L3 or Overlay network
IPs are routable
Pods can talk to each other without NAT
Don’t have the to worry about port mapping management and complexity