kubernetes基础概念理解
一、概念理解
容器：一种轻量级、可移植、自包含的软件打包技术
Pod: k8s最小的调度单位，封装了一个或者多个容器的资源对象，共享命名空间
资源标签：一个键值型（key/value）数据，辨别pod的熟悉
标签选择器： Lable Selector，根据标签过滤符合调剂的资源对象的机制
Pod控制器：用户不会直接部署管理pod，借助另一个抽象的工具---控制器(control) 进行管理，达到副本数量精确
1、ReplicationController //几乎废弃
2、ReplicaSet //新一代控制器
3、Deployment //是目前最常用的管理无状态的pod，构建于RS之上
4、StatefulSet //有状态应用，如database，为每个Pod创建独特标识，确保Pod间顺序性
5、DaemonSet //用于确保每个节点都运行某Pod的一个副本，新增节点也会被添加此类Pod,用于运行集群存储守护进程，如ceph和glusterd,日志收集进程fluentd、logstash以及监控进程，prometheus的Node Exporter等
6、Job //运行完成后可终止的应用，如批处理作业任务
Deployment 支持基于集合（ set-based ）的标签选择器，以及它的滚动更新（ Rolling-Update ）机制,区别于RS的地方
7、服务资源 （ Serv ice )
Service 是建立在一组Pod 对象之上的资源抽象，它通过标签选择器选定一组Pod 对象，并为这组Pod 对象定义一个统一的固定访问入口（通常是一个IP 地址），若Kubemetes 集群存在DNS 附件，它就会在Service 创建时为其自动配置一个DNS 名称以便客户端进行服务发现。到达Service IP 的请求将被负载均衡至其后的端点一一各个Pod 对象之上，因此Service从本质上来讲是一个四层代理服务。另外， Service 还可以将集群外部流量引入到集群中来。
层级关系理解： 物理层 ------> 单个容器（container） --------> Pod --------> service
Service IP 是一种虚拟IP ，也称为Cluster IP ，它专用于集群内通信，通常使用专用的地址段，如“ 10.96.0.0 /12 ”网络 PodIP常用网段: 10.244.0.0/16
8、Ingress：Pod和service都只能在集群内部通信，Ingress可以实现HTTPS（七层）负载均衡，实现和集群外部通信，本身是一组路由规则的集合其控制器主要使用Nginx
9、k8s集群的网络
a、各主机自身的网络，地址配置于主机网络接口，配置于k8s集群构建之前，不能由k8s管理
b、k8s集群专用于pod资源对象的虚拟网络，配置在Pod的容器接口上，为Pod设定IP和网络，借助于CNI插件实现，可部署k8s集群之外或者托管在集群上，需要在构建集群有管理员定义
c、专用于service资源对象的虚拟网络，不配置在任何主机或者容器的网络接口，通过node的kube-proxy配置为iptables或者ipvs规则，网络在集群创建时指定
二、k8s服务、网络、存储概念
1、Service类型：
第一种是仅用于集群内部通信的ClusterIP类型；
第二种是接入集群外部请求的NodePort 类型它工作于每个节点的主机IP 之上；
第三种是LoadBalancer 类型，它可以把外部请求负载均衡至多个Node 的主机IP 的NodePort 之上
此三种类型中，每一种都以其前一种为基础才能实现，而且第三种类型中的LoadBalancer 需要协同集群外部的组件才能实现，并且此外部组件并不接受Kubemetes的管理。
第四种：ExternalName,通过将Service映射由ExternalName字段的内容指定的主机名来暴露服务
2、Kubernetes 的资源对象依据资源的主要功能作为分类标准， Kubemetes 的API 对象大体可分为
工作负载( Workload ） 有状态、无状态
发现和负载均衡（ Discovery & LB ） Ingress
配置和存储（ Config & Storage ）、
集群( Cluster ）资源 RoleBinding、 ClusterRoleBinding
元数据（ Metadat a ）
具有kind 、apiVersion 、meta data 、spec 和status 五个一级宇段
资源类型（ resource type ）是指在URL 中使用的名称，如Pod 、Namespace 和Service等，其URL 格式为“ GROUPNERSION度ESOURCE ”，如apps/v1/deployment 。
kind 代表着资源对象所属的类 Namespace/Deployment
metadata 字段为资源提供元数据信息，如名称、隶属的名称空间和标签等；
spec 则用于定义用户期望的状态，不同的资源类型，其状态的意义也各有不同
status 则记录着活动对象的当前状态信息，它由Kubemetes 系统自行维护，对用户来说为只读字段
4、kubectl 的命令由此可以分为三类：
陈述式命令（ imperative command ） run , expose 、delete 和get 等命令
陈述式对象配置（ imperative object configuration ） create 、delete 、get 和replace
声明式对象配置（ declarative object config uration ） apply
NodePort 部署于每一台节点
LoadBalancer 外部复制均衡器
HostPort和NodePort的区别：NodetPort是通过所有节点暴露容器服务，而HostPort由Pod对象所在的节点IP地址来暴露
5、常用命令
[root@master ~]# kubectl version --short Client Version: v1.15.0 Server Version: v1.15.0
kubectl -it exec <Pod-name> /bin/bash //进入容器，如果一个pod里面有多个容器加 -c< container name> 指定容器
[root@master ~]# kubectl run client --image=busybox --restart=Never -it -- /bin/bash //运行一个测试容器
报错：OCI runtime create failed: container_linux.go:345: starting container process caused "exec: \"/bin/bash\": stat /bin/bash: no such file or directory": unknown
可能是没有bash这个命令
[root@master ~]# kubectl run client --image=busybox --restart=Never -it -- /bin/sh //执行这个没有问题
6、Pod的生命周期
Pending: API Server创建了Pod资源对象并已经存入etcd中，但它尚未被调度完成，或者处于下载镜像过程中
Running: Pod已经被调度至某节点，并且所有容器被kubelet创建完成
Successed: Pod中的所有容器都已经成功终止且不会被重启
Failed: 所有容器都已经终止，但至少有一个终止失败
Unknown：API Server无法正常获取到Pod对象状态的信息，通常是由于无法和kubelet通信导致
7、Pod健康检查机制
存活性探测：判断容器是否处于Running状态，一旦此类检测未通过，kubelet将杀死容器并根据策略判断是否重启，主要用于四层（TCP）服务探测
就绪性探测：判断容器是否准备就绪可对外提供服务，主要用于七层（http）服务探测
8、kube-proxy请求代理的三种方式userspace代理模式、iptables代理模式、ipvs代理模式
三、数据存储与持久化
存储卷和Pod绑定，PV（PersistentVolume） PVC（persistentVolumeClaim）
