2018-09-26不实践，就无法理解为什么pod这么设计，这里给了我自己的实践的记录：
https://github.com/huan9huan/k8s-practice/tree/master/15-pod-advanced
仅供参考。 1 30
2018-09-26信息量大，要多看两遍 13
2018-09-27在使用PodPreset对象时,发现并未生效,最终才知道是因为当初安装时未启用 Pod Preset.然后参考[https://kubernetes.io/docs/concepts/workloads/pods/podpreset/#enable-pod-preset] 修改 [/etc/kubernetes/manifests/kube-apiserver.yaml] 中的spec.containers.command: 修改原[ - --runtime-config=api/all=true]为[- --runtime-config=api/all=true,settings.k8s.io/v1alpha1=true], 新加一行[- --enable-admission-plugins=PodPreset] 可以等自动生效也可以强制重启[systemctl restart kubelet]. 然后再重新创建,就可以在pod中看见spec.containers.env.name:DB_PORT等信息了.作者回复: 对。新特性需要先启用。
5 11
2018-09-26probe的原理是通过sidecar容器来实现的吗作者回复: 不是的，exec
8
2018-09-26Kubernetes 的 livenessProbe 和 readinessProbe 两个在项目中都用到了，最基本的是定时检测服务端口是否在，毕竟好的是请求服务，例如针对http服务，发起一个请求，查看服务是否正常，因为有时候端口在，服务不一定正常。 5
2018-10-16按照老师的操作执行这个命令报错了
[root@node1 k8s]# kubectl create -f preset.yaml
error: unable to recognize "preset.yaml": no matches for kind "PodPreset" in version "settings.k8s.io/v1alpha1"
求解展开 3 4- 2018-09-26目前项目使用了forever之类的wrapper进程来管理工作进程，forever是根据工作进程的状态做重启操作（也可以使用forever的api接口做health检查）。另外，日志都是使用append的形式，而不是覆盖，这样可以不用掩盖错误的发生。 4
2019-04-22我公司也在用livenessprobe和readinessprobe，第一个是就绪探针在确定容器是否已经就绪可以接受流量，而第二个是存活容器来确定容器是否假死，如果遇到假死则开始重启p 1 3
2018-09-27我记得deployment所创建的pod restart策略只支持aways。是我使用的版本太低了吗？作者回复: deployment确实是这么要求的啊。不过你可以想想为什么。
1 3- 2018-09-26文章中的代码 dapi-volume.yaml 格式不对,被取消了缩进,导致直接贴出来使用会报错.
还有按文章中的命令 kubectl create secret generic user --from-file=./username.txt ,在pod中[ kubectl exec -it test-projected-volume -- /bin/sh]展示的目录不是user,而是username.txt. 可以通过[kubectl edit secrets user]手动修改data:下的字段名.作者回复: 请仔细看，我在文稿列出来的exec的输出，是第二种方法、也就是写YAML文件方法创建的Secret。而你列出来的是第一种方法创建的Secret。他俩本来就是不一样的。
3 
2018-09-26是projected volume 1.11以后，不是persistent volume 3
2018-09-26讲的详细量又大哈 3
2019-04-29和openshift哪个较好 2
2019-04-23使用yaml文件创建secret对象部分的验证阶段有问题：
$ kubectl exec -it test-projected-volume -- /bin/sh
$ ls /projected-volume/
user
pass
$ cat /projected-volume/user
root
$ cat /projected-volume/pass
1f2d1e2e67df
上面/projected-volume/user里面的内容应该是admin，而非root
另外一个问题，之前课程建议使用kubectl apply的方式创建和更新对象，为什么这篇里面还是全用kubectl create的方式呢？展开 2
2018-12-02复习了下容器的检查探针, 有几个点还是没太明白, 还望老师能解答下:
1. restartPolicy : 这个restartPolicy是重启的Pod的Container, 那么重启的时机是根据Container结束时返回的状态码吗?
2. restart 和 probe的关系: Pod某个容器的livenessProbe 返回fail, 这个时候Container并没有结束, 只是状态检查是失败的, 那为什么Container也会重启呢? 这个重启动作是谁发起的呢?
3. readnessProbe: 如果某个Pod含多个Container, 且每个都有readnessProbe, 那是不是说只有全部Container的Probe返回success, 该Pod才会是 readness呢?展开作者回复: 很简单。restart policy 要尊重 liveness probe
2
2018-10-19老师好，probe我们在生产实际应用中，有个问题。就是，每次新部署的时候，旧容器要做graceful delete，这个会触发kubelet的delete逻辑。 只有在容器被kill以后，k8s才会remove 这个探针。即，容器已经收到kill信号在停服务了，但是探针还在检测于是一直报错。 不知道有没有配置可解决这个问题。作者回复: 嗯，代码实现目前就是这样的。有具体的影响吗？除了报错比较多之外。
2
2018-09-27老师你好，有句话不太明白
原文：“相信你一定有过这样的想法：我现在有了一个 Pod，我能不能在这个 Pod 里安装一个 Kubernetes 的Client，这样就可以从容器里直接访问并且操作这个 Kubernetes 的 API 了呢？”
1. 这里可以举个简单例子吗？
2.“kubernetes的client”指的是什么？
3. 操作“kubernetes的API”这里的API由指什么？
小白问题，过不了这关，听得有点晕。见谅展开作者回复: client library，kubernetes 对外暴露的api
2
2018-09-26在讲述livenessProbe的时候说到：虽然是 Restart（重启），但实际却是重新创建了容器；那之前那个还在运行的liveness容器被自动销毁了吗？作者回复: 对
2
2018-09-26pv是1.11以后？作者回复: 再仔细看看……
2
2018-11-22我创建了 podPreset 包含 redis 6379等 关联了role frontend
但是 我创建了Pod website
用kubectl get pod website -o yaml 查看，没有看到有文章中的
env:
- name: DB_PORT
value: "6379"
信息，是我哪里操作不对？还是哪里有问题呢？期待老师的回复，感谢展开 1