fix some typo

website/docs/apimachinery/kubernetes-api.mdx

@@ -65,7 +65,7 @@ HTTP语境下的*Resource*的概念首次在[RFC 1630](rfc1630)中伴随URI(Unif
 
 也就是：**HTTP请求的"目标"即为*资源*，它可以是文档、图片或者是其他（存储在服务端的）任何"内容"**。
 :::tip 注
-这些"内容"也可以是是数据库中的一行数据，也可以是算法的执行结果等[^5]。
+这些"内容"也可以是数据库中的一行数据，也可以是算法的执行结果等[^5]。
 :::
 
 
@@ -101,13 +101,13 @@ HTTP语境下的*Resource*的概念首次在[RFC 1630](rfc1630)中伴随URI(Unif
 > * A single instance of a resource type is called a resource, and also usually represents an object
 
 
-事情似乎看起来并不简单，为了定义*Kubernetes资源*，官方还引入了*Resource Type*和*Kind*的概念。
+事情似乎看起来并不简单，为了定义*Kubernetes资源*，官方还引入了*resource type*和*kind*的概念。
 本节接下来的内容，便是对上述定义的详细解读。请跟随我一起开始了解这些术语吧。
 
 ## API分组（group）和版本化（version）
 
 :::tip 注
-为了解释清楚*Resource Type*、*Kind*、以及*Resource*这三个术语，我们需要从Kubernetes API URL的结构说起。
+为了解释清楚*resource type*、*kind*、以及*resource*这三个术语，我们需要从Kubernetes API URL的结构说起。
 :::
 
 为了便于扩展和迭代API，Kubernetes对所有API进行分组(API groups)和版本化(version)[^7]。
@@ -337,8 +337,8 @@ Kubernetes社区核心贡献者 [Jordan Liggitt](https://github.com/liggitt) 在
 我们按照文档[Kubernetes API terminology <KubernetesSVG />](https://kubernetes.io/docs/reference/using-api/api-concepts/#standard-api-terminology)的思路**严格地**定义了这些术语。
 经验告诉我们，越是严格的定义往往越是晦涩。
 
-当然这种严格也相应地带来一些好处——我们可以基于它更全面完整地了解最初对Kubernetes资源的全貌。
-Kubernetes资源既然是*kind*的实例，它们并不局限于以JSON的形式存在，它们可以是：YAML以及序列化后的字节流（bytes）。
+当然这种严格也相应地带来一些好处——我们可以更为全面地引申Kubernetes*资源*的所指。
+Kubernetes资源既然是*kind*的实例，那么它们将并不局限于以JSON的形式存在，它们也可以是：YAML格式甚至是（实例序列化后的）字节流（bytes）的形式等。
 同时，在Kubernetes系统中，这些数据形式又存在于多种媒介中：内存（`kubectl`，`kube-apiserver`，`kubelet`等）、网络（HTTP）、文件（YAML）、磁盘（etcd）。
 
 在绝大多数时候，我们对*Kubernetes资源*的第一种认知已经足够（即便它可能是模糊的）。

website/docs/client-go/controller.mdx

@@ -36,9 +36,8 @@ import StreamWatcherSVG from '@site/static/img/streamwatcher.svg';
 > Controllers continuously strive to make the observed state match the desired state, and report back their status to the apiserver asynchronously.
 
 
-意思是说控制器**只能**通过与Kubernetes API交互来实施协调动作，而不能直接访问状态集群的存储（etcd）或者其他私有的服务[^5]。
+意思是说控制器**只能**通过与Kubernetes API交互来实施协调动作，而不能直接访问状态集群的存储（etcd）或者其他私有的服务。
 
-控制器在Kubernetes**声明式资源管理系统**
 
 Kubernetes集群内置了一些原生资源的控制器，例如Job控制器等。
 当用户声明一个`job`资源后，Job控制器本身并不创建pod资源来执行任务，它而是通过Kubernetes API来创建pod资源来运行任务[^4]，并同时不断将`job`对象的状态"汇报"给Kubernetes API以写入`etcd`中。
@@ -234,7 +233,7 @@ for event := range eventChannel {
         > That is, it watches some object for the world's desired state, and it watches the world's actual state, too.
         > Then, it sends instructions to try and make the world's current state be more like the desired state.
 [^3]: Kubernetes控制器其实借用了自动化中*[closed-loop controller](https://en.wikipedia.org/wiki/Closed-loop_controller)*这个概念。在自动化里，closed-loop controller使用反馈来控制动态系统的状态或输出。它们在本质上是相通的。
-[^4]: 在Kubernetes系统中，真正创建pod资源的动作由kubelet组件完成。
+[^4]: 在Kubernetes系统中，真正创建pod资源的动作由`kubelet`组件完成。
 [^5]: 所谓HTTP"流"指的是HTTP 1.1的*分块传输编码*（[HTTP/1.1 Chunked Transfer Coding](https://en.wikipedia.org/wiki/Chunked_transfer_encoding)）。
       `kube-apiserver`会在返回的头（header）中
       设置`Transfer-Encoding`为`chunked`，表示采用分块传输编码，客户端每读完一个数据块（即资源的变更事件）后，会继续读取或等待下一个数据块，直到客户端主动终止连接或者读到长度为0的数据分块为止。

website/docs/client-go/restclient.mdx

@@ -166,7 +166,7 @@ func main() {
 在上述的例子中，我们说`RESTClient`基于建造者模式。其实更准确的说法是基于建造者模式的是`client-go`中的`Request`类型而非`RESTClient`。
 
 我们可以再回过头来具体看看`RESTClient`的接口`rest.Interface`，可以发现`RESTClient`的`Post()`，`Get()`，`Delete()`等方法其实返回是`Request`类型（指针），而不是`RESTClient`类型自身。
-真正执行向Kubernetes API发送请求动作的其实是是`Request`类型。
+真正执行向Kubernetes API发送请求动作的其实是`Request`类型。
 上述例子中的`Namespace()`，`Resource()`，`Name()`，`VersionedParams()`，等方法其实是`Request`类型的方法，这些方法返回的也是`Request`类型本身。所以`RESTClient`的链式调用其实在背后基于的是`Request`类型的建造者模式。