Pod控制器（一）ReplicaSet
?
目錄
1、關(guān)于Pod控制器
1.1Pod控制器概述
1.2 控制器與Pod對(duì)象
1.3 ReplicaSet控制器
1.3.1? ReplicaSet概述
1.3.2? 創(chuàng)建ReplicaSet
1.3.3 ReplicaSet管控下的Pod對(duì)象
1.3.4? 更新ReplicaSet控制器
1.3.5?? 刪除ReplicaSet控制器資源
?
1、關(guān)于Pod控制器
我們可以把API Server類比成一個(gè)存儲(chǔ)對(duì)象的數(shù)據(jù)庫系統(tǒng)，它向客戶端提供了API，并負(fù)責(zé)存儲(chǔ)由用戶創(chuàng)建的各種資源對(duì)象，至于各對(duì)象的當(dāng)前狀態(tài)如何才能符合用戶期望的狀態(tài)，則需要交由另一類稱為控制器的組件來負(fù)責(zé)完成。Kubernetes提供了眾多的控制器來管理各種類型的資源，如Node Lifecycle Controller、Namespace Controller、Service Controller和Deployment Controller等，它們的功用幾乎可以做到見名知義。創(chuàng)建完成后，每一個(gè)控制器對(duì)象都可以通過內(nèi)部的和解循環(huán) （reconciliation loop），不間斷地監(jiān)控著由其負(fù)責(zé)的所有資源并確保其處于或不斷地逼近用戶定義的目標(biāo)狀態(tài)。
盡管能夠由kubelet為其提供自愈能力，但在節(jié)點(diǎn)宕機(jī)時(shí)，自主式Pod對(duì)象的重建式自愈機(jī)制則需要由Pod控制器對(duì)象負(fù)責(zé)提供，并且由它來負(fù)責(zé)實(shí)現(xiàn)生命周期中的各類自動(dòng)管理行為，如創(chuàng)建及刪除等。
1.1Pod控制器概述
Master的各組件中，API Server僅負(fù)責(zé)將資源存儲(chǔ)于etcd中，并將其變動(dòng)通知給各相關(guān)的客戶端程序，如kubelet、kube-scheduler、kube-proxy和kube-controller-manager等，kube-scheduler監(jiān)控到處于未綁定狀態(tài)的Pod對(duì)象出現(xiàn)時(shí)遂啟動(dòng)調(diào)度器為其挑選適配的工作節(jié)點(diǎn)，然而， Kubernetes的核心功能之一還在于要確保各資源對(duì)象的當(dāng)前狀態(tài) （status）以匹配用戶期望的狀態(tài)（spec），使當(dāng)前狀態(tài)不斷地向期望狀態(tài)“和解”（reconciliation）來完成容器應(yīng)用管理，而這些則是kube-controller-manager的任務(wù)。kube-controller-manager是一個(gè)獨(dú)立的單體守護(hù)進(jìn)程，然而它包含了眾多功能不同的控制器類型分別用于各類和解任務(wù)，如圖5-1所示。
提示 Kubernetes可用的控制器有attachdetach、bootstrapsigner、clusterrole-aggregation、cronjob、csrapproving、 csrcleaner、csrsigning、daemonset、deployment、disruption、endpoint、 garbagecollector、horizontalpodautoscaling、job、namespace、node、 persistentvolume-binder、persistentvolume-expander、podgc、pvc-protection、replicaset、replication- controller、resourcequota、route、service、serviceaccount、serviceaccount-token、statefulset、tokencleaner和ttl等數(shù)十種。創(chuàng)建為具體的控制器對(duì)象之后，每個(gè)控制器均通過API Server提供的接口持續(xù)監(jiān)控相關(guān)資源對(duì)象的當(dāng)前狀態(tài)，并在因故障、更新或其他原因?qū)е孪到y(tǒng)狀態(tài)發(fā)生變化時(shí)，嘗試讓資源的當(dāng)前狀態(tài)向期望狀態(tài)遷移和逼近。簡單來說，每個(gè)控制器對(duì)象運(yùn)行一個(gè)和解循環(huán)負(fù)責(zé)狀態(tài)和解，并將目標(biāo)資源對(duì)象的當(dāng)前狀態(tài)寫入到其status字段中。控制器的“和解”循環(huán)如圖5-2所示。
List-Watch是Kubernetes實(shí)現(xiàn)的核心機(jī)制之一，在資源對(duì)象的狀態(tài)發(fā)生變動(dòng)時(shí)，由API Server負(fù)責(zé)寫入etcd并通過水平觸發(fā)（level-triggered）機(jī)制主動(dòng)通知給相關(guān)的客戶端程序以確保其不會(huì)錯(cuò)過任何一個(gè)事件。控制器通過API Server的watch接口實(shí)時(shí)監(jiān)控目標(biāo)資源對(duì)象的變動(dòng)并執(zhí)行和解操作，但并不會(huì)與其他控制器進(jìn)行任何交互，甚至彼此之間根本就意識(shí)不到對(duì)方的存在。
工作負(fù)載（workload）一類的控制器資源類型包括ReplicationController、ReplicaSet、Deployment、DaemonSet、 StatefulSet、Job和CronJob等，它們分別代表了一種類型的Pod控制器資源，后面的篇幅主要介紹各控制器的特性及其應(yīng)用，不過StatefulSet控制器依賴于存儲(chǔ)卷資源，因此它將單獨(dú)在存儲(chǔ)卷之后的章節(jié)中給予介紹。
?
1.2 控制器與Pod對(duì)象
Pod控制器資源通過持續(xù)性地監(jiān)控集群中運(yùn)行著的Pod資源對(duì)象來確保受其管控的資源嚴(yán)格符合用戶期望的狀態(tài)，例如資源副本的數(shù)量要精確符合期望等。通常，一個(gè)Pod控制器資源至少應(yīng)該包含三個(gè)基本的組成部分。- 標(biāo)簽選擇器：匹配并關(guān)聯(lián)Pod資源對(duì)象，并據(jù)此完成受其管控的Pod資源計(jì)數(shù)。
- 期望的副本數(shù)：期望在集群中精確運(yùn)行著的Pod資源的對(duì)象數(shù)量。
- Pod模板：用于新建Pod資源對(duì)象的Pod模板資源。
注意：DaemonSet用于確保集群中的每個(gè)工作節(jié)點(diǎn)或符合條件的每個(gè)節(jié)點(diǎn)上都運(yùn)行著一個(gè)Pod副本，而不是某個(gè)精確的數(shù)量值，因此不具有上面組成部分中的第二項(xiàng)。
例如，一個(gè)如圖5-3所示的Deployment控制器資源使用的標(biāo)簽選擇器為“role=be-eshop”，它期望相關(guān)的Pod資源副本數(shù)量精確為3個(gè)，少于此數(shù)量的缺失部分將由控制器通過Pod模板予以創(chuàng)建，而多出的副本也將由控制器負(fù)責(zé)終止及刪除。1.3 ReplicaSet控制器
1.3.1? ReplicaSet概述
ReplicaSet（簡稱RS）是Pod控制器類型的一種實(shí)現(xiàn)，用于確保由其管控的Pod對(duì)象副本數(shù)在任一時(shí)刻都能精確滿足期望的數(shù)量。如圖5-4所示，ReplicaSet控制器資源啟動(dòng)后會(huì)查找集群中匹配其標(biāo)簽選擇器的Pod資源對(duì)象，當(dāng)前活動(dòng)對(duì)象的數(shù)量與期望的數(shù)量不吻合時(shí)，多則刪除，少則通過Pod模板創(chuàng)建以補(bǔ)足，等Pod資源副本數(shù)量符合期望值后即進(jìn)入下一輪和解循環(huán)。
ReplicaSet的副本數(shù)量、標(biāo)簽選擇器甚至是Pod模板都可以隨時(shí)按需進(jìn)行修改，不過僅改動(dòng)期望的副本數(shù)量會(huì)對(duì)現(xiàn)存的Pod副本產(chǎn)生直接影響。修改標(biāo)簽選擇器可能會(huì)使得現(xiàn)有的Pod副本的標(biāo)簽變得不再匹配，此時(shí)ReplicaSet控制器要做的不過是不再計(jì)入它們而已。另外，在創(chuàng)建完成后，ReplicaSet也不會(huì)再關(guān)注Pod對(duì)象中的實(shí)際內(nèi)容，因此Pod模板的改動(dòng)也只會(huì)對(duì)后來新建的Pod副本產(chǎn)生影響。
相比較于手動(dòng)創(chuàng)建和管理Pod資源來說，ReplicaSet能夠?qū)崿F(xiàn)以下功能。- 確保Pod資源對(duì)象的數(shù)量精確反映期望值：ReplicaSet需要確保由其控制運(yùn)行的Pod副本數(shù)量精確吻合配置中定義的期望值，否則就會(huì)自動(dòng)補(bǔ)足所缺或終止所余。
- 確保Pod健康運(yùn)行：探測到由其管控的Pod對(duì)象因其所在的工作節(jié)點(diǎn)故障而不可用時(shí)，自動(dòng)請(qǐng)求由調(diào)度器于其他工作節(jié)點(diǎn)創(chuàng)建缺失的Pod副本
- 彈性伸縮：業(yè)務(wù)規(guī)模因各種原因時(shí)常存在明顯波動(dòng)，在波峰或波谷期間，可以通過ReplicaSet控制器動(dòng)態(tài)調(diào)整相關(guān)Pod資源對(duì)象的數(shù)量。 此外，在必要時(shí)還可以通過HPA（HroizontalPodAutoscaler）控制器實(shí)現(xiàn)Pod資源規(guī)模的自動(dòng)伸縮。
1.3.2? 創(chuàng)建ReplicaSet
類似于Pod資源，創(chuàng)建ReplicaSet控制器對(duì)象同樣可以使用YAML或JSON格式的清單文件定義其配置，而后使用相關(guān)的創(chuàng)建命令來完成資源創(chuàng)建。它也由kind、apiVersion、metadata、spec和status這5個(gè)一級(jí)字段組成，其中status為只讀字段，因此需要在清單文件中配置的僅為前4個(gè)字段。它的spec字段一般嵌套使用以下幾個(gè)屬性字段。
- replicas<integer>：期望的
- selector<Object>：當(dāng)前控制器匹配Pod對(duì)象副本的標(biāo)簽選擇器，支持matchLabels和matchExpressions兩種匹配機(jī)制。
- template<Object>：用于補(bǔ)足Pod副本數(shù)量時(shí)使用的Pod模板資源。
- minReadySecond<integer>s：新建的Pod對(duì)象，在啟動(dòng)后的多長時(shí)間內(nèi)如果其容器未發(fā)生崩潰等異常情況即被視為“就緒”；默認(rèn)為0秒，表示一旦就緒性探測成功，即被視作可用。
[root@master ~]# vim replicaSet.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
? name: rs-example
spec:
? replicas: 2
? selector:
???? matchLabels:
?????? app: rs-demo
? template:
??? metadata:
????? labels:
??????? app: rs-demo
??? spec:
????? containers:
????? - name: myapp
??????? image: ikubernetes/myapp:v1
??????? ports:
??????? - name: http
????????? containerPort: 80
[root@master ~]# kubectl apply -f replicaSet.yaml
replicaset.apps/rs-example created
?
集群中當(dāng)前沒有標(biāo)簽為“app：rs-demo”的Pod資源存在，因此rs-example需要按照replicas字段的定義創(chuàng)建它們，名稱以其所屬的控制器名稱為前綴。這兩個(gè)Pod資源一開始都處于ContainerCreating狀態(tài)，即處于 容器創(chuàng)建過程中，待創(chuàng)建過程完成后，其狀態(tài)即轉(zhuǎn)為Running，Pod也將 轉(zhuǎn)變?yōu)?/span>“READY”： [root@master ~]# kubectl get pods -l app=rs-demo NAME?????????????? READY?? STATUS??? RESTARTS?? AGErs-example-ms4ps?? 1/1???? Running?? 0????????? 113s
rs-example-t6w67?? 1/1???? Running?? 0????????? 113s 接下來可以使用“kubectl get replicaset”命令查看ReplicaSet控制器資源的相關(guān)狀態(tài)。下面的命令結(jié)果顯示出它已經(jīng)根據(jù)清單中配置的Pod模板創(chuàng)建了2個(gè)Pod資源，這時(shí)它們已創(chuàng)建完成：
[root@master ~]# kubectl get replicaset rs-example -o wide
NAME???????? DESIRED?? CURRENT?? READY?? AGE???? CONTAINERS?? IMAGES???????????????? SELECTOR
rs-example?? 2???????? 2???????? 2?????? 4m59s?? myapp??????? ikubernetes/myapp:v1?? app=rs-demo
- DESIRED：期望有幾個(gè)pod
- CURRENT：當(dāng)前一共有幾個(gè)pod
- READY：有幾個(gè)pod已經(jīng)就緒了
- AGE：什么時(shí)間創(chuàng)建的
?
1.3.3 ReplicaSet管控下的Pod對(duì)象
上面創(chuàng)建的rc-example通過標(biāo)簽選擇器將擁有“app=rs-demo”標(biāo)簽的Pod資源收歸于麾下，并確保其數(shù)量精確符合所期望的數(shù)目，使用標(biāo)簽選擇器顯示出的Pod資源列表也能驗(yàn)證這一點(diǎn)。然而，實(shí)際中存著不少可能導(dǎo)致Pod對(duì)象數(shù)目與期望值不符合的可能性，如Pod對(duì)象的意外刪除、Pod對(duì)象標(biāo)簽的變動(dòng)（已有的Pod資源變得不匹配控制器的標(biāo)簽選擇器，或者外部的Pod資源標(biāo)簽變得匹配到了控制器的標(biāo)簽選擇器）、控制器的標(biāo)簽選擇器變動(dòng)，甚至是工作節(jié)點(diǎn)故障等。ReplicaSet 控制器的和解循環(huán)過程能夠?qū)崟r(shí)監(jiān)控到這類異常，并及時(shí)啟動(dòng)和解操作。
1.缺少Pod副本
任何原因?qū)е碌南嚓P(guān)Pod對(duì)象丟失，都會(huì)由ReplicaSet控制器自動(dòng)補(bǔ)足。例如，手動(dòng)刪除上面列出的一個(gè)Pod對(duì)象，命令如下：[root@master ~]# kubectl delete pods rs-example-ms4ps
pod "rs-example-ms4ps" deleted
[root@master ~]# kubectl get pods -l app=rs-demo -o wide
NAME?????????????? READY?? STATUS??????? RESTARTS?? AGE?? IP??????????? NODE??? NOMINATED NODE?? READINESS GATES
rs-example-cwxgh?? 1/1???? Running?????? 0????????? 3s??? 10.244.1.11?? node1?? <none>?????????? <none>
rs-example-t6w67?? 0/1???? Terminating?? 0????????? 14m?? 10.244.1.10?? node1?? <none>?????????? <none>
rs-example-zcjmj?? 1/1???? Running?????? 0????????? 3m??? 10.244.2.11?? node2?? <none>?????????? <none>??
?另外，強(qiáng)行修改隸屬于控制器rs-example的某Pod資源（匹配于標(biāo)簽控制器）的標(biāo)簽，會(huì)導(dǎo)致它不再被控制器作為副本計(jì)數(shù)，這也將觸發(fā)控制器的Pod對(duì)象副本缺失補(bǔ)足機(jī)制。例如，將rs-example-p66nv的標(biāo)簽app的值置空：
[root@master ~]# kubectl label pods rs-example-cwxgh app=? --overwritepod/rs-example-cwxgh labeled 列出rs-example相關(guān)Pod對(duì)象的信息，發(fā)現(xiàn)rs-example-cwxgh已經(jīng)消失不見，并且正在創(chuàng)建新的對(duì)象副本
[root@master ~]# kubectl get pods -l app=rs-demo
NAME?????????????? READY?? STATUS??? RESTARTS?? AGE
rs-example-q494g?? 1/1???? Running?? 0????????? 38s
rs-example-zcjmj?? 1/1???? Running?? 0????????? 7m16s
2.多出Pod副本
一旦被標(biāo)簽選擇器匹配到的Pod資源數(shù)量因任何原因超出期望值，多余的部分都將被控制器自動(dòng)刪除。例如，為mypod手動(dòng)為其添 加“app：rs-demo”標(biāo)簽：[root@master ~]# kubectl label pods mypod app=rs-demo
pod/mypod labeled
[root@master ~]# kubectl get pods -l app=rs-demo
NAME?????????????? READY?? STATUS??? RESTARTS?? AGE
mypod????????????? 1/1???? Running?? 0????????? 6d23h
rs-example-zcjmj?? 1/1???? Running?? 0????????? 16m
3.查看Pod資源變動(dòng)的相關(guān)事件
“kubectl describe replicasets”命令可打印出ReplicaSet控制器的詳細(xì)狀態(tài)，從下面命令結(jié)果中Events一段也可以看出，rs-example執(zhí)行了Pod 資源的創(chuàng)建和刪除操作，為的就是確保其數(shù)量的精確性。[root@master ~]# kubectl describe replicasets/rs-example
Name:???????? rs-example
Namespace:??? default
Selector:???? app=rs-demo
Labels:?????? <none>
Annotations:? <none>
Replicas:???? 2 current / 2 desired
Pods Status:? 2 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
? Labels:? app=rs-demo
? Containers:
?? myapp:
??? Image:??????? ikubernetes/myapp:v1
??? Port:???????? 80/TCP
??? Host Port:??? 0/TCP
??? Environment:? <none>
??? Mounts:?????? <none>
? Volumes:??????? <none>
Events:
? Type??? Reason??????????? Age??? From?????????????????? Message
? ----??? ------??????????? ----?? ----?????????????????? -------
? Normal? SuccessfulCreate? 32m??? replicaset-controller? Created pod: rs-example-ms4ps
? Normal? SuccessfulCreate? 32m??? replicaset-controller? Created pod: rs-example-t6w67
? Normal? SuccessfulCreate? 20m??? replicaset-controller? Created pod: rs-example-zcjmj
? Normal? SuccessfulCreate? 17m??? replicaset-controller? Created pod: rs-example-cwxgh
? Normal? SuccessfulCreate? 14m??? replicaset-controller? Created pod: rs-example-q494g
? Normal? SuccessfulDelete? 4m48s? replicaset-controller? Deleted pod: rs-example-q494g
?
1.3.4? 更新ReplicaSet控制器
ReplicaSet控制器的核心組成部分是標(biāo)簽選擇器、副本數(shù)量及Pod模板，但更新操作一般是圍繞replicas和template兩個(gè)字段值進(jìn)行的，畢竟改變標(biāo)簽選擇器的需求幾乎不存在。改動(dòng)Pod模板的定義對(duì)已經(jīng)創(chuàng)建完成的活動(dòng)對(duì)象無效，但在用戶逐個(gè)手動(dòng)關(guān)閉其舊版本的Pod資源后就能 以新代舊，實(shí)現(xiàn)控制器下應(yīng)用版本的滾動(dòng)升級(jí)。另外，修改副本的數(shù)量也就意味著應(yīng)用規(guī)模的擴(kuò)展（提升期望的副本數(shù)量）或收縮（降低期望的副本數(shù)量）。這兩種操作也是系統(tǒng)運(yùn)維人員日常維護(hù)工作的重要組成部分。1.更改Pod模板：升級(jí)應(yīng)用
ReplicaSet控制器的Pod模板可隨時(shí)按需修改，但它僅影響這之后由其新建的Pod對(duì)象，對(duì)已有的副本不會(huì)產(chǎn)生作用。大多數(shù)情況下，用戶需要改變的通常是模板中的容器鏡像文件及其相關(guān)的配置以實(shí)現(xiàn)應(yīng)用的 版本升級(jí)。下面的示例清單文件片斷（replicaSet-v2.yaml）中的內(nèi)容與 之前版本（replicaSet.yaml）的唯一不同之處也僅在于鏡像文件的改動(dòng)：?
[root@master ~]# vim replicaSet-v2.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
? name: rs-example
spec:
? replicas: 2
? selector:
???? matchLabels:
?????? app: rs-demo
? template:
??? metadata:
????? labels:
??????? app: rs-demo
??? spec:
????? containers:
????? - name: myapp
??????? image: ikubernetes/myapp:v2
??????? ports:
??????? - name: http
????????? containerPort: 80
[root@master ~]# kubectl apply -f replicaSet-v2.yaml
replicaset.apps/rs-example configured
[root@master ~]# kubectl get pods -l app=rs-demo -o? custom-columns=Name:metadata.name,Image:spec.containers[0].image
Name?????????????? Image
mypod????????????? ikubernetes/myapp:v1
rs-example-zcjmj?? ikubernetes/myapp:v1
- 一次性刪除控制器相關(guān)的所有Pod副本或更改相關(guān)的標(biāo)簽：劇烈更替，可能會(huì)導(dǎo)致Pod中的應(yīng)用短時(shí)間不可訪問（如圖所示）；生產(chǎn)實(shí)踐中，此種做法不可取。
- 分批次刪除舊有的Pod副本或更改其標(biāo)簽（待控制器補(bǔ)足后再刪除另一批）：滾動(dòng)更替，更替期間新舊版本共存（如圖所示）。
[root@master ~]# kubectl delete pods -l app=rs-demo
pod "mypod" deleted
pod "rs-example-zcjmj" deleted
[root@master ~]# kubectl get pods -l app=rs-demo -o? custom-columns=Name:metadata.name,Image:spec.containers[0].image
Name?????????????? Image
rs-example-jdp8k?? ikubernetes/myapp:v2
rs-example-zrm66?? ikubernetes/myapp:v2
2.擴(kuò)容和縮容
改動(dòng)ReplicaSet控制器對(duì)象配置中期望的Pod副本數(shù)量（replicas字段）會(huì)由控制器實(shí)時(shí)做出響應(yīng)，從而實(shí)現(xiàn)應(yīng)用規(guī)模的水平伸縮。replicas的修改及應(yīng)用方式同Pod模板，不過，kubectl還提供了一個(gè)專用的子命令scale用于實(shí)現(xiàn)應(yīng)用規(guī)模的伸縮，它支持從資源清單文件中獲取新的目 標(biāo)副本數(shù)量，也可以直接在命令行通過“--replicas”選項(xiàng)進(jìn)行讀取，例如 將rs-example控制器的Pod副本數(shù)量提升至5個(gè)： [root@master ~]# kubectl scale replicasets rs-example --replicas=5replicaset.apps/rs-example scaled 由下面顯示的rs-example資源的狀態(tài)可以看出，將其Pod資源副本數(shù)量擴(kuò)展至5個(gè)的操作已經(jīng)成功完成：
[root@master ~]# kubectl get replicasets rs-example
NAME???????? DESIRED?? CURRENT?? READY?? AGE
rs-example?? 5???????? 5???????? 5?????? 88m
replicaset.apps/rs-example scaled 另外，kubectl scale命令還支持在現(xiàn)有Pod副本數(shù)量符合指定的值時(shí)才執(zhí)行擴(kuò)展操作，這僅需要為命令使用“--current-replicas”選項(xiàng)即可。例如，下面的命令表示如果rs-example目前的Pod副本數(shù)量為2，就將其擴(kuò)展至4個(gè)：
[root@master ~]# kubectl scale replicasets rs-example --current-replicas=2 --replicas=4
error: Expected replicas to be 2, was 3
1.3.5?? 刪除ReplicaSet控制器資源
使用kubectl delete命令刪除ReplicaSet對(duì)象時(shí)默認(rèn)會(huì)一并刪除其管控的各Pod對(duì)象。有時(shí)，考慮到這些Pod資源未必由其創(chuàng)建，或者即便由其創(chuàng)建卻也并非其自身的組成部分，故而可以為命令使用“-- cascade=false”選項(xiàng)，取消級(jí)聯(lián)，刪除相關(guān)的Pod對(duì)象，這在Pod資源后續(xù)可能會(huì)再次用到時(shí)尤有用。例如，刪除rs控制器rs-example： [root@master ~]# kubectl delete replicasets rs-example --cascade=falsereplicaset.apps "rs-example" deleted 刪除操作完成后，此前由rs-example控制器管控的各Pod對(duì)象仍處于活動(dòng)狀態(tài)，但它們變成了自主式Pod資源，用戶需要自行組織和維護(hù)好它們。 盡管ReplicaSet控制器功能強(qiáng)大，但在實(shí)踐中，它卻并非是用戶直接使用的控制器，而是要由比其更高一級(jí)抽象的Deployment控制器對(duì)象來調(diào)用
總結(jié)
以上是生活随笔為你收集整理的Pod控制器（一）ReplicaSet的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java判断数字整数_JAVA判断数字、
- 下一篇： LIN总线知识基础