From 3c4e384413a319062a79670860533dcf810bbd31 Mon Sep 17 00:00:00 2001
From: Jason Chua <91486739+jchua99@users.noreply.github.com>
Date: Fri, 2 Feb 2024 16:28:03 +0800
Subject: [PATCH] linter

---
 README.md                           | 2 +-
 scripts/openyurt-deployer/README.md | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/README.md b/README.md
index c33e4d622..24e91a138 100644
--- a/README.md
+++ b/README.md
@@ -31,7 +31,7 @@ including functions autoscaling and cold-start delay optimization with several s
 
 vHive has added support for the state-of-the-art extension [eStargz](https://github.com/containerd/stargz-snapshotter) to container layers and lazy pull support for container images.
 
-vHive has added support for [OpenYurt](https://openyurt.io/), an open platform that extends upstream Kubernetes to the edge. It will assist in node management for cloud and edge nodes and can be deployed with scripts/openyurt-deployer.
+vHive has added support for [`OpenYurt`](https://openyurt.io/), an open platform that extends upstream Kubernetes to the edge. It will assist in node management for cloud and edge nodes and can be deployed with `scripts/openyurt-deployer`.
 
 ## vHive architecture
 
diff --git a/scripts/openyurt-deployer/README.md b/scripts/openyurt-deployer/README.md
index 406a19ee3..37b03ba5b 100644
--- a/scripts/openyurt-deployer/README.md
+++ b/scripts/openyurt-deployer/README.md
@@ -11,15 +11,15 @@ It support setting up a Kubernetes cluster using kubeadm and then deploy `OpenYu
 ### Key Features
 
 #### 1. Powerful edge autonomy capability
-OpenYurt addresses this issue by implementing a per-node proxy (YurtHub) along with local storage to cache the state of the cloud apiserver. Consequently, when a node loses its connection, the cached states remain accessible to Kubelet, KubeProxy, and any user Pods.
+`OpenYurt` addresses this issue by implementing a per-node proxy (`YurtHub`) along with local storage to cache the state of the cloud apiserver. Consequently, when a node loses its connection, the cached states remain accessible to Kubelet, `KubeProxy`, and any user Pods.
 
 #### 2. Cross NodePool network communication capability
 
-In an edge computing Kubernetes cluster, nodes are often distributed across various geographical regions. Consequently, when relying on a native Container Network Interface (CNI) solution, Pods within different NodePools may be unable to communicate using Pod IP, Service IP, or Node IP, particularly if each NodePool resides within its own isolated LAN. Raven offers a networking solution that enables cross-NodePool communication within an OpenYurt cluster.
+In an edge computing Kubernetes cluster, nodes are often distributed across various geographical regions. Consequently, when relying on a native Container Network Interface (CNI) solution, Pods within different `NodePools` may be unable to communicate using Pod IP, Service IP, or Node IP, particularly if each `NodePool` resides within its own isolated LAN. Raven offers a networking solution that enables `cross-NodePool` communication within an `OpenYurt` cluster.
 
 #### 3. Multi-NodePool Management
 
-In order to manage applications and traffic in multiple nodepools conveniently, YurtAppSet and YurtAppDaemon are introduced for managing workloads in multi-nodepool, and service topology capability for routing traffic in nodepool.
+In order to manage applications and traffic in multiple nodepools conveniently, `YurtAppSet` and `YurtAppDaemon` are introduced for managing workloads in multi-nodepool, and service topology capability for routing traffic in nodepool.
 
 ## 2. Brief overview