一、写在前面：

云提供了kubernetes的Paas服务，但是很多同学对kubernetes的使用不是很清楚，最根本的原因就是出发点不同。cloud是要把技术门槛降低，通过可视化的配置降低学习成本；而企业要的是稳定性，以及故障恢复的时效性，以及故障复盘；这就造成了一系列的问题：
support视角：1.cloud的support 不知道客户做了什么 操作了什么从而陷入trouble
user视角 : 2.只要出问题就是cloud的问题
所以要根本的解决这个问题只能依赖我们不断的了解kubernetes、熟悉kubernetes、kubernetes是一个庞大的生态，很难有人对这个生态圈的每一个组件、每一种解决方案都了如指掌，通过一个现象或者一段报错日志就能定位出问题，并且给一个复盘报告。
前面写运维 是对传统架构做了一种梳理，以及常用的软件做了一个梳理。
而kubernetes提供一个一套新的Linux使用思想，就像当年从物理机到虚拟机的变革一样。我觉得kubernetes直接跑在物理机上也未尝不可，反而是一种更好的方案，因为可以减小一层虚拟化的开销。比如一个10台机器的机柜，每台32核128G 那么我们就有320核、1280G的内存可以用，对于小型公司的话业务场景很难利用到该资源池水位的50%-70%的。

二、Cloud Kubernetes VS private kubernetes

云端的kubernetes致力于打造一个Paas平台，从阿里云的产品迭代就知道了，是为了meet cloud native的路线的。目前阿里云有几个版本的kubernetes平台：
1.kubernetes： 3master HA+N（n>1）worker集群
特点：组件自由可控
成本：多出3台HA master的钱

2.kubernetes托管版：0master +N(n>1)worker集群
特点：组件不可控，master托管在阿里云，丧失了很多扩展的可能性
成本：节约掉了3台HA master

3.多可用区kubernetes
特点：节点可以分布多可用区，避免IOHANG造成某可用区瘫痪 导致可用区故障
成本：与普通kubernetes版没有太多差异

4.serverless版
特点 : 弱化了服务器的概念，基础资源从ECS变成了交付的ECI实例，按量选取
成本：低，资源用多少给多少钱，也易于扩展，是理想中的主流，实际上不可控因素太多

而自建的kubernetes自由度很大，可以使用社区的任何插件，甚至阿里云提供的插件也可以使用，所以如果有运维能力的话，这种集群是最适合应用于生产的。目前有个小问题就是阿里云不支持vip，所以如果要自建ha-master的话有点麻烦，因为自建master-ha实际上是在每个master上装haproxy结合keepalived来实现的，部署的yaml模板里面的master节点ip实际上是ha提供的vip。
所以要自己部署ha集群的话，目前只能使用阿里云的lb，通过阿里云负载均衡代理进来。
所以考虑到这种场景，如果没有时间瞎折腾的话还是使用阿里云的集群比较好。写这个连载就是想通过对比，让大家更好的理解kubernetes，也是自己的一个学习过程，同时希望能对大家的技术选型能有所帮助。

三、kubeadm部署kubernetes 1.13.1集群

为了贴近阿里云当前发布最新版本，选用了1.13而非最新的1.14kubernetes集群

1.资源规划：

主机名	IP地址	角色	组件	配置
k8s-master	192.168.0.242	master	kube-apiserver kube-controller-manager kube-scheduler kube-proxy etcd coredns kube-flannel	2C 4G
k8s-node1	192.168.0.243	worker	kube-proxy kube-flannel	2C 4G
k8s-node2	192.168.0.244	worker	kube-proxy kube-flannel	2C 4G
k8s-node3	192.168.0.245	worker	kube-proxy kube-flannel	2C 4G

2.基本配置：

docker的安装 ： Kubernetes默认的容器运行时仍然是Docker，使用的是kubelet中内置dockershim CRI实现。需要注意的是，Kubernetes 1.13最低支持的Docker版本是1.11.1，最高支持是18.06，而Docker最新版本已经是18.09了，故我们安装时需要指定版本为18.06.1-ce。

一键安装：
$ curl -sSL https://raw.githubusercontent.com/willzhang/shell/master/install_docker.sh | sh

修改主机名：

#master节点:
hostnamectl set-hostname k8s-master
#node1节点：
hostnamectl set-hostname k8s-node1
#node2节点:
hostnamectl set-hostname k8s-node2
#node3节点:
hostnamectl set-hostname k8s-node3

cat >> /etc/hosts << EOF
192.168.0.242 k8s-master
192.168.0.243 k8s-node1
192.168.0.244 k8s-node2
192.168.0.245 k8s-node2
EOF
#关闭防火墙和selinux  默认是关闭的 阿里云主机可以跳过这步
systemctl stop firewalld && systemctl disable firewalld
sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config && setenforce 0

#关闭swap  默认也是关闭的  阿里云主机跳过这一步
swapoff -a
yes | cp /etc/fstab /etc/fstab_bak
cat /etc/fstab_bak |grep -v swap > /etc/fstab

配置时间同步
使用chrony同步时间，配置master节点与网络NTP服务器同步时间，所有node节点与master节点同步时间。
master:

#安装chrony：
yum install -y chrony
#注释默认ntp服务器
sed -i 's/^server/#&/' /etc/chrony.conf
#指定上游公共 ntp 服务器，并允许其他节点同步时间
cat >> /etc/chrony.conf << EOF
server 0.asia.pool.ntp.org iburst
server 1.asia.pool.ntp.org iburst
server 2.asia.pool.ntp.org iburst
server 3.asia.pool.ntp.org iburst
allow all
EOF
#重启chronyd服务并设为开机启动：
systemctl enable chronyd && systemctl restart chronyd
#开启网络时间同步功能
timedatectl set-ntp true
 

worker:

#安装chrony：
yum install -y chrony
#注释默认服务器
sed -i 's/^server/#&/' /etc/chrony.conf
#指定内网 master节点为上游NTP服务器
echo server 192.168.0.242 iburst >> /etc/chrony.conf
#重启服务并设为开机启动：
systemctl enable chronyd && systemctl restart chronyd
验证
[root@iZt4n4ll1c59ld8prjmm8kZ ~]# chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^* k8s-master                    2   6    17    35  -4000ns[  -38us] +/-   39ms
查看存在以^*开头的行，说明已经与服务器时间同步

修改iptables相关参数
RHEL / CentOS 7上的一些用户报告了由于iptables被绕过而导致流量路由不正确的问题。创建/etc/sysctl.d/k8s.conf文件，添加如下内容：

cat <<EOF >  /etc/sysctl.d/k8s.conf
vm.swappiness = 0
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF

# 使配置生效
modprobe br_netfilter
sysctl -p /etc/sysctl.d/k8s.conf
 

加载ipvs相关模块
由于ipvs已经加入到了内核的主干，所以为kube-proxy开启ipvs的前提需要加载以下的内核模块：
在所有的Kubernetes节点执行以下脚本:

cat > /etc/sysconfig/modules/ipvs.modules <<EOF
#!/bin/bash
modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack_ipv4
EOF

#执行脚本
chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep -e ip_vs -e nf_conntrack_ipv4

上面脚本创建了/etc/sysconfig/modules/ipvs.modules文件，保证在节点重启后能自动加载所需模块。 使用lsmod | grep -e ip_vs -e nf_conntrack_ipv4命令查看是否已经正确加载所需的内核模块。
接下来还需要确保各个节点上已经安装了ipset软件包。 为了便于查看ipvs的代理规则，最好安装一下管理工具ipvsadm。

# yum install ipset ipvsadm -y

安装kubeadm、kubelet、kubectl
官方安装文档可以参考：
https://kubernetes.io/docs/setup/independent/install-kubeadm/

kubelet 在群集中所有节点上运行的核心组件, 用来执行如启动pods和containers等操作。
kubeadm 引导启动k8s集群的命令行工具，用于初始化 Cluster。
kubectl 是 Kubernetes 命令行工具。通过 kubectl 可以部署和管理应用，查看各种资源，创建、删除和更新各种组件

#配置kubernetes.repo的源，由于官方源国内无法访问，这里使用阿里云yum源
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

#在所有节点上安装指定版本 kubelet、kubeadm 和 kubectl
yum install -y kubelet-1.13.1 kubeadm-1.13.1 kubectl-1.13.1

#启动kubelet服务
systemctl enable kubelet && systemctl start kubelet
 

3.master配置

完整的官方文档可以参考：
https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/

kubeadm init \
    --apiserver-advertise-address= 192.168.0.242 \
    --image-repository registry.aliyuncs.com/google_containers \
    --kubernetes-version v1.13.1 \
    --pod-network-cidr=10.244.0.0/16
 

说明一下：这里pod的cidr网段不要和vpc重合 否则会导致流量转发异常 这也就是weish为啥阿里云建集群有地址判断的原因了

初始化命令:

--apiserver-advertise-address

指明用 Master 的哪个 interface 与 Cluster 的其他节点通信。如果 Master 有多个 interface，建议明确指定，如果不指定，kubeadm 会自动选择有默认网关的 interface。

--pod-network-cidr

指定 Pod 网络的范围。Kubernetes 支持多种网络方案，而且不同网络方案对 --pod-network-cidr 有自己的要求，这里设置为 10.244.0.0/16 是因为我们将使用 flannel 网络方案，必须设置成这个 CIDR。

--image-repository

Kubenetes默认Registries地址是 k8s.gcr.io，在国内并不能访问 gcr.io，在1.13版本中我们可以增加–image-repository参数，默认值是 k8s.gcr.io，将其指定为阿里云镜像地址：registry.aliyuncs.com/google_containers。
 

--kubernetes-version=v1.13.1

关闭版本探测，因为它的默认值是stable-1，会导致从https://dl.k8s.io/release/stable-1.txt下载最新的版本号，我们可以将其指定为固定版本（最新版：v1.13.1）来跳过网络请求 ```

 
[root@iZt4n4ll1c59ld8prjmm8iZ ~]# kubeadm init \
>     --apiserver-advertise-address= 192.168.0.242 \
>     --image-repository registry.aliyuncs.com/google_containers \
>     --kubernetes-version v1.13.1 \
>     --pod-network-cidr=10.244.0.0/16
[init] Using Kubernetes version: v1.13.1
[preflight] Running pre-flight checks
    [WARNING SystemVerification]: this Docker version is not on the list of validated versions: 18.09.3. Latest validated version: 18.06
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'

[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Activating the kubelet service
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [k8s-master localhost] and IPs [192.168.0.242 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [k8s-master localhost] and IPs [192.168.0.242 127.0.0.1 ::1]
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [k8s-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.0.242]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 20.003958 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.13" in namespace kube-system with the configuration for the kubelets in the cluster
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-master" as an annotation
[mark-control-plane] Marking the node k8s-master as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node k8s-master as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: 86krb1.txcuqz85bgko2xup
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join 192.168.0.242:6443 --token 86krb1.txcuqz85bgko2xup --discovery-token-ca-cert-hash sha256:87ddcfa1adec67772a33d58bcdaba3cb07c859a25b7d891422f29bd79f9d9b85

plus:至此 kubernetes的部署变的跟swarm一样简单了，node节点只需要获得token就阔以加入到master

初始化过程说明：

[preflight] kubeadm 执行初始化前的检查。
[kubelet-start] 生成kubelet的配置文件”/var/lib/kubelet/config.yaml”
[certificates] 生成相关的各种token和证书
[kubeconfig] 生成 KubeConfig 文件，kubelet 需要这个文件与 Master 通信
[control-plane] 安装 Master 组件，会从指定的 Registry 下载组件的 Docker 镜像。
[bootstraptoken] 生成token记录下来，后边使用kubeadm join往集群中添加节点时会用到
[addons] 安装附加组件 kube-proxy 和 kube-dns。
Kubernetes Master 初始化成功，提示如何配置常规用户使用kubectl访问集群。
提示如何安装 Pod 网络。
提示如何注册其他节点到 Cluster。

配置 kubectl

kubectl 是管理 Kubernetes Cluster 的命令行工具，前面我们已经在所有的节点安装了 kubectl。Master 初始化完成后需要做一些配置工作，然后 kubectl 就能使用了。
依照 kubeadm init 输出的最后提示，推荐用 Linux 普通用户执行 kubectl。

 #创建普通用户并设置密码123456
useradd centos && echo "centos:123456" | chpasswd centos

#追加sudo权限,并配置sudo免密
sed -i '/^root/a\centos  ALL=(ALL)       NOPASSWD:ALL' /etc/sudoers

#保存集群安全配置文件到当前用户.kube目录
su - centos
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

#启用 kubectl 命令自动补全功能（注销重新登录生效）
echo "source <(kubectl completion bash)" >> ~/.bashrc

需要这些配置命令的原因是：Kubernetes 集群默认需要加密方式访问。所以，这几条命令，就是将刚刚部署生成的 Kubernetes 集群的安全配置文件，保存到当前用户的.kube 目录下，kubectl 默认会使用这个目录下的授权信息访问 Kubernetes 集群。
如果不这么做的话，我们每次都需要通过 export KUBECONFIG 环境变量告诉 kubectl 这个安全配置文件的位置。
配置完成后centos用户就可以使用 kubectl 命令管理集群了。

通过 kubectl describe 指令的输出，我们可以看到 NodeNotReady 的原因在于，我们尚未部署任何网络插件，kube-proxy等组件还处于starting状态。
另外，我们还可以通过 kubectl 检查这个节点上各个系统 Pod 的状态，其中，kube-system 是 Kubernetes 项目预留的系统 Pod 的工作空间（Namepsace，注意它并不是 Linux Namespace，它只是 Kubernetes 划分不同工作空间的单位）：
可以看到，CoreDNS依赖于网络的 Pod 都处于 Pending 状态，即调度失败。这当然是符合预期的：因为这个 Master 节点的网络尚未就绪。
集群初始化如果遇到问题，可以使用kubeadm reset命令进行清理然后重新执行初始化。

部署网络插件
要让 Kubernetes Cluster 能够工作，必须安装 Pod 网络，否则 Pod 之间无法通信。
Kubernetes 支持多种网络方案，这里我们使用 flannel
执行如下命令部署 flannel：
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

可以看到，所有的系统 Pod 都成功启动了，而刚刚部署的flannel网络插件则在 kube-system 下面新建了一个名叫kube-flannel-ds-amd64-lkf2f的 Pod，一般来说，这些 Pod 就是容器网络插件在每个节点上的控制组件。
Kubernetes 支持容器网络插件，使用的是一个名叫 CNI 的通用接口，它也是当前容器网络的事实标准，市面上的所有容器网络开源项目都可以通过 CNI 接入 Kubernetes，比如 Flannel、Calico、Canal、Romana 等等，它们的部署方式也都是类似的“一键部署”。
再次查看master节点状态已经为ready状态：
至此，Kubernetes 的 Master 节点就部署完成了。如果你只需要一个单节点的 Kubernetes，现在你就可以使用了。不过，在默认情况下，Kubernetes 的 Master 节点是不能运行用户 Pod 的。

4.worker配置

获取master的token

[root@iZt4n4ll1c59ld8prjmm8iZ kubernetes]# kubeadm token create --print-join-command
kubeadm join 192.168.0.242:6443 --token 3bpx58.px0vceawb0bjpfeq --discovery-token-ca-cert-hash sha256:87ddcfa1adec67772a33d58bcdaba3cb07c859a25b7d891422f29bd79f9d9b85

所有节点依次执行

验证：

[centos@k8s-master kubernetes]$ kubectl get nodes
NAME         STATUS   ROLES    AGE   VERSION
k8s-master   Ready    master   52m   v1.13.1
k8s-node1    Ready    <none>   46s   v1.13.1
k8s-node2    Ready    <none>   26s   v1.13.1
k8s-node3    Ready    <none>   24s   v1.13.1

nodes状态全部为ready，由于每个节点都需要启动若干组件，如果node节点的状态是 NotReady，可以查看所有节点pod状态，确保所有pod成功拉取到镜像并处于running状态：
现在把kubeconfig拷贝到各node上验证：

这时，所有的节点都已经 Ready，Kubernetes Cluster 创建成功，一切准备就绪。
如果pod状态为Pending、ContainerCreating、ImagePullBackOff 都表明 Pod 没有就绪，Running 才是就绪状态。
如果有pod提示Init:ImagePullBackOff，说明这个pod的镜像在对应节点上拉取失败，我们可以通过 kubectl describe pod 查看 Pod 具体情况，以确认拉取失败的镜像：
这里看最后events输出内容，可以看到在下载 image 时失败，如果网络质量不好，这种情况是很常见的。我们可以耐心等待，因为 Kubernetes 会重试，我们也可以自己手工执行 docker pull 去下载这个镜像。

[root@k8s-node2 ~]# docker pull quay.io/coreos/flannel:v0.10.0-amd64
v0.10.0-amd64: Pulling from coreos/flannel
ff3a5c916c92: Already exists
8a8433d1d437: Already exists
306dc0ee491a: Already exists
856cbd0b7b9c: Already exists
af6d1e4decc6: Already exists
Digest: sha256:88f2b4d96fae34bfff3d46293f7f18d1f9f3ca026b4a4d288f28347fcb6580ac
Status: Image is up to date for quay.io/coreos/flannel:v0.10.0-amd64
[root@k8s-node2 ~]#

如果无法从 quay.io/coreos/flannel:v0.10.0-amd64 下载镜像，可以从阿里云或者dockerhub镜像仓库下载，然后改回原来的tag即可：

docker pull registry.cn-hangzhou.aliyuncs.com/kubernetes_containers/flannel:v0.10.0-amd64
docker tag registry.cn-hangzhou.aliyuncs.com/kubernetes_containers/flannel:v0.10.0-amd64 quay.io/coreos/flannel:v0.10.0-amd64
docker rmi registry.cn-hangzhou.aliyuncs.com/kubernetes_containers/flannel:v0.10.0-amd64

查看master的镜像：

查看node节点下载了哪些镜像：

至此，一个1master+3worker的集群就部署完毕了，下面就是测试各个组件了
Plus：集群证书1年为周期，如果集群超过了1年的话需要重新更新证书，证书过期不影响集群功能，但是kubectl无法连接到apiserver

四、kubernetes集群体验

参考文档：
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

如果有docker使用基础的同学这里就很简单了，说到底，kubernetes是对docker的能力扩展。回想当时跑第一个容器是什么呢？docker run吧，同理，kuernetes也可以通过kubectl来管理；而当时docker是怎么实现容器编排的呢？docker-compose吧，同理，kubernetes其实也就是一个编排工具，可以利用yaml文件结合kubernetes的能力标签 apply -f 出一个完美的应用；说到kubernetes是compose的扩展，是因为他有更强大的能力，比如流量管理、服务管理、租户隔离等等。

1.创建一个nginx deployment扩容2个nginx

我们都知道无论pod ip还是service ip 都是一个集群内的vip，是一个集群内的概念，只能在集群内才能访问到。
那么我们如何才能在公网能访问到呢？这个就需要我们通过kubeproxy把端口映射到节点

[centos@k8s-master ~]$ kubectl expose deployment nginx --port=80 --type=NodePort
service/nginx exposed
[centos@k8s-master ~]$ kubectl get services nginx
NAME    TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
nginx   NodePort   10.98.9.151   <none>        80:30699/TCP   15s

访问的生命周期：
1.我们在创建pod的时候在node1 ，node3 上起了2个replicas 这是随机的 scheduler优选之后产生的部署节点
2.集群内有2个vip，把请求转发到pod里面 telnet 10.244.1.2 80 是通的 其实这就是flannel cni产生的网络端点

这个端点是我们刚才创建集群时候指定cni网段产生的 --pod-network-cidr=10.244.0.0/16
随着pod的增多 会逐渐把网段耗尽，所以最开始的时候一定要规划好集群规模
3.kubeproxy映射，把flannel虚拟网络的地址和宿主机地址映射 在每个节点上启动一个node port 映射到集群内部
这也就是为啥node 2并没有分配到pod 但是端口是通的的原因
4.最后通过node的端口来访问服务，node可以通过阿里云的lb组件映射到负载均衡上，阿里云就是这么做的。如果是自己的话，那么就建个nginx转发吧，或者手工绑定slb或者sdk绑定 都OK。
5.正常的访问：
slb:80-->nodeport:30699-->flannel cni:80-->container inner port

dns验证：

 kubectl run -it curl --image=radial/busyboxplus:curl

通过pod ip（cni）访问 也没有问题

Pod调度到Master节点
出于安全考虑，默认配置下Kubernetes不会将Pod调度到Master节点。查看Taints字段默认配置：
默认是污点节点 pod无法创建

解除污点，允许业务容器pod调度

kubectl taint node k8s-master node-role.kubernetes.io/master-

由于是单节点的，我怕把master搞挂了，还是恢复unschedule吧

kubectl taint node k8s-master node-role.kubernetes.io/master=:NoSchedule

kube-proxy开启ipvs

[centos@k8s-master ~]$  kubectl edit cm kube-proxy -n kube-system
configmap/kube-proxy edited

什么是IPVS？
IPVS (IP Virtual Server，IP虚拟服务器)是基于Netfilter的、作为linux内核的一部分实现传输层负载均衡的技术，通常称为第4层LAN交换。

IPVS集成在LVS(Linux Virtual Server)中，它在主机中运行，并在真实服务器集群前充当负载均衡器。IPVS可以将对TCP/UDP服务的请求转发给后端的真实服务器，并使真实服务器的服务在单个IP地址上显示为虚拟服务。因此IPVS天然支持Kubernetes Service。

为什么选择IPVS
随着kubernetes使用量的增长，其资源的可扩展性变得越来越重要。特别是对于使用kubernetes运行大型工作负载的开发人员或者公司来说，service的可扩展性至关重要。

kube-proxy是为service构建路由规则的模块，之前依赖iptables来实现主要service类型的支持，比如(ClusterIP和NodePort)。但是iptables很难支持上万级的service，因为iptables纯粹是为防火墙而设计的，并且底层数据结构是内核规则的列表。

kubernetes早在1.6版本就已经有能力支持5000多节点，这样基于iptables的kube-proxy就成为集群扩容到5000节点的瓶颈。举例来说，如果在一个5000节点的集群，我们创建2000个service，并且每个service有10个pod，那么我们就会在每个节点上有至少20000条iptables规则，这会导致内核非常繁忙。

基于IPVS的集群内负载均衡就可以完美的解决这个问题。IPVS是专门为负载均衡设计的，并且底层使用哈希表这种非常高效的数据结构，几乎可以允许无限扩容。

IPVS vs. IPTABLES区别
IPVS模式在Kubernetes v1.8中引入，并在v1.9中进入了beta。 1.11中实现了GA(General Availability)。IPTABLES模式在v1.1中添加，并成为自v1.2以来的默认操作模式。 IPVS和IPTABLES都基于netfilter。 IPVS模式和IPTABLES模式之间的差异如下：

IPVS为大型集群提供了更好的可扩展性和性能。
IPVS支持比iptables更复杂的负载平衡算法（最小负载，最少连接，位置，加权等）。
IPVS支持服务器健康检查和连接重试等。

移除节点和集群
kubernetes集群移除节点
以移除k8s-node2节点为例，在Master节点上运行：
kubectl drain k8s-node2 --delete-local-data --force --ignore-daemonsets
kubectl delete node k8s-node2
上面两条命令执行完成后，在k8s-node2节点执行清理命令，重置kubeadm的安装状态：
kubeadm reset
在master上删除node并不会清理k8s-node2运行的容器，需要在删除节点上面手动运行清理命令。
如果你想重新配置集群，使用新的参数重新运行kubeadm init或者kubeadm join即可。