7 天前 / MingWei
volume:- name: volume1hostPath:path: /xxx/yyytype: Directory 这个容器启动后去查看对应的目录的确已经挂载进来了，但是随着时间的流逝，偶然间发现容器内的这个目录内容与物理机的内容是不一样的！不一样的！不一样的！ 解决思路本质需求是容器挂载目录与物理机的目录这两边的数据是实时更新的，但显然这两边的数据并不一致，所以这中间有一个 gap 我并不了解。 先用 docker inspect 查看一下容器的信息。这个容器对应卷的 volume mount 部分信息如下： {"Type": "bind","Source": "/xxx/yyy","Destination": "/test","Mode": "","RW": true,"Propagat...
9 天前 / 崔秀龙
人在江湖飘，哪能不挨刀 说了好几期 CIS 之类的运行时安全问题，K8s 在运行过程中，还有个常见的安全威胁就是镜像漏洞，不少同学都有在实施过程中因为镜像漏洞问题被吊打的经验，今天就结合个人经验，说说镜像漏洞修复的一般流程。 这里主要指的是第三方镜像的修复过程，Scratch 不在此列。 修复任务分析 通常扫描报告会明确指明确切的问题源头、相关软件包、问题版本、修复版本等，首先要根据报告判断修复的目标。修复目标并不一定是固定的，有些情况下可能仅需要修复公开的高危漏洞，有些可能要求更多。
26 天前 / Mohuishou
rss2020 年 8 月 24 日 上午 2k 字 32 分钟序注意：这篇文章代码比较多，包含了 简单工厂、工厂方法、抽象工厂、DI 容器的实现，由于内容具有关联性就不进行拆分了 Go 设计模式实现，包含 23 种常见的设计模式实现，同时这也是 极客时间 - 设计模式之美的笔记，源课程采用 Java 实现，本系列会采用 Go 实现课程： 44 | 工厂模式（上）：我为什么说没事不要随便用工厂模式创建对象？本文代码仓库： https://github.com/mohuishou/go-design-patternRoadMap: 02/22 持续更新中，预计一周更新 2 ~ 3 种设计模式...
37 天前 / ???米?开?朗?基?杨???
更多精彩内容欢迎订阅我的博客：https://fuckcloudnative.io/ 在容器的整个生命周期中，拉取镜像是最耗时的步骤之一。Harter 等人的研究 [1]表明： 拉取镜像占用了容器启动时间的 76%，只有 6.4% 的时间用来读取数据。 这个问题一直困扰着各类工作负载，包括 serverless 函数的冷启动时间，镜像构建过程中基础镜像的拉取等。虽然有各种折中的解决方案，但这些方案都有缺陷： 缓存镜像 : 冷启动时仍然有性能损失。减小镜像体积 : 无法避免某些场景需要用到大体积的镜像，比如机器学习。
53 天前 / 优美代码
容器是什么？相信很多人听说过依赖注入，依赖注入实现的基础条件离不开容器，容器就是用来管理类依赖和注入的，负责服务的管理和解耦组件，最简单的理解我们可以把容器理解成一个超级大、专门存对象的数组。 图 1 如图所示调用者通过容器的标示获取到对象实例，图里可以看出来，可以通过::class的方式来获取也可以直接通过对象标示获取实例对象。 IOC 是什么？ 大家可能都听说过 IOC 容器，IOC 的全称是：(Inversion Of Control，反转控制)。
56 天前 / KevinYan
刚开始学 Docker 的时候因为不知道 Docker 跟以前在 VirtualBox 里安的虚拟机还有 Vargrant 有啥区别，我都是习惯性的把开发环境里用的东西往单个容器里塞。后来看网上的教程还有别人分享的案例多了后，才知道把应用容器化的第一步是：要把应用用到的东西拆解放到多个容器里。慢慢地我发现不少人刚开始学 Docker 时候跟我一样都有刚接触时把 Docker 当虚拟机来用的问题，比如我特别早以前发过一篇文章《用 Docker-Compose 搭建 Laravel 开发环境》里，我用三个分别装着 PHP、MySQL 和 Nginx 的容器搭建了一个开发环境。
65 天前 / KevinYan
用 Go 开发的应用程序的一个优势在于，可以从"零"开始构建应用的 Docker 镜像，镜像中仅需要包含 Go 应用程序编译后的二进制文件，不需要额外安装其他执行环境。这样一来 Go 应用镜像占用的空间确实很小（通常是几 MB），而且也会更安全些。常用的 alpine 镜像（alpine 是专门为容器设计的小型 Linux 发行版）中存在一个安全漏洞，该漏洞为大量生产容器留下了空的 root 用户密码，所以如果你的的 Go 应用程序在没有 alpine（或任何其他操作系统）的容器中运行，黑客就不能利用操作系统的漏洞去攻击容器里的应用。
73 天前 / 高飞
Docker 可以说是现在微服务，DevOps 的基础，咱们。Net Core 自然也得上 Docker。.Net Core 发布到 Docker 容器的教程网上也有不少，但是今天还是想来写一写。 你搜。Net core 程序发布到 Docker 网上一般常见的有两种方案： 1、在本地编译成 Dll 文件后通过 SCP 命令或者 WinSCP 等工具上传到服务器上，然后构建 Docker 镜像再运行容器。该方案跟传统的发布很像，麻烦的地方是每次都要打开相关工具往服务器上复制文件。 2、在服务端直接通过 Git 获取最新源代码后编译成 Dll 然后构建 Docker 镜像再运行容器。
79 天前 / KevinYan
Docker 这几年的迅猛发展让容器重新流行起来，不过但很多资料里介绍 Docker 时都说是 "新瓶装旧酒"。除了容器外虚拟机也是我们或多或少会接触到的虚拟化技术。虚拟机和容器都用于创建隔离的虚拟环境，但是这两种虚拟化技术有显著的不同，今天的文章就来聊一下它们之间的区别。 虚拟机虚拟机（VM）是共享一个服务器的物理资源的操作系统。它是主机硬件上的 Guest，因此也被称为 Guest 虚拟机。 虚拟机由几层组成。支持虚拟化的层是 hypervisor。hypervisor 是一种虚拟化服务器的软件。
92 天前 / 小米云技术官方
本文讲述了小米是如何将 Redis Cluster 部署在 K8S 上提供高质量的服务的 往期文章回顾：HBase Region Read Replicas 功能详解 背景 Why K8S How K8s Why Proxy Proxy 带来的问题 K8s 带来的好处 遇到的问题 总结 背景小米的 Redis 使用规模很大，现在有数万个实例，并且每天有百万亿次的访问频率，支撑了几乎所有的产品线和生态链公司。之前所有的 Redis 都部署在物理机上，也没有做资源隔离，给管理治理带来了很大的困难。我们的运维人员工作压力很大，机器宕机网络抖动导致的 Redis 节点下线都经常需要人工介入处理。
93 天前 / ???米?开?朗?基?杨???
Docker 技术鼻祖系列 原文链接：https://ieevee.com/tech/2020/05/11/nginx-process-auto.html 1. 问题描述 nginx 容器化时，有一个普遍会遇到的问题：如何自动设置 nginx worker process 的数量？ nginx 官方容器镜像的 nginx.conf 配置文件中，会有一条 worker process 配置： 它会配置 nginx 仅启动 1 个 worker。这在 nginx 容器为 1 核时，可以良好的工作。 当我们希望 nginx 给更高的配置，例如 4c 或者 16c，我们需要确保 nginx 也能启动响应个数的 worker process。
102 天前 / 崔秀龙
如果寿司店老板说，有一种人叫寿司人，寿司人的一切都是为了吃寿司，寿司人比别的人都厉害，你肯定会嗤之以鼻；云厂商提出了云原生概念，倒是拥趸甚多——这是因为云比寿司好吃多了，它提供的好处，足以让人铤而走险，削减脑袋挤上云计算的车，这也就是业务上云了。 从参与《Kubernetes 权威指南》第二版到现在已经好几年了，在几年的容器化、云原生的推动过程中，因为一直从事企业服务的勾当，这个小视野里的绝大多数应用，都是证明可以成功容器化的。
108 天前 / jameswhale
前言 近几年容器（Container）、Kubernetes 等技术在数据中心、云计算、各互联网公司的业务服务中得到广泛应用，和 20 世纪 60 年代就兴起的虚拟机（Virtual Machine，VM）技术一样，容器也是一种服务虚拟化技术（Server Virtualization），但是它更加轻量，同时将焦点从 Machine 转移到 Application，极大提高了开发、测试、生产环境部署的效率，不过其安全性和隔离性比虚拟机稍逊一筹，在一些场景下也无法完全替代虚拟机。本文主要从以下几部分来梳理虚拟机和容器技术，详细讲一下他们的区别与联系。
109 天前 / 煎鱼
最近我在回顾思考（写 PPT），整理了现状，发现了这个问题存在多时，经过一番波折，最终确定了元凶和相对可行的解决方案，因此分享一下排查历程，希望能够给大家一些借鉴的经验。 时间线： 在上 Kubernetes 的前半年，只是用 Kubernetes，开发没有权限，业务服务极少，忙着写新业务，风平浪静。 在上 Kubernetes 的后半年，业务服务较少，偶尔会阶段性被运维唤醒，问之 “为什么你们的服务内存占用这么高，赶紧查”。此时大家还在为新业务冲刺，猜测也许是业务代码问题，但没有调整代码去尝试解决。
117 天前 / ???米?开?朗?基?杨???
作为一名系统重启工程师（SRE），你可能经常需要重启容器，毕竟 Kubernetes 的优势就是快速弹性伸缩和故障恢复，遇到问题先重启容器再说，几秒钟即可恢复，实在不行再重启系统，这就是系统重启工程师的杀手锏。然而现实并没有理论上那么美好，某些容器需要花费 10s 左右才能停止，这是为啥？有以下几种可能性： 容器中的进程没有收到 SIGTERM[1] 信号。容器中的进程收到了信号，但忽略了。容器中应用的关闭时间确实就是这么长。对于第 3 种可能性我们无能为力，本文主要解决 1 和 2。