1. kubernetes(以下简称k8s)

基础概念

Master
Cluster 的大脑，主要职责是调度，可以运行多个master 来保证高可用。
Node
职责是运行容器应用，Node 由Master 管理，负责监控并汇报容器的状态，同时根据Master 的要求管理容器的生命周期。
Pod
Pod 是K8s 的最小工作单元。每个Pod 包含一个或多个容器。

1. 有些容器天生就是需要紧密联系，一起工作。Pod 提供了比容器更高层次的抽象，K8s 以Pod 为最小单位进行调度、扩展、共享资源、管理生命周期。
2. Pod 中的所有容器使用同一个网络的namespace，即相同的IP 地址和Port空间。它们可以直接用localhost 通信。同样的，这些容器可以共享存储，当K8s 挂载Volume 到Pod 上，本质上是将volume 挂载到Pod 中的每一个容器。

Pod 控制器
K8s 通常不直接创建Pod，而是通过Controller 来管理Pod。Controller 中定义了pod 的部署属性，比如几个副本、在什么样的Node 上运行等。K8s 提供了多种Controller，包括Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等。

1. ReplicationController （副本控制器），确保Pod 的数量始终保持设定的个数。也支持Pod 的滚动更新。
2. ReplicaSet （副本集），它不直接使用，有一个声明式更新的控制器叫Deployment 来负责管理。但是Deployment 只能负责管理那些无状态的应用。
3. StatefulSet （有状态副本集），负责管理有状态的应用。
4. DaemonSet ，如果需要在每一个Node 上只运行一个副本，而不是随意运行，就需要DaemonSet。
5. Job，运行作业，对于时间不固定的操作，比如：某个应用生成了一大堆数据集，现在需要临时启动一个Pod 去清理这些数据集，清理完成后，这个Pod 就可以结束了。这些不需要一直处于运行状态的应用，就用Job 这个类型的控制器去控制。如果Pod 运行过程中意外中止了，Job负责重启Pod。如果Pod 任务执行完了，就不需要再启动了。
6. Cronjob，周期性作业。

Service
Deployement 可以部署多个副本，每个Pod 都有自己的副IP，外界如何访问这些副本。Pod 会被频繁的销毁和重启，IP 实时变化，不能用IP， 答案是通过service。K8s service 定义了外界访问一组特定Pod 的方式。service 有自己的IP 和端口，service 为Pod 提供了负载均衡。

Namespace:
Namespace 将物理的Cluster 逻辑上划分成多个虚拟Cluster，每个Cluster 就是一个Namespace。不同的Namespace 里的资源是完全隔离的。

1. default：默认的namespace
2. kube-system: K8s 自己创建的的系统资源放到这个namespace

K8S 的架构

Kubernetes 集群包含有节点代理Kubelet 和Master 组件（APIs，scheduler，etc.），下面是K8S 的架构图。

Master 节点包含API Server、Scheduler（调度器）、ControllerManager（控制器管理器）这三个核心的组件。

Node 节点包含的核心组件有Kubelet、Docker 容器引擎、Kube-proxy

API Server（kube-apiserver）
提供了HTTP/HTTPS RESTful API,即Kubernetes API。API server 是Kubernetes Cluster 的前端接口。其他客户端工具（CLI 或UI）以及K8S其它组件可以通过它管理Cluster 资源。

Scheduler(kube-scheduler)
调度器，它负责决定将Pod 放在哪个Node 上运行。调度时候考虑Cluster拓扑，各个节点的负载，以及应用对高可用、性能、数据亲和性的需求。

Controller-Manager
负责监控每一个Controller（控制器）的健康状态，并确保控制器是健康的。而控制器是确保Pod 健康的组件。

etcd
负责保存K8s Cluster 的配置信息和各种资源的状态信息。当数据发生变化时，etcd 可以快速的通知K8s 组件。

Pod 网络
Pod 能通信，k8s cluster 必须部署Pod 网络（比如flannel 是其中一个方案）

Kubelet
是Node 的agent,当scheduler 确定在某个Node 上运行Pod 后，会将Pod 的具体配置信息（image、volume 等）发送给该节点的kubelet，kubelet 根据这些信息创建和运行容器，并向Master 报告运行状态。

Kube-proxy
service 在逻辑上代表了后端的多个Pod，外界通过service 访问Pod。service接收到的请求是如何转发到Pod 的呢？这就是kube-proxy 要完成的工作。每个node 都运行kube-proxy 服务，它负责将访问service 的TCP/UDP 数据流转发到后端容器。如果有多个副本，kube-proxy 实现负载均衡。

2. Kubernetes 集群搭建

环境准备

使用docker 18.09.9 和kubelet-1.16.4，要求centos7.6 以上版本

关闭selinux
查看selinux 是否关闭

先设置临时关闭

永久关闭

关闭swap
k8s 要求系统关闭，否则安装过程会报错
查看系统是否关闭了swap

临时禁用：swapoff -a

永久禁用：sed -i.bak ‘/swap/s/^/#/’ /etc/fstab ##注释掉swap 那一行作用就是修改/etc/fstab 配置为如下：

配置ip_forward 转发
ip_forward 配置文件当前内容为0，表示禁止数据包转发，将其修改为1 表示允许

echo “1” > /proc/sys/net/ipv4/ip_forward

更新yum 源
为了一次性配置好下载源，我们一次性修改好centos7 软件源，docker 源，
k8s 源
先清除掉系统自带配置

下载centos7 的源和docker 源

wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
wget -P /etc/yum.repos.d/ http://mirrors.aliyun.com/repo/epel-7.repo
wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

结果如下：

配置k8s 源

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=0
EOF

刷新yum 缓存

安装docker

docker 使用版本18.09.9
yum install docker-ce-18.09.9 docker-ce-cli-18.09.9 containerd.io -y

k8s 运行要求docker 的–cgroup-driver=systemd

启动docker 并设置开机启动
systemctl enable docker && systemctl start docker

安装k8s 组件

yum install -y kubelet-1.16.4 kubeadm-1.16.4 kubectl-1.16.4


设置开机启动：systemctl enable kubelet && systemctl start kubelet

添加kubectl 上下文到环境中
echo “source <(kubectl completion bash)” >> ~/.bash_profile
source .bash_profile
在家目录中，配置生效

内核参数修改

k8s 网络一般使用flannel，该网络需要设置内核参数bridge-nf-call-iptables=1添加参数配置文件：

执行：sysctl -p /etc/sysctl.d/k8s.conf

至此，环境准备工作完毕

内核参数修改失败常见问题

有些系统执行sysctl -p /etc/sysctl.d/k8s.conf 会报异常，一般是因为修改这个参数需要系统有br_netfilter 模块

使用lsmod |grep br_netfilter 命令，查看系统里是否有br_netfilter 模块

新增br_netfilter 模块:

上述方式重启后无效。需要配置系统启动加载脚本使其永久生效：
先加开机启动动作
vi /etc/rc.sysinit

再做加载模块动作
vi /etc/sysconfig/modules/br_netfilter.modules

再增加执行权限

Master 节点配置

Master 节点初始化

kubeadm init --pod-network-cidr=10.244.0.0/16 --image-repository=registry.aliyuncs.com/google_containers --ignore-preflight-errors=all
这一步，如果出现下面错误，则是前面的2.1.6 节点内核没有配置

正常情况，如下：


出现这一步，恭喜你，已经成功一大半了！
接下来，我们按它的提示执行操作

添加flannel 的网络

按照master 的提示，我们接下来应该配置一个pod network。
但是，因为国内网络不通的原因，此操作无法完成。
你只能选择为你定制的下面这个文件来完成
上传文件到你的系统后，使用下面命令
kubectl apply -f peter-flannel.yml

至此，大功告成

查看集群

查看你k8s 集群

work 节点初始化

work 节点的配置，相对master 来说简单许多，只需要规划好节点的名称即可

设置机器名

设置一个机器名为work1

配置对应的ip

加入集群
在要加入的工作节点机器上，执行master 初始化时提示的join 语句，即加到master 的管辖内

回到master 节点再次查看集群

3. K8S 基础操作

kubectl 的命令用法

可以借助kubectl -h 命令学习用法，下面介绍常用的一些命令使用：

kubectl run，创建一个应用程序

kubectl run nginx-dep --image=nginx:1.7.9 --port=80 --replicas=2
可以先测试：–dry-run

正式创建：

查看服务信息：
kubectl get pods -o wide
#获取pod 的信息，-o wide 表示更详细的显示信息

看到系统里启动了两个pod 服务（运行nginx），分别运行在节点node2 和node3 上
测试nginx 服务，服务ok

探究pod 详情：

kubectl describe pod nginx-dep-5779c9d6c9-cwjth


进入容器查看：
格式：kubectl exec -it podName -c containerName -n namespace – shell comand
kubectl exec -it nginx-dep-5779c9d6c9-cwjth -c nginx-dep /bin/bash

暴露服务到外网

将pod 创建完成后，访问该pod 内的服务只能在集群内部通过pod 的的地址去访问该服务；当该pod 出现故障后，该pod 的控制器会重新创建一个包括该服务的pod,此时访问该服务须要获取该服务所在的新的pod 的地址ip 去访问。

#删除当前的pod:

如何保持pod 的故障恢复，对调用者无影响呢？可以创建一个service，当新的pod 的创建完成后，service 会通过pod 的label连接到该服务，只需通过service 即可访问该服务。

查看svc 的label 配置

上述方式，虽然能够通过service 访问到pod 服务。但在集群外部，是无法访问到的，如在本地windows 机器上，想要访问到nginx 服务，网络是不通的。我们可以修改service 的类型的NodePort。
kubectl edit svc nginx-svc

查看绑定端口

在外部可以通过node 节点的地址及该端口访问pod 内的服务。

服务的伸缩

Pod 创建完成后，当服务的访问量过大时，可以对pod 的进行扩展让pod 中的服务处理更多的请求；当访问量减小时，
可以缩减pod 数量，以节约资源。这些操作都可以在线完成，并不会影响现有的服务。

缩减服务雷同

服务的在线升级与回滚

在kubernetes 服务中部署完服务后，对服务的升级可以在线完成，升级出问题后，也可以在线完成回滚。

可以看到滚动更新的过程：
kubectl get pod -w ##w 参数是watch，持续执行，并观察改变

再次查看镜像版本

还可以再回滚回原来的版本：
kubectl rollout undo deployment nginx-dep

查看版本，又回到1.7.9 的版本