代理、api网关与servicemesh

十二月 20, 2017 发布在 servicemesh

代理

四层

lvs
haproxy
F5

四层代理基于ip+port的负载均衡，功能:

全流量转发（mysql、redis等）

优势：

性能好，资源消耗低
应用广泛
配置项较少（也是劣势）

劣势： - 可配置化程度低

七层

nginx
haproxy
Træfik

七层代理现在主要应用于HTTP协议，功能:

请求链接的负载均衡.
智能请求路由。
防御攻击（syn攻击）。

优势：

匹配规则灵活
对网络稳定性依赖较小
配置灵活

能用七层不用四层，七层可定制化程度高。

api网关

kong
orange
openresty
zuul

功能：

服务发现
负载均衡
请求路由熔断
身份认证
熔断
流量管控
链路跟踪
监控

缺陷：

维护复杂的路由逻辑

service mesh

服务网格分为控制面板和数据面板

控制面板

linkerd
envoy
conduit-proxy

数据面板

conduit
istio
contour (基于envoy)

相对于apigateway优势

集成服务发现
分布式系统，解耦，控制面板负责管理配置，数据面板根据配置进行相应的动作，上报状态到数据面板进行展示。
sidecar模式,精确获取应用的详细信息，不受其他服务影响.
集中化配置，统一管理，相当于代理层的配置中心。

最终的目标：

应用部署层all in k8s,应用逻辑层all in servicemesh.

欢迎加入QQ群：k8s开发与实践（482956822）一起交流k8s技术

作者的图片

tianpeng du

All in k8s,All in servicemesh

devops

BeiJing

Meta Controller

Jun 6, 2019

简介 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.

如何实现自己的k8s调度器

Mar 3, 2018

调度器介绍 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 '.

Hpa With Prom by Resource Metrics Api

Mar 3, 2018

核心指标管道从 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.

自定义k8s存储插件

Mar 3, 2018

从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毫秒(代码),

User Define Kubectl Plugin

Mar 3, 2018

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 目录。在大多数情况下，就是 ~/.

管理pod的nat策略

Mar 3, 2018

关闭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.

使用ES作为监控系统后端存储

Jan 1, 2018

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

k8s使用calico网络

Jan 1, 2018

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证书的三种方式

Dec 12, 2017

生成证书根据官方文档，生成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.

kubernetes中的Resource QoS

Dec 12, 2017

介绍 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.