虚拟侵入

本文所有相关链接pdf： https://tungstenfabric.org.cn/assets/uploads/files/tf-ceg-case-2.pdf Kubernetes的Ingress文档页面将其描述为： “用于管理对集群中服务的外部访问的API对象，通常是HTTP。Ingress可以提供负载均衡、SSL终结和基于名称的虚拟主机。” CNI不提供Ingress功能。这意味着Kubernetes集群管理者通常要为其集群安装、管理和支持单独的Ingress控制器解决方案。 对于没有内置Ingress支持的本地和公共云中的Kubernetes部署，Tungsten Fabric捆绑了自己的Ingress控制器。它在后台使用HAProxy并实现了Kubernetes Ingress文档页面中所述的所有基本功能。 在AWS上运行时，可以将Kubernetes 配置为使用AWS的Application Load Balancer （ALB）为其Ingress服务。通过这种方式的设置，沙箱中的Kubernetes可以最紧密地反映典型的现实部署场景。 下图概述了示例应用程序的最终部署架构： 使用场景 Ingress控制器选项仅与使用HTTP或HTTPS的应用程序兼容。如果您的应用程序是这种情况，可能需要考虑使用Ingress来实现以下目标： 使用HTTPS保护应用程序

kubernetes Ingess 是有2部分组成，Ingress Controller 和Ingress服务组成，常用的Ingress Controller 是ingress-nginx，工作的原理是： Ingress Controller 会动态感知集群中的Ingress的规则变化，然后读取，动态生成Nginx的配置文件，最后注入到运行nginx的pod的中，然后会自动reload，配置生效。 用kubernetes Ingress 是由于它是7层调度，可以直接卸载https会话，代理的后端的pod可以直接使用明文的http协议。 而Service NodePort得类型，是4层得调度，做不到这点，然而现在https是一种趋势，所以在kubernetes 对外暴露服务得时候我们还是要选择Ingress。 下面我们来看下Ingress得部署： 原理图 1.创建后端容器和service 首先创建一个文件夹专门放置Igress得yaml得文件，mkdir ingress vim myapp.yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp spec: replicas: 3 selector: matchLabels: app: myapp template: metadata: labels: app:

同一k8s集群中多nginx ingress controller 同一k8s集群中，若有多个项目（对应多个namespace）共用一个nginx ingress controller，因此任意注册到ingress的服务有变更都会导致controller配置重载，当更新频率越来越高时，此controller压力会越来越大，理想的解决方案就是每个namespace对应一个nginx ingress controller，各司其职。 NGINX ingress controller提供了ingress.class参数来实现多ingress功能 使用示例 如果你已配置好多个nginx ingress controller，则可在创建ingress时在annotations中指定使用ingress.class为nginx（示例）的controller： metadata: name: foo annotations: kubernetes.io/ingress.class: "nginx" 注意：将annotation设置为与有效ingress class不匹配的任何值将强制controller忽略你的ingress。 如果你只运行单个controller，同样annotation设置为除此ingress class或空字符串之外的任何值也会被controller忽略。 配置多个nginx

源文件： https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.26.2/deploy/static/mandatory.yaml 可以通过wget下载后作修改！ 主要改动： hostNetwork: true bitnami/nginx-ingress-controller:0.26.2 apiVersion: v1 kind: Namespace metadata: name: ingress-nginx labels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx --- kind: ConfigMap apiVersion: v1 metadata: name: nginx-configuration namespace: ingress-nginx labels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx --- kind: ConfigMap apiVersion: v1 metadata: name: tcp-services namespace: ingress

写在前面 上一篇文章中介绍了基于Nginx实现Ingress Controller的实现，介绍了Nginx Ingress Controller安装、相关功能，TLS，高级特性等介绍，本章开始介绍基于腾讯云TKE实现ingress服务暴露。 1. TKE ingress 1.1 TKE ingress架构 TKE是Tencent Kubernetes Engine即腾讯云基于kubernetes提供的公有云上容器云服务，TKE提供了两种暴露服务的方式：service和ingress。 内网CLB，四层负载均衡，提供VPC内访问，通过node节点的NodePort转发至service； 外网CLB，四层负载均衡，提供公网访问，需要node节点具有访问公网的能力； ingress， 七层负载均衡，提供http和https接入，提供ingress控制器的功能，借助NodePort转发 要使用TKE的ingress功能，需要了解一下相关的组件内容： l7-lb-controller ingress客户端，安装在kube-system，用于解析ingress配置并更新CLB的规则 CLB 七层负载均衡，提供ingress controller的功能，根据ingress规则创建http/https监听器，配置转发规则，以NodePort端口绑定后端RS Service

注：本文使用的Traefik为1.x的版本 在生产环境中，我们常常需要控制来自互联网的外部进入集群中，而这恰巧是Ingress的职责。 Ingress的主要目的是将HTTP和HTTPS从集群外部暴露给该集群中运行的服务。这与Ingress控制如何将外部流量路由到集群有异曲同工之妙。接下来，我们举一个实际的例子来更清楚的说明Ingress的概念。 首先，想象一下在你的Kubernetes集群中有若干个微服务（小型应用程序之间彼此通信）。这些服务能够在集群内部被访问，但我们想让我们的用户从集群外部也能够访问它们。因此，我们需要做的是使用反向代理将每个HTTP（S）（例如， service.yourdomain.com ）路由与相应的后端关联，并在该服务的不同实例之间（如，pod）进行负载均衡。与此同时，由于Kubernetes的性质会不断发生变化，因此我们希望跟踪服务后端的更改，以便能够在添加或删除新Pod时将这些HTTP路由重新关联到新Pod实例。 使用Ingress资源和关联的Ingress Controller，你可以实现以下目标： 将你的域 app.domain.com 指向你的私有网络中的微服务应用程序 将路径 domain.com/web 指向你的私有网络中的微服务web 将你的域 backend.domain.com 指向你的私有网络中的微服务后端

注：本文使用的Traefik为1.x的版本 在生产环境中，我们常常需要控制来自互联网的外部进入集群中，而这恰巧是Ingress的职责。 Ingress的主要目的是将HTTP和HTTPS从集群外部暴露给该集群中运行的服务。这与Ingress控制如何将外部流量路由到集群有异曲同工之妙。接下来，我们举一个实际的例子来更清楚的说明Ingress的概念。 首先，想象一下在你的Kubernetes集群中有若干个微服务（小型应用程序之间彼此通信）。这些服务能够在集群内部被访问，但我们想让我们的用户从集群外部也能够访问它们。因此，我们需要做的是使用反向代理将每个HTTP（S）（例如， service.yourdomain.com ）路由与相应的后端关联，并在该服务的不同实例之间（如，pod）进行负载均衡。与此同时，由于Kubernetes的性质会不断发生变化，因此我们希望跟踪服务后端的更改，以便能够在添加或删除新Pod时将这些HTTP路由重新关联到新Pod实例。 使用Ingress资源和关联的Ingress Controller，你可以实现以下目标： 将你的域 app.domain.com 指向你的私有网络中的微服务应用程序 将路径 domain.com/web 指向你的私有网络中的微服务web 将你的域 backend.domain.com 指向你的私有网络中的微服务后端

GitHub: Helm Chart for Harbor 1. 添加harbor的helm库 helm repo add harbor https://helm.goharbor.io 2. 将harbor下载到本地 helm fetch harbor/harbor tar xf harbor-1.1.1.tgz 3. 自定义配置 默认的values.yaml基本不需要多大改动，只有极个别的需要自定义修改 具体改什么需要根据自动需求，可以查看GitHub上面的配置列表 configuration 根据自己的特殊需求创建一个新的values文件，覆盖掉之前的值 cat new-values.yaml expose: type: ingress tls: enabled: true ingress: hosts: core: harbor.mytest.io notary: notary.mytest.io externalURL: https://harbor.mytest.io persistence: enabled: true resourcePolicy: "keep" persistentVolumeClaim: registry: storageClass: "harbor-data" chartmuseum: storageClass: "harbor-data"

常见的CNI网络插件包含以下几种： Flannel：为Kubernetes提供叠加网络的网络插件，基于TUN/TAP隧道技术，使用UDP封装IP报文进行创建叠 加网络，借助etcd维护网络的分配情况，缺点：无法支持网络策略访问控制。 Calico：基于BGP的三层网络插件，也支持网络策略进而实现网络的访问控制；它在每台主机上都运行一个虚拟路由，利用Linux内核转发网络数据包，并借助iptables实现防火墙功能。实际上Calico最后的实现就是将每台主机都变成了一台路由器，将各个网络进行连接起来，实现跨主机通信的功能。 Canal：由Flannel和Calico联合发布的一个统一网络插件，提供CNI网络插件，并支持网络策略实现。 其他的还包括Weave Net、Contiv、OpenContrail、Romana、NSX-T、kube-router等等。而Flannel和Calico是目前最流行的选择方案。 1.全部拒绝 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all-egress namespace: cs1 #应用于cs1 名称空间，不写名称空间对default应用 spec: podSelector: {} ingress: egress: #定义出站规则

ingress HTTPS代理访问： 创建证书，以及cert存储方式: openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginxsvc/O=nginxsvc" kubectl create secret tls tls-secret --key tls.key --cert tls.crt deployment3.yaml apiVersion: extensions/v1beta1 kind: Deployment metadata: name: deployment-3 spec: replicas: 2 template: metadata: labels: name: nginx3 spec: containers: - name: nginx image: nginx:v1 imagePullPolicy: IfNotPresent ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: svc-3 spec: ports: - port: 80 targetPort: 80 protocol: TCP selector: