Merge remote-tracking branch 'upstream/master' into dev-1.19

Makefile

@@ -36,7 +36,10 @@ serve: ## Boot the development server.
 	hugo server --buildFuture
 
 docker-image:
-	$(DOCKER) build . --tag $(DOCKER_IMAGE) --build-arg HUGO_VERSION=$(HUGO_VERSION)
+	$(DOCKER) build . \
+		--network=host \
+		--tag $(DOCKER_IMAGE) \
+		--build-arg HUGO_VERSION=$(HUGO_VERSION)
 
 docker-build:
 	$(DOCKER_RUN) $(DOCKER_IMAGE) hugo

OWNERS_ALIASES

@@ -41,7 +41,6 @@ aliases:
   sig-docs-en-owners: # Admins for English content
     - bradtopol
     - daminisatya
-    - jaredbhatti
     - jimangel
     - kbarnard10
     - kbhawkey
@@ -59,7 +58,6 @@ aliases:
   sig-docs-en-reviews: # PR reviews for English content
     - bradtopol
     - daminisatya
-    - jaredbhatti
     - jimangel
     - kbarnard10
     - kbhawkey

assets/sass/_base.sass

@@ -439,6 +439,7 @@ footer
   width: 100%
   background-image: url(/images/texture.png)
   background-color: $dark-grey
+  overflow-x: hidden
 
   .main-section
     padding: 20px 0
@@ -1214,7 +1215,7 @@ $feature-box-div-margin-bottom: 40px
     margin-bottom: 20px
 
   #desktopKCButton
-    position: relative
+    position: absolute
     font-size: 18px
     background-color: $dark-grey
     border-radius: 8px

content/en/blog/_index.md

@@ -8,3 +8,9 @@ menu:
     post: >
        <p>Read the latest news for Kubernetes and the containers space in general, and get technical how-tos hot off the presses.</p>
 ---
+{{< comment >}}
+
+For information about contributing to the blog, see
+https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/#write-a-blog-post
+
+{{< /comment >}}

content/en/blog/_posts/2018-04-13-local-persistent-volumes-beta.md

@@ -144,7 +144,7 @@ The local persistent volume beta feature is not complete by far. Some notable en
 
 [Pod disruption budget](/docs/concepts/workloads/pods/disruptions/) is also very important for those workloads that must maintain quorum. Setting a disruption budget for your workload ensures that it does not drop below quorum due to voluntary disruption events, such as node drains during upgrade.
 
-[Pod affinity and anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) ensures that your workloads stay either co-located or spread out across failure domains. If you have multiple local persistent volumes available on a single node, it may be preferable to specify an pod anti-affinity policy to spread your workload across nodes. Note that if you want multiple pods to share the same local persistent volume, you do not need to specify a pod affinity policy. The scheduler understands the locality constraints of the local persistent volume and schedules your pod to the correct node.
+[Pod affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) ensures that your workloads stay either co-located or spread out across failure domains. If you have multiple local persistent volumes available on a single node, it may be preferable to specify an pod anti-affinity policy to spread your workload across nodes. Note that if you want multiple pods to share the same local persistent volume, you do not need to specify a pod affinity policy. The scheduler understands the locality constraints of the local persistent volume and schedules your pod to the correct node.
 
 ## Getting involved
 

content/en/blog/_posts/2018-10-10-runtimeclass.md

@@ -27,7 +27,7 @@ Why is RuntimeClass a pod level concept? The Kubernetes resource model expects c
 
 ## What's next?
 
-The RuntimeClass resource is an important foundation for surfacing runtime properties to the control plane. For example, to implement scheduler support for clusters with heterogeneous nodes supporting different runtimes, we might add [NodeAffinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) terms to the RuntimeClass definition. Another area to address is managing the variable resource requirements to run pods of different runtimes. The [Pod Overhead proposal](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview) was an early take on this that aligns nicely with the RuntimeClass design, and may be pursued further.
+The RuntimeClass resource is an important foundation for surfacing runtime properties to the control plane. For example, to implement scheduler support for clusters with heterogeneous nodes supporting different runtimes, we might add [NodeAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) terms to the RuntimeClass definition. Another area to address is managing the variable resource requirements to run pods of different runtimes. The [Pod Overhead proposal](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview) was an early take on this that aligns nicely with the RuntimeClass design, and may be pursued further.
 
 Many other RuntimeClass extensions have also been proposed, and will be revisited as the feature continues to develop and mature. A few more extensions that are being considered include:
 

content/en/case-studies/babylon/index.html

@@ -4,7 +4,7 @@
 case_study_styles: true
 cid: caseStudies
 css: /css/case-studies-gradient.css
-logo: babylon_featured_logo.png
+logo: babylon_featured_logo.svg
 featured: true
 weight: 1
 quote: >