虚拟侵入

Kubernetes 调试 deployment 的思路原文： https://learnk8s.io/troubleshooting-deployments 1、组件匹配规则 当你希望在Kubernetes中部署一个应用程序，你通常需要定义三个组件： Deployment——这是创建名为Pods的应用程序副本的方法 Serivce——内部负载均衡器，将流量路由到Pods Ingress——可以描述流量如何从集群外部流向Service 在Kubernetes中，你的应用程序通过两层负载均衡器暴露：内部和外部。内部负载均衡器称为Service，而外部负载均衡器则称为Ingress。 端口和标签需要匹配规则： Service selector应该匹配Pod的标签 Service targerPort应该匹配在Pod内容器的containerPort Service 端口可以是任意数字。多个Service可以使用同个端口，因为它们已经分配了不同的IP地址 Ingress的servicePort应该匹配在Service中的port Service的名称应该匹配在Ingress中的serviceName的字段 假设你想部署一个简单的Hello World应用程序，那么对于此类应用程序，其YAML文件与以下类似： apiVersion: apps/v1 kind: Deployment

1 我们现在怎么做的 基于docker容器技术，我们K8s进行容器编排和调度管理。利用ingress controller进行负载均衡，主要是nginx。 最早以前，我们自己实现的服务发现，是新增的服务去报活，发送消息，nginx接受到消息后更新配置文件，后来我们利用consul去实现服务发现。 现在ingress controller帮我们实现了负载均衡和动态服务发现。负责监听pod资源变化。 Ingress controller 通过不断地与 kube-apiserver 打交道，实时的感知后端 service、pod 的变化，当得到这些变化信息后，Ingress controller 再结合 Ingress 的配置，更新反向代理负载均衡器，达到服务发现的作用。其实这点和服务发现工具 consul consul-template 非常类似 2 Service mesh怎么做 Service mesh 其实把服务之前的通讯层剥离处理，我们只是负责处理业务逻辑 Hytrix类似这种lib在处理服务降级之类的任务时，如果服务语言不同，无法使用 如果服务数量巨大，servcie mesh可以通过面板统一管理，调度 Hytrix可以参考这个文章的具体demo https://blog.csdn.net/JinXYan/article/details/90598216 来源： CSDN

该文为《深入浅出Docker》的学习笔记，感谢查看，如有错误，欢迎指正 一、基础理论 Docker 网络架构由3个主要部分构成： 容器网络模型（Container Network Model，CNM） Libnetwork 驱动 1.1 容器网络模型（CNM） CNM是设计标准，定义了3个基本要素： 沙盒（Sandbox） ， 终端（Endpoint） ， 网络（Network） 沙盒是一个独立的网络栈，包括 以太网接口 ， 端口 ， 路由表 ， DNS配置 ； 终端是虚拟网络接口，负责创建连接，在CNM中，负责将沙盒连接到网络，一个终端只能连接到某一个网络，如果容器需要加入网络，就需要多个终端； 网络是802.1d网桥的软件实现，网络是需要交互的终端的集合,并且终端之间相互独立。 1.2 Libnetwork Libnetwork是标准的实现，除了实现了CNM中的3个基本要素外，还实现了 本地服务发现（Service Discovery） ， 基于Ingress的容器负载均衡 ， 网络控制层和管理层功能 。 1.3 驱动 如果说Libnetwork实现了控制层和管理层，那么驱动就负责实现 数据层 。 Docker封装了若干内置驱动，通常被称为原生驱动或者本地驱动。在Linux中包括 Bridge ， Overlay ， Macvlan ，在Windows中包括 NAT ，

作者：漠然，原文发布于2017年3月4日， 原文链接 一、Ingress 介绍 Kubernetes 暴露服务的方式目前只有三种：LoadBlancer Service、NodePort Service、Ingress；前两种估计都应该很熟悉，具体的可以参考下 这篇文章 ；下面详细的唠一下这个 Ingress 。 1.1、Ingress 是个什么玩意 可能从大致印象上 Ingress 就是能利用 Nginx、Haproxy 啥的负载均衡器暴露集群内服务的工具；那么问题来了，集群内服务想要暴露出去面临着几个问题： 1.2、Pod 漂移问题 众所周知 Kubernetes 具有强大的副本控制能力，能保证在任意副本(Pod)挂掉时自动从其他机器启动一个新的，还可以动态扩容等，总之一句话，这个 Pod 可能在任何时刻出现在任何节点上，也可能在任何时刻死在任何节点上；那么自然随着 Pod 的创建和销毁，Pod IP 肯定会动态变化；那么如何把这个动态的 Pod IP 暴露出去？这里借助于 Kubernetes 的 Service 机制，Service 可以以标签的形式选定一组带有指定标签的 Pod，并监控和自动负载他们的 Pod IP，那么我们向外暴露只暴露 Service IP 就行了；这就是 NodePort 模式：即在每个节点上开起一个端口，然后转发到内部 Pod IP 上，如下图所示

socket.io 多实例间通信 在实际工程中不会只用一个node实例，用户多的时候会需要开多个node实例。这些实例间的通信可以用redis适配器来实现，socket.io官方有个现有的封装 socket.io-redis ，它是利用redis的发布订阅模式来实现的，使用示例如下： const redisAdapter = require('socket.io-redis'); var redis_config = { host: ’127.0.0.1‘, port: 3306, password:'abc' }; io.adapter(redisAdapter(redis_config)); 加载Redis适配器后就可以直接使用io对象了，和单实例的使用方式是一致的。 在k8s Ingress下使用socket.io socket.io官方的例子 是直接利用nginx来实现： http { server { listen 3000; server_name io.yourhost.com; location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; proxy_pass http://nodes; # enable

基础服务ingress-nginx 接着上面阿里云上的kubernetes集群，一步步搭建服务 创建一个hostNetwork网络模式的ingress-nginx 暴露hostport hostport 比桥接模式 效率高 并且没有网络转发，在任何一个节点都可以访问。nodeport会有网络转发，因为不知道在哪个节点，会多一次转发。 首先需要添加labels kubectl label node k8s-op-n03 app = ingress mandatory.yaml --- apiVersion : v1 kind : Namespace metadata : name : ingress - nginx --- apiVersion : extensions/v1beta1 kind : Deployment metadata : name : default - http - backend labels : app.kubernetes.io/name : default - http - backend app.kubernetes.io/part-of : ingress - nginx namespace : ingress - nginx spec : replicas : 1 selector : matchLabels : app.kubernetes

理解k8s 的 Ingress https://www.jianshu.com/p/189fab1845c5/ 暴露一个http服务的方式 service 是 k8s 暴露http服务的默认方式， 其中 NodePort 类型可以将http 服务暴露在宿主机的端口上，以便外部可以访问。 service模式的结构如下. service -> label selector -> pods 31217 -> app1 selector -> app1 1234 31218 -> app2 selector -> app2 3456 31218 -> app2 selector -> app2 4567 模式的优点 结构简单， 容易理解。 模式缺点 一个app 需要占用一个主机端口 端口缺乏管理 L4转发， 无法根据http header 和 path 进行路由转发 Ingress 模式 在service 之前加了一层ingress，结构如下 ingress -> service -> label selector -> pods www.app1.com -> app1-service -> app1 selector -> app1 1234 80 -> www.app2.com -> app2-service -> app2 selector -> app2 3456 www

问题 线上某平台，通过Jenkins的API查询流水线的执行历史记录时，报错414. 排查 1.jenkins的访问，使用的为ingress的访问方式，414的返回码，可能是jenkins本身返回，也可能是ingress-controller返回（使用的为nginx-ingress-controller,版本为0.26.1）。于是同时对ingress-controller和jenkins的pod抓包，定位414返回码为ingress-controller返回（同时刻jenkins的pod未抓取到414的返回码），同时在nginx-ingress-controller的日志也显示414的错误；判定调用jenkins的API时，请求到nginx-ingress-controller时就被中止了。 如上图，在ingress-controller的上面抓包的414错误 2.排查Request—URI Too Large，为请求头参数过长的错误，解决办法为加大client_header_buffer_size 和large_client_header_buffers的配置。于是修改jenkins对应的ingress的annotation部分，检查nginx-ingress-controller的对应server段配置文件，配置已经生效。 3.在nginx-ingress

一、概述 Ingress Ingress 是 Kubernetes 的一种 API 对象，将集群内部的 Service 通过 HTTP/HTTPS 方式暴露到集群外部，并通过规则定义 HTTP/HTTPS 的路由。Ingress 具备如下特性：集群外部可访问的 URL、负载均衡、SSL Termination、按域名路由（name-based virtual hosting）。 Ingress Controller （通常需要负载均衡器配合）负责实现 Ingress API 对象所声明的能力。如下图所示： Ingress Controller 监听所有 worker 节点上的 80/443 端口 Ingress Controller 将所有对域名为 a.kuboard.cn 的 HTTP/HTTPS 请求路由到 Service B 的 9080 端口 Service B 将请求进一步转发到其标签所选择的 Pod 容器组（通过 targetPort 指定容器组上的端口号） 该图中，请求被转发的过程为： 假设您将 a.kuboard.cn 的 DNS 解析到了集群中的一个 worker 节点的 IP 地址 192.168.2.69 。（如果您的 worker 节点有外网地址，请使用外网地址，这样您可以从外网访问您的服务） 从客户端机器执行命令 curl http://a.kuboard

K8S的ingress 如果使用的是nginx的话，默认是没有隐藏nginx版本号的，我们可以通过在ingress的configmap中修改它的默认值，方法如下 $ vi configmap.yaml apiVersion: v1 data: server-tokens: "false" kind: ConfigMap metadata: name: nginx-configuration namespace: ingress-nginx 保存文件后应用这个yaml文件 $kubectl apply -f configmap.yaml data 里面可以配置的的参数列表： https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/configmap.md 来源： CSDN 作者： 一直学下去 链接： https://blog.csdn.net/lwlfox/article/details/103986918