Kubernetes: контроллер репликации все еще там после удаления - PullRequest
Новая
       8

Kubernetes: контроллер репликации все еще там после удаления

0 голосов
/ 05 декабря 2018

Я управляю K8s-кластером, управляемым terraform: 

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-21T09:17:39Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-21T09:05:37Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Я хочу удалить стек;поэтому я удалил код и применил.Это вызвало ошибку из-за тайм-аута.Я повторил попытку и ушел успешно.

но теперь у меня все еще есть 2 контроллера репликации (которые пусты): 

portal-api                                          0         0         0         2h
portal-app                                          0         0         0         2h

больше нет службы, нет больше горизонтального_пода_scheduler;но все еще мой replication_controller.

Я пытался удалить их: 

$ kubectl delete rc portal-api                                                                                                      
error: timed out waiting for "portal-api" to be synced

То же самое, если я хочу принудительно удалить: 

$ kubectl delete rc portal-api --cascade=false --force=true
$ 
$ kubectl get rc
[...]
portal-api                                          0         0         0         2h
portal-app                                          0         0         0         2h
[...]

Я также все еще могу видеть егоконфигурация (заполненная deletionTimestamp): 

$ kubectl edit rc portal-api

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
kind: ReplicationController
metadata:
  creationTimestamp: 2018-12-05T14:00:15Z
  deletionGracePeriodSeconds: 0
  deletionTimestamp: 2018-12-05T15:22:00Z
  finalizers:
  - orphan
  generation: 3
  labels:
    App: portal-api
  name: portal-api
  namespace: default
  resourceVersion: "32590661"
  selfLink: /api/v1/namespaces/default/replicationcontrollers/portal-api
  uid: 171f605e-f896-11e8-b761-02d4b8553a0e
spec:
  replicas: 0
  selector:
    App: portal-api
  template:
    metadata:
      creationTimestamp: null
      labels:
        App: portal-api
    spec:
      automountServiceAccountToken: false
      containers:
      - env:
        - name: AUTHORITY_MGR
          value: http://system-authority-manager-service
        image: gitlab.********************:4567/apps/portal/api:prd
        imagePullPolicy: Always
        name: portal-api
        ports:
        - containerPort: 3300
          protocol: TCP
        resources:
          limits:
            cpu: "1"
            memory: 512Mi
          requests:
            cpu: 500m
            memory: 256Mi
        terminationGracePeriodSeconds: 30
    status:
  replicas: 0

Может ли кто-нибудь помочь мне в этом?Любая идея ?

спасибо,

Ответы [ 2 ]

0 голосов
/ 06 декабря 2018

Это около Сборка мусора и как удалить определенные объекты, у которых когда-то был владелец, но у которых его уже нет.

При удалении объекта вы можете указатьнезависимо от того, будут ли автоматически удалены иждивенцы объекта.Удаление зависимостей автоматически называется каскадное удаление .Существует два режима каскадного удаления : background и foreground .

Если вы удаляете объект, не удаляя его зависимые автоматически, зависимыеназывается осиротевшим .

Вы можете прочитать документацию, касающуюся Управление тем, как сборщик мусора удаляет зависимых , как происходит каскадное удаление на переднем плане и каскадное удаление на заднем планеработает.

Установка политики каскадного удаления

Чтобы управлять политикой каскадного удаления, установите поле propagationPolicy в аргументе deleteOptions при удалении объекта.Возможные значения: «Сирота», «Передний план» или «Фон».

До Kubernetes 1.9 политика сбора мусора по умолчанию для многих ресурсов контроллера была orphan.Это включает ReplicationController, ReplicaSet, StatefulSet, DaemonSet и Deployment.Для видов в версиях групп extensions/v1beta1, apps/v1beta1 и apps/v1beta2, если не указано иное, зависимые объекты по умолчанию являются бесхозными.В Kubernetes 1.9 для всех видов в версии группы apps/v1 зависимые объекты удаляются по умолчанию

kubectl также поддерживает каскадное удаление.Для автоматического удаления зависимостей с помощью kubectl установите --cascade в значение true.Для сирот-иждивенцев установите --cascade в false.Значение по умолчанию для --cascade - true.

Вот пример, который теряет зависимые элементы набора ReplicaSet: kubectl delete replicaset my-repset --cascade=false

0 голосов
/ 05 декабря 2018

Используя kubectl edit rc portal-api удалить finalizer деталь из ресурса: 

finalizers:
  - orphan
...