Merge pull request #49693 from michellengnx/merged-main-dev-1.33

Merge main branch into dev-1.33

Author: k8s-ci-robot

Makefile

@@ -7,7 +7,7 @@ NETLIFY_FUNC      = $(NODE_BIN)/netlify-lambda
 # CONTAINER_ENGINE=podman make container-image
 CONTAINER_ENGINE ?= docker
 IMAGE_REGISTRY ?= gcr.io/k8s-staging-sig-docs
-IMAGE_VERSION=$(shell scripts/hash-files.sh Dockerfile Makefile package.json package-lock.json | cut -c 1-12)
+IMAGE_VERSION=$(shell scripts/hash-files.sh Dockerfile Makefile netlify.toml .dockerignore cloudbuild.yaml package.json package-lock.json | cut -c 1-12)
 CONTAINER_IMAGE   = $(IMAGE_REGISTRY)/k8s-website-hugo:v$(HUGO_VERSION)-$(IMAGE_VERSION)
 # Mount read-only to allow use with tools like Podman in SELinux mode
 # Container targets don't need to write into /src

README.md

@@ -30,7 +30,10 @@ git clone https://github.com/kubernetes/website.git
 cd website
 ```
 
-The Kubernetes website uses git submodules. Even if you plan to run the website in a container, we strongly recommend pulling in the submodule and other development dependencies by running the following:
+The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/docsy#readme),
+which can be installed via npm. You can also download a pre-configured
+development container image that includes Hugo and Docsy. Additionally, a Git
+submodule is used for tools that generate the reference documentation.
 
 ### Windows
 

assets/scss/_custom.scss

@@ -125,6 +125,33 @@ body.td-home main[role="main"] > section:first-of-type .content p:first-child {
   }
 }
 
+.section-feature#kubeweekly {
+
+  a.kubeweekly-signup, a.kubeweekly-signup:hover {
+    color: $primary;
+    font-weight: 400;
+    font-size: 1.1rem;
+  }
+  > .kubeweekly-inner {
+    form p {
+      text-align: center;
+      font-size: 1.2rem;
+      color: $black;
+    }
+    margin-left: auto;
+    margin-right: auto;
+    padding-top: 2rem;
+  }
+
+  h5 {
+    text-align: center;
+
+    a:hover {
+      text-decoration: underline;
+    }
+  }
+}
+
 body.td-404 main .error-details {
   max-width: 1100px;
   margin: 0 auto;
@@ -1932,9 +1959,13 @@ div.alert > em.javascript-required {
   font-size: 1.15rem;
 }
 
-body.td-search #search {
-  margin-top: 1rem;
-  margin-bottom: 3rem;
+body.td-search {
+  width: 100%; // avoid confusion with other .td-search elements that have a width set
+
+  #search {
+    margin-top: 1rem;
+    margin-bottom: 3rem;
+  }
 }
 
 /* CSS for 'figure' full-screen display */

assets/scss/case_studies.scss

@@ -70,6 +70,10 @@ body.cid-casestudies {
     background-repeat: no-repeat;
   }
 
+  .banner h2 {
+	color: #fff;
+  }
+
   .banner * {
     position: relative;
   }
@@ -213,15 +217,16 @@ body.td-section.cid-casestudies {
   }
 
   .video-quote, .case-study-video {
-     max-width: calc(clamp(40em, 50vw + 20em, 100vw - 4em));
-     margin-left: auto;
-     margin-right: auto;
+     width: 50%;
      padding-top: 1em;
      padding-bottom: 1em;
+     box-sizing: border-box;
+     text-align: center;
      iframe {
        display: block;
        margin-left: auto;
-       margin-top: 1.5em;
+       width: 90%;
+       aspect-ratio: 16 / 9;
      }
   }
 
@@ -269,12 +274,17 @@ body.td-section.cid-casestudies {
   }
 }
 
-@media (max-width: 1000px) {
+@media (max-width: 1200px) {
   body.td-section.cid-casestudies {
     .case-study {
        width: initial;
        flex-basis: 90vw;
        margin-bottom: 40px;
     }
+
+    .video-quote, .case-study-video {
+       width: initial;
+       flex-basis: 90%;
+    }
   }
 }

content/en/_index.html

@@ -62,3 +62,5 @@ <h3>Attend upcoming KubeCon + CloudNativeCon events</h3>
 {{< blocks/kubernetes-features >}}
 
 {{< blocks/case-studies >}}
+
+{{< kubeweekly id="kubeweekly" >}}

content/en/docs/concepts/services-networking/dns-pod-service.md

@@ -13,56 +13,56 @@ description: >-
 <!-- overview -->
 
 Kubernetes creates DNS records for Services and Pods. You can contact
-Services with consistent DNS names instead of IP addresses. 
+Services with consistent DNS names instead of IP addresses.
 
 <!-- body -->
 
 Kubernetes publishes information about Pods and Services which is used
-to program DNS.  Kubelet configures Pods' DNS so that running containers
-can lookup Services by name rather than IP.
+to program DNS. kubelet configures Pods' DNS so that running containers
+can look up Services by name rather than IP.
 
 Services defined in the cluster are assigned DNS names. By default, a
 client Pod's DNS search list includes the Pod's own namespace and the
-cluster's default domain. 
+cluster's default domain.
 
-### Namespaces of Services 
+### Namespaces of Services
 
-A DNS query may return different results based on the namespace of the Pod making 
-it. DNS queries that don't specify a namespace are limited to the Pod's 
-namespace. Access Services in other namespaces by specifying it in the DNS query. 
+A DNS query may return different results based on the namespace of the Pod making
+it. DNS queries that don't specify a namespace are limited to the Pod's
+namespace. Access Services in other namespaces by specifying it in the DNS query.
 
-For example, consider a Pod in a `test` namespace. A `data` Service is in 
-the `prod` namespace. 
+For example, consider a Pod in a `test` namespace. A `data` Service is in
+the `prod` namespace.
 
-A query for `data` returns no results, because it uses the Pod's `test` namespace. 
+A query for `data` returns no results, because it uses the Pod's `test` namespace.
 
-A query for `data.prod` returns the intended result, because it specifies the 
-namespace. 
+A query for `data.prod` returns the intended result, because it specifies the
+namespace.
 
-DNS queries may be expanded using the Pod's `/etc/resolv.conf`. Kubelet 
-configures this file for each Pod. For example, a query for just `data` may be 
-expanded to `data.test.svc.cluster.local`. The values of the `search` option 
-are used to expand queries. To learn more about DNS queries, see 
-[the `resolv.conf` manual page.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html) 
+DNS queries may be expanded using the Pod's `/etc/resolv.conf`. kubelet
+configures this file for each Pod. For example, a query for just `data` may be
+expanded to `data.test.svc.cluster.local`. The values of the `search` option
+are used to expand queries. To learn more about DNS queries, see
+[the `resolv.conf` manual page](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html).
 
 ```
 nameserver 10.32.0.10
 search <namespace>.svc.cluster.local svc.cluster.local cluster.local
 options ndots:5
 ```
 
-In summary, a Pod in the _test_ namespace can successfully resolve either 
+In summary, a Pod in the _test_ namespace can successfully resolve either
 `data.prod` or `data.prod.svc.cluster.local`.
 
 ### DNS Records
 
 What objects get DNS records?
 
 1. Services
-2. Pods
+1. Pods
 
 The following sections detail the supported DNS record types and layout that is
-supported.  Any other layout or names or queries that happen to work are
+supported. Any other layout or names or queries that happen to work are
 considered implementation details and are subject to change without warning.
 For more up-to-date specification, see
 [Kubernetes DNS-Based Service Discovery](https://github.com/kubernetes/dns/blob/master/docs/specification.md).
@@ -73,43 +73,53 @@ For more up-to-date specification, see
 
 "Normal" (not headless) Services are assigned DNS A and/or AAAA records,
 depending on the IP family or families of the Service, with a name of the form
-`my-svc.my-namespace.svc.cluster-domain.example`.  This resolves to the cluster IP
+`my-svc.my-namespace.svc.cluster-domain.example`. This resolves to the cluster IP
 of the Service.
 
-[Headless Services](/docs/concepts/services-networking/service/#headless-services) 
+[Headless Services](/docs/concepts/services-networking/service/#headless-services)
 (without a cluster IP) are also assigned DNS A and/or AAAA records,
-with a name of the form `my-svc.my-namespace.svc.cluster-domain.example`.  Unlike normal
+with a name of the form `my-svc.my-namespace.svc.cluster-domain.example`. Unlike normal
 Services, this resolves to the set of IPs of all of the Pods selected by the Service.
 Clients are expected to consume the set or else use standard round-robin
 selection from the set.
 
 ### SRV records
 
 SRV Records are created for named ports that are part of normal or headless
-services.  For each named port, the SRV record has the form
-`_port-name._port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
-For a regular Service, this resolves to the port number and the domain name:
-`my-svc.my-namespace.svc.cluster-domain.example`.
-For a headless Service, this resolves to multiple answers, one for each Pod
-that is backing the Service, and contains the port number and the domain name of the Pod
-of the form `hostname.my-svc.my-namespace.svc.cluster-domain.example`.
+services.
+
+- For each named port, the SRV record has the form
+  `_port-name._port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
+- For a regular Service, this resolves to the port number and the domain name:
+  `my-svc.my-namespace.svc.cluster-domain.example`.
+- For a headless Service, this resolves to multiple answers, one for each Pod
+  that is backing the Service, and contains the port number and the domain name of the Pod
+  of the form `hostname.my-svc.my-namespace.svc.cluster-domain.example`.
 
 ## Pods
 
 ### A/AAAA records
 
-Kube-DNS versions, prior to the implementation of the [DNS specification](https://github.com/kubernetes/dns/blob/master/docs/specification.md), had the following DNS resolution:
+Kube-DNS versions, prior to the implementation of the
+[DNS specification](https://github.com/kubernetes/dns/blob/master/docs/specification.md),
+had the following DNS resolution:
 
-`pod-ipv4-address.my-namespace.pod.cluster-domain.example`.
+```
+pod-ipv4-address.my-namespace.pod.cluster-domain.example
+```
 
 For example, if a Pod in the `default` namespace has the IP address 172.17.0.3,
 and the domain name for your cluster is `cluster.local`, then the Pod has a DNS name:
 
-`172-17-0-3.default.pod.cluster.local`.
+```
+172-17-0-3.default.pod.cluster.local
+```
 
-Some cluster DNS mechanisms, like [CoreDNS], also provide `A` records for:
+Some cluster DNS mechanisms, like [CoreDNS](https://coredns.io/), also provide `A` records for:
 
-<tt><em>pod-ipv4-address</em>.<em>service-name</em>.<em>my-namespace</em>.svc.<em>cluster-domain.example</em>.</tt>
+```
+<pod-ipv4-address>.<service-name>.<my-namespace>.svc.<cluster-domain.example>
+```
 
 ### Pod's hostname and subdomain fields
 
@@ -191,7 +201,8 @@ An {{<glossary_tooltip term_id="endpoint-slice" text="EndpointSlice">}} can spec
 the DNS hostname for any endpoint addresses, along with its IP.
 
 {{< note >}}
-A and AAAA records are not created for Pod names since `hostname` is missing for the Pod. A Pod with no `hostname` but with `subdomain` will only create the
+A and AAAA records are not created for Pod names since `hostname` is missing for the Pod.
+A Pod with no `hostname` but with `subdomain` will only create the
 A or AAAA record for the headless Service (`busybox-subdomain.my-namespace.svc.cluster-domain.example`),
 pointing to the Pods' IP addresses. Also, the Pod needs to be ready in order to have a
 record unless `publishNotReadyAddresses=True` is set on the Service.
@@ -203,16 +214,24 @@ record unless `publishNotReadyAddresses=True` is set on the Service.
 
 When a Pod is configured to have fully qualified domain name (FQDN), its
 hostname is the short hostname. For example, if you have a Pod with the fully
-qualified domain name `busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example`, 
-then by default the `hostname` command inside that Pod returns `busybox-1` and  the
+qualified domain name `busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example`,
+then by default the `hostname` command inside that Pod returns `busybox-1` and the
 `hostname --fqdn` command returns the FQDN.
 
-When you set `setHostnameAsFQDN: true` in the Pod spec, the kubelet writes the Pod's FQDN into the hostname for that Pod's namespace. In this case, both `hostname` and `hostname --fqdn` return the Pod's FQDN.
+When you set `setHostnameAsFQDN: true` in the Pod spec, the kubelet writes the Pod's FQDN
+into the hostname for that Pod's namespace. In this case, both `hostname` and `hostname --fqdn`
+return the Pod's FQDN.
 
 {{< note >}}
 In Linux, the hostname field of the kernel (the `nodename` field of `struct utsname`) is limited to 64 characters.
 
-If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from Pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment.
+If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start.
+The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating
+error events, such as Failed to construct FQDN from Pod hostname and cluster domain,
+FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested).
+One way of improving user experience for this scenario is to create an
+[admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)
+to control FQDN size when users create top level objects, for example, Deployment.
 {{< /note >}}
 
 ### Pod's DNS Policy
@@ -235,7 +254,11 @@ following Pod-specific DNS policies. These policies are specified in the
   explicitly set its DNS policy to "`ClusterFirstWithHostNet`". Otherwise, Pods
   running with hostNetwork and `"ClusterFirst"` will fallback to the behavior
   of the `"Default"` policy.
-  - Note: This is not supported on Windows. See [below](#dns-windows) for details
+
+  {{< note >}}
+  This is not supported on Windows. See [below](#dns-windows) for details.
+  {{< /note >}}
+
 - "`None`": It allows a Pod to ignore DNS settings from the Kubernetes
   environment. All DNS settings are supposed to be provided using the
   `dnsConfig` field in the Pod Spec.
@@ -246,7 +269,6 @@ following Pod-specific DNS policies. These policies are specified in the
 explicitly specified, then "ClusterFirst" is used.
 {{< /note >}}
 
-
 The example below shows a Pod with its DNS policy set to
 "`ClusterFirstWithHostNet`" because it has `hostNetwork` set to `true`.
 
@@ -315,7 +337,9 @@ For IPv6 setup, search path and name server should be set up like this:
 ```shell
 kubectl exec -it dns-example -- cat /etc/resolv.conf
 ```
+
 The output is similar to this:
+
 ```
 nameserver 2001:db8:30::a
 search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
@@ -343,7 +367,7 @@ this problem.
 
 ## DNS resolution on Windows nodes {#dns-windows}
 
-- ClusterFirstWithHostNet is not supported for Pods that run on Windows nodes.
+- `ClusterFirstWithHostNet` is not supported for Pods that run on Windows nodes.
   Windows treats all names with a `.` as a FQDN and skips FQDN resolution.
 - On Windows, there are multiple DNS resolvers that can be used. As these come with
   slightly different behaviors, using the
@@ -362,6 +386,4 @@ this problem.
 ## {{% heading "whatsnext" %}}
 
 For guidance on administering DNS configurations, check
-[Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/)
-
-[CoreDNS]: https://coredns.io/
+[Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/).

content/en/docs/contribute/new-content/open-a-pr.md

@@ -169,7 +169,6 @@ Figure 2. Working from a local fork to make your changes.
    ```shell
    git clone [email protected]:<github_username>/website
    cd website
-   git submodule update --init --recursive --depth 1
    ```
 
 1. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote:
@@ -338,20 +337,24 @@ variable to override this behaviour.
 
 Alternately, install and use the `hugo` command on your computer:
 
-1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in
+1. Install the [Hugo (Extended edition)](https://gohugo.io/getting-started/installing/) and [Node](https://nodejs.org/en) version specified in
    [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml).
 
-1. If you have not updated your website repository, the `website/themes/docsy` directory is empty.
-   The site cannot build without a local copy of the theme. To update the website theme, run:
+1. Install any dependencies:
 
    ```shell
-   git submodule update --init --recursive --depth 1
+   npm ci
    ```
 
 1. In a terminal, go to your Kubernetes website repository and start the Hugo server:
 
    ```shell
    cd <path_to_your_repo>/website
+   make serve
+   ```
+   If you're on a Windows machine or unable to run the `make` command, use the following command:
+
+   ```
    hugo server --buildFuture
    ```