dockerfile指令
1.FROM
1 | #指定所创建镜像的基础镜像,如果本地不存在,则默认去镜像仓库下载指定镜像 |
2.MAINTAINER
1 | #指定维护者信息 |
3.RUN
1 | #镜像制作过程中,在可写层执行指定命令 |
4.CMD
1 | #指定启动容器时默认执行的命令,一般用于执行服务启动脚本。每个 Dockerfile 只能有一条 CMD 指令,如果指定了多条,只有最后一条会生效,并且 docker run 接的命令会覆盖掉 CMD 指令的内容。支持三种格式: |
1.FROM
1 | #指定所创建镜像的基础镜像,如果本地不存在,则默认去镜像仓库下载指定镜像 |
2.MAINTAINER
1 | #指定维护者信息 |
3.RUN
1 | #镜像制作过程中,在可写层执行指定命令 |
4.CMD
1 | #指定启动容器时默认执行的命令,一般用于执行服务启动脚本。每个 Dockerfile 只能有一条 CMD 指令,如果指定了多条,只有最后一条会生效,并且 docker run 接的命令会覆盖掉 CMD 指令的内容。支持三种格式: |
1.查找镜像
1 | docker serch IMG_NAME[:TAG] |
2.下载镜像
1 | docker pull IMG_NAME[:TAG] |
3.查看镜像
1 | docker images |
4.镜像打tag
1 | docer tag SRC_IMG_NAME[:TAG] NEW_IMG_NAME[:TAG] |
1.创建容器
1 | docker create [OPTIONS] CONTAINER_NAME[:TAG] |
2.启动容器
1 | docker start CONTAINER_ID |
3.运行容器(相当于docker create + docker start)
1 | docker run [OPTIONS] NAME[:TAG] |
本文主要讲述如何使用prometheus,结合kube-state-metrics,cAdvisor,Grafana对k8s集群进行监控和报警,和监控大盘的整体展示。
kube-state-metrics安装有以下配置文件,可以把kube-state-metrics-deployment.yaml里面的镜像路径改成内网的镜像路径。
1 | #把配置文件都放在kube-state-metrics,执行这个命令即可部署 |
镜像准备(注意,提前在所有节点都下载好镜像,不然coredns kube-proxy 这些pod会自动安装安装不上 )
master节点粘贴下面脚本,下载镜像:
1 |
|
node节点粘贴下面脚本,下载镜像:
1 |
|
由于默认情况下容器挂载的是宿主机的硬件配置信息,导致有些应用根据这些信息来决定启动内存等的大小,导致应用内存溢出等问题。
LXCFS简介
社区中常见的做法是利用 lxcfs来提供容器中的资源可见性。lxcfs 是一个开源的FUSE(用户态文件系统)实现来支持LXC容器,它也可以支持Docker容器。
LXCFS通过用户态文件系统,在容器中提供下列 procfs 的文件。
1 | /proc/cpuinfo |
LXCFS的示意图如下:
比如,把宿主机的 /var/lib/lxcfs/proc/memoinfo 文件挂载到Docker容器的/proc/meminfo位置后。容器中进程读取相应文件内容时,LXCFS的FUSE实现会从容器对应的Cgroup中读取正确的内存限制。从而使得应用获得正确的资源约束设定。
安装lxcfs ,先安装需要使用的依赖包:
yum install http://mirror.centos.org/centos/7/os/x86_64/Packages/fuse-libs-2.9.2-10.el7.x86_64.rpm
用deamonset方式在每个节点启动一个lxcfs,lxcfs-daemonset.yaml配置如下:
由于nginx要部署到指定节点上,所以需要对node打个label,通过nodeSelector调度到节点上,同时要确保部署节点主机的80、443、18080、10254端口没有被占用。
kubectl label node ss-1-centos221 nginx-ingress=nginx
kubectl label node ss-1-centos221-2 nginx-ingress=nginx
1 |
|
k8s有自己的一套网络管理机制,集群内的容器和容器之间是可以相互通信的。
但是在容器化升级改造的过程中,不可能一步到位的将所有的服务全部迁移到k8s的容器当中来,毕竟新的技术在没有经过实践趟坑时,肯定不能轻易的全面铺开升级。
那么就涉及到集群外的服务访问集群内的服务,集群内容器中的ip都是k8s管理的IP,dubbo服务注册的也是获取的容器内分配的IP。
比如宿主机ip是10.201.7.xx,容器内的ip就是172.66.4.x。群外的和宿主主机同网段的服务通过拿到dubbo的注册的172.66.4.x也根本没法访问容器内的dubbo服务。
k8s是通过Service来暴露集群内的服务,假如dubbo服务注册的是Service暴露的端口和宿主的IP那么集群外的服务就可以直接访问集群内容器中的服务了。
该方案主要有两个难点:
1.如何获取Service暴露的端口和宿主机的IP注入到POD环境变量;
2.Dubbo服务如何从环境变量获取IP和端口注册到ZK;
关于难点1:
通过downward-api的方式向Pod内注入NodeIP的env;
通过给Pod注入env的方式将NodePort注入到Pod内;(要求先创建Service)
关于难点2:
Dubbo在启动阶段提供两对系统属性,用于设置外部通信的IP和端口地址。
DUBBO_IP_TO_REGISTRY — 注册到注册中心的IP地址
DUBBO_PORT_TO_REGISTRY — 注册到注册中心的端口
DUBBO_IP_TO_BIND — 监听IP地址
DUBBO_PORT_TO_BIND — 监听端口
是否还记得第一个接触Docker的时候,你从Docker Hub下拉的那个镜像呢?在那个处女镜像的基础上,你运行了容器生涯的处女容器。镜像的基石作用已经很明显,在Docker的世界里,可以说是:No Image,No Container。
再进一步思考Docker镜像,大家可能很快就会联想到以下几类镜像:
1.系统级镜像:如Ubuntu镜像,CentOS镜像以及Debian容器等;
2.工具栈镜像:如Golang镜像,Flask镜像,Tomcat镜像等;
3.服务级镜像:如MySQL镜像,MongoDB镜像,RabbitMQ镜像等;
4.应用级镜像:如WordPress镜像,DockerRegistry镜像等。
镜像林林总总,想要运行Docker容器,必须要有Docker镜像;想要有Docker镜像,必须要先下载Docker镜像;既然涉及到下载Docker镜像,自然会存在Docker镜像存储。谈到Docker镜像存储,那我们首先来聊聊Docker镜像大小方面的知识。
以下将从三个角度来分析Docker镜像的大小问题:Dockerfile与镜像、联合文件系统以及镜像共享关系。
Dockerfile与镜像
Dockerfile由多条指令构成,随着深入研究Dockerfile与镜像的关系,很快大家就会发现,Dockerfile中的每一条指令都会对应于Docker镜像中的一层。
继续以如下Dockerfile为例:
1 | FROM ubuntu:14.04 |
1.1 时区修改
官网下载centos镜像默认时区是国外的时区,需要把它修改成上海时区。运维提供提一个基础的镜像给业务部门下载使用。
1.2 规范docker运行程序的用户
基于安全和规范的考虑,docker统一使用一个uid为1001的,用户名为pub的普通账号运行程序,需要在镜像和容器的宿主机上面同时新建。这个也是运维在初始化基础镜像和容器宿主机上面统一创建。
1.3 规范每个容器的cpu和内存(每个容器分配1核2G内存,视情况而定)
2.1 默认的镜像拉取策略是“IfNotPresent”,在镜像已经存在的情况下,kubelet将不在去拉取镜像。 如果总是想要拉取镜像,必须设置拉取策略为“Always”或者设置镜像标签为“:latest”。
如果没有指定镜像的标签,它会被假定为“:latest”,同时拉取策略为“Always”。
首先,了解下什么是RABC:
基于角色的访问控制(Role-Based Access Control, 即”RBAC”)使用”rbac.authorization.k8s.io” API Group实现授权决策,允许管理员通过Kubernetes API动态配置策略。
在RBAC API中,一个角色包含了一套表示一组权限的规则。 权限以纯粹的累加形式累积(没有”否定”的规则)。 角色可以由命名空间(namespace)内的Role对象定义,而整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现
比如授予default命名空间的default ServiceAccount账号能够”get”, “watch”, “list”, “patch” default 命名空间里面的pod资源
3.1 定义role,一个Role对象只能用于授予对某一单一命名空间中资源的访问权限。 以下示例描述了”default”命名空间中的一个Role对象的定义,用于授予对pod的读访问权限:
1 | kind: Role |