理解OpenShift(1):網路之 Router 和 Route
1. OpenShift 為什麼需要 Router 和 Route?
顧名思義,Router 是路由器,Route 是路由器中配置的路由。OpenShift 中的這兩個概念是為了解決從叢集外部(就是從除了叢集節點以外的其它地方)訪問服務的需求。不曉得為什麼OpenShift 要將Kubernetes 中的 Ingress 改為 Router,我倒是覺得 Ingress 名字更貼切。
從外部通過 router 和從內部通過 servide 訪問 pod 中的應用兩個過程的簡單的示意圖如下:
上圖中,某個應用的三個pod 分別位於 node1,node2 和 node3 上。OpenShift 中有三層IP地址概念:
- pod 自己的 IP 地址,可以類比為 OpenStack 中虛擬機器的固定IP。它只有在叢集內才有意義。
- service 的 IP 地址。Service 通常有 ClusterIP,這也是一種叢集內部的IP 地址。
- 應用的外部 IP 地址,可以類比為OpenStack 中的浮動IP,或者IDC IP(和浮動IP 之間是NAT 對映關係)。
因此,要從叢集外部訪問 pod 中的應用,無非兩種方式:
- 一種是利用一個代理(proxy),把外部 IP 地址轉化為後端的 Pod IP 地址。這就是 OpenShift router/route 的思路。OpenShift 中的 router 服務,是一個執行在特定節點(通常是基礎架構節點)上的叢集基礎服務,由叢集管理員負責建立和管理。它可以有多個副本(pod)。router 中可有多個 route,每個 route 能通過外部HTTP 請求的域名找出其後端的 pod 列表,並進行網路包的轉發。也就是將pod 中的應用暴露到外網域名,使得使用者可以外面通過域名訪問到應用。這實際上是一種七層負載均衡器。OpenShift 預設採用 HAProxy 來實現,當然也支援其它實現,比如 F5.
- 另一種是將服務直接暴露到叢集外。這種方式具體會在『服務 Service』那一篇文章中詳細解釋。
2. OpenShift 如何利用 HAProxy 實現 router 和 route?
2.1 Router 部署
使用 ansible 採用預設配置部署 OpenShift 叢集時,在叢集 Infra 節點上,會以 Host networking 方式執行一個 HAProxy 的 pod,它會在所有網絡卡的 80 和 443 埠上進行監聽。
[[email protected] cloud-user]# netstat -lntp | grep haproxy tcp0 0 127.0.0.1:10443 0.0.0.0:* LISTEN 583/haproxy tcp 0 0 127.0.0.1:10444 0.0.0.0:* LISTEN 583/haproxy tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 583/haproxy tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 583/haproxy
其中,172.0.0.1 上的 10443 和 10444 是HAproxy 自己使用的。下文會有解釋。
因此,在每個 infra 節點上,只能有一個 HAProxy pod,因為這些埠只能被佔用一次。如果排程器找不到滿足要求的節點,則router 服務的排程就會失敗:
0/7 nodes are available: 2 node(s) didn't have free ports for the requested pod ports, 5 node(s) didn't match node selector
OpenShift HAProxy Router 支援兩種部署方式:
- 一種是常見的單Router 服務部署,它有一個或多個例項(pod),分佈在多個節點上,負責整個叢集上部署的服務的對外訪問。
- 另一種是分片(sharding)部署。此時,會有多個 Router 服務,每個Router 服務負責指定的若干project,兩者之間採用標籤(label)進行對映。這是為了解決單個 Router 的效能不夠問題而提出的解決方案。
OpenShift 提供了 oc adm router 命令來建立 router 服務。
建立router:
[[email protected] cloud-user]# oc adm router router2 --replicas=1 --service-account=router info: password for stats user admin has been set to J3YyPjlbqf --> Creating router router2 ... warning: serviceaccounts "router" already exists clusterrolebinding.authorization.openshift.io "router-router2-role" created deploymentconfig.apps.openshift.io "router2" created service "router2" created --> Success
詳細的部署方法請參見官方文件 https://docs.openshift.com/container-platform/3.11/install_config/router/default_haproxy_router.html。
2.2 Router pod 中的 HAProxy 程序
在 Router 服務的每個 pod 之中,openshift-router 程序啟動了一個 haproy 程序:
UID PID PPID C STIME TTY TIME CMD 1000000+ 1 0 0 Nov21 ? 00:14:27 /usr/bin/openshift-router 1000000+ 16011 1 0 12:42 ? 00:00:00 /usr/sbin/haproxy -f /var/lib/haproxy/conf/haproxy.config -p /var/lib/haproxy/run/haproxy.pid -x /var/lib/haproxy/run/haproxy.sock -sf 16004
檢視 haproxy 使用的配置檔案(只是部分):
global maxconn 20000 daemon ca-base /etc/ssl crt-base /etc/ssl 。。。。 defaults maxconn 20000 # Add x-forwarded-for header. # server openshift_backend 127.0.0.1:8080 errorfile 503 /var/lib/haproxy/conf/error-page-503.http 。。。 timeout http-request 10s timeout http-keep-alive 300s # Long timeout for WebSocket connections. timeout tunnel 1h frontend public bind :80 mode http tcp-request inspect-delay 5s tcp-request content accept if HTTP monitor-uri /_______internal_router_healthz # Strip off Proxy headers to prevent HTTpoxy (https://httpoxy.org/) http-request del-header Proxy # DNS labels are case insensitive (RFC 4343), we need to convert the hostname into lowercase # before matching, or any requests containing uppercase characters will never match. http-request set-header Host %[req.hdr(Host),lower] # check if we need to redirect/force using https. acl secure_redirect base,map_reg(/var/lib/haproxy/conf/os_route_http_redirect.map) -m found redirect scheme https if secure_redirect use_backend %[base,map_reg(/var/lib/haproxy/conf/os_http_be.map)] default_backend openshift_default # public ssl accepts all connections and isn't checking certificates yet certificates to use will be # determined by the next backend in the chain which may be an app backend (passthrough termination) or a backend # that terminates encryption in this router (edge) frontend public_ssl bind :443 tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } # if the connection is SNI and the route is a passthrough don't use the termination backend, just use the tcp backend # for the SNI case, we also need to compare it in case-insensitive mode (by converting it to lowercase) as RFC 4343 says acl sni req.ssl_sni -m found acl sni_passthrough req.ssl_sni,lower,map_reg(/var/lib/haproxy/conf/os_sni_passthrough.map) -m found use_backend %[req.ssl_sni,lower,map_reg(/var/lib/haproxy/conf/os_tcp_be.map)] if sni sni_passthrough # if the route is SNI and NOT passthrough enter the termination flow use_backend be_sni if sni # non SNI requests should enter a default termination backend rather than the custom cert SNI backend since it # will not be able to match a cert to an SNI host default_backend be_no_sni 。。。
backend be_edge_http:demoprojectone:jenkins mode http option redispatch option forwardfor balance leastconn timeout server 4m timeout check 5000ms http-request set-header X-Forwarded-Host %[req.hdr(host)] http-request set-header X-Forwarded-Port %[dst_port] http-request set-header X-Forwarded-Proto http if !{ ssl_fc } http-request set-header X-Forwarded-Proto https if { ssl_fc } http-request set-header X-Forwarded-Proto-Version h2 if { ssl_fc_alpn -i h2 } http-request add-header Forwarded for=%[src];host=%[req.hdr(host)];proto=%[req.hdr(X-Forwarded-Proto)];proto-version=%[req.hdr(X-Forwarded-Proto-Version)] cookie 4376ea64d7d0abf11209cfe5f7cca1e7 insert indirect nocache httponly secure server pod:jenkins-1-84nrt:jenkins:10.128.2.13:8080 10.128.2.13:8080 cookie 8669a19afc9f0fed6824feb9fb1cf4ac weight 256 。。。
為了簡單期間,上面只是配置檔案的部分內容,它主要包括三種類型:
- 全域性配置,比如最大連線數 maxconn,超時時間 timeout 等;以及front部分,即前端配置,HAProxy 預設會在 443 和 80 兩個埠上分別監聽外部 https 和 http 請求。
- backend,即每個服務的後端配置,裡面有很多關鍵內容,比如後端協議(mode)、負載均衡方法(balance)、後端列表(server,這裡是pod,包括其IP 地址和埠)、證書等。
因此,OpenShift 的路由器功能需要能對這三部分進行管理和控制。
2.3 全域性配置管理
要指定或修改 HAProxy 的全域性配置,OpenShift 有提供兩種方式:
(1)第一種是使用 oc adm router 命令在建立 router 時候指定各種引數,比如 --max-connections 用於設定最大連線數。比如:
oc adm router --max-connections=200000 --ports='81:80,444:443' router3
創建出來的HAProxy 的 maxconn 將是 20000,router3 這個服務對外暴露出來的埠是 81 和 444,但是 HAProxy pod 的埠依然是 80 和 443.
(2)通過設定 dc/<dc router名> 的環境變數來設定 router 的全域性配置。
在官方文件 https://docs.openshift.com/container-platform/3.4/architecture/core_concepts/routes.html#haproxy-template-router 中有完整的環境變數列表。比如執行以下命令後,
oc set env dc/router3 ROUTER_SERVICE_HTTPS_PORT=444 ROUTER_SERVICE_HTTP_PORT=81 STATS_PORT=1937
router3 會重新部署,新部署的HAProxy 的 https 監聽埠是 444,http 監聽埠是 80,統計埠是 1937.
2.4 OpenShift passthrough 型別的 route 與 HAProxy backend
(1)通過OpenShift Console 或者 oc 命令建立一條 route,它將 sit 專案的 jenkins 服務暴露到域名 sitjenkins.com.cn:
在介面上建立 route:
結果:
Name: sitjenkins.com.cn Namespace: sit Labels: app=jenkins-ephemeral template=jenkins-ephemeral-template Annotations: <none> Requested Host: sitjenkins.com.cn Path: <none> TLS Termination: passthrough Endpoint Port: web Service: jenkins Weight: 100 (100%) Endpoints: 10.128.2.15:8080, 10.131.0.10:8080
這裡,service name 起了一箇中介作用,把 route 和服務的端點(也就是pod)連線了起來。
(2)router 服務的兩個 pod 中的 HAProxy 程序的配置檔案中多了一個backend:
# Secure backend, pass through backend be_tcp:sit:sitjenkins.com.cn balance source hash-type consistent timeout check 5000ms} server pod:jenkins-1-bqhfj:jenkins:10.128.2.15:8080 10.128.2.15:8080 weight 256 check inter 5000ms server pod:jenkins-1-h2fff:jenkins:10.131.0.10:8080 10.131.0.10:8080 weight 256 check inter 5000ms
其中,這些後端 server 其實就是 pod,它們是 openshift 通過步驟(1)中的 service name 找到的。balance 是負載均衡策略,後文會解釋。
(3)檔案 /var/lib/haproxy/conf/os_sni_passthrough.map 中多了一條記錄
sh-4.2$ cat /var/lib/haproxy/conf/os_sni_passthrough.map ^sitjenkins\.com\.cn(:[0-9]+)?(/.*)?$ 1
(4)檔案 /var/lib/haproxy/conf/os_tcp_be.map 中多了一條記錄
sh-4.2$ cat /var/lib/haproxy/conf/os_tcp_be.map ^sitjenkins\.com\.cn(:[0-9]+)?(/.*)?$ be_tcp:sit:sitjenkins.com.cn
(5)HAProxy 根據上面的 map 檔案為該條 route 選擇第(2)步中增加的 backend的邏輯如下
frontend public_ssl #解釋:前端協議 https, bind :443 ##前端埠 443 tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } # if the connection is SNI and the route is a passthrough don't use the termination backend, just use the tcp backend # for the SNI case, we also need to compare it in case-insensitive mode (by converting it to lowercase) as RFC 4343 says acl sni req.ssl_sni -m found ##檢查 https request 支援 sni acl sni_passthrough req.ssl_sni,lower,map_reg(/var/lib/haproxy/conf/os_sni_passthrough.map) -m found ##檢查通過 sni 傳來的 hostname 在 os_sni_patthrough.map 檔案中 use_backend %[req.ssl_sni,lower,map_reg(/var/lib/haproxy/conf/os_tcp_be.map)] if sni sni_passthrough ##從 oc_tcp_be.map 中根據 sni hostname 獲取 backend name # if the route is SNI and NOT passthrough enter the termination flow use_backend be_sni if sni # non SNI requests should enter a default termination backend rather than the custom cert SNI backend since it # will not be able to match a cert to an SNI host default_backend be_no_sni
(6)HAPorxy 程序會重啟,從而應用修改了的配置檔案。
理解(5)中的指令碼需要的一些背景知識:
從上面的藍色註釋中,我們能看到 HAProxy 程序通過 https 請求中通過 SNI 傳入的域名 sitjenkins.com.cn ,在 os_tcp_be.map 檔案中獲取到了 backend 名稱 be_tcp:sit:sitjenkins.com.cn,這樣就和(2)步驟中的 backend 對應上了。
OpenShift 的 router 使用的 HAProxy 採用基於域名的負載均衡路由方式,示例如下,具體說明請參加官方文件。
2.5 OpenShift edge 和 re-encrypt 型別的 route 與 HAProxy
HAProxy 前端:前端依然是在 443 埠監聽外部 HTTPS 請求
frontend public_ssl bind :443
..... # if the route is SNI and NOT passthrough enter the termination flow use_backend be_sni if sni
但是,當 TLS 終止型別不是 passthrough (edge 或者 re-encrypt)時,會使用backend be_sni。
backend be_sni server fe_sni 127.0.0.1:10444 weight 1 send-prox
而這個後端是由本機的 127.0.0.1:10444 提供服務,因此又轉到了前端 fe_sni:
frontend fe_sni # terminate ssl on edge bind 127.0.0.1:10444 ssl no-sslv3 crt /var/lib/haproxy/router/certs/default.pem crt-list /var/lib/haproxy/conf/cert_config.map accept-proxy mode http 。。。。。。 # map to backend # Search from most specific to general path (host case). # Note: If no match, haproxy uses the default_backend, no other # use_backend directives below this will be processed. use_backend %[base,map_reg(/var/lib/haproxy/conf/os_edge_reencrypt_be.map)] default_backend openshift_default
map 對映檔案:
sh-4.2$ cat /var/lib/haproxy/conf/os_edge_reencrypt_be.map ^edgejenkins\.com\.cn(:[0-9]+)?(/.*)?$ be_edge_http:sit:jenkins-edge
Edge 型別 route 的 HAProxy 後端:
backend be_edge_http:sit:jenkins-edge mode http option redispatch option forwardfor balance leastconn timeout check 5000ms ..... server pod:jenkins-1-bqhfj:jenkins:10.128.2.15:8080 10.128.2.15:8080 cookie 71c6bd03732fa7da2f1b497b1e4c7993 weight 256 check inter 5000ms server pod:jenkins-1-h2fff:jenkins:10.131.0.10:8080 10.131.0.10:8080 cookie fa8d7fb72a46958a7add1406e6d26cc8 weight 256 check inter 5000ms
Re-encrypt 型別 route 的 HAProxy 後端:
# Plain http backend or backend with TLS terminated at the edge or a # secure backend with re-encryption. backend be_secure:sit:reencryptjenkins.com.cn mode http 。。。。
http-request set-header X-Forwarded-Host %[req.hdr(host)]
http-request set-header X-Forwarded-Port %[dst_port]
http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
http-request set-header X-Forwarded-Proto https if { ssl_fc }
http-request set-header X-Forwarded-Proto-Version h2 if { ssl_fc_alpn -i h2 }
server pod:jenkins-1-bqhfj:jenkins:10.128.2.15:8080 10.128.2.15:8080 cookie ... weight 256 ssl verifyhost jenkins.sit.svc verify required ca-file /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt check inter 5000ms #與後端的鏈路採用 ssl 加密,並且要檢查hostname server pod:jenkins-1-h2fff:jenkins:10.131.0.10:8080 10.131.0.10:8080 cookie ... weight 256 ssl verifyhost jenkins.sit.svc verify required ca-file /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt check inter 5000ms
這裡可以看出來重新使用金鑰對連線進行加密,但是不知道為何 mode 依然是 http,而不是 https。
2.6 設定和修改 route 配置
route 配置主要有以下幾個比較重要的:
(1)SSL 終結方式。共三種:
- edge:TLS 在 router 上被終結,然後非SSL網路包被轉發給後端 pod。因此需要在 router 上安裝 TLS 證書。不安裝的話,會使用 router 的預設證書。
- passthrough:加密網路包直接被髮給 pod,router 上不做TLS 終結,因為不需要在 router 上配置證書或金鑰。
- Re-encryption:是 edge 的一種變種。首先 router 上會使用一個證書做 TSL 終結,然後使用另外的證書再進行加密,然後發給後端 pod。因此,整個網路路徑都是加密的。
設定:
(2)負載均衡策略。也有三種:
- roundrobin:根據權重輪流使用所有後端。
- leastconn:選擇最少連線的後端接收請求。
- source:將源IP進行雜湊,確保來自同一個源IP的請求發給同一個後端。
- 要修改整個 router 的負載均衡策略,可使用 ROUTER_TCP_BALANCE_SCHEME 環境變數,為該 router 的所有 passthrough 型別的 route設定負載均衡策略,使用 ROUTER_LOAD_BALANCE_ALGORITHM 為其它型別的 route 設定策略。
舉例:
- 設定整個 router 的環境變數:oc set env dc/router ROUTER_TCP_BALANCE_SCHEME=roundrobin
- 修改某個 route 的負載均衡的策略:oc edit route aaaa.svc.cluster.local
3. OpenShift router 服務如何實現高可用?
OpenShift router 服務支援兩種高可用模式。
3.1 單 router 服務多副本,並利用和DNS/LB 實現高可用
這種模式只部署一個 router 服務,它支援叢集的所有對外暴露的服務。要實現HA,需要設定副本數(replicas)大於1,使得會在超過一臺伺服器上建立pod,然後再通過DNS輪詢或者四層負載均衡。
因為 router/pod 中的 HAProxy 要實現本地配置檔案,因此實際上它們是有狀態容器。OpenShift 採用 etcd 作為配置的統一儲存,openshift-router 程序應該是採取某種機制(被通知或定時拉取)從 etcd 中獲取 router 和 route 的配置,然後再修改本地的配置檔案,再重啟 HAPorxy 程序來應用新修改了的配置檔案。 要深入瞭解這裡面的工作原理,可以去看原始碼。
3.2 多 router 服務通過分片(sharding)實現高可用
這種模式下,管理員需要建立和部署多個 router 服務,每個router 服務支援一個或幾個 project/namespace。router 和 project/namespace 之間的對映使用標籤(label)來實現。具體的配置請參考官網 https://docs.openshift.com/container-platform/3.11/install_config/router/default_haproxy_router.html。實際上,和一些產品(比如mysql,memedcache)的分片功能類似,該功能更多地是為了解決效能問題,而無法完全解決高可用問題。
4. 常見問題如何排查?
從上面的分析可以看出,要使得 router 和 route 都正常工作,至少要確保以下幾個環節都是沒問題的:
- 客戶端使用 route 中配置的域名和埠來訪問服務。
- DNS 能將域名解析到目標 router 所在的伺服器(在使用分片配置時比較複雜,尤其需要注意)。
- 如有采用另外的四層負載均衡器的話,它得配置正確、工作正常。
- HAProxy 能通過域名匹配到正確的backend。
- router 和 route 的配置被正確地反映到了 HAProxy 的配置檔案中了。
- HAProxy 程序重啟了,從而讀取了新修改的配置檔案。
- 後端 pod 列表正確,並且至少有一個 pod 正常工作。
如果您看到如下的錯誤頁面,則說明上面的第3到7點至少有一處不能正常功能。此時,進行有針對性的排查即可。
感謝您的閱讀,歡迎關注我的微信公眾號:
相關推薦
理解OpenShift(1):網路之 Router 和 Route Neutron 理解 (7): Neutron 是如何實現負載均衡器虛擬化的
理解OpenShift(1):網路之Router 和 Route 1. OpenShift 為什麼需要 Router 和 Route? 顧名思義,Router 是路由器,Route 是路由器中配置的路由。OpenShift 中的這兩個概念是為了解決從叢集外部(就是從除了叢集節點
理解OpenShift(1):網路之 Router 和 Route
1. OpenShift 為什麼需要 Router 和 Route? 顧名思義,Router 是路由器,Route 是路由器中配置的路由。OpenShift 中的這兩個概念是為了解決從叢集外部(就是從除了叢集節點以外的其它地方)訪問服務的需求。不曉得為什麼OpenShift 要將Kubernetes
理解OpenShift(2):網路之 DNS(域名服務)
理解OpenShift(1):網路之 Router 和 Route 理解OpenShift(2):網路之 DNS(域名服務) OpenShift 叢集中,至少有三個地方需要用到 DNS: 一是Pod 中的應用通過域名訪問外網的時候,需要DNS來解析外網的域名 二是在叢集內部(p
理解OpenShift(3):網路之 SDN
理解OpenShift(1):網路之 Router 和 Route 理解OpenShift(2):網路之 DNS(域名服務) 理解OpenShift(3):網路之 SDN 1. 概況 OpenShift SDN 實現了符合Kubernetes CNI 要求的 OpenShift
深入理解Plasma(1):Plasma 框架
這一系列文章將圍繞以太坊的二層擴容框架,介紹其基本執行原理,具體操作細節,安全性討論以及未來研究方向等。本篇文章作為開篇,主要目的是理解 Plasma 框架。 Plasma 作為以太坊的二層擴容框架,自從 2017 年被 Joseph Poon(Lightning N
理解Docker(1):Docker 安裝和基礎用法
來源:https://www.cnblogs.com/sammyliu/p/5875470.html 1. 安裝 1.1 在 Ubuntu 14.04 上安裝 Docker 前提要求: 核心版本必須是3.10或者以上 依次執行下面的步驟: sudo apt-g
理解OpenShift(4):使用者及許可權管理
理解OpenShift(1):網路之 Router 和 Route 理解OpenShift(2):網路之 DNS(域名服務) 理解OpenShift(3):網路之 SDN 理解OpenShift(4):使用者及許可權管理 OpenShift 支援 RBAC(Role Based Acc
理解OpenShift(6):集中式日誌處理
理解OpenShift(1):網路之 Router 和 Route 理解OpenShift(2):網路之 DNS(域名服務) 理解OpenShift(3):網路之 SDN 理解OpenShift(4):使用者及許可權管理 理解OpenShift(5):從 Docker Volume 到
PTA 資料結構題目(1):最大子列和問題(分而治之、線上處理演算法)
題目來源: 問題描述: 問題分析: 對於一般的問題,原始解 都能通過一種 蠻力演算法,即窮舉法的思想得到。這題也不例外。 如果我們,把輸入的陣列,所有的子列都歷遍,並從中找出最大,即可得出我們的演算法。也就是版本一。 學習要點: 1、如何
理解 OpenStack 高可用(HA)(1):OpenStack 高可用和災備方案 [OpenStack HA and DR]
本系列會分析OpenStack 的高可用性(HA)概念和解決方案: 1. 基礎知識 1.1 高可用 (High Availability,簡稱 HA) 高可用性是指提供在本地系統單個元件故障情況下,能繼續訪問應用的能力,無論這個故障是業務流程、物理設施、IT軟/硬體的
Nginx專題(1):Nginx之反向代理及配置
摘要:本文從Nginx的概念出發,分別從反向代理的概念、優勢、配置程式碼3個方面介紹了Nginx的特性之一反向代理。 文章來源:宜信技術學院 & 宜信支付結算團隊技術分享第一期-宜信支付結算八方資料團隊高階技術經理 周恆《Nginx的細枝末節》 分享者:宜信支付結算八方資料團隊高階技術經理 周恆 原
ActiveMQ(18):Message之延遲和定時消息投遞
jms activemq 延遲和定時消息投遞 一、簡介延遲和定時消息投遞(Delay and Schedule Message Delivery) 有時候我們不希望消息馬上被broker投遞出去,而是想要消息60秒以後發給消費者,或者我們想讓消息沒隔 一定時間投遞一次,一共投遞指定的次數。。。
C++學習(1):最大子段和(多種解法)
多少 問題: code namespace 數據 組成 amp using () 問題:給定由n個數(可能為負數)組成的序列a1,a2,a3,...,an,求該序列子段和的最大值。 第一種解法:(最容易考慮的方法,將所有的子段一一相加,然後比較) 1 #include&
基礎知識概念(1):Socket 長連線和短連線的概念
1.短連線 連線->傳輸資料->關閉連線 HTTP是無狀態的,瀏覽器和伺服器每進行一次HTTP操作,就建立一次連線,但任務結束後就中斷連線。短連線是指SOCKET建立連線後 ,傳送後或接收完資料後,就馬上斷開連線。 2.長連線
多執行緒(1):繼承Thread類和實現Runnable介面
多執行緒的兩種實現方法: 1.繼承Thread類 繼承Thread類,重寫run()方法。建立多執行緒的時候,需要建立物件例項,然後呼叫start()方法。類物件的屬性屬於執行緒私有,執行緒之間互不影響。 public class ClassExtendT
機器學習儲備(1):協方差和相關係數
為了深刻理解機器學習演算法的原理,首先得掌握其中涉及到的一些基本概念和理論,比如概率,期望,標準差,方差。在這些基本概念上,又衍生出了很多重要概念,比如協方差,相關係數等。今天我們就來聊聊這些組成機器學習的基本概念。 1、概率 概率 P 是對隨機事件發生的可能性的度量。 例如,小明在期末
理解JVM(六):執行緒安全和鎖優化
執行緒安全的實現方法 互斥同步 互斥是因,同步是果;互斥是方法,同步是目的。 synchronized關鍵字 synchronized關鍵字是基本的互斥同步手段。它在編譯後會在同步程式碼塊前後加入2條位元組碼指令:monitorenter和mo
gdb除錯(1):單步執行和跟蹤函式呼叫
轉發自:http://songjinshan.com/akabook/zh/gdb.html#id1看下面的程式: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18#include <stdio.h> in
Kubernetes部署(十):儲存之glusterfs和heketi部署
概觀 本指南支援在Kubernetes叢集中整合,部署和管理GlusterFS容器化儲存節點。這使Kubernetes管理員能夠為其使用者提供可靠的共享儲存。 包括設定指南、其中包含一個示例伺服器pod,它使用動態配置的GlusterFS捲進行儲存。對於那些希望測試或瞭解有關此主題的更多資訊的人,請按照主
排序演算法(1):簡單選擇排序和堆排序
1.簡單選擇排序 (1)本質:每一趟從給定待排序序列A[ 1......n ] ,選擇出第i小元素,並和A[i]交換。 程式碼: /************************************************* 演算法:簡單選擇排序(升序) 時間