这篇文章使用fluentd官方提供的kubernetes部署方案daemonset来部署日志收集, 参考项目地址:

• https://github.com/fluent/fluentd-kubernetes-daemonset

本文使用的kubernetes版本为: 1.22.8

使用fluentd镜像为: fluent/fluentd-kubernetes-daemonset:v1.15.2-debian-kafka2-1.0

请注意下文配置中<var>标记, 需要根据需求自行替换.

创建命名空间 #

本项目所有的资源创建在logging下, 先创建它:

1

kubectl create ns fluentd-kafka

先创建服务账号 #

创建服务账号并赋予集群查看的权限, 使用下面的命令:

这篇文章使用fluentd官方提供的kubernetes部署方案daemonset来部署日志收集, 参考项目地址:

• https://github.com/fluent/fluentd-kubernetes-daemonset

本文使用的kubernetes版本为: 1.22.8

使用fluentd镜像为: fluent/fluentd-kubernetes-daemonset:v1.15.2-debian-elasticsearch7-1.0

请注意下文配置中<var>标记, 需要根据需求自行替换.

创建命名空间 #

本项目所有的资源创建在logging下, 先创建它:

1
2

NAMESPACE=logging
kubectl create ns $NAMESPACE

先创建服务账号 #

创建服务账号并赋予集群查看的权限, 使用下面的命令:

Envoy静态配置 #

L4转发 #

下面的例子是配置4层转发, 将443端口的流量都代理到www.example.com对应的后端的443端口上, 如下:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

static_resources:

  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 443
    filter_chains:
    - filters:
      - name: envoy.filters.network.tcp_proxy
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy
          stat_prefix: tcp_443
          cluster: cluster_0

  clusters:
  - name: cluster_0
    type: LOGICAL_DNS
    dns_lookup_family: V4_ONLY
    load_assignment:
      cluster_name: cluster_0
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: www.example.com
                port_value: 443

启动Envoy #

将创建的静态配置文件envoy-custom.yaml映射到容器内部, 启动:

rsync安装 #

在传输双方的服务器上都安装rsync软件. 如果服务器上有rsync可以跳过.

先检查有没有安装rsync:

1

rsync -h

如果没有安装, 使用下面的命令安装:

1
2
3
4
5
6
7
8

# Debian
sudo apt-get install rsync

# Red Hat
sudo yum install rsync

# Arch Linux
sudo pacman -S rsync

启动rsync守护进程 #

rsync使用最多的是ssh模式. 在现代的公司中, 出于安全的原因, 很多ssh是被禁止使用的. 所以, 我们可以使用rsync的守护进程模式. 一起看看怎么用吧.

因为etcd中的内容都是加密的, 使用下面的命令安装解密工具:

1
2
3
4
5
6

mkdir auger
curl -o ./auger/auger_1.0.2_linux_amd64.tar.gz \
  https://llaoj.oss-cn-beijing.aliyuncs.com/files/github.com/etcd-io/auger/releases/download/v1.0.2/auger_1.0.2_linux_amd64.tar.gz
tar -xvf ./auger/auger_1.0.2_linux_amd64.tar.gz -C ./auger
mv ./auger/auger /usr/local/bin/
rm -rf ./auger

下面这个脚本提供了etcdctl连接etcd所需要的端点、证书相关的信息. 这个脚本需要在master节点上执行:

MetalLB概念安装配置和使用请查看

测试组件的版本情况 #

• kubernetes: v1.22.8
• metellb: v0.10.3
• nginx: latest

创建测试应用 #

创建一个nginx服务和service资源:

1

kubectl -n without-istio create deploy nginx --image=nginx

测试分配IP #

创建loadbalancer类型的service:

nginx反向代理的请求, 和我们直接请求有一定的区别, 比如:

http version #

nginx proxy 发出的反向代理请求的http version默认是: 1.0, 但是istio支持1.1 & 2.0, 所以如果不增加http版本限制的话istio就无法进行报文解析, 也就无法应用istio-proxy(sidecar)L7层代理策略, 我们知道istio流量治理是基于L7层的.

http header: Host #

有时候nginx发出的代理请求的http header中host的值, 不能保证是上游服务的host name. 在这种情况下, 是没办法匹配上游服务在istio-proxy中的L7流量治理的配置.

新建集群的第一步就是要规划服务器、网络、操作系统等等, 下面就结合我平时的工作经验总结下相关的要求, 内容根据日常工作持续补充完善:

服务器配置 #

kubernetes 集群分为控制节点和数据节点, 它们对于配置的要求有所不同:

控制面 #

系统盘40+Gi，用于储存 etcd 信息及相关配置文件等

官方文档

为什么使用? #

Kubernetes没有提供适用于裸金属集群的网络负载均衡器实现, 也就是LoadBalancer类型的Service. Kubernetes 附带的网络负载均衡器的实现都是调用各种 IaaS 平台（GCP、AWS、Azure ……）的胶水代码。 如果您没有在受支持的 IaaS 平台（GCP、AWS、Azure…）上运行，LoadBalancers 在创建时将一直保持在pending状态。

裸金属集群的运维人员只剩下两个方式来将用户流量引入集群内: NodePort和externalIPs. 这两种在生产环境使用有很大的缺点, 这样, 裸金属集群也就成了 Kubernetes 生态中的第二类选择, 并不是首选.

MetalLB 的目的是实现一个网络负载均衡器来与标准的网络设备集成, 这样这些外部服务就能尽可能的正常工作了.