k8s中pod基础及https密钥、horber仓库
一、pod基础：
1.pod是k8s里面最小单位，pod也是最小化运行容器的资源对象；容器是基于pod在k8s集群中工作；在k8s集群当中，一个pod就代表着一个运行进程，k8s的大部分组件都是围绕pod进行的，对pod进行支持支持和扩展。例如deployment、service都是围绕pod进行部署。
2.k8s的pod有两种使用方式：
一个pod一个容器，这是最常见的方式，k8s管理pod而不管理容器；
一个pod里面可以有多个容器，但是再多的容器也和pod共用一个IP；
3.现在容器的技术要求：一个pod下的容器必须要运行在同一节点上，因为要共享网络和挂载卷，但是共享网络和挂载卷不是pod自身提供，而是由pause提供网络共享和挂载卷共享
4.创建pause：在创建pod时候是先把pause镜像运行起来也就是初始化镜像（系统自己处理），pause镜像运行起来后才能拉取nginx镜像；运行过程中pause不参与，只在删除的时候参与，删除镜像的过程中回收容器的资源和容器内的僵尸进程，完了通知kubelet回收pod，再通知APIserver保存到etcd。
二、pod分类：
1.pod作用：共享网络，共享挂载卷
2.初始化容器：这种初始化容器包含再pod内部的，属于pod的组成部分之一，而且扮演着pod的生命周期当中的启动环节；当我们拉起一个pod时，先构建pause，构建完之后如果包含初始化容器时必须要等初始化容器部署完毕之后才会部署应用容器。
启动顺序pause----->初始化容器---->真正意义的容器
3.定义初始化容器
三个容器，前两个为初始化容器 ，最后一个才是业务容器（真正意义上的容器）
查看创建过程、启动的先后顺序是什么：先启动初始化容器，再启动业务容器
怎么进入容器：kubectl exec -it pod名称 -c 容器名 bash
怎么查看容器日志
4.初始化容器运行完成之后使命完成之后即刻退出，节点上的容器还在，这个时候只能查询到业务容器和状态；初始化容器运行完毕之后必须要退出，否则后续的业务容器无法继续构建。
5.初始化容器启动失败后pod就进入到了ready状态
6.init容器作用：
1.创建pod的时候，可以为业务容器初始化运行条件以及提供环境变量和一些软件（自定义）
2.权限：初始化容器可以访问secrets权限不需要配置，业务容器必须要配置之后才能访问secret
3.可以在业务容器运行之前提供一些必要的条件，前提条件满足之后
4.容器内部进行挂载：
三、镜像拉取的三种策略：ifNotpresent、Always、Never
如果拉取镜像不加标签也就是镜像后面的数字，例如nginx:1.22，默认就是laster，laster指的是最新版本。如果没有指定标签也没有指定策略，默认是Always;如果镜像指定了标签默认则是ifNotpresent
1.ifNotpresent：镜像在本地已经存在，就不会到镜像仓库再拉取镜像了，默认模式。
2.Always：每次创建pod都会拉取镜像。
3.Never：从来不去仓库拉取镜像，只使用本地镜像。
四、安装horber仓库
另开一台主机安装docker先
安装组件：仓库及docker-compose
https：加密的http 端口443，tcp协议，建立连接和普通的tcp一样的都是三次握手和四次挥手，但在原来三次握手的基础上多出一次ssl或tls握手，多次一次的握手过程为了建立安全的加密通信通道。
SSL/TLS握手的过程：
生成密钥
opnessl：生成RSA的密钥
-des3：使用的时des加密算法/类型对私钥进行加密
-out：私钥的文件名
2048：RSA密钥的位数是2048
基于私钥签发请求文件：
备份私钥文件
清除私钥的密码
签名证书
x509:使用openssl证书常用的公钥证书的标准
-req：输入的文件是一个证书签名请求
csr：签名的请求文件，来对CRT文件进行签名证书
-days：证书的有效期
-in server.csr：指定证书签名的请求文件，
-signkey：用私钥文件对生成的证书进行自签名，私钥和csr里面的公钥是匹配的
-out server.csr：生成的自签名证书文件
配置文件：为了验证密钥对
登录harbor
将数据传给主节点和node节点
回到三个节点，同步操作
配置vim /etc/hosts，同步操作
将地址指向仓库
node节点上传镜像
主节点 下载
