Kubernetes 1.8: Security, Workloads and Feature Depth

Introduction

On September 29 2017, Kubernetes version 1.8 was officially released.
This release emphasised security, workload maturity and architectural depth, signalling that Kubernetes had entered a new phase of stability and extensibility.

Official Highlights

1. Security and Governance

• The Role-Based Access Control (RBAC) API reached General Availability (GA), enabling cluster admins to enforce fine-grained authorization policies.
• Kubelet certificate rotation (TLS) moved to beta, improving node + control-plane security.
• Work began on strengthening governance and formalising release processes.
• PodSecurityPolicy (beta) received meaningful updates, enabling stricter pod admission controls.

2. Workload APIs & Extensibility

• The “Workloads” API group (apps/v1 beta2) including Deployment, DaemonSet, ReplicaSet, StatefulSet advanced further.
• Support for alternative runtimes expanded — e.g., CRI-O providing an OCI-compatible runtime.
• Device Plugin API (alpha) arrived to expose GPUs/FPGAs through a consistent interface.

3. Improved Stability & Process Maturity

• Over 2000 commits and ~39 new features were introduced, across many Special Interest Groups (SIGs) and working groups.
• The project emphasised sustainable practices — architecture, release process, scaling beyond early adopters.

Milestones Timeline

RBAC & Security Implications

• RBAC is now GA and ships with stricter bootstrap roles—review any remaining ABAC policies and replace ad-hoc cluster-admin bindings with least-privilege roles.

• Enable kubelet certificate rotation to reduce manual cert management:

  kubelet \
    --rotate-certificates \
    --rotate-server-certificates
  

• PodSecurityPolicy improvements (still beta) make it easier to enforce hostPath, privileged and volume usage policies; trial them in staging before enforcing cluster-wide.

• Audit webhooks and the alpha EventRateLimit admission plugin help throttle noisy clients—configure them alongside RBAC for end-to-end governance.

Runtime & Workload Notes

• Try CRI-O by pointing the kubelet to --container-runtime=remote --container-runtime-endpoint=/var/run/crio/crio.sock; ideal for OCI-compliant, RHEL-based clusters.
• Device Plugin API unlocks GPU/FGA integrations (e.g., NVIDIA’s device plugin). Expect ecosystem plugins to stabilize through 1.9.
• Begin migrating manifests from legacy extensions/v1beta1 Deployments/DaemonSets to apps/v1beta2 to prepare for the 1.9 GA cutoff.

Patch Releases for 1.8

Patch releases in the 1.8 branch (1.8.x) delivered bug-fixes, stability patches and compatibility updates.

Graduations & Deprecations

Legacy and Impact

Kubernetes 1.8 marked a key transition from fast growth to production-focused maturity:
Its GA security APIs, expanded runtime options, and deep workload support helped it become a robust foundation for enterprise and multi-tenant deployments. The project also shifted into stronger governance and process stability, reflecting its position as the de facto container orchestration standard.

Summary

Next in the Series

Next up: Kubernetes 1.9 (December 2017) — we’ll explore Apps/v1 GA, enhanced storage drivers (CSI), and ecosystem expansion.