Add a blog post about Kubernetes Networking Architecture

[xPetersue]

Hi! I have been planning to elaborate on the Kubernetes Networking Architecture for ages. As far as I know, nobody has explained this topic clearly with both a good command of networking and Linux. Here, with my 10 years of DevOps work experience and double CCIE certification in the fields of networking and cybersecurity, I have put in half a year's worth of hard work to provide a detailed explanation. You can find the entire article at the following link.
https://github.com/kubernetes/website/pull/43914/files

Feel free to leave comments and contribute to the PR (Pull Request) process. I need all of your help for this initial endeavour. Cheers!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign onlydole for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• content/en/blog/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[netlify]

✅ Pull request preview available for checking

Name	Link
🔨 Latest commit
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-io-main-staging/deploys/659abfc6a11f679c96294615
😎 Deploy Preview	https://deploy-preview-43914--kubernetes-io-main-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[xPetersue]

This is my first time uploading an article here, and it includes some images. However, I'm unsure about where to place these images. Can anyone offer some guidance? I would really appreciate it.

[xPetersue]

All images are ready. Please have a review. Thanks!

[dipesh-rawat]

@xPetersue Thanks for your contribution. Looks like the blog content is missing some front matter in markdown used by Hugo and there are some formatting issue.

Refer to the 'Submitting blog posts and case studies' page: https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/ for guidance and feel free to seek assistance in the #sig-docs-blog channel on the Kubernetes Slack workspace.

[dipesh-rawat]

/retitle [WIP] Add a blog post about Kubernetes Networking Architecture

[xPetersue]

@xPetersue Thanks for your contribution. Looks like the blog content is missing some front matter in markdown used by Hugo and there are some formatting issue.

Refer to the 'Submitting blog posts and case studies' page: https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/ for guidance and feel free to seek assistance in the #sig-docs-blog channel on the Kubernetes Slack workspace.

@dipesh-rawat Thanks for sharing this with me. It is really helpful. I have modified this blog's format as requested. Please have a review, hope it is ok this time.

[xPetersue]

Could you help me proceed with this PR to accelerate its publication? If anyone could share the next steps in the process, I would greatly appreciate it.

[salaboy]

I will try to review the content of this PR during the weekend and provide advice. Initially I think that the sections:

• What is Kubernetes and its
  purpose?
• Docker vs Docker Swarm
• Architecture: Docker vs
  Kubernetes
• Basic Kubernetes concepts and
  terms

Can be omitted as this is the Kubernetes blog already, people should be familiar with those topics.

[xPetersue]

I will try to review the content of this PR during the weekend and provide advice. Initially I think that the sections:

• What is Kubernetes and its
  purpose?
• Docker vs Docker Swarm
• Architecture: Docker vs
  Kubernetes
• Basic Kubernetes concepts and
  terms

Can be omitted as this is the Kubernetes blog already, people should be familiar with those topics.

@salaboy Thanks for your suggestion. I have removed the four parts as you mentioned above. Please check, and thanks for investing time to review this blog.

[salaboy]

@xPetersue my other recommendation would be to add a short description of the blog post here in the initial comment but remove all the content from here, and just leave that in the file that is changed. The PR content will not be evaluated based on what we see on the comments here, but only based on what is on the file that you are submitting as part of this PR. So for example if you look at the file, the sections that you mention that you have removed are still there: https://github.com/kubernetes/website/pull/43914/files#diff-4752d92c319d8fff5838e250ba4a24e56593b25f3aa5d6611fef0bc76d15b54eR4

[xPetersue]

@xPetersue my other recommendation would be to add a short description of the blog post here in the initial comment but remove all the content from here, and just leave that in the file that is changed. The PR content will not be evaluated based on what we see on the comments here, but only based on what is on the file that you are submitting as part of this PR. So for example if you look at the file, the sections that you mention that you have removed are still there: https://github.com/kubernetes/website/pull/43914/files#diff-4752d92c319d8fff5838e250ba4a24e56593b25f3aa5d6611fef0bc76d15b54eR4

@salaboy I have modified everything you suggested here. Please check. Thanks for your contribution. Really appreciate it.

[Gauravpadam]

Thanks for this insightful article @xPetersue!

I've added some initial reviews to move the progress on this PR

Here are some observation:

• We need to correct the directory structure,

  We follow the structure content/en/blog/_posts/<blog_date>-<blog_name>/index.md
  'index.md' should contain this article, and the images can be a part of this same directory

• The images are generally in .svg format

• I've addressed some conventions in the suggestions

I'll be happy to complete the review post these amendments

[xPetersue]

Thanks,

Let's aim for publication by 7th January

Here's some more feedback:

• figure shortcodes can have a caption and alt property; Please use them wherever applicable
• Please provide a caption for the tables using <caption> with display set to none
• We're good to update the directory name with the actual publication date

@Gauravpadam Thank you very much for your assistance. I have resolved all of your comments. Please take a moment to review the changes. I truly appreciate your help. We are nearly there. Cheers!

[sftim]

This PR is marked as a work in progress. Would you like it reviewed @xPetersue?

/hold
pending assignment of a publication date

[xPetersue]

This PR is marked as a work in progress. Would you like it reviewed @xPetersue?

/hold pending assignment of a publication date

@sftim Yes, please mark it reviewed. Thanks!

[sftim]

You can make that change yourself @xPetersue - I'll do that now, anyway

/retitle Add a blog post about Kubernetes Networking Architecture

[david-martin]

@xPetersue I had a read of your blog post and found it interesting, and very comprehensive.
The read time was ~30-40 mins though.
I wonder if it could be brought down to a shorter time and still keep the most relevant and interesting pieces (from a kubernetes networking point of view).

I would go as far as to say there could be the makings of 3 or more different posts in this
(kube networking from the ground up, how docker & docker swarm differs from kubernetes, linux networking 101, setting up an ingress controller, how kubernetes layers on linux, in general)
though i'll focus on the kubernetes networking 1 for now :)

As I was reading through the first section on different interface types, I started wondering how all of these are relevant to kubernetes. Maybe this section could be slimmed down to have info on the most relevant interface type for kubernetes?
That way, the blog post could be about building from the ground up how kubernetes networking works.
An example command or 2 is definitely helpful. Maybe they could be given in the context of a kubernetes cluster so they could be more meaningful to the reader?

The gifs for showing pod to pod comms etc.. were useful in showing the layers traffic goes through.
This was the most interesting piece in my opinion.
I'd love to see some detail on what happens at the different numbered steps in those gifs, and how it relates to the actual interfaces (and even some cmds that show those interfaces)
That would make for a great goal of the blog post.

To keep the post on point, I'd even go as far as removing these sections (definitely useful in the right context though)

• containers runtime
• ingress controller setup (an example ingress is fine)
• docker swarm
• the detailed linux networking interface reference (1 or 2 relevant cmd examples is definitely useful in the right kubernetes context)
• the table showing linux networking & kubernetes networking (I don't think this is needed, and also shows non networking stuff)

In general, if the most relevant things to kubernetes networking are kept, with a loose goal of the post to show how kube networking works from the ground up, this would be excellent.

I do have a few other pieces of feedback, but they are more about the style of writing than the content.

• No need to include your credentials/qualifications in the post. I think the blog post content should be convincing enough :)
• I would avoid qualifying statements like this (without references) as it may put off the reader "Most developers are familiar with Docker but don't have the whole perspective of Kubernetes", "Many engineers with years of Linux experience will find this format convenient for understanding..."
• "Routing in Linux is quite simple." statements like this are very subjective. Some may find it simple, some may not, and everything in between. I'd avoid.

[sftim]

The read time was ~30-40 mins though. I wonder if it could be brought down to a shorter time and still keep the most relevant and interesting pieces (from a kubernetes networking point of view).

I would go as far as to say there could be the makings of 3 or more different posts in this

That's a good suggestion. @xPetersue we can help you split this up if that matches what you would like to do.

[xPetersue]

The read time was ~30-40 mins though. I wonder if it could be brought down to a shorter time and still keep the most relevant and interesting pieces (from a kubernetes networking point of view).
I would go as far as to say there could be the makings of 3 or more different posts in this

That's a good suggestion. @xPetersue we can help you split this up if that matches what you would like to do.

@sftim I'm okay with splitting up this blog. However, I can't agree with removing the content. I wrote these sections because they are closely related to each other. As for the ending part, you may consider it impractical, but many people have their own Hamlet. I recommend keeping them. Thank you.

[xPetersue]

@xPetersue I had a read of your blog post and found it interesting, and very comprehensive. The read time was ~30-40 mins though. I wonder if it could be brought down to a shorter time and still keep the most relevant and interesting pieces (from a kubernetes networking point of view).

I would go as far as to say there could be the makings of 3 or more different posts in this (kube networking from the ground up, how docker & docker swarm differs from kubernetes, linux networking 101, setting up an ingress controller, how kubernetes layers on linux, in general) though i'll focus on the kubernetes networking 1 for now :)

As I was reading through the first section on different interface types, I started wondering how all of these are relevant to kubernetes. Maybe this section could be slimmed down to have info on the most relevant interface type for kubernetes? That way, the blog post could be about building from the ground up how kubernetes networking works. An example command or 2 is definitely helpful. Maybe they could be given in the context of a kubernetes cluster so they could be more meaningful to the reader?

The gifs for showing pod to pod comms etc.. were useful in showing the layers traffic goes through. This was the most interesting piece in my opinion. I'd love to see some detail on what happens at the different numbered steps in those gifs, and how it relates to the actual interfaces (and even some cmds that show those interfaces) That would make for a great goal of the blog post.

To keep the post on point, I'd even go as far as removing these sections (definitely useful in the right context though)

• containers runtime
• ingress controller setup (an example ingress is fine)
• docker swarm
• the detailed linux networking interface reference (1 or 2 relevant cmd examples is definitely useful in the right kubernetes context)
• the table showing linux networking & kubernetes networking (I don't think this is needed, and also shows non networking stuff)

In general, if the most relevant things to kubernetes networking are kept, with a loose goal of the post to show how kube networking works from the ground up, this would be excellent.

I do have a few other pieces of feedback, but they are more about the style of writing than the content.

• No need to include your credentials/qualifications in the post. I think the blog post content should be convincing enough :)
• I would avoid qualifying statements like this (without references) as it may put off the reader "Most developers are familiar with Docker but don't have the whole perspective of Kubernetes", "Many engineers with years of Linux experience will find this format convenient for understanding..."
• "Routing in Linux is quite simple." statements like this are very subjective. Some may find it simple, some may not, and everything in between. I'd avoid.

@david-martin Thank you for taking the time to read my blog and provide valuable comments. Here are the responses to your three categories of feedback.

1. I apologize for not agreeing with you regarding the suggested sections for removal.
2. I'm fine with splitting up this blog, but I can't agree with removing the content. I included these sections because they are closely related to each other.
3. I've made all the style changes as you recommended. Please review them.

I truly appreciate your help. Thanks once more!

[sftim]

@xPetersue, this PR could become the basis of a series of articles that would be really useful. However, we'd want to align it more with our docs style guide, and we'd want to ensure there wasn't anything in the article text that is outright misleading.

Are you on the Kubernetes Slack workspace? I'd like to facilitate collaboration on this, with you and some people associated with the blog editorial side working together to produce a series of articles that you're happy to put your name to.

I asked about Slack because I think this will take some time (weeks on a calendar; more than two hours of actual collaboration). If you have the appetite to work on this further, please say Hi in #sig-docs-blog on the Kubernetes Slack workspace (I'm @sftim there). You can visit https://slack.k8s.io/ for an invitation.

[xPetersue]

@xPetersue, this PR could become the basis of a series of articles that would be really useful. However, we'd want to align it more with our docs style guide, and we'd want to ensure there wasn't anything in the article text that is outright misleading.

Are you on the Kubernetes Slack workspace? I'd like to facilitate collaboration on this, with you and some people associated with the blog editorial side working together to produce a series of articles that you're happy to put your name to.

I asked about Slack because I think this will take some time (weeks on a calendar; more than two hours of actual collaboration). If you have the appetite to work on this further, please say Hi in #sig-docs-blog on the Kubernetes Slack workspace (I'm @sftim there). You can visit https://slack.k8s.io/ for an invitation.

@sftim Thanks. I have contacted you via Kubernetes Slack. Let me know what else I need to you.

[sftim]

We discussed this on a Zoom call. A large portion of this article has already been published at https://cloudnativenow.com/topics/cloudnativenetworking/understanding-kubernetes-networking-architecture/

We require a copyright licence - the CNCF CLA - for contributions, and we cannot accept articles that have been published elsewhere (or where substantial portions have been).

There are several obstacles to publication

• We could not accept this article for the CLA issue and because of the policy on first publication. I'm afraid that this concern stands even if you retract the other article.
• The article as it stands has substantial technical inaccuracy that we would need to address
• The reading time will be too long for our audience

Right now, the principal obstacle is that you have published elsewhere. We could only publish another article that was clearly different from what you've proposed.

Thank you for your enthusiasm. We - Kubernetes - could benefit from a good explanation of the topic you're proposed, but this work as it stands cannot move forwards to publication.

[sftim]

/hold

We will close this PR soon.

[xPetersue]

We discussed this on a Zoom call. A large portion of this article has already been published at https://cloudnativenow.com/topics/cloudnativenetworking/understanding-kubernetes-networking-architecture/

We require a copyright licence - the CNCF CLA - for contributions, and we cannot accept articles that have been published elsewhere (or where substantial portions have been).

There are several obstacles to publication

• We could not accept this article for the CLA issue and because of the policy on first publication. I'm afraid that this concern stands even if you retract the other article.
• The article as it stands has substantial technical inaccuracy that we would need to address
• The reading time will be too long for our audience

Right now, the principal obstacle is that you have published elsewhere. We could only publish another article that was clearly different from what you've proposed.

Thank you for your enthusiasm. We - Kubernetes - could benefit from a good explanation of the topic you're proposed, but this work as it stands cannot move forwards to publication.

@sftim

• We could not accept this article for the CLA issue and because of the policy on first publication. I'm afraid that this concern stands even if you retract the other article.
• The article as it stands has substantial technical inaccuracy that we would need to address
• The reading time will be too long for our audience

@sftim
Thank you Tim for engaging in our nearly two-hour discussion.

Regarding your three comments, here are my proposed solutions:

1. We could not accept this article for the CLA issue and because of the policy on first publication. I'm afraid that this concern stands even if you retract the other article.
   %SS: As the author, I've been diligently working on getting this blog published on kubernetes.io for almost two months. However, since it has already been partially published on another authoritative Cloud Native website, I'm open to the idea of exclusively publishing it on kubernetes.io if that's a possibility.

2. The article as it stands has substantial technical inaccuracy that we would need to address
   %SS: During our meeting, we discussed the technical inaccuracies, and although I may not fully agree, I am willing to work with you and others to correct these inaccuracies from a technical standpoint and improve the overall content.
   @david-martin @mrbobbytables @onlydole @nate-double-u

3. The reading time will be too long for our audience.
   %SS: In response to David Martin's suggestion, while I believe it makes more sense to keep the entire content intact as it flows logically and maintains a seamless connection between topics, I am willing to compromise by including only "Classic Networking Scenarios in Kubernetes" in this published blog. What do you think?

In summary, I am committed to adhering to Kubernetes.io's rules and regulations while sharing my knowledge with fellow professionals, making their understanding of Kubernetes networking architecture smoother and less challenging. I am determined to make the most of the past two months of work and contributions. I kindly request that you refrain from closing this PR too hastily, and I greatly appreciate your assistance in this endeavour.

[sftim]

/close

[k8s-ci-robot]

@sftim: Closed this PR.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.