柏理
柏理_个人页
柏理
文章
7
问答
0
视频
0
个人介绍
暂无个人介绍
擅长的技术
- Java
- Linux
- 数据库
-
发表了文章 2021-02-26
如何在 Java 镜像构建过程中免重复下载依赖包
近来收到一些反馈：使用 maven 编译 Java 工程，如何保留本地 repository 缓存，避免每次构建都重新下载所有依赖包，毕竟这很耗时。实际上，构建工具（docker/buildkit 等）在构建过程中是没办法直接挂载本地目录到系统的，所以构建系统也没办法通过为用户创建缓存来复用依赖包。但是，可以利用容器镜像构建缓存机制来复用 Java 依赖包缓存。原始 Dockerfile以一个 Java Hello World 工程为例，Dockerfile 内定义了一个两阶段构建，首次构建耗时 110s，且后续构建也无法利用前次已经下载依赖包缓存。# First stage: complete build environment FROM maven:3.5.0-jdk-8-alpine AS builder # add pom.xml and source code ADD ./pom.xml pom.xml ADD ./src src/ # package jar RUN mvn install -Dmaven.test.skip=true From openjdk:8 # copy jar from the first stage COPY --from=builder target/my-app-1.0-SNAPSHOT.jar my-app-1.0-SNAPSHOT.jar EXPOSE 8080 CMD ["java", "-jar", "my-app-1.0-SNAPSHOT.jar"]优化和遇到的问题优化思路是将项目包下载、打包过程划分开，先拷贝工程 pom.xml 并下载所有的依赖包，再拷贝工程源代码并打包项目，下文给了一个改写方案。使用此 Dockerfile 首次构建耗时在 240s，且惊奇的发现两次 mvn install 过程中，第二次依然需要下载所有依赖包，无法复用第一次的结果。更改项目代码，再次构建镜像也没办法利用到前次构建的缓存。# First stage: complete build environment FROM maven:3.5.0-jdk-8-alpine AS builder # download dependencies (no re-download when the source code changes) ADD ./pom.xml pom.xml RUN mvn install ADD ./src src/ # package jar RUN mvn install -Dmaven.test.skip=true From openjdk:8 # copy jar from the first stage COPY --from=builder target/my-app-1.0-SNAPSHOT.jar my-app-1.0-SNAPSHOT.jar EXPOSE 8080 CMD ["java", "-jar", "my-app-1.0-SNAPSHOT.jar"]使用 mvn 下载依赖包的命令有很多，例如：mvn install、dependency:go-offline 等。起初怀疑是 maven 的问题，但是直接在本地运行并进入基础镜像 maven:3.5.0-jdk-8-alpine，手动执行 Dockerfile 内的所有命令，发现第二次执行 mvn install 是可以利用到第一次的依赖包缓存的。mvn install 命令默认将依赖包下载到 ~/.m2 目录（即镜像内的 /root/.m2）下，而对于 Dockerfile 内的每个 RUN ，构建工具都会启动新容器来执行命令，生成新的镜像层。猜测是启动容器时 /root/.m2 目录被清理了，所以才导致缓存失效，这应该与基础镜像 maven:3.5.0-jdk-8-alpine 有关。查看 maven:3.5.0-jdk-8-alpine 的镜像配置，发现 /root/.m2 目录被定义成 Volume 了。查看官方文档中对 Volume 的说明可以知道在构建过程中，所有被写入卷目录的内容在后续构建过程中都会被清理，这也就是缓存无法被利用到的原因。最终版本为了避开默认 /root/.m2 目录，使用 -Dmaven.repo.local 来显示指定本地 maven 仓库目录。首次构建耗时 115s，后续构建耗时在 10s 左右，复用了依赖包缓存，耗时降低了 91%。# First stage: complete build environment FROM maven:3.5.0-jdk-8-alpine AS builder # To resolve dependencies in a safe way (no re-download when the source code changes) ADD ./pom.xml pom.xml RUN mvn install -Dmaven.repo.local=./.m2 ADD ./src src/ # package jar RUN mvn -Dmaven.repo.local=./.m2 install -Dmaven.test.skip=true From openjdk:8 # copy jar from the first stage COPY --from=builder target/my-app-1.0-SNAPSHOT.jar my-app-1.0-SNAPSHOT.jar EXPOSE 8080 CMD ["java", "-jar", "my-app-1.0-SNAPSHOT.jar"]附录https://stackoverflow.com/questions/60522767/docker-build-with-maven-how-to-prevent-re-downloading-dependencieshttps://docs.docker.com/engine/reference/builder/#volume
-
发表了文章 2020-12-24
使用 CoreDNS sidecar 来优化 Kubernetes Pod dns 性能
kubernetes 集群内，应用可能会遇到 dns 性能问题。可以在 Pod 内增加 nscd 来增强性能，该方法需要重制镜像；下面介绍一种给业务 Pod 添加 dns cache sidecar 来增强 dns 性能的方法，虽然无需重制镜像，但需要改动应用 YAML 配置。可以根据实际情况选择合适优化方法。 部署 dns-cache 配置 将下列 dns-cache 的配置部署到应用的命名空间。该配置说明： 输出 log 和 errors 信息到标准输出。 将 dns 查询请求转发到 /etc/resolv.conf 配置的上游 dns 服务器中。 cache 所有请求 30s。（可以调整 cache 时间，配置 prefetch 策略。） 配置 reload ，当该配置文件有变动时，可以自动 reload 并应用新配置。 apiVersion: v1 kind: ConfigMap data: Corefile: | .:53 { errors log forward . /etc/resolv.conf cache 30 reload } metadata: name: dns-cache 给业务 Pod 配置 dns sidecar 给 pod 配置 sidecar dns-cache。 通过 postStart 机制，调整业务容器的 dns 配置，把 sidecar 地址作为首选项。 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: ubuntu labels: app: ubuntu spec: replicas: 1 template: metadata: labels: app: ubuntu spec: containers: - name: ubuntu image: ubuntu:latest command: ["sleep", "100000"] lifecycle: postStart: exec: command: ["/bin/sh", "-c", "echo \"$(sed \'1i nameserver 127.0.0.1\' /etc/resolv.conf)\" > /etc/resolv.conf"] - name: dns-cache image: registry.cn-hangzhou.aliyuncs.com/acs/coredns:1.6.2 args: [ "-conf", "/etc/coredns/Corefile" ] volumeMounts: - mountPath: /etc/coredns name: config-volume readOnly: true volumes: - name: config-volume configMap: name: dns-cache items: - key: Corefile path: Corefile
-
发表了文章 2020-11-29
在 Kubernetes 集群中通过 dns-admission-controller 来调整 Pod dns 配置
上文介绍了 Kubernetes 集群 DNS 服务发现原理。 但在某些场景下，我们希望能够更灵活调整 Pod 默认的 dns 配置，如： 调小 ndots 的值以减少冗余的域名查询请求，以提高查询效率。 集群部署了 local-dns，调整 Pod 的 nameserver 接入 local-dns。 通常，你需要重配置集群 kubelet 的启动参数，或者给应用 YAML 配置 dnsConfig 来达到目的，但是侵入性较强。 本文会介绍 dns-admission-controller 组件，通过 mutating webhook 机制能够在集群级别自动调整 pod 的 dns 配置，灵活性强、侵入性低。 手动部署 dns-admission-controller 参数确定 设定集群的 kube-dns 服务 IP 为 172.21.0.10，集群主域名后缀为 cluster.local。首先，需要确定需要调整的 dns 配置。 参数 说明 nameserver dns 服务的 IP。如果不希望调整，则需要为集群 kube-dns 服务 IP clusterDomain 集群主域名后缀 ndots ndots 值，默认为 3 部署 以调小 ndots 值到 2 为目的示范部署流程，通过下载 helm chart 应用来一键部署应用。 export clusterDomain=cluster.local export nameserver=172.21.0.10 export ndots=2 curl https://node-local-dns.oss-cn-hangzhou.aliyuncs.com/install_dns-admission-controller.sh -o install_dns-admission-controller.sh;chmod 744 install_dns-admission-controller.sh;bash install_dns-admission-controller.sh $clusterDomain $nameserver $ndots 查看是否安装成功： $ helm list -n kube-system NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION dns-admission-controller kube-system 1 2020-11-29 22:39:56.833004 +0800 CST deployed ack-node-local-dns-admission-controller-0.0.1 $ kubectl get deployment dns-admission-controller -n kube-system NAME READY UP-TO-DATE AVAILABLE AGE dns-admission-controller 1/1 1 1 109s 接入 给需要接入的命名空间打标（以 default 为例） kubectl label namespace default node-local-dns-injection=enabled 注：admission-controller 会忽略 kube-system 和 kube-public 命名空间下的应用。 在集群的 default 命名空间下部署以下测试应用 apiVersion: apps/v1 # for versions before 1.8.0 use apps/v1beta1 kind: Deployment metadata: name: ubuntu labels: app: ubuntu spec: replicas: 2 selector: matchLabels: app: ubuntu template: metadata: labels: app: ubuntu spec: containers: - name: ubuntu image: ubuntu command: ["sh", "-c"] args: ["sleep 100000"] $ kubectl apply -f ubuntu-deployment.yaml deployment.apps/ubuntu created $ kubectl get deployment ubuntu NAME READY UP-TO-DATE AVAILABLE AGE ubuntu 2/2 2 2 7s 查看 dnsConfig 是否注入成功 $ kubectl get pods NAME READY STATUS RESTARTS AGE ubuntu-766448f68c-mj8qk 1/1 Running 0 4m39s ubuntu-766448f68c-wf5hw 1/1 Running 0 4m39s $ kubectl get pod ubuntu-766448f68c-mj8qk -o=jsonpath='{.spec.dnsConfig}' map[nameservers:[172.21.0.10] options:[map[name:ndots value:2]] searches:[default.svc.cluster.local svc.cluster.local cluster.local]]
-
发表了文章 2020-11-29
Kubernetes 集群 DNS 服务发现原理
本文介绍 Kubernetes 集群中 DNS 服务发现原理。 前提需要 拥有一个 Kubernetes 集群（可以通过 ACK 创建一个 Kubernetes 集群） 能通过 kubectl 连接 Kubernetes 集群 集群 DNS 服务 Kubernetes 集群中部署了一套 DNS 服务，通过 kube-dns 的服务名暴露 DNS 服务。您可执行以下命令查看 kube-dns 的服务详情。 kubectl get svc kube-dns -n kube-system 输出： NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 172.24.0.10 <none> 53/UDP,53/TCP,9153/TCP 27d 服务后端是两个名为 coredns（下文会介绍 CoreDNS 解析原理） 的 Pod。您可执行以下命令查看 coredns 的 Pod 详情。 kubectl get deployment coredns -n kube-system 输出： NAME READY UP-TO-DATE AVAILABLE AGE coredns 2/2 2 2 27d 集群内域名解析原理 Kubernetes 集群节点上 kubelet 有--cluster-dns=${dns-service-ip} 和 --cluster-domain=${default-local-domain} 两个 dns 相关参数，分别被用来设置集群DNS服务器的IP地址和主域名后缀。 查看集群 default 命名空间下 dnsPolicy:ClusterFirst （下文会介绍 dnsPolicy）模式的 Pod 内的 DNS 域名解析配置文件 /etc/resolv.conf 内容： nameserver 172.24.0.10 search default.svc.cluster.local svc.cluster.local cluster.local options ndots:5 各参数描述如下： nameserver: 定义 DNS 服务器的 IP 地址。 search: 设置域名的查找后缀规则，查找配置越多，说明域名解析查找匹配次数越多。集群匹配有 default.svc.cluster.local、svc.cluster.local、cluster.local 3个后缀，最多进行8次查询 (IPV4和IPV6查询各四次) 才能得到正确解析结果。 option: 定义域名解析配置文件选项，支持多个KV值。例如该参数设置成ndots:5，说明如果访问的域名字符串内的点字符数量超过ndots值，则认为是完整域名，并被直接解析；如果不足ndots值，则追加search段后缀再进行查询。 根据上述文件配置，在 Pod 内尝试解析： 同命名空间下服务，如 kubernetes：添加一次 search 域，发送kubernetes.default.svc.cluster.local. 一次 ipv4 域名解析请求到 172.24.0.10 进行解析即可。 跨命名空间下的服务，如 kube-dns.kue-system：添加两次 search 域，发送 kube-dns.kue-system.default.svc.cluster.local. 和 kube-dns.kue-system.svc.cluster.local. 两次 ipv4 域名解析请求到 172.24.0.10 才能解析出正确结果。 集群外服务，如 aliyun.com：添加三次 search 域，发送 aliyun.com.default.svc.cluster.local.、aliyun.com.svc.cluster.local.、aliyun.com.cluster.local. 和 aliyun.com 四次 ipv4 域名解析请求到 172.24.0.10 才能解析出正确结果。 Pod dnsPolicy Kubernetes 集群中支持通过 dnsPolicy 字段为每个 Pod 配置不同的 DNS 策略。目前支持四种策略： ClusterFirst：通过集群 DNS 服务来做域名解析，Pod 内 /etc/resolv.conf 配置的 DNS 服务地址是集群 DNS 服务的 kube-dns 地址。该策略是集群工作负载的默认策略。None：忽略集群 DNS 策略，需要您提供 dnsConfig 字段来指定 DNS 配置信息。Default：Pod 直接继承集群节点的域名解析配置。即在集群直接使用节点的 /etc/resolv.conf 文件。ClusterFirstWithHostNetwork：强制在 hostNetWork 网络模式下使用 ClusterFirst 策略（默认使用 Default 策略）。 CoreDNS CoreDNS 目前是 Kubernetes 标准的服务发现组件，dnsPolicy: ClusterFirst 模式的 Pod 会使用 CoreDNS 来解析集群内外部域名。 在命名空间 kube-system 下，集群有一个名为 coredns 的 configmap。其 Corefile 字段的文件配置内容如下（CoreDNS 功能都是通过 Corefile 内的插件提供）。 Corefile: | .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf cache 30 loop reload loadbalance } 其中，各插件说明： errors：错误信息到标准输出。 health：CoreDNS自身健康状态报告，默认监听端口8080，一般用来做健康检查。您可以通过http://localhost:8080/health获取健康状态。 ready：CoreDNS插件状态报告，默认监听端口8181，一般用来做可读性检查。可以通过http://localhost:8181/ready获取可读状态。当所有插件都运行后，ready状态为200。 kubernetes：CoreDNS kubernetes插件，提供集群内服务解析能力。 prometheus：CoreDNS自身metrics数据接口。可以通过http://localhost:9153/metrics获取prometheus格式的监控数据。 forward（或proxy）：将域名查询请求转到预定义的DNS服务器。默认配置中，当域名不在kubernetes域时，将请求转发到预定义的解析器（/etc/resolv.conf）中。默认使用宿主机的/etc/resolv.conf配置。 cache：DNS缓存。 loop：环路检测，如果检测到环路，则停止CoreDNS。 reload：允许自动重新加载已更改的Corefile。编辑ConfigMap配置后，请等待两分钟以使更改生效。 loadbalance：循环DNS负载均衡器，可以在答案中随机A、AAAA、MX记录的顺序。
-
发表了文章 2019-07-22
ACK容器服务虚拟节点使用阿里云日志服务来收集业务容器日志
按照这篇博文的介绍，可以在ACK集群上通过Helm的方式部署虚拟节点，提升集群的弹性能力。现在，通过虚拟节点部署的ECI弹性容器实例也支持将stdout输出、日志文件同步到阿里云日志服务（SLS）进行统一管理，所有日志能够被统一收集同一个日志服务project里面。并且，日志收集方式与集群上普通容器收集方式一致，无缝结合。 本文将结合虚拟节点弹性伸缩的能力来介绍日志收集。 在ACK集群部署日志服务支撑组件 在ACK集群安装界面勾选使用日志服务，集群会安装支持日志收集的必要组件。 集群安装完毕后，可以在日志服务控制台 查看到按k8s-log-{Kubernetes 集群 ID}形式命名的工程。收集到的业务容器日志都会放在该工程下。 已有集群可以按照阿里云帮助文档去部署相关组件。如果在普通集群没有部署相关日志服务组件，那么ECI实例的日志将会被统一收集到eci-log-default-project-开头的project内。 部署虚拟节点 可以按照ACK容器服务发布virtual node addon，快速部署虚拟节点提升集群弹性能力这篇文章在集群内部署虚拟节点。 使用YAML模版来收集普通业务容器日志 YAML 模板的语法同 Kubernetes 语法，但是为了给容器指定采集配置，需要使用 env 来为 container 增加采集配置和自定义 Tag，并根据采集配置，创建对应的 volumeMounts 和 volumes。以下是一个简单的 Deployment 示例： apiVersion: apps/v1 kind: Deployment metadata: labels: app: alpine name: alpine spec: replicas: 2 selector: matchLabels: app: alpine template: metadata: labels: app: alpine spec: containers: - image: alpine imagePullPolicy: Always args: - ping - 127.0.0.1 name: alpine env: ######### 配置 环境变量 ########### - name: aliyun_logs_test-stdout value: stdout - name: aliyun_logs_test-file value: /log/*.log - name: aliyun_logs_log_tags value: tag1=v1 ################################# ######### 配置vulume mount ####### volumeMounts: - name: volume-sls mountPath: /log volumes: - name: volume-sls ############################### 其中有三部分需要根据您的需求进行配置，一般按照顺序进行配置。 第一部分通过环境变量来创建您的采集配置和自定义 Tag，所有与配置相关的环境变量都采用aliyun_logs_作为前缀。创建采集配置的规则如下： - name: aliyun_logs_{Logstore 名称} value: {日志采集路径} 示例中创建了两个采集配置，其中 aliyun_logs_log-stdout 这个 env 表示创建一个 Logstore 名字为 log-stdout，日志采集路径为 stdout 的配置，从而将容器的标准输出采集到 log-stdout 这个 Logstore 中。 说明 Logstore 名称中不能包含下划线（_），可以使用 - 来代替。 创建自定义 Tag 的规则如下： - name: aliyun_logs_{任意不包含'_'的名称}_tags value: {Tag 名}={Tag 值} 配置 Tag 后，当采集到该容器的日志时，会自动附加对应的字段到日志服务。 如果您的采集配置中指定了非 stdout 的采集路径，需要在此部分创建相应的 volumnMounts。示例中采集配置添加了对/log/*.log 的采集，因此相应地添加了/log的 volumeMounts。 将上述yaml保存为test.yaml,应用在集群上： $ kubectl create ns virtual $ kubectl create -f test.yaml -n virtual # 查看pod部署情况 $ kubectl get pods -n virtual -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE alpine-57c9977fd6-bsvwh 1/1 Running 0 10m 172.18.1.161 cn-hangzhou.10.1.190.228 <none> alpine-57c9977fd6-wc89v 1/1 Running 0 10m 172.18.0.169 cn-hangzhou.10.1.190.229 <none> 查看日志 到日志服务控制台的相应工程下找到test-stdout这个logstore，点击查询可以看到收集到的普通容器的stdout日志: 将业务容器扩容到虚拟节点 将把上面创建的命名空间virtual标记为使用虚拟节点进行部署，然后伸缩两个pod到虚拟节点。 # 标记namespace $ kubectl label namespace virtual virtual-node-affinity-injection=enabled # scale deployment/alpine $ kubectl scale --replicas=4 deployments/alpine -n virtual # 查看pod部署情况，可以看到2个部署在正常节点，2个部署在虚拟节点 $ kubectl get pods -n virtual -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE alpine-57c9977fd6-2ctp7 1/1 Running 0 23s 10.1.190.231 virtual-kubelet <none> alpine-57c9977fd6-b4445 1/1 Running 0 23s 10.1.190.230 virtual-kubelet <none> alpine-57c9977fd6-bsvwh 1/1 Running 0 10m 172.18.1.161 cn-hangzhou.10.1.190.228 <none> alpine-57c9977fd6-wc89v 1/1 Running 0 10m 172.18.0.169 cn-hangzhou.10.1.190.229 <none> 再次查看日志 再点开test-stdout这个logstore，可以看到收集到的普通容器和ECI实例的混合stdout日志: 需要注意: 您账户下不同集群内的不同logstore不可以配置收集相同匹配规则的ECI实例日志，如stdout；同一个集群下，不同logstore不可以配置收集相同匹配规则的普通容器、ECI实例日志。
-
发表了文章 2019-07-17
使用node local dns来提升ClusterDNS服务质量
NodeLocal DNSCache通过在集群上运行一个dnsCache daemonset来提高clusterDNS性能和可靠性。在ACK集群上的一些测试表明：相比于纯coredns方案，nodelocaldns + coredns方案能够大幅降低DNS查询timeout的频次，提升服务稳定性。 本文将介绍如何在ACK集群上部署node local dns。 部署nodelocaldns nodelocaldns通过添加iptables规则能够接收节点上所有发往169.254.20.10的dns查询请求，把针对集群内部域名查询请求路由到coredns；把集群外部域名请求直接通过host网络发往集群外部dns服务器。 # 下载部署脚本 $ curl https://node-local-dns.oss-cn-hangzhou.aliyuncs.com/install-nodelocaldns.sh # 部署。确保kubectl能够连接集群 $ bash install-nodelocaldns.sh DNS优化方案的具体实施仍在探索中，该脚本部署不对集群现有业务有任何影响，需要使用node local dns的业务容器也需要定制其dnsConfig。 定制业务容器dnsConfig 为了使业务容器能够使用nodelocaldns，需要将nameserver配置为169.254.20.10,而不是ClusterDNS。定制dnsConfig有以下几点需要注意到： dnsPolicy: None。不使用ClusterDNS。 配置searches，保证集群内部域名能够被正常解析。 适当降低ndots值。当前ACK集群ndots值默认为5,降低ndots值有利于加速集群外部域名访问。如果业务容器没有使用带多个dots的集群内部域名，建议将值设为2。 apiVersion: v1 kind: Pod metadata: name: alpine namespace: default spec: containers: - image: alpine command: - sleep - "10000" imagePullPolicy: Always name: alpine dnsPolicy: None dnsConfig: nameservers: ["169.254.20.10"] searches: - default.svc.cluster.local - svc.cluster.local - cluster.local options: - name: ndots value: "2"
-
发表了文章 2019-06-17
容器服务Windows Kubernetes使用阿里云日志服务来收集容器日志
目前，容器服务Windows Kubernetes支持将业务容器产生的stdout输出、日志文件同步到阿里云日志服务（SLS）进行统一管理。 支撑组件安装 在Windows Kubernetes集群安装界面勾选使用日志服务，集群会安装支持日志收集的必要组件logtail。 集群安装完毕后，可以在日志服务控制台 查看到按k8s-sls-{Kubernetes 集群 ID}形式命名的工程。收集到的业务容器日志都会放在该工程下。 使用YAML模版部署业务容器 YAML 模板的语法同 Kubernetes 语法，但是为了给容器指定采集配置，需要使用 env 来为 container 增加采集配置和自定义 Tag，并根据采集配置，创建对应的 volumeMounts 和 volumns。以下是一个简单的 Deployment 示例： apiVersion: extensions/v1beta1 kind: Deployment metadata: labels: app: logtail-test name: logtail-test spec: replicas: 1 template: metadata: labels: app: logtail-test name: logtail-test spec: containers: - name: logtail image: registry-vpc.cn-hangzhou.aliyuncs.com/acs/windows-logtail:1809-1.0.0.4 command: ["powershell.exe"] args: [cmd /k "ping -t 127.0.0.1 -w 10000 > C:\log\data.log"] env: ######### 配置 环境变量 ########### - name: aliyun_logs_log-stdout value: stdout - name: aliyun_logs_log-varlog value: C:\log\*.log - name: aliyun_logs_log_tags value: tag1=v1 ################################# ######### 配置vulume mount ####### volumeMounts: - name: volumn-sls-win mountPath: c:\log volumes: - name: volumn-sls-win emptyDir: {} ############################### nodeSelector: beta.kubernetes.io/os: windows 其中有三部分需要根据您的需求进行配置，一般按照顺序进行配置。 第一部分通过环境变量来创建您的采集配置和自定义 Tag，所有与配置相关的环境变量都采用aliyun_logs_作为前缀。创建采集配置的规则如下： - name: aliyun_logs_{Logstore 名称} value: {日志采集路径} 示例中创建了两个采集配置，其中 aliyun_logs_log-stdout 这个 env 表示创建一个 Logstore 名字为 log-stdout，日志采集路径为 stdout 的配置，从而将容器的标准输出采集到 log-stdout 这个 Logstore 中。 说明 Logstore 名称中不能包含下划线（_），可以使用 - 来代替。 创建自定义 Tag 的规则如下： - name: aliyun_logs_{任意不包含'_'的名称}_tags value: {Tag 名}={Tag 值} 配置 Tag 后，当采集到该容器的日志时，会自动附加对应的字段到日志服务。 如果您的采集配置中指定了非 stdout 的采集路径，需要在此部分创建相应的 volumnMounts。示例中采集配置添加了对c:log*.log 的采集，因此相应地添加了c:log的 volumeMounts。 查看日志 本例部署的应用会向data.log文件中写入日志。可以按以下步骤查看日志： 安装成功后，进入日志服务控制台。 在进入控制台后，选择 Kubernetes 集群对应的 Project（默认为 k8s-log-{Kubernetes 集群 ID}），进入 Logstore 列表页面。 在列表中找到相应的 Logstore（采集配置中指定），单击查询。 本例中，在日志查询页面，您可查看容器内文本日志，并可发现自定义tag附加到日志字段中。
2021年02月
-
02.26 20:59:32
发表了文章
2021-02-26 20:59:32
如何在 Java 镜像构建过程中免重复下载依赖包
利用镜像构建缓存机制来加速 Java 镜像构建过程，免重复下载依赖包。
2020年12月
-
12.24 18:02:31发表了文章
2020-12-24 18:02:31
使用 CoreDNS sidecar 来优化 Kubernetes Pod dns 性能
介绍一种给业务 Pod 添加 dns cache sidecar 来增强 dns 性能的方法。
2020年11月
-
11.29 22:49:29发表了文章
2020-11-29 22:49:29
在 Kubernetes 集群中通过 dns-admission-controller 来调整 Pod dns 配置
本文介绍 dns-admission-controller 组件，通过 mutating webhook 机制能够在集群级别自动调整 pod 的 dns 配置，灵活性强、侵入性低。 -
11.29 18:28:15发表了文章
2020-11-29 18:28:15
Kubernetes 集群 DNS 服务发现原理
本文介绍 Kubernetes 集群中 DNS 服务发现原理。
2019年07月
-
07.22 13:44:16发表了文章
2019-07-22 13:44:16
ACK容器服务虚拟节点使用阿里云日志服务来收集业务容器日志
按照这篇博文的介绍，可以在ACK集群上通过Helm的方式部署虚拟节点，提升集群的弹性能力。现在，通过虚拟节点部署的ECI弹性容器实例也支持将stdout输出、日志文件同步到阿里云日志服务（SLS）进行统一管理，所有日志能够被统一收集同一个日志服务project里面。 -
07.17 13:48:26发表了文章
2019-07-17 13:48:26
使用node local dns来提升ClusterDNS服务质量
NodeLocal DNSCache在集群的上运行一个dnsCache daemonset来提高clusterDNS性能和可靠性。在ACK集群上的一些测试表明：相比于纯coredns方案，nodelocaldns + coredns方案能够大幅降低DNS查询timeout的频次，提升服务稳定性，能够扛住1倍多的QPS。
2019年06月
-
06.17 10:08:21发表了文章
2019-06-17 10:08:21
容器服务Windows Kubernetes使用阿里云日志服务来收集容器日志
目前，容器服务Windows Kubernetes支持将业务容器产生的stdout输出、日志文件同步到阿里云日志服务（SLS）进行统一管理。 支撑组件安装 在Windows Kubernetes集群安装界面勾选使用日志服务，集群会安装支持日志收集的必要组件logtail。
-
发表了文章
2021-02-26
如何在 Java 镜像构建过程中免重复下载依赖包
-
发表了文章
2020-12-24
使用 CoreDNS sidecar 来优化 Kubernetes Pod dns 性能
-
发表了文章
2020-11-29
在 Kubernetes 集群中通过 dns-admission-controller 来调整 Pod dns 配置
-
发表了文章
2020-11-29
Kubernetes 集群 DNS 服务发现原理
-
发表了文章
2019-07-22
ACK容器服务虚拟节点使用阿里云日志服务来收集业务容器日志
-
发表了文章
2019-07-17
使用node local dns来提升ClusterDNS服务质量
-
发表了文章
2019-06-17
容器服务Windows Kubernetes使用阿里云日志服务来收集容器日志
滑动查看更多
暂无更多信息
暂无更多信息