Table of Contents
Networking and Kubernetes
Return to Kubernetes networking, Networking with Kubernetes, Bibliography, Kubernetes Bibliography, Kubernetes Books, K8S Bibliography, K8S Books,
by James Strong and Vallery Lancey
Kubernetes has become an essential part of the daily work for most system, network, and cluster administrators today. But to work effectively together on a production-scale Kubernetes system, they must be able to speak the same language. This book provides a clear guide to the layers of complexity and abstraction that come with running a Kubernetes network.
Authors James Strong and Vallery Lancey bring you up to speed on the intricacies that Kubernetes has to offer for large container deployments. If you're to be effective in troubleshooting and maintaining a production cluster, you need to be well versed in the abstraction provided at each layer. This practical book shows you how.
- Learn the Kubernetes networking model
- Choose the best interface for your Kubernetes clusters from the CNCF Container Network Interface project
- Explore the Kubernetes networking and Linux primitives that power Kubernetes
- Quickly troubleshoot Kubernetes networking issues and prevent Kubernetes downtime
- Examine cloud networking and Kubernetes using the three major Cloud providers: Amazon Web Services, Google Cloud (GCP), and Microsoft Azure
- Learn the pros and cons of various network tools – and how to select the best ones for your Kubernetes stack
About the Authors
James began his career in Networking, first attending Cisco Networking Academy in High School. He then went on to be a Network Engineer at the University of Dayton and GE Appliances. While attending GE’s Information Technology Leadership program, James was able to see many of the problems that face system administrators and developers in an Enterprise environment. As the Cloud Native Director at Contino, James leads many large-scale enterprises and financial institutions through their Cloud and DevOps journeys. He is deeply involved in his local cloud native community, running local meetups, both AWS User Group & Cloud-Native Louisville. He holds a Master of Science in Computer Science from the University of Louisville, six AWS Certifications, including the Certified Advanced Networking Specialty, along with the CNCF’s CKA.
Vallery started her career at Checkfront as the company’s first DevOps Engineer. She began adopting Kubernetes in 2017, living through many of the early-adopter challenges, and rapidly evolving features. At Lyft, she works on the Compute Platform team as an Infrastructure Software Engineer, building and maintaining Lyft’s multi-cluster Kubernetes platform. At Lyft, she has worked on multicluster ingress support. Vallery is a Kubernetes contributor, and got her start in SIG-Network. There, she has contributed to kube-proxy, and IP dualstack support. She currently contributes to multiple areas of Kubernetes, and brings an end-user perspective to the project.
Product details
- Publisher : O'Reilly Media; 1st edition
- Publication date : September 8, 2021
- ISBN-10 : 1492081655
- ISBN-13 : 978-1492081654
- ASIN : B09FX149GC
Preface
Just Another Packet
Since the first two computers were joined together over a cable, networking has been a crucial part of our infrastructure. Networks now have layers and layers of complexity to support a multitude of use cases, and the advent of containers and projects like Mesosphere and Kubernetes have not changed that. While the contributors of Kubernetes have attempted to abstract away this networking complexity for developers, computer science is just that, abstraction upon abstraction. Kubernetes, and its networking API, is another abstraction that makes it easier and faster to deploy applications for consumption. What about the administrator who has to manage Kubernetes? This book intends to dispel the mysticism around the abstractions Kubernetes puts in place, guide administrators through the layers of complexity, and help you realize Kubernetes is not just another packet.
Who This Book Is For
According to 451 Research, the global application container market is expected to grow from USD 2.1 billion in 2019 to USD 4.2 billion by 2022. This explosive growth in the container market underscores the need for IT professionals to be knowledgeable in deploying, managing, and troubleshooting containers.
This book is intended to be read from beginning to end by new network, Linux, or cluster administrators, and it can be used by more experienced DevOps engineers to jump to specific topics for which they find themselves needing to be upskilled. Network, Linux, and cluster administrators need to be familiar with how to operate Kubernetes at scale.
In this book, readers will find the information required to navigate the layers of complexity that come with running a Kubernetes network. This book will peel back the abstractions that Kubernetes puts in place so that developers have a similar experience across deployments on-premises, in the cloud, and with managed services. Engineers responsible for production cluster operations and network uptime can use this book to bridge the gap in their knowledge of those abstractions.
What You Will Learn
By the end of this book, the reader will understand the following:
Also, the reader will be able to do the following:
Conventions Used in This Book
The following typographical conventions are used in this book:
Indicates new terms, URLs, email addresses, filenames, and file extensions.
Constant width
Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.
Constant width bold
Shows commands or other text that should be typed literally by the user.
Shows text that should be replaced with user-supplied values or by values determined by context.
This element signifies a tip or suggestion.
This element signifies a general note.
This element indicates a warning or caution.
Supplemental material (code examples, exercises, etc.) is available for download at https://github.com/strongjz/Networking-and-Kubernetes.
If you have a technical question, or a problem using the code examples, please send email to bookquestions@oreilly.com.
This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing examples from O'Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
We appreciate, but generally do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Networking and Kubernetes by James Strong and Vallery Lancey (O'Reilly). Copyright 2021 Strongjz tech and Vallery Lancey, 978-1-492-08165-4.”
If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at permissions@oreilly.com.
For more than 40 years, O'Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed.
Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O'Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O'Reilly and 200+ other publishers. For more information, visit http://oreilly.com.
How to Contact Us
Please address comments and questions concerning this book to the publisher:
O'Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
800-998-9938 (in the United States or Canada)
707-829-0515 (international or local)
707-829-0104 (fax)
We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/NetKubernetes.
Email bookquestions@oreilly.com to comment or ask technical questions about this book.
For news and information about our books and courses, visit http://oreilly.com.
Find us on Facebook: http://facebook.com/oreilly.
Follow us on Twitter: http://twitter.com/oreillymedia.
Watch us on YouTube: http://youtube.com/oreillymedia.
The authors would like to thank the team at O'Reilly Media for helping them through the process of writing their first book. Melissa Potter was instrumental in getting this across the finish line. We would also like to recognize Thomas Behnken for aiding us with his Azure expertise.
James: Karen, thank you for all your faith in me and for helping him believe in himself even when he didn’t. Wink, you are the reason I started working in this field, and I am forever grateful. Ann, I have come a long way since learning English is supposed to be capitalized. James would also like to thank all the other teachers and coaches in his life who supported him.
Vallery: I’d like to thank the friendly faces in SIG-Network for helping me get started in upstream Kubernetes.
Finally, the authors would like to thank the Kubernetes community; this book wouldn’t exist without them. We hope it helps further the knowledge for all engineers looking to adopt Kubernetes.
Chapter 1. Networking Introduction
“Guilty until proven innocent.” That’s the mantra of networks and the engineers who supervise them. In this opening chapter, we will wade through the development of networking technologies and standards, give a brief overview of the dominant theory of networking, and introduce our Golang web server that will be the basis of the networking examples in Kubernetes and the cloud throughout the book.
The internet we know today is vast, with cables spanning oceans and mountains and connecting cities with lower latency than ever before. Barrett Lyon’s “Mapping the Internet,” shown in Figure 1-1, shows just how vast it truly is. That image illustrates all the connections between the networks of networks that make up the internet. The purpose of a network is to exchange information from one system to another system. That is an enormous ask of a distributed global system, but the internet was not always global; it started as a conceptual model and slowly was built up over time, to the behemoth in Lyon’s visually stunning artwork. There are many factors to consider when learning about networking, such as the last mile, the connectivity between a customer’s home and their internet service provider’s network—all the way to scaling up to the geopolitical landscape of the internet. The internet is integrated into the fabric of our society. In this book, we will discuss how networks operate and how Kubernetes abstracts them for us.
Figure 1-1. Barrett Lyon, “Mapping the Internet,” 2003
Table 1-1 briefly outlines the history of networking before we dive into a few of the important details.
Table 1-1. A brief history of networking Year Event
1969
ARPANET’s first connection test
1969
Telnet 1969 Request for Comments (RFC) 15 drafted
1971
FTP RFC 114 drafted
1973
FTP RFC 354 drafted
1974
TCP RFC 675 by Vint Cerf, Yogen Dalal, and Carl Sunshine drafted
1980
Development of Open Systems Interconnection model begins
1981
1982
NORSAR and University College London left the ARPANET and began using TCP/IP over SATNET
1984
ISO 7498 Open Systems Interconnection (OSI) model published
1991
National Information Infrastructure (NII) Bill passed with Al Gore’s help
1991
First version of Linux released
First version of Kubernetes released
In its earliest forms, networking was government run or sponsored; in the United States, the Department of Defense (DOD) sponsored the Advanced Research Projects Agency Network (ARPANET), well before Al Gore’s time in politics, which will be relevant in a moment. In 1969, ARPANET was deployed at the University of California–Los Angeles, the Augmentation Research Center at Stanford Research Institute, the University of California–Santa Barbara, and the University of Utah School of Computing. Communication between these nodes was not completed until 1970, when they began using the Network Control Protocol (NCP). NCP led to the development and use of the first computer-to-computer protocols like Telnet and File Transfer Protocol (FTP).
The success of ARPANET and NCP, the first protocol to power ARPANET, led to NCP’s downfall. It could not keep up with the demands of the network and the variety of networks connected. In 1974, Vint Cerf, Yogen Dalal, and Carl Sunshine began drafting RFC 675 for Transmission Control Protocol (TCP). (You’ll learn more about RFCs in a few paragraphs.) TCP would go on to become the standard for network connectivity. TCP allowed for exchanging packets across different types of networks. In 1981, the Internet Protocol (IP), defined in RFC 791, helped break out the responsibilities of TCP into a separate protocol, increasing the modularity of the network. In the following years, many organizations, including the DOD, adopted TCP as the standard. By January 1983, TCP/IP had become the only approved protocol on ARPANET, replacing the earlier NCP because of its versatility and modularity.
A competing standards organization, the International Organization for Standardization (ISO), developed and published ISO 7498, “Open Systems Interconnection Reference Model,” which detailed the OSI model. With its publication also came the protocols to support it. Unfortunately, the OSI model protocols never gained traction and lost out to the popularity of TCP/IP. The OSI model is still an excellent learning tool for understanding the layered approach to networking, however.
In 1991, Al Gore invented the internet (well, really he helped pass the National Information Infrastructure [NII] Bill), which helped lead to the creation of the Internet Engineering Task Force (IETF). Nowadays standards for the internet are under the management of the IETF, an open consortium of leading experts and companies in the field of networking, like Cisco and Juniper. RFCs are published by the Internet Society and the Internet Engineering Task Force. RFCs are prominently authored by individuals or groups of engineers and computer scientists, and they detail their processes, operations, and applications for the internet’s functioning.
Proposed Standard
A protocol specification has reached enough community support to be considered a standard. The designs are stable and well understood. A proposed standard can be deployed, implemented, and tested. It may be withdrawn from further consideration, however.
Per RFC 2026: “In general, an internet standard is a stable specification and well understood, technically competent, has multiple, independent, and interoperable implementations with substantial operational experience, enjoys significant public support, and is recognizably useful in some parts of the internet.”
Draft standard is a third classification that was discontinued in 2011.
There are thousands of internet standards defining how to implement protocols for all facets of networking, including wireless, encryption, and data formats, among others. Each one is implemented by contributors of open source projects and privately by large organizations like Cisco.
A lot has happened in the nearly 50 years since those first connectivity tests. Networks have grown in complexity and abstractions, so let’s start with the OSI model.
The OSI model is a conceptual framework for describing how two systems communicate over a network. The OSI model breaks down the responsibility of sending data across networks into layers. This works well for educational purposes to describe the relationships between each layer’s responsibility and how data gets sent over networks. Interestingly enough, it was meant to be a protocol suite to power networks but lost to TCP/IP.
Here are the ISO standards that outline the OSI model and protocols:
ISO/IEC 7498-1, “The Basic Model”
ISO/IEC 7498-2, “Security Architecture”
ISO/IEC 7498-3, “Naming and Addressing”
ISO/IEC 7498-4, “Management Framework”
The ISO/IEC 7498-1 describes what the OSI model attempts to convey:
5.2.2.1 The basic structuring technique in the Reference Model of Open Systems Interconnection is layering. According to this technique, each open system is viewed as logically composed of an ordered set of (N)-subsystems…Adjacent (N)-subsystems communicate through their common boundary. (N)-subsystems of the same rank (N) collectively form the (N)-layer of the Reference Model of Open Systems Interconnection. There is one and only one (N)-subsystem in an open system for layer N. An (N)-subsystem consists of one or several (N)-entities. Entities exist in each (N)-layer. Entities in the same (N)-layer are termed peer-(N)-entities. Note that the highest layer does not have an (N+l)-layer above it, and the lowest layer does not have an (N-1)-layer below it.
The OSI model description is a complex and exact way of saying networks have layers like cakes or onions. The OSI model breaks the responsibilities of the network into seven distinct layers, each with different functions to aid in transmitting information from one system to another, as shown in Figure 1-2. The layers encapsulate information from the layer below it; these layers are Application, Presentation, Session, Transport, Network, Data Link, and Physical. Over the next few pages, we will go over each layer’s functionality and how it sends data between two systems.
Each layer takes data from the previous layer and encapsulates it to make its Protocol Data Unit (PDU). The PDU is used to describe the data at each layer. PDUs are also part of TCP/IP. The applications of the Session layer are considered “data” for the PDU, preparing the application information for communication. Transport uses ports to distinguish what process on the local system is responsible for the data. The Network layer PDU is the packet. Packets are distinct pieces of data routed between networks. The Data Link layer is the frame or segment. Each packet is broken up into frames, checked for errors, and sent out on the local network. The Physical layer transmits the frame in bits over the medium. Next we will outline each layer in detail:
The Application layer is the top layer of the OSI model and is the one the end user interacts with every day. This layer is not where actual applications live, but it provides the interface for applications that use it like a web browser or Office 365. The single biggest interface is HTTP; you are probably reading this book on a web page hosted by an O'Reilly web server. Other examples of the Application layer that we use daily are DNS, SSH, and SMTP. Those applications are responsible for displaying and arranging data requested and sent over the network.
Presentation
This layer provides independence from data representation by translating between application and network formats. It can be referred to as the syntax layer. This layer allows two systems to use different encodings for data and still pass data between them. Encryption is also done at this layer, but that is a more complicated story we’ll save for “TLS”.
The Session layer is responsible for the duplex of the connection, in other words, whether sending and receiving data at the same time. It also establishes procedures for performing checkpointing, suspending, restarting, and terminating a session. It builds, manages, and terminates the connections between the local and remote applications.
The Transport layer transfers data between applications, providing reliable data transfer services to the upper layers. The Transport layer controls a given connection’s reliability through flow control, segmentation and desegmentation, and error control. Some protocols are state- and connection-oriented. This layer tracks the segments and retransmits those that fail. It also provides the acknowledgment of successful data transmission and sends the next data if no errors occurred. TCP/IP has two protocols at this layer: TCP and User Datagram Protocol (UDP).
The Network layer implements a means of transferring variable-length data flows from a host on one network to a host on another network while sustaining service quality. The Network layer performs routing functions and might also perform fragmentation and reassembly while reporting delivery errors. Routers operate at this layer, sending data throughout the neighboring networks. Several management protocols belong to the Network layer, including routing protocols, multicast group management, network-layer information, error handling, and network-layer address assignment, which we will discuss further in “TCP/IP”.
This layer is responsible for the host-to-host transfers on the same network. It defines the protocols to create and terminate the connections between two devices. The Data Link layer transfers data between network hosts and provides the means to detect and possibly correct errors from the Physical layer. Data Link frames, the PDU for layer 2, do not cross the boundaries of a local network.
The Physical layer is represented visually by an Ethernet cord plugged into a switch. This layer converts data in the form of digital bits into electrical, radio, or optical signals. Think of this layer as the physical devices, like cables, switches, and wireless access points. The wire signaling protocols are also defined at this layer.
There are many mnemonics to remember the layers of the OSI model; our favorite is All People Seem To Need Data Processing.
Table 1-2 summarizes the OSI layers.
Table 1-2. OSI layer details Layer number Layer name Protocol data unit Function overview
7
High-level APIs and application protocols like HTTP, DNS, and SSH.
6
Presentation
Character encoding, data compression, and encryption/decryption.
5
Continuous data exchanges between nodes are managed here: how much data to send, when to send more.
4
Transmission of data segments between endpoints on a network, including segmentation, acknowledgment, and multiplexing.
3
Structuring and managing addressing, routing, and traffic control for all endpoints on the network.
2
Transmission of data frames between two nodes connected by a Physical layer.
1
Sending and receiving of bitstreams over the medium.
The OSI model breaks down all the necessary functions to send a data packet over a network between two hosts. In the late 1980s and early 1990s, it lost out to TCP/IP as the standard adopted by the DOD and all other major players in networking. The standard defined in ISO 7498 gives a brief glimpse into the implementation details that were considered by most at the time to be complicated, inefficient, and to an extent unimplementable. The OSI model at a high level still allows those learning networking to comprehend the basic concepts and challenges in networking. In addition, these terms and functions are used in the TCP/IP model covered in the next section and ultimately in Kubernetes abstractions. Kubernetes services break out each function depending on the layer it is ope[[rating at, for example, a layer 3 IP address or a layer 4 port; you will learn more about that in Chapter 4. Next, we will do a deep dive into the TCP/IP suite with an example walk-through.
TCP/IP creates a heterogeneous network with open protocols that are independent of the ope[[rating system and architectural differences. Whether the hosts are running Windows, Linux, or another OS, TCP/IP allows them to communicate; TCP/IP does not care if you are running Apache or Nginx for your web server at the Application layer. The separation of responsibilities similar to the OSI model makes that possible. In Figure 1-3, we compare the OSI model to TCP/IP.
Figure 1-3. OSI model compared to TCP/IP
Here we expand on the differences between the OSI model and the TCP/IP:
In TCP/IP, the Application layer comprises the communications protocols used in process-to-process communications across an IP network. The Application layer standardizes communication and depends upon the underlying Transport layer protocols to establish the host-to-host data transfer. The lower Transport layer also manages the data exchange in network communications. Applications at this layer are defined in RFCs; in this book, we will continue to use HTTP, RFC 7231 as our example for the Application layer.
TCP and UDP are the primary protocols of the Transport layer that provide host-to-host communication services for applications. Transport protocols are responsible for connection-oriented communication, reliability, flow control, and multiplexing. In TCP, the window size manages flow control, while UDP does not manage the congestion flow and is considered unreliable; you’ll learn more about that in “UDP”. Each port identifies the host process responsible for processing the information from the network communication. HTTP uses the well-known port 80 for nonsecure communication and 443 for secure communication. Each port on the server identifies its traffic, and the sender generates a random port locally to identify itself. The governing body that manages port number assignments is the Internet Assigned Number Authority (IANA); there are 65,535 ports.
The Internet, or Network layer, is responsible for transmitting data between networks. For an outgoing packet, it selects the next-hop host and transmits it to that host by passing it to the appropriate link-layer. Once the packet is received by the destination, the Internet layer will pass the packet payload up to the appropriate Transport layer protocol.
IP provides the fragmentation or defragmentation of packets based on the maximum transmission unit (MTU); this is the maximum size of the IP packet. IP makes no guarantees about packets’ proper arrival. Since packet delivery across diverse networks is inherently unreliable and failure-prone, that burden is with the endpoints of a communication path, rather than on the network. The function of providing service reliability is in the Transport layer. A checksum ensures that the information in a received packet is accurate, but this layer does not validate data integrity. The IP address identifies packets on the network.
The Link layer in the TCP/IP model comprises networking protocols that operate only on the local network that a host connects to. Packets are not routed to nonlocal networks; that is the Internet layer’s role. Ethernet is the dominant protocol at this layer, and hosts are identified by the link-layer address or commonly their Media Access Control addresses on their network interface cards. Once determined by the host using Address Resolution Protocol 9 (ARP), data sent off the local network is processed by the Internet layer. This layer also includes protocols for moving packets between two Internet layer hosts.
The Physical layer defines the components of the hardware to use for the network. For example, the Physical network layer stipulates the physical characteristics of the communications media. The Physical layer of TCP/IP details hardware standards such as IEEE 802.3, the specification for Ethernet network media. Several interpretations of RFC 1122 for the Physical layer are included with the other layers; we have added this for completeness.
Throughout this book, we will use the minimal Golang web server (also called Go) from Example 1-1 to show various levels of networking components from tcpdump, a Linux syscall, to show how Kubernetes abstracts the syscalls. This section will use it to demonstrate what is happening at the Application, Transport, Network, and Data Link layers.
As mentioned, Application is the highest layer in the TCP/IP stack; it is where the user interacts with data before it gets sent over the network. In our example walk-through, we are going to use Hypertext Transfer Protocol (HTTP) and a simple HTTP transaction to demonstrate what happens at each layer in the TCP/IP stack.
HTTP is responsible for sending and receiving Hypertext Markup Language (HTML) documents—you know, a web page. A vast majority of what we see and do on the internet is over HTTP: Amazon purchases, Reddit posts, and tweets all use HTTP. A client will make an HTTP request to our minimal Golang web server from Example 1-1, and it will send an HTTP response with “Hello” text. The web server runs locally in an Ubuntu virtual machine to test the full TCP/IP stack.
See the example code repository for full instructions.
Example 1-1. Minimal web server in Go
package main import ( “fmt” “net/http” ) func hello(w http.ResponseWriter, _ *http.Request) { fmt.Fprintf(w, “Hello”) } func main() { http.HandleFunc(“/”, hello) http.ListenAndServe(“0.0.0.0:8080”, nil) }
In our Ubuntu virtual machine we need to start our minimal web server, or if you have Golang installed locally, you can just run this:
go run web-server.go
Let’s break down the request for each layer of the TPC/IP stack.
cURL is the requesting client for our HTTP request example. Generally, for a web page, the client would be a web browser, but we’re using cURL to simplify and show the command line.
cURL is meant for uploading and downloading data specified with a URL. It is a client-side program (the c) to request data from a URL and return the response.
In Example 1-2, we can see each part of the HTTP request that the cURL client is making and the response. Let’s review what all those options and outputs are.
Example 1-2. Client request
○ → curl localhost:8080 -vvv * Trying ::1…
- TCP_NODELAY set * Connected to localhost (::1) port 8080 > GET / HTTP/1.1 > Host: localhost:8080 > User-Agent: curl/7.64.1 > Accept: */* > < HTTP/1.1 200 OK < Date: Sat, 25 Jul 2020 14:57:46 GMT < Content-Length: 5 < Content-Type: text/plain; charset=utf-8 < * Connection #0 to host localhost left intact Hello* Closing connection 0
curl localhost:8080 -vvv: This is the curl command that opens a connection to the locally running web server, localhost on TCP port 8080. -vvv sets the verbosity of the output so we can see everything happening with the request. Also, TCP_NODELAY instructs the TCP connection to send the data without delay, one of many options available to the client to set.
Connected to localhost (::1) port 8080: It worked! cURL connected to the web server on localhost and over port 8080.
Get / HTTP/1.1: HTTP has several methods for retrieving or updating information. In our request, we are performing an HTTP GET to retrieve our “Hello” response. The forward slash is the next part, a Uniform Resource Locator (URL), which indicates where we are sending the client request to the server. The last section of this header is the version of HTTP the server is using, 1.1.
Host: localhost:8080: HTTP has several options for sending information about the request. In our request, the cURL process has set the HTTP Host header. The client and server can transmit information with an HTTP request or response. An HTTP header contains its name followed by a colon (:) and then its value.
User-Agent: cURL/7.64.1: The user agent is a string that indicates the computer program making the HTTP request on behalf of the end user; it is cURL in our context. This string often identifies the browser, its version number, and its host ope[[rating system.
Accept: */*: This header instructs the web server what content types the client understands. Table 1-3 shows examples of common content types that can be sent.
HTTP/1.1 200 OK: This is the server response to our request. The server responds with the HTTP version and the response status code. There are several possible responses from the server. A status code of 200 indicates the response was successful. 1XX means informational, 2XX means successful, 3XX means redirects, 4XX responses indicate there are issues with the requests, and 5XX generally refers to issues from the server.
Date: Sat, July 25, 2020, 14:57:46 GMT: The Date header field represents the date and time at which the message originated. The sender generates the value as the approximate date and time of message generation.
Content-Length: 5: The Content-Length header indicates the size of the message body, in bytes, sent to the recipient; in our case, the message is 5 bytes.
Content-Type: text/plain; charset=utf-8: The Content-Type entity header is used to indicate the resource’s media type. Our response is indicating that it is returning a plain-text file that is UTF-8 encoded.
- Closing connection 0: This prints out the response from our web server and closes out the HTTP connection.
Table 1-3. Common content types for HTTP data Type Description
Any kind of binary data that doesn’t fall explicitly into one of the other types. Common examples include application/json, application/pdf, application/pkcs8, and application/zip.
audio
Audio or music data. Examples include audio/mpeg and audio/vorbis.
font
Font/typeface data. Common examples include font/woff, font/ttf, and font/otf.
Image or graphical data including both bitmap and vector such as animated GIF or APNG. Common examples are image/jpg, image/png, and image/svg+xml.
Model data for a 3D object or scene. Examples include model/3mf and model/vrml.
Text-only data including human-readable content, source code, or text data. Examples include text/plain, text/csv, and text/html.
video
Video data or files, such as video/mp4.
This is a simplistic view that happens with every HTTP request. Today, a single web page makes an exorbitant number of requests with one load of a page, and in just a matter of seconds! This is a brief example for cluster administrators of how HTTP (and for that matter, the other seven layers’ applications) operate. We will continue to build our knowledge of how this request is completed at each layer of the TCP/IP stack and then how Kubernetes completes those same requests. All this data is formatted and options are set at layer 7, but the real heavy lifting is done at the lower layers of the TCP/IP stack, which we will go over in the next sections.
The Transport layer protocols are responsible for connection-oriented communication, reliability, flow control, and multiplexing; this is mostly true of TCP. We’ll describe the differences in the following sections. Our Golang web server is a layer 7 application using HTTP; the Transport layer that HTTP relies on is TCP.
As already mentioned, TCP is a connection-oriented, reliable protocol, and it provides flow control and multiplexing. TCP is considered connection-oriented because it manages the connection state through the life cycle of the connection. In TCP, the window size manages flow control, unlike UDP, which does not manage the congestion flow. In addition, UDP is unreliable, and data may arrive out of sequence. Each port identifies the host process responsible for processing the information from the network communication. TCP is known as a host-to-host layer protocol. To identify the process on the host responsible for the connection, TCP identifies the segments with a 16-bit port number. HTTP servers use the well-known port of 80 for nonsecure communication and 443 for secure communication using Transport Layer Security (TLS). Clients requesting a new connection create a source port local in the range of 0–65534.
To understand how TCP performs multiplexing, let’s review a simple HTML page retrieval:
In a web browser, type in a web page address.
The browser opens a connection to transfer the page.
The browser opens connections for each image on the page.
The browser opens another connection for the external CSS.
Each of these connections uses a different set of virtual ports.
All the page’s assets download simultaneously.
The browser reconstructs the page.
Let’s walk through how TCP manages multiplexing with the information provided in the TCP segment headers:
This identifies the sending port.
Destination port (16 bits)
This identifies the receiving port.
If the SYN flag is set, this is the initial sequence number. The sequence number of the first data byte and the acknowledged number in the corresponding ACK is this sequence number plus 1. It is also used to reassemble data if it arrives out of order.
Acknowledgment number (32 bits)
If the ACK flag is set, then this field’s value is the next sequence number of the ACK the sender is expecting. This acknowledges receipt of all preceding bytes (if any). Each end’s first ACK acknowledges the other end’s initial sequence number itself, but no data has been sent.
This specifies the size of the TCP header in 32-bit words.
This is for future use and should be set to zero.
There are nine 1-bit fields defined for the TCP header:
NS–ECN-nonce: Concealment protection.
CWR: Congestion Window Reduced; the sender reduced its sending rate.
ECE: ECN Echo; the sender received an earlier congestion notification.
URG: Urgent; the Urgent Pointer field is valid, but this is rarely used.
ACK: Acknowledgment; the Acknowledgment Number field is valid and is always on after a connection is established.
PSH: Push; the receiver should pass this data to the application as soon as possible.
RST: Reset the connection or connection abort, usually because of an error.
SYN: Synchronize sequence numbers to initiate a connection.
FIN: The sender of the segment is finished sending data to its peer.
The NS bit field is further explained in RFC 3540, “Robust Explicit Congestion Notification (ECN) Signaling with Nonces.” This specification describes an optional addition to ECN improving robustness against malicious or accidental concealment of marked packets.
This is the size of the receive window.
The checksum field is used for error checking of the TCP header.
This is an offset from the sequence number indicating the last urgent data byte.
Variable 0–320 bits, in units of 32 bits.
Padding
The TCP header padding is used to ensure that the TCP header ends, and data begins on a 32-bit boundary.
This is the piece of application data being sent in this segment.
In Figure 1-4, we can see all the TCP segment headers that provide metadata about the TCP streams.
Figure 1-4. TCP segment header
These fields help manage the flow of data between two systems. Figure 1-5 shows how each step of the TCP/IP stack sends data from one application on one host, through a network communicating at layers 1 and 2, to get data to the destination host.
Index
A
Accept header, HTTP request, HTTP-HTTP
ACK flag, TCP, TCP, TCP handshake, tcpdump
acknowledgment number, TCP, TCP, tcpdump
ACR (Azure Container Registry), Deploying an Application to Azure Kubernetes Service, Connecting to and configuring AKS, Deploying the Go web server
Address Resolution Protocol (ARP), TCP/IP, Link Layer-Link Layer
addresses output, Kubernetes, Endpoint Slices
addresses, endpoints and, Endpoints
addresses, IP (see IP (Internet Protocol) addresses)
Advanced Research Projects Agency Network (ARPANET), Networking History
agent, Cilium, Popular CNI Plugins
AGIC (application gateway ingress controller), Azure, Azure load balancer, Application gateway ingress controller
AKS (see Azure Kubernetes Service (AKS))
ALB (see AWS ALB (application load balancer) ingress controller)
allocate-node-cidrs flag, Kubernetes, kube-controller-manager Configuration
Amazon Elastic Kubernetes Service (EKS) (see EKS (Amazon Elastic Kubernetes Service))
Amazon Web Services (AWS) (see AWS (Amazon Web Services))
annotations, Kubernetes, Ingress Controllers and Rules, Service Meshes
API, Kubernetes, Pod Readiness and Probes, NetworkPolicy, Rules, Service Meshes
app command, NetworkPolicy, NetworkPolicy, Selecting Pods, Rules
application deployment - benefits of containers for, Containers, Setting Up Namespaces
challenges of, Applications-Hypervisor, Docker
application gateway ingress controller (AGIC), Azure, Azure load balancer, Application gateway ingress controller
Application layer (L7)with Cilium, eBPF, Popular CNI Plugins, NetworkPolicy Example with Cilium
examples of, OSI Model, TCP/IP
with HTTP, cURL, NetworkPolicy Example with Cilium, Elastic load balancers, Azure load balancer
ingress and, Ingress, Deploy ingress rules, Application gateway ingress controller
load balancers for, LoadBalancer, Azure load balancer
with NetworkPolicy, NetworkPolicy Example with Cilium
of OSI model, OSI Model, TCP/IP
of TCP/IP, TCP/IP, Application-HTTP
application load balancers (ALB) (see AWS ALB (application load balancer) ingress controller)
ARM (Azure Resource Manager), Azure, Network security groups
ARP (Address Resolution Protocol), TCP/IP, Link Layer-Link Layer
ARPANET (Advanced Research Projects Agency Network), Networking History
ASNs (autonomous system numbers), Getting round the network-Getting round the network
attacker strategieswith networking tools, Security Warning
NetworkPolicies and, NetworkPolicy, NetworkPolicy, Rules, Rules
authenticationfor AWS load balancers, Elastic load balancers
for Azure Kubernetes, Deploying an Azure Kubernetes Service cluster
authorization policies, service mesh, Service Meshes
Auto Scaling groups, Amazon EKS, EKS nodes
autonomous system numbers (ASNs), Getting round the network-Getting round the network
availability zones (AZs), Region and availability zones, Security groups, Azure backbone infrastructure-Route tables, Deploying an Azure Kubernetes Service cluster
AWS (Amazon Web Services)App Mesh service mesh in, Service Meshes
AWS networking in (see AWS networking)
AWS VPC CNI in, Container Network Interface, eksctl-AWS VPC CNI
EKS in (see EKS (Amazon Elastic Kubernetes Service))
overview of, Amazon Web Services
AWS Account ID, Deploy ALB ingress and verify
AWS ALB (application load balancer) ingress controllerexample deployment of, AWS ALB ingress controller-Cleanup
overview of, Elastic load balancers, AWS VPC CNI-AWS ALB ingress controller
AWS Managed Service NAT gateway (NAT GW), Network address translation] [[devices, EKS nodes
AWS networking, AWS Network Services-Elastic load balancersAWS ALB ingress controller in, AWS Network Services, Elastic load balancers, AWS VPC CNI-Cleanup
with AZs and geographic regions, Region and availability zones, Security groups
elastic load balancer in, Elastic load balancers-Elastic load balancers
ENIs and EIPs in, Elastic network interface-Elastic IP address
internet gateway in, Internet gateway
NAT devices in, Network address translation] [[devices
route tables in, Routing tables-Elastic network interface, Network address translation] [[devices
security controls in, Security controls-Network access control lists
subnets in, Subnet-Elastic network interface, Elastic IP address-Network access control lists, eksctl, Deploy EKS cluster
AZs (availability zones), Region and availability zones, Security groups, Azure backbone infrastructure-Route tables, Deploying an Azure Kubernetes Service cluster
Azure, Azure-AKS conclusionAKS (Azure Kubernetes Service) in, Azure Kubernetes Service-AKS conclusion
communications external to, Communication outside the virtual network
deployment models for, Azure, Network security groups
load balancing in, Azure load balancer-Azure load balancer
overview of, Azure-Azure backbone infrastructure
Vnet networking in, Azure Networking Services-Communication outside the virtual network
Azure Active Directory service principals, Deploying an Application to Azure Kubernetes Service, Deploying an Azure Kubernetes Service cluster
Azure Container Registry (ACR), Deploying an Application to Azure Kubernetes Service, Connecting to and configuring AKS, Deploying the Go web server
Azure Geography, Azure backbone infrastructure
Azure Kubernetes Service (AKS), Azure Kubernetes Service-AKS conclusionapplication gateway ingress controller in, Azure load balancer, Application gateway ingress controller
authentication page in, Deploying an Azure Kubernetes Service cluster
create page in, Deploying an Azure Kubernetes Service cluster-Deploying an Azure Kubernetes Service cluster
example deployment with, Deploying an Application to Azure Kubernetes Service-AKS conclusion
overview of, Azure Kubernetes Service-Azure Kubernetes Service
validation page in, Deploying an Azure Kubernetes Service cluster
Azure networking services (Vnet), Azure Networking Services-Communication outside the virtual networkcommunications external to, Communication outside the virtual network
public/private IPs in, Public and private IPs, Communication outside the virtual network
regions of, Azure backbone infrastructure-Route tables, Communication outside the virtual network, Deploying an Azure Kubernetes Service cluster
route tables in, Route tables-Route tables
security with, Route tables, Network security groups-Communication outside the virtual network
subnets in, Subnets, Route tables, Communication outside the virtual network
Azure Resource Manager (ARM), Azure, Network security groups
B
backend destinationsingress rules and, Ingress Controllers and Rules, Deploy ingress rules, Cleanup
iptables and, Practical iptables, IPVS, iptables Mode
for load balancing, Azure load balancer-Azure load balancer
requests to, Verify LoadBalancer services for Golang web server
base image of containers, Containers
Belamaric, John, DNS
Berkeley Packet Filter (BPF), eBPF
binaries, CNI plugins and, The CNI Specification, The IPAM Interface
Border Gateway Protocol (BGP), Getting round the network-Getting round the network, Container Network Interface, Popular CNI Plugins
BPF (Berkeley Packet Filter), eBPF
br0 bridge device, creating, The Bridge Interface
brctl command, Linux, The Bridge Interface
bridge container network mode, Container Network Basics, Docker Networking Model
bridge interface, The Bridge Interface-The Bridge Interface, Setting Up Namespaces, Setting Up Namespaces
bridge networking, Docker, Container Network Basics-Container Network Basics
busybox containers, Container Network Basics-Container Network Basics
C
caching system, container, Container Connectivity
Calico CNI plugin, Container Network Interface, Popular CNI Plugins, NetworkPolicy
cert-manager, Ingress Controllers and Rules
certificates and keyscURL for, cURL
with ingress, Ingress Controllers and Rules
cgroups (control groups), Containers, Container Primitives-Control Groups, Namespaces
chains, iptablesexecution of, iptables, iptables chains-Subchains
iptables -L for showing, Practical iptables
Netfilter hooks and, Netfilter, iptables, iptables chains
checksum, TCP/IP, TCP, tcpdump, UDP, Internet Protocol, ICMP
CIDR (Classless Inter-Domain Routing) rangesfor Amazon EKS, EKS nodes, eksctl
for AWS network services, Virtual private cloud, Subnet, eksctl
for Azure Vnet, Azure Networking Services
for Google GCP, Virtual private cloud
with kube-controller-manager, kube-controller-manager Configuration
in Kubernetes pods, Flat Networks-Flat Networks, kube-controller-manager Configuration
with NetworkPolicy, Rules
overview of, Internet Protocol-Internet Protocol
Ciliumas CNI plugin, Container Network Interface, Popular CNI Plugins-Popular CNI Plugins, NetworkPolicy
connectivity check for, Popular CNI Plugins-Popular CNI Plugins
eBPF for, eBPF, Container Network Interface
example deployment of, Popular CNI Plugins-Popular CNI Plugins
NetworkPolicy example with, NetworkPolicy Example with Cilium-NetworkPolicy Example with Cilium
circuit breaking, service meshes for, Service Meshes, Service Meshes
class, ingress selection of, Ingress Controllers and Rules
classful IP addressing, Internet Protocol
classic load balancers, Elastic load balancers
Classless Inter-Domain Routing (CIDR) (see CIDR (Classless Inter-Domain Routing) ranges)
CLI (client/command-line interface)in Azure, Connecting to and configuring AKS
in Cilium, Popular CNI Plugins
in Docker, Docker, Container Connectivity, Deploying an Application to Azure Kubernetes Service
eksctl as, AWS Network Services, Amazon Elastic Kubernetes Service
in Linkerd, Service Meshes-Service Meshes, Service Meshes, Service Meshes
client requestswith HTTP, HTTP-HTTP, Revisiting Our Web Server-Revisiting Our Web Server, Basics, Basics-Basics
with TCL encryption, TLS-TLS
with TCP handshake, TCP handshake-TCP handshake
CLOSED connection state, TCP, TCP handshake
cloud networking and Kuberneteswith AWS (see AWS (Amazon Web Services))
CNIs for, Container Network Interface, Kubernetes and Cloud Networking, eksctl-AWS VPC CNI, Azure CNI
flat layout for, Flat Networks
with Google Compute Cloud (GCP), Google Compute Cloud (GCP)-GCP GKE nodes
LoadBalancer services and, LoadBalancer, LoadBalancer, Ingress Controllers and Rules
summary of options for, Conclusion
cluster administratorsAWS EKS and, Amazon Elastic Kubernetes Service
AWS VPC networks and, Container Network Interface
CNI selection by, CNI Plugins, NetworkPolicy Example with Cilium
NetworkPolicies and, Rules
VPC decisions by, EKS mode, eksctl
cluster modes, GKE, GCP GKE nodes-GCP GKE nodes
cluster networking, Conclusion(see also Kubernetes networking abstractions)
in cloud, EKS nodes, GCP GKE nodes, Azure Kubernetes Service, Deploying an Azure Kubernetes Service cluster-AKS conclusion
complexity of IP addresses with, The Kubernetes Networking Model
data flow of, Pod Readiness and Probes
default-open status of, The Kubernetes Networking Model
diagnostic tools for, Services Conclusion
with dual stacks, IPv4/IPv6 Dual Stack-Conclusion
ExternalName service in, ExternalName Service-ExternalName Service
with flat networks, Flat Networks-Flat Networks, CNI Plugins
with island networks, Island Networks
with isolated networks, Isolated Networks-Isolated Networks
L3 requirement for, Node and Pod Network Layout
local deployment for, Popular CNI Plugins-Popular CNI Plugins
multihost, The Kubernetes Networking Model
with overlay networks, CNI Plugins
cluster-CIDR flag, Kubernetes, kube-controller-manager Configuration
ClusterFirstWithHostNet, dnsPolicy, DNS
ClusterIP service, Kubernetes, kube-proxy, ClusterIP-Headless, Deploy ingress rules, Deploy test application
clusterip-service command, AWS EKS, Deploy test application
CMD instruction, Dockerfile, Container Connectivity
CNI (Container Network Interface)AWS VPC CNI as, Container Network Interface, eksctl-AWS VPC CNI
Cilium as, Popular CNI Plugins-Popular CNI Plugins
cloud networking with, Container Network Interface, Kubernetes and Cloud Networking, eksctl-AWS VPC CNI, Azure CNI
Kubelet and, The Kubelet, Pod Readiness and Probes
Kubernetes plugins with, Container Network Interface, The Kubernetes Networking Model, Flat Networks, CNI Plugins-Popular CNI Plugins, NetworkPolicy, AWS VPC CNI
network models for, CNI Plugins
NetworkPolicy and, NetworkPolicy, NetworkPolicy Example with Cilium
overview of, Overlay Networking, The CNI Specification
projects using, Container Network Interface-Container to Container Separate Hosts
specifications of, The CNI Specification
standardization with, Setting Up Namespaces, The Kubernetes Networking Model, The Kubernetes Networking Model
CNM (container networking model), Docker Networking Model-Overlay Networking
command-line interface (CLI) (see CLI (client/command-line interface))
communicationApplication layer for, TCP/IP
host-to-host, Overlay Networking-Overlay Networking
networking challenges with, Kubernetes Networking Introduction
pod-to-pod restrictions of (see NetworkPolicies, Kubernetes)
resiliency of, Service Meshes
service-to-service, Service Meshes
Community ingress Nginx, Ingress Controllers and Rules-Deploy ingress rules
conditionType attribute, Kubernetes, Pod Readiness and Probes
configure-cloud-routes flag, Kubernetes, kube-controller-manager Configuration
connection fan-out with iptables, Practical iptables
connection tracking, Conntrack-Conntrack
Conntrack, Linux, Conntrack-Conntrack
Consul service mesh, Service Meshes
container ID, Container Network Basics, Container Connectivity, Container to Container
container networking model (CNM), Docker Networking Model-Overlay Networking
container orchestration, Containers
container runtime, Containers, The Kubelet, Pod Readiness and Probes
container-native cluster, GKE, GCP GKE nodes-GCP GKE nodes
containerd service, containerd, Docker
containerd-shim, containerd, Docker
containersas abstraction, Introduction to Containers
addresses for, Docker Networking Model
benefits of, Containers, Setting Up Namespaces, Container Network Basics
cgroups (control groups) and, Containers, Container Primitives-Control Groups, Namespaces
creating, Setting Up Namespaces-Setting Up Namespaces
Docker (see Docker networking model)
functionality of, Containers-OCI
on global systems, Overlay Networking-Overlay Networking, Container to Container Separate Hosts
history of, Container Networking Basics-Containers
initiatives for, OCI-CRI-O
layers in, Container Connectivity
on local systems, Docker Networking Model, Container to Container-Container to Container
namespaces and (see namespaces, network)
network modes with, Container Network Basics-Container Network Basics, Docker Networking Model
networking scenarios with, Container Connectivity-Container to Container Separate Hosts
OCI specifications for, OCI
runC routines for, Containers, OCI, Docker, Container Primitives, Control Groups
runtimes of, Containers-OCI, containerd-CRI-O
terminology for, Containers-Containers
Content-Length header, HTTP request, HTTP-HTTP
Content-Type header, HTTP request, HTTP-HTTP
control plane, Kubernetesof Amazon EKS, EKS mode, EKS mode, eksctl
with service meshes, Service Meshes
control-plane-version, Service Meshes
CoreOS CNI, Overlay Networking
corporate networks with ENIs, Elastic network interface
CRDs (custom resource definitions), The Kubernetes Networking Model, The Kubernetes Networking Model, Deploy ALB ingress and verify
create page, AKS, Deploying an Azure Kubernetes Service cluster-Deploying an Azure Kubernetes Service cluster
CRI runtime, CRI-O, The Kubelet, Pod Readiness and Probes
cURL/curl tool client requests with, HTTP, tcpdump, Revisiting Our Web Server, cURL, Deploying the Go web server
for data transfer, cURL-cURL
localhost command with, HTTP, NetworkPolicy Example with Cilium, Deploy ingress rules
for service meshes, Service Meshes
for testing ingresses, Deploy ingress rules
custom container network mode, Container Network Basics, Docker Networking Model
custom resource definitions (CRDs), The Kubernetes Networking Model, The Kubernetes Networking Model, Deploy ALB ingress and verify
custom route table, VPC, Routing tables, Internet gateway
D
datahost-to-host transfer of, OSI Model, TCP/IP, TCP, Overlay Networking-Overlay Networking
HTTP content types of, HTTP
tcpdump transmissions of, tcpdump
Data Link layer (see Link layer (L2))
database, Postgres, NetworkPolicy Example with Cilium, NetworkPolicy Example with Cilium, StatefulSets, Deploy test application
Date header, HTTP request, HTTP-HTTP
debugging, tcpdump, Basics, Network Troubleshooting Tools-cURL, Services Conclusion
deployment resource, Kubernetes, The Kubernetes Networking Modelendpoint controller and, Endpoints
pods and, Pod Readiness and Probes
versus StatefulSets, StatefulSets
destination address, IP header, Internet Protocol
destination hashing (dh), IPVS mode, IPVS
destination port identification, TCP, UDP
destination values, routing, Conntrack, Routing
developers, Applications-Hypervisor, Docker, Setting Up Namespaces, Conclusion, Service Meshes, Service Meshes, Security controls, Network access control lists, Amazon Elastic Kubernetes Service
Differentiated Services Code Point (DSCP), Internet Protocol
dig DNS lookup tool, dig-telnet
DNAT (destination NAT), Conntrack, iptables chains, iptables rules, Practical iptables
DNS (Domain Name System)dig lookup tool for, dig-telnet
ExternalService with, ExternalName Service-ExternalName Service
headless services with, Headless, ExternalName Service
in Kubernetes, DNS-DNS
StatefulSets and, StatefulSets
dnsPolicy, Kubernetes, DNS-DNS
dnsutils, Kuberneteswith AWS EKS deployment, Deploy test application-Verify LoadBalancer services for Golang web server
as debugging tool, Services Conclusion
image, Container Connectivity, Container to Container, StatefulSets, Headless
loopback address, Container to Container
with pod for NetworkPolicy, NetworkPolicy Example with Cilium-NetworkPolicy Example with Cilium, NetworkPolicy Example with Cilium
with StatefulSets, StatefulSets
Docker container technologyarchitecture and components of, Docker-CRI-O
bridge networking in, Container Network Basics-Container Network Basics
container-to-container connectivity with, Container Connectivity-Container to Container Separate Hosts
with Dockerfile, Container Connectivity-Container Connectivity
host networking in, Container Network Basics-Container Network Basics
images from, Popular CNI Plugins, LoadBalancer, Deploying an Application to Azure Kubernetes Service
installing, Container Network Basics-Container Network Basics
KIND network on, LoadBalancer
limitations of private networks of, Kubernetes Networking Introduction
Macvlan networks and, Container Network Basics
network types in, Container Network Basics-Docker Networking Model
networking model in, Docker Networking Model-Overlay Networking
OCI specifications and, OCI
runC architecture for, OCI
docker0 bridge interface, Container Network Basics, Container Network Basics, Docker Networking Model, Container to Container
Dockerfile, building image in, Container Connectivity-Container Connectivity
drivers, local and global, Docker Networking Model
DSCP (Differentiated Services Code Point), Internet Protocol
E
eBPF (Berkeley Packet Filtering), eBPF-eBPFKubernetes and, eBPF
Linux kernel operations with, eBPF-eBPF, Popular CNI Plugins
EC2 instances, Amazon EKS, EKS nodes, eksctl, AWS VPC CNI
echo requests, ICMP, ICMP, ping
ECN (Robust Explicit Congestion Notification) Signaling with Nonces, TCP
edge association, VPC, Routing tables
egress, Node and Pod Network Layout, Selecting Pods, Rules-Rules
EIP (elastic IP addresses), Elastic IP address
EKS (Amazon Elastic Kubernetes Service), Amazon Elastic Kubernetes Service-CleanupAWS VPC CNI in, eksctl-AWS VPC CNI
communication path of, EKS mode
eksctl in, AWS Network Services, Amazon Elastic Kubernetes Service, eksctl-eksctl
example deployment with, AWS ALB ingress controller-Cleanup
nodes in, EKS nodes, eksctl, eksctl-AWS VPC CNI
overview of, Amazon Elastic Kubernetes Service
public/private network modes in, EKS mode-EKS mode
scaling with, Amazon Elastic Kubernetes Service, AWS ALB ingress controller
security with, EKS mode, EKS mode, eksctl
EKS Pod Networking, information for, AWS VPC CNI
eksctl tool, AWS, AWS Network Services, Amazon Elastic Kubernetes Service, eksctl-eksctl, Deploy EKS cluster
elastic IP addresses (EIP), Elastic IP address
elastic load balancers, Elastic load balancers-Elastic load balancers
elastic network interface (ENI) (see ENI (elastic network interface))
encryption with TCL, TLS-TLS
end-to-end encryption, Service Meshes
Endpoints objects, Endpoints, Endpoints, Endpoint Slices, Endpoint Slices
endpoints, Docker, Docker Networking Model, Overlay Networking
endpoints, Kubernetes, Endpoints-Endpointswith Amazon EKS, EKS mode, Deploy test application
versus endpointslices, Endpoint Slices-Endpoint Slices
headless services with, Headless-Headless
with kube-proxy, kube-proxy
local versus cluster routing to, NodePort
readiness probes and, Pod Readiness and Probes
as service discovery tool, Endpoints-Endpoints
troubleshooting tips for, Services Conclusion
endpointslices, Kubernetes, Endpoint Slices-Endpoint Slicesversus EndPoints, Endpoint Slices-Endpoint Slices
with kube-proxy, kube-proxy, Endpoint Slices
readiness probes and, Pod Readiness and Probes
ENI (elastic network interface), Elastic network interface-Elastic IP address, AWS VPC CNI(see also EKS (Amazon Elastic Kubernetes Service))
eth0 device and bridge interface, The Bridge Interface-The Bridge Interface, Setting Up Namespaces
Ethernetdemultiplexing example of, Link Layer
header and footers of, Link Layer
in host networking, Docker, Container Network Basics
in Link layer, TCP/IP, Link Layer-Link Layer
protocols, Link Layer-Link Layer
veth pairs and, The Bridge Interface
VLAN identifiers for, Overlay Networking
external load balancer controllers, Ingress Controllers and Rules
ExternalName Service, Kubernetes, ExternalName Service-ExternalName Service
externalTrafficPolicy routing, NodePort
extraPortMappings for ingress controller, Ingress Controllers and Rules