Merge branch 'main' into travis/ambassador-blog-post

.devcontainer/devcontainer.json

@@ -1,6 +1,6 @@
 {
     "name": "linkerd-website",
-    "image": "ghcr.io/linkerd/dev:v30",
+    "image": "ghcr.io/linkerd/dev:v44",
     "onCreateCommand": ".devcontainer/on-create.sh",
     "extensions": [
         "DavidAnson.vscode-markdownlint",

.github/workflows/install.yml

@@ -3,24 +3,19 @@ name: install
 on:
   pull_request:
     paths:
+    - .github/workflows/install.yml
     - Makefile
     - run.linkerd.io/public/install*
 
 jobs:
   lint:
     name: Lint install script
     runs-on: ubuntu-latest
-    container:
-      image: ghcr.io/linkerd/dev:v39
-      options: --user root
     steps:
+    - uses: linkerd/dev/actions/setup-tools@v44
     - name: Checkout code
       uses: actions/checkout@v4
 
-    - name: On create
-      run: |
-        .devcontainer/on-create.sh
-
     - name: Lint install script
       run: |
         make shellcheck

.github/workflows/publish.yml

@@ -11,10 +11,8 @@ jobs:
   publish:
     name: Publish
     runs-on: ubuntu-latest
-    container:
-      image: ghcr.io/linkerd/dev:v39
-      options: --user root
     steps:
+    - uses: linkerd/dev/actions/setup-tools@v44
     - name: Checkout code
       uses: actions/checkout@v4
 

.github/workflows/validate.yml

@@ -3,22 +3,20 @@ name: validate
 on:
   pull_request:
     paths:
+    - .github/workflows/validate.yml
     - linkerd.io/**
 
 jobs:
   linkerd_io:
     name: Validate generated HTML
     runs-on: ubuntu-latest
-    container:
-      image: ghcr.io/linkerd/dev:v39
-      options: --user root
     steps:
+    - uses: linkerd/dev/actions/setup-tools@v44
     - name: Checkout code
       uses: actions/checkout@v4
 
     - name: On create
-      run: |
-        .devcontainer/on-create.sh
+      run: .devcontainer/on-create.sh
 
     - name: Lint markdown
       run: |

README.md

@@ -10,7 +10,7 @@ Source code for the linkerd.io website.
    ```bash
    docker run \
       --mount type=bind,source="$(pwd)",target=/website --workdir=/website \
-      ghcr.io/linkerd/dev:v39 sh -c ".devcontainer/on-create.sh && make lint check"
+      ghcr.io/linkerd/dev:v44 sh -c ".devcontainer/on-create.sh && make lint check"
    ```
 
 1. Install Hugo to run the site locally:
@@ -109,13 +109,13 @@ main from slate-linkerd and add it to the public dir.
 
 ### Notes
 
-- This does not update api.linkerd.io, see the section for that specifically to
+* This does not update api.linkerd.io, see the section for that specifically to
   update it.
 
-- There is no caching in front of run.linkerd.io and versioncheck.linkerd.io.
+* There is no caching in front of run.linkerd.io and versioncheck.linkerd.io.
   You should see updates there immediately.
 
-- There is caching for non-html pages in front of linkerd.io. If you're updating
+* There is caching for non-html pages in front of linkerd.io. If you're updating
   a non-html page for linkerd.io, it might be worth flushing the cache
   (cloudflare) and waiting awhile.
 

linkerd.io/README.md

@@ -4,8 +4,8 @@
 
 Please do not put files in the `static` directory that are referenced on
 linkerd.io. This directory is reserved for assets that are used as external
-resources. If you need to add images for a page, please add them in the [page
-bundle](https://gohugo.io/content-management/page-bundles/).
+resources. If you need to add images for a page, please add them in the
+[page bundle](https://gohugo.io/content-management/page-bundles/).
 
 **Note:** Images in page bundles that have a width or height larger than 2400
 pixels will be downsized.
@@ -27,9 +27,46 @@ date: # The date of your post in the format: `2024-01-01T00:00:00Z`
 slug: # The URL slug for the page. Only set this param if you want to use a different slug than the title.
 keywords: [] # An array of keywords are used to relate blog posts
 params:
-  author: # The author id of the blog post. It must be an author from `data/authors.yaml`
+  author: # The author of the blog post
 ```
 
+#### Assigning an author
+
+There are 2 ways to assign an author to a blog post.
+
+1. If the author has more than one blog post, the author data should be defined
+   in `data/authors.yaml`, then the author id can be set in the frontmatter
+   params. For example:
+
+```yaml
+params:
+  author: william
+```
+
+2. If the author is only going to have a single blog post, the author data can
+   be set inline if desired. For example:
+
+```yaml
+params:
+  author:
+    name: Author name
+    avatar: avatar.png
+```
+
+For inline author data, the avatar image can either be a page resource or a
+remote image. To use a remote image, simply provide the full url to the image,
+and Hugo will download and resize it when the site is published. For example:
+
+```yaml
+params:
+  author:
+    name: John Smith
+    avatar: https://example.com/avatars/john-smith.png
+```
+
+**Note:** If an author only has a single blog post, but there's a chance they
+will have more in the future, please not use the inline method.
+
 #### Cover, thumbnail, and feature images
 
 To associate a cover, thumbnail, or feature image to a blog post, you do not
@@ -48,14 +85,14 @@ blog/
 
 If a blog post is featured, by default, the cover image will be used on the blog
 list page. If a cover image is not present, or you would like to use a different
-image than the cover image, you can name it `feature` and place it in the
-blog post folder.
+image than the cover image, you can name it `feature` and place it in the blog
+post folder.
 
 If a thumbnail image is not present in the blog post folder, the thumbnail image
 will be created from the cover image. By default, the thumbnail image will be
 cropped and resized into a square. If you would like to maintaining the original
-aspect ratio, you can set the `thumbnailProcess` frontmatter param to `fit`.
-For example:
+aspect ratio, you can set the `thumbnailProcess` frontmatter param to `fit`. For
+example:
 
 ```yaml
 params:
@@ -89,8 +126,8 @@ post is shared on social media. For example:
 images: [social.png]
 ```
 
-If the images array is empty, images with names matching `feature`, `cover`,
-or `thumbnail` will be used in that order.
+If the images array is empty, images with names matching `feature`, `cover`, or
+`thumbnail` will be used in that order.
 
 #### Markdown images
 

linkerd.io/assets/scss/app/_ambassadors.scss

@@ -3,7 +3,23 @@
 */
 
 .ambassadors {
+  // Override all h2s on the page
+  h2 {
+    font-size: $font-size-h1;
+  }
   .page__container {
+    @include make-stack(7);
+  }
+  .ambassadors__section {
+    @include make-stack(5);
+
+    @media (min-width: breakpoint-min-width("lg")) {
+      h2 {
+        text-align: center;
+      }
+    }
+  }
+  .ambassadors__items {
     display: grid;
     gap: spacer(4);
     grid-template-columns: 1fr;
@@ -18,22 +34,18 @@
     .card__footer {
       gap: spacer(1);
     }
-    &.ambassadors__emeritus {
-      border: solid 2px $blue;
+    .ambassadors__emeritus-badge {
+      position: absolute;
 
-      .badge {
-        position: absolute;
-
-        @media (max-width: breakpoint-max-width("lg")) {
-          left: spacer(4);
-          bottom: spacer(4);
-          width: 128px; // Thumbnail width
-          text-align: center; // Center badge under thumbnail
-        }
-        @media (min-width: breakpoint-min-width("xl")) {
-          top: spacer(3);
-          right: spacer(3);
-        }
+      @media (max-width: breakpoint-max-width("lg")) {
+        left: spacer(4);
+        bottom: spacer(4);
+        width: 128px; // Thumbnail width
+        text-align: center; // Center badge under thumbnail
+      }
+      @media (min-width: breakpoint-min-width("xl")) {
+        top: spacer(3);
+        right: spacer(3);
       }
     }
   }

linkerd.io/config/_default/menu.yaml

@@ -39,6 +39,9 @@ docs:
   - name: Linkerd edge
     pageRef: /2-edge/
     weight: 99
+  - name: Linkerd 2.17
+    pageRef: /2.17/
+    weight: 17
   - name: Linkerd 2.16
     pageRef: /2.16/
     weight: 16

linkerd.io/config/_default/params.yaml

@@ -12,4 +12,4 @@ social:
   twitter: Linkerd
 
 # Latest major version of Linkerd
-latestMajorVersion: "2.16"
+latestMajorVersion: "2.17"

linkerd.io/content/2-edge/features/egress.md

@@ -0,0 +1,27 @@
+---
+title: Egress
+description: Linkerd features capabilities to monitor and apply policies to egress traffic.
+---
+
+Linkerd features capabilities to monitor and apply policies to egress traffic.
+This allows cluster operators to make use of the `EgressNetwork` CRD to classify
+and visualize traffic. This CRD can be used as a parent reference for
+Gateway API route primitives in order to enable policy and routing configuration.
+Linkerd's egress control is implemented in the sidecar proxy itself; separate
+egress gateways are not required (though they can be supported).
+
+{{< warning >}}
+
+No service mesh can provide a strong security guarantee about egress traffic
+by itself; for example, a malicious actor could bypass the Linkerd sidecar -
+and thus Linkerd's egress controls - entirely. Fully restricting egress
+traffic in the presence of arbitrary applications thus typically requires a
+more comprehensive approach.
+
+{{< /warning >}}
+
+Related content:
+
+* [Guide: Managing egress traffic]({{< relref
+  "../tasks/managing-egress-traffic" >}})
+* [EgressNetwork Reference]({{< relref "../reference/egress-network" >}})

linkerd.io/content/2-edge/features/multicluster.md

@@ -39,8 +39,8 @@ splitting](../traffic-split/) or [dynamic request routing](../request-routing/)
 to allow local services to access the *Foo* service as if it were on the local
 cluster.
 
-Linkerd supports two basic forms of multi-cluster communication: hierarchical
-and flat.
+Linkerd supports three basic forms of multi-cluster communication: hierarchical,
+flat, and federated.
 
 ![Architectural diagram comparing hierarchical and flat network modes](/docs/images/multicluster/flat-network.png)
 
@@ -65,11 +65,18 @@ several advantages:
 * Better multi-cluster authorization policies, as workload identity
   is preserved across cluster boundaries.
 
-Hierarchical (gateway-based) and flat (direct pod-to-pod) modes can be combined,
-and pod-to-pod mode can be enabled for specific services by using the
-`remote-discovery` value for the label selector used to export services to other
-clusters. See the [pod-to-pod multicluster
-communication](../../tasks/pod-to-pod-multicluster/) guide and the
+### Federated services
+
+A federated service is a union of services with the same name and namespace
+in multiple different clusters. Meshed clients that send traffic to a federated
+service will have that traffic distributed across all replicas of services in
+the federated service across clusters. Federated services use the *flat
+networking* model and do not use a gateway intermediary.
+
+These modes can be combined, with each specific service selecting the mode that
+is most appropriate for that service. See the
+[pod-to-pod multicluster communication](../../tasks/pod-to-pod-multicluster/)
+guide, the [federated services](../../tasks/federated-services/) guide, and the
 [multi-cluster reference](../../reference/multicluster/) for more.
 
 ## Headless services
@@ -80,8 +87,8 @@ communication](../../tasks/pod-to-pod-multicluster/) guide and the
 By default, Linkerd will mirror all exported services as Kubernetes `clusterIP`
 services. This also extends to [headless services][headless-svc]; an exported
 headless service will be mirrored as `clusterIP` and have an IP address
-assigned to it. In general, headless services _should not have an IP address_,
-they are used when a workloads needs a stable network identifier or to
+assigned to it. In general, headless services *should not have an IP address*;
+they are used when a workload needs a stable network identifier or to
 facilitate service discovery without being tied to Kubernetes' native
 implementation. This allows clients to either implement their own load
 balancing or to address a pod directly through its DNS name. In certain
@@ -110,14 +117,17 @@ exported as a headless service, the hosts backing the service need to be named
 Deployment would not be supported, since they do not allow for arbitrary
 hostnames in the pod spec).
 
+Note that headless services can *not* be part of a federated service.
+
 Ready to get started? See the [getting started with multi-cluster
 guide](../../tasks/multicluster/) for a walkthrough.
 
 ## Further reading
 
-* [Multi-cluster installation instructions](../../tasks/installing-multicluster/).
+* [Multi-cluster installation instructions](../../tasks/installing-multicluster/)
 * [Pod-to-pod multicluster communication](../../tasks/pod-to-pod-multicluster/)
-* [Multi-cluster communication with StatefulSets](../../tasks/multicluster-using-statefulsets/).
+* [Multi-cluster communication with StatefulSets](../../tasks/multicluster-using-statefulsets/)
+* [Federated services](../../tasks/federated-services/)
 * [Architecting for multi-cluster
   Kubernetes](/2020/02/17/architecting-for-multicluster-kubernetes/), a blog
   post explaining some of the design rationale behind Linkerd's multi-cluster