docker 和 k8s 使用说明

1. build好的程序包需要通过k8s发布时，需要构建docker image，将程序包构建进原始的镜像里去，再push到docker的私服。k8s 部署程序时调用docker从docker 私服上拉取。docker 原始镜像我们通常用Alpine，该镜像很小，只有几M。Alpine使用APK命令来管理软件包，比如：

apk search #查找所以可用软件包

apk info #列出所有已安装的软件包

apk add 安装PACKAGES并自动解决依赖关系。

apk add asterisk=1.6.0.21-r0 安装指定版本软件包

2. docker 私服用harbor，功能比原生docker registry强大，后端镜像存储可以考虑用MinIO或者raid硬盘，或者主从harbor(harbor 支持主从)。harbor部署在物理机上的docker环境，用docker-compose 启动harbor 两台同样部署 做仓库管理 配置要同步到的harbor中。目前我们测试环境的镜像仓库用的是gitlab集成的docker registry。GitLab Container Registry，修改配置 /etc/gitlab/gitlab.rb 文件，将 registry_external_url 的值修改为仓库地址，registry_external_url 这个地址是我们使用 docker 命令进行 pull 或者 push 镜像的仓库地址,比如:

registry_external_url 'https://gitlab.example.com:5555'

。重启 gitlab 后，可以在 每个项目的gitlab 左侧面板看到 Container Registry 的菜单。

quick Start 里面有推送镜像仓库的命令，下面列表中还有镜像的具体地址

3.docker-compose是一个用于定义和运行多容器 Docker 的应用程序工具，使用docker-compose.yml来定义你的应用，并且使用up/down命令来运行，这样可以让你对多容器的应用进行编排。

4. docker在/etc/docker/daemon.json（没有就创建）中可以指定默认的仓库的位置（通常指定为docker私服仓库的地址）.

添加如下信息：
{ "insecure-registries":["192.168.1.10"] }

重启docker

systemctl restart docker

5.在一个镜像上运行一个容器的时候，容器会创建一个临时的存储层, 来临时的保存容器中所产生的数据，当容器被删除时, 存储层同时被删除,为了将容器中产生的数据及时保留下来，可以将物理机中的一个目录映射到容器中去，容器会在这个映射后的目录中保存数据，同时会永久的保存在物理机上，而不会随着容器的消失而消失.数据卷主要是在宿主机与容器之间建立连接，数据卷容器则是在容器与容器之间建立连接。数据卷容器：指挂载了数据卷的容器，其它容器通过挂载这个(父容器)实现数据共享。

直接添加数据卷 ,

docker run -it -v /myDataVolume:/dataVolumeContainer[:ro] centos：添加数据卷建立连接

• -v：代表数据卷
• /myDataVolume：宿主机绝对路径目录
• :/dataVolumeContainer：容器内目录
• centos：镜像名
• :ro：设置权限为只读

通过docker file 添加数据卷

在宿主机根目录下新建mydocker文件夹后，添加Dockerfile文件

# dockerfile文件

# 使用VOLUME指令来给镜像添加一个或多个数据卷

FROM centos

VOLUME ["/dataVolumeContainer1","/dataVolumeContainer2"]

CMD echo "finished,--------success1"

CMD /bin/bash

docker buile -f /mydocker/Dockerfile -t gql/centos .：build后生成新的镜像

定义 Dockerfile 时，如果太多的使用 RUN 指令，经常会导致镜像有特别多的层，镜像很臃肿，而且甚至会碰到超出最大层数（127层）限制的问题，遵循 Dockerfile 最佳实践，我们应该把多个命令串联合并为一个 RUN（通过运算符&&和/ 来实现），每一个 RUN 要精心设计，确保安装构建最后进行清理，这样才可以降低镜像体积，以及最大化的利用构建缓存。

为了应对镜像中存在太多镜像层，Docker 1.13 版本以后，提供了一个压扁镜像功能，即将 Dockerfile 中所有的操作压缩为一层。 需要在启动Docker时添加-experimental 选项，我们不推荐使用这个办法，请在撰写 Dockerfile 时遵循最佳实践编写，不要试图用这种办法去压缩镜像。

Docker 17.05.0-ce 版本以后支持多阶段构建。使用多阶段构建，你可以在 Dockerfile 中使用多个 FROM 语句，每条 FROM 指令可以使用不同的基础镜像，这样您可以选择性地将服务组件从一个阶段 COPY 到另一个阶段，在最终镜像中只保留需要的内容。

6.k8s  部署微服务，kubectl apply -f ****.yaml 或者kubectl apply -f ****.yaml 来启动一个微服务，kubectl apply命令将配置应用于资源。 如果资源不在那里，那么它将被创建。kubectl create命令可创建新资源。 因此，如果再次运行该命令，则会抛出错误，因为资源名称在名称空间中应该是唯一的。可以通过文件或者命令行输入：

# 将pod.json中的配置应用到pod

$ kubectl apply -f ./pod.json

# 将控制台输入的JSON配置应用到Pod

$ cat pod.json | kubectl apply -f -

#直接在shell脚本中读取配置信息

cat <<EOF | kubectl apply -n $KUBE_NAMESPACE --record --force -f -

apiVersion: apps/v1
kind: Deployment
metadata:
  name: $name

cat <<EOF 用于多行导入文件。上述命令相当于把yaml配置文件读入给kubectl命令

在cat <<EOF >abcd.txt命令 与下一个输入的EOF行之间的所有文本行都会被当做是stdin数据。其实可以用其他字符来代替EOF，它也只是个标识符而已！

kubectl rollout undo 用来回滚

7.****.yaml 指定了k8s 部署一个应用的描述信息。具体资料网上比较多。从网上找的一个简单例子如下：

#test-pod   apiVersion: v1 #指定api版本，此值必须在kubectl apiversion中     kind: Pod #指定创建资源的角色/类型     metadata: #资源的元数据/属性       name: test-pod #资源的名字，在同一个namespace中必须唯一       labels: #设定资源的标签       k8s-app: apache         version: v1         kubernetes.io/cluster-service: "true"      annotations:            #自定义注解列表         - name: String        #自定义注解名字     spec: #specification of the resource content 指定该资源的内容       restartPolicy: Always #表明该容器一直运行，默认k8s的策略，在此容器退出后，会立即创建一个相同的容器       nodeSelector:     #节点选择，先给主机打标签kubectl label nodes kube-node1 zone=node1         zone: node1       containers:       - name: test-pod #容器的名字         image: 10.192.21.18:5000/test/chat:latest #容器使用的镜像地址         imagePullPolicy: Never #三个选择Always、Never、IfNotPresent，每次启动时检查和更新（从registery）images的策略，                              # Always，每次都检查                              # Never，每次都不检查（不管本地是否有）                              # IfNotPresent，如果本地有就不检查，如果没有就拉取       command: ['sh'] #启动容器的运行命令，将覆盖容器中的Entrypoint,对应Dockefile中的ENTRYPOINT         args: ["$(str)"] #启动容器的命令参数，对应Dockerfile中CMD参数         env: #指定容器中的环境变量         - name: str #变量的名字           value: "/etc/run.sh" #变量的值         resources: #资源管理         requests: #容器运行时，最低资源需求，也就是说最少需要多少资源容器才能正常运行             cpu: 0.1 #CPU资源（核数），两种方式，浮点数或者是整数+m，0.1=100m，最少值为0.001核（1m）           memory: 32Mi #内存使用量           limits: #资源限制             cpu: 0.5            memory: 1000Mi        ports:         - containerPort: 80 #容器开发对外的端口         name: httpd  #名称         protocol: TCP         livenessProbe: #pod内容器健康检查的设置         httpGet: #通过httpget检查健康，返回200-399之间，则认为容器正常             path: / #URI地址             port: 80            #host: 127.0.0.1 #主机地址             scheme: HTTP           initialDelaySeconds: 180 #表明第一次检测在容器启动后多长时间后开始           timeoutSeconds: 5 #检测的超时时间           periodSeconds: 15  #检查间隔时间           #也可以用这种方法           #exec: 执行命令的方法进行监测，如果其退出码不为0，则认为容器正常           #  command:           #    - cat           #    - /tmp/health           #也可以用这种方法           #tcpSocket: //通过tcpSocket检查健康            #  port: number          lifecycle: #生命周期管理           postStart: #容器运行之前运行的任务             exec:               command:                 - 'sh'                - 'yum upgrade -y'          preStop:#容器关闭之前运行的任务             exec:               command: ['service httpd stop']         volumeMounts:  #挂载持久存储卷       - name: volume #挂载设备的名字，与volumes[*].name 需要对应             mountPath: /data #挂载到容器的某个路径下           readOnly: True      volumes: #定义一组挂载设备       - name: volume #定义一个挂载设备的名字         #meptyDir: {}         hostPath:           path: /opt #挂载设备类型为hostPath，路径为宿主机下的/opt,这里设备类型支持很多种       #nfs      使用k8s ,需要对k8s的一些核心概念有所了解： 1.namespace Namespace为名称提供了一个范围。资源的Names在Namespace中具有唯一性。比如同一个namespace中，pod名唯一。 2.Node Node是Kubernetes中的工作节点。一个Node可以是VM或物理机。每个Node（节点）具有运行pod的一些必要服务，并由Master组件进行管理，Node节点上的服务包括Docker、kubelet和kube-proxy。 3.pod Pod是Kubernetes创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程。 一个Pod封装一个应用容器（也可以有多个容器），存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。Pod代表部署的一个单位：Kubernetes中单个应用的实例，它可能由单个容器或多个容器共享组成的资源。 4.ReplicaSet ReplicaSet能确保运行指定数量的pod。 5.Deployment Deployment为Pod和Replica Set（升级版的 Replication Controller）提供声明式更新。 你只需要在 Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。 6.Servie 一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。 一个微服务内网里通过service这个概念做负载均衡， 7.ingress service和pod仅可在集群内部网络中通过IP地址访问，Ingress是授权入站连接到达集群服务的规则集合。可以给Ingress配置提供外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。用户通过POST Ingress资源到API server的方式来请求ingress。