
Sign up to save your podcasts
Or


Show: 28
Show Overview: Brian and Tyler talk about Joe Beda's "More Usable Kubernetes" presentation at KubeCon focused on Roles and Personas of Kubernetes environments. They look at how Cluster and Applications are separated, and how Operators and Developers distribute roles, as well as the intersection of those four areas.
Show Notes:
Topics - On today's show, we looked at the four quadrants outlined by Joe Beda in his talk "More Usable Kubernetes" at KubeCon 2017 Austin. He looked at each role and how well the Kubernetes community has addressed that functional area in both tooling and clear definition of the tasks required. We explored where areas are doing well (green) and where there are still areas that need improvement (yellow or red).
Feedback?
Show: 27
Show Overview: Brian and Tyler talk about the new Serverless working group and whitepaper from CNCF, the 4 elements of serverless, the difference between serverless and FaaS, and the on-going role of Ops teams in a serverless world.
Show Notes:
Topic 1 - Let’s talk about the history of serverless within the CNCF, and maybe within the context of PaaS and Kubernetes.
Topic 2 - When talking about Serverless, there seem to be 4 areas to dissect:
Topic 3 - What were your key takeaways from reading the CNCF Serverless whitepaper?
Topic 4 - What about Operations? Do those jobs go away? Are there Ops uses for serverless?
Feedback?
Show: 26
Show Overview: Brian and Tyler talk common myths and misperceptions about Kubernetes, container usage, Kubernetes architecture, compatibility, and OSS stats.
Show Notes:
Myth/Misunderstanding 1 - Architecture - Kubernetes Multi-Tenancy
Myth/Misunderstanding 2 - Architecture - Kubernetes is only for Operators
Myth/Misunderstanding 3 - What does "GKE Compatible" mean?
Myth/Misunderstanding 4 - Enterprises should run Kubernetes as trunk version
Myth/Misunderstanding 5 - Are OSS stats important? How to interpret them?
Feedback?
Show: 25
Show Overview: Brian and Tyler talk common myths and misperceptions about Kubernetes, container usage, and which applications are a good fit for container platforms.
Show Notes:
Myth/Misunderstanding 1 - Kubernetes is a platform.
Myth/Misunderstanding 2 - Containers are only for microservices
Myth/Misunderstanding 3 - Microservices are always “micro” (small in size)
Myth/Misunderstanding 4 - Kubernetes is only for stateful app
Feedback?
Show: 24
Show Overview: Brian and Tyler talk about the differences between a container and an application, and where the lines are blurred at the platform later. What should developers care about? Should Kubernetes be the only platform technology?
Show Notes:
News of the Week:
Topic 1 - What’s the most common “basic” question you get about containers? How often is it about either [a] what should developers care about?, or [b] what applications can go into a container?
Topic 2 - As we’ve seen from various survey data (both from CNCF and analyst firms), there is still some amount of “mixed orchestration” in usage. Have you seen specific applications that really require different orchestrators these days?
Topic 3 - Are the orchestrators similar enough that Ops teams can learn multiple? What else is required to operator multiple orchestrators?
Topic 4 - What is the line between a CaaS and a PaaS? Are those even the right distinctions anymore? What’s different for each for a developer?
Topic 5 - As we’re seeing more “serverless / FaaS” projects created for Kubernetes (OpenFaaS, Kubeless, Fission, OpenWhisk, Nuclio, Fn, etc.), where developers just deal with functions and event-sources, won’t this blur the line more?
Feedback?
Show: 23
Show Overview: Brian and Tyler talk with Christian Posta (@christianposta, Chief Architect, Cloud Application Development at Red Hat) about the evolution of SOA and Microservices, Envoy Proxy and Istio Service Mesh, emerging application patterns, and how Kubernetes and Istio are the future of microservices.
Show Notes:
Topic 1 - Welcome to the show. Give us a little bit of your background as a developer and history of working with various development frameworks/languages/concepts.
Topic 2 - Let’s start with some basics - as a development paradigm, why are we now seeing technologies like Istio and Envoy? The premise of service mesh “reliably connecting services across the network” sounds eerily similar to what we heard about ESB technology. Can you say some words about why this service mesh concept idea is different? Or is it?
Topic 3 - So we’re seeing a need to decouple the application code from the routing-level logic and control. Walk us through the types of things that Istio and Envoy are providing for applications? What are the performance implications of the service mesh? How is this related to API management?
Topic 4 - Architecturally, where are you seeing some of the advantages of Istio / Envoy vs. either previous approaches, or some other service-mesh like projects in the market? (e.g. linkerd, Netflix OSS projects)
Topic 5 - What are some specific problem examples that people run into that should make them think “maybe I need Istio”?
Topic 6 - Where is Istio in its maturity to run in production?
Feedback?
Show: 22
Show Overview: Brian talks with Taylor Thomas (@_oftaylor, Software Engineer at Nike, @HelmPack Maintainer) about the architecture of Helm, how developers interact with it to deploy applications, how Helm manages ALM, Helm Summit, and the future plans for Helm v3.
Show Notes:
Topic 1 - Welcome to the show. Let’s talk about your background prior to getting involved in the Helm community, as well as where you’re focused on with Helm these days.
Topic 2 - For someone that might only be familiar with docker containers (e.g. a DockerFile), give us the basics of what Helm does and the various pieces involved with using Helm (e.g. Helm, Helm Charts, Tiller, Kubernetes).
Topic 3 - Helm is like a blueprint of how you want your containers / application to run. Can you walk us through what else is built into Helm to give it the ability to do Application Lifecycle Management? (versioning, updates, rollback, deletion, etc.)
Topic 4 - Kubernetes can have a lot of different deployment models (stateful, stateless, jobs, batch, custom-resources, etc.). Does Helm have awareness of all of these models?
Topic 5 - What are some of the common tools and patterns you’re seeing around using Helm (CI/CD pipelines, multicloud deployments, etc.)?
Feedback?
Show: 21
Show Overview: Brian and Tyler talk about how Role-Based Access Control (RBAC) is implemented for Kubernetes.
Show Notes:
Topic 1 - The concept of RBAC is best described as “Can ______ (noun) ______ (verb) on ______ (object) at ______ (location)?” where “noun” is a person/service, “verb” is an action, “object” is a function of the API, and “location” is proximity to a Kubernetes cluster.
Topic 2 - RBAC operates on the concept of Roles and RoleBindings, which map actors to actions, and those actors and actions are defined either globally or locally, and the actions are also defined globally or locally.
Topic 3 - RBAC can be manually defined, or enabled (by default) by an installer or distribution. It comes with a default set of Roles. Everything is done within the scope of a cluster.
Topic 4 - By default, the kube-scheduler, kube-controller-manager, and kube-proxy all have RBAC roles defined. Kubelets (node-level) don’t use RBAC by default, but have their own authorizer, which can then be combined with an RBAC authorizer.
Topic 5 - “Add-ons” (networking, monitoring, logging, etc.) can have RBAC defined in their manifests, or you can grant them access to their service account.
Topic 6 - “If the element needs to be something other than those default roles, or using default authorizer services, then CustomRoles can be created. Can use audit logs to track the needs of a specific add-on. Can use “audit2rbac” tool to views the logs and create custom RBAC roles.
Topic 7 - “Aggregate Roles” are now available in Kubernetes 1.9.
Feedback?
Show: 20
Show Overview: Brian and Tyler talk with Diane Mueller (@pythondj, Director, Community Development Red Hat, OpenShift Commons) about OpenShift Commons the Open Source community that’s grown up around OpenShift Origin and the OpenShift ecosystem.
Show Notes:
Topic 1 - Welcome to the show. Tell us a little bit about your background, as you’ve been through many of the transitions in the application/developer platform market.
Topic 2 - With the breadth of the Kubernetes community today, why does the OpenShift Commons community exist? Don’t they overlap, or are they different types of goals?
Topic 3 - We wanted to talk about the bridge between really wide open communities and customers aligning around common interests. Can you tell us how OpenShift Commons is helping to facilitate those connections? What are some of the “interests” that are growing?
Topic 4 - Almost every week you host at least one video webinar that highlight new technologies. Why do you spend all this time on non-Red Hat technologies and vendors? Have you had any recently that really jumped out at you?
Topic 5 - Around each KubeCon and Red Hat Summit, you host an event called OpenShift Commons Gathering. Can you tell us what these events are, who typically attends, and how these have co-existed with the KubeCon events?
Feedback?
Show Overview: Brian and Tyler discuss the basics of Service Meshes, such as Istio, Envoy and Linkerd.
Show Notes:
Service Mesh is a layer that manages the communication between apps (or between parts of the same app, e.g. microservices)
Just as applications shouldn’t be writing their own TCP stack, they also shouldn’t be managing their own load balancing logic, or their own service discovery management, or their own retry and timeout logic. - link
Mesh: A group of hosts that coordinate to provide a consistent network topology. In this documentation, an “Envoy mesh” is a group of Envoy proxies that form a message passing substrate for a distributed system comprised of many different services and application platforms. - link
Topic 1 - What is a Service Mesh?
Topic 2 - Didn’t developers build Microservices before Service Meshes?
Topic 3 - How does a Container or Kubernetes interact with a Service Mesh?
Feedback?
From the publisher's feed