一個簡單的網際網路應用

K8S叢集的基本構造

master：負責管理整個叢集，例如，對應用進行排程(擴縮)、維護應用期望的狀態、對應用進行釋出等。
node：叢集中的宿主機（可以是物理機也可以是虛擬機器），每個node上都有一個agent，名為kubelet，用於跟master通訊。同時一個node需要有管理容器的工具包，用於管理在node上執行的容器(如docker)。一個k8s叢集至少要有3個節點

master節點上有如下程序（一個apiserver，一個controller-manager，一個scheduler）

$ ps -elf|grep -i Kubernetes
0 R umelog   11077  5416  0  80   0 - 28166 -      14:51 pts/2    00:00:00 grep
 
 --color=auto -i Kubernetes
4 S root     63481     1  1  80   0 - 65218 futex_ 10:48 ?        00:02:52 /usr/bin/kube-apiserver --storage-backend=etcd2 --insecure-bind-address=0.0.0.0 --insecure-port=1180 --etcd-servers=http://10.237.65.192:2379,http://10.237.65.193:2379,http://10.237.65.194:2379 --service-cluster-ip-range=
 
169.169.0.0/16 --admission_control=NamespaceLifecycle,LimitRanger,ResourceQuota,ServiceAccount --service-node-port-range=10-65535 --client_ca_file=/etc/kubernetes/ssl/ca.crt --tls-private-key-file=/etc/kubernetes/ssl/apiserver.key --tls-cert-file=/etc/kubernetes/ssl/apiserver.crt --logtostderr=false --log-dir=/opt/log/kubernetes --v=
 
0 --allow_privileged=true
4 S root     63560     1  1  80   0 - 27582 futex_ 10:50 ?        00:02:35 /usr/bin/kube-controller-manager --node-sync-period=10s --service_account_private_key_file=/etc/kubernetes/ssl/apiserver.key --root-ca-file=/etc/kubernetes/ssl/ca.crt --v=0 --logtostderr=false --log-dir=/var/log/kubernetes --master=http://10.237.65.192:1180
4 S root     63603     1  0  80   0 - 15208 futex_ 10:51 ?        00:01:09 /usr/bin/kube-scheduler --logtostderr=false --log-dir=/var/log/kubernetes --v=0 --master=http://10.237.65.192:1180

API server作為叢集的核心，負責各個功能模組之間的通訊。叢集中各個模組通過API server將資訊存入etcd，當需要獲取和操作這些資料時，則通過API server提供的REST介面來實現，從而實現各模組之間的資訊互動。

Node節點下如有日下程序（一個proxy，一個kublet）

 ps -elf|grep -i kubernetes
4 S root      2672     1  0  80   0 - 14101 futex_ 13:08 ?        00:00:13 /usr/bin/kube-proxy --proxy-mode=iptables --logtostderr=false --log-dir=/var/log/kubernetes --v=0 --master=http://10.237.65.192:1180
0 S umelog   20568 20447  0  80   0 - 28167 pipe_w 15:28 pts/0    00:00:00 grep --color=auto -i kubernetes
4 S root     62199     1  0  80   0 - 319964 futex_ 11:02 ?       00:02:13 /usr/bin/kubelet --root_dir=/var/kubernetes --v=0 --pod_infra_container_image=10.237.65.192:1179/google_containers/pause:3.0 --cluster_dns=169.169.0.100 --cluster_domain=cluster.local --address=0.0.0.0 --port=10250 --api_servers=http://10.237.65.192:1180 --logtostderr=false --allow_privileged=true --log-dir=/var/log/kubernetes

基本概念

在K8S中，Pod是建立或部署的最小/最簡單的基本單位，一個Pod是由多個Docker容器組成的容器組。

Pod

Kubernetes中的Pod使用可分兩種主要方式：

• Pod中執行一個容器。“one-container-per-Pod”模式是Kubernetes最常見的用法; 在這種情況下，你可以將Pod視為單個封裝的容器，但是Kubernetes是直接管理Pod而不是容器。
• Pod中執行多個需要一起工作的容器。Pod可以封裝緊密耦合的應用，它們需要由多個容器組成，它們之間能夠共享資源，這些容器可以形成一個單一的內部service單位 - 一個容器共享檔案，另一個“sidecar”容器來更新這些檔案。Pod將這些容器的儲存資源作為一個實體來管理。

Service

是真實應用服務的抽象。Service通常用來將浮動的資源與後端真實提供服務的容器進行關聯。Service對外表現為一個單一的訪問介面，外部不需要了解後端的規模與機制。Service是定義在叢集中一組執行Pod集合的抽象資源，它提供了所有相同的功能。當一個Service資源被建立後，將會分配一個唯一的IP（也叫做叢集IP），這個IP地址將存在於Service的整個生命資源，Service一旦被建立，整個IP無法進行修改。Pod可以通過Service進行通訊，並且所有的通訊將會通過Service自動負載均很到所有的Pod中的容器。

Pod IP／Cluster IP／外部IP

• Pod IP
  Kubernetes的最小部署單元是Pod。利用Flannel作為不同HOST之間容器互通技術時，由Flannel和etcd維護了一張節點間的路由表。Flannel的設計目的就是為叢集中的所有節點重新規劃IP地址的使用規則，從而使得不同節點上的容器能夠獲得“同屬一個內網”且”不重複的”IP地址，並讓屬於不同節點上的容器能夠直接通過內網IP通訊。每個Pod啟動時，會自動建立一個映象為gcr.io/google_containers/pause:0.8.0的容器，pod內部與外部的通訊經由此容器代理，該容器的IP也可以稱為Pod IP。
• Cluster IP
  Pod IP 地址是實際存在於某個網絡卡(可以是虛擬裝置)上的，但Service Cluster IP就不一樣了，沒有網路裝置為這個地址負責。它是由kube-proxy使用Iptables規則重新定向到其本地埠，再均衡到後端Pod的。
• 外部IP
  Service物件在Cluster IP range池中分配到的IP只能在內部訪問，如果服務作為一個應用程式內部的層次，還是很合適的。如果這個Service作為前端服務，準備為叢集外的客戶提供業務，我們就需要給這個服務提供公共IP了。

Replication Controller

Replication Controller 保證了在所有時間內，都有特定數量的Pod副本正在執行，如果太多了，Replication Controller就殺死幾個，如果太少了，Replication Controller會新建幾個，和直接建立的pod不同的是，Replication Controller會替換掉那些刪除的或者被終止的pod，不管刪除的原因是什麼（維護阿，更新啊，Replication Controller都不關心）。基於這個理由，我們建議即使是隻建立一個pod，我們也要使用Replication Controller。Replication Controller 就像一個程序管理器，監管著不同node上的多個pod,而不是單單監控一個node上的pod,Replication Controller 會委派本地容器來啟動一些節點上服務（Kubelet ,Docker）。

流程和原理

Service啟動流程

• 當我們的Service被建立時，Kubernetes給它分配一個地址10.0.0.1（Cluster IP）。這個地址從我們啟動API的service-cluster-ip-range引數(舊版本為portal_net引數)指定的地址池中分配，比如–service-cluster-ip-range=10.0.0.0/16。
• 叢集內的所有kube-proxy都會注意到這個Service。當proxy發現一個新的service後，它會在本地節點開啟一個任意埠，建相應的iptables規則，重定向服務的IP和port到這個新建的埠，開始接受到達這個服務的連線。

kube-proxy轉發的兩種模式

由kube-proxy轉發，效率不是很高

kube-proxy只負責更改iptable的設定。核心轉發。效率高。

元件介紹

Etcd

etcd的官網介紹是一個分散式的K/V儲存，而Zookeeper的官網介紹是一個高度可用的分散式協調者。看起來他們做的事情完全不同啊，那我們來比較一下功能介紹。但是實際上二者非常類似。

二者的使用場景的對比如下

ETCD儲存著docker叢集的一些基本配置。

$ etcdctl ls /registry
/registry/minions
/registry/deployments
/registry/ranges
/registry/services
/registry/apiregistration.k8s.io
/registry/configmaps
/registry/events
/registry/secrets
/registry/replicasets
/registry/pods
/registry/controllers
/registry/namespaces
/registry/serviceaccounts

TLS

SSL協議位於TCP/IP協議與各種應用層協議之間，為資料通訊提供安全支援。SSL協議可分為兩層： SSL記錄協議（SSL Record Protocol）：它建立在可靠的傳輸協議（如TCP）之上，為高層協議提供資料封裝、壓縮、加密等基本功能的支援。

安全傳輸層協議（TLS）用於在兩個通訊應用程式之間提供保密性和資料完整性。該協議由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。較低的層為 TLS 記錄協議，位於某個可靠的傳輸協議（例如 TCP）上面，與具體的應用無關，所以，一般把TLS協議歸為傳輸層安全協議。

flannel

根據官網的描述，flannel是一個專為kubernetes定製的三層網路解決方案，主要用於解決容器的跨主機通訊問題。

元件選擇

Kubernetes 1.9 <–Docker 1.11.2 to 1.13.1 and 17.03.x
Kubernetes 1.8 <–Docker 1.11.2 to 1.13.1 and 17.03.x
Kubernetes 1.7 <–Docker 1.10.3, 1.11.2, 1.12.6
Kubernetes 1.6 <–Docker 1.10.3, 1.11.2, 1.12.6
Kubernetes 1.5 <–Docker 1.10.3, 1.11.2, 1.12.3

常用命令kubeadm/kubelet/kubectl

kubeadm —— 啟動 k8s 叢集的命令工具
kubelet —— 叢集容器內的命令工具
kubectl —— 操作叢集的命令工具