本文目录：
- 1、Docker+ Kubernetes已成为云计算的主流（二十六）
- 2、腾讯云网络适配器设置为监听模式
- 3、安装 gitlab ee
- 4、腾讯云负载均衡支持HTTPS吗
- 5、Istio 中实现客户端源 IP 的保持
- 6、使用ELK分析腾讯云CLB日志
Docker+ Kubernetes已成为云计算的主流（二十六）
最近正在抽时间编写k8s的相关教程，很是费时，等相关内容初步完成后，再和大家分享。对于k8s，还是上云更为简单、稳定并且节省成本，因此我们需要对主流云服务的容器服务进行了解，以便更好地应用于生产。
主流云服务容器服务介绍
Docker+ Kubernetes已成为云计算的主流
亚马逊AWS
Amazon Web Services (AWS) 是亚马逊公司旗下云计算服务平台，为全世界范围内的客户提供云解决方案。AWS面向用户提供包括弹性计算、存储、数据库、应用程序在内的一整套云计算服务，帮助企业降低IT投入成本和维护成本。
那么如何在AWS上运行Docker呢？AWS 同时为 Docker 开源解决方案和商业解决方案提供支持，并且可通过多种方式在 AWS 上运行容器：
微软Azure
Microsoft Azure 是一个开放而灵活的企业级云计算平台。通过 IaaS + PaaS 帮助用户加快发展步伐，提高工作效率并节省运营成本。
Azure是一种灵活和支持互操作的平台，它可以被用来创建云中运行的应用或者通过基于云的特性来加强现有应用。它开放式的架构给开发者提供了Web应用、互联设备的应用、个人电脑、服务器、或者提供最优在线复杂解决方案的选择。
在容器这块，Azure同样的提供了众多解决方案：
下面我们侧重介绍下以下服务：
阿里云
阿里云（）创立于2009年，是全球领先的云计算及人工智能 科技 公司，为200多个国家和地区的企业、开发者和政府机构提供服务。2017年1月阿里云成为奥运会全球指定云服务商。2017年8月阿里巴巴财报数据显示，阿里云付费云计算用户超过100万。阿里云致力于以在线公共服务的方式，提供安全、可靠的计算和数据处理能力，让计算和人工智能成为普惠 科技 。阿里云在全球18个地域开放了49个可用区，为全球数十亿用户提供可靠的计算支持。此外，阿里云为全球客户部署200多个飞天数据中心，通过底层统一的飞天操作系统，为客户提供全球独有的混合云体验。
飞天（Apsara）是由阿里云自主研发、服务全球的超大规模通用计算操作系统。 它可以将遍布全球的百万级服务器连成一台超级计算机，以在线公共服务的方式为 社会 提供计算能力。 从PC互联网到移动互联网到万物互联网，互联网成为世界新的基础设施。飞天希望解决人类计算的规模、效率和安全问题。飞天的革命性在于将云计算的三个方向整合起来：提供足够强大的计算能力，提供通用的计算能力，提供普惠的计算能力。飞天诞生于2009年2月，目前为全球200多个国家和地区的创新创业企业、政府、机构等提供服务。
同样，阿里云对容器也提供了友好的支持：
容器服务提供高性能可伸缩的容器应用管理服务，支持用Docker和Kubernetes进行容器化应用的生命周期管理，提供多种应用发布方式和持续交付能力并支持微服务架构。容器服务简化了容器管理集群的搭建工作，整合了阿里云虚拟化、存储、网络和安全能力，打造云端最佳容器运行环境。
容器服务 Kubernetes 版（简称 ACK）提供高性能可伸缩的容器应用管理能力，支持企业级 Kubernetes 容器化应用的全生命周期管理。容器服务 Kubernetes 版简化集群的搭建和扩容等工作，整合阿里云虚拟化、存储、网络和安全能力，打造云端最佳的 Kubernetes 容器化应用运行环境。
阿里云弹性容器实例（Elastic Container Instance）是 Serverless 和容器化的弹性计算服务。用户无需管理底层 ECS 服务器，只需要提供打包好的镜像，即可运行容器，并仅为容器实际运行消耗的资源付费。
容器镜像服务（Container Registry）提供安全的镜像托管能力，稳定的国内外镜像构建服务，便捷的镜像授权功能，方便用户进行镜像全生命周期管理。容器镜像服务简化了Registry的搭建运维工作，支持多地域的镜像托管，并联合容器服务等云产品，为用户打造云上使用Docker的一体化体验。
腾讯云
腾讯云为腾讯倾力打造的云计算品牌，以卓越 科技 能力助力各行各业数字化转型，为全球客户提供领先的云计算、大数据、人工智能服务，以及定制化行业解决方案。其基于QQ、微信、腾讯 游戏 等海量业务的技术锤炼，从基础架构到精细化运营，从平台实力到生态能力建设，腾讯云将之整合并面向市场，使之能够为企业和创业者提供集云计算、云数据、云运营于一体的云端服务体验。
在容器这块，腾讯云提供了如下解决方案：
腾讯云容器服务（Tencent Kubernetes Engine ，TKE）基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务。腾讯云容器服务完全兼容原生 kubernetes API ，扩展了腾讯云的 CBS、CLB 等 kubernetes 插件，为容器化的应用提供高效部署、资源调度、服务发现和动态伸缩等一系列完整功能，解决用户开发、测试及运维过程的环境一致性问题，提高了大规模容器集群管理的便捷性，帮助用户降低成本，提高效率。容器服务提供免费使用，涉及的其他云产品另外单独计费。
容器实例服务（Container Instance Service , CIS）可以帮用户在云上快捷、灵活的部署容器，让用户专注于构建程序和使用容器而非管理设备上。无需预购 CVM（云服务器），就可以在几秒内启动一批容器来执行任务。同时，开发者也可以通过 kubernetes API 把已有kubernetes 集群的 pod 调度到 CIS 上以处理突增业务。CIS 根据实际使用的资源计费，可以帮用户节约计算成本。使用 CIS 可以极大降低用户部署容器的门槛，降低用户执行 batch 型任务或处理业务突增的成本。
从上面主流的云服务中我们可以看到，没有哪家云厂商不支持Docker，同样的，也没有哪家云厂商不支持Kubernetes！也就是说，Docker+ Kubernetes已经成为云计算的主流！
什么是Kubernetes（k8s）
Kubernetes（简称k8s）诞生于谷歌，是一个开源的，用于管理云平台中多个主机上的容器化的应用，k8s的目标是让部署容器化的应用简单并且高效，其提供了应用部署、规划、更新、维护的机制。
k8s主要有以下特点：
支持公有云，私有云，混合云，多重云（multi-cloud） 。可以将容器化的工作负载从本地开发计算机无缝移动到生产环境。在本地基础结构以及公共云和混合云中，在不同环境中协调容器，保持一致性。
支持模块化，插件化，可挂载，可组合。并且k8s的扩展和插件在社区开发者和各大公司的支持下高速增长，用户可以充分利用这些社区产品/服务以添加各种功能。
支持自动部署，自动重启，自动复制，自动伸缩/扩展，并且可以定义复杂的容器化应用程序并将其部署在服务器群集甚至多个群集上——因为k8s会根据所需状态优化资源。通过内置的自动缩放器，k8s可轻松地水平缩放应用程序，同时自动监视和维护容器的正常运行。
Kubernetes正在塑造应用程序开发和管理的未来
k8s构建于 Google 数十年经验，一大半来源于 Google 生产环境规模的经验。结合了社区最佳的想法和实践，而且还在不断地高速迭代和更新之中。
她衔着金钥匙出生，一诞生就广受欢迎，更是在2017，其打败了所有的竞争对手，赢得了云计算的战争——主流的云厂商基本上都纷纷放弃了自己造“轮子”的举动，终止了各自的容器编排工具，加盟了k8s阵营，其中包括Red Hat、微软、IBM、阿里、腾讯、华为和甲骨文等。
k8s像风暴一样席卷了应用开发领域，并且已成为云原生应用程序（架构、组件、部署和管理方式）的事实标准，大量的开发者和企业正在使用k8s创建由微服务和无服务器功能组成的现代架构。
Docker+ Kubernetes已成为云计算的主流
容器是现代软件交付的未来，而Kubernetes是编排容器的最佳方案（事实上的标准）。
Docker 和Kubernetes相辅相成，联手打下了云计算的“万里江山”。Docker 为打包和分发容器化应用程序提供了一个开放的标准，而 Kubernetes 则协调和管理通过 Docker 创建的分布式容器化应用程序。换句话说，Kubernetes 提供了部署和运行通过Docker生成的应用程序所需的基础结构。
在主流的云服务，基于Docker+k8s的新型PaaS平台具有敏捷部署、弹性伸缩、灵活调度、故障自动恢复等优势，充分满足业务扩展中的资源支持，因此在短短两年之内，便从Docker Swarm、Cloud Foundry Diego、Kontena、Apache Mesos、Amazon ECS…等大量对手中脱颖而出，拿下了皇冠。
k8s和Docker的胜利意味着这是有史以来第一次，无论使用哪一种云平台，研发人员都可以拥有完全相同的计算环境。
腾讯云网络适配器设置为监听模式
1、登录负载均衡控制台，在左侧导航栏单击实例管理。在CLB实例列表页面左上角选择地域，在实例列表右侧的操作列中单击配置监听器。
2、在HTTP/HTTPS监听器下，单击新建，在弹出的创建监听器对话框中配置HTTP监听器。
3、在监听器管理页面，单击刚才创建的监听器，如上述HTTP:80监听器，单击左侧的+图标展开域名和URL路径，选中具体的URL路径，即可在监听器右侧查看该路径上已绑定的后端服务。单击绑定，在弹出框中选择需绑定的后端服务器，并配置服务端口和权重。
安装 gitlab ee
如下是版本建议
GitLab database必须开启 pg_trgm 扩展。使用PostgreSQL super user 开启扩展 。
有些系统，还需要安装额外的包来支持扩展功能 (for example, postgresql-contrib ) 。
支持如下浏览器:
Install self-managed GitLab
官方强烈建议使用 官方Linux包 安装，更快安装、更易升级， 并且它包含了其他安装方式没有的特性来加强可靠性。强烈 建议最少 4GB 可用内存 运行Gitlab。
基于CentOS7 安装
关闭selinux
关闭firwalld
安装Postfix
这里使用腾讯云CVM+负载均衡CLB+证书。所以不带参数安装，参数手动配置。
可以看到安装文件都部署于/opt/gitlab目录下
配置文件 /etc/gitlab/gitlab.rb
执行 gitlab-ctl reconfigure 使配置生效
也可以添加多个 Git data 目录，配置如下：
手动修改克隆地址后，不能再执行 gitlab-ctl reconfigure。gitlab-ctl reconfigure会使用 /etc/gitlab/gitlab.rb覆盖所有配置。
或者执行gitlab-ctl reconfigure后，再手动配置下也行
修改配置文件/opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml：
在使用 gitlab-ctl reconfigure 命令初始化配置的时候，创建了 gitlab-runsvdir.service
可以使用如下命令启动/停止服务
查看服务状态
第一次登陆，会重定向到重设密码页面。输入初始管理员密码，然后会返回到登陆页面。默认账户root。
See our documentation for detailed instructions on installing and configuration .
After completing your installation, consider the recommended practices to secure your GitLab instance .
腾讯云负载均衡支持HTTPS吗
支持的，申请SSL证书，可以淘宝搜索：Gworg 办理。
腾讯云负载均衡CLB目前支持证书。目前支持服务器证书和CA证书的上传，服务器证书需要上传证书内容和私钥，CA证书只需要上传证书内容；这两种类型的证书都只支持PEM编码格式的上传。
Istio 中实现客户端源 IP 的保持
对于很多后端服务业务，我们都希望得到客户端资源 IP。云上的负载均衡器，比如，腾讯云 CLB 支持将客户端源IP传递到后端服务。但在使用 istio 的时候，由于 istio ingressgateway 以及 sidecar 的存在，后端服务如果需要获取客户端源 IP，特别是四层协议，情况会变得比较复杂。
很多业务场景，我们都希望得到客户端资源 IP。云上负载均衡器，比如，腾讯云 CLB支持将客户端 IP 传递到后端服务。TKE/TCM 也对该能力做了很好的集成。
但在使用 istio 的时候，由于中间链路上，istio ingressgateway 以及 sidecar 的存在，后端服务如果需要获取客户端 IP，特别是四层协议，情况会变得比较复杂。
对于应用服务商来说，它只能看到 Envoy 过来的连接。
先看看一些常见 Loadbalancer/Proxy 的源 IP 保持方法。我们的应用协议一般都是四层、或者七层协议。
七层的客户端源 IP 保持方式比较简单，最具代表性的是 HTTP 头 XFF（X-Forwarded-For） ，XFF 保存原始客户端的源 IP，并透传到后端，应用可以解析 XFF 头，得到客户端的资源 IP。常见的七层代理组件，比如 Nginx、Haproxy，包括 Envoy 都支持该功能。
IPVS/iptables 都支持 DNAT，客户端通过 VIP 访问 LB，请求报文到达 LB 时，LB 根据连接调度算法选择一个后端 Server，将报文的目标地址 VIP 改写成选定 Server 的地址，报文的目标端口改写成选定 Server 的相应端口，最后将修改后的报文发送给选出的 Server。由于 LB 在转发报文时，没有修改报文的来源 IP，所以，后端 Server 可以看到客户端的资源 IP。
Nginx/Haproxy 支持透明代理( Transparent Proxy )。当开启该配置时，LB 与后端服务建立连接时，会将 socket 的源 IP 绑定为客户端的 IP 地址，这里依赖内核TPROXY以及 socket 的 IP_TRANSPARENT 选项。
此外，上面两种方式，后端服务的响应必须经过 LB，再回到 Client，一般还需要策略路由的配合。
TOA( TCP Option Address )是基于四层协议（TCP）获取真实源 IP 的方法，本质是将源 IP 地址插入 TCP 协议的 Options 字段。这需要内核安装对应的TOA内核模块。
Proxy Protocol是 Haproxy 实现的一个四层源地址保留方案。它的原理特别简单，Proxy 在与后端 Server 建立 TCP 连接后，在发送实际应用数据之前，首先发送一个 Proxy Protocol 协议头(包括客户端源 IP/端口、目标IP/端口等信息)。这样，后端 server 通过解析协议头获取真实的客户端源 IP 地址。
Proxy Protocol 需要 Proxy 和 Server 同时支持该协议。但它却可以实现跨多层中间代理保持源 IP。这有点类似七层 XFF 的设计思想。
istio 中，由于 istio ingressgateway 以及 sidecar 的存在，应用要获取客户端源 IP 地址，会变得比较困难。但 Envoy 本身为了支持透明代理，它支持 Proxy Protocol ，再结合 TPROXY，我们可以在 istio 的服务中获取到源 IP。
istio 东西向服务访问时，由于 Sidecar 的注入，所有进出服务的流量均被 Envoy 拦截代理，然后再由 Envoy 将请求转给应用。所以，应用收到的请求的源地址，是 Envoy 访问过来的地址 127.0.0.6 。
可以看到，httpbin 看到的源 IP 是 127.0.0.6 。从 socket 信息，也可以确认这一点。
我们修改 httpbin deployment，使用 TPROXY（注意 httpbin 的 IP 变成了 172.17.0.59 ）:
可以看到，httpbin 可以得到 sleep 端的真实 IP。
socket 的状态：
第一行是 httpbin 的接收端 socket，第二行是 envoy 的发送端 socket。
httpbin envoy 日志：
可以看到，
httpbin envoy 连接 httpbin 的 local address 为 sleep 的 IP 地址。
对于南北向流量，客户端先请求 CLB，CLB 将请求转给 ingressgateway，再转到后端服务，由于中间多了 ingressgateway 一跳，想要获取客户端源 IP，变得更加困难。
我们以 TCP 协议访问 httpbin:
通过 ingressgateway 访问 httpbin：
可以看到，httpbin 看到的地址是 ingressgateway 的地址：
虽然我们在 httpbin envoy 开启了透明代理，但 ingressgateway 并不能把 client 的源地址传到 httpbin envoy 。基于 envoy 实现的 Proxy Protocol ，可以解决这个问题。
通过 EnvoyFilter 在 ingressgateway 和 httpbin 同时开启 Proxy Protocol 支持。
再次通过 LB 访问 httpbin:
httpbin 得到了客户端的源 IP。
可以看到，
可以看到，
值得注意的是， httpbin envoy 的 upstream_local_address 保留了客户端的 IP，这样，httpbin 看到的源地址 IP，就是客户端的真实 IP。
TPROXY 的内核实现参考net/netfilter/xt_TPROXY.c。
istio-iptables 会设置下面的 iptables 规则，给数据报文设置标记。
值得一提的是，TPROXY 不用依赖 NAT，本身就可以实现数据包的重定向。另外，结合策略路由，将非本地的数据包通过本地 lo 路由:
TPROXY 的更多详细介绍参考这里。
这里使用了 Version 1(Human-readable header format) ，如下：
可以看到，header 包括 client 和 ingressgateway 的 IP:PORT 信息。更加详细的介绍参考这里。
ingressgateway 作为发送端，使用 ProxyProtocolUpstreamTransport ，构建 Proxy Protocol 头部:
httpbin envoy 作为接收端，配置ListenerFilter( envoy.filters.listener.proxy_protocol )解析 Proxy Protocol 头部:
这里值得注意的， envoy.filters.listener.proxy_protocol 在解析 proxy protocol header 时， local_address 为发送端的 dst_addr(172.17.0.54:8000) ， remote_address 为发送端的 src_addr(106.52.131.116) 。顺序刚好反过来了。
经过 proxy_protocol 的处理，连接的 downstream_remote_address 被修改为client的源地址。
对于 sidecar.istio.io/interceptionMode: TPROXY ， virtualInbound listener 会增加 envoy.filters.listener.original_src :
envoy.filters.listener.original_src 通过 tcp option 实现修改 upstream_local_address 为 downstream_remote_address ，实现透传client IP。
另外， httbin envoy 作为 ingressgateway 的接收端， virtualInbound listener 还配置了 ListenerFilter( envoy.filters.listener.original_dst )，来看看它的作用。
对于 istio，由 iptable 截持原有 request，并转到15006(in request)，或者15001(out request)端口，所以，处理 request 的 socket 的 local address ，并不请求的 original dst address 。 original_dst ListenerFilter 负责将 socket 的 local address 改为 original dst address 。
对于 virtualOutbound listener ，不会直接添加 envoy.filters.listener.original_dst ，而是将 use_original_dst 设置为 true，然后 envoy 会自动添加 envoy.filters.listener.original_dst 。同时， virtualOutbound listener 会将请求，转给请求原目的地址关联的 listener 进行处理。
对于 virtualInbound listener ，会直接添加 envoy.filters.listener.original_dst 。与 virtualOutbound listener 不同的是，它只是将地址改为 original dst address ，而不会将请求转给对应的 listener 处理（对于入请求，并不存在 dst address 的 listener）。实际上，对于入请求是由 FilterChain 完成处理。
参考 istio 生成 virtualInbound listener 的代码:
基于 TPROXY 以及 Proxy Protocol，我们可以在 istio 中，实现四层协议的客户端源 IP 的保持。
文章来自
使用ELK分析腾讯云CLB日志
最近在使用腾讯云，想对访问日志进行收集与分析，发现CLB（负责均衡）日志只能保存到COS上面，而且是每个CLB没小时压发送个gz压缩包到COS。
CLB配置日志存储到COS，Filebeat客户端CVM安装cosfs挂载COS，并配置Filebeat输出到Elasticsearch集群，最后通过Kibana和Grafana分析。
日志访问：当前仅支持HTTP/HTTPS访问日志的收集，腾讯云默认在CLB底层为客户保留3天的日志；开启日志访问后，日志将存入COS，支持更长期地存储，详情请见 。
安装Filebeat或Logstash客户端上安装COSFS工具，挂载COS，安装参考 。
a. Logstash主要配置信息如下：
b. Nginx模板配置信息如下：
c. Filebeat主配置文件如下：
a. Grafana制图模板如下：
【腾讯云clb】的内容来源于互联网，如引用不当，请联系我们修改。
网友留言：