[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-bezopasnost-konteynerov-kak-ogranichenie-resursov-zashchishchaet-ot-dos-atak":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":20,"progress":21,"seo":22},320,"kak-ogranichenie-resursov-zashchishchaet-ot-dos-atak",9,"bezopasnost-konteynerov","Безопасность контейнеров","🛡️","Как ограничение ресурсов защищает от DoS-атак?","\u003C!-- grade: -->\n\nОграничение ресурсов (resource limits) в Kubernetes и Docker предотвращает ситуацию, когда один контейнер потребляет все ресурсы хоста, лишая остальные контейнеры возможности нормально функционировать. Это защита от **DoS (Denial of Service)** — как от целенаправленных атак, так и от ошибок в коде (утечки памяти, бесконечные циклы, неконтролируемый рост числа потоков).\n\n**Requests и Limits в Kubernetes:**\n\n```yaml\napiVersion: apps\u002Fv1\nkind: Deployment\nmetadata:\n  name: banking-service\n  namespace: banking\nspec:\n  template:\n    spec:\n      containers:\n      - name: app\n        image: registry.bank.local\u002Fbanking-service:1.0.0\n        resources:\n          requests:\n            memory: \"256Mi\"  # Гарантированные ресурсы для планировщика\n            cpu: \"250m\"      # 0.25 CPU core\n          limits:\n            memory: \"512Mi\"  # Максимум — при превышении контейнер получит OOMKill\n            cpu: \"1000m\"     # 1 CPU core — при превышении контейнер будет троттлиться\n        env:\n        - name: JAVA_OPTS\n          value: >-\n            -XX:MaxRAMPercentage=75.0\n            -XX:+UseG1GC\n            -XX:+ExitOnOutOfMemoryError\n```\n\n**Разница между requests и limits:**\n\n- **requests** — минимальный гарантированный объём ресурсов. Планировщик Kubernetes использует requests при выборе ноды для размещения пода: под будет размещён только на той ноде, где имеется достаточно свободных ресурсов для покрытия requests всех контейнеров.\n- **limits** — максимально допустимое потребление. При превышении memory limit ядро Linux немедленно завершает процесс через OOMKill. При превышении CPU limit контейнер подвергается троттлингу (throttling) — ему выделяется меньше процессорного времени, но процесс продолжает работать.\n\n**Настройка JVM с учётом container limits:**\n\n```dockerfile\nENTRYPOINT [\"java\", \\\n    \"-XX:MaxRAMPercentage=75.0\", \\\n    \"-XX:InitialRAMPercentage=50.0\", \\\n    \"-XX:+UseContainerSupport\", \\\n    \"-XX:+ExitOnOutOfMemoryError\", \\\n    \"-jar\", \"\u002Fapp\u002Fapp.jar\"]\n```\n\nФлаг `-XX:+UseContainerSupport` (включён по умолчанию с Java 10+) позволяет JVM корректно определять memory и CPU limits контейнера через cgroups и соответствующим образом настраивать размер heap и количество потоков GC. Параметр `-XX:MaxRAMPercentage=75.0` выделяет 75% от доступной памяти контейнера под Java heap, оставляя 25% для metaspace, стеков потоков, native memory (NIO-буферы, JNI) и самой операционной системы.\n\nФлаг `-XX:+ExitOnOutOfMemoryError` приказывает JVM немедленно завершить процесс при OutOfMemoryError, чтобы Kubernetes мог перезапустить под через restartPolicy. Без этого флага JVM может оказаться в «зомби»-состоянии: процесс жив, но не обрабатывает запросы.\n\n**LimitRange — ограничения по умолчанию для namespace:**\n\n```yaml\napiVersion: v1\nkind: LimitRange\nmetadata:\n  name: banking-limits\n  namespace: banking\nspec:\n  limits:\n  - type: Container\n    default:          # Значения limits по умолчанию (если не указаны в Pod spec)\n      memory: \"512Mi\"\n      cpu: \"500m\"\n    defaultRequest:   # Значения requests по умолчанию\n      memory: \"256Mi\"\n      cpu: \"250m\"\n    max:              # Максимально допустимые limits\n      memory: \"2Gi\"\n      cpu: \"2\"\n    min:              # Минимально допустимые requests\n      memory: \"64Mi\"\n      cpu: \"50m\"\n  - type: Pod\n    max:\n      memory: \"4Gi\"\n      cpu: \"4\"\n```\n\nLimitRange выполняет две функции: автоматически назначает limits\u002Frequests контейнерам, для которых они не указаны явно, и валидирует, что указанные значения попадают в допустимый диапазон. Это предотвращает ситуацию, когда разработчик забывает указать limits или устанавливает неоправданно высокие значения.\n\n**ResourceQuota — ограничение суммарных ресурсов namespace:**\n\n```yaml\napiVersion: v1\nkind: ResourceQuota\nmetadata:\n  name: banking-quota\n  namespace: banking\nspec:\n  hard:\n    requests.cpu: \"10\"\n    requests.memory: \"20Gi\"\n    limits.cpu: \"20\"\n    limits.memory: \"40Gi\"\n    pods: \"50\"\n    services: \"20\"\n    secrets: \"30\"\n    configmaps: \"30\"\n```\n\nResourceQuota ограничивает **суммарное** потребление ресурсов всеми подами в namespace. Это защита от ситуации, когда одна команда создаёт слишком много подов или потребляет непропорционально много ресурсов кластера. Поле `pods: \"50\"` также ограничивает количество подов, что защищает от атаки через массовое создание ресурсов.\n\n**Ограничение ресурсов в Docker:**\n\n```bash\ndocker run \\\n    --memory=512m \\\n    --memory-swap=512m \\    # Запретить использование swap\n    --cpus=1.0 \\\n    --pids-limit=200 \\      # Ограничение числа процессов (защита от fork bomb)\n    --ulimit nofile=1024:2048 \\\n    my-java-app\n```\n\nПараметр `--memory-swap=512m`, равный `--memory`, полностью запрещает использование swap. Swap может скрывать проблемы с потреблением памяти и ухудшать производительность, поэтому в production-среде его рекомендуется отключать. Параметр `--pids-limit=200` ограничивает количество процессов внутри контейнера, что защищает от fork bomb (атака, при которой процесс рекурсивно создаёт копии самого себя, исчерпывая PID-ы системы).\n\n**Сценарии атак, которые предотвращают limits:**\n\n| Атака | Без ограничений | С ограничениями |\n|-------|----------------|-----------------|\n| Утечка памяти (memory leak) | Падение всего хоста из-за исчерпания RAM | OOMKill только конкретного пода, остальные продолжают работать |\n| Бесконечный цикл (100% CPU) | Деградация производительности всех сервисов на ноде | Throttling только этого пода, другие получают своё процессорное время |\n| Fork bomb | Исчерпание PID-ов хоста, невозможность запустить новые процессы | `pids-limit` ограничит число процессов внутри контейнера |\n| Заполнение диска логами | Диск заполнен, все сервисы на ноде перестают писать логи и данные | `emptyDir.sizeLimit` + `ephemeral-storage` limits ограничат потребление дискового пространства |","","middle",[15,16,17,18,19],"kubernetes","dos-protection","resource-limits","container-security","docker",[],null,{"title":23,"description":24,"ogTitle":23,"ogDescription":25,"keywords":26,"schemaAnswer":34,"featuredSnippetReady":35},"Ограничение ресурсов контейнеров: защита от DoS-атак — Gymterview","Как resource limits в Kubernetes и Docker защищают от DoS-атак? Requests и limits, LimitRange, ResourceQuota. Настройка JVM с UseContainerSupport и MaxRAMPercentage.","Resource limits в Kubernetes и Docker: requests vs limits, настройка JVM для контейнеров, LimitRange и ResourceQuota для защиты от DoS-атак.",[27,28,29,30,31,32,33],"resource limits Kubernetes","requests limits","LimitRange","ResourceQuota","DoS защита контейнеров","UseContainerSupport JVM","MaxRAMPercentage","Resource limits в Kubernetes и Docker предотвращают ситуацию, когда один контейнер потребляет все ресурсы хоста. Requests — минимальные гарантированные ресурсы для планировщика, limits — максимальный потолок (при превышении memory — OOMKill, CPU — throttling). LimitRange задаёт ограничения по умолчанию для namespace, ResourceQuota — суммарные лимиты. Для JVM используется -XX:+UseContainerSupport и -XX:MaxRAMPercentage=75.0, чтобы JVM корректно учитывала cgroup-лимиты контейнера.",true]