在Kubernetes集群中，Pod是有生命周期的，为了能够给对应的客户端提供一个固定访问端点，因此在客户端与服务端（Pod之间）添加了一个固定中间层，这个中间层被称之为Service。Service的工作严重依赖于在Kubernetes集群之上，部署的附件Kubernetes DNS服务。较新版本使用的coreDNS，1.11之前使用的KubeDNS。 service的名称解析是强依赖于DNS附件的。因此在部署完Kubernetes后，需要部署CoreDNS或KubeDNS。 Kubernetes要想向客户端提供网络功能，依赖于第三方方案，在较新版本中，可通过CNI容器网络插件标准接口，来接入任何遵循插件标准的第三方方案。 Service从一定程度上来说，在每个节点之上都工作有一个组件Kube-proxy，Kube-proxy将始终监视apiserver当中，有关service资源的变动状态。此过程是通过Kubernetes中固有的请求方法watch来实现的。一旦有service资源的内容发生变动，kube-proxy都将其转换为当前节点之上的能够实现service资源调度至特定Pod之上的规则。 service实现方式 在Kubernetes中service的实现方式有三种模型。 userspace 用户空间，可以理解为，用户的请求。 1.1之前包括1.1使用此模型。 用户的请求到达当前节点的内核空间的iptables规则（service规则），由service转发至本地监听的某个套接字上的用户空间的kube-proxy，kube-proxy在处理完再转发给service，最终代理至service相关联的各个Pod，实现调度。 iptables 1.10- 客户端IP请求时，直接请求serviceIP，IP为本地内核空间中的service规则所截取，并直接调度至相关Pod。service工作在内核空间，由iptables直接调度。 ipvs 1.11默认使用，如IPVS没有激活，默认降级为iptables 客户端请求到达内核空间后，直接由ipvs规则直接调度至Pod网络地址范围内的相关Pod资源。 使用清单创建service资源 SVC中的kubernetes service是集群中各Pod需要与Kubernetes集群apiserver联系时需要通过此svc地址联系。这个地址是集群内的apiserver服务地址。 service类型 ClusterIP 默认值，表示分配集群IP地址，仅用于集群内通信。自动分配地址，如需固定，需要指定相应地址，在创建后无法修改。当使用ClusterIP时，只有两个端口有用，port与targetPort NodePort 接入集群外部流量，默认分配的端口是30000~32767 LoadBalancer 表示将Kubernetes部署在虚拟机上，虚拟机是工作在云环境中，云环境支持lbaas（负载均衡及服务的一键调用）。 ExternaName 表示将集群外部服务引用到集群内部中来，在集群内部直接使用。 yaml 1 2 3 4 5 6 7 8 9 10 11 12 spec: ports: # 将哪个端口与后端容器端口建立关联关系。 - port # service对外提供服务的端口 name 指明port的名称 targetPort # 容器的端口 nodePort # 只有类型为NodePort时，才有必要用节点端口，否则此选项是无用的。 protocol 协议，默认TCP seletcor 关联到哪些Pod资源上 app: redis run: redis clusterIP: # clusterIP可以动态分贝可以不配置 type: ClusterIP yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 apiVersion: v1 kind: Service metadata: name: redis namespace: default spec: selector: run: redis clusterIP: 10....

Overview kube-scheduler 是kubernetes控制平面的核心组件，其默认行为是将 pod 分配给节点，同时平衡Pod与Node间的资源利用率。通俗来讲就是 kube-scheduler 在运行在控制平面，并将工作负载分配给 Kubernetes 集群。 本文将深入 Kubernetes 调度的使用，包含：”一般调度”，”亲和度“，“污点与容忍的调度驱逐”。最后会分析下 Scheduler Performance Tuning，即微调scheduler的参数来适应集群。 简单的调度 NodeName [1] 最简单的调度可以指定一个 NodeName 字段，使Pod可以运行在对应的节点上。如下列资源清单所示 yaml 1 2 3 4 5 6 7 8 9 apiVersion: v1 kind: Pod metadata: name: netpod spec: containers: - name: netbox image: cylonchau/netbox nodeName: node01 通过上面的资源清单Pod最终会在 node01上运行。这种情况下也会存在很多的弊端，如资源节点不足，未知的nodename都会影响到Pod的正常工作，通常情况下，这种方式是不推荐的。 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 $ kubectl describe pods netpod Name: netpod Namespace: default ....

Kubernetes资源清单 类别 名称 工作负载型资源（workload） 运行应用程序，对外提供服务：Pod、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、Cronjob （ReplicationController在v1.11版本被废弃） 服务发现及负载均衡 service、Ingress 配置与存储 Volume、CSI（容器存储接口 特殊类型存储卷 ConfigMap（当配置中心来使用的资源类型）、Secret（保存敏感数据）、DownwardAPI（把外部环境中的信息输出给容器） 集群级资源 Namespace、Node、Role、ClusterRole、RoleBinding（角色绑定）、ClusterRoleBinding（集群角色绑定） 元数据型资源 HPA、PodTemplate（Pod模板，用于让控制器创建Pod时使用的模板）、LimitRange（用来定义硬件资源限制的） Kubernetes配置清单使用说明 在Kubernetes中创建资源时，除了命令式创建方式，还可以使用yaml格式的文件来创建符合我们预期期望的pod，这样的yaml文件我们一般称为资源清单。资源清单由很多属性或字段所组成。 以yawl格式输出pod的详细信息。 资源清单格式 yaml 1 kubectl get pod clients -o yaml Pod资源清单常用字段讲解 在创建资源时，apiserver仅接收JSON格式的资源定义。在使用kubectl run命令时，自动将给定内容转换成JSON格式。yaml格式提供配置清单，apiserver可自动将其转为JSON格式，（yaml可无损转为json），而后再提交。使用资源配置请清单可带来复用效果。 Pod资源配置清单由五个一级字段组成，通过kubectl create -f yamlfile就可以创建一个Pod apiVersion: 说明对应的对象属于Kubernetes的哪一个API群组名称和版本。给定apiVersion时由两部分组成group/version，group如果省略表示core（核心组）之意。使用kubectl api-versions获得当前系统所支持的apiserver版本。alpha 内测版、beta 公测版、stable 稳定版 kind: 资源类别，用来指明哪种资源用来初始化成资源对象时使用。 metadata: 元数据，内部嵌套很多2级、3级字段。主要提供以下几个字段。 name，在同一类别当中name必须是唯一的。 namespace 对应的对象属于哪个名称空间，name受限于namespace，不同的namespace中name可以重名。 lables key-value数据，对于key名称及value，最多为63个字符，value，可为空。填写时只能使用字母、数字、_、-、.，只能以字母或数字开头及结尾。 annotations 资源注解。与label不同的地方在于，它不能用于挑选资源对象，仅用于为对象提供“元数据”。对键值长度没有要求。在构建大型镜像时通常会用其标记对应的资源对象的元数据 spec: specification，定义接下来创建的资源对象应该满足的规范（期望的状态 disired state）。spec是用户定义的。不同的资源类型，其所需要嵌套的字段各不相同。如果某一字段属性标记为required表示为必选字段，剩余的都为可选字段，系统会赋予其默认值。如果某一字段标记为Cannot be updated，则表示为对象一旦创建后不能改变字段值。可使用kubectl explain pods.spec查看详情。 containers [required]object list name [string] 定义容器名称 image [string] 启动Pod内嵌容器时所使用的镜像。可是顶级、私有、第三方仓库镜像。 imagePulLPolicy [string] 镜像获取的策略，可选参数Always（总是从仓库下载，无论本地有无此镜像）、Never（从不下载，无论本地有无此镜像）、IfNotPresent（本地存在则使用，不存在则从仓库拉去镜像）。如果tag设置为latest，默认值则为Always，非latest标签，默认值都为IfNotPresent。...

Deployment当中借助于ReplicaSet进行更新的策略反映在Deployment的对象定义所需字段可使用kubectl explain deploy，Deployment属于extension群组。在1.10版本中它被移至到apps群组。他与ReplicaSet相比增加了几个字段。 stratgy 重要字段，定义更新策略，它支持两种策略 重建式更新 Recreate与滚动更新RollingUpdate，如果type为RollingUpdate，那么RollingUpdate的策略还可以使用RollingUpdate来定义，如果type为Recreate，那么RollingUpdate字段无效。 默认值为RollingUpdate stratgy.RollingUpdate控制RollingUpdate更新力度 maxSurge 对应的更新过程当中，最多能超出目标副本数几个。有两种取值方式，为直接指定数量和百分比。在使用百分比时，在计算数据时如果不足1会补位1个。 maxUnavailable 最多有几个副本不可用。 revisionHistoryLimit 滚动更新后，在历史当中最多保留几个历史版本，默认10。 在使用Deployment创建Pod时，Deployment会自动创建ReplicaSet，而且Deployment名称是使用Pod模板的hash值，此值是固定的。 Deployment在实现更新应用时，可以通过编辑配置文件来实现，使用kubectl apply -f更改每次变化。每次的变化通过吧变化同步至apiserver中，apiserver发现其状态与etcd不同，从而改变etcd值来实现修改其期望状态，来实现现有状态去逼近期望状态。 kubectl explain deploy yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 apiVersion: apps/v1 kind: Deployment metadata: name: app-deploy namespace: default spec: replicas: 2 selector: matchLabels: app: deploy release: canary template: metadata: labels: app: deploy release: canary spec: containers: - name: my-deploy image: node01:5000/busybox:v1 ports: - name: http containerPort: 80 command: ["/bin/sh","-c","/bin/httpd -f -h /tmp"] 使用kubectl apply 声明式更新、创建资源对象。...

IngressController比较独特，它与DaemonSet、Deployment、Repliacaset不同，DaemonSet、Deployment等控制器是作为ControllerManager的子组件存在的。Ingress Controller是独立运行的一组Pod资源，通常是拥有七层代理、调度能力的应用程序。 通常在使用IngressController时有三种选择Nginx、Traefik、Envoy。 IngressController nginx运行在Pod中，其配置文件是在Pod中。后端代理的Pod随时会发生变动，IngressController需要watch API当中的后端Pod资源的改变。IngressController自身无法识别目前符合自己关联的（条件的）被代理的Pod资源有哪些，IngressController需借助service来实现。 因此要想定义一个对应的调度功能，还需要创建service，此service通过label selector关联至每一个upstream服务器组，通过此service资源关联至后端的Pod。此service不会被当做被代理时的中间节点，它仅仅是为Pod做分类的。此service关联的Pod，就将其写入upstream中。 在Kubernetes中有一种特殊资源叫做Ingress，当Pod发生改变时，其servcie对应的资源也会发生改变， 依赖于IngressResource将变化结果反应至配置文件中。 Ingress定义期望IngressController如何创建前段代理资源（虚拟主机、Url路由映射），同时定义后端池（upstream）。upstream中的列表数量，是通过service获得。 Ingress可以通过编辑注入到IngressController中，并保存为配置文件，且Ingress发现service选定的后端Pod资源发生改变，此改变会及时反映至Ingress中，Ingress将其注入到前端调度器Pod中，并触发Pod中的container主进程（nginx）重载配置文件。 要想使用Ingress功能，需要有service对某些后端资源进行分类，而后Ingress通过分类识别出Pod的数量和IP地址信息，并将反映结果生成配置信息注入到upstream中。 IngressController根据自身需求方式来定义前端，而后根据servcie收集到的后端Pod IP定义成upstream server，将这些信息反映在Ingress server当中，由Ingress动态注入到IngressController当中。 Ingress也是标准的Kubernetes资源，定义Ingress时同样类似于Pod方式来定义。使用kubectl explain Ingress查看帮助。 spec rules 规则，对象列表 host 主机调度 虚拟主机而非url映射 http paths 路径调度 backend path backend 定义被调度的后端主机，靠service定义，找到后端相关联的Pod资源。 serviceName 后端servcie名称，即用来关联Pod资源的service。 servicePort IngressController部署 namespace.yaml 创建名称空间 configmap.yaml 为nginx从外部注入配置的 rbac.yaml 定义集群角色、授权。必要时让IngressController拥有访问他本身到达不了的名称空间的权限 ingress.yaml yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 apiVersion: extensions/v1beta1 kind: Ingress metadata: name: ingress-myapp namespace: defualt # 与deployment和要发布的service处在同一名称空间内 annotations: kubernetes....

基于web的UI前端，认证是由Kubernetes完成的。登陆dashboard的密码是k8s的账号和密码，和dashboard自身没有关系。dashboard自身不做认证。 text 1 kubectl patch svc kubernetes-dashboard -p'{"spec":{"type":"NodePort"}}'-n kube-system 如使用域名访问，CN一定要与域名保持一致。 text 1 2 3 4 (umask 077; openssl genrsa -out dashboard.key 2048) openssl req -new -key dashboard.key -out dashboard.csr -subj "/O=test/CN=dashboard" openssl req -in dashboard.csr -noout -text openssl x509 -req -in dashboard.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out dashboard.crt -days 3650 Certificate Attributes 要想穿透集群边界，从集群外访问集群内部某一服务或Pod上的容器的应用，有两种方式 nodePort、NodeBlanc 或ingress text 1 2 3 4 5 kubectl create secret generic \ dashboard-cert \ -n kube-system \ --from-file=dashboard....

secret、configMap特殊类型的存储卷，多数情况下不是为Pod提供存储空间来用的，而是给管理员或用户提供了从集群外部向Pod内部应用注入配置信息的方式。 工作实现 configMap 在集群内部存在一个名称空间，在名称空间当中拥有一个可正常运行的Pod，当镜像启动时使用的配置文件在做镜像之前就确定了，并且做完镜像就不能修改了。除非在做镜像时使用entryPoint脚本去接受用户启动容器时传入环境变量进来，将环境变量的数据替换到配置文件中去，从而使应用程序在启动之前就能获得一个新的配置文件而后得到新的配置。当需要修改配置文件时是很麻烦的。而配置中心只需将集中的配置文件修改，并通知给相应进程，让其重载配置文件。而Kubernetes的应用也存在此类问题，当配置文件修改后就需要更新整个镜像。因此无需将配置信息写死在镜像中。而是引入一个新的资源，这个资源甚至是整个Kubernetes集群上的一等公民（标准的K8S资源）。这个资源被叫做configMap configMap当中存放的配置信息，随后启动每一个Pod时，Pod可以共享使用同一个configMap资源，这个资源对象可以当存储卷来使用，也可以从中基于环境变量方式从中获取到一些数据传递给环境变量，注入到容器中去使用。 因此configMap扮演了Kubernetes中的配置中心的功能。但是configMap是明文存储数据的。因此和configMap拥有同样功能的标准资源secret就诞生了。与configMap所不同之处在于，secret中存放的数据是用过编码机制进行存放的。 核心作用：让配置信息从镜像中解耦，从而增强应用的可移植性与复用性。使一个镜像文件可以为应用程序运行不同配置的环境而工作。简单来讲，一个configMap就是一系列配置数据的集合。这些数据可以注入到Pod对象中的容器所使用。 在configMap中，所有的配置信息都保存为key value格式。V只是代表了一段配置信息，可能是一个配置参数，或整个配置文件信息都是没有问题的。 配置容器化应用的方式 自定义命令行参数 args [] 把配置文件直接陪进镜像； 环境变量 Cloud Native的应用程序一般可直接通过环境变量加载配置 通过entrypoint脚本来预处理变量为配置文件中的配置信息。 存储卷 配置文件注入方式： 将configMap做存储卷 使用env docker config contioners env name 变量名 value 变量值 valueFrom 数据不是一个字符串，而是引用另外一个对象将其传递给这个变量。 configMapKeyRef configMap中的某个键 fieldRef 某个字段。此资源可以是Pod自身的字段。如metadata.labels status.hostIP status.podIP resourceFieldRef 资源需求和资源限制。 secreKeyRef 引用secre configMap无需复杂描述，因此没有spec字段 text 1 2 3 4 apiVersion kind data binaryData 一般情况下data与binaryData只使用其中一种。 创建简单的configMap还可以使用 kubectl create configMap来创建。如需要长期使用，可以定义为配置清单文件。 text 1 2 3 kubectl create configmap nginx-config \ --from-literal=nginx_port=80 \ --from-literal=servername=test.com 使用文件创建...

RPM概述 RPM (Red Hat Package Manager)，几乎所有的 Linux 发行版本都使用这种形式的软件包管理安装、更新和卸载软件。对于最终用户来说，使用RPM所提供的功能来维护系统是比较容易和轻松的。安装、卸载和升级RPM软件包只需一条命令就可以搞定。RPM维护了一个所有已安装的软件包和文件的数据库，可以让用户进行查询和验证工作。在软件包升级过程中，RPM会对配置文件进行特别处理，绝对不会丢失以往的定制信息。对于程序员RPM可以让我们连同软件的源代码打包成源代码和二进制软件包供最终用户使用。 一般而言制作一个RPM包包含以下几个步骤 计划你想要建立什么 收集软件包 根据需要修补软件 计划升级旧有的包 创建可重现的软件构建 概述任何依赖关系 构建rpm 测试rpm（能否安装、升级） RPM capability 能力 运行或安装需要依赖于其他的RPM包本身或所提供的文件为基础的现象被称之为依赖关系。但在制作RPM包时，依赖关系有两类编译依赖与安装依赖。 自身名字所包含的意义 它提供的文件也有可能被其他软件所依赖，文件本身也能识别成一种能力 编译依赖和安装依赖 每一个RPM包都提供一种能够完成任务的功能，此种能力很可能被其他RPM所依赖，此能力大多数情况下和RPM名字是相同的。 制作RPM包的纲要有如下四部 设定RPM包制作的目录结构（制作车间） 将原材料（源码包、配置文件、补丁包）放置规划好的目录当中。 创建spec文件，指挥如何使用原材料将其制作成rpm包。 编译源代码生成rpm包 在一个特定的目录中提供如下5个子目录 redhat上默认在/usr/src/reahat BUILD 源代码解压以后放置的位置，仅需提供目录。 RPMS 放置制作完成后的RPM包 SOURCES 原材料放置目录（配置文件、源码包、补丁包） SPECS 放置spec文件（纲领性文件）的。 SRPMS SRC rpm包存放位置 RPM优缺点 优点： 集中管理：RPM可以集中管理安装、升级和删除软件包，保证系统的干净和稳定。 精确控制：RPM提供详细的软件包信息，可以对软件包的安装路径、依赖关系、版本等进行精确控制，使得软件安装更加灵活便捷。 简单易用：RPM提供了一套完整的命令行工具和图形化管理工具，对于普通用户来说，使用起来非常方便。 更新机制：RPM可以根据用户需要进行更新，包括安全更新、功能更新和修复错误等，可以更好地保证系统安全与稳定性。 缺点： 依赖管理：RPM虽然可以管理软件包的依赖关系，但其解决依赖的方式容易出现问题，可能会出现某些软件包的依赖关系无法解决的情况。 更新速度：由于需要对软件包进行依赖检查等操作，升级软件包可能需要较长时间，特别是当软件包依赖比较复杂时。 存在问题：有时候使用RPM安装的软件包出现问题，需要手动卸载并重新安装，这会导致一些无法预测的麻烦。 兼容性：RPM采用了特定的软件包管理标准，要求安装的软件包必须符合这些标准。因此，RPM可能不太适用于其他Linux系统或自定义的软件包格式。 SPEC文件 制作RPM软件包的关键在于编写SPEC软件包描述文件。要想制作一个rpm软件包就必须写一个软件包描述文件（SPEC）。这个文件中包含了软件包的诸多信息，如软件包的名字、版本、类别、说明摘要、创建时要执行什么指令、安装时要执行什么操作、以及软件包所要包含的文件列表等等。 SPEC文件通常包括以下几个部分： 头文件：包括软件包的名称、版本、发布号、授权等信息。 %description：包括软件包的描述、依赖关系、构建环境等信息。 %prep：指定源代码的来源和如何解压缩及准备源代码。 %build：指定如何编译源代码。 %install：指定如何安装编译好的软件包。 %check：指定测试源代码的特定部分，通常是用来运行单元测试。 %clean：指定清除构建过程中产生的临时文件和目录的方法。 %files：指定哪些文件应该包括在最终的RPM文件中。 %changelog：记录软件包的变更历史。 SPEC文件中常用的宏变量 宏变量 说明 %{name} 软件包的名称，如 myapp。 %{version} 软件包的版本号，如 1....

Kubernetes API Object 在Kubernetes线群中，Kubernetes对象是持久化的实体（最终存入etcd 中的数据），集群中通过这些实体来表示整个集群的状态。前面通过kubectl来提交的资源清单文件，将我们的YAML文件转换成集群中的一个API对象的，然后创建的对应的资源对象。 Kubernetes API是一个以JSON为主要序列化方式的HTTP服务，除此之外支持Protocol Buffers序列化方式（主要用干集群内年件间的通信）。为了api的可扩展性，Kubemetes在不同的API路径（/api/v1或/apis/batch）下面支持了多个API版本，不同的API版本就味不同级别稳定性和支持。 Alpha ：例如v1Alpha：默认情况下是禁用的，可以随时删除对功能的支持。 Beta：例如 v2beta1 默认是启用的，表示代码已经经过了很好的测试，但是对象的语义可能会在施后的版本中以不兼咨的方式更改 Stable：例如：v1 表示已经是稳定版本，也会出现在后续的很多版本中。 在Kubernetes集群中，一个API对象在Etcd 里的完整资源路径，是由：group （API组）、 version （API版本） 和 Resource API资源类型）三个部分组成。通过这种的结构，整个Kubernetes 中所有API对象，就可以用如下的树形结构表示出来： Kubernetes API Object的使用 API对象组成查看：kubectl get --raw / 通常，KubernetesAPI支持通过标准HTTP P0ST、PUT、DELETE 和 GET 在指定PATH路径上创建、更新、删除和检索操作，并使用JSON作为默认的数据交互格式。 如要创建一个Deployment对象，那YAML文件的声明就需： yaml 1 2 apiVersion: apps/v1 # kind: Deployment Deployment就是这个API对象的资源类型（Resource），apps就是它的组（Group），v1就是它的版本（Version）。API Group、Version 和资源满唯一定义了一个HTTP路径，然后在kube-apiserver 对这个url进行了监听，然后把对应的请求传递给了对应的控制器进行处理。 API对象参考文档 授权插件分类 Node 由节点来认证。 ABAC 基于属性的访问控制，RBAC之前的授权控制的插件算法 RBAC Role-based Access Control。 Webhook 基于http的回调机制来实现访问控制。 RBAC 基于角色的访问控制可以理解为，角色（role）反而是授权的机制，完成了权限的授予、分配等。角色是指一个组织或者任务工作中的位置，通常代表一种权利、资格、责任等。在基于角色的访问控制中还有一种术语叫做 ==许可==（permission）。 简单来讲就如同上图描述，使用户去扮演这个角色，而角色拥有这个权限，所以用户拥有这个角色的权限。所以授权不授予用户而授予角色。 RBAC 使用 rbac.authorization.k8s.ioAPI组来驱动鉴权操作，允许管理员通过 Kubernetes API 动态配置策略。...

近期因 centos 6.x 默认 openssh 扫描存在大量漏洞，基于安全考虑，需要将 openssh_5.3p1 升级为最新版，网上查了很多教程，发现 openssh 存在大量依赖，不解决依赖问题很难保证其他服务政策。而 openssl 又被大量程序依赖。实在是头疼。最后发现一个不破坏各种依赖又可以完美升级的方案 注：curl wget yum 等依赖 openssl gitlab依赖 openssh 因卸载 openssh 与 openssl 编译安装导致各种依赖程序被破坏，虽然最后升级成功，但是wget curl 和代码库被破坏。 下载 openssh-7.7p 源码包 下载地址 下载之后解压看 README 和 INSTALL text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 1. Prerequisites ---------------- A C compiler. Any C89 or better compiler should work....

项目地址：https://github.com/weaveworks/weave 注：weave公司与2024年关门 weaves说明 Weave是由weaveworks公司开发的解决Docker跨主机网络的解决方案，它能够创建一个虚拟网络，用于连接部署在多台主机上的Docker容器，这样容器就像被接入了同一个网络交换机，那些使用网络的应用程序不必去配置端口映射和链接等信息。 外部设备能够访问Weave网络上的应用程序容器所提供的服务，同时已有的内部系统也能够暴露到应用程序容器上。Weave能够穿透防火墙并运行在部分连接的网络上，另外，Weave的通信支持加密，所以用户可以从一个不受信任的网络连接到主机。 weaves实现原理 weave launch初始化时会自动下载三个docker容器来辅助运行，并且创建linux网桥与docker网络 weave 运行了三个容器： weave 是主程序，负责建立weave网络，收发数据，提供 DNS 服务等。 weavevolumes容器提供卷存储 weavedb容器提供数据存储 sh 1 2 3 4 5 6 $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE weaveworks/weavedb latest 15c78a9b1895 4 weeks ago 698B weaveworks/weaveexec 2.4.0 bf0c403ea58d 4 weeks ago 151MB weaveworks/weave 2.4.0 7aa67bc6bc43 4 weeks ago 96.7MB 自动创建网桥 sh 1 2 3 4 5 $ brctl show bridge name bridge id STP enabled interfaces docker0 8000....

默认情况下，容器没有任何资源限制，因此几乎耗尽docker主机之上，内核可分配给当前容器的所有资源。可以使用主机内核调度程序允许的尽可能多的给定资源。在此基础上Docker provides提供了控制容器可以使用多少内存，CPU或块IO的方法，设置docker run命令的运行时配置标志。 容器得以实现主要依赖于内核中的两个属性namespace cgroup。其中许多功能都要求您的内核支持Linux功能。要检查支持，可以使用docker info命令。 Memory OOME 在Linux主机上，如果内核检测到没有足够的内存来执行重要的系统功能，它会抛出OOME或Out of Memory Exception异常，并开始终止进程以释放内存资源。一旦发生OOME，任何进程都有可能被杀死，包括docker daemon自身在内。为此，Docker特地调整了docker daemon的OOM优选级，以免它被内核“正法”，但容器的优选级并未被调整。 工作逻辑为 在宿主机上跑有很多容器并包括系统级进程。系统级进程也包括docke daemon自身。当内核执行系统管理操作，如内核需要使用内存，发现可以内存已经为空，会启动评估操作，评估谁占用内存高。我们认为哪个资源占用内存高就该将其kill来释放内存空间。（需要注意的是占用内存高的进程也不一定被kill掉。A进程分配10G已使用5G，进程B分配1G已使用1G。A只使用50%内存，而B已经耗尽所有内存）。内核会提供这些进程进行评分，按照优先级逆序强制kill，直至可使用内存空间足够。此时内核就可以使用内存资源创建其他进程。 每一个进程被计算之后会有一个oom scores，得分越高就会被优先kill。得分是由内存申请分配空间等一系列复杂计算得知。当进程得分最高也不能被kill掉时，如docker daemon，此时需要调整优先级。每一个进程有一个oom.adj的参数，将优先级调整越低，计算的分数就越少。 在docker run时可以直接调整容器的OOM.adj参数。如果想限制容器能使用多少内存资源、或CPU资源，有专门的选项可以实现。非常重要的容器化应用需要在启动容器时调整其OOM.adj，还可以定义容器的策略，一旦被kill直接restart Limit a container’s resources 限制一个容器能使用多少内存资源或CPU资源docker有专门的选项来实现 -m 限制容器可用RAM空间。选项参数可以使用KB M G等作为接受单位使用。可单独使用。 --memory-swap 设置容器可用交换分区大小。使用swap允许容器在容器耗尽可用的所有RAM时将多余的内存需求写入磁盘。--memory-swap是一个修饰符标志，只有在设置了–memorys时才有意义。 --memory-swap --memory-swap --memory 功能 正数S 正数 M 容器可用总空间为S，其中可用ram为M 0 正数 M相当于未设置swap（unset） unset（未设置） 正数 M 若主机（Docker Host）启用了swap，则容器的可用swap为 2*M -1 正数M 若主机（Docker Host）启用了swap，则容器可使用交换分区总空间大小为宿主机上的所有swap空间的swap资源 注意：在容器内使用free命令可以看到的swap空间并不具有其所展现出的空间指示意义。 –memory-swappiness 用来限定容器使用交换分区的倾向性。 –memory-reservation 预留的内存空间 –oom-kill-disable 禁止oom被kill掉 默认情况下，每个容器对主机CPU周期的访问权限是不受限制的。可以设置各种约束来限制给定容器访问主机的CPU周期。大多数用户使用和配置默认CFS调度程序。在Docker 1.13及更高版本中，还可以配置实时调度程序。 CPU Limit a container’s resources 内核中进程管理子系统当中最重要的组件为进程角度器scheduler，非实时优先级,有效范围为100-139[-20,19]。因此每个进程的默认优先级为120。实时优先级0-99。调度100-139之间的进程有个非常重要的调度器CFS scheduler（完全公平调度器），公平调度每一个进程在需要执行时，去分配scores到这个进程上。...

修改logging.properties text 1 /usr/local/apache-tomcat-8.5.32/conf/logging.properties bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ############################################################ # Handler specific properties. # Describes specific configuration info for Handlers. ############################################################ 1catalina.org.apache.juli.AsyncFileHandler.level = FINE 1catalina.org.apache.juli.AsyncFileHandler.directory = /data/logs 1catalina.org.apache.juli.AsyncFileHandler.prefix = catalina. 2localhost.org.apache.juli.AsyncFileHandler.level = FINE 2localhost.org.apache.juli.AsyncFileHandler.directory = /data/logs 2localhost.org.apache.juli.AsyncFileHandler.prefix = localhost. 3manager.org.apache.juli.AsyncFileHandler.level = FINE 3manager.org.apache.juli.AsyncFileHandler.directory = /data/logs 3manager.org.apache.juli.AsyncFileHandler.prefix = manager. 4host-manager.org.apache.juli.AsyncFileHandler.level = FINE 4host-manager....

tomcat介绍 Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，Tomcat是Apache 软件基金会（Apache Software Foundation）的Jakarta 项目中的一个核心项目，它早期的名称为catalina，后来由Apache、Sun 和其他一些公司及个人共同开发而成，并更名为Tomcat。 java体系结构 java程序设计语言（编程） java类文件格式 java api java vm java 纯面向对象语言 obj：以指令为中心，围绕指令组织数据 面向对象：以数据为中心，围绕数据组织指令 Tomcat核心组件： Catalina：servlet container在tomcat中用于实现servlet代码的被称作Catalina Coyote：一个http连接器，能够接受http请求并相应http请求的web服务器 jasper：JSP Engine jsp翻译器 Tomcat组成部分 Tomcat支持Servlet和JSP1的规范，它由一组嵌套的层次和组件组成，一般可分为以下四类： 顶级组件：位于配置层次的顶级，并且彼此间有着严格的对应关系； 连接器：连接客户端（可以是浏览器或Web服务器）请求至Servlet容器， 容器：包含一组其它组件； 被嵌套的组件：位于一个容器当中，但不能包含其它组件； tomcat常见组件 服务器(server) 服务器(server)顶级组件：Tomcat的一个实例，通常一个JVM只能包含一个Tomcat实例；因此，一台物理服务器上可以在启动多个JVM的情况下在每一个JVM中启动一个Tomcat实例，每个实例分属于一个独立的管理端口。这是一个顶级组件。 server相关属性 className：用于实现此Server容器的完全限定类的名称，默认为 org.apache.cataliana.core.StandardServer; port：接收shutdown指令的端口，默认仅允许通过本机访问，默认为8005 shutdown：发往此Server用于实现关闭tomcat实例的命令字符串，默认为SHUTDOWN 服务(service) Service主要用于关联一个引擎和此引擎相关的连接器，每个连接器通过一个特定的端口和协议接收入站请求将其转发至关联的引擎进行处理，因此，Service要包含一个引擎（Engine）、一个或多个连接器（Connector）。 定义一个名为Catalina的Service，此名字也会产生相关的日志信息时记录在日志文件当中。 xml 1 <Service name="Catalina"> Service相关属性 className：用于实现service的类名，一般都是 org.apache.catalina.core.StandardService name：此服务的名称，默认为Catalina。 连接器(connectors) 分析并接收用户请求，并把它转换成本地jsp文件代码的请求。负责连接客户端（可以是浏览器或Web服务器）请求至Servlet容器内的Web应用程序，通常指的是接收客户发来请求的位置及服务器端分配的端口。 默认端口通常是HTTP协议的8080，管理员也可以根据自己的需要改变此端口。一个引擎可以配置多个连接器，但这些连接器必须使用不同的端口。默认的连接器是基于HTTP/1.1的Coyote。同时，Tomcat也支持AJP、JServ和JK2连接器。 进入Tomcat的请求可以根据Tomcat的工作模式分为如下两类： Tomcat作为应用程序服务器：请求来自于前端的web服务器，这可能是Apache IIS Nginx。 Tomcat作为独立服务器：请求来自与web浏览器。 Tomcat应该考虑工作情形并为相应情形下的请求分别定义好需要的连接器才能正确接收来自于客户端的请求，一个引擎可以有一个或多个连接器，以适应多种请求方式。 定义连接器可以使用多种属性，有些属性也只是适用于某种特定的连接器类型， 一般来说，常见于server.xml中的连接器类型通常有4种： HTTP连接器 SSL连接器 AJP 1.3连接器 proxy连接器 xml 1 2 3 <Connector port="8080" protocol="HTTP/1....

关于vlan说明 Macvlan和ipvlan是Linux网络驱动程序，它们将底层或主机接口直接暴露给在主机中运行的VM或容器。 Macvlan允许单个物理接口使用macvlan子接口具有多个mac和ip地址。这与使用vlan在物理接口上创建子接口不同。使用vlan子接口，每个子接口使用vlan属于不同的L2域，所有子接口都具有相同的mac地址。使用macvlan，每个子接口将获得唯一的mac和ip地址，并将直接暴露在底层网络中。Macvlan接口通常用于虚拟化应用程序，每个macvlan接口都连接到Container或VM。每个容器或VM可以直接从公共服务器获取dhcp地址，就像主机一样。这将有助于希望Container成为传统网络的客户使用他们已有的IP寻址方案。Macvlan有4种类型(Private, VEPA, Bridge, Passthru)。常用的类型是Macvlan网桥，它允许单个主机中的端点能够在没有数据包离开主机的情况下相互通信。对于外部连接，使用底层网络。下图显示了两个使用macvlan网桥相互通信以及外部世界的容器。两个容器将使用Macvlan子接口直接暴露在底层网络中。 使用mavvlan构建docker网络 Macvlan，MACVLAN或MAC-VLAN允许您在单个物理接口上配置多个第2层（即以太网MAC）地址。 Macvlan允许您配置父物理以太网接口（也称为上层设备）的子接口（也称为从设备），每个接口都有自己唯一的（随机生成的）MAC地址，因此也有自己的IP地址。然后，应用程序、VM和容器可以绑定到特定的子接口，以使用自己的MAC和IP地址直接连接到物理网络。 Mavlan子接口不能直接与父接口通信，即VM不能直接与主机通信。如果需要VM主机通信，则应添加另一个macvlan子接口并将其分配给主机。 Macvlan子接口使用 eth0.20@eth0 表示法来清楚地识别子接口及其父接口。子接口状态绑定到其父级状态。如果eth0关闭，则 eth0.20@eth0 也会关闭。 配置macvlan先决条件 至少需要Linux内核版本3.9以上，建议使用4.0或更高版本。 环境准备 主机名 IP地址 地位 软件环境 物理机 10.0.0.1 物理机 windows10 网关 10.0.0.2 宿主机网关 vmvare网关 c1 10.0.0.3 容器01 docker c2 10.0.0.4 容器02 docker node01 10.0.0.15 宿主机01（vm虚拟机） centos 7.3/docker-ce1806 node02 10.0.0.16 宿主机02（vm虚拟机） centos 7.3/docker-ce1806 2.3 启动网卡混合模式 两台主机网卡使用桥接模式,网卡混杂模式开启全部允许。 主机上配置的eth0网卡和创建的vlan网卡,均需要开启混杂模式。如果不开启混杂模式会导致macvlan网络无法访问外界,具体在不使用vlan时,表现为无法ping通路由,无法ping通同一网络内其他主机。 sh 1 2 ip link set eth0 promisc on ip link set eth0 promisc off 开启后查看网卡状态 sh 1 2 3 4 5 6 7 $ ip addr 2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:0c:29:84:f3:29 brd ff:ff:ff:ff:ff:ff inet 10....

docker的四种网络模式 Bridge模式（默认） 当Docker进程启动时，会在宿主机上创建一个名为docker0的虚拟网桥，此主机上启动的Docker容器会连接到这个虚拟网桥上。虚拟网桥的工作方式和物理交换机类似，这样主机上的所有容器就通过交换机连在了一个二层网络中。 默认ip段172.17.0.1/16；从docker0子网中分配一个IP给容器使用，并设置docker0的IP为容器的默认网关。在主机上创建一对虚拟网卡veth pair设备，Docker将veth pair设备的一端放在新创建的容器中，并命名为eth0（容器的网卡），另一端放在主机中，以vethxxx这样类似的名字命名，并将这个网络设备加入到docker0网桥中。可以通过brctl show命令查看。 使用 docker run -p 时，docker实际是在iptables做了DNAT规则，实现端口转发功能。可以使用 iptables -t nat -nL 查看。 host模式 启动容器的时候使用host模式，那么这个容器将不会获得一个独立的Network Namespace，而是和宿主机共用一个Network Namespace。容器将不会虚拟出自己的网卡，配置自己的IP等，而是使用宿主机的IP和端口。但是，容器的其他方面，如文件系统、进程列表等还是和宿主机隔离的。 none模式 使用none模式，Docker容器拥有自己的Network Namespace，但是，并不为Docker容器进行任何网络配置。也就是说，这个Docker容器没有网卡、IP、路由等信息。需要我们自己为Docker容器添加网卡、配置IP等。 container模式 这个模式指定新创建的容器和已经存在的一个容器共享一个 Network Namespace，而不是和宿主机共享。新创建的容器不会创建自己的网卡，配置自己的 IP，而是和一个指定的容器共享 IP、端口范围等。同样，两个容器除了网络方面，其他的如文件系统、进程列表等还是隔离的。两个容器的进程可以通过 lo 网卡设备通信。 容器外部访问原理 bash 1 2 3 4 5 6 7 8 docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0 inet6 fe80::42:a5ff:fe59:2034 prefixlen 64 scopeid 0x20<link> ether 02:42:a5:59:20:34 txqueuelen 0 (Ethernet) RX packets 56986 bytes 2746876 (2.6 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 64106 bytes 503304169 (479....

参数 说明 -i, –interactive 即使不是交互模式也保持stdin打开 -d, –detach 后台运行容器并打印容器ID -t, –tty 分配一个伪TTY 添加自定义主机映射 bash 1 2 3 4 5 6 $ docker run -tid --add-host docker-node:10.0.0.1 centos 61d5824c720f1a32c743a3d0f434e17a7f6860dba1cb5559653a80c064da8073 $ docker exec 61d5824c720f1a32c cat /etc/hosts ff02::2 ip6-allrouters 10.0.0.1 docker-node 172.17.0.2 61d5824c720f 添加linux功能 linux内核特性，提供权限访问控制。如需要特殊权限，不赋权限容器将不能正常运行。 将容器pid写入一个文件内 bash 1 2 3 4 $ docker run -itd --cidfile /tmp/pid centos 458d9f4b3cc51a4f0f3abffbc78c643b98a89eef3cdfe263e762ac05d3f5f47d $ cat /tmp/pid 458d9f4b3cc51a4f0f3abffbc78c643b98a89eef3cdfe263e762ac05d3f5f47d 将主机列表添加到容器中 bash 1 --device list 设置自定义dns bash 1 2 3 4 5 $ docker run -it centos cat /etc/resolv....

Docker Overlay Network Overlay网络是指在不改变现有网络基础设施的前提下，通过某种约定通信协议，把二层报文封装在IP报文之上的新的数据格式。这样不但能够充分利用成熟的IP路由协议进程数据分发；而且在Overlay技术中采用扩展的隔离标识位数，能够突破VLAN的4000数量限制支持高达16M的用户，并在必要时可将广播流量转化为组播流量，避免广播数据泛滥。 因此，Overlay网络实际上是目前最主流的容器跨节点数据传输和路由方案。 要想使用Docker原生Overlay网络，需要满足下列任意条件 Docker 运行在Swarm 使用键值存储的Docker主机集群 使用键值存储搭建Docker主机集群 使用键值存储的Docker主机集群，需满足下列条件： 集群中主机连接到键值存储，Docker支持 Consul、Etcd和Zookeeper 集群中主机运行一个Docker守护进程 集群中主机必须具有唯一的主机名，因为键值存储使用主机名来标识集群成员 集群中linux主机内核版本在3.12+,支持VXLAN数据包处理，否则可能无法通行 部署docker内置的OverLAY网络 环境准备说明 host ip- node01 10.0.0.15 node02 10.0.0.16 安装Consul 下载地址：Download Consul 启动命令 bash 1 2 3 4 5 6 7 8 consul agent -server -bootstrap -ui -data-dir /data/docker/consul \ -client=10.0.0.16 -bind=10.0.0.16 docker run -d -p 8400:8400 -p 8500:8500 -p 8600:53/udp -h consul progrium/consul -server -bootstrap -ui-dir /ui #-ui : consul 的管理界面 #-data-dir : 数据存储 配置docker链接consul bash 1 2 3 4 5 ExecStart=/usr/bin/dockerd \ -H tcp://0....

一、使用前提 通用镜像未必与应用程序和配置是符合我们需要的。 1.1 常见镜像制作方式 常见制作镜像方式有两种 基于容器 基于镜像制作：编辑一个Dockerfile，而后根据此文件制作； 二、Dockerfile概述 Dockerfile只是构建Docker镜像的源代码，docker可以通过读取Dockerfile中的指令自动构建图像。Dockerfile是一个文本文档，其中包含用户可以在命令行上调用以组合图像的所有命令。用户可以使用 docker build 创建连续执行多个命令行指令的自动构建。 2.1 Dockerfile的工作模式 基于Dockerfile制作镜像时，需在专用目录放置Dockerfile文件，并且文件首字母必须大写。基于Dockerfile中打包的文件必须奇基于工作目录往下走的路径。在打包镜像时，.dockeringore 文件本身与所有包含在 .dockeringore 文件中的路径，都不被打包进去。在Dockerfile制作环境为底层镜像启动容器时所能够提供的环境。 2.2 环境变量替换 制作镜像中还可以使用环境变量。环境变量（使用ENV语句声明）也可以在某些指令中使用，因为Dockerfile环境变量在 Dockerfile 中以 $variable_name 或${variable_name}标记。 语法还支持一些标准`bash修饰符 ${variable:-word} 表示如果设置了变量，那么结果将是该值。如果未设置变量，那么word将是结果。 ${variable+word} 表示如果设置了变量，则word将是结果，否则结果为空字符串。 三、Dockerfile指令说明 特别说明：Dockerfile中每一条指令都会生成一个新的镜像层。 FROM FROM指令（最重要的一个），必须为Dockerfile文件开篇的第一个非注释行，用于为镜像文件构建过程指定基准镜像，后续的指令运行于此基准镜像所提供的运行环境。基准镜像可以是任何可用镜像文件，默认情况下，docker build会在docker主机上查找指定的镜像文件，在其不存在时，则会从 Docker Hub Registry 上拉取所需的镜像文件。如果找不到指定的镜像文件，docker build 会返回一个错误信息 Syntax: sh 1 FROM repository[:tag] sh 1 FROM registry/repository[:tag] bash 1 FROM resository@[digest] #←相同名称时，可以使用resository@镜像hush码指定镜像。 参数 说明- reposotiry 某一个镜像的仓库，如redis镜像仓库。 registry docker镜像仓库，如docker hub，docker registry包含很多reposotiry，如nginx php tomcat等。不指定registry，默认从docker hub下载。 tag image的标签，为可选项，省略时默认为latest。 MAINTANIER(depreacted) MAINTANIER（depreacted）用于让Dockerfile制作者提供本人的详细信息。Dockerfile并不限制MAINTAINER指令可在出现的位置，但推荐将其放置于FROM指令之后。...

使用docker-compose构建LNMP环境 编写Dockerfile 这里采用的是先将nginx php打包为rpm包，然后做成镜像。与直接在容器里编译安装同理的。 nginx Dockerfile bash 1 2 3 4 5 6 7 8 FROM centos MAINTAINER lc RUN yum install -y gcc gcc-c++ openssl-devel make pcre-devel ADD nginx-1.13.9-1.el7.centos.x86_64.rpm /tmp/ RUN cd /tmp/ && rpm -ivh nginx-1.13.9-1.el7.centos.x86_64.rpm ADD nginx.conf /etc/nginx/ EXPOSE 80 CMD ["/usr/sbin/nginx", "-g", "daemon off;"] php Dockerfile bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 FROM centos MAINTAINER LC RUN curl -o /etc/yum....