K8S学习笔记

Dockerfile的基本指令有哪些？
FROM 指定基础镜像（必须为第一个指令，因为需要指定使用哪个基础镜像来构建镜像）；
MAINTAINER 设置镜像作者相关信息，如作者名字，日期，邮件，联系方式等；
COPY 复制文件到镜像；
ADD 复制文件到镜像（ADD与COPY的区别在于，ADD会自动解压tar、zip、tgz、xz等归档文件，而COPY不会，同时ADD指令还可以接一个url下载文件地址，一般建议使用COPY复制文件即可，文件在宿主机上是什么样子复制到镜像里面就是什么样子这样比较好）；
ENV 设置环境变量；
EXPOSE 暴露容器进程的端口，仅仅是提示别人容器使用的哪个端口，没有过多作用；
VOLUME 数据卷持久化，挂载一个目录；
WORKDIR 设置工作目录，如果目录不在，则会自动创建目录；
RUN 在容器中运行命令，RUN指令会创建新的镜像层，RUN指令经常被用于安装软件包；
CMD 指定容器启动时默认运行哪些命令，如果有多个CMD，则只有最后一个生效，另外，CMD指令可以被docker run之后的参数替换；
ENTRYOINT 指定容器启动时运行哪些命令，如果有多个ENTRYOINT，则只有最后一个生效，另外，如果Dockerfile中同时存在CMD和ENTRYOINT，那么CMD或docker run之后的参数将被当做参数传递给ENTRYOINT；

Harbor：镜像存储
Koolshare：翻墙

集群资源级别
名称空间级别：

集群级别

元数据型

apiVersion: v1
kind: Pod
namespace: default
spec:
container: my-app

init-container:

探针：
ExecAction：在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功
TCPSocketAction：对指定端口上的容器的IP地址就是TCP检查，如果端口打开，则诊断被认为是成功的
HTTPGetAction：对指定的端口和路径上的容器的IP地址执行HTTP Get请求。如果响应的状态码大玉等于200且小于400，则诊断被认为是成功的

livenessprobe存活探测，指示容器是否正在运行；readinessprobe就绪探测，指示容器是否准备好服务请求

容器生命周期钩子：
容器生命周期钩子（Container Lifecycle Hooks）监听容器生命周期的特定事件，并在事件发生时执行已注册的回调函数。
postStart： 容器创建后立即执行，注意由于是异步执行，它无法保证一定在 ENTRYPOINT 之前运行。如果失败，容器会被杀死，并根据 RestartPolicy 决定是否重启；
preStop：容器终止前执行，常用于资源清理。执行完成之后容器将成功终止，如果失败，容器同样也会被杀死。在其完成之前 会阻塞删除容器的操作；

钩子的回调函数支持三种方式定义动作：
exec：在容器内执行命令，如果命令的退出状态码是 0 表示执行成功，否则表示失败；
HTTPGet：向指定 URL 发起 GET 请求，如果返回的 HTTP 状态码在 [200, 400) 之间表示请求成功，否则表示失败；
TCPSocket：在容器尝试访问指定的socket；

Pod的运行状态：
Pending：挂起
Running：运行中
Succeed：成功
Failed：失败
Unknown：未知

Pod的分类：
自主式Pod：Pod退出了，此类型的Pod不会被创建

控制器管理的Pod：在控制器的生命周期里，始终要维持这个Pod的状态

控制器：
k8s中内建了很多controller，这些相当于一个状态机，用来控制Pod的具体状态和行为。

控制器类型：
rc和rs
Deployment
DaemonSet:
这个Pod运行在Kubernetes集群里的每一个节点（Node）上；
每个节点上只有一个这样的Pod实例；
当有新的节点加入Kubernetes集群后，该Pod会自动地在新节点上被创建出来；而当旧节点被删除后，它上面的Pod也相应地会被回收掉。

StateFulSet（为有状态服务建立）:
	拓扑状态（VIP即ClusterIP/HeadLess）：这种情况意味着，应用的多个实例之间不是完全对等的关系。这些应用实例，必须按照某些顺序启动
	存储状态（PV及PVC）：这种情况意味着，应用的多个实例分别绑定了不同的存储数据
Job/CronJob
Horizontal Pod Autoscaling

init Container：提前做准备的
sideCar：提供各种辅助功能

service代理模式分类：
ClusterIp
NodePort
headless
ExtraName
网络代理：
userspace
iptables
IPVS
Ingress-Nginx
Ingress-Haproxy

存储类型：
configMap

Secret
volume
	emptyDir
		暂存空间
		用作长时间计算崩溃恢复时的检查点
		
	hostPath
		
Persistent Volume
PVC

集群调度
节点亲和性
preferredDuringSchedullingIgnoredDuringExecution：软策略
requiredDuringSchedullingIgnoredDuringExecution：硬策略
亲和性
反亲和性
nodeAffinity：node亲和性 In，NotIn，Exists，DoesNotExist，Gt，Lt
podAffinity：Pod亲和性 In，NotIn，Exists，DoesNotExist
PodAnitAffinity：Pod反亲和性 In，NotIn，Exists，DoesNotExist

污点和容忍
Taint/Toleration

固定节点调度：通过标签lables调度

k8s集群安全
k8s使用认证（Authentication）、鉴权（Authorization）、准入控制（AdmissionControl）三步来保证API Server的安全。

认证：当用户访问API Server时触发认证机制
	HTTP Token认证：通过一个Token来识别合法用户
	
	HTTP Base认证：通过用户名+密码的方式认证
	
	最严格的HTTPS证书认证：基于CA根证书签名的客户端身份认证方式
	

总结：
	认证：
		1、Pod --> Service Account --> service-account-token --> API Server
		2、k8s组件：
			kubectl、kube-proxy --> 手动签发证书 --> kubeconfig --> API Server
			kubelet --> TLS Bootstrap --> 证书 kubeconfig --> API Server

授权鉴权Authorization：
认证过程只是确认通信的双方都确认了对方是可信的，可以互相通信。而鉴权是确定请求方有哪些资源的权限。
AlwaysDeny：表示拒绝所有请求
AlwaysAllow：允许接收所有请求
ABAC（Attribute-Based Access Control）：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制
Webbook：通过调用外部REST服务对用户进行授权
RBAC（Role-Based Access Control）：基于角色的访问控制，现行默认规则
顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding

准入控制
是API Server的插件集合，通过添加不同的插件，实现额外的准入控制规则。甚至于API Server的一些主要的功能都需要通过
Admission Controllers实现，比如ServiceAccount
如：
NamespaceLifecycle：防止在不存在的namespace上创建对象，防止删除系统预置namespace
LimitTangerine：确保请求的资源不会超过资源所在Namespace的LimitRange的限制
ServiceAccount：实现了自动化添加ServiceAccount
ResourceQuota：确保请求的资源不会超过资源的ResourceQuota限制。

Helm：
Helm的本质就是让k8s的应用管理（Deploy门头，Service等）可配置，能动态生成。通过动态生成k8s资源清单文件（deployment.yaml，service.yaml）。然后调用kubectl自动执行k8s资源部署。

Helm有两个重要的概念：chart和release

init Container：提前做准备的
sideCar：提供各种辅助功能
Infra（pause）：容器特性（共享一个volume、网络等资源）

一个容器，实际上是一个由Linux Namespace、Linux Cgroups和rootfs三种技术构建出来的进程的隔离环境。
一个正在运行的Docker容器，其实就是一个启用了多个Linux Namespace的应用进程，而这个进程能够使用的资源量，则受Cgroups配置的限制。
对Docker项目来说，它最核心的原理实际上就是为待创建的用户进程：
1、启用Linux Namespace配置；
2、设置指定的Cgroups参数；
3、切换进程的根目录（Change Root）。

Namespace做隔离，Cgroups做限制，rootfs做文件系统
namespace的几种隔离种类：
1、UTS --> 主机名及域名 --> 2.6.19
2、IPC --> 信号量、消息队列和共享内存 --> 2.6.19
3、PID --> 进程编号 --> 2.6.24
4、NetWork --> 网络设备、网络栈端口等 --> 2.6.29
5、Mount --> 挂载点（文件系统） --> 2.4.19
6、User --> 用户和用户组 --> 3.8

容器的“单进程模型”，并不是指容器里只能运行“一个”进程，而是指容器没有管理多个进程的能力。这是因为容器里PID=1的进程就是应用本身，其他的进程都是这个PID=1进程的子进程

声明式API：
kubectl apply
它跟kubectl replace命令有什么本质区别吗？
实际上，你可以简单地理解为，kubectl replace的执行过程，是使用新的YAML文件中的API对象，替换原有的API对象；而kubectl apply，则是执行了一个对原有API对象的PATCH操作。类似地，kubectl set image和kubectl edit也是对已有API对象的修改。
更进一步地，这意味着kube-apiserver在响应命令式请求（比如，kubectl replace）的时候，一次只能处理一个写请求，否则会有产生冲突的可能。而对于声明式请求（比如，kubectl apply），一次能处理多个写操作，并且具备Merge能力。
首先，所谓“声明式”，指的就是我只需要提交一个定义好的API对象来“声明”，我所期望的状态是什么样子。
其次，“声明式API”允许有多个API写端，以PATCH的方式对API对象进行修改，而无需关心本地原始YAML文件的内容。
最后，也是最重要的，有了上述两个能力，Kubernetes项目才可以基于对API对象的增、删、改、查，在完全无需外界干预的情况下，完成对“实际状态”和“期望状态”的调谐（Reconcile）过程。
所以说，声明式API，才是Kubernetes项目编排能力“赖以生存”的核心所在，希望你能够认真理解。

在Kubernetes项目中，一个API对象在Etcd里的完整资源路径，是由：Group（API组）、Version（API版本）和Resource（API资源类型）三个部分组成的。

网络通信：
1、同一个pod之间的容器通信（clusterip）；
2、同一个node上的pod之间的容器通信；
3、同一个集群中的node上的pod之间的容器通信（nodeport）；
4、集群外部到pod容器通信（1、headless；2、extraname；3、loadbalance；）；