Kubernetes Networking 101 - Randy Abernethy, RX-M LLC

แชร์
ฝัง
  • เผยแพร่เมื่อ 29 ก.ย. 2024
  • Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
    Kubernetes Networking 101 - Randy Abernethy, RX-M LLC
    Kubernetes Networking 101 will introduce attendees to the world of network communications in a hands on Cloud Native setting. This talk delivers a high level but completely practical end to end look at service communications within and without a Kubernetes cluster. Attendees will see how the many facets of Kubernetes networking come together to enable powerful communications solutions first hand. The tutorial begins with the simplest types of service communications, using Kubernetes services, DNS (CoreDNS) and CNI plugins (Cilium) to facilitate interprocess communications and load balancing. The tutorial builds additional scenarios on this base, including ingress (Emissary/Envoy), NodePort / HostPort features, load balancing (Metal-lb) and finally a short look at service mesh functionality (Linkerd). Upon completion of this tutorial, attendees will have a clear understanding of the Kubernetes communications possibilities and pointers to next steps in the learning journey.

ความคิดเห็น • 14

  • @fraternitas5117
    @fraternitas5117 5 หลายเดือนก่อน +10

    11:53 start

  • @mamborambo
    @mamborambo ปีที่แล้ว +13

    Although Kubernetes is "unopinionated", it does need to provide some guidelines or best practices, otherwise it is just a bag of tools dependent on the user's skill sets. By 1.23+, Kubernetes is still too difficult for most users, and this is telling.

  • @blegster
    @blegster 9 หลายเดือนก่อน +3

    Thank you Dr. House for this talk

  • @__noob__coder__
    @__noob__coder__ ปีที่แล้ว +3

    Can't speak after watching this. Such an amazing experience I had !

  • @joshreji7510
    @joshreji7510 ปีที่แล้ว +1

    Kubernetes eats it's own dog food.
    Or Kubernetes eat it own shit.

  • @assonancex
    @assonancex ปีที่แล้ว +1

    This was a fantastic comprehensive talk. Filled some the gaps in my understanding for sure.

  • @vasumahalingam5162
    @vasumahalingam5162 5 หลายเดือนก่อน

    Brilliant presentation, thanks @Randy

  • @joshreji7510
    @joshreji7510 ปีที่แล้ว

    Such an incredible insightful video!!

  • @joeharyar9873
    @joeharyar9873 ปีที่แล้ว

    Actually how many subnet is required to form k8s cluster? Got nodeip, clusterip, serviceip, podip. I seen for min single subnet does work but actually for production deployment how many subnet network is required (regardless the prefix).

    • @ronaldpetty343
      @ronaldpetty343 ปีที่แล้ว +1

      It does very by many factors. In many cases people (developers) are not in full control of their operating environment and things like overlay networks can give them some flexibility there (e.g. pod network packets are routing over the node physical network). The cluster/service IPs (same thing) in most installations are thought of as networks, but not really networks in themselves. They are typically just rules in IPTables that influence things before routing decisions are made. Again, that is partially because IPTables was/is a gold standard in managing packets AND using IPs keeps things down at L3 (aka for routing), other wise we have to deal with more specific things like HTTP Headers (at L7). Not really an answer, just some thoughts on why it looks like 3 networks are the norm, when in theory and practice we can do other things.

    • @joeharyar9873
      @joeharyar9873 ปีที่แล้ว

      @@ronaldpetty343 Thanks Ronald, you have good point. The perspective might be different from a developer who just leverage the container pods for the application development compare to system admin who manage the cluster itself. As a cluster owner definitely they want to have the control of the cluster inclusive the network attached. I mean, user have the right to customize the cluster as per their requirement. In this specific case user must subscribe dedicated cluster for them, I don't think sharing cluster will be fit for them.

  • @codelinx
    @codelinx 2 ปีที่แล้ว +3

    This is what I was looking for. I haven't gotten far into the video, but hope this has info about metallb.🤞

    • @codelinx
      @codelinx 2 ปีที่แล้ว +3

      Yes metallb is in this!

  • @saqibbutt120
    @saqibbutt120 ปีที่แล้ว +3

    Amazing, outstanding, superb