本文內容已經基於k8s v1.8.8進行了驗證測試。k8s的Service定義了一個服務的訪問入口地址，前端的應用通過這個入口地址訪問其背後的一組由Pod副本組成的叢集例項，來自外部的訪問請求被負載均衡到後端的各個容器應用上。Service與其後端Pod副本叢集之間則是通過Label Selector來實現對接的。而RC的作用相當於是保證Service的服務能力和服務質量始終處於預期的標準。Service 定義可以基於 POST 方式，請求 apiserver 建立新的例項。一個 Service 在 Kubernetes 中是一個 REST 物件。本文對Service的使用進行詳細說明，包括Service的負載均衡、外網訪問、DNS服務的搭建、Ingress7層路由機制等。 

1、Service定義詳解

1.1 yaml格式的Service定義檔案的完整內容

apiVersion: v1kind: Servicematadata:  name: string  namespace: string  labels:  - name: string  annotations:  - name: stringspec:  selector: []  type: string  clusterIP: string  sessionAffinity: string  ports:  - name: string    protocol: string    port: int    targetPort: int    nodePort: int  status:    loadBalancer:      ingress:        ip: string        hostname: string

1.2 對Service定義檔案中各屬性的說明表

屬性名稱	取值型別	是否必選	取值說明
version	string	Required	v1
kind	string	Required	Service
metadata	object	Required	元資料
metadata.name	string	Required	Service名稱
metadata.namespace	string	Required	名稱空間，預設為default
metadata.labels[]	list	自定義標籤屬性列表
metadata.annotation[]	list	自定義註解屬性列表
spec	object	Required	詳細描述
spec.selector[]	list	Required	Label Selector配置，將選擇具有指定Label標籤的Pod作為管理範圍
spec.type	string	Required	Service的型別，指定Service的訪問方式，預設值為ClusterIP。取值範圍如下：ClusterIP: 虛擬服務的IP，用於k8s叢集內部的pod訪問，在Node上kube-proxy通過設定的Iptables規則進行轉發。NodePort：使用宿主機的埠，使用能夠訪問各Node的外部客戶端通過Node的IP地址和埠就能訪問服務。LoadBalancer: 使用外接負載均衡器完成到服務的負載分發，需要在spec.status.loadBalancer欄位指定外部負載均衡器的IP地址，並同時定義nodePort和clusterIP，用於公有云環境。
spec.clusterIP	string	虛擬服務的IP地址，當type=clusterIP時，如果不指定，則系統進行自動分配。也可以手工指定。當type=LoadBalancer時，則需要指定。
spec.sessionAffinity	string	是否支援Session，可選值為ClientIP，表示將同一個源IP地址的客戶端訪問請求都轉發到同一個後端Pod。預設值為空。
spec.ports[]	list	Service需要暴露的埠列表
spec.ports[].name	string	埠名稱
spec.ports[].protocol	string	埠協議，支援TCP和UDP，預設值為TCP
spec.ports[].port	int	服務監聽的埠號
spec.ports[].targetPort	int	需要轉發到後端Pod的埠號
spec.ports[].nodePort	int	當spec.type=NodePort時，指定對映到物理機的埠號
status	object	當spec.type=LoadBalancer時，設定外部負載均衡器的地址，用於公有云環境
status.loadBalancer	object	外部負載均衡器
status.loadBalancer.ingress	object	外部負載均衡器
status.loadBalancer.ingress.ip	string	外部負載均衡器的IP地址
status.loadBalancer.ingress.hostname	string	外部負載均衡器的主機名

2、Service，RC，Pod架構層次關係

3、VIP 和 Service 代理

執行在每個Node上的kube-proxy程序其實就是一個智慧的軟體負載均衡器，它會負責把對Service的請求轉發到後端的某個Pod例項上並在內部實現服務的負載均衡與會話保持機制。Service不是共用一個負載均衡器的IP，而是被分配了一個全域性唯一的虛擬IP地址，稱為Cluster IP。在Service的整個生命週期內，它的Cluster IP不會改變。 kube-proxy 負責為 Service 實現了一種 VIP（虛擬 IP）的形式，而不是 ExternalName 的形式。在k8s v1.2版本之前預設使用userspace提供vip代理服務，從 Kubernetes v1.2 起，預設是使用 iptables 代理。iptables 代理模式這種模式，kube-proxy 會監視 Kubernetes master 對 Service 物件和 Endpoints 物件的新增和移除。 對每個 Service，它會建立相關 iptables 規則，從而捕獲到達該 Service 的 clusterIP（虛擬 IP）和埠的請求，進而將請求重定向到 Service 的一組 backend 中的某個上面。 對於每個 Endpoints 物件，它也會建立 iptables 規則，這個規則會選擇一個 backend Pod。預設的策略是，隨機選擇一個 backend。 實現基於客戶端 IP 的會話親和性，可以將 service.spec.sessionAffinity 的值設定為 "ClientIP" （預設值為 "None"）。和 userspace 代理類似，網路返回的結果是，任何到達 Service 的 IP:Port 的請求，都會被代理到一個合適的 backend，不需要客戶端知道關於 Kubernetes、Service、或 Pod 的任何資訊。 這應該比 userspace 代理更快、更可靠。然而，不像 userspace 代理，如果初始選擇的 Pod 沒有響應，iptables 代理能夠自動地重試另一個 Pod，所以它需要依賴 readiness probes。

4、 釋出服務 —— type型別

對一些應用希望通過外部（Kubernetes 叢集外部）IP 地址暴露 Service。Kubernetes ServiceTypes 允許指定一個需要的型別的 Service，預設是 ClusterIP 型別。Type 的取值以及行為如下：

• ClusterIP：通過叢集的內部 IP 暴露服務，選擇該值，服務只能夠在叢集內部可以訪問，這也是預設的 ServiceType。
• NodePort：通過每個 Node 上的 IP 和靜態埠（NodePort）暴露服務。NodePort 服務會路由到 ClusterIP 服務，這個 ClusterIP 服務會自動建立。通過請求 <NodeIP>:<NodePort>，可以從叢集的外部訪問一個 NodePort 服務。
• LoadBalancer：使用雲提供商的負載局衡器，可以向外部暴露服務。外部的負載均衡器可以路由到 NodePort 服務和 ClusterIP 服務。
• ExternalName：通過返回 CNAME 和它的值，可以將服務對映到 externalName 欄位的內容（例如， foo.bar.example.com）。 沒有任何型別代理被建立，這隻有 Kubernetes 1.7 或更高版本的 kube-dns 才支援。

k8s中有3種IP地址：

• Node IP： Node節點的IP地址，這是叢集中每個節點的物理網絡卡的IP地址；
• Pod IP： Pod的IP地址，這是Docker Engine根據docker0網橋的IP地址段進行分配的，通常是一個虛擬的二層網路；
• Cluster IP：Service 的IP地址，這也是一個虛擬的IP，但它更像是一個“偽造”的IP地址，因為它沒有一個實體網路物件，所以無法響應ping命令。它只能結合Service Port組成一個具體的通訊服務埠，單獨的Cluster IP不具備TCP/IP通訊的基礎。在k8s叢集之內，Node IP網、Pod IP網與Cluster IP網之間的通訊採用的是k8s自己設計的一種程式設計實現的特殊的路由規則，不同於常見的IP路由實現。

5、 服務發現

Kubernetes 支援2種基本的服務發現模式 —— 環境變數和 DNS。環境變數當 Pod 執行在 Node 上，kubelet 會為每個活躍的 Service 新增一組環境變數。 它同時支援 Docker links相容 變數、簡單的 {SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT 變數，這裡 Service 的名稱需大寫，橫線被轉換成下劃線。舉個例子，一個名稱為 "redis-master" 的 Service 暴露了 TCP 埠 6379，同時給它分配了 Cluster IP 地址 10.0.0.11，這個 Service 生成了如下環境變數：REDIS_MASTER_SERVICE_HOST=10.0.0.11REDIS_MASTER_SERVICE_PORT=6379REDIS_MASTER_PORT=tcp://10.0.0.11:6379REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379REDIS_MASTER_PORT_6379_TCP_PROTO=tcpREDIS_MASTER_PORT_6379_TCP_PORT=6379REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11這意味著需要有順序的要求 —— Pod 想要訪問的任何 Service 必須在 Pod 自己之前被建立，否則這些環境變數就不會被賦值。DNS 並沒有這個限制。DNS一個強烈推薦的叢集外掛 是 DNS 伺服器。 DNS 伺服器監視著建立新 Service 的 Kubernetes API，從而為每一個 Service 建立一組 DNS 記錄。 如果整個叢集的 DNS 一直被啟用，那麼所有的 Pod 應該能夠自動對 Service 進行名稱解析。例如，有一個名稱為 "my-service" 的 Service，它在 Kubernetes 叢集中名為 "my-ns" 的 Namespace 中，為 "my-service.my-ns" 建立了一條 DNS 記錄。 在名稱為 "my-ns" 的 Namespace 中的 Pod 應該能夠簡單地通過名稱查詢找到 "my-service"。 在另一個 Namespace 中的 Pod 必須限定名稱為 "my-service.my-ns"。 這些名稱查詢的結果是 Cluster IP。Kubernetes 也支援對埠名稱的 DNS SRV（Service）記錄。 如果名稱為 "my-service.my-ns" 的 Service 有一個名為 "http" 的 TCP 埠，可以對 "_http._tcp.my-service.my-ns" 執行 DNS SRV 查詢，得到 "http" 的埠號。Kubernetes DNS 伺服器是唯一的一種能夠訪問 ExternalName 型別的 Service 的方式。 更多資訊可以檢視DNS Pod 和 Service。Kubernetes 從 1.3 版本起， DNS 是內建的服務，通過外掛管理器 叢集外掛 自動被啟動。Kubernetes DNS 在叢集中排程 DNS Pod 和 Service ，配置 kubelet 以通知個別容器使用 DNS Service 的 IP 解析 DNS 名字。

6、Service的基本用法

一般來說，對外提供服務的應用程式需要通過某種機制來實現，對於容器應用最簡便的方式就是通過TCP/IP機制及監聽IP和埠號來實現。建立一個基本功能的Service（1）例如，我們定義一個提供web服務的RC，由兩個tomcat容器副本組成，每個容器通過containerPort設定提供服務號為8080：webapp-rc.yamlapiVersion: v1kind: ReplicationControllermetadata:  name: webappspec:  replicas: 2  template:    metadata:      name: webapp      labels:        app: webapp    spec:      containers:      - name: webapp        image: tomcat        ports:        - containerPort: 8080建立該RC：#kubectl create -f webapp-rc.yaml獲取Pod的IP地址：#kubectl get pods -l app=webapp -o yaml|grep podIPpodIP:172.17.0.2podIP:172.17.0.3直接通過這兩個Pod的IP地址和埠號訪問Tomcat服務：#curl 172.17.0.2:8080直接通過Pod的IP地址和埠號可以訪問容器內的應用服務，但是Pod的IP地址是不可靠的，例如Pod所在的Node發生故障，Pod將被k8s重新排程到另一臺Node。Pod的IP地址將發生變化，更重要的是，如果容器應用本身是分散式的部署方式，通過多個例項共同提供服務，就需要在這些例項的前端設定一個負載均衡器來實現請求的分發。kubernetes中的Service就是設計出來用於解決這些問題的核心元件。（2）為了讓客戶端應用能夠訪問到兩個Tomcat Pod 例項，需要建立一個Service來提供服務k8s提供了一種快速的方法，即通過kubectl expose命令來建立：#kubectl expose rc webapp檢視新建立的Service可以看到系統為它分配了一個虛擬的IP地址（clusterIP），而Service所需的埠號則從Pod中的containerPort複製而來：[[email protected] ~]# kubectl expose rc webappservice "webapp" exposed[[email protected] ~]# kubectl get svcNAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGEkubernetes   ClusterIP   10.10.10.1     <none>        443/TCP    19dmysql        ClusterIP   10.10.10.200   <none>        3306/TCP   19dwebapp       ClusterIP   10.10.10.58    <none>        8080/TCP   9s接下來，我們就可以通過Service的IP地址和Service的埠號訪問該Service了：#curl 10.10.10.58:8080這裡，對Service地址10.10.10.58:8080的訪問被自動負載分發到了後端兩個Pod之一。（3）除了使用kubectl expose命令建立Service，我們也可以通過配置檔案定義Service，再通過kubectl create命令進行建立。例如前面的webapp就用，我們可以設定一個Service：webapp-svc.yamlapiVersion: v1kind: Servicemetadata:  name: webappspec:  ports:  - port: 8081    targetPort: 8080  selector:    app: webappService定義中的關鍵欄位是ports和selector。本例中ports定義部分指定了Service所需的虛擬埠號為8081，由於與Pod容器埠號8080不一樣，所以需要在通過targetPort來指定後端Pod的埠。selector定義部分設定的是後端Pod所擁有的label: app=webapp（4）目前kubernetes提供了兩種負載分發策略：RoundRobin和SessionAffinity

• RoundRobin：輪詢模式，即輪詢將請求轉發到後端的各個Pod上
• SessionAffinity：基於客戶端IP地址進行會話保持的模式，第一次客戶端訪問後端某個Pod，之後的請求都轉發到這個Pod上

預設是RoundRobin模式。

7、多埠Service

有時候，一個容器應用提供多個埠服務，可以按下面這樣定義：apiVersion: v1kind: Servicemetadata:  name: webappspec:  ports:  - name: web    port: 8080    targetPort: 8080  - name: management    port: 8005    targetPort: 8005  selector:    app: webapp另一個例子是兩個埠使用了不同的4層協議，即TCP和UDPapiVersion: v1kind: Servicemetadata:  name: kube-dns  namespace: kube-system  labels:    k8s-app: kube-dns    kubernetes.io/cluster-service: "true"    kubernetes.io/name: "KubeDNS"spec:  selector:    k8s-app: kube-dns  clusterIP: 10.10.10.100  ports:  - name: dns    port: 53    protocol: UDP  - name: dns-tcp    port: 53    protocol: TCP

8、Headless Service

有時不需要或不想要負載均衡，以及單獨的 Service IP。 遇到這種情況，可以通過指定 Cluster IP（spec.clusterIP）的值為 "None" 來建立 Headless Service。這個選項允許開發人員自由尋找他們自己的方式，從而降低與 Kubernetes 系統的耦合性。 應用仍然可以使用一種自注冊的模式和介面卡，對其它需要發現機制的系統能夠很容易地基於這個 API 來構建。對這類 Service 並不會分配 Cluster IP，kube-proxy 不會處理它們，而且平臺也不會為它們進行負載均衡和路由。僅依賴於Label Selector將後端的Pod列表返回給呼叫的客戶端。apiVersion: v1kind: Servicemetadata:  name: nginx  labels:    app: nginxspec:  ports:  - port: 80clusterIP: Noneselector:    app: nginx這樣，Service就不再具有一個特定的ClusterIP地址，對其進行訪問將獲得包含Label"app=nginx"的全部Pod列表，然後客戶端程式自行決定如何處理這個Pod列表。例如, StatefulSet就是使用Headless Service為客戶端返回多個服務地址。Lable Secector：

• 配置 Selector：對定義了 selector 的 Headless Service，Endpoint 控制器在 API 中建立了 Endpoints 記錄，並且修改 DNS 配置返回 A 記錄（地址），通過這個地址直接到達 Service 的後端 Pod上。
• 不配置 Selector：對沒有定義 selector 的 Headless Service，Endpoint 控制器不會建立 Endpoints 記錄。 

9、外部服務Service——沒有 selector 的 Service

在某些環境中，應用系統需要將一個外部資料庫用為後端服務進行連線，或將另一個叢集或Namespace中的服務作為服務的後端，這時可以通過建立一個無Label Selector的Service實現：apiVersion: v1kind: Servicemetadata:  name: my-servicespec:  ports:  - protocol: TCP    port: 80    targetPort: 80Servcie 抽象了該如何訪問 Kubernetes Pod，但也能夠抽象其它型別的 backend，例如：

• 希望在生產環境中使用外部的資料庫叢集。
• 希望服務指向另一個 Namespace 中或其它叢集中的服務。
• 正在將工作負載同時轉移到 Kubernetes 叢集和執行在 Kubernetes 叢集之外的 backend。

由於這個 Service 沒有 selector，就不會建立相關的 Endpoints 物件。可以手動將 Service 對映到指定的 Endpoints：kind: EndpointsapiVersion: v1metadata:  name: my-servicesubsets:  - addresses:      - ip: 1.2.3.4    ports:      - port: 9376注意：Endpoint IP 地址不能是 loopback（127.0.0.0/8）、 link-local（169.254.0.0/16）、或者 link-local 多播（224.0.0.0/24）。訪問沒有 selector 的 Service，與有 selector 的 Service 的原理相同。請求將被路由到使用者定義的 Endpoint（該示例中為 1.2.3.4:9376）。ExternalName Service 是 Service 的特例，它沒有 selector，也沒有定義任何的埠和 Endpoint。 相反地，對於執行在叢集外部的服務，它通過返回該外部服務的別名這種方式來提供服務。kind: ServiceapiVersion: v1metadata:  name: my-service  namespace: prodspec:  type: ExternalName  externalName: my.database.example.com當查詢主機 my-service.prod.svc.CLUSTER時，叢集的 DNS 服務將返回一個值為 my.database.example.com 的 CNAME 記錄。 訪問這個服務的工作方式與其它的相同，唯一不同的是重定向發生在 DNS 層，而且不會進行代理或轉發。 如果後續決定要將資料庫遷移到 Kubernetes 叢集中，可以啟動對應的 Pod，增加合適的 Selector 或 Endpoint，修改 Service 的 type。

10、叢集外部訪問Pod或Service的方法

由於Pod和Service是k8s叢集範圍內的虛擬概念，所以叢集外的客戶端系統無法通過Pod的IP地址或者Service的虛擬IP地址和虛擬埠號訪問到它們。為了讓外部客戶端可以訪問這些服務，可以將Pod或Service的埠號對映到宿主機，以使得客戶端應用能夠通過物理機訪問容器應用。

10.1 將容器應用的埠號對映到物理機

（1）通過設定容器級別的hostPort，將容器應用的埠號對映到物理機上檔案pod-hostport.yamlapiVersion: v1kind: Podmetadata:  name: webapp  labels:    app: webappspec:  containers:  - name: webapp    image: tomcat    ports:    - containerPort: 8080      hostPort: 8081通過kubectl create建立這個Pod：#kubectl create -f pod-hostport.yaml通過物理機的IP地址和8081埠號訪問Pod內的容器服務：#curl 10.0.2.6:8081（2）通過設定Pod級別的hostNetwork=true，該Pod中所有容器的埠號都將被直接對映到物理機上設定hostWork=true是需要注意，在容器的ports定義部分如果不指定hostPort，則預設hostPort等於containerPort，如果指定了hostPort，則hostPort必須等於containerPort的值。檔案pod-hostnetwork.yamlapiVersion: v1kind: Podmetadata:  name: webapp-hostnetwork  labels:    app: webapp-hostnetworkspec:  hostNetwork: true  containers:  - name: webapp-hostnetwork    image: tomcat    imagePullPolicy: Never    ports:    - containerPort: 8080建立這個Pod：#kubectl create -f pod-hostnetwork.yaml[[email protected] ~]# kubectl get pod -o wideNAME                   READY     STATUS    RESTARTS   AGE       IP           NODEdapi-test-pod-volume   1/1       Running   4          12d       172.17.0.7   10.0.2.6pod-affinity           1/1       Running   3          11d       172.17.0.4   10.0.2.6webapp                 1/1       Running   0          6m        172.17.0.2   10.0.2.6webapp-hostnetwork     1/1       Running   0          37s       10.0.2.10    10.0.2.10通過物理機的IP地址和8080埠訪問Pod的容器服務#curl 10.0.2.10:8080

10.2 將Service的埠號對映到物理機

（1）通過設定nodePort對映到物理機，同時設定Service的型別為NodePort檔案webapp-svc-nodeport.yamlapiVersion: v1kind: Servicemetadata:  name: webapp-nodeportspec:  type: NodePort  ports:  - port: 8090    targetPort: 8080    nodePort: 8090  selector:    app: webapp建立這個Service：

相關推薦

k8s技術預研8--深入掌握Kubernetes Service

本文內容已經基於k8s v1.8.8進行了驗證測試。k8s的Service定義了一個服務的訪問入口地址，前端的應用通過這個入口地址訪問其背後的一組由Pod副本組成的叢集例項，來自外部的訪問請求被負載均衡到後端的各個容器應用上。Service與其後端Pod副本叢集之間則是通過Label Selector來實現對

k8s技術預研12--kubernetes的常見開源網路元件

k8s的網路模型假定了所有Pod都在一個可以直接連通的扁平的網路空間中。這是因為k8s出自Google，而在GCE裡面是提供了網路模型作為基礎設施的，所以k8s就假定這個網路已經存在。而在大傢俬有的平臺設施裡搭建k8s叢集，就不能假定這種網路已經存在了。我們需要自己實現這個網路，將不同節點上的Docker容器

k8s技術預研13--kubernetes共享儲存原理與動態儲存供應用使用示例

1、共享儲存機制概述Kubernetes對於有狀態的容器應用或者對於資料需要持久化的應用，不僅需要將容器內的目錄掛載到宿主機的目錄或者emptyDir臨時儲存卷，而且需要更加可靠的儲存來儲存應用產生的重要資料，以便容器應用在重建之後，仍然可以使用之前的資料。不過，儲存資源和計

k8s技術預研1--通過一個簡單例項認識k8s基礎概念知識

一、Kubernetes基礎知識 1、在Kubernete中，Service是分散式叢集架構的核心，一個Service物件擁有如下關鍵特徵 擁有一個唯一指定的名字。 擁有一個虛擬IP和埠號。 能夠提供某種遠端服務能力。 被對映到了提供這種服務能力的一組容器應用上。

手機螢幕適配技術預研

前言 隨著手機螢幕的不斷的變化，同時也遇到一些使用者手機螢幕還是處於240*320這種螢幕的大小，當然也存著在一些不規則的螢幕解析度心寸大小。對於很多的UI來說，不同的手機螢幕很多時候得出多套的圖才能保證手機客戶端在不同的螢幕上實現匹配。針對手機客戶端在不同螢幕下的實現進

南京華為技術預研面試經歷

按照約定，下班就直奔新街口的長髮銀座，不過想找到能上到7樓的電梯還真是有點困難，繞著轉了一圈，很失敗的先上了B座電梯，發現7樓的按鈕按不了，最後才登上了A座電梯，到達了7樓。一出電梯門，偌大的幾個華為南京研究所幾個字，做了一個前臺mm，很新潮，不過臉上的粉抹得似乎太多了，頓時

深入學習Kubernetes(一):單節點k8s安裝

ase yun line http number 安裝與配置 num 網絡 pos 環境準備 本文的例子是基於Centos 7的Linux版本，為了讓例子更簡單， 本文省去了網絡Fannel的安裝與配置，只做基本通用的開發環境搭建，希望對大家有幫助。 本例子用於測試的服務器

《深入分析JavaWeb技術內幕》之 8-深入分析ClassLoader工作機制

8.1實體記憶體和虛擬記憶體 所謂實體記憶體就是我們通常所說的RAM（隨機儲存器）。在計算機中，還有一個儲存單元叫暫存器，它用於儲存計算單元執行指令（如浮點、整數等運算時）的中間結果。暫存器的大小決定了一次計算可使用的最大數值。 連線處理器和RAM或者處理器和暫存器的是地址匯流排，這個地址匯

k8s技術--Kubernetes叢集kubectl命令的常見使用方法

簡介：kubectl是一個命令列介面，用於運行鍼對Kubernetes群集的命令。 語法： kubectl [command] [TYPE] [NAME] [flags] command：指定您希望對一個或多個資源執行的操作，

Kubernetes系列04：深入掌握Pod

本節將對kubernetes如何釋出和管理應用進行說明和示例，主要包括Pod和容器的使用、Pod的控制和排程、應用配置管理等內容。1.Pod定義詳解 yaml格式的Pod定義檔案的完整內容： apiVersion: v1 kind: Pod metadata:   name

深入掌握K8S Pod

k8s系列文章： - [什麼是K8S](https://zhuanlan.zhihu.com/p/103124918) - [K8S configmap介紹](https://www.cnblogs.com/ybjourney/p/12363751.html) Pod是k8s中最小的排程單元，包含了一個“

8.深入k8s：資源控制Qos和eviction及其原始碼分析

> 轉載請宣告出處哦~，本篇文章釋出於luozhiyun的部落格：https://www.luozhiyun.com，原始碼版本是[1.19](https://github.com/kubernetes/kubernetes/tree/release-1.19) ![83980769_p0_master12

消息：SQL Server 2017（vNext）的第三個公開的CTP（社區技術預覽版）發布了

start spn system 看到了 一個 get creat 社區 目前 今天看到了一個新聞，跟大家分享一下，有興趣的可以去嘗試一下。 SQL Server 2017 CTP3於5月23日發布了，詳細版本號是6.7.55.0。 大家可以去安裝試試。在下載頁面，目前是S

Docker（一）：Docker核心技術預覽

docker開始學習docker了，想寫一篇docker技術介紹的純理論文章，發現以下網站的文檔寫的特別好，就直接引用了，文章轉載自：http://www.infoq.com/cn/DockerDeep http://www.infoq.com/cn/articles/docker-core-technolo

微軟發布Azure Stack第一個技術預覽版

模式 net cto linux 第一個 企業 網絡 靈敏度 連接 為了提升商業靈敏度和加快創新步伐，各個企業都在迅速地轉向雲服務。在微軟，我們已經見到微軟智能雲Azure的飛速發展和使用，每月我們都有近十萬的新增訂閱量。然而，我們也了解到還有很多企業在完全移到公有雲這點上

[k8s集群系列-10]Kubernetes Service暴露方式及Traefik使用

com b- IE 均衡器 end 國外 add cas 部署 訪問部署在kubernetes集群中服務，有兩種類型： 集群內部實現訪問 集群外部實現訪問 但是不管是集群內部還是外部訪問都是要經過kube-proxy的 集群內部實現訪問 ClusterIP Clus

深入解析 kubernetes 資源管理，容器雲牛人有話說

系統 關系 充足 sig 配置信息 解釋 進行 解決 由於 資源，無論是計算資源、存儲資源、網絡資源，對於容器管理調度平臺來說都是需要關註的一個核心問題。 ? 如何對資源進行抽象、定義？? 如何確認實際可以使用的資源量？? 如何為容器分配它所申請的資源？ 這些問題都是平

Java核心技術卷一 8. java並發

tde mic 出現 表現 枚舉類型 喚醒 發送 queue tar 什麽是線程 每個進程擁有自己的一整套變量，而線程則共享數據。 沒有使用多線程的程序，調用 Thread.sleep 不會創建一個新線程，用於暫停當前線程的活動。程序未結束前無法與程序進行交互。 使用線程給

一文掌握Kubernetes衍生的9大開源專案

Kubernetes是當今容器革命的中心。容器運動使整個IT行業圍繞開放標準進行整合，使所有組織受益，而不僅僅是少數強大的供應商。這就是Kubernetes所代表的：一個建立在開放基礎上的軟體交付世界。   然而，這種開放性不僅僅與Kubernetes有關。相反，在圍繞Kube

深入瞭解Kubernetes REST API的工作方式

關於Kubernetes REST API的工作方式： 在哪裡以及如何定義從REST路徑到處理REST呼叫的函式的對映？ 與etcd的交互發生在哪裡？ 從客戶端發出請求到儲存在etcd中物件的端到端路徑是怎樣的？ Kubernetes REST框架 Kubernetes