一种常见情形是，使用聊天机器人来搜集用户提供的信息，在rasa中，一般这种行为叫做
slot filling
需要在 policy 中添加
policies:
- name: FormPolicy
- name: MemoizationPolicy
- name: TEDPolicy
max_history: 5
epochs: 100
- name: MappingPolicy
这里我使用的是官方例子，不过做了一些小修改
## request restaurant happy path
* request_restaurant
- restaurant_form
- form{"name": "restaurant_form"}
- form{"name": null}
FROM ubuntu:18.04
# Set temp work directory
# for package configuration
WORKDIR /usr/src/cache
# Update apt packages RUN apt update RUN apt upgrade -y
# Install vim
RUN apt install vim -y
# Install python 3.7
RUN apt install software-properties-common -y
RUN add-apt-repository ppa:deadsnakes/ppa
RUN apt install python3.7 -y # Make python 3.7 the default
插播一个备忘录
sudo apt install docker.io
sudo usermod -a -G docker lizhe
然后正常退出，重启docker保证能正常使用
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
要连接两个以上的 namespace ， 需要使用 Linux bridge。
网桥是二层网络设备，两个端口分别有一条独立的交换信道，不共享背板总线，可以隔离冲突 （比集线器性能好一些，集线器共享同一条背板总线）
不过目前网桥已经被具有更多端口、可隔离冲突域的交换机取代了。
Linux 网桥 和 其他的网络设备区别在于， 普通设备（例如网卡）只有两端，从一端进去从另一端出来。
物理网卡从网络中收到数据，转发给 内核协议栈 ， 从内核协议栈过来的数据会转发到外面的物理网络中。
Linux 网桥 有多个端口，数据可以从任何端口进来，然后取决于 MAC 地址，选择从哪个口出去，原理和交换机差不多
创建一个网桥
root@ubuntu:/home/lizhe# ip link add name br0 type bridge
root@ubuntu:/home/lizhe# ip link set br0 up
root@ubuntu:/home/lizhe#
刚创建的网桥只有一端连接着协议栈
之前创建了一个 veth pair
veth0 10.10.10.1
veth1 10.10.10.2
这里他们都在一个网段上，如果你使用 ping 命令直接 ping 它们都可以ping通
但是 ping -I veth0 10.10.10.2 使用 veth0 ping veth1 是 ping不通的
我们尝试使用 tcpdump 来看看发生了什么
veth 是虚拟以太网卡 （ Virtual Ethemet ）的缩写。
veth 设备总是成对的，因此我们称之为 veth pair。 veth pair 常被用于 跨 network namespace 之间的通信，即分别将 veth pair 的两端放在不同的 namespace 里
仅有veth pair设备，容器是无法访问外部网络的。
从容器发出的数据包，实际上是直接进了 veth pair 设备的协议栈。
如果容器需要访问网络，则需要使用网桥等技术将 veth pair 设备接收的数据包转发出去。
这里我创建一个新仓库
然后分别提交3次，依次提交 file1、file2 和 file3
bae637edfecf634185f6dc3cf51d251a8d27aad0 file1 第一次提交
39defcb06a20910ee01cf2dd688b6d2b1ce0a411 file2 第二次提交
f8f10774bbb0c7faab1190bd173e763b0cca34cc file3 第三次提交
显示所有提交
git log
如果你熟悉docker的namespace隔离机制，你应该知道docker的network也是通过 namespace隔离的
要了解kubernetes的网络原理，不得不提到 linux 的network namespace
Linux的 namespace 的作用是 隔离内核资源，命名空间会给其中的进程造成两个错觉
1. 它是系统内唯一的进程
2. 它独享系统的所有资源
network namespace是从 2.6 开始引入的，作用是隔离 Linux 系统的设备，ip 地址、端口、路由表 和 防火墙规则等网络资源
创建一个名为 netns1 的 新命名空间
sudo ip netns add netns1
当 ip 命令 创建了一个 新命名空间 之后，系统会在 /var/run/netns 目录下生成一个新的挂载点
挂载点的作用在于一方面是为了方便 命名空间管理，另一个方面是使 命名空间 可以在没有进程运行时也能继续存在
Kubernetes三种弹性伸缩：
我们先来看一下HPA
这里不会演示如何创建HPA，我关注的是一些具体细节
Kubernetes 的自动伸缩特性在1.6和1.7本本之间重写过一次，有一些特性发生了变化
自动伸缩分为3个步骤
1. 获取被伸缩资源对象所管理的所有pod度量
2. 计算使度量数值达到（或接近）所指定的目标数值所需的pod数量
3. 更新被伸缩资源的 replicas 字段
度量数据的流向
Pod -> cAdvisor -> Heapster -> Horizontal Pod AutoScaler
ResourceQuota 的接纳控制插件会检查将要创建的Pod 是否会引起 总资源量 超出 ResourceQuota。
ResourceQuota 也无法影响已经创建的 pod
apiVersion: v1
kind: ResourceQuota
metadata:
namespace: lizhe
name: lizhe-rq
spec:
hard:
pods: 5
requests.cpu: 1
requests.memory: 1Gi
limits.cpu: 1.5
limits.memory: 1Gi
configmaps: 2
persistentvolumeclaims: 5
replicationcontrollers: 5
secrets: 2
services: 2