Istio 1.4 部署指南

原文链接:Istio 1.4 部署指南

Istio 一直处于快速迭代更新的过程中,它的部署方法也在不断更新,之前我在 1.0 版本中介绍的安装方法,对于最新的 1.4 版本已经不适用了。以后主流的部署方式都是用 istioctl 进行部署,helm 可以渐渐靠边站了~~

在部署 Istio 之前,首先需要确保 Kubernetes 集群(kubernetes 版本建议在 1.13 以上)已部署并配置好本地的 kubectl 客户端。

1. Kubernetes 环境准备

为了快速准备 kubernetes 环境,我们可以使用 sealos 来部署,步骤如下:

前提条件

安装 kubernetes 集群

$ sealos init --master 192.168.0.2 \
    --node 192.168.0.3 \
    --node 192.168.0.4 \
    --node 192.168.0.5 \
    --user root \
    --passwd your-server-password \
    --version v1.16.3 \
    --pkg-url /root/kube1.16.3.tar.gz 

检查安装是否正常:

$ kubectl get node

NAME       STATUS   ROLES    AGE   VERSION
sealos01   Ready    master   18h   v1.16.3
sealos02   Ready    <none>   18h   v1.16.3
sealos03   Ready    <none>   18h   v1.16.3
sealos04   Ready    <none>   18h   v1.16.3

2. 下载 Istio 部署文件

你可以从 GitHub 的 release 页面下载 istio,或者直接通过下面的命令下载:

$ curl -L https://istio.io/downloadIstio | sh -

下载完成后会得到一个 istio-1.4.2 目录,里面包含了:

  • install/kubernetes : 针对 Kubernetes 平台的安装文件
  • samples : 示例应用
  • bin : istioctl 二进制文件,可以用来手动注入 sidecar proxy

进入 istio-1.4.2 目录。

$ cd istio-1.4.2

$ tree -L 1 ./
./
├── bin
├── demo.yaml
├── install
├── LICENSE
├── manifest.yaml
├── README.md
├── samples
└── tools

4 directories, 4 files

将 istioctl 拷贝到 /usr/local/bin/ 中:

$ cp bin/istioctl /usr/local/bin/

开启 istioctl 的自动补全功能

bash

tools 目录中的 istioctl.bash 拷贝到 $HOME 目录中:

$ cp tools/istioctl.bash ~/

~/.bashrc 中添加一行:

source ~/istioctl.bash

应用生效:

$ source ~/.bashrc

zsh

tools 目录中的 _istioctl 拷贝到 $HOME 目录中:

$ cp tools/_istioctl ~/

~/.zshrc 中添加一行:

source ~/_istioctl

应用生效:

$ source ~/.zshrc

3. 部署 Istio

istioctl 提供了多种安装配置文件,可以通过下面的命令查看:

$ istioctl profile list

Istio configuration profiles:
    minimal
    remote
    sds
    default
    demo

它们之间的差异如下:

default demo minimal sds remote
核心组件
istio-citadel X X X X
istio-egressgateway X
istio-galley X X X
istio-ingressgateway X X X
istio-nodeagent X
istio-pilot X X X X
istio-policy X X X
istio-sidecar-injector X X X X
istio-telemetry X X X
附加组件
Grafana X
istio-tracing X
kiali X
prometheus X X X

其中标记 X 表示该安装该组件。

如果只是想快速试用并体验完整的功能,可以直接使用配置文件 demo 来部署。

在正式部署之前,需要先说明两点:

Istio CNI Plugin

当前实现将用户 pod 流量转发到 proxy 的默认方式是使用 privileged 权限的 istio-init 这个 init container 来做的(运行脚本写入 iptables),需要用到 NET_ADMIN capabilities。对 linux capabilities 不了解的同学可以参考我的 Linux capabilities 系列

Istio CNI 插件的主要设计目标是消除这个 privileged 权限的 init container,换成利用 Kubernetes CNI 机制来实现相同功能的替代方案。具体的原理就是在 Kubernetes CNI 插件链末尾加上 Istio 的处理逻辑,在创建和销毁 pod 的这些 hook 点来针对 istio 的 pod 做网络配置:写入 iptables,让该 pod 所在的 network namespace 的网络流量转发到 proxy 进程。

详细内容请参考官方文档

使用 Istio CNI 插件来创建 sidecar iptables 规则肯定是未来的主流方式,不如我们现在就尝试使用这种方法。

Kubernetes 关键插件(Critical Add-On Pods)

众所周知,Kubernetes 的核心组件都运行在 master 节点上,然而还有一些附加组件对整个集群来说也很关键,例如 DNS 和 metrics-server,这些被称为关键插件。一旦关键插件无法正常工作,整个集群就有可能会无法正常工作,所以 Kubernetes 通过优先级(PriorityClass)来保证关键插件的正常调度和运行。要想让某个应用变成 Kubernetes 的关键插件,只需要其 priorityClassName 设为 system-cluster-criticalsystem-node-critical,其中 system-node-critical 优先级最高。

注意:关键插件只能运行在 kube-system namespace 中!

详细内容可以参考官方文档

接下来正式安装 istio,命令如下:

$ istioctl manifest apply --set profile=demo \
   --set cni.enabled=true --set cni.components.cni.namespace=kube-system \
   --set values.gateways.istio-ingressgateway.type=ClusterIP

istioctl 支持两种 API:

在上述安装命令中,cni 参数使用的是 IstioControlPlane API,而 values.* 使用的是 Helm API。

部署完成后,查看各组件状态:

$ kubectl -n istio-system get pod

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-6b65874977-8psph                  1/1     Running   0          36s
istio-citadel-86dcf4c6b-nklp5             1/1     Running   0          37s
istio-egressgateway-68f754ccdd-m87m8      0/1     Running   0          37s
istio-galley-5fc6d6c45b-znwl9             1/1     Running   0          38s
istio-ingressgateway-6d759478d8-g5zz2     0/1     Running   0          37s
istio-pilot-5c4995d687-vf9c6              0/1     Running   0          37s
istio-policy-57b99968f-ssq28              1/1     Running   1          37s
istio-sidecar-injector-746f7c7bbb-qwc8l   1/1     Running   0          37s
istio-telemetry-854d8556d5-6znwb          1/1     Running   1          36s
istio-tracing-c66d67cd9-gjnkl             1/1     Running   0          38s
kiali-8559969566-jrdpn                    1/1     Running   0          36s
prometheus-66c5887c86-vtbwb               1/1     Running   0          39s
$ kubectl -n kube-system get pod -l k8s-app=istio-cni-node

NAME                   READY   STATUS    RESTARTS   AGE
istio-cni-node-k8zfb   1/1     Running   0          10m
istio-cni-node-kpwpc   1/1     Running   0          10m
istio-cni-node-nvblg   1/1     Running   0          10m
istio-cni-node-vk6jd   1/1     Running   0          10m

可以看到 cni 插件已经安装成功,查看配置是否已经追加到 CNI 插件链的末尾:

$ cat /etc/cni/net.d/10-calico.conflist

{
  "name": "k8s-pod-network",
  "cniVersion": "0.3.1",
  "plugins": [
  ...
    {
      "type": "istio-cni",
      "log_level": "info",
      "kubernetes": {
        "kubeconfig": "/etc/cni/net.d/ZZZ-istio-cni-kubeconfig",
        "cni_bin_dir": "/opt/cni/bin",
        "exclude_namespaces": [
          "istio-system"
        ]
      }
    }
  ]
}

默认情况下除了 istio-system namespace 之外,istio cni 插件会监视其他所有 namespace 中的 Pod,然而这并不能满足我们的需求,更严谨的做法是让 istio CNI 插件至少忽略 kube-systemistio-system 这两个 namespace,怎么做呢?

也很简单,还记得之前提到的 IstioControlPlane API 吗?可以直接通过它来覆盖之前的配置,只需要创建一个 IstioControlPlane CRD 就可以了。例如:

$ cat cni.yaml

apiVersion: install.istio.io/v1alpha2
kind: IstioControlPlane
spec:
  cni:
    enabled: true
    components:
      namespace: kube-system
  values:
    cni:
      excludeNamespaces:
       - istio-system
       - kube-system
       - monitoring
  unvalidatedValues:
    cni:
      logLevel: info
$ istioctl manifest apply -f cni.yaml

删除所有的 istio-cni-node Pod:

$ kubectl -n kube-system delete pod -l k8s-app=istio-cni-node

再次查看 CNI 插件链的配置:

$ cat /etc/cni/net.d/10-calico.conflist

{
  "name": "k8s-pod-network",
  "cniVersion": "0.3.1",
  "plugins": [
  ...
    {
      "type": "istio-cni",
      "log_level": "info",
      "kubernetes": {
        "kubeconfig": "/etc/cni/net.d/ZZZ-istio-cni-kubeconfig",
        "cni_bin_dir": "/opt/cni/bin",
        "exclude_namespaces": [
          "istio-system",
          "kube-system",
          "monitoring"
        ]
      }
    }
  ]
}

4. 暴露 Dashboard

这个没什么好说的,通过 Ingress Controller 暴露就好了,可以参考我以前写的 Istio 1.0 部署。如果使用 Contour 的可以参考我的另一篇文章:Contour 学习笔记(一):使用 Contour 接管 Kubernetes 的南北流量

这里我再介绍一种新的方式,istioctl 提供了一个子命令来从本地打开各种 Dashboard:

$ istioctl dashboard --help

Access to Istio web UIs

Usage:
  istioctl dashboard [flags]
  istioctl dashboard [command]

Aliases:
  dashboard, dash, d

Available Commands:
  controlz    Open ControlZ web UI
  envoy       Open Envoy admin web UI
  grafana     Open Grafana web UI
  jaeger      Open Jaeger web UI
  kiali       Open Kiali web UI
  prometheus  Open Prometheus web UI
  zipkin      Open Zipkin web UI

例如,要想在本地打开 Grafana 页面,只需执行下面的命令:

$ istioctl dashboard grafana
http://localhost:36813

咋一看可能觉得这个功能很鸡肋,我的集群又不是部署在本地,而且这个命令又不能指定监听的 IP,在本地用浏览器根本打不开呀!其实不然,你可以在本地安装 kubectl 和 istioctl 二进制文件,然后通过 kubeconfig 连接到集群,最后再在本地执行上面的命令,就可以打开页面啦,开发人员用来测试是不是很方便?Windows 用户当我没说。。。

5. 暴露 Gateway

为了暴露 Ingress Gateway,我们可以使用 HostNetwork 模式运行,但你会发现无法启动 ingressgateway 的 Pod,因为如果 Pod 设置了 HostNetwork=true,则 dnsPolicy 就会从 ClusterFirst 被强制转换成 Default。而 Ingress Gateway 启动过程中需要通过 DNS 域名连接 pilot 等其他组件,所以无法启动。

我们可以通过强制将 dnsPolicy 的值设置为 ClusterFirstWithHostNet 来解决这个问题,详情参考:Kubernetes DNS 高阶指南

修改后的 ingressgateway deployment 配置文件如下:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: istio-system
  ...
spec:
  ...
  template:
    metadata:
    ...
    spec:
      affinity:
        nodeAffinity:
          ...
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                - 192.168.0.4   # 假设你想调度到这台主机上
      ...
      dnsPolicy: ClusterFirstWithHostNet
      hostNetwork: true
      restartPolicy: Always
      ...

接下来我们就可以在浏览器中通过 Gateway 的 URL 来访问服务网格中的服务了。后面我会开启一系列实验教程,本文的所有步骤都是为后面做准备,如果想跟着我做后面的实验,请务必做好本文所述的准备工作。

微信公众号

扫一扫下面的二维码关注微信公众号,在公众号中回复◉加群◉即可加入我们的云原生交流群,和孙宏亮、张馆长、阳明等大佬一起探讨云原生技术

使用 font-spider 对 webfont 网页字体进行压缩

原文链接:使用 font-spider 对 webfont 网页字体进行压缩

随着当前 Web 技术的日新月异,网页界面内容越来越丰富,让人眼花缭乱,其中就包括了网页中的各种自定义字体。

例如,个人博客的首页字体:

CSS3 引入的 @font-face 这一属性可以很好的解决这个问题,可以帮助我们非常灵活的使用一些特殊的字体,即使用户电脑里面没有安装这个字体,网页也可以显示。

EOT 字体是 IE 浏览器的首选格式,其他浏览器都不支持;其他浏览器更钟爱常见的 TTFSVGWOFF

基本语法如下:

@font-face {
    font-family: <自定义一个字体的名称>;
    src: url('<下载好的字体,在电脑中保存的路径>');
    font-variant: <font-variant>; 
    font-stretch: <font-stretch>;
    font-style: <style>;
    font-weight: <weight>;

例如:

@font-face {
    font-family: 'Lora';
    src: url('../fonts/STKaiti.eot'); /* IE9 Compat Modes */
    src: url('../fonts/STKaiti.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
           url('../fonts/STKaiti.woff2') format('woff2'), /* Super Modern Browsers */
           url('../fonts/STKaiti.woff') format('woff'), /* Modern Browsers */
           url('../fonts/STKaiti.ttf') format('truetype'), /* Safari, Android, iOS */
           url('../fonts/STKaiti.svg#STKaiti') format('svg'); /* Legacy iOS */
    font-style: normal;
    font-weight: normal;
}

body {
  font-family: STKaiti;
  ...
}

测试效果:Chrome,Firefox,IE7-IE11 均可以实现

1. 字体难题

自定义中文字体虽炫酷,但有一个弊端,那就是中文字体太大了,很耗费资源,具体的原因其实很简单:英文只有 26 个字母,一张 ASCII 码表上 128 个字符集几乎可以表示任何英文语句。由于字符集小,字体文件也可以做的非常小;中文字体就完全不同,单单 GB2313 编码的中文字符(含符号)就达到 7445 个,字符数量是 ASCII 码表的 58 倍,而字体设计师需要为每一个中文字符设计字体,简单计算下,中文字体文件大小也几乎达到英文字体文件的数十倍。

2. 解决思路

解决思路其实也很简单,只在字库中保留页面中出现的文字,将其他大量不用的文字删掉,生成一个只包含特定字符的小字体文件,便可以大大减少字体文件,从而提高访问速度。现在思路有了,那么有没有现成的工具呢?

3. 裁剪工具

还真有。经过我一番搜寻,找到了两款工具:一个是华人开发的「字蛛」,英文名 font-spider,依赖 Node.js 环境,是一款命令行工具。主要思路是采集线上网页使用到的字体,从字体文件中分离出来,完成大幅度压缩。另一个是腾讯的大佬改版后的 font-soider,叫 font-spider-plus。它们的工作原理如下:

我选择使用 font-spider-plus,毕竟改版过的,bug 更少,功能更多,还支持线上动态渲染的页面。唯一的不足就是官方文档写的太含糊了,许多人看了根本不知道怎么用。下面我将给我一个详细的范例,手把手教你如何使用 font-spider-plus。

4. font-spider-plus 使用方法

根据官方文档,要想使用 font-spider-plus,首先要在 CSS 文件中通过 @font-face 引入全量大小的特殊字体。具体怎么做呢?并没有说,我来告诉你。

书写 HTML 文件

首先我们新建一个文件夹用来放 html 文件:

$ mkdir index

然后在 index 目录中创建一个 index.html 文件,内容如下:

<div class="test">
米开朗基杨
</div>
<style>
  @font-face {
    font-family: 'font';
    src: url('../fonts/<font>.eot');
    src:
      url('../fonts/<font>.eot?#font-spider') format('embedded-opentype'),
      url('../fonts/<font>.woff2') format('woff2'),
      url('../fonts/<font>.woff') format('woff'),
      url('../fonts/<font>.ttf') format('truetype'),
      url('../fonts/<font>.svg') format('svg');
    font-weight: normal;
    font-style: normal;
  }
  .test{
      font-family: 'font';
  }
</style>
  • 请将<div class="test"> </div> 中的文字换成你自己的网站的文字。你可以选择将你的博客所有文章内容全选,然后粘贴到此处。
  • 下载你想使用的字体到 fonts 文件夹,然后将 index.html 中的 <font> 换成你下载的字体的前缀。

特别说明: @font-face 中的 src 定义的 .ttf 文件必须存在,其余的格式将由工具自动生成

下面是中文字体对应的英文名称:

新细明体:PMingLiU 
细明体:MingLiU 
标楷体:DFKai-SB 
黑体:SimHei 
宋体:SimSun 
新宋体:NSimSun 
仿宋:FangSong 
楷体:KaiTi 
仿宋_GB2312:FangSong_GB2312 
楷体_GB2312:KaiTi_GB2312 
微软正黑体:Microsoft JhengHei 
微软雅黑体:Microsoft YaHei 

装Office会多出来的一些字体: 
隶书:LiSu 
幼圆:YouYuan 
华文细黑:STXihei 
华文楷体:STKaiti 
华文宋体:STSong 
华文中宋:STZhongsong 
华文仿宋:STFangsong 
方正舒体:FZShuTi 
方正姚体:FZYaoti 
华文彩云:STCaiyun 
华文琥珀:STHupo 
华文隶书:STLiti 
华文行楷:STXingkai 
华文新魏:STXinwei 

苹果电脑中的字体: 
华文细黑:STHeiti Light [STXihei] 
华文黑体:STHeiti 
华文楷体:STKaiti 
华文宋体:STSong 
华文仿宋:STFangsong 
丽黑 Pro:LiHei Pro Medium 
丽宋 Pro:LiSong Pro Light 
标楷体:BiauKai 
苹果丽中黑:Apple LiGothic Medium 
苹果丽细宋:Apple LiSung Light

压缩本地 WebFont

然后执行下面的命令来压缩本地 WebFont:

$ fsp local index/index.html

哦对了,你需要先通过 npm 安装 fsp 命令:

$ npm i font-spider-plus -g

压缩完成后,就会在 fonts 目录下生成压缩后的字体文件:

$ ll fonts/

total 41328
-rw-rw-rw-  1 cnsgyg  staff   7.7K 11 21 01:08 STKaiti.eot
-rw-rw-rw-  1 cnsgyg  staff   8.2K 11 21 01:08 STKaiti.svg
-rw-rw-rw-  1 cnsgyg  staff   7.6K 11 21 01:08 STKaiti.ttf
-rw-rw-rw-  1 cnsgyg  staff   7.7K 11 21 01:08 STKaiti.woff
-rw-rw-rw-  1 cnsgyg  staff   3.9K 11 21 01:08 STKaiti.woff2

压缩之前的字体文件会被移到 fonts 目录下的 .font-spider 目录:

$ ll fonts/.font-spider

total 24880
-rw-rw-rw-  1 cnsgyg  staff    12M 11 21 01:08 STKaiti.ttf

书写 CSS

现在字体压缩完了,怎么应用到自己的网站中呢?也很简单,先写个 CSS 通过 @font-faxe 引入压缩后的字体,格式与第一步中的 index.html 类似:

/* fonts-zh.css */
@font-face {
  font-family: 'font';
  src: url('../fonts/<font>.eot');
  src: url('../fonts/<font>.eot?#font-spider') format('embedded-opentype'),
         url('../fonts/<font>.woff2') format('woff2'),
         url('../fonts/<font>.woff') format('woff'),
         url('../fonts/<font>.ttf') format('truetype'),
         url('../fonts/<font>.svg') format('svg');
  font-weight: normal;
  font-style: normal;
  }

这样还不行,你还需要将压缩后的字体文件拷贝你的网站中,CSS 中通过相对路径要能找到这些字体文件。可我不想这么做,太麻烦了,我还想更简单点。

base64 编码

灵机一动,想到了 base64,编码之后可以不用拷贝这些字体文件,还能减少网站字体的加载体积,真是一箭双雕啊!具体的步骤我就不解释了,直接把所有步骤放到脚本中:

#!/bin/bash

font=STKaiti

eot=$(cat fonts/$font.eot|base64|tr -d '\n')
woff=$(cat fonts/$font.woff|base64|tr -d '\n')
woff2=$(cat fonts/$font.woff2|base64|tr -d '\n')
ttf=$(cat fonts/$font.ttf|base64|tr -d '\n')
svg=$(cat fonts/$font.svg|base64|tr -d '\n')

cat > fonts-zh.css <<EOF
@font-face {
    font-family: '$font';
    src: url(data:application/font-eot;charset=utf-8;base64,$eot) format('eot');
    font-weight: normal;
    font-style: normal;
}
@font-face {
    font-family: '$font';
    src: url(data:application/font-woff2;charset=utf-8;base64,$woff2) format('woff2'),
         url(data:application/font-woff;charset=utf-8;base64,$woff) format('woff'),
     url(data:application/font-ttf;charset=utf-8;base64,$ttf) format('truetype'),
     url(data:application/font-svg;charset=utf-8;base64,$svg) format('svg');
    font-weight: normal;
    font-style: normal;
}
EOF

执行完上面的脚本后,就生成了一个 fonts-zh.css,这是我们唯一需要的东西,不再需要任何额外的文件。

引入 CSS

最后一步就是在你的网站中引入该 CSS,具体的做法大同小异,以 hugo 为例,先将 fonts-zh.css 复制到网站主题目录的 static/css/ 目录下,然后在 <head></head> 中引入该 css,以 beatifulhugo 主题为例,直接在 layouts/partials/head_custom.html 中加上下面一行:

<link rel="stylesheet" href="{{ "css/fonts-zh.css" | absURL }}" />

最后让网站的 body 使用该中文字体,具体的做法是修改 body 的 css,以 hugo 的 beatifulhugo 主题为例,修改 static/css/main.css 中的 body 属性:

body {
  font-family: STKaiti;
  ...
}

可以再加上备用字体,例如:

body {
  font-family: STKaiti,Cambria;
  ...
}

表示如果 STKaiti 字体不可用,将使用 Cambria 字体。到这里就大功告成了,具体的效果可以参考我的网站:https://fuckcloudnative.io/

5. 总结

如果你没有强迫症,到这一步就大功告成了,可我还觉得不够简单,那么多步骤实在是太繁琐了,我要让它们全部自动化,把所有的步骤放到一个自动化脚本中。这还不够,为了造福大众,我在 GitHUb 中新建了一个仓库,所有的脚本和步骤都在上面,有需求的小伙伴可以拿去 happy 啦~~

项目地址:https://github.com/yangchuansheng/font-spider-plus

6. 参考资料

微信公众号

扫一扫下面的二维码关注微信公众号,在公众号中回复◉加群◉即可加入我们的云原生交流群,和孙宏亮、张馆长、阳明等大佬一起探讨云原生技术

如何向纯洁的女朋友解释并发与并行的区别?

原文链接:并发与并行的区别

现在我们都说设计可并行、高并发的程序,而且我们很多时候会在潜意识里觉得自己对并行(Parallelism)和并发(Concurrency)的区别很清楚,但如果要明确的说出二者的区别,又感觉没办法给出一个非常清晰的描述。

那么什么是并发?什么又是并行呢?并行的概念比较简单,并行总是和执行(executions)相关,很多东西同时执行就是并行;而并发则是通过一些方式组织你的程序,让它可以分成多个模块去独立的执行。并行必然是需要多核的,一个处理器是无法并行的;但并发和处理器并没有什么必然联系,在一个处理器上面,我们的程序也可以是并发的。

举个简单的例子,华罗庚泡茶,必须有烧水、洗杯子、拿茶叶等步骤。现在我们想尽快做完这件事,也就是“一共要处理很多事情”,有很多方法可以实现并发,例如请多个人同时做,这就是并行。并行是实现并发的一种方式,但不是唯一的方式。我们一个人也可以实现并发,例如先烧水、然后不用等水烧开就去洗杯子,所以通过调整程序运行方式也可以实现并发。

如果你觉得以上的讲解还是太抽象了,下面通过一个小故事来讲解,故事原型来自 Go 语言创始人之一 Rob Pike 的一篇演讲。

故事的开始有一个需求:有一群地鼠要把一堆废弃的说明书用小推车推到火炉去烧毁。

刚开始只有一只地鼠,使用一辆推车,将书装到车上,运输到火炉旁,将书卸到火炉。完成任务必然需要比较长的时间。

此时如果再增加一只地鼠,那也没什么用,因为一只地鼠在干活,另一只地鼠只能等待。(当然有人说两只地鼠轮流使用一辆推车,这样可以让地鼠得到休息,这样它们干活更快,也可以提高效率。)

再找一辆推车来,两只地鼠分别使用各自的推车,将书装到车上,运输到火炉旁,将书卸到火炉。这样会提高运输效率,但它们会在装书和卸书时进行排队,降低了效率。

这样虽然比之前快了,但还是有瓶颈的。因为书只有一堆,火炉也只有一个,所以我们还必须通过消息来协调两只地鼠的行动。好吧,那我们再把书分成两堆,再增加一个火炉。

这样就比之前的效率高差不多一倍了。现在这个模型就是并发的,因为两只地鼠可以独立完成一件事了,这样提高了运输效率,而且在装书和卸书时不会进行排队,提高了装卸的效率。但这个模型不一定是并行的,比如同一时刻可能只有一只地鼠在干活。

上面就是第一种并发模型,我们还可以设计更多的并发模型,继续看漫画。

这次找了 3 只地鼠,一只负责把书装到车上,一只负责运输,一只负责把书卸到火炉焚烧。每只地鼠做一个独立的任务,当然三只地鼠之间需要使用一些诸如消息通信之类的手段进行协调。

装书和烧书的两只地鼠都很轻松,负责运输的这只地鼠却很累,系统出现了瓶颈。那我们再找一只地鼠来,专门负责运回空推车。

我们在一个已有的设计(指三个地鼠的那个设计)中添加一个并发的步骤(第四只地鼠)增强了系统的性能。这样一来,两只地鼠去搞运输,如果协调的好,理论情况下工作效率将是一只地鼠的 4 倍。

总共有 4 个并发的步骤:

  1. 把书装到车上;
  2. 把推车运到火炉旁;
  3. 把书卸到火炉里;
  4. 运回空推车。

可以再增加一个分组,将这个并发模型并行化。

下面我们再来看另外一种并发模型。负责运输的地鼠抱怨说运输路程太长,那我们就增加一个中转站。

然后再增加一个分组,将这个并发模型并行化,两个分组并行执行。

可以把上面的并发模型再改进一下。增加中转站的同时,再增加两只地鼠,一只负责将从书堆运过来的书卸到中转站,另一只负责将书从中转站装到推车里,再让后面的地鼠运输到火炉旁。

然后再增加一个分组,将这个并发模型并行化。

漫画到这里就结束了,总共介绍了三种并发模型,每种模型都可以很容易地并行化。可以看到上面的并发模型每改进一次,其实就是将任务拆的更细了,一旦分解了问题,并发就自然而然产生了,每个人只专注于一个任务。

回到程序中,书就代表着数据,地鼠就是 CPU,而车可能就是序列化、反序列化、网络等设施,火炉就是代理、浏览器或其他的消费者。而上面的并发模型就是一个可扩展的 Web Service。

该演讲题目为《Concurrency is not Parallelism》,原文链接:

参考链接

微信公众号

扫一扫下面的二维码关注微信公众号,在公众号中回复◉加群◉即可加入我们的云原生交流群,和孙宏亮、张馆长、阳明等大佬一起探讨云原生技术

Linux Capabilities 入门教程:基础实战篇

该系列文章总共分为三篇:

上篇文章介绍了 Linux capabilities 的诞生背景和基本原理,本文将会通过具体的示例来展示如何查看和设置文件的 capabilities。

Linux 系统中主要提供了两种工具来管理 capabilities:libcaplibcap-nglibcap 提供了 getcapsetcap 两个命令来分别查看和设置文件的 capabilities,同时还提供了 capsh 来查看当前 shell 进程的 capabilities。libcap-ng 更易于使用,使用同一个命令 filecap 来查看和设置 capabilities。

1. libcap

安装很简单,以 CentOS 为例,可以通过以下命令安装:

$ yum install -y libcap

如果想查看当前 shell 进程的 capabilities,可以用 capsh 命令。下面是 CentOS 系统中的 root 用户执行 capsh 的输出:

$ capsh --print

Current: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read+ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=0(root)

解释一下:

  • Current : 表示当前 shell 进程的 Effective capabilities 和 Permitted capabilities。可以包含多个分组,每一个分组的表示形式为 capability[,capability…]+(e|i|p),其中 e 表示 effective,i 表示 inheritable,p 表示 permitted。不同的分组之间通过空格隔开,例如:Current: = cap_sys_chroot+ep cap_net_bind_service+eip。再举一个例子,cap_net_bind_service+e cap_net_bind_service+ipcap_net_bind_service+eip 等价。

  • Bounding set : 这里仅仅表示 Bounding 集合中的 capabilities,不包括其他集合,所以分组的末尾不用加上 +...

  • Securebits : 我也没搞清楚这是个什么鬼。

这个命令输出的信息比较有限,完整的信息可以查看 /proc 文件系统,比如当前 shell 进程就可以查看 /proc/$$/status。其中一个重要的状态就是 NoNewPrivs,可以通过以下命令查看:

grep NoNewPrivs /proc/$$/status

NoNewPrivs:    0

根据 prctl(2) 中的描述,自从 Linux 4.10 开始,/proc/[pid]/status 中的 NoNewPrivs 值表示了线程的 no_new_privs 属性。至于 no_new_privs究竟是干嘛的,下面我单独解释一下。

no_new_privs

一般情况下,execve() 系统调用能够赋予新启动的进程其父进程没有的权限,最常见的例子就是通过 setuidsetgid 来设置程序进程的 uid 和 gid 以及文件的访问权限。这就给不怀好意者钻了不少空子,可以直接通过 fork 来提升进程的权限,从而达到不可告人的目的。

为了解决这个问题,Linux 内核从 3.5 版本开始,引入了 no_new_privs 属性(实际上就是一个 bit,可以开启和关闭),提供给进程一种能够在 execve() 调用整个阶段都能持续有效且安全的方法。

  • 开启了 no_new_privs 之后,execve 函数可以确保所有操作都必须调用 execve() 判断并赋予权限后才能被执行。这就确保了线程及子线程都无法获得额外的权限,因为无法执行 setuid 和 setgid,也不能设置文件的权限。

  • 一旦当前线程的 no_new_privs 被置位后,不论通过 fork,clone 或 execve 生成的子线程都无法将该位清零。

Docker 中可以通过参数 --security-opt 来开启 no_new_privs 属性,例如:docker run --security-opt=no_new_privs busybox。下面通过一个例子来体会一下 no_new_privs 属性的作用。

首先撸一段 C 代码,显示当前进程的有效用户 id:

$ cat testnnp.c

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>

int main(int argc, char *argv[])
{
        printf("Effective uid: %d\n", geteuid());
        return 0;
}
$ make testnnp
cc     testnnp.c   -o testnnp

将可执行文件打入 docker 镜像中:

FROM fedora:latest
ADD testnnp /root/testnnp
RUN chmod +s /root/testnnp
ENTRYPOINT /root/testnnp

构建镜像:

$ docker build -t testnnp .
Step 1 : FROM fedora:latest
 ---> 760a896a323f
Step 2 : ADD testnnp /root/testnnp
 ---> 6c700f277948
Removing intermediate container 0981144fe404
Step 3 : RUN chmod +s /root/testnnp
 ---> Running in c1215bfbe825
 ---> f1f07d05a691
Removing intermediate container c1215bfbe825
Step 4 : ENTRYPOINT /root/testnnp
 ---> Running in 5a4d324d54fa
 ---> 44f767c67e30
Removing intermediate container 5a4d324d54fa
Successfully built 44f767c67e30

下面来做两个实验,先在没有开启 no-new-privileges 的情况下启动容器:

$ docker run -it --rm --user=1000  testnnp
Effective uid: 0

从输出结果来看,只要给可执行文件设置了 SUID 标识,即使我们使用普通用户(UID=1000)来运行容器,进程的有效用户也会变成 root。

接着在开启 no-new-privileges 的前提下启动容器,以防止执行设置了 SUID 标识的可执行文件进行 UID 转换:

$ docker run -it --rm --user=1000 --security-opt=no-new-privileges testnnp
Effective uid: 1000

可以看到,开启了 no_new_privs 属性之后,即使可执行文件设置了 SUID 标识,线程的有效用户 ID 也不会变成 root。这样即使镜像中的代码有安全风险,仍然可以通过防止其提升权限来避免受到攻击。

Kubernetes 也可以开启 no_new_privs,不过逻辑稍微复杂一点。当 Pod 的 SecurityContext 定义下的 allowPrivilegeEscalation 字段值为 false 时(默认就是 false),如果不满足以下任何一个条件,就会开启 no_new_privs 属性:

  • 设置了 privileged=true

  • 增加了 CAP_SYS_ADMIN capabilities,即 capAdd=CAP_SYS_ADMIN

  • 以 root 用户运行,即 UID=0

例如,当设置了 privileged=trueallowPrivilegeEscalation=false 时,就不会开启 no_new_privs 属性。同理,设置了 capAdd=CAP_SYS_ADMINallowPrivilegeEscalation=false 也不会开启 no_new_privs 属性。

管理 capabilities

可以通过 getcap 来查看文件的 capabilities,例如:

$ getcap /bin/ping /usr/sbin/arping

/bin/ping = cap_net_admin,cap_net_raw+p
/usr/sbin/arping = cap_net_raw+p

也可以使用 -r 参数来递归查询:

$ getcap -r /usr 2>/dev/null

/usr/bin/ping = cap_net_admin,cap_net_raw+p
/usr/bin/newgidmap = cap_setgid+ep
/usr/bin/newuidmap = cap_setuid+ep
/usr/sbin/arping = cap_net_raw+p
/usr/sbin/clockdiff = cap_net_raw+p

如果想查看某个进程的 capabilities,可以直接使用 getpcaps,后面跟上进程的 PID:

$ getpcaps 1234

如果想查看一组相互关联的线程的 capabilities(比如 nginx),可以这么来看:

$ getpcaps $(pgrep nginx)

这里你会看到只有主线程才有 capabilities,子线程和其他 workers 都没有 capabilities,这是因为只有 master 才需要特殊权限,例如监听网络端口,其他线程只需要响应请求就好了。

设置文件的 capabilities 可以使用 setcap,语法如下:

$ setcap CAP+set filename

例如,将 CAP_CHOWNCAP_DAC_OVERRIDE capabilities 添加到 permittedeffective 集合:

$ setcap CAP_CHOWN,CAP_DAC_OVERRIDE+ep file1

如果想移除某个文件的 capabilities,可以使用 -r 参数:

$ setcap -r filename

2. libcap-ng

安装也很简单,以 CentOS 为例:

$ yum install libcap-ng-utils

用法

libcap-ng 使用 filecap 命令来管理文件的 capabilities。有几个需要注意的地方:

  • filecap 添加删除或查看 capabilities 时,capabilities 的名字不需要带 CAP_ 前缀(例如,使用 NET_ADMIN 代替 CAP_NET_ADMIN);

  • filecap 不支持相对路径,只支持绝对路径;

  • filecap 不允许指定 capabilities 作用的集合,capabilities 只会被添加到 permittedeffective 集合。

查看文件的 capabilities:

$ filecap /full/path/to/file

递归查看某个目录下所有文件的 capabilities:

$ filecap /full/path/to/dir

例如:

$ filecap /usr/bin

file                 capabilities
/usr/bin/newgidmap     setgid
/usr/bin/newuidmap     setuid

注意: filecap 只会显示“capabilities 被添加到 permittedeffective 集合中”的文件。所以这里没有显示 ping 和 arping。

递归查看整个系统所有文件的 capabilities:

$ filecap /
# or
$ filecap -a

设置文件的 capabilities 语法如下:

$ filecap /full/path/to/file cap_name

例如:

$ filecap /usr/bin/tac dac_override

移除某个文件的 capabilities:

$ filecap /full/path/to/file none

3. 总结

本文通过两种工具演示了如何对可执行文件的 capabilities 进行管理,并以 docker 为例,展现了 no_new_privs 的强大之处。如果条件允许,推荐大家以后尽量用 capabilities 来替代完整的 root 权限或者设置 SUID 标识。

4. 参考资料

微信公众号

扫一扫下面的二维码关注微信公众号,在公众号中回复◉加群◉即可加入我们的云原生交流群,和孙宏亮、张馆长、阳明等大佬一起探讨云原生技术

Linux Capabilities 入门教程:概念篇

原文链接:Linux Capabilities 入门教程:概念篇

Linux 是一种安全的操作系统,它把所有的系统权限都赋予了一个单一的 root 用户,只给普通用户保留有限的权限。root 用户拥有超级管理员权限,可以安装软件、允许某些服务、管理用户等。

作为普通用户,如果想执行某些只有管理员才有权限的操作,以前只有两种办法:一是通过 sudo 提升权限,如果用户很多,配置管理和权限控制会很麻烦;二是通过 SUID(Set User ID on execution)来实现,它可以让普通用户允许一个 owner 为 root 的可执行文件时具有 root 的权限。

SUID 的概念比较晦涩难懂,举个例子就明白了,以常用的 passwd 命令为例,修改用户密码是需要 root 权限的,但普通用户却可以通过这个命令来修改密码,这就是因为 /bin/passwd 被设置了 SUID 标识,所以普通用户执行 passwd 命令时,进程的 owner 就是 passwd 的所有者,也就是 root 用户。

SUID 虽然可以解决问题,但却带来了安全隐患。当运行设置了 SUID 的命令时,通常只是需要很小一部分的特权,但是 SUID 给了它 root 具有的全部权限。这些可执行文件是黑客的主要目标,如果他们发现了其中的漏洞,就很容易利用它来进行安全攻击。简而言之,SUID 机制增大了系统的安全攻击面。

为了对 root 权限进行更细粒度的控制,实现按需授权,Linux 引入了另一种机制叫 capabilities

1. Linux capabilities 是什么?

Capabilities 机制是在 Linux 内核 2.2 之后引入的,原理很简单,就是将之前与超级用户 root(UID=0)关联的特权细分为不同的功能组,Capabilites 作为线程(Linux 并不真正区分进程和线程)的属性存在,每个功能组都可以独立启用和禁用。其本质上就是将内核调用分门别类,具有相似功能的内核调用被分到同一组中。

这样一来,权限检查的过程就变成了:在执行特权操作时,如果线程的有效身份不是 root,就去检查其是否具有该特权操作所对应的 capabilities,并以此为依据,决定是否可以执行特权操作。

Capabilities 可以在进程执行时赋予,也可以直接从父进程继承。所以理论上如果给 nginx 可执行文件赋予了 CAP_NET_BIND_SERVICE capabilities,那么它就能以普通用户运行并监听在 80 端口上。

capability 名称 描述
CAP_AUDIT_CONTROL 启用和禁用内核审计;改变审计过滤规则;检索审计状态和过滤规则
CAP_AUDIT_READ 允许通过 multicast netlink 套接字读取审计日志
CAP_AUDIT_WRITE 将记录写入内核审计日志
CAP_BLOCK_SUSPEND 使用可以阻止系统挂起的特性
CAP_CHOWN 修改文件所有者的权限
CAP_DAC_OVERRIDE 忽略文件的 DAC 访问限制
CAP_DAC_READ_SEARCH 忽略文件读及目录搜索的 DAC 访问限制
CAP_FOWNER 忽略文件属主 ID 必须和进程用户 ID 相匹配的限制
CAP_FSETID 允许设置文件的 setuid 位
CAP_IPC_LOCK 允许锁定共享内存片段
CAP_IPC_OWNER 忽略 IPC 所有权检查
CAP_KILL 允许对不属于自己的进程发送信号
CAP_LEASE 允许修改文件锁的 FL_LEASE 标志
CAP_LINUX_IMMUTABLE 允许修改文件的 IMMUTABLE 和 APPEND 属性标志
CAP_MAC_ADMIN 允许 MAC 配置或状态更改
CAP_MAC_OVERRIDE 忽略文件的 DAC 访问限制
CAP_MKNOD 允许使用 mknod() 系统调用
CAP_NET_ADMIN 允许执行网络管理任务
CAP_NET_BIND_SERVICE 允许绑定到小于 1024 的端口
CAP_NET_BROADCAST 允许网络广播和多播访问
CAP_NET_RAW 允许使用原始套接字
CAP_SETGID 允许改变进程的 GID
CAP_SETFCAP 允许为文件设置任意的 capabilities
CAP_SETPCAP 参考 capabilities man page
CAP_SETUID 允许改变进程的 UID
CAP_SYS_ADMIN 允许执行系统管理任务,如加载或卸载文件系统、设置磁盘配额等
CAP_SYS_BOOT 允许重新启动系统
CAP_SYS_CHROOT 允许使用 chroot() 系统调用
CAP_SYS_MODULE 允许插入和删除内核模块
CAP_SYS_NICE 允许提升优先级及设置其他进程的优先级
CAP_SYS_PACCT 允许执行进程的 BSD 式审计
CAP_SYS_PTRACE 允许跟踪任何进程
CAP_SYS_RAWIO 允许直接访问 /devport、/dev/mem、/dev/kmem 及原始块设备
CAP_SYS_RESOURCE 忽略资源限制
CAP_SYS_TIME 允许改变系统时钟
CAP_SYS_TTY_CONFIG 允许配置 TTY 设备
CAP_SYSLOG 允许使用 syslog() 系统调用
CAP_WAKE_ALARM 允许触发一些能唤醒系统的东西(比如 CLOCK_BOOTTIME_ALARM 计时器)

2. capabilities 的赋予和继承

Linux capabilities 分为进程 capabilities 和文件 capabilities。对于进程来说,capabilities 是细分到线程的,即每个线程可以有自己的capabilities。对于文件来说,capabilities 保存在文件的扩展属性中。

下面分别介绍线程(进程)的 capabilities 和文件的 capabilities。

线程的 capabilities

每一个线程,具有 5 个 capabilities 集合,每一个集合使用 64 位掩码来表示,显示为 16 进制格式。这 5 个 capabilities 集合分别是:

  • Permitted
  • Effective
  • Inheritable
  • Bounding
  • Ambient

每个集合中都包含零个或多个 capabilities。这5个集合的具体含义如下:

Permitted

定义了线程能够使用的 capabilities 的上限。它并不使能线程的 capabilities,而是作为一个规定。也就是说,线程可以通过系统调用 capset() 来从 EffectiveInheritable 集合中添加或删除 capability,前提是添加或删除的 capability 必须包含在 Permitted 集合中(其中 Bounding 集合也会有影响,具体参考下文)。 如果某个线程想向 Inheritable 集合中添加或删除 capability,首先它的 Effective 集合中得包含 CAP_SETPCAP 这个 capabiliy。

Effective

内核检查线程是否可以进行特权操作时,检查的对象便是 Effective 集合。如之前所说,Permitted 集合定义了上限,线程可以删除 Effective 集合中的某 capability,随后在需要时,再从 Permitted 集合中恢复该 capability,以此达到临时禁用 capability 的功能。

Inheritable

当执行exec() 系统调用时,能够被新的可执行文件继承的 capabilities,被包含在 Inheritable 集合中。这里需要说明一下,包含在该集合中的 capabilities 并不会自动继承给新的可执行文件,即不会添加到新线程的 Effective 集合中,它只会影响新线程的 Permitted 集合。

Bounding

Bounding 集合是 Inheritable 集合的超集,如果某个 capability 不在 Bounding 集合中,即使它在 Permitted 集合中,该线程也不能将该 capability 添加到它的 Inheritable 集合中。

Bounding 集合的 capabilities 在执行 fork() 系统调用时会传递给子进程的 Bounding 集合,并且在执行 execve 系统调用后保持不变。

  • 当线程运行时,不能向 Bounding 集合中添加 capabilities。
  • 一旦某个 capability 被从 Bounding 集合中删除,便不能再添加回来。
  • 将某个 capability 从 Bounding 集合中删除后,如果之前 Inherited 集合包含该 capability,将继续保留。但如果后续从 Inheritable 集合中删除了该 capability,便不能再添加回来。

Ambient

Linux 4.3 内核新增了一个 capabilities 集合叫 Ambient ,用来弥补 Inheritable 的不足。Ambient 具有如下特性:

  • PermittedInheritable 未设置的 capabilities,Ambient 也不能设置。
  • PermittedInheritable 关闭某权限(比如 CAP_SYS_BOOT)后,Ambient 也随之关闭对应权限。这样就确保了降低权限后子进程也会降低权限。
  • 非特权用户如果在 Permitted 集合中有一个 capability,那么可以添加到 Ambient 集合中,这样它的子进程便可以在 AmbientPermittedEffective 集合中获取这个 capability。现在不知道为什么也没关系,后面会通过具体的公式来告诉你。

Ambient 的好处显而易见,举个例子,如果你将 CAP_NET_ADMIN 添加到当前进程的 Ambient 集合中,它便可以通过 fork()execve() 调用 shell 脚本来执行网络管理任务,因为 CAP_NET_ADMIN 会自动继承下去。

文件的 capabilities

文件的 capabilities 被保存在文件的扩展属性中。如果想修改这些属性,需要具有 CAP_SETFCAP 的 capability。文件与线程的 capabilities 共同决定了通过 execve() 运行该文件后的线程的 capabilities。

文件的 capabilities 功能,需要文件系统的支持。如果文件系统使用了 nouuid 选项进行挂载,那么文件的 capabilities 将会被忽略。

类似于线程的 capabilities,文件的 capabilities 包含了 3 个集合:

  • Permitted
  • Inheritable
  • Effective

这3个集合的具体含义如下:

Permitted

这个集合中包含的 capabilities,在文件被执行时,会与线程的 Bounding 集合计算交集,然后添加到线程的 Permitted 集合中。

Inheritable

这个集合与线程的 Inheritable 集合的交集,会被添加到执行完 execve() 后的线程的 Permitted 集合中。

Effective

这不是一个集合,仅仅是一个标志位。如果设置开启,那么在执行完 execve() 后,线程 Permitted 集合中的 capabilities 会自动添加到它的 Effective 集合中。对于一些旧的可执行文件,由于其不会调用 capabilities 相关函数设置自身的 Effective 集合,所以可以将可执行文件的 Effective bit 开启,从而可以将 Permitted 集合中的 capabilities 自动添加到 Effective 集合中。

详情请参考 Linux capabilities 的 man page

3. 运行 execve() 后 capabilities 的变化

上面介绍了线程和文件的 capabilities,你们可能会觉得有些抽象难懂。下面通过具体的计算公式,来说明执行 execve() 后 capabilities 是如何被确定的。

我们用 P 代表执行 execve() 前线程的 capabilities,P' 代表执行 execve() 后线程的 capabilities,F 代表可执行文件的 capabilities。那么:

P'(ambient) = (file is privileged) ? 0 : P(ambient)

P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding))) | P'(ambient)

P'(effective)   = F(effective) ? P'(permitted) : P'(ambient)

P'(inheritable) = P(inheritable) [i.e., unchanged]

P'(bounding) = P(bounding) [i.e., unchanged]

我们一条一条来解释:

  • 如果用户是 root 用户,那么执行 execve() 后线程的 Ambient 集合是空集;如果是普通用户,那么执行 execve() 后线程的 Ambient 集合将会继承执行 execve() 前线程的 Ambient 集合。

  • 执行 execve() 前线程的 Inheritable 集合与可执行文件的 Inheritable 集合取交集,会被添加到执行 execve() 后线程的 Permitted 集合;可执行文件的 capability bounding 集合与可执行文件的 Permitted 集合取交集,也会被添加到执行 execve() 后线程的 Permitted 集合;同时执行 execve() 后线程的 Ambient 集合中的 capabilities 会被自动添加到该线程的 Permitted 集合中。
  • 如果可执行文件开启了 Effective 标志位,那么在执行完 execve() 后,线程 Permitted 集合中的 capabilities 会自动添加到它的 Effective 集合中。
  • 执行 execve() 前线程的 Inheritable 集合会继承给执行 execve() 后线程的 Inheritable 集合。

这里有几点需要着重强调:

  1. 上面的公式是针对系统调用 execve() 的,如果是 fork(),那么子线程的 capabilities 信息完全复制父进程的 capabilities 信息。

  2. 可执行文件的 Inheritable 集合与线程的 Inheritable 集合并没有什么关系,可执行文件 Inheritable 集合中的 capabilities 不会被添加到执行 execve() 后线程的 Inheritable 集合中。如果想让新线程的 Inheritable 集合包含某个 capability,只能通过 capset() 将该 capability 添加到当前线程的 Inheritable 集合中(因为 P'(inheritable) = P(inheritable))。

  3. 如果想让当前线程 Inheritable 集合中的 capabilities 传递给新的可执行文件,该文件的 Inheritable 集合中也必须包含这些 capabilities(因为 P'(permitted)   = (P(inheritable) & F(inheritable))|…)。

  4. 将当前线程的 capabilities 传递给新的可执行文件时,仅仅只是传递给新线程的 Permitted 集合。如果想让其生效,新线程必须通过 capset() 将 capabilities 添加到 Effective 集合中。或者开启新的可执行文件的 Effective 标志位(因为 P'(effective)   = F(effective) ? P'(permitted) : P'(ambient))。

  5. 在没有 Ambient 集合之前,如果某个脚本不能调用 capset(),但想让脚本中的线程都能获得该脚本的 Permitted 集合中的 capabilities,只能将 Permitted 集合中的 capabilities 添加到 Inheritable 集合中(P'(permitted)  = P(inheritable) & F(inheritable)|…),同时开启 Effective 标志位(P'(effective)   = F(effective) ? P'(permitted) : P'(ambient))。有 有 Ambient 集合之后,事情就变得简单多了,后续的文章会详细解释。

  6. 如果某个 UID 非零(普通用户)的线程执行了 execve(),那么 PermittedEffective 集合中的 capabilities 都会被清空。

  7. 从 root 用户切换到普通用户,那么 PermittedEffective 集合中的 capabilities 都会被清空,除非设置了 SECBIT_KEEP_CAPS 或者更宽泛的 SECBIT_NO_SETUID_FIXUP。

关于上述计算公式的逻辑流程图如下所示(不包括 Ambient 集合):

4. 简单示例

下面我们用一个例子来演示上述公式的计算逻辑,以 ping 文件为例。如果我们将 CAP_NET_RAW capability添加到 ping 文件的 Permitted 集合中(F(Permitted)),它就会添加到执行后的线程的 Permitted 集合中(P'(Permitted))。由于 ping 文件具有 capabilities 意识,即能够调用 capset()capget() ,它在运行时会调用 capset()CAP_NET_RAW capability 添加到线程的 Effective 集合中。

换句话说,如果可执行文件不具有 capabilities 意识,我们就必须要开启 Effective 标志位(F(Effective)),这样就会将该 capability 自动添加到线程的 Effective 集合中。具有capabilities 意识的可执行文件更安全,因为它会限制线程使用该 capability 的时间。

我们也可以将 capabilities 添加到文件的 Inheritable 集合中,文件的 Inheritable 集合会与当前线程的 Inheritable 集合取交集,然后添加到新线程的 Permitted 集合中。这样就可以控制可执行文件的运行环境。

看起来很有道理,但有一个问题:如果可执行文件的有效用户是普通用户,且没有 Inheritable 集合,即 F(inheritable) = 0,那么 P(inheritable) 将会被忽略(P(inheritable) & F(inheritable))。由于绝大多数可执行文件都是这种情况,因此 Inheritable 集合的可用性受到了限制。我们无法让脚本中的线程自动继承该脚本文件中的 capabilities,除非让脚本具有 capabilities 意识

要想改变这种状况,可以使用 Ambient 集合。Ambient 集合会自动从父线程中继承,同时会自动添加到当前线程的 Permitted 集合中。举个例子,在一个 Bash 环境中(例如某个正在执行的脚本),该环境所在的线程的 Ambient 集合中包含 CAP_NET_RAW capability,那么在该环境中执行 ping 文件可以正常工作,即使该文件是普通文件(没有任何 capabilities,也没有设置 SUID)。

5. 终极案例

最后拿 docker 举例,如果你使用普通用户来启动官方的 nginx 容器,会出现以下错误:

bind() to 0.0.0.0:80 failed (13: Permission denied)

因为 nginx 进程的 Effective 集合中不包含 CAP_NET_BIND_SERVICE capability,且不具有 capabilities 意识(普通用户),所以启动失败。要想启动成功,至少需要将该 capability 添加到 nginx 文件的 Inheritable 集合中,同时开启 Effective 标志位,并且在 Kubernetes Pod 的部署清单中的 securityContext –> capabilities 字段下面添加 NET_BIND_SERVICE(这个 capability 会被添加到 nginx 进程的 Bounding 集合中),最后还要将 capability 添加到 nginx 文件的 Permitted 集合中。如此一来就大功告成了,参考公式:P'(permitted) = ...|(F(permitted) & P(bounding)))|...P'(effective) = F(effective) ? P'(permitted) : P'(ambient)

如果容器开启了 securityContext/allowPrivilegeEscalation,上述设置仍然可以生效。如果 nginx 文件具有 capabilities 意识,那么只需要将 CAP_NET_BIND_SERVICE capability 添加到它的 Inheritable 集合中就可以正常工作了。

当然了,除了上述使用文件扩展属性的方法外,还可以使用 Ambient 集合来让非 root 容器进程正常工作,但 Kubernetes 目前还不支持这个属性,具体参考 Kubernetes 项目的 issue

虽然 Kubernetes 官方不支持,但我们可以自己来实现,具体实现方式可以关注我后续的文章。

6. 参考资料

微信公众号

扫一扫下面的二维码关注微信公众号,在公众号中回复◉加群◉即可加入我们的云原生交流群,和孙宏亮、张馆长、阳明等大佬一起探讨云原生技术

Podman 使用指南

原文链接:Podman 使用指南

Podman 原来是 CRI-O 项目的一部分,后来被分离成一个单独的项目叫 libpod。Podman 的使用体验和 Docker 类似,不同的是 Podman 没有 daemon。以前使用 Docker CLI 的时候,Docker CLI 会通过 gRPC API 去跟 Docker Engine 说「我要启动一个容器」,然后 Docker Engine 才会通过 OCI Container runtime(默认是 runc)来启动一个容器。这就意味着容器的进程不可能是 Docker CLI 的子进程,而是 Docker Engine 的子进程。

Podman 比较简单粗暴,它不使用 Daemon,而是直接通过 OCI runtime(默认也是 runc)来启动容器,所以容器的进程是 podman 的子进程。这比较像 Linux 的 fork/exec 模型,而 Docker 采用的是 C/S(客户端/服务器)模型。与 C/S 模型相比,fork/exec 模型有很多优势,比如:

  • 系统管理员可以知道某个容器进程到底是谁启动的。

  • 如果利用 cgroup 对 podman 做一些限制,那么所有创建的容器都会被限制。

  • SD_NOTIFY : 如果将 podman 命令放入 systemd 单元文件中,容器进程可以通过 podman 返回通知,表明服务已准备好接收任务。

  • socket 激活 : 可以将连接的 socket 从 systemd 传递到 podman,并传递到容器进程以便使用它们。

废话不多说,下面我们直接进入实战环节,本文将手把手教你如何用 podman 来部署静态博客,并通过 Sidecar 模式将博客所在的容器加入到 Envoy mesh 之中。

1. 方案架构

我的部署方案涉及到两层 Envoy:

  • 首先会有一个前端代理单独跑一个容器。前端代理的工作是给访问者提供一个入口,将来自外部的访问请求转发到具体的后端服务。

  • 其次,博客静态页面由 nginx 提供,同时以 Sidecar 模式运行一个 Envoy 容器,它与 nginx 共享 network nemspace

  • 所有的 Envoy 形成一个 mesh,然后在他们之间共享路由信息。

我之前写过一篇用 Docker 部署 hugo 静态博客并配置 HTTPS 证书的文章,本文采用的是相同的方案,只是将 docker 换成了 podman,具体参考为 Envoy 开启 TLS 验证实战

2. 部署 hugo 和 sidecar proxy

我的博客是通过 hugo 生成的静态页面,可以将其放到 nginx 中,其他静态网站工具类似(比如 hexo 等),都可以这么做。现在我要做的是让 nginx 容器和 envoy 容器共享同一个 network namespace,同时还要让前端代理能够通过域名来进行服务发现。以前用 docker 很简单,直接用 docker-compose 就搞定了,podman 就比较麻烦了,它又不能用 docker-compose,服务发现看来是搞不定了。

好不容易在 Github 上发现了一个项目叫 podman-compose,以为有救了,试用了一下发现还是不行,podman-compose 创建容器时会将字段 network_mode: "service:hugo" 转化为 podman CLI 的参数 --network service:hugo(真脑残),导致容器创建失败,报错信息为 CNI network "service:hugo" not found。将该字段值改为 network_mode: "container:hugo_hugo_1" 可以启动成功,然而又引来了另一个问题:podman-compose 的做法是为每一个 service 创建一个 pod(pod 的名字为 docker-compose.yml 所在目录名称),然后往这个 pod 中添加容器。我总不能将前端代理和后端服务塞进同一个 pod 中吧?只能分别为前端代理和 hugo 创建两个目录,然后分别创建 docker-compose.yml。这个问题解决了,下个问题又来了,podman-compose 不支持通过 service name 进行服务发现,扒了一圈发现支持 links(其实就是加个参数 --add-host),然而 links 只在同一个 pod 下才生效,我都拆分成两个 pod 了,links 鞭长莫及啊,还是没什么卵用。我能怎么办,现在唯一的办法就是手撸命令行了。

上面我提到了一个新名词叫 pod,这里花 30 秒的时间给大家简单介绍一下,如果你是 Kubernetes 的重度使用者,对这个词应该不陌生,但这里确实说的是 podman 的 pod,意思还是一样的,先创建一个 pause 容器,然后再创建业务容器,业务容器共享 pause 容器的各种 linux namespace,因此同一个 pod 中的容器之间可以通过 localhost 轻松地相互通信。不仅如此,podman 还可以将 pod 导出为 Kubernetes 的声明式资源定义,举个栗子:

先创建一个 pod:

$ podman pod create --name hugo

查看 pod:

$ podman pod ls

POD ID         NAME   STATUS    CREATED         # OF CONTAINERS   INFRA ID
88226423c4d2   hugo   Running   2 minutes ago   2                 7e030ef2e7ca

在这个 pod 中启动一个 hugo 容器:

$ podman run -d --pod hugo nginx:alpine

查看容器:

$ podman ps

CONTAINER ID  IMAGE                           COMMAND               CREATED        STATUS            PORTS  NAMES
3c91cab1e99d  docker.io/library/nginx:alpine  nginx -g daemon o...  3 minutes ago  Up 3 minutes ago         reverent_kirch

查看所有容器,包括 pause 容器:

$ podman ps -a

CONTAINER ID  IMAGE                           COMMAND               CREATED        STATUS            PORTS  NAMES
3c91cab1e99d  docker.io/library/nginx:alpine  nginx -g daemon o...  4 minutes ago  Up 4 minutes ago         reverent_kirch
7e030ef2e7ca  k8s.gcr.io/pause:3.1                                  6 minutes ago  Up 6 minutes ago         88226423c4d2-infra

查看所有容器,包括 pause 容器,并显示容器所属的 pod id:

$ podman ps -ap

CONTAINER ID  IMAGE                           COMMAND               CREATED        STATUS            PORTS  NAMES               POD
3c91cab1e99d  docker.io/library/nginx:alpine  nginx -g daemon o...  4 minutes ago  Up 4 minutes ago         reverent_kirch      88226423c4d2
7e030ef2e7ca  k8s.gcr.io/pause:3.1                                  6 minutes ago  Up 6 minutes ago         88226423c4d2-infra  88226423c4d2

查看 pod 中进程的资源使用情况:

$ podman pod top hugo

USER    PID   PPID   %CPU    ELAPSED           TTY   TIME   COMMAND
root    1     0      0.000   8m5.045493912s    ?     0s     nginx: master process nginx -g daemon off;
nginx   6     1      0.000   8m5.045600833s    ?     0s     nginx: worker process
nginx   7     1      0.000   8m5.045638877s    ?     0s     nginx: worker process
0       1     0      0.000   9m41.051039367s   ?     0s     /pause

将 pod 导出为声明式部署清单:

$ podman generate kube hugo > hugo.yaml

查看部署清单内容:

$ cat hugo.yaml

# Generation of Kubernetes YAML is still under development!
#
# Save the output of this file and use kubectl create -f to import
# it into Kubernetes.
#
# Created with podman-1.0.2-dev
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: 2019-10-17T04:17:40Z
  labels:
    app: hugo
  name: hugo
spec:
  containers:
  - command:
    - nginx
    - -g
    - daemon off;
    env:
    - name: PATH
      value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    - name: TERM
      value: xterm
    - name: HOSTNAME
    - name: container
      value: podman
    - name: NGINX_VERSION
      value: 1.17.4
    - name: NJS_VERSION
      value: 0.3.5
    - name: PKG_RELEASE
      value: "1"
    image: docker.io/library/nginx:alpine
    name: reverentkirch
    resources: {}
    securityContext:
      allowPrivilegeEscalation: true
      capabilities: {}
      privileged: false
      readOnlyRootFilesystem: false
    workingDir: /
status: {}

怎么样,是不是有种熟悉的味道?这是一个兼容 kubernetes 的 pod 定义,你可以直接通过 kubectl apply -f hugo.yaml 将其部署在 Kubernetes 集群中,也可以直接通过 podman 部署,步骤大致是这样的:

先删除之前创建的 pod:

$ podman pod rm -f hugo

然后通过部署清单创建 pod:

$ podman play kube hugo.yaml

回到之前的问题,如果通过声明式定义来创建 pod,还是无法解决服务发现的问题,除非换个支持静态 IP 的 CNI 插件,而支持静态 IP 的这些 CNI 插件又需要 etcd 作为数据库,我就这么点资源,可不想再加个 etcd,还是手撸命令行吧。

首先我要创建一个 hugo 容器,并指定容器的 IP:

$ podman run -d --name hugo \
  --ip=10.88.0.10 \
  -v /opt/hugo/public:/usr/share/nginx/html \
  -v /etc/localtime:/etc/localtime \
  nginx:alpine

再创建一个 envoy 容器,与 hugo 容器共享 network namespace:

$ podman run -d --name hugo-envoy \
  -v /opt/hugo/service-envoy.yaml:/etc/envoy/envoy.yaml \
  -v /etc/localtime:/etc/localtime \
  --net=container:hugo envoyproxy/envoy-alpine:latest

service-envoy.yaml 的内容如下:

static_resources:
  listeners:
  - address:
      socket_address:
        address: 0.0.0.0
        port_value: 8080
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          codec_type: auto
          stat_prefix: ingress_http
          access_log:
          - name: envoy.file_access_log
            config:
              path: "/dev/stdout"
          route_config:
            name: local_route
            virtual_hosts:
            - name: service
              domains:
              - "*"
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: local_service
          http_filters:
          - name: envoy.router
            config: {}
  clusters:
  - name: local_service
    connect_timeout: 0.25s
    type: strict_dns
    lb_policy: round_robin
    hosts:
    - socket_address:
        address: 127.0.0.1
        port_value: 80
admin:
  access_log_path: "/dev/null"
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 8081

具体的含义请参考为 Envoy 开启 TLS 验证实战

本文开头提到 podman 创建的容器是 podman 的子进程,这个表述可能比较模糊,实际上 podman 由两部分组成,一个是 podman CLI,还有一个是 container runtime,container runtime 由 conmon 来负责,主要包括监控、日志、TTY 分配以及类似 out-of-memory 情况的杂事。也就是说,conmon 是所有容器的父进程。

conmon 需要去做所有 systemd 不做或者不想做的事情。即使 CRI-O 不直接使用 systemd 来管理容器,它也将容器分配到 sytemd 兼容的 cgroup 中,这样常规的 systemd 工具比如 systemctl 就可以看见容器资源使用情况了。

$ podman ps

CONTAINER ID  IMAGE                                     COMMAND               CREATED             STATUS                 PORTS  NAMES
42762bf7d37a  docker.io/envoyproxy/envoy-alpine:latest  /docker-entrypoin...  About a minute ago  Up About a minute ago         hugo-envoy
f0204fdc9524  docker.io/library/nginx:alpine            nginx -g daemon o...  2 minutes ago       Up 2 minutes ago              hugo

对 cgroup 不熟的同学,可以参考下面这个系列:

零基础的同学建议按照上面的目录从上到下打怪升级,祝你好运!

3. 部署前端代理

这个很简单,直接创建容器就好了:

$ podman run -d --name front-envoy \
--add-host=hugo:10.88.0.10 \
-v /opt/hugo/front-envoy.yaml:/etc/envoy/envoy.yaml \
-v /etc/localtime:/etc/localtime \
-v /root/.acme.sh/yangcs.net:/root/.acme.sh/yangcs.net \
--net host envoyproxy/envoy

由于没办法自动服务发现,需要通过参数 --add-host 手动添加 hosts 到容器中。envoy 的配置文件中是通过域名来添加 cluster 的,front-envoy.yaml 内容如下:

static_resources:
  listeners:
  - address:
      socket_address:
        address: 0.0.0.0
        port_value: 80
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          codec_type: auto
          stat_prefix: ingress_http
          access_log:
          - name: envoy.file_access_log
            config:
              path: "/dev/stdout"
          route_config:
            virtual_hosts:
            - name: backend
              domains:
              - "*"
              routes:
              - match:
                  prefix: "/"
                redirect:
                  https_redirect: true
                  response_code: "FOUND"
          http_filters:
          - name: envoy.router
            config: {}
  - address:
      socket_address:
        address: 0.0.0.0
        port_value: 443
    filter_chains:
    - filter_chain_match:
        server_names: ["yangcs.net", "www.yangcs.net"]
      tls_context:
        common_tls_context:
          alpn_protocols: h2
          tls_params:
            tls_maximum_protocol_version: TLSv1_3
          tls_certificates:
            - certificate_chain:
                filename: "/root/.acme.sh/yangcs.net/fullchain.cer"
              private_key:
                filename: "/root/.acme.sh/yangcs.net/yangcs.net.key"
      filters:
      - name: envoy.http_connection_manager
        config:
          codec_type: auto
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend
              domains:
              - "yangcs.net"
              - "www.yangcs.net"
              routes:
              - match:
                  prefix: "/admin"
                route:
                  prefix_rewrite: "/"
                  cluster: envoy-ui
              - match:
                  prefix: "/"
                route:
                  cluster: hugo
                  response_headers_to_add:
                    - header:
                        key: "Strict-Transport-Security"
                        value: "max-age=63072000; includeSubDomains; preload"
          http_filters:
          - name: envoy.router
            config: {}
  clusters:
  - name: hugo
    connect_timeout: 0.25s
    type: strict_dns
    lb_policy: round_robin
    http2_protocol_options: {}
    hosts:
    - socket_address:
        address: hugo
        port_value: 8080
admin:
  access_log_path: "/dev/null"
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 8001

具体的含义请参考为 Envoy 开启 TLS 验证实战

现在就可以通过公网域名访问博客网站了,如果后续还有其他应用,都可以参考第二节的步骤,然后重新创建前端代理,添加 --add-host参数。以我的网站 https://www.yangcs.net 为例:

我好像透露了一些什么不得了的东西,就此打住,你也不要说,你也不要问。

4. 开机自启

由于 podman 不再使用 daemon 管理服务,--restart 参数被废弃了,要想实现开机自动启动容器,只能通过 systemd 来管理了。先创建 systemd 服务配置文件:

$ vim /etc/systemd/system/hugo_container.service

[Unit]
Description=Podman Hugo Service
After=network.target
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/podman start -a hugo
ExecStop=/usr/bin/podman stop -t 10 hugo
Restart=always

[Install]
WantedBy=multi-user.target
$ vim /etc/systemd/system/hugo-envoy_container.service

[Unit]
Description=Podman Hugo Sidecar Service
After=network.target
After=network-online.target
After=hugo_container.service

[Service]
Type=simple
ExecStart=/usr/bin/podman start -a hugo-envoy
ExecStop=/usr/bin/podman stop -t 10 hugo-envoy
Restart=always

[Install]
WantedBy=multi-user.target
$ vim /etc/systemd/system/front-envoy_container.service

[Unit]
Description=Podman Front Envoy Service
After=network.target
After=network-online.target
After=hugo_container.service hugo-envoy_container.service

[Service]
Type=simple
ExecStart=/usr/bin/podman start -a front-envoy
ExecStop=/usr/bin/podman stop -t 10 front-envoy
Restart=always

[Install]
WantedBy=multi-user.target

然后将之前停止之前创建的容器,注意:是停止,不是删除!

$ podman stop $(podman ps -aq)

最后通过 systemd 服务启动这些容器。

$ systemctl start hugo_container
$ systemctl start hugo-envoy_container
$ systemctl start front-envoy_container

设置开机自启。

$ systemctl enable hugo_container
$ systemctl enable hugo-envoy_container
$ systemctl enable front-envoy_container

之后每次系统重启后 systemd 都会自动启动这个服务所对应的容器。

4. 总结

以上就是将博客从 Docker 迁移到 Podman 的所有变更操作,总体看下来还是比较曲折,因为 Podman 是为 Kubernetes 而设计的,而我要求太高了,就一个资源紧张的 vps,即不想上 Kubernetes,也不想上 etcd,既想搞 sidecar,又想搞自动服务发现,我能怎么办,我也很绝望啊,这个事怨不得 podman,为了防止在大家心里留下 “podman 不好用” 的印象,特此声明一下。啥都不想要,只能自己想办法了~~

微信公众号

扫一扫下面的二维码关注微信公众号,在公众号中回复◉加群◉即可加入我们的云原生交流群,和孙宏亮、张馆长、阳明等大佬一起探讨云原生技术