地震 API的問題，透過圖書和論文來找解法和答案更準確安心。 我們找到下列免費下載的地點或者是各式教學

Kubernetes網路權威指南：基礎、原理與實踐

為了解決地震 API的問題，作者杜軍 這樣論述：

本書是容器與Kubernetes網路的基礎和進階書籍，旨在讓更多人瞭解和學習雲原生時代的底層網路模型與實現機制，指導企業在落地雲原生時的網路方案 選型。   全書包括：容器網路虛擬化基礎、Docker容器網路、Kubernetes網路和Istio網路4部分，共6章。第1章容器網路虛擬化基礎將支撐 容器網路的內核技術娓娓道來。第2章簡單介紹了Docker原生的容器網路能力。Kubernetes網路分為3章，第3章介紹Kubernetes網路 的基礎概念和使用，第4章為讀者剖析了Kubernetes網路的底層實現原理，第5章詳解了業界主流的Kubernetes網路外掛程式。Istio網路總 共1章

，重點解析Istio網路流量管控的背後機制。   本書適合作為高等院校電腦相關專業雲計算課程的參考資料，也適合雲計算從業者，特別是希望對雲原生 網路技術有較深入瞭解並希望將其應用到日常工作中的所有讀者閱讀。 杜軍，浙大SEL實驗室碩士，曾任華為雲架構師、諮詢組專家，國內最早的容器技術佈道師。開源社區自身貢獻者與維護著，CNCF TOC Contributor，Kubernetes和Istio雙科maintainer，對雲計算技術演進與內在驅動力有深刻見解，主要研究方向為容器、微服務、DevOps、邊緣計算。 第1章夯實基礎：Linux網路虛擬化 1 1.

1 網路虛擬化基石：network namespace      1 1.1.1 初識network namespace     2 1.1.2 配置network namespace     3 1.1.3 network namespace API的使用     6 1.1.4 小結   12 1.2 千呼萬喚始出來：veth pair    12 1.2.1 veth pair內核實現     14 1.2.2 容器與host veth pair的關係     15 1.2.3 小結   17 1.3 連接你我他：Linux bridge     17 1.3.1 Linux bridg

e初體驗    17 1.3.2 把IP讓給Linux bridge   21 1.3.3 將物理網卡添加到Linux bridge    22 1.3.4 Linux bridge在網路虛擬化中的應用    25 1.3.5 網路介面的混雜模式     26 1.4 給用戶態一個機會：tun/tap設備    28 1.4.1 tun/tap設備的工作原理  28 1.4.2 利用tun設備部署一個VPN    29 1.4.3 tun設備程式設計       31 1.5 iptables    34 1.5.1 祖師爺netfilter     34 1.5.2 iptables的三板斧

：table、chain和rule    36 1.5.3 iptables的常規武器    39 1.6 初識 Linux 隧道：ipip     45 1.6.1 測試ipip隧道      46 1.6.2 ipip隧道測試結果複盤   49 1.6.3 小結   50 1.7 Linux 隧道網路的代表：VXLAN       51 1.7.1 為什麼需要VXLAN      51 1.7.2 VXLAN協議原理簡介   52 1.7.3 VXLAN組網必要資訊   54 1.7.4 VXLAN基本配置命令   55 1.7.5 VXLAN網路實踐     56 1.7.6 分散式控制

中心    63 1.7.7 自維護VTEP組    63 1.7.8 小結   68 1.8 物理網卡的分身術：Macvlan    68 1.8.1 Macvlan五大工作模式解析     68 1.8.2 測試使用Macvlan設備   72 1.8.3 Macvlan的跨機通信      73 1.8.4 Macvlan與overlay對比     74 1.8.5 小結   75 1.9 Macvlan的救護員：IPvlan    75 1.9.1 IPvlan簡介     75 1.9.2 測試IPvlan     77 1.9.3 Docker IPvlan網路     78 1

.9.4 小結   78   第2章 飲水思源：Docker網路模型簡介 79 2.1 主角登場：Linux容器    79 2.1.1 容器是什麼   79 2.1.2 容器與虛擬機器對比    80 2.1.3 小結   81 2.2 打開萬花筒：Docker的四大網路模式   81 2.2.1 bridge模式    82 2.2.2 host模式    83 2.2.3 container模式    84 2.2.4 none模式   85 2.3 最常用的Docker網路技巧    85 2.3.1 查看容器IP    85 2.3.2 埠映射    86 2.3.3 訪問外網   

84 2.3.4 DNS和主機名稱    87 2.3.5 自訂網路  88 2.3.6 發佈服務    90 2.3.7 docker link：兩兩互聯   91 2.4 容器網路的第一個標準：CNM  93 2.4.1 CNM標準    93 2.4.2 體驗CNM介面    94 2.4.3 Libnetwork  95 2.4.4 Libnetwork擴展   97 2.4.5 小結   98 2.5 天生不易：容器組網的挑戰   99 2.5.1 容器網路挑戰綜述    99 2.5.2 Docker的解決方案    101 2.5.3 協力廠商容器網路外掛程式   102 2.5

.4 小結   103 2.6 如何做好技術選型：容器組網方案沙場點兵   103 2.6.1 隧道方案    104 2.6.2 路由方案    104 2.6.3 容器網路組網類型    106 2.6.4 關於容器網路標準介面  107 2.6.5 小結   108   第 3 章 標準的勝利：Kubernetes 網路原理與實踐 109 3.1 容器基礎設施的代言人：Kubernetes  109 3.1.1 Kubernetes簡介    109 3.1.2 Kubernetes能做什麼   111 3.1.3 如何用Kubernetes    113 3.1.4 Docker在Ku

bernetes中的角色    113 3.2 終於等到你：Kubernetes網路  114 3.2.1 Kubernetes網路基礎   114 3.2.2 Kubernetes網路架構綜述    115 3.2.3 Kubernetes主機內組網模型     117 3.2.4 Kubernetes跨節點組網模型     118 3.2.5 Pod的hosts文件   120 3.2.6 Pod的hostname    121 3.3 Pod的核心：pause容器    124 3.4 打通CNI與Kubernetes：Kubernetes網路驅動   131 3.4.1 即將完成歷史使

命：Kubenet   131 3.4.2 網路生態第一步：CNI   133 3.5 找到你並不容易：從集群內訪問服務   139 3.5.1 Kubernetes Service詳解  141 3.5.2 Service的三個port   145 3.5.3 你的服務適合哪種發佈形式    146 3.5.4 Kubernetes Service發現  150 3.5.5 特殊的無頭Service    151 3.5.6 怎麼訪問本機服務    153 3.6 找到你並不容易：從集群外訪問服務   154 3.6.1 Kubernetes Ingress   155 3.6.2 小結 

 157 3.7 你的名字：通過功能變數名稱訪問服務   158 3.7.1 DNS服務基本框架    158 3.7.2 功能變數名稱解析基本原理    159 3.7.3 DNS使用   161 3.7.4 調試DNS   166 3.8 Kubernetes網路策略：為你的應用保駕護航    167 3.8.1 網路策略應用舉例    168 3.8.2 小結   172 3.9 前方高能：Kubernetes網路故障定位指南   173 3.9.1 IP轉發和橋接   173 3.9.2 Pod CIDR衝突    175 3.9.3 hairpin  176 3.9.4 查看Pod

IP地址    176 3.9.5 故障排查工具    178 3.9.6 為什麼不推薦使用SNAT     180   第 4 章 刨根問底：Kubernetes網路實現機制 183 4.1 豈止iptables：Kubernetes Service官方實現細節探秘     183 4.1.1 userspace模式   184 4.1.2 iptables模式   186 4.1.3 IPVS模式    191 4.1.4 iptables VS. IPVS    198 4.1.5 conntrack    199 4.1.6 小結  200 4.2 Kubernetes極客們的日常：D

IY一個Ingress Controller   201 4.2.1 Ingress Controller的通用框架  202 4.2.2 Nginx Ingress Controller詳解    202 4.2.3 小結  209 4.3 滄海桑田：Kubernetes DNS架構演進之路    209 4.3.1 Kube-dns的工作原理   209 4.3.2 上位的CoreDNS    212 4.3.3 Kube-dns VS. CoreDNS   217 4.3.4 小結  220 4.4 你的安全我負責：使用Calico提供Kubernetes網路策略   220 4.4.1

部署一個帶Calico的Kubernetes集群   221 4.4.2 測試Calico網路策略   225   第5章 百花齊放：Kubernetes網路外掛程式生態 228 5.1 從入門到放棄：Docker原生網路的不足   228 5.2 CNI標準的勝出：從此江湖沒有CNM    229 5.2.1 CNI與CNM的轉換   230 5.2.2 CNI的工作原理   231 5.2.3 為什麼Kubernetes不使用Libnetwork   235 5.3 Kubernetes網路外掛程式鼻祖flannel     238 5.3.1 flannel簡介   239 5.3.2

flannel安裝配置    241 5.3.3 flannel backend詳解   244 5.3.4 flannel與etcd    256 5.3.5 小結  257 5.4 全能大三層網路外掛程式：Calico   257 5.4.1 Calico簡介    258 5.4.2 Calico的隧道模式   263 5.4.3 安裝Calico    263 5.4.4 Calico報文路徑    264 5.4.5 Calico使用指南    267 5.4.6 為什麼Calico網路選擇BGP    272 5.4.7 小結  274 5.5 Weave：支援資料加密的網路外掛

程式    276 5.5.1 Weave簡介   276 5.5.2 Weave實現原理   277 5.5.3 Weave安裝   278 5.5.4 Weave網路通信模型   280 5.5.5 Weave的應用示例   282 5.5.6 小結  288 5.6 Cilium：為微服務網路連接安全而生    288 5.6.1 為什麼使用Cilium   289 5.6.2 以API為中心的微服務安全    294 5.6.3 BPF優化的資料平面性能    295 5.6.4 試用Cilium：網路策略  297 5.6.5 小結  299 5.7 Kubernetes多網路的先行

者：CNI-Genie    299 5.7.1 為什麼需要CNI-Genie  300 5.7.2 CNI-Genie功能速遞   302 5.7.3 容器多IP    303   第6章 Kubernetes網路下半場：Istio  305 6.1 微服務架構的大地震：sidecar模式    305 6.1.1 你真的需要 Service Mesh嗎   306 6.1.2 sidecar模式    307 6.1.3 Service Mesh與sidecar   307 6.1.4 Kubernetes Service VS. Service Mesh    309 6.1.5 Ser

vice Mesh典型實現之Linkerd    310 6.2 Istio：引領新一代微服務架構潮流   312 6.2.1 Istio簡介    312 6.2.2 Istio安裝    313 6.2.3 Istio路由規則的實現   317 6.3 一切盡在不言中：Istio sidecar透明注入   319 6.3.1 Init容器  319 6.3.2 sideca注入示例    319 6.3.3 手工注入sidecar    326 6.3.4 自動注入sidecar   327 6.3.5 從應用容器到sidecar代理的通信   329 6.4 不再為iptables腳本

所困：Istio CNI外掛程式    330 6.5 除了微服務，Istio還能做更多   331   緣起 這些年來，我觀察到每次Linux世界的重大技術創新都發源於內核，經過一層層面向用戶的抽象和封裝，演化出應用層的森羅萬象。正所謂萬變不離其宗！ 我自認為是個“old school”（老派）的人，堅信維持這個世界運轉的、最本質的那部分東西是不會輕易改變的。儘管新技術“亂花漸欲迷人眼”，但經歷過時間錘煉的實用技術和工具總是歷久彌新的。一個很好的例子便是傳統的網路虛擬化和BGP，它們就是在容器這個新瓶子裡煥發第二春的。因此，當有時髦的新技術出現時，我的第一反應是這些新技

術底層是怎麼實現的，對那些看起來酷炫的功能反倒沒有興趣。正如Open Stack興起的那些年，當大家都在談論nova、neutron這類調度虛擬機器和網路的元件時，我默默地翻讀了內核虛擬機器（KVM）的源碼。至今，我對那種奇妙的感覺記憶猶新，恰如一個發燒級攝影愛好者走進暗房，欣喜若狂地親自手洗一張可觸摸的膠片影像。當我讀懂了KVM時，再回過頭來看Open Stack便有了一種“會當淩絕頂，一覽眾山小”的豁然貫通之感。 工作之餘讓心靜下來，細細品味，認真思考技術的本質——相信這是所有有激情、有夢想的工程師的共同追求。雖然在軟體版本快速反覆運算的高壓面前，這種良好的追求有時也會變成一種奢求，但是

我堅信工程師不能只當一個使用者，而一定要理解當前正在使用的技術的底層實現機制。因此，在我的《雲原生分散式存儲基石：etcd深入解析》一書中，開篇隻字未提全書主角etcd，而耗費將近80頁的筆墨，從分散式系統的基本理論一直講到一致性協議Raft。儘管內容看似與這個高速發展、追求快節奏的社會“格格不入”，但我仍希望能夠通過出版技術書這種本身就慢節奏且帶儀式感的行為沉澱自己的思考。如果能夠跟有緣的讀者碰撞出思想的火花，則將是我人生的一大幸事！   我為什麼寫這本書 雲計算的世界裡，計算最基礎，存儲最重要，網路最複雜。在Kubernetes已經成為雲原生代名詞的今天，市面上介紹Kubernetes的書

籍已經很多，然而限於篇幅或術業有專攻等諸多主客觀因素，不少書籍對Kubernetes網路部分的講解只是蜻蜓點水，甚至有些還存在專業性的錯誤。我經常在一些學習Kubernetes的論壇和群裡看到有用戶抱怨：傳統網路架構都還沒搞明白，又要理解容器網路。容器網路領域不但存在大量的術語，而且理解具體的方案需要不少前置知識，這無形中增加了學習的難度。電腦網路是我在大學裡最喜歡，也是最擅長的一門課程。在我看來，電腦網路趣味性強，而且對邏輯性和動手能力要求較高。看到整個雲原生網路領域正發生著激動人心的技術變革，意義不亞於上一次SDN興起帶來的衝擊，我感覺這對傳統網路工程師來說會是一次自我升級轉型的契機。於是

，我萌生了專門為Docker、Kubernetes的使用者，以及傳統網路工程師撰寫一本雲原生網路書籍的想法，破除他們學習過程中“不識廬山真面目，只緣身在此山中”的無力感。   關於本書 雖然書名是《Kubernetes網路權威指南：基礎、原理與實踐》，但全書內容並不局限於Kubernetes。我對本書的定位是雲原生領域的網路權威指南，企業落地方案的選型參考。按照我“oldschool”的思路，本書特別注重提供理解容器網路所必需的基礎知識，會由淺入深地從架構、使用、實現原理等多方面展開，試圖為讀者呈現整個雲原生網路的知識體系。 全書的脈絡是：以Linux網路虛擬化基礎作為“暖場嘉賓”，以Doc

ker原生的容器網路“承前啟後”，隨後是主角Kubernetes網路“粉墨登場”，在各類CNI外掛程式“沙場點兵”過後，以代表容器下半場的服務網格Istio“謝幕”。 王安石在登上飛來峰後曾吟下“不畏浮雲遮望眼，自緣身在最高層”這樣的千古佳句。希望本書能夠成為雲計算2.0時代的弄潮兒們叩開網路大門的敲門磚，在解決各類場景下錯綜複雜的問題時能夠做到“口中有糧、心中不慌”。不論是定位疑難雜症，還是技術選型，抑或是定制化開發都能輕鬆駕馭！ “人生不止眼前的苟且，還有詩和遠方的田野”，願更多的同路人加入。   杜軍 2019年8月於廈門鼓浪嶼  

地震 API進入發燒排行的影片

離岸風機扇葉於虛擬環境下之影像監測

為了解決地震 API的問題，作者徐聖硯 這樣論述：

影像量測技術有潛力以更高的經濟效益對離岸風機扇葉結構進行全域性的監測。然而於海上實施影像式監測，環境的干擾及雜訊對其有著高度敏感，往往常因環境背景、光線與相機偏轉等變化，導致量測結果不佳。故其提升抗噪技術的研發需求極高。此外欲研發影像量測技術需仰賴大量的實驗進行驗證，若實地進行實驗其成本相當龐大且不切實際。隨著近年電腦繪圖軟體的擬真影像技術提升，本研究採用電腦繪圖軟體 Blender 結合有限元素分析軟體OpenSees建立離岸風機的虛擬動態影像，並透過虛擬產生的環境干擾 (霧、海浪、相機偏轉) 等條件，監測扇葉旋轉時的面外方向振動行為，探討單相機影像量測技術於離岸風機扇葉結構監測的可行性。

本研究考量由虛擬環境產生的影像是否達到影像量測精度之標準。研究結果顯示，此系統用於開發影像量測技術有著極高的契合度，亦能於虛擬環境下建立具高真實性的環境干擾情境等模擬，以解決無法進行實際現地實驗等困難。

未來世界的倖存者：終極技術大革命的前夜，每一個人都該思索與知道的事

為了解決地震 API的問題，作者阮一峰 這樣論述：

AI、機器人與智能化來勢洶洶，向高度自動化又高度不確定的未來進軍。 這個世界正劇烈變化也停不下來，我們該如何處理這一切？ 　　科技與技術正日復一日不斷迅猛增長，並不理會這個世界是否同意。當智能化與自動化工程起飛後，未來「你的鞋可能都比你聰明」；大多數人將會在這種技術革命後的時代失去工作──而我們對這樣的前景思考得太少。 　　「我對於未來的基本判斷就是，大部分人沒用了，而人類的壽命卻越來越長，由此產生許許多巨大的問題。」 　　「請想像一下：當人類社會極度依賴技術，將無數自動化系統組合成一個超級系統，但是沒有一種技術能夠保證百分之百可靠。一旦發生問題，整個自動化系統就會發生動盪，甚至崩潰

，後果將難以預料。」 　　兩岸知名的IT作家阮一峰最新文集，這本書意圖探索「絕對比人類更強大」的機器與「智能化時代」大潮襲來時，人類社會「多數人」的處境與問題。 　　在資本過剩與技術高度發展兩大趨勢相結合後，科技應用的場景與革新速度幾乎是以幾何速度增長──本書作者認為，在可預見的未來，「技術終將淘汰人類」，低技術與知識的工作、乃至許許多多的中產白領階級職業將會消失。 　　在這場即將到來，恐將徹底解構過往發展模式的人類社會變局中，本書將提出許許多多的觀察與正在發生的現象，意圖喚醒我們在這場變化中必須有意識地應對變局。因為，一些可怕的景象將可能（或是已經）出現： 　　‧大部分人愈來愈窮，薪

資會因為「多數人爭搶少量人工」而更形僵固──但更嚴峻的事實是，目前人類的平均壽命也愈來愈長。 　　‧「AI」將取代大部分工作職位的主張幾乎確定會成真。本書展示許多技術發展將如何壓低人力成本並求取最大化的效益。例如，早在2005年，亞馬遜就曾以一個名叫「土耳其機器人」的專案外包網，讓人們完成編程工作領取報酬──許多公司都研究過以API（軟體應用接口）的方式，取代過往企業科層組織中負責執行任務的中階主管職位。未來僅有少部人人能夠躋身「API」以上，至於「API」之下的工作，將更趨零散與廉價化。 　　在盛行談論（也是流行性焦慮）「未來能力」與「未來教育技能」的時代──許多人也可能有些第二專長的企

圖──這其中有哪些趨勢值得我們注意？「大學教育」是不是仍然必備？我們又如何在「沒有安全工作」的時代中謀生？我們是否又想過自己在「人生最長的工作期」結束後，該如何準備一個保有收入來源的「B計畫」？ 　　除了這些問題外，還有更多因為技術帶來的社會革新「進行式」也將在本書討論，世界正在劇烈變化，技術也將會帶來目前難以預見的新問題。本書將呈現的是一位資深軟體圈內人與技術愛好者的不樂觀思索與應變預警。 特別推薦 　　傅瑞德／管理顧問．吐納商業評論創辦人

基於人工智慧及雲端運算技術之無所不在中介資訊多重代理系統 – 以學者資訊為例

為了解決地震 API的問題，作者王世文 這樣論述：

Alphago與Alphago Zero不僅呈現出人工智慧系統的成功，更展現其應用技術的成熟。無所不在運算（Ubiquitous Computing）是一後端運算之人機互動模式，如何藉由當代行動設備廣泛且無縫地藉由相關網際網路中介資訊代理系統之雲端運算互動範式更是需求日殷的重點技術。為此，本論文旨在應用本體論技術發展一植基於人工智慧與雲端運算技術之無所不在中介資訊多重代理系統，其引用一致性使用者需求語言CURRL，快速且明確地處理使用者的查詢命令，除了方便後端人工智慧技術為基資訊多重代理系統OntoIAS來處理使用者的資訊需求外，更避免肇因於誤解使用者查詢企圖所帶來龐雜且不正確的資訊洪流。提

出以ZigBee、GPS與Bluetooth在Google Android平台的雛型中介資訊系統與後端OntoIAS之雲端運算互動範式，此互動範式除了解決諸多行動設備的先天缺陷外，更充分發揮後端資訊系統OntoIAS的強大功能。初步的系統驗證本系統整體平均信度為0.89；平均效度則為0.80，無論在資訊推薦信度與效度的驗證均屬上乘。最後，持續完成相關行動設備中介程式開發，例如NFC、5G等，擴大至其它傳輸工具間的溝通，藉以變成完備無所不在資訊代理系統的終極目標，更是本論文未來的探究重點。