kube-ladder lab2

lab2_answer

Open sweetpotatoman opened this issue 5 years ago • 0 comments

lab2-application-and-service

学习 kubectl proxy 命令及其含义。回答如何通过 proxy 访问 kubernetes 集群？

Kubernetes Proxy API 是一种特殊的 API，Kube-APIServer 只是代理这类 API 的 HTTP 请求，然后将请求转发到某个节点上的 Kubelet 进程监听的端口上。最后实际是由该端口上的 REST API 响应请求。
- kubectl proxy
```
kubectl proxy --port=8080 &
```
  - 现在，你可以使用 Kubernetes Proxy API 进行访问。比如：需要访问一个服务，可以使用 /api/v1/namespaces/<NAMESPACE>/services/<SERVICE-NAME>/proxy/
学习 kubectl port-forward 命令及其含义。回答如何通过 port-forward 访问应用？

从 Kubernetes v1.10 开始，kubectl port-forward 允许使用资源名称（例如 pod 名称）来选择匹配的 pod 来进行端口转发。

kubectl port-forward 命令转发了本地端口到 pod 端口的连接。它的手册现在这里可以查看。相比于 kubectl proxy，kubectl port-forward 也可以转发 TCP 流量而 kubectl proxy 只能转发 HTTP 流量。
- kubectl port-forward redis-master-765d459796-258hz 7000:6379
  
  这相当于
```
kubectl port-forward pods/redis-master-765d459796-258hz 7000:6379
```
  或者
```
kubectl port-forward deployment/redis-master 7000:6379 
```
  或者
```
kubectl port-forward rs/redis-master 7000:6379
```
  或者
```
kubectl port-forward svc/redis-master 7000:6379
```
  以上所有命令都应该有效。输出应该类似于：
```
I0710 14:43:38.274550    3655 portforward.go:225] Forwarding from      127.0.0.1:7000 -> 6379
I0710 14:43:38.274797    3655 portforward.go:225] Forwarding from      [::1]:7000 -> 6379
```
修改 Pod label 使其与 Deployment 不相符，集群有什么变化？
- deployment 会发现少了自己的 pod，重新启动一个拥有自己 label 的 pod；当然，修改的那个 pod 还存在
进一步学习 kubectl run。回答如何向 Pod 注入环境变量？如何查看是否注入成功？
- kubectl run
  - 通过 kubectl run --env 设置环境变量
```
kubectl run nginx-test --image=nginx:1.15.2  --env="DNS_DOMAIN=cluster" --env="POD_NAMESPACE=onemore" --env="ONE=more" -n onemore
```
  - 可以查看到该 pod template 中的 Environment 有刚才定义的环境变量信息
```
kubectl describe -n onemore deployments.apps nginx-test
```

进一步学习 kubectl rollout。回答如何通过 kubectl rollout 将应用回滚到指定版本？

使用 kubectl rollout history deployment/nginx-deployment 查看 deployment 升级历史

$ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment"
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=nginx-test.yml --record=true
2         kubectl replace --filename=nginx-test.yml --record=true

回滚到上一个版本

kubectl rollout undo deployment/nginx-deployment

回滚到指定版本

kubectl rollout undo deployment/nginx-deployment --to-revision=2

Note: 如果 CHANGE-CAUSE 为空，那是因为在创建 deployment 时没有使用 --record 选项

Pod LivenessProbe 实验中，检查方式采用的是 http 模式。回答如何使用 exec 进行健康检查？请写出 yaml 文件。

参考资料

exec_livenessProbe.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox  
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

进一步学习 Pod Lifecycle。回答如何使用 PostStart Hook？请写出 yaml 文件。

参考资料

apiVersion: v1
kind: Pod
metadata:
  name: test-post-start
spec:
  containers:
  - name: test-post-start-container
    image: busybox
    command: ["/bin/sh", "-c", "sleep 5 && echo $(date) 'written by         entrypoint' >> log.log && sleep 600"]
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "sleep 30 && echo $(date) 'written by      post start' >> log.log"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep 15 && echo $(date) 'written by      post stop' >> log.log"]

登录宿主机，使用 docker ps 查看 Pod，如何理解 docker ps 输出？
- docker ps 会列出所有运行中的容器
- docker ps –a 会列出所有的容器，不管是运行的，还是停止的
10张图带你深入理解Docker容器和镜像
- docker images 会列出了所有顶层（top-level）镜像
  - 实际上，在这里我们没有办法区分一个镜像和一个只读层，所以我们提出了 top-level 镜像。只有创建容器时使用的镜像或者是直接 pull 下来的镜像能被称为顶层（top-level）镜像，并且每一个顶层镜像下面都隐藏了多个镜像层
- docker images –a 列出了所有的镜像，也可以说是列出了所有的可读层
  - 要查看某一个 image-id 下的所有层，可以使用 docker history 来查看
- docker stop 会向运行中的容器发送一个 SIGTERM 的信号，然后停止所有的进程
- docker kill 向所有运行在容器中的进程发送了一个不友好的 SIGKILL 信号
- docker pause 它利用了cgroups的特性将运行中的进程空间暂停
  - 具体的内部原理你可以在这里找到：https://www.kernel.org/doc/Doc ... m.txt，但是这种方式的不足之处在于发送一个SIGTSTP信号对于进程来说不够简单易懂，以至于不能够让所有进程暂停。
- docker rm 会移除构成容器的可读写层
  - [注意，这个命令只能对非运行态容器执行]
- docker rmi 会移除构成镜像的一个只读层
  - 你只能够使用 docker rmi 来移除最顶层（top level layer）（也可以说是镜像），你也可以使用 -f 参数来强制删除中间的只读层
- docker commit 将容器的可读写层转换为一个只读层，这样就把一个容器转换成了不可变的镜像
- docker build 非常有趣，它会反复的执行多个命令
- docker exec 会在运行中的容器执行一个新进程
- docker inspect 会提取出容器或者镜像最顶层的元数据
- docker save 会创建一个镜像的压缩文件，这个文件能够在另外一个主机的 Docker 上使用
  - 和 export 命令不同，这个命令为每一个层都保存了它们的元数据。这个命令只能对镜像生效
- docker export 创建一个 tar 文件，并且移除了元数据和不必要的层，将多个层整合成了一个层，只保存了当前统一视角看到的内容
- docker history 递归地输出指定镜像的历史镜像

学习使用 Secret，然后创建一个 Secret 并在 Pod 内访问。请写出 secret 和 pod 的 yaml 文件。

创建 secret

game.properties

enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30

kubectl create secret generic game-secret --from-file=game.properties

pod_secret.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-secret
spec:
  restartPolicy: Never
  containers:
    - name: test-container
      image: busybox:1.26
      command: ["/bin/sh"]
      args: ["-c", "cat /etc/config/game.properties && sleep 60"]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
      resources:
        requests:
          cpu: "0.1"
          memory: "100Mi"
        limits:
          cpu: "0.1"
          memory: "100Mi"
  volumes:
    - name: config-volume
      secret:
        secretName: game-secret

ConfigMap 实验中，我们采用文件加载的方式使用 ConfigMap。请写出利用环境变量加载 configmap 的例子。

创建 configmap

apiVersion: v1
kind: ConfigMap
metadata:
  name: demo-configmap-1
  namespace: xxx
data:
  DEPLOYMENT_ENV: test

利用环境变量加载 configmap

apiVersion: apps/v1
kind: Deployment
metadata:
  name: xxx
  namespace: xxx
  labels:
    app: xxx
spec:
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: xxx
  template:
    metadata:
      labels:
        app: xxx
    spec:
      containers:
      - name: demo
        image: xxx/demo:0.0.1
        imagePullPolicy: IfNotPresent
        args: ["--spring.profiles.active=$(DEPLOYMENT_ENV_KEY)"]
        ports:
        - containerPort: 8080
        env:
        - name: DEPLOYMENT_ENV_KEY
          valueFrom:
            configMapKeyRef:
              name: demo-configmap-1
              key: DEPLOYMENT_ENV

Dec 30 '19 10:12 sweetpotatoman

kube-ladder kube-ladder copied to clipboard

lab2_answer

lab2-application-and-service

kube-ladder
kube-ladder copied to clipboard