1、請簡述OSI七層網絡模型有哪些層及各自的含義?

• 物理層：底層數據傳輸，比如網線、網卡標準
• 數據鏈路層：定義數據的基本格式，如何傳輸，如何標識。比如網卡mac地址
• 網絡層：定義IP編碼，定義路由功能，比如不同設備的數據轉發
• 傳輸層：端到端傳輸數據的基本功能，比如TCP、UDP
• 會話層：控制應用程序之間會話能力，比如不同軟件數據分發給不停軟件
• 表示層：數據格式標識，基本壓縮加密功能。
• 應用層：各種應用軟件，包括 Web 應用。

2、在linux的LVM分區格式下，請簡述給根分區磁盤擴容的步驟?

這個分3種

第一種方法:

growpart /dev/vda 1
resize2fs /dev/vda1    

第二種方法:

partpeobe /dev/sda
resize2fs /dev/vda1    

第三種方法:

fdisk /dev/sdb   # n p 1 1 回車 回車 t 8e w
pvcreate /dev/sdb1
vgextend datavg /dev/sdb1
lvextend -r -L +100%free /dev/mApper/datavg-lv01

3、講述一下Tomcat8005、8009、8080三個端口的含義？

• 8005 關閉時使用
• 8009為AJP端口，即容器使用，如Apache能通過AJP協議訪問Tomcat的8009端口來實現功能
• 8080 一般應用使用

4、簡述DNS進行域名解析的過程？

迭代查詢（返回最優結果）、遞歸查詢（本地找DNS）用戶要訪問 www.baidu.com，會先找本機的host文件，再找本地設置的DNS服務器，如果也沒有找到，就去網絡中找根服務器，根服務器反饋結果，說只能提供一級域名服務器.cn，就去找一級域名服務器，一級域名服務器說只能提供二級域名服務器.com.cn,就去找二級域名服務器，二級域服務器只能提供三級域名服務器.baidu.com.cn，就去找三級域名服務器，三級域名服務器正好有這個網站www.baidu.com，然后發給請求的服務器，保存一份之后，再發給客戶端。

5、講一下Keepalived的工作原理？

在一個虛擬路由器中，只有作為MASTER的VRRP(虛擬路由冗余協議)路由器會一直發送VRRP通告信息，BACKUP不會搶占MASTER，除非它的優先級更高。當MASTER不可用時(BACKUP收不到通告信息)多臺BACKUP中優先級最高的這臺會被搶占為MASTER。這種搶占是非常快速的(<1s)，以保證服務的連續性由于安全性考慮，VRRP包使用了加密協議進行加密。BACKUP不會發送通告信息，只會接收通告信息。

6、LVS、Nginx、HAproxy有什么區別？工作中你怎么選擇？

LVS：

• 抗負載能力強、工作在第4層僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟件里的性能最強的；無流量，同時保證了均衡器IO的性能不會受到大流量的影響；
• 工作穩定，自身有完整的雙機熱備方案，如LVS+Keepalived和LVS+Heartbeat；
• 應用范圍比較廣，可以對所有應用做負載均衡；
• 配置簡單，因為沒有可太多配置的東西，所以并不需要太多接觸，大大減少了人為出錯的幾率；

LVS的缺點：

• 軟件本身不支持正則處理，不能做動靜分離，這就凸顯了Nginx/HAProxy+Keepalived的優勢。
• 如果網站應用比較龐大，LVS/DR+Keepalived就比較復雜了，特別是后面有windows Server應用的機器，實施及配置還有維護過程就比較麻煩，相對而言，Nginx/HAProxy+Keepalived就簡單多了。

Nginx：

• 工作在第7層，應用層，可以針對http應用做一些分流的策略。比如針對域名、目錄結構。它的正則比HAProxy更為強大和靈活；
• Nginx對網絡的依賴非常小，理論上能ping通就就能進行負載功能
• Nginx安裝和配置簡單
• 可以承擔高的負載壓力且穩定，一般能支撐超過幾萬次的并發量；
• Nginx不僅僅是一款優秀的負載均衡器/反向代理軟件，它同時也是功能強大的Web應用服務器。Nginx在處理靜態頁面、特別是抗高并發方面相對apache有優勢；
• Nginx作為Web反向代理加速緩存越來越成熟，速度比傳統的Squid服務器更快

Nginx的缺點：

• Nginx不支持url來檢測。
• Nginx僅能支持http、https和Email協議
• Nginx的Session的保持，Cookie的引導能力相對欠缺。

HAProxy：

• HAProxy是支持虛擬主機的，可以工作在4、7層(支持多網段)；
• 能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作；
• 支持url檢測后端的服務器；
• 它跟LVS一樣，本身僅僅就只是一款負載均衡軟件；單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度，在并發處理上也是優于Nginx的；
• HAProxy可以對MySQL讀進行負載均衡，對后端的MySQL節點進行檢測和負載均衡，不過在后端的MySQL slaves數量超過10臺時性能不如LVS；
• HAProxy的算法較多，達到8種；

工作選擇：

HAproxy和Nginx由于可以做七層的轉發，所以URL和目錄的轉發都可以做在很大并發量的時候我們就要選擇LVS，像中小型公司的話并發量沒那么大選擇HAproxy或者Nginx足已，由于HAproxy由是專業的代理服務器配置簡單，所以中小型企業推薦使用HAproxy。

7、Docker的工作原理是什么，講一下

docker是一個Client-Server結構的系統，docker守護進程運行在宿主機上，守護進程從客戶端接受命令并管理運行在主機上的容器，容器是一個運行時環境，這就是我們說的集裝箱。

8、docker的組成包含哪幾大部分

一個完整的docker有以下幾個部分組成：

• docker client，客戶端，為用戶提供一系列可執行命令，用戶用這些命令實現跟 docker daemon 交互；
• docker daemon，守護進程，一般在宿主主機后臺運行，等待接收來自客戶端的請求消息；
• docker image，鏡像，鏡像run之后就生成為docker容器；
• docker container，容器，一個系統級別的服務，擁有自己的ip和系統目錄結構；運行容器前需要本地存在對應的鏡像，如果本地不存在該鏡像則就去鏡像倉庫下載。

docker 使用客戶端-服務器 (C/S) 架構模式，使用遠程api來管理和創建docker容器。docker 容器通過 docker 鏡像來創建。容器與鏡像的關系類似于面向對象編程中的對象與類。

9、docker與傳統虛擬機的區別什么？

• 傳統虛擬機是需要安裝整個操作系統的，然后再在上面安裝業務應用，啟動應用，通常需要幾分鐘去啟動應用，而docker是直接使用鏡像來運行業務容器的，其容器啟動屬于秒級別；
• Docker需要的資源更少，Docker在操作系統級別進行虛擬化，Docker容器和內核交互，幾乎沒有性能損耗，而虛擬機運行著整個操作系統，占用物理機的資源就比較多;
• Docker更輕量，Docker的架構可以共用一個內核與共享應用程序庫，所占內存極小;同樣的硬件環境，Docker運行的鏡像數遠多于虛擬機數量，對系統的利用率非常高;
• 與虛擬機相比，Docker隔離性更弱，Docker屬于進程之間的隔離，虛擬機可實現系統級別隔離;
• Docker的安全性也更弱，Docker的租戶root和宿主機root相同，一旦容器內的用戶從普通用戶權限提升為root權限，它就直接具備了宿主機的root權限，進而可進行無限制的操作。虛擬機租戶root權限和宿主機的root虛擬機權限是分離的，并且虛擬機利用如Intel的VT-d和VT-x的ring-1硬件隔離技術，這種技術可以防止虛擬機突破和彼此交互，而容器至今還沒有任何形式的硬件隔離;
• Docker的集中化管理工具還不算成熟，各種虛擬化技術都有成熟的管理工具，比如：VMware vCenter提供完備的虛擬機管理能力;
• Docker對業務的高可用支持是通過快速重新部署實現的，虛擬化具備負載均衡，高可用、容錯、遷移和數據保護等經過生產實踐檢驗的成熟保障機制，Vmware可承諾虛擬機99.999%高可用，保證業務連續性;
• 虛擬化創建是分鐘級別的，Docker容器創建是秒級別的，Docker的快速迭代性，決定了無論是開發、測試、部署都可以節省大量時間;
• 虛擬機可以通過鏡像實現環境交付的一致性，但鏡像分發無法體系化，Docker在Dockerfile中記錄了容器構建過程，可在集群中實現快速分發和快速部署。from wljslmz

10、docker技術的三大核心概念是什么？

• 鏡像：鏡像是一種輕量級、可執行的獨立軟件包，它包含運行某個軟件所需的所有內容，我們把應用程序和配置依賴打包好形成一個可交付的運行環境(包括代碼、運行時需要的庫、環境變量和配置文件等)，這個打包好的運行環境就是image鏡像文件。
• 容器：容器是基于鏡像創建的，是鏡像運行起來之后的一個實例，容器才是真正運行業務程序的地方。如果把鏡像比作程序里面的類，那么容器就是對象。
• 鏡像倉庫：存放鏡像的地方，研發工程師打包好鏡像之后需要把鏡像上傳到鏡像倉庫中去，然后就可以運行有倉庫權限的人拉取鏡像來運行容器了。

11、centos鏡像幾個G，但是docker centos鏡像才幾百兆，這是為什么？

一個完整的Linux操作系統包含Linux內核和rootfs根文件系統，即我們熟悉的/dev、/proc/、/bin等目錄。我們平時看到的centOS除了rootfs，還會選裝很多軟件，服務，圖形桌面等，所以centOS鏡像有好幾個G也不足為奇。

而對于容器鏡像而言，所有容器都是共享宿主機的Linux 內核的，而對于docker鏡像而言，docker鏡像只需要提供一個很小的rootfs即可，只需要包含最基本的命令，工具，程序庫即可，所有docker鏡像才會這么小。

12、講一下鏡像的分層結構以及為什么要使用鏡像的分層結構？

一個新的鏡像其實是從 base 鏡像一層一層疊加生成的。每安裝一個軟件，dockerfile中使用RUM命令，就會在現有鏡像的基礎上增加一層，這樣一層一層的疊加最后構成整個鏡像。所以我們docker pull拉取一個鏡像的時候會看到docker是一層層拉去的。

分層機構最大的一個好處就是 ：共享資源。比如：有多個鏡像都從相同的 base 鏡像構建而來，那么 Docker Host 只需在磁盤上保存一份 base 鏡像；同時內存中也只需加載一份 base 鏡像，就可以為所有容器服務了。而且鏡像的每一層都可以被共享。

13、講一下容器的copy-on-write特性，修改容器里面的內容會修改鏡像嗎？

我們知道，鏡像是分層的，鏡像的每一層都可以被共享，同時，鏡像是只讀的。當一個容器啟動時，一個新的可寫層被加載到鏡像的頂部，這一層通常被稱作“容器層”，“容器層”之下的都叫“鏡像層”。

所有對容器的改動 - 無論添加、刪除、還是修改文件，都只會發生在容器層中，因為只有容器層是可寫的，容器層下面的所有鏡像層都是只讀的。鏡像層數量可能會很多，所有鏡像層會聯合在一起組成一個統一的文件系統。如果不同層中有一個相同路徑的文件，比如 /a，上層的 /a 會覆蓋下層的 /a，也就是說用戶只能訪問到上層中的文件 /a。在容器層中，用戶看到的是一個疊加之后的文件系統。

• 添加文件：在容器中創建文件時，新文件被添加到容器層中。
• 讀取文件：在容器中讀取某個文件時，Docker 會從上往下依次在各鏡像層中查找此文件。一旦找到，立即將其復制到容器層，然后打開并讀入內存。
• 修改文件：在容器中修改已存在的文件時，Docker 會從上往下依次在各鏡像層中查找此文件。一旦找到，立即將其復制到容器層，然后修改之。
• 刪除文件：在容器中刪除文件時，Docker 也是從上往下依次在鏡像層中查找此文件。找到后，會在容器層中記錄下此刪除操作。

只有當需要修改時才復制一份數據，這種特性被稱作 Copy-on-Write。可見，容器層保存的是鏡像變化的部分，不會對鏡像本身進行任何修改。

14、簡單描述一下Dockerfile的整個構建鏡像過程

• 首先，創建一個目錄用于存放應用程序以及構建過程中使用到的各個文件等；
• 然后，在這個目錄下創建一個Dockerfile文件，一般建議Dockerfile的文件名就是Dockerfile；
• 編寫Dockerfile文件，編寫指令，如，使用FORM指令指定基礎鏡像，COPY指令復制文件，RUN指令指定要運行的命令，ENV設置環境變量，EXPOSE指定容器要暴露的端口，WORKDIR設置當前工作目錄，CMD容器啟動時運行命令，等等指令構建鏡像；
• Dockerfile編寫完成就可以構建鏡像了，使用docker build -t 鏡像名:tag . 命令來構建鏡像，最后一個點是表示當前目錄，docker會默認尋找當前目錄下的Dockerfile文件來構建鏡像，如果不使用默認，可以使用-f參數來指定dockerfile文件，如：docker build -t 鏡像名:tag -f /xx/xxx/Dockerfile ；
• 使用docker build命令構建之后，docker就會將當前目錄下所有的文件發送給docker daemon，順序執行Dockerfile文件里的指令，在這過程中會生成臨時容器，在臨時容器里面安裝RUN指定的命令，安裝成功后，docker底層會使用類似于docker commit命令來將容器保存為鏡像，然后刪除臨時容器，以此類推，一層層的構建鏡像，運行臨時容器安裝軟件，直到最后的鏡像構建成功。

15、Dockerfile構建鏡像出現異常，如何排查？

首先，Dockerfile是一層一層的構建鏡像，期間會產生一個或多個臨時容器，構建過程中其實就是在臨時容器里面安裝應用，如果因為臨時容器安裝應用出現異常導致鏡像構建失敗，這時容器雖然被清理掉了，但是期間構建的中間鏡像還在，那么我們可以根據異常時上一層已經構建好的臨時鏡像，將臨時鏡像運行為容器，然后在容器里面運行安裝命令來定位具體的異常。

16、Dockerfile的基本指令有哪些？

• FROM 指定基礎鏡像（必須為第一個指令，因為需要指定使用哪個基礎鏡像來構建鏡像）；
• MAINTAINER 設置鏡像作者相關信息，如作者名字，日期，郵件，聯系方式等；
• COPY 復制文件到鏡像；
• ADD 復制文件到鏡像（ADD與COPY的區別在于，ADD會自動解壓tar、zip、tgz、xz等歸檔文件，而COPY不會，同時ADD指令還可以接一個url下載文件地址，一般建議使用COPY復制文件即可，文件在宿主機上是什么樣子復制到鏡像里面就是什么樣子這樣比較好）；
• ENV 設置環境變量；
• EXPOSE 暴露容器進程的端口，僅僅是提示別人容器使用的哪個端口，沒有過多作用；
• VOLUME 數據卷持久化，掛載一個目錄；
• WORKDIR 設置工作目錄，如果目錄不在，則會自動創建目錄；
• RUN 在容器中運行命令，RUN指令會創建新的鏡像層，RUN指令經常被用于安裝軟件包；
• CMD 指定容器啟動時默認運行哪些命令，如果有多個CMD，則只有最后一個生效，另外，CMD指令可以被docker run之后的參數替換；
• ENTRYOINT 指定容器啟動時運行哪些命令，如果有多個ENTRYOINT，則只有最后一個生效，另外，如果Dockerfile中同時存在CMD和ENTRYOINT，那么CMD或docker run之后的參數將被當做參數傳遞給ENTRYOINT；

17、如何進入容器？使用哪個命令

進入容器有兩種方法：docker attach、docker exec。

18、什么是k8s？說出你的理解

K8s是kube.NETes的簡稱，其本質是一個開源的容器編排系統，主要用于管理容器化的應用，其目標是讓部署容器化的應用簡單并且高效（powerful）,Kubernetes提供了應用部署，規劃，更新，維護的一種機制。

說簡單點：k8s就是一個編排容器的系統，一個可以管理容器應用全生命周期的工具，從創建應用，應用的部署，應用提供服務，擴容縮容應用，應用更新，都非常的方便，而且還可以做到故障自愈，所以，k8s是一個非常強大的容器編排系統。

19、k8s的組件有哪些，作用分別是什么？

k8s主要由master節點和node節點構成。master節點負責管理集群，node節點是容器應用真正運行的地方。

• master節點包含的組件有：kube-api-server、kube-controller-manager、kube-scheduler、etcd。
• node節點包含的組件有：kubelet、kube-proxy、container-runtime。

kube-api-server：以下簡稱api-server，api-server是k8s最重要的核心組件之一，它是k8s集群管理的統一訪問入口，提供了RESTful API接口, 實現了認證、授權和準入控制等安全功能；api-server還是其他組件之間的數據交互和通信的樞紐，其他組件彼此之間并不會直接通信，其他組件對資源對象的增、刪、改、查和監聽操作都是交由api-server處理后，api-server再提交給etcd數據庫做持久化存儲，只有api-server才能直接操作etcd數據庫，其他組件都不能直接操作etcd數據庫，其他組件都是通過api-server間接的讀取，寫入數據到etcd。

kube-controller-manager：以下簡稱controller-manager，controller-manager是k8s中各種控制器的的管理者，是k8s集群內部的管理控制中心，也是k8s自動化功能的核心；controller-manager內部包含replication controller、node controller、deployment controller、endpoint controller等各種資源對象的控制器，每種控制器都負責一種特定資源的控制流程，而controller-manager正是這些controller的核心管理者。

kube-scheduler：以下簡稱scheduler，scheduler負責集群資源調度，其作用是將待調度的pod通過一系列復雜的調度算法計算出最合適的node節點，然后將pod綁定到目標節點上。shceduler會根據pod的信息（關注微信公眾號：網絡技術聯盟站），全部節點信息列表，過濾掉不符合要求的節點，過濾出一批候選節點，然后給候選節點打分，選分最高的就是最佳節點，scheduler就會把目標pod安置到該節點。

Etcd：etcd是一個分布式的鍵值對存儲數據庫，主要是用于保存k8s集群狀態數據，比如，pod，service等資源對象的信息；etcd可以是單個也可以有多個，多個就是etcd數據庫集群，etcd通常部署奇數個實例，在大規模集群中，etcd有5個或7個節點就足夠了；另外說明一點，etcd本質上可以不與master節點部署在一起，只要master節點能通過網絡連接etcd數據庫即可。

kubelet：每個node節點上都有一個kubelet服務進程，kubelet作為連接master和各node之間的橋梁，負責維護pod和容器的生命周期，當監聽到master下發到本節點的任務時，比如創建、更新、終止pod等任務，kubelet 即通過控制docker來創建、更新、銷毀容器；每個kubelet進程都會在api-server上注冊本節點自身的信息，用于定期向master匯報本節點資源的使用情況。

kube-proxy：kube-proxy運行在node節點上，在Node節點上實現Pod網絡代理，維護網絡規則和四層負載均衡工作，kube-proxy會監聽api-server中從而獲取service和endpoint的變化情況，創建并維護路由規則以提供服務IP和負載均衡功能。簡單理解此進程是Service的透明代理兼負載均衡器，其核心功能是將到某個Service的訪問請求轉發到后端的多個Pod實例上。

container-runtime：容器運行時環境，即運行容器所需要的一系列程序，目前k8s支持的容器運行時有很多，如docker、rkt或其他，比較受歡迎的是docker，但是新版的k8s已經宣布棄用docker。

20、kubelet的功能、作用是什么？（重點，經常會問）

kubelet部署在每個node節點上的，它主要有4個功能：

• 節點管理。kubelet啟動時會向api-server進行注冊，然后會定時的向api-server匯報本節點信息狀態，資源使用狀態等，這樣master就能夠知道node節點的資源剩余，節點是否失聯等等相關的信息了。master知道了整個集群所有節點的資源情況，這對于 pod 的調度和正常運行至關重要。
• pod管理。kubelet負責維護node節點上pod的生命周期，當kubelet監聽到master的下發到自己節點的任務時，比如要創建、更新、刪除一個pod，kubelet 就會通過CRI（容器運行時接口）插件來調用不同的容器運行時來創建、更新、刪除容器；常見的容器運行時有docker、containerd、rkt等等這些容器運行時，我們最熟悉的就是docker了，但在新版本的k8s已經棄用docker了，k8s1.24版本中已經使用containerd作為容器運行時了。
• 容器健康檢查。pod中可以定義啟動探針、存活探針、就緒探針等3種，我們最常用的就是存活探針、就緒探針，kubelet 會定期調用容器中的探針來檢測容器是否存活，是否就緒，如果是存活探針，則會根據探測結果對檢查失敗的容器進行相應的重啟策略；
• Metrics Server資源監控。在node節點上部署Metrics Server用于監控node節點、pod的CPU、內存、文件系統、網絡使用等資源使用情況，而kubelet則通過Metrics Server獲取所在節點及容器的上的數據。

21、kube-api-server的端口是多少？各個pod是如何訪問kube-api-server的？

kube-api-server的端口是8080和6443，前者是http的端口，后者是https的端口，以我本機使用kubeadm安裝的k8s為例：

在命名空間的kube-system命名空間里，有一個名稱為kube-api-master的pod，這個pod就是運行著kube-api-server進程，它綁定了master主機的ip地址和6443端口，但是在default命名空間下，存在一個叫kubernetes的服務，該服務對外暴露端口為443，目標端口6443，這個服務的ip地址是clusterip地址池里面的第一個地址，同時這個服務的yaml定義里面并沒有指定標簽選擇器，也就是說這個kubernetes服務所對應的endpoint是手動創建的，該endpoint也是名稱叫做kubernetes，該endpoint的yaml定義里面代理到master節點的6443端口，也就是kube-api-server的IP和端口。這樣一來，其他pod訪問kube-api-server的整個流程就是：pod創建后嵌入了環境變量，pod獲取到了kubernetes這個服務的ip和443端口，請求到kubernetes這個服務其實就是轉發到了master節點上的6443端口的kube-api-server這個pod里面。

22、k8s中命名空間的作用是什么？

amespace是kubernetes系統中的一種非常重要的資源，namespace的主要作用是用來實現多套環境的資源隔離，或者說是多租戶的資源隔離。

k8s通過將集群內部的資源分配到不同的namespace中，可以形成邏輯上的隔離，以方便不同的資源進行隔離使用和管理。不同的命名空間可以存在同名的資源，命名空間為資源提供了一個作用域。

可以通過k8s的授權機制，將不同的namespace交給不同的租戶進行管理，這樣就實現了多租戶的資源隔離，還可以結合k8s的資源配額機制，限定不同的租戶能占用的資源，例如CPU使用量、內存使用量等等來實現租戶可用資源的管理。

23、pod資源控制器類型有哪些?

• Deployments：Deployment為Pod和ReplicaSet提供聲明式的更新能力。
• ReplicaSet：ReplicaSet的目的是維護一組在任何時候都處于運行狀態的Pod副本的穩定集合。因此，它通常用來保證給定數量的、完全相同的Pod的可用性。
• StatefulSets：和Deployment類似，StatefulSet管理基于相同容器規約的一組Pod。但和Deployment不同的是，StatefulSet為它們的每個Pod維護了一個有粘性的ID。這些Pod是基于相同的規約來創建的，但是不能相互替換：無論怎么調度，每個Pod都有一個永久不變的ID。
• DaemonSet：DaemonSet確保全部（或者某些）節點上運行一個Pod的副本。當有節點加入集群時，也會為他們新增一個Pod。當有節點從集群移除時，這些Pod也會被回收。刪除DaemonSet將會刪除它創建的所有Pod。
• Jobs：Job會創建一個或者多個Pod，并將繼續重試Pod的執行，直到指定數量的Pod成功終止。隨著Pod成功結束，Job跟蹤記錄成功完成的Pod個數。當數量達到指定的成功個數閾值時，任務（即Job）結束。刪除Job的操作會清除所創建的全部Pod。掛起Job的操作會刪除Job的所有活躍Pod，直到Job被再次恢復執行。
• Automatic Clean-up for Finished Jobs：TTL-after-finished控制器提供了一種TTL機制來限制已完成執行的資源對象的生命周期。TTL控制器目前只處理Job。
• CronJob：一個CronJob對象就像crontab(crontable)文件中的一行。它用Cron格式進行編寫，并周期性地在給定的調度時間執行Job。
• ReplicationController：ReplicationController確保在任何時候都有特定數量的Pod副本處于運行狀態。換句話說，ReplicationController確保一個Pod或一組同類的Pod總是可用的。

24、nginx算法策略

輪詢（默認）

加權輪詢（輪詢+weight）

ip_hash

每一個請求的訪問IP，都會映射成一個hash，再通過hash算法（hash值%node_count），分配到不同的后端服務器，訪問ip相同的請求會固定訪問同一個后端服務器，這樣可以做到會話保持，解決session同步問題。

least_conn（最少連接）

使用最少連接的負載平衡，nginx將嘗試不會使繁忙的應用程序服務器超載請求過多，而是將新請求分發給不太繁忙的服務器。

25、nignx常用模塊

• upstream
• rewrite
• location
• proxy_pass

26、如何查看并且殺死僵尸進程？

top —> task (line)—> zombie.

把父進程殺掉，父進程死后，過繼給1號進程init，init 始終負責清理僵尸進程，它產生的所有僵尸進程跟著消失；如果你使用kill ，一般都不能殺掉 defunct進程.。用了kill -15,kill -9以后 之后反而會多出更多的僵尸進程。

27、搜索某個用戶運行的進程

pgrep -au neteagle

28、查看某個端口正在被哪個進程使用

lsof -i :[port]

29、端口轉發

iptables -t nat -A PREROUTING -d 10.0.0.8 -p tcp --dport 80 -j REDIRECT --to-ports 8080

30、查看http的并發請求數與其TCP連接狀態

etstat-n|awk'/^tcp/{++b[$NF]}END{for(ainb)printa,b[a]}'

31、查看/var/log目錄下文件數

ls/var/log/-lR|grep"^-"|wc-l

32、linux系統啟動流程

• 第一步：開機自檢，加載BIOS
• 第二步：讀取ＭＢＲ
• 第三步：Boot Loader　grub引導菜單
• 第四步：加載kernel內核
• 第五步：init進程依據inittab文件夾來設定運行級別
• 第六步：init進程執行rc.sysinit
• 第七步：啟動內核模塊
• 第八步：執行不同運行級別的腳本程序
• 第九步：執行/etc/rc.d/rc.lo

33、Linux文件類型

• -：常規文件，即file
• d：目錄文件
• b：block device 即塊設備文件，如硬盤;支持以block為單位進行隨機訪問
• c：character device 即字符設備文件，如鍵盤支持以character為單位進行線性訪問
• l：symbolic link 即符號鏈接文件（關注微信公眾號：網絡技術聯盟站），又稱軟鏈接文件
• p：pipe 即命名管道文件
• s：socket 即套接字文件，用于實現兩個進程進行通信

34、簡述lvm，如何給使用lvm的/分區擴容？

功能：可以對磁盤進行動態管理。動態按需調整大小

概念：

• PV 物理卷：物理卷在邏輯卷管理中處于最底層，它可以是實際物理硬盤上的分區，也可以是整個物理硬盤，也可以是raid設備。
• VG 卷組：卷組建立在物理卷之上，一個卷組中至少要包括一個物理卷，在卷組建立之后可動態添加物理卷到卷組中。一個邏輯卷管理系統工程中可以只有一個卷組，也可以擁有多個卷組。
• LV 邏輯卷：邏輯卷建立在卷組之上，卷組中的未分配空間可以用于建立新的邏輯卷，邏輯卷建立后可以動態地擴展和縮小空間。系統中的多個邏輯卷可以屬于同一個卷組，也可以屬于不同的多個卷組。

給/分區擴容步驟：

• 添加磁盤
• 使用fdisk命令對新增加的磁盤進行分區
• 分區完成后修改分區類型為lvm
• 使用pvcreate創建物理卷
• 使用vgextend命令將新增加的分區加入到根目錄分區中
• 使用lvextend命令進行擴容
• 使用xfs_growfs調整卷分區大小

35、如何在文本里面進行復制、粘貼，刪除行，刪除全部，按行查找和按字母查找。

以下操作全部在vi/vim命令行狀態操作，不要在編輯狀態操作：

• 在文本里 移動到想要復制的行按yy想復制到哪就移動到哪，然后按P就黏貼了
• 刪除行 移動到改行 按dd
• 刪除全部dG這里注意G一定要大寫
• 按行查找 :90 這樣就是找到第90行
• 按字母查找 /path 這樣就是找到path這個單詞所在的位置，文本里可能存在多個，多次查找會顯示在不同的位置。

36、符號鏈接與硬鏈接的區別

• 我們可以把符號鏈接，也就是軟連接 當做是 windows系統里的 快捷方式。
• 硬鏈接 就好像是 又復制了一份.
• ln 3.txt 4.txt 這是硬鏈接，相當于復制，不可以跨分區，但修改3,4會跟著變，若刪除3,4不受任何影響。
• ln -s 3.txt 4.txt 這是軟連接，相當于快捷方式。修改4,3也會跟著變，若刪除3,4就壞掉了。不可以用了。

37、什么是正向代理？

一個位于客戶端和原始服務器(origin server)之間的服務器，為了從原始服務器取得內容，客戶端向代理發送一個請求并指定目標(原始服務器)，然后代理向原始服務器轉交請求并將獲得的內容返回給客戶端。

客戶端才能使用正向代理。正向代理總結就一句話：代理端代理的是客戶端。例如說：我們使用的OpenVPN 等等。

38、什么是反向代理？

反向代理（Reverse Proxy）方式，是指以代理服務器來接受 Internet上的連接請求，然后將請求，發給內部網絡上的服務器并將從服務器上得到的結果返回給 Internet 上請求連接的客戶端，此時代理服務器對外就表現為一個反向代理服務器。

反向代理總結就一句話：代理端代理的是服務端。

39、什么是動態資源、靜態資源分離？

動態資源、靜態資源分離，是讓動態網站里的動態網頁根據一定規則把不變的資源和經常變的資源區分開來，動靜資源做好了拆分以后我們就可以根據靜態資源的特點將其做緩存操作，這就是網站靜態化處理的核心思路。

動態資源、靜態資源分離簡單的概括是：動態文件與靜態文件的分離。

在我們的軟件開發中，有些請求是需要后臺處理的（如：.jsp,.do 等等），有些請求是不需要經過后臺處理的（如：css、html、jpg、js 等等文件），這些不需要經過后臺處理的文件稱為靜態文件，否則動態文件。

因此我們后臺處理忽略靜態文件。這會有人又說那我后臺忽略靜態文件不就完了嗎？當然這是可以的，但是這樣后臺的請求次數就明顯增多了。在我們對資源的響應速度有要求的時候，我們應該使用這種動靜分離的策略去解決動、靜分離將網站靜態資源（HTML，JAVAScript，CSS，img等文件）與后臺應用分開部署，提高用戶訪問靜態代碼的速度，降低對后臺應用訪問

這里我們將靜態資源放到 Nginx 中，動態資源轉發到 Tomcat 服務器中去。

當然，因為現在七牛、阿里云等 CDN 服務已經很成熟，主流的做法，是把靜態資源緩存到 CDN 服務中，從而提升訪問速度。

相比本地的 Nginx 來說，CDN 服務器由于在國內有更多的節點，可以實現用戶的就近訪問。并且，CDN 服務可以提供更大的帶寬，不像我們自己的應用服務，提供的帶寬是有限的。

40、網站登陸緩慢是什么原因?

• 網絡帶寬，這是一個很常見的瓶頸。
• cpu、硬盤、內存配置過低，服務器負載不起來。
• 網站的開發代碼不夠完善，例如mysql語句沒有進行優化，導致數據庫的讀寫相當耗費時間。
• 數據庫的瓶頸。當我們的數據庫的數據變得越來越多的時候，那么對于數據庫的讀寫壓力肯定會變大。

41、a與b服務器不在同一網段怎么設置?設置完還ping不通怎么排查?

• AB服務器不在同一個網段
• 首先把不同IP段的服務器劃分給不同的vlan
• 在通過通過三層交換機添加虛擬IP路由實在不同網段的vlan的連接

42、在AB兩臺服務器之間通過一個服務器c做軟路由使用給路由器c配置兩塊網卡并開啟自身的路由功能

vi /etc/sysconfig/network-scripts/ifcfg-eth0

查看網卡狀況IP -a -s 網卡的名字

A服務器設置相關網卡信息

子網掩碼：255.255.255.0
IP=10.0.0.1
網關=10.0.0.254
重啟網卡生效
查看路由信息
route -n
添加對應路由
route add -net 10.0.1.0/24 gw 10.0.0.11

B服務器的設置相關信息

IP=10.0.1.10
網關10.0.1.254
重啟網卡生效
route -n
添加對應的路由
route add -net 10.0.0.0/24 gw 10.0.1.11

C服務器的兩塊網卡

網卡1
IP=10.0.0.11
網關=10.0.0.254


網卡2
IP=10.0.1.11
網關=10.0.1.254
重啟網卡生效
route -n
vi /etc/sysctl.conf
net.ipv4.ip_forword = 1

43、如果PING不通怎么排查

• 首先先看看是不是網路接口故障水晶頭或是網卡接口接觸不良造成，其次檢查交換機和路由等網絡設備是有故障
• 是否關閉了防火墻和selinux機制
• 然后查看網卡和路由和網關是否配置正確

44、docker容器ping不通是什么原因?

ifconfig 查看一下docker0網橋，ping一下網橋看看是否通，有可能是網橋配置問題

weave路由器端口6783

• 安裝docker容器的服務器沒有關閉防火墻(訪問一下安裝docker物理機的，是否能訪問，如果不能訪問就變不能訪問docker)
• docker在創建鏡像的時候沒有做端口映射(出現這種情況能訪問物理機不能訪問docker)使用dockers ps 查看鏡像的端口映射情況
• 端口映射不正確
• 查看網絡配置ping網橋看是否能ping通，有可能是網橋的原因

45、如果一臺辦公室內主機無法上網(打不開網站)，請給出你的排查步驟?

• 首先確定物理鏈路是否聯通正常。
• 查看本機IP，路由，DNS的設置情況是否達標。
• telnet檢查服務器的WEB有沒有開啟以及防火墻是否阻攔。
• ping一下網關，進行最基礎的檢查，通了，表示能夠到達服務器。
• 測試到網關或路由器的通常情況，先測網關，然后再測路由器一級一級的測試。
• 測試ping公網ip的通常情況(記住幾個外部IP)，
• 測試DNS的通暢。ping出對應IP。
• 通過以上檢查后，還在網管的路由器上進行檢查。

46、如果我們的網站打開速度慢請說下您的排查思路?

判斷原因

首先我要以用戶的身份登錄我們的網站，判斷問題出現在我們自身原因，還是用戶那邊的原因。

如果是用戶問題有以下幾個原因：

• 用戶那邊的帶寬
• 用戶的瀏覽器器版本低，安裝插件太多
• 中毒和電腦里的垃圾文件過多
• 用戶主機的主機的性能和操作系統

如果是我們的網站自身問題有一下幾個原因

• 網絡帶寬
• 服務器的cpu、硬盤、內存過低服務器負載不起來也就是說服務器自身的性能方面
• 網站代碼不夠完善。如mysql語句沒有進行優化導致數據庫讀寫耗時
• 服務器未開啟圖片壓縮
• 網頁臺下
• 死連接過多插件使用及js文件調用頻繁網站服務器的速度或是租用空間所在的服務器速度

解決思路

1、檢測服務器速度的快慢

• ping命令查看連接到服務器的時間和丟包情況(ping 測試網址的)
• 查看丟包率(1000個包沒有丟一個是最理想的、一般一個速度好的機房丟包率不超過1%)
• ping值要小同城電信adsl ping平均值絕對不能超過20，一般都在10，跨省的平均值20-40屬于正常
• ping值要均勻最小值和最大值相差太大說明路由不穩定的表現

2、查看服務器自身性能

查看cpu的使用率uptime

查看內存情況 free -m

查看I/O讀寫iostat 磁盤I/O讀寫等看看是那個進程大量占用系統資源導致我的服務器變慢

3、看看訪問最多的URL和IP有什么特征，如果是惡意URL和IP就把他屏蔽掉如果是善意的就限流有可能是CDN回源量大造成網站無法訪問

4、查看同臺服務器上其他網站的打開速度，可以通過查詢工具查看和自己在同一臺服務器上的網站個數和網址可以看他們打開快慢

5、電信和聯通互訪的問題

如果是空間打開時快時慢，有時打不開那就是空間不穩定找空間商解決或是換空間傷，如果是有的地方快有的地方慢應該是網絡線路問題，比如電信用戶訪問放在聯通服務器上的網站，聯通用戶訪問放在電信服務器上的網站，解決辦吧是：使用雙線空間或是多線空間

6、從網站自身的原因

• 網站的程序設計結構是否合理是否由于幻燈片代碼影響網站打開速度(找程序設計相關人士解決)
• 網頁的設計結構和代碼錯誤(請專業人士進行修改)
• 網頁的內容如：大尺寸圖片、大尺寸flash、過多的引用其他網站內容，如果被引用內容的網站速度慢，也影響自身網站把。譬如友情連接可以把對方 的圖片放到自己網站上

解決辦法

• 優化圖片，限制圖片大小尺寸，降低圖片質量，減少圖片數量
• 限定圖片的格式：jpg，png，gif
• 減少http的請求數(當打開網頁時瀏覽器會發出很多對象請求，每個對象的加載都會有所延時，如果網頁上的對象很多就會花費大量的時間，去除不必要的對象，將臨近的圖片合成一張，合并css文件) f r o m ：w l j s l m z

46、如何查看二進制文件的內容

我們一般通過 hexdump 命令 來查看二進制文件的內容。

hexdump -C XXX(文件名) -C 是參數 不同的參數有不同的意義

-C 是比較規范的 十六進制和 ASCII 碼顯示

-c 是單字節字符顯示

-b 單字節八進制顯示

-o 是雙字節八進制顯示

-d 是雙字節十進制顯示

-x 是雙字節十六進制顯示

等等等等

47、你是怎么備份數據的，包括數據庫備份？

在生產環境下，不管是應用數據、還是數據庫數據首先在部署的時候就會有主從架構、或者集群，這本身就是屬于數據的熱備份；其實考慮冷備份，用專門一臺服務器做為備份服務器，比如可以用rsync+inotify配合計劃任務來實現數據的冷備份，如果是發版的包備份，正常情況下有臺發布服務器，每次發版都會保存好發版的包。

48、zabbix常用術語你知道幾個？

• 主機（host）：要監控的網絡設備，可由IP或DNS名稱指定；
• 主機組（hostgroup）：主機的邏輯容器，可以包含主機和模板，但同一個組織內的主機和模板不能互相鏈接；主機組通常在給用戶或用戶組指派監控權限時使用；
• 監控項（item）：一個特定監控指標的相關的數據；這些數據來自于被監控對象；item是zabbix進行數據收集的核心，相對某個監控對象，每個item都由"key"標識；
• 觸發器（trigger）：一個表達式，用于評估某監控對象的特定item內接收到的數據是否在合理范圍內，也就是閾值；接收的數據量大于閾值時，觸發器狀態將從"OK"轉變為"Problem"，當數據再次恢復到合理范圍，又轉變為"OK"；
• 事件（event）：觸發一個值得關注的事情，比如觸發器狀態轉變，新的agent或重新上線的agent的自動注冊等；
• 動作（action）：指對于特定事件事先定義的處理方法，如發送通知，何時執行操作；
• 報警升級（escalation）：發送警報或者執行遠程命令的自定義方案，如每隔5分鐘發送一次警報，共發送5次等；
• 媒介（media）：發送通知的手段或者通道，如Email、Jabber或者SMS等；
• 通知（notification）：通過選定的媒介向用戶發送的有關某事件的信息；遠程命令（remote command）：預定義的命令，可在被監控主機處于某特定條件下時自動執行；
• 模板（template）：用于快速定義被監控主機的預設條目集合，通常包含了item、trigger、graph、screen、application以及low-level
• discovery rule；模板可以直接鏈接至某個主機；應用（application）：一組item的集合；
• web場景（webscennario）：用于檢測web站點可用性的一個活多個HTTP請求；前端（frontend）：Zabbix的web接口；

49、虛擬化技術有哪些表現形式

• 完全擬化技術：通過軟件實現對操作系統的資源再分配，比較成熟，完全虛擬化代表技術：KVM、ESXI、Hyper-V。
• 半虛擬化技術：通過代碼修改已有的系統，形成一種新的可虛擬化的系統，調用硬件資源去安裝多個系統，整體速度上相對高一點，半虛擬化代表技術：Xen。
• 輕量級虛擬化：介于完全虛擬化、半虛擬化之間，輕量級虛擬化代表技術：Docker。

50、修改線上業務配置文件流程

• 先告知運維經理和業務相關開發人員
• 在測試環境測試，并備份之前的配置文件
• 測試無誤后修改生產環境配置
• 觀察生產環境是否正常，是否有報警
• 完成配置文件更改