简介 Metacontroller是GKE为k8s开发的一个附加组件，用简单的脚本便可以方便的管理自定义控制器。 概念 CRD 自定义资源 Metacontroller Metacontroller控制器本身 DecoratorController Metacontroller中用于向现有资源添加新行为 CompositeController Metacontroller中用于通过父对象管理子对象 安装 # 创建命名空间 kubectl create namespace metacontroller # 创建serviceaccount和rolebiding kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/metacontroller/master/manifests/metacontroller-rbac.yaml # 创建metacontroller crd 和 metacontroller statefulset kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/metacontroller/master/manifests/metacontroller.yaml 创建一个控制器 目标 通过HelloWorld自定义资源来创建pod，打印hello 创建HelloWorld CRD cat << EOF | kubectl apply -f - apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: helloworlds.example.com spec: group: example.com version: v1 names: kind: HelloWorld plural: helloworlds singular: helloworld scope: Namespaced EOF 创建CompositeController cat << EOF | kubectl apply -f - apiVersion: metacontroller.

调度器介绍 scheduler 是k8s master的一部分 自定义调度器方式 添加功能重新编译 实现自己的调度器（multi-scheduler） scheduler调用扩展程序实现最终调度（Kubernetes scheduler extender） 添加调度功能 k8s中的调度算法介绍 预选 优选 实现自己的调度器(配置多个scheduler) scheduler以插件形式存在，集群中可以存在多个scheduler，可以显式指定scheduler 配置pod使用自己的调度器 下面pod显式指定使用my-scheduler调度器 apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: schedulerName: my-scheduler containers: - name: nginx image: nginx:1.10 官方给出的shell版本scheduler示例 #!/bin/bash SERVER='localhost:8001' while true; do for PODNAME in $(kubectl --server $SERVER get pods -o json | jq '.items[] | select(.spec.schedulerName == "my-scheduler") | select(.spec.nodeName == null) | .metadata.name' | tr -d '"') ; do NODES=($(kubectl --server $SERVER get nodes -o json | jq '.

核心指标管道 从 Kubernetes 1.8 开始，资源使用指标（如容器 CPU 和内存使用率）通过 Metrics API 在 Kubernetes 中获取。 这些指标可以直接被用户访问(例如通过使用 kubectl top 命令)，或由集群中的控制器使用(例如，Horizontal Pod Autoscale 可以使用这些指标作出决策)。 Resource Metrics API 通过 Metrics API，您可以获取指定 node 或 pod 当前使用的资源量。这个 API 不存储指标值， 因此想要获取某个指定 node 10 分钟前的资源使用量是不可能的。 Metrics API 和其他的 API 没有什么不同： 它可以通过与 /apis/metrics.k8s.io/ 路径下的其他 Kubernetes API 相同的端点来发现 它提供了相同的安全性、可扩展性和可靠性保证 Metrics API 在 k8s.io/metrics 仓库中定义。您可以在这里找到关于Metrics API 的更多信息。 注意： Metrics API 需要在集群中部署 Metrics Server。否则它将不可用。 Metrics Server Metrics Server 实现了Resource Metrics API Metrics Server 是集群范围资源使用数据的聚合器。 从 Kubernetes 1.

从1.8版开始，Kubernetes Storage SIG停止接受树内卷插件，并建议所有存储提供商实施树外插件。目前有两种推荐的实现方式：容器存储接口（CSI）和Flexvolume。 Flexvolume 介绍 lexvolume使用户能够编写自己的驱动程序并在Kubernetes中添加对卷的支持。如果–enable-controller-attach-detach启用Kubelet选项，则供应商驱动程序应安装在每个Kubelet节点和主节点上的卷插件路径中。 Flexvolume是Kubernetes 1.8版本以后的GA特性。 先决条件 在插件路径中的所有节点上安装供应商驱动程序，–enable-controller-attach-detach设置为true， 安装插件的路径：<plugindir>/<vendor~driver>/<driver>。 默认的插件目录是/usr/libexec/kubernetes/kubelet-plugins/volume/exec/。 可以通过–volume-plugin-dir标志在Kubelet中进行更改， 并通过标志在控制器管理器中进行更改–flex-volume-plugin-dir。 例如，要添加cifs驱动程序，供应商foo将驱动程序安装在： /usr/libexec/kubernetes/kubelet-plugins/volume/exec/foo~cifs/cifs 供应商和驱动程序名称必须与卷规格中的flexVolume.driver匹配，’〜’替换为’/‘。 例如，如果flexVolume.driver设置为foo/cifs，那么供应商是foo，而驱动程序是cifs 动态插件发现 Flexvolume从v1.8开始支持动态检测驱动程序的能力。 系统初始化时不需要存在驱动程序，或者需要重新启动kubelet或控制器管理器， 则可以在系统运行时安装，升级/降级和卸载驱动程序。有关更多信息，请参阅设计文档 自动插件安装/升级 安装和升级Flexvolume驱动程序的一种可能方式是使用DaemonSet。见推荐驱动程序部署方法的详细信息。 插件详细信息 该插件希望为后端驱动程序实现以下调用。有些标注是可选的。 调用是从Kubelet和Controller管理器节点调用的。 只有当启用了“–enable-controller-attach-detach”Kubelet选项时， 才会从Controller-manager调用调用。 驱动程序调用模型 init 初始化驱动程序。在Kubelet＆Controller manager初始化期间调用。 成功时，该函数返回一个功能映射，显示驱动程序是否支持每个Flexvolume功能。当前功能: attach - 指示驱动是否需要附加和分离操作的布尔字段。 该字段是必需的，但为了向后兼容，默认值设置为true，即需要附加和分离。 有关功能图格式，请参阅驱动程序输出。 <driver executable> init attach 在给定主机上附加给定规范指定的卷。成功时，返回设备连接到节点的设备路径。 如果启用了“–enable-controller-attach-detach”Kubelet选项， 则Nodename参数才是有效/相关的。来自Kubelet＆Controllermanager。 此调出不会传递Flexvolume规范中指定的“secrets”。如果您的驱动程序需要secrets， 请不要执行此调出，而是使用“mount”调出并在该调出中执行attach和调用。 <driver executable> attach <json options> <node name> Detach 从Kubelet节点分离卷。只有在启用启用了“–enable-controller-attach-detach”Kubelet选项时 Nodename参数才是有效/相关的。Kubelet & Controller manager进行调用 <driver executable> detach <mount device> <node name> Wait for attach 等待卷连接到远程节点上。成功后，返回设备的路径。从Kubelet & Controller manager进行调用，超时时间为10毫秒(代码),

kubectl-plugins kubectl-plugins 是在 v1.8.0 发行版中作为 alpha 功能正式引入的。 因此，尽管插件功能的某些部分已经在以前的版本中可用，建议使用 1.8.0 或更高版本的 kubectl 版本. 安装 kubectl 插件 一个插件只不过是一组文件：至少一个 plugin.yaml 描述符，以及可能有一个或多个二进制文件、脚本或资产文件。 要安装一个插件，将这些文件复制到 kubectl 搜索插件的文件系统中的某个位置. 请注意，Kubernetes 不提供包管理器或类似的东西来安装或更新插件， 因此您有责任将插件文件放在正确的位置。我们建议每个插件都位于自己的目录下， 因此安装一个以压缩文件形式发布的插件就像将其解压到 插件加载器 部分指定的某个位置一样简单。 插件加载器 插件加载器负责在下面指定的文件系统位置搜索插件文件，并检查插件是否提供运行所需的最小信息量。放在正确位置但未提供最少信息的文件将被忽略，例如没有不完整的 plugin.yaml 描述符。 插件搜索顺序 插件加载器使用以下搜索顺序： 如果指定了 ${KUBECTL_PLUGINS_PATH} ，搜索在这里停止。 ${XDG_DATA_DIRS}/kubectl/plugins ~/.kube/plugins 如果存在 KUBECTL_PLUGINS_PATH 环境变量，则加载器将其用作查找插件的唯一位置。 KUBECTL_PLUGINS_PATH 环境变量是一个目录列表。在 Linux 和 Mac 中，列表是冒号分隔的。在 Windows 中，列表是以分号分隔的。 如果 KUBECTL_PLUGINS_PATH 不存在，加载器将搜索这些额外的位置： 首先，根据指定的一个或多个目录 [XDG系统目录结构]（https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html） 规范。具体来说，加载器定位由 XDG_DATA_DIRS 环境变量指定的目录， 然后在里面搜索 kubectl/plugins 目录。 如果未指定 XDG_DATA_DIRS ，则默认为 /usr/local/share:/usr/share 。 其次，用户的 kubeconfig 目录下的 plugins 目录。在大多数情况下，就是 ~/.

关闭docker及flannel的snat策略 关闭dockersnat docker默认开启masq,可以通过 --ip-masq=false参数关闭masq 关闭flannel snat策略 flannel默认通过参数注入的方式开启masq： 使用daemonset方式启动可以通过删除–ip-masq参数实现 在系统直接部署的可以修改/usr/libexec/flannel/mk-docker-opts.sh设置ipmasq=false 通过ip-masq-agent实现 介绍 ip-masq-agent 配置iptables规则为MASQUERADE（除link-local外）， 并且可以附加任意IP地址范围 它会创建一个iptables名为IP-MASQ-AGENT的链，包含link local（169.254.0.0/16） 和用户指定的IP地址段对应的规则， 它还创建了一条规则POSTROUTING，以保证任何未绑定到LOCAL目的地的流量会跳转到这条链上。 匹配到IP-MASQ-AGENT中对应规则的IP（最后一条规则除外）， 通过IP-MASQ-AGENT将不受MASQUERADE管理（他们提前从链上返回）， ip-masq-agent链最后一条规则将伪装任何非本地流量。 安装 此仓库包含一个示例yaml文件， 可用于启动ip-masq-agent作为Kubernetes集群中的DaemonSet。 kubectl create -f ip-masq-agent.yaml ip-masq-agent.yaml中的规则指定kube-system为对应DaemonSet Pods 运行的名称空间。 配置代理 提示：您不应尝试在Kubelet也配置有非伪装CIDR的集群中运行此代理。 您可以传递–non-masquerade-cidr=0.0.0.0/0给Kubelet以取消其规则， 这将防止Kubelet干扰此代理。 默认情况下，代理配置为将RFC 1918指定的三个私有IP范围视为非伪装CIDR。 这些范围是10.0.0.0/8，172.16.0.0/12和192.168.0.0/16。 该代理默认将link-local（169.254.0.0/16）视为非伪装CIDR。 默认情况下，代理配置为每60秒从其容器中的/etc/config/ip-masq-agent文件重新加载其配置， 代理配置文件应该以yaml或json语法编写，并且可能包含三个可选项： nonMasqueradeCIDRs []string：CIDR表示法中的列表字符串，用于指定非伪装范围。 masqLinkLocal bool：是否伪装流量169.254.0.0/16。默认为False。 resyncInterval string：代理尝试从磁盘重新加载配置的时间间隔。语法是Go的time.ParseDuration函数接受的任何格式。 该代理将在其容器中查找配置文件/etc/config/ip-masq-agent。这个文件可以通过一个configmap提供，通过一个ConfigMap管道进入容器ConfigMapVolumeSource。 因此，该客户端可以通过创建或编辑ConfigMap实现实时群集中重新配置代理程序。 这个仓库包括一个ConfigMap，可以用来配置代理（agent-config目录）的目录表示。 使用此目录在急群众创建ConfigMap： kubectl create configmap ip-masq-agent --from-file=agent-config --namespace=kube-system 请注意，我们在与DaemonSet Pods相同的命名空间中创建了configmap， 并切该ConfigMap的名称与ip-masq-agent.yaml中的配置一致。 这对于让ConfigMap对于出现在Pods的文件系统中是必需的。 理论基础 该代理解决了为集群中的非伪装配置CIDR范围的问题（通过iptables规则）。 现在这以功能是通过–non-masquerade-cidr向Kubelet 传递一个标志来实现的， 该标志只允许一个CIDR被配置为非伪装。RFC 1918定义了三个范围（10/8，172.

优势 分布式系统查询效率高 搭配grafana可以很高效的做展示 grafana配置ES数据源 在datasource中添加es后端存储，配置对应的ES及对应的认证信息 索引信息 配置template # 例如以nginx host为变量 {"find":"terms","field":"http_host.raw"} 选择 query http_host:$servername 欢迎加入QQ群：k8s开发与实践（482956822）一起交流k8s技术

calico是一个安全的 L3 网络和网络策略提供者。 安装方式 标准托管安装（ETCD存储） 需要提前安装etcd集群 # 创建calico连接etcd的secret kubectl create secret generic calico-etcd-secrets \ --from-file=etcd-key=/etc/kubernetes/ssl/kubernetes-key.pem \ --from-file=etcd-cert=/etc/kubernetes/ssl/kubernetes.pem \ --from-file=etcd-ca=/etc/kubernetes/ssl/ca.pem # 部署 kubectl create -f https://docs.projectcalico.org/v3.0/getting-started/kubernetes/installation/hosted/calico.yaml # rbac kubectl apply -f https://docs.projectcalico.org/v3.0/getting-started/kubernetes/installation/rbac.yaml kubeadm 托管部署 依赖 k8s1.7+ 没有其他cni插件 –pod-network-cidr参数需要和calico ip pool保持一致 –service-cidr 不能和calico ip pool重叠 kubectl apply -f https://docs.projectcalico.org/v3.0/getting-started/kubernetes/installation/hosted/kubeadm/1.7/calico.yaml Kubernetes 数据存储托管安装(不需要etcd) 依赖 暂时不支持ipam,推荐使用 host-local ipam与pod cidr结合使用 默认使用node-to-node mesh模式 k8s1.7+ 没有其他cni插件 –pod-network-cidr参数需要和calico ip pool保持一致 –service-cidr 不能和calico ip pool重叠 # rbac kubectl create -f https://docs.

生成证书 根据官方文档，生成k8s秘钥证书及相关管理证书有三种方式，其本质都是通过openssl cfssl easyrsa openssl 官方文档 cfssl方式 cfssl下载地址 VERSION=R1.2 for i in {cfssl,cfssljson,cfssl-certinfo} do wget https://pkg.cfssl.org/${VERSION}/${i}_linux-amd64 -O /usr/local/bin/${i} done 创建CA证书 生成CA配置文件 mkdir ssl && cd ssl cfssl print-defaults config > config.json cfssl print-defaults csr > csr.json cat > ca-config.json <<EOF { "signing": { "default": { "expiry": "87600h" }, "profiles": { "kubernetes": { "usages": [ "signing", "key encipherment", "server auth", "client auth" ], "expiry": "87600h" } } } } EOF 生成CA签名配置文件 cat > ca-csr.

介绍 k8s中资源限制分别为requests(需求)和limits(限制) 分类 request: 保留的资源 limit: 最大占用的资源 查看pod内容器的资源限制 kubectl get pods --namespace=test test -o template --template='{{range .spec.containers}}{{.resources}}{{end}}' requests与limit值范围如下： 0 <= requests <= NodeAllocatable requests <= limits <= Infinity 根据request与limit的比较大小分为以下三种qos Guaranteed pod中所有容器都必须统一设置limits，并且设置参数都一致，如果有一个容器要设置requests，那么所有容器都要设置，并设置参数同limits一致，那么这个pod的QoS就是Guaranteed级别。 Burstable pod中只要有一个容器的requests和limits的设置不相同，该pod的QoS即为Burstable。 Best-Effort 如果对于全部的resources来说requests与limits均未设置，该pod的QoS即为Best-Effort。 查看qosClass： kubectl get pods --namespace=test test -o template --template='{{.status.qosClass}}' 判断代码如下： if len(requests) == 0 && len(limits) == 0 { return v1.PodQOSBestEffort } // Check is requests match limits for all resources.