Migrated the Ruby Linter to NodeJS Linter

.markdownlint.json

@@ -0,0 +1,13 @@
+{
+    "default": false,
+    "MD002": { "level": 2 },
+    "MD007": { "indent": 4 },
+    "MD013": false,
+    "MD026": { "punctuation": ".,;:!" }, 
+    "MD014": false,
+    "MD030": false,
+    "MD032": false,
+    "MD033": false,
+    "MD041": false,
+    "MD046": false
+  }

common/Makefile.common.mk

@@ -50,7 +50,8 @@ lint-python:
 	@${FINDFILES} -name '*.py' \( ! \( -name '*_pb2.py' \) \) -print0 | ${XARGS} autopep8 --max-line-length 160 --exit-code -d
 
 lint-markdown:
-	@${FINDFILES} -name '*.md' -not -path './manifests/addons/dashboards/*' -print0 | ${XARGS} mdl --ignore-front-matter --style common/config/mdl.rb
+	@${FINDFILES} -name '*.md' -not -path './manifests/addons/dashboards/*' -print0 | ${XARGS} markdownlint-cli2 --config .markdownlint.json
+
 
 lint-links:
 	@${FINDFILES} -name '*.md' -print0 | ${XARGS} awesome_bot --skip-save-results --allow_ssl --allow-timeout --allow-dupe --allow-redirect --white-list ${MARKDOWN_LINT_ALLOWLIST}

content/en/about/faq/metrics-and-logs/life-of-a-request.md

@@ -2,7 +2,7 @@
 title: How to figure out what happened to a request in Istio?
 weight: 80
 ---
-
+<!-- markdownlint-disable MD026 -->
 You can enable [tracing](/docs/tasks/observability/distributed-tracing/) to determine the flow of a request in Istio.
 
 Additionally, you can use the following commands to know more about the state of the mesh:

content/en/about/faq/traffic-management/cors.md

@@ -2,7 +2,7 @@
 title: Why is my CORS configuration not working?
 weight: 40
 ---
-
+<!-- markdownlint-disable MD007 -->
 After applying [CORS configuration](/docs/reference/config/networking/virtual-service/#CorsPolicy), you may find that seemingly nothing happened and wonder what went wrong.
 CORS is a commonly misunderstood HTTP concept that often leads to confusion when configuring.
 

content/en/about/faq/traffic-management/ingress-with-no-route-rules.md

@@ -2,7 +2,7 @@
 title: Can I use standard Ingress specification without any route rules?
 weight: 40
 ---
-
+<!-- markdownlint-disable MD007 -->
 Simple ingress specifications, with host, TLS, and exact path based
 matches will work out of the box without the need for route
 rules. However, note that the path used in the ingress resource should

content/en/blog/2017/0.1-canary/index.md

@@ -8,7 +8,7 @@ keywords: [traffic-management,canary]
 aliases:
     - /blog/canary-deployments-using-istio.html
 ---
-
+<!-- markdownlint-disable MD007 MD026-->
 {{< tip >}}
 This post was updated on May 16, 2018 to use the latest version of the traffic management model.
 {{< /tip >}}

content/en/blog/2017/0.1-using-network-policy/index.md

@@ -8,6 +8,7 @@ aliases:
     - /blog/using-network-policy-in-concert-with-istio.html
 target_release: 0.1
 ---
+<!-- markdownlint-disable-file MD007 -->
 
 The use of Network Policy to secure applications running on Kubernetes is a now a widely accepted industry best practice.  Given that Istio also supports policy, we want to spend some time explaining how Istio policy and Kubernetes Network Policy interact and support each other to deliver your application securely.
 

content/en/blog/2018/egress-https/index.md

@@ -8,7 +8,7 @@ attribution: Vadim Eisenberg
 keywords: [traffic-management,egress,https]
 target_release: 1.1
 ---
-
+<!-- markdownlint-disable-file MD007 -->
 In many cases, not all the parts of a microservices-based application reside in a _service mesh_. Sometimes, the
 microservices-based applications use functionality provided by legacy systems that reside outside the mesh. You may want
 to migrate these systems to the service mesh gradually. Until these systems are migrated, they must be accessed by the

content/en/blog/2018/egress-mongo/index.md

@@ -8,6 +8,7 @@ attribution: Vadim Eisenberg
 keywords: [traffic-management,egress,tcp,mongo]
 target_release: 1.1
 ---
+<!-- markdownlint-disable-file MD007 MD026 -->
 
 In the [Consuming External TCP Services](/blog/2018/egress-tcp/) blog post, I described how external services
 can be consumed by in-mesh Istio applications via TCP. In this post, I demonstrate consuming external MongoDB services.

content/en/blog/2018/export-logs-through-stackdriver/index.md

@@ -6,6 +6,7 @@ subtitle:
 attribution: Nupur Garg and Douglas Reid
 target_release: 0.8
 ---
+<!-- markdownlint-disable-file MD007 MD026 -->
 
 This post shows how to direct Istio logs to [Stackdriver](https://cloud.google.com/stackdriver/)
 and export those logs to various configured sinks such as such as

content/en/blog/2018/incremental-traffic-management/index.md

@@ -8,7 +8,7 @@ twitter: crcsmnky
 keywords: [traffic-management,gateway]
 target_release: 1.0
 ---
-
+<!-- markdownlint-disable-file MD007 -->
 Traffic management is one of the critical benefits provided by Istio. At the heart of Istio’s traffic management is the ability to decouple traffic flow and infrastructure scaling. This lets you control your traffic in ways that aren’t possible without a service mesh like Istio.
 
 For example, let’s say you want to execute a [canary deployment](https://martinfowler.com/bliki/CanaryRelease.html). With Istio, you can specify that **v1** of a service receives 90% of incoming traffic, while **v2** of that service only receives 10%. With standard Kubernetes deployments, the only way to achieve this is to manually control the number of available Pods for each version, for example 9 Pods running v1 and 1 Pod running v2. This type of manual control is hard to implement, and over time may have trouble scaling. For more information, check out [Canary Deployments using Istio](/blog/2017/0.1-canary/).

content/en/blog/2018/istio-authorization/index.md

@@ -7,7 +7,7 @@ attribution: Limin Wang
 keywords: [authorization,rbac,security]
 target_release: 0.8
 ---
-
+<!-- markdownlint-disable-file MD007 -->
 Micro-segmentation is a security technique that creates secure zones in cloud deployments and allows organizations to
 isolate workloads from one another and secure them individually.
 [Istio's authorization feature](/docs/concepts/security/#authorization), also known as Istio Role Based Access Control,

content/en/blog/2018/traffic-mirroring/index.md

@@ -7,6 +7,7 @@ attribution: Christian Posta
 keywords: [traffic-management,mirroring]
 target_release: 0.5
 ---
+<!-- markdownlint-disable-file MD007 -->
 
 Trying to enumerate all the possible combinations of test cases for testing services in non-production/test environments can be daunting. In some cases, you'll find that all of the effort that goes into cataloging these use cases doesn't match up to real production use cases. Ideally, we could use live production use cases and traffic to help illuminate all of the feature areas of the service under test that we might miss in more contrived testing environments.
 

content/en/blog/2018/v1alpha3-routing/index.md

@@ -7,7 +7,7 @@ attribution: Frank Budinsky (IBM) and Shriram Rajagopalan (VMware)
 keywords: [traffic-management]
 target_release: 0.7
 ---
-
+<!-- markdownlint-disable-file MD007 -->
 Up until now, Istio has provided a simple API for traffic management using four configuration resources:
 `RouteRule`, `DestinationPolicy`, `EgressRule`, and (Kubernetes) `Ingress`.
 With this API, users have been able to easily manage the flow of traffic in an Istio service mesh.

content/en/blog/2019/announcing-istio-client-go/index.md

@@ -6,6 +6,7 @@ attribution: Neeraj Poddar (Aspen Mesh)
 keywords: [client-go,tools,crd]
 target_release: 1.4
 ---
+<!-- markdownlint-disable-file MD007 -->
 
 We are pleased to announce the initial release of the Istio
 [client go](https://github.com/istio/client-go) repository which enables developers

content/en/blog/2019/data-plane-setup/index.md

@@ -8,6 +8,7 @@ twitter: chugtum
 keywords: [kubernetes,sidecar-injection, traffic-management]
 target_release: 1.0
 ---
+<!-- markdownlint-disable-file MD007 -->
 A simple overview of an Istio service-mesh architecture always starts with describing the control-plane and data-plane.
 
 [From Istio’s documentation](/docs/ops/deployment/architecture/):

content/en/blog/2019/multicluster-version-routing/index.md

@@ -7,7 +7,7 @@ attribution: Frank Budinsky (IBM)
 keywords: [traffic-management,multicluster]
 target_release: 1.0
 ---
-
+<!-- markdownlint-disable-file MD007 -->
 If you've spent any time looking at Istio, you've probably noticed that it includes a lot of features that
 can be demonstrated with simple [tasks](/docs/tasks/) and [examples](/docs/examples/)
 running on a single Kubernetes cluster.

content/en/blog/2019/v1beta1-authorization-policy/index.md

@@ -7,7 +7,7 @@ attribution: Yangmin Zhu (Google)
 keywords: [security, RBAC, access control, authorization]
 target_release: 1.4
 ---
-
+<!-- markdownlint-disable-file MD007 -->
 Istio 1.4 introduces the
 [`v1beta1` authorization policy](/docs/reference/config/security/authorization-policy/),
 which is a major update to the previous `v1alpha1` role-based access control

content/en/blog/2020/deploy-wasm-declarative/index.md

@@ -6,6 +6,7 @@ publishdate: 2020-03-16
 attribution: "Christian Posta (Solo.io)"
 keywords: [wasm,extensibility,alpha,operator]
 ---
+<!-- markdownlint-disable-file MD007 -->
 
 As outlined in the [Istio 2020 trade winds blog](/blog/2020/tradewinds-2020/) and more recently [announced with Istio 1.5](/news/releases/1.5.x/announcing-1.5/), WebAssembly (Wasm) is now an (alpha) option for extending the functionality of the Istio service proxy (Envoy proxy). With Wasm, users can build support for new protocols, custom metrics, loggers, and other filters. Working closely with Google, we in the community ([Solo.io](https://solo.io)) have focused on the user experience of building, socializing, and deploying Wasm extensions to Istio. We've announced [WebAssembly Hub](https://webassemblyhub.io) and [associated tooling](https://docs.solo.io/web-assembly-hub/latest/installation/) to build a "docker-like" experience for working with Wasm.
 

content/en/blog/2020/dns-proxy/index.md

@@ -6,7 +6,7 @@ publishdate: 2020-11-12
 attribution: "Shriram Rajagopalan (Tetrate.io) on behalf of Istio Networking WG"
 keywords: [dns,sidecar,multicluster,vm,external services]
 ---
-
+<!-- markdownlint-disable-file MD007 -->
 DNS resolution is a vital component of any application infrastructure
 on Kubernetes. When your application code attempts to access another
 service in the Kubernetes cluster or even a service on the internet,

content/en/blog/2020/multi-cluster-mesh-automation/index.md

@@ -7,6 +7,7 @@ attribution: Anil Attuluri (Intuit), Jason Webb (Intuit)
 keywords: [traffic-management,automation,configuration,multicluster,multi-mesh,gateway,federated,globalidentifer]
 target_release: 1.5
 ---
+<!-- markdownlint-disable-file MD007 -->
 
 At Intuit, we read the blog post [Multi-Mesh Deployments for Isolation and Boundary Protection](/blog/2019/isolated-clusters/) and immediately related to some of the problems mentioned.
 We realized that even though we wanted to configure a single multi-cluster mesh, instead of a federation of multiple meshes

content/en/blog/2020/proxying-legacy-services-using-egress-gateways/index.md

@@ -7,6 +7,7 @@ attribution: Antonio Berben (Deutsche Telekom - PAN-NET)
 keywords: [configuration,egress,gateway,external,service]
 target_release: 1.8.0
 ---
+<!-- markdownlint-disable-file MD007 -->
 
 At [Deutsche Telekom Pan-Net](https://pan-net.cloud/aboutus), we have embraced Istio as the umbrella to cover our services. Unfortunately, there are services which have not yet been migrated to Kubernetes, or cannot be.
 

content/en/blog/2020/show-source-ip/index.md

@@ -5,6 +5,7 @@ publishdate: 2020-12-11
 attribution: "Xinhui Li (Salesforce) "
 keywords: [trafficManagement,protocol extending]
 ---
+<!-- markdownlint-disable-file MD007 -->
 This blog presents my latest experience about how to configure and enable proxy protocol with stack of AWS NLB and Istio Ingress gateway. The [Proxy Protocol](https://www.haproxy.com/blog/haproxy/proxy-protocol/) was designed to chain proxies and reverse-proxies without losing the client information. The proxy protocol prevents the need for infrastructure changes or `NATing` firewalls, and offers the benefits of being protocol agnostic and providing good scalability. Additionally, we also enable the `X-Forwarded-For` HTTP header in the deployment to make the client IP address easy to read. In this blog, traffic management of Istio ingress is shown with an httpbin service on ports 80 and 443 to demonstrate the use of proxy protocol. Note that both v1 and v2 of the proxy protocol work for the purpose of this example, but because the AWS NLB currently only supports v2, proxy protocol v2 is used in the rest of this blog by default. The following image shows the use of proxy protocol v2 with an AWS NLB.
 
 {{< tip >}}

content/en/blog/2020/workload-entry/index.md

@@ -6,7 +6,7 @@ publishdate: 2020-05-21
 attribution: "Cynthia Coan (Tetrate), Shriram Rajagopalan (Tetrate), Tia Louden (Tetrate), John Howard (Google), Sven Mawson (Google)"
 keywords: [vm,workloadentry,migration,'1.6',baremetal,serviceentry,discovery]
 ---
-
+<!-- markdownlint-disable-file MD007 -->
 ## Introducing Workload Entries: Bridging Kubernetes and VMs
 
 Historically, Istio has provided great experience to workloads that run on Kubernetes, but it has been less smooth for other types of workloads, such as Virtual Machines (VMs) and bare metal. The gaps included the inability to declaratively specify the properties of a sidecar on a VM, inability to properly respond to the lifecycle changes of the workload (e.g., booting to not ready to ready, or health checks), and cumbersome DNS workarounds as the workloads are migrated into Kubernetes to name a few.

content/en/blog/2021/better-external-authz/index.md

@@ -6,7 +6,7 @@ publishdate: 2021-02-09
 attribution: Yangmin Zhu (Google)
 keywords: [authorization,access control,opa,oauth2]
 ---
-
+<!-- markdownlint-disable-file MD007 MD026 -->
 ## Background
 
 Istio's authorization policy provides access control for services in the mesh. It is fast, powerful and a widely used

content/en/blog/2021/discovery-selectors/index.md

@@ -5,6 +5,7 @@ publishdate: 2021-04-30
 attribution: "Lin Sun (Solo.io), Christian Posta (Solo.io), Harvey Xia (Solo.io)"
 keywords: [discoveryselectors,Istio,namespaces,sidecar]
 ---
+<!-- markdownlint-disable-file MD007 MD026 -->
 
 As users move their services to run in the Istio service mesh, they are often surprised that the control plane watches and processes all of the Kubernetes resources, from all namespaces in the cluster, by default. This can be an issue for very large clusters with lots of namespaces and deployments, or even for a moderately sized cluster with rapidly churning resources (for example, Spark jobs).
 

content/en/blog/2021/external-locality-failover/index.md

@@ -5,6 +5,7 @@ publishdate: 2021-06-04
 attribution: "Ram Vennam (Solo.io)"
 keywords: [locality,region,failover,Istio,outlier,external]
 ---
+<!-- markdownlint-disable-file MD007 -->
 
 Istio’s powerful APIs can be used to solve a variety of service mesh use cases. Many users know about its strong ingress and east-west capabilities but it also offers many features for egress (outgoing) traffic. This is especially useful when your application needs to talk to an external service - such as a database endpoint provided by a cloud provider. There are often multiple endpoints to chose from depending on where your workload is running. For example, Amazon's DynamoDB provides [several endpoints](https://docs.aws.amazon.com/general/latest/gr/ddb.html) across their regions. You typically want to choose the endpoint closest to your workload for latency reasons, but you may need to configure automatic failover to another endpoint in case things are not working as expected.
 

content/en/blog/2021/migrate-alpha-policy/index.md

@@ -5,7 +5,7 @@ publishdate: 2021-03-03
 attribution: Yangmin Zhu (Google), Craig Box (Google)
 keywords: [security,policy,migrate,alpha,beta,deprecate,peer,jwt,authorization]
 ---
-
+<!-- markdownlint-disable-file MD007 MD026 -->
 In versions of Istio prior to 1.4, security policy was configured using `v1alpha1` APIs (`MeshPolicy`, `Policy`, `ClusterRbacConfig`, `ServiceRole` and `ServiceRoleBinding`). After consulting with our early adopters, we made [major improvements to the policy system](/blog/2019/v1beta1-authorization-policy/) and released `v1beta1` APIs along with Istio 1.4. These refreshed APIs (`PeerAuthentication`, `RequestAuthentication` and `AuthorizationPolicy`) helped standardize how we define policy targets in Istio, helped users understand where policies were applied, and cut the number of configuration objects required.
 
 The old APIs were deprecated in Istio 1.4. Two releases after the `v1beta1` APIs were introduced, Istio 1.6 removed support for the `v1alpha1` APIs.

content/en/blog/2021/proxyless-grpc/index.md

@@ -4,6 +4,7 @@ description: Introduction to Istio support for gRPC's proxyless service mesh fea
 publishdate: 2021-10-28
 attribution: "Steven Landow (Google)"
 ---
+<!-- markdownlint-disable-file MD007 -->
 
 Istio dynamically configures its Envoy sidecar proxies using a set of discovery APIs, collectively known as the
 [xDS APIs](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/dynamic_configuration).

content/en/blog/2022/cryptomb-privatekeyprovider/index.md

@@ -5,7 +5,7 @@ publishdate: 2022-06-15
 attribution: "Ravi kumar Veeramally (Intel), Ismo Puustinen (Intel), Sakari Poussa (Intel)"
 keywords: [Istio, CryptoMB, gateways, sidecar]
 ---
-
+<!-- markdownlint-disable-file MD007 -->
 Cryptographic operations are among the most compute-intensive and critical operations when it comes to secured connections. Istio uses Envoy as the "gateways/sidecar" to handle secure connections and intercept the traffic.
 
 Depending upon use cases, when an ingress gateway must handle a large number of incoming TLS and secured service-to-service connections through sidecar proxies, the load on Envoy increases. The potential performance depends on many factors, such as size of the cpuset on which Envoy is running, incoming traffic patterns, and key size. These factors can impact Envoy serving many new incoming TLS requests. To achieve performance improvements and accelerated handshakes, a new feature was introduced in Envoy 1.20 and Istio 1.14. It can be achieved with 3rd Gen Intel® Xeon® Scalable processors, the Intel® Integrated Performance Primitives (Intel® IPP) crypto library, CryptoMB Private Key Provider Method support in Envoy, and Private Key Provider configuration in Istio using `ProxyConfig`.

content/en/blog/2022/get-started-ambient/index.md

@@ -5,6 +5,7 @@ publishdate: 2022-09-07T08:00:00-06:00
 attribution: "Lin Sun (Solo.io), John Howard (Google)"
 keywords: [ambient,demo,guide]
 ---
+<!-- markdownlint-disable-file MD007 -->
 
 {{< warning >}}
 Refer to the latest [getting started with ambient mesh doc](/docs/ambient/getting-started/) for updated instructions.

content/en/blog/2022/getting-started-gtwapi/index.md

@@ -5,6 +5,7 @@ publishdate: 2022-12-14
 attribution: Frank Budinsky (IBM)
 keywords: [traffic-management,gateway,gateway-api,api,gamma,sig-network]
 ---
+<!-- markdownlint-disable-file MD007 -->
 
 Whether you're running your Kubernetes application services using Istio, or any service mesh for that matter,
 or simply using ordinary services in a Kubernetes cluster, you need to provide access to your application services

content/en/blog/2023/dlb-connection-balancing/index.md

@@ -5,6 +5,7 @@ publishdate: 2023-08-08
 attribution: "Loong Dai (Intel)"
 keywords: [Istio, DLB, gateways]
 ---
+<!-- markdownlint-disable-file MD007 MD026 -->
 
 ## What is connection load balancing?
 

content/en/blog/2023/egress-sni/index.md

@@ -5,7 +5,7 @@ publishdate: 2023-12-01
 attribution: "Gergő Huszty (IBM)"
 keywords: [traffic-management,gateway,mesh,mtls,egress,remote]
 ---
-
+<!-- markdownlint-disable-file MD007 MD026 -->
 If you are using Istio to handle application-originated traffic to destinations outside of the mesh, you're probably familiar with the concept of egress gateways.
 Egress gateways can be used to monitor and forward traffic from mesh-internal applications to locations outside of the mesh.
 This is a useful feature if your system is operating in a restricted

content/en/blog/2023/native-sidecars/index.md

@@ -5,6 +5,7 @@ publishdate: 2023-08-15
 attribution: "John Howard (Google)"
 keywords: [istio,sidecars,kubernetes]
 ---
+<!-- markdownlint-disable-file MD007 -->
 
 If you have heard anything about service meshes, it is that they work using the sidecar pattern: a proxy server is deployed alongside your application code.
 The sidecar pattern is just that: a pattern.

content/en/blog/2023/waypoint-proxy-made-simple/index.md

@@ -5,6 +5,7 @@ publishdate: 2023-03-31
 attribution: "Lin Sun (Solo.io), John Howard (Google)"
 keywords: [istio,ambient,waypoint]
 ---
+<!-- markdownlint-disable-file MD007 -->
 
 Ambient splits Istio’s functionality into two distinct layers, a secure overlay layer and a
 Layer 7 processing layer. The waypoint proxy is an optional component that is Envoy-based

content/en/blog/2024/authz-policy-with-kyverno/index.md

@@ -5,6 +5,7 @@ publishdate: 2024-11-25
 attribution: "Charles-Edouard Brétéché (Nirmata)"
 keywords: [istio,kyverno,policy,platform,authorization]
 ---
+<!-- markdownlint-disable-file MD007 -->
 
 Istio supports integration with many different projects.  The Istio blog recently featured a post on [L7 policy functionality with OpenPolicyAgent](../l7-policy-with-opa). Kyverno is a similar project, and today we will dive how Istio and the Kyverno Authz Server can be used together to enforce Layer 7 policies in your platform.