k8s随笔

k8s

  • kubelet
    • 1. system.slice相关
    • 2. pause容器
    • 3. pod的生命周期对业务容器的影响
  • kube-apiserver
    • 1. watch
    • 2. 访问apiserver获取更多数据
    • 3. kubectl proxy连接apiserver
    • 4.访问pod中的容器通过端口暴露的应用的几种curl方式
    • 5. downward api
    • 6. pod内部curl访问apiserver简化
    • 7. 操作api的几个动作
    • 8. ambassador 容器模式访问apiserver
  • service
    • 1. NodePort服务不通
    • 2. 客户端典型的访问k8s内pod的方式
    • 3. 可以使用 kubectl set selector 命令来修改 Service 的 pod 选择器
    • 4.有状态服务和无状态服务的区别
    • 5.为什么需要服务
    • 6.集群内访问服务
    • 7.headless服务作用
  • 资源
    • 1. 某kubelet异常引起副本异常时,三类副本控制器的动作
    • 2. configmap、secret、downwardAPI卷共同点:
    • 3. kubernetes服务
    • 4. pod基本概念
    • 5.label和annotation区别
    • 6. rc的滚动升级(已过期)
    • 为什么推荐rs替代rc?
    • 7. Deployment的滚动升级
    • 8.sts基本概念
    • 9.声明式资源的组成
    • 10.副本控制器几种扩缩容(扩缩副本)的方式
    • 11.configmap和secret进行pod配置管理,敏感数据传递
    • 12.ds资源
  • 存储
    • 1. k8s和docker的volume设计有什么不同?
    • 2. 常用的vloume插件(volume-plugin)
    • 3. 为什么k8s不再接收内置volume-plugin,转而推荐通过csi(container-storage-interface)容器存储接口使用/拓展存储插件?
    • 4.pv,pvc的需求
    • 5.静态,动态pv使用区别
  • 双向认证
    • tls认证是什么
    • 1.客户端ca校验服务端server.crt
    • 2.服务端ca校验客户端认证,即token,证书等等
    • 3.集群需要的几种双向认证(Mutual TLS)证书
  • 管理工具
    • 命令行客户端kubectl
    • 编程式客户端client-go
    • 包管理工具helm3.0
      • 意义
      • 基本组成Chart、Config、Release
      • 特点
      • 使用
    • 日志系统
      • 收集什么?
      • 一般设计
      • 几种日志收集架构
    • 监控系统prometheus
  • 整体架构
    • 1. Kubemetes系统组件间只能通过API服务器通信, 它们之间不会直接通信。
    • 2. API服务器和其他组件的连接基本都是由组件发起的。
    • 3. list-watch

kubelet

1. system.slice相关

cpu/system.slice,memery/system.slice内的资源分别对应SystemReserverd预留的cpu,memery资源
例如no space in device:定义的预留资源太小(一般会导致节点notReady)
no device:没有定义对应的预留资源(在enforceNodeAllocatable显式规定要为某些组件预留资源但是没有定义对应的预留资源)(一般会导致需要分配资源的pod异常)

2. pause容器

每个pod都有pause容器,作用是为pod的所有容器共享网络和linux命名空间。
1.pause容器将 一个pod所有的容器收纳到 一起。
2.pause容器是 一个基础容器, 它的唯 一 目的就是保存所有的命名空间。
3.所有pod的其他用户定义容器 使用pod自己的pause容器的命名空间

3. pod的生命周期对业务容器的影响

无论任何原因将pod的status标注成*(unknown、…),最后因为无法恢复,这个 pod 就会自动从节点上驱逐。这是由controller-manager)处理的 。 它通过删除 pod 的资源来把它从节点上驱逐。
1.整个流程pod的状态是Running-*-Terminating
2.但是对于里面的容器而言,只要pod没有被真正地删除,容器还是一直运行着,占用资源,提供服务.

kube-apiserver

1. watch

close to connection,watch失败,是否可以加一条显式关闭连接的操作保证下一次不再使用旧连接?
这个问题已经通过1.14修复go语言net包解决。具体详情看issue

 https://github.com/kubernetes/kubernetes/issues/87615

2. 访问apiserver获取更多数据

敲kubect cluster-info获取apiserver访问地址
如果apiserver是https且单向认证,可以通过curl -k跳过服务端证书校验
如果apiserver是https且双项认证,要带认证参数–cacert/-k,-cert,–key!

$ curl --cacert /etc/kubernetes/pki/ca.crt --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt --key /etc/ubernetes/pki/apiserver-kubelet-client.key https://172.17.0.7:6443/api/v1/namespaces/kube-system/pods/coredns-66bff467f8-5b7xh|more
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  9167    0  9167    0     0   596k      0 --:--:-- --:--:-- --:--:--  596k
{
   
  "kind": "Pod",
  "apiVersion": "v1",
  "metadata": {
   
    "name": "coredns-66bff467f8-5b7xh",

注意:在真实的应用中, 永远不要跳过栓查服务器证书的环节(不要-k)。 这样做会导致你的应用验证凭证暴露给采用中间人攻击方式的攻击者

3. kubectl proxy连接apiserver

同样是客户端用curl ,之所以存在kubectl proxy的功能是因为双向认证直接访问apiserver时要带认证参数–cacert/-k,-cert,–key太繁琐,而使用kubectl proxy之后,通过使用kubectl.kubeconfig的认证方式,即使用kubectl的用户和认证去访问apiserver,把认证完全交给kubectl的配置,客户端只需要考虑curl的目标资源即可。(当然需要Kubectl的用户的资源权限足够多)

curl http://localhost:8001/api/v1/namespaces/kube-system/pods/coredns-66bff467f8-5b7xh|more
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  9167    0  9167    0     0   497k      0 --:--:-- --:--:-- --:--:--  497k
{
   
  "kind": "Pod",
  "apiVersion": "v1",
  "metadata": {
   
    "name": "coredns-66bff467f8-5b7xh",
// 另一个终端
controlplane $ kubectl proxy -v 10
I0906 09:05:58.706913   <

你可能感兴趣的:(k8s,容器)