Skip to content

Latest commit

 

History

History
197 lines (145 loc) · 16.9 KB

Kubernetes.md

File metadata and controls

197 lines (145 loc) · 16.9 KB

1. Can you describe how you set up and managed Kubernetes clusters for the migration project?

  • Answer: In my project, I used Azure Kubernetes Service (AKS) to manage Kubernetes clusters for application migration. I utilized Terraform to provision the necessary infrastructure, including the AKS clusters, networking, and storage. I ensured consistency and scalability across environments (Dev, IT, UAT, and Production) by automating cluster setup using Terraform scripts. Additionally, I used Ansible for configuration management tasks like installing dependencies and configuring environments for VM-based applications.
    Best practices:
    • Define clusters as code using Terraform to ensure repeatable infrastructure provisioning.
    • Use Azure Resource Manager (ARM) templates in conjunction with Terraform for consistent and scalable cluster management.
    • Employ Helm for managing application deployment and configurations across clusters.

2. What CI/CD tools did you use in your project, and how did you integrate them with Kubernetes?

  • Answer: We used GitLab CI/CD as the primary tool for continuous integration and delivery. The CI pipeline handled tasks like code quality scans, vulnerability checks, Docker image builds, and storing images in JFrog Artifactory. After the CI stage, the pipeline deployed the applications using Helm charts to AKS.
    We also used Twistlock (Prisma Cloud) to scan images for vulnerabilities before they were pushed to the repository, ensuring security throughout the deployment process.
    Best practices:
    • Automate Docker image builds with Kaniko for secure image creation.
    • Manage environment-specific configurations with Helm charts.
    • Integrate security tools like SonarQube, Fortify, and BlackDuck for early vulnerability detection.

3. Can you explain how you handled Helm chart deployments across multiple environments?

  • Answer: I used Helm charts to define reusable application configurations and deployments across multiple environments like Dev, IT, UAT, and Production. Each environment had a dedicated values.yaml file, which allowed me to customize configurations like resource limits, database credentials, and ingress rules.
    Helm enabled easy management of resources such as Deployments, StatefulSets, and Ingress controllers for microservices. For UAT/Prod environments, I used ServiceNow for change approvals to comply with organizational processes.
    Best practices:
    • Use Helm values files for environment-specific configuration management.
    • Ensure Helm charts are version-controlled for better rollback management.
    • Utilize Helm hooks to automate database migrations or custom logic during deployments.

4. How did you ensure security compliance while migrating applications to AKS?

  • Answer: Security was a key focus during the migration process. I implemented security best practices like using Azure Active Directory (AAD) for authentication and Role-Based Access Control (RBAC) to manage permissions within AKS. For Kubernetes secrets, we leveraged Azure Key Vault to store sensitive data and integrate them securely into the application.
    In the CI/CD pipeline, tools like SonarQube, Fortify, and BlackDuck were used to scan the code for vulnerabilities, ensuring that security issues were addressed early. Additionally, we performed image vulnerability scanning with Twistlock before pushing images to JFrog Artifactory.
    Best practices:
    • Use Kubernetes RBAC and Azure AD integration for access control.
    • Encrypt sensitive data using Azure Key Vault and Kubernetes Secrets.
    • Regularly audit cluster configurations for security compliance using tools like Kube-bench.

5. What was your approach for troubleshooting issues within the Kubernetes environment?

  • Answer: During the migration, I frequently encountered issues like 404 errors and ImagePullBackOff errors. For troubleshooting, I used kubectl describe and kubectl logs to gather detailed information about pod statuses and errors. For example, 404 errors were resolved by reviewing and correcting Istio Gateway and VirtualService configurations.
    We also used Splunk for centralized log management, which allowed us to trace issues across applications running in the AKS clusters. Additionally, AKS Active Logs were useful for monitoring pod health and performance.
    Best practices:
    • Enable Kubernetes logging using tools like Fluentd or Splunk.
    • Monitor pod statuses and errors using kubectl commands.
    • Set up Prometheus and Grafana for real-time monitoring and alerting.

6. How did you manage artifacts and container images during the deployment process?

  • Answer: I used JFrog Artifactory to manage container images and build artifacts. After the CI pipeline built the Docker images using Kaniko, the images were scanned for vulnerabilities using Twistlock and then pushed to JFrog Artifactory. This approach ensured that only secure, tested images were deployed to AKS.
    During deployments, I automated the update of image versions in Kubernetes manifests using sed commands in the GitLab pipeline, ensuring that the correct image versions were deployed across environments.
    Best practices:
    • Use JFrog Artifactory for secure image storage and versioning.
    • Automate the versioning of images in Kubernetes manifests using sed or CI/CD scripts.
    • Integrate image vulnerability scanning early in the pipeline to prevent insecure images from being used.

7. How did you ensure high availability and fault tolerance for the applications in AKS?

  • Answer: To ensure high availability and fault tolerance, I deployed applications in multiple Availability Zones (AZs) within AKS. I also used Horizontal Pod Autoscaling (HPA) to scale the application pods based on CPU and memory usage, ensuring that the application could handle varying loads.
    Additionally, I set up PodDisruptionBudgets (PDBs) to ensure that the application remained highly available during maintenance or pod disruptions. I also leveraged Azure Load Balancers to distribute traffic evenly across the pods.
    Best practices:
    • Use multi-AZ deployment in AKS for fault tolerance.
    • Implement HPA and PDBs to manage scalability and availability.
    • Leverage Load Balancers and Ingress controllers for efficient traffic routing.

8. Can you explain your process for ensuring application performance in a Kubernetes environment?

  • Answer: I used resource limits and requests to ensure that applications had enough resources to perform efficiently without consuming excessive cluster resources. During testing, I monitored pod resource utilization and adjusted resource limits accordingly.
    Additionally, I used Prometheus and Grafana for monitoring cluster and application performance. Metrics like CPU, memory usage, and network latency were tracked in real-time, enabling quick identification of performance bottlenecks.
    Best practices:
    • Define resource requests and limits to avoid resource contention.
    • Use Prometheus and Grafana for real-time performance monitoring.
    • Regularly review performance metrics and adjust resource configurations as needed.

9. What challenges did you face while using Istio Service Mesh, and how did you overcome them?

  • Answer: One of the challenges we faced with Istio Service Mesh was dealing with 404 errors caused by misconfigurations in the Istio Gateway and VirtualService resources. To resolve this, I reviewed the Istio configuration files to ensure that all routes were correctly defined and tested them in different environments.
    Additionally, I configured Istio to handle TLS termination and traffic routing for secure communication between services.
    Best practices:
    • Regularly test Istio configurations in staging environments before production deployment.
    • Leverage Istio’s built-in traffic management features for fine-grained control over service communication.
    • Use Istio’s telemetry features for enhanced monitoring and debugging.

10. How do you ensure consistency in deployment configurations across multiple environments?

  • Answer: To maintain consistency across environments, I used Helm charts with environment-specific values.yaml files. This approach allowed me to manage configurations like resource limits, environment variables, and application-specific settings while keeping the deployment process consistent.
    Additionally, I stored all Helm charts and Kubernetes manifests in GitLab, enabling version control and ensuring that deployments were reproducible across different environments (Dev, IT, UAT, Prod).
    Best practices:
    • Use Helm for environment-specific configuration management.
    • Store Kubernetes manifests and Helm charts in a version-controlled Git repository.
    • Automate configuration updates across environments to reduce human error.

Certainly! Here are additional questions that could be relevant for interviews, especially given your experience with Kubernetes, Istio, CI/CD, and cloud migrations. These questions cover other aspects of your project that weren't discussed earlier:

1. How do you ensure high availability in Kubernetes and how was it handled in your project?

Answer:
High availability (HA) in Kubernetes is crucial for ensuring that applications are resilient to failures. In my project, we achieved HA by:

  • Replicas: Ensuring that each deployment has multiple replicas of the pod, typically in a StatefulSet or Deployment, so that if one pod fails, the others continue to serve traffic.
  • Pod Anti-Affinity: Configuring PodAntiAffinity rules to spread pods across different nodes to prevent all replicas from being on the same node.
  • Horizontal Pod Autoscaler: Using Kubernetes HPA to automatically scale pods based on resource utilization metrics, ensuring that the application can handle varying traffic loads.
  • Disruption Budgets: Configuring PodDisruptionBudgets (PDBs) to prevent too many pods from being evicted during maintenance activities.

In my Azure Kubernetes Service (AKS) setup, these practices, along with proper network policies, ensured that applications remained highly available even during node failures or scaling events.

2. How do you manage Kubernetes resources across multiple environments (e.g., dev, staging, production)?

Answer:
In my project, we used Helm charts to manage Kubernetes resources across multiple environments. Helm made it easier to manage environment-specific configurations by parameterizing values (e.g., database URLs, secrets, replica counts) in values.yaml files for different environments.

For example, we had separate values-dev.yaml, values-staging.yaml, and values-prod.yaml files, each containing configuration values tailored to the environment they represented.

Additionally, we used Kustomize for managing different overlays, ensuring that Kubernetes manifests were not duplicated but customized for each environment. This helped us to manage resources more efficiently across Dev, IT, UAT, and Production environments.

3. Can you describe your experience with Helm charts and how you used them for deployments in your project?

Answer:
I extensively used Helm charts to package and deploy Kubernetes applications. Helm allowed me to define Kubernetes resources such as deployments, services, ConfigMaps, and Secrets in reusable templates, making it easier to manage applications across environments. For instance, in my migration project, I created Helm charts to define services like database deployments, application workloads, and networking resources.

The key benefits we derived from using Helm in my project were:

  • Consistency: Helm provided a consistent way to deploy the same set of resources across environments.
  • Parameterization: By using Helm’s templating mechanism, we could inject environment-specific variables (e.g., database connections, secrets) without modifying the actual Kubernetes manifest.
  • Version Control: Helm helped in versioning our deployments, making rollbacks and updates smoother.

I also used Helm hooks for pre-deployment and post-deployment tasks like database migrations and other setup activities.

4. How do you manage secrets in Kubernetes, and what tools did you use in your project?

Answer:
In Kubernetes, managing secrets is critical to ensuring the confidentiality of sensitive data. In my project, we used the following approaches:

  • Kubernetes Secrets: For storing sensitive information like API keys, database passwords, etc., we used Kubernetes Secrets. These secrets were encrypted at rest using Kubernetes' default encryption providers.
  • HashiCorp Vault: We integrated HashiCorp Vault with Kubernetes to manage and inject secrets dynamically into pods using Vault Kubernetes Auth. This allowed us to securely manage and access secrets without storing them directly in Kubernetes.
  • Azure Key Vault: For cloud-native secret management, we used Azure Key Vault to store secrets for services running on Azure Kubernetes Service (AKS). Azure’s integration with Kubernetes allowed for secure access to secrets in the AKS environment.

For CI/CD pipelines, we used GitLab’s Secret Management capabilities to securely manage credentials and access tokens required during deployments.

5. Can you explain the difference between StatefulSets and Deployments in Kubernetes? When would you choose one over the other?

Answer:

  • Deployments: Used for stateless applications, where the individual pod’s state does not need to be preserved. Deployments ensure that a specified number of replicas of a pod are always running, and they are best suited for stateless workloads like web services or APIs.

  • StatefulSets: Used for stateful applications where each pod needs a unique identity or persistent storage (e.g., databases). StatefulSets provide a stable, unique identity to each pod and guarantee that pods are created and terminated in a specific order.

In my project, I used StatefulSets for applications like databases where the state needs to persist across pod restarts, and Deployments for stateless microservices that don’t need to maintain any state across pods.

6. How do you monitor and log Kubernetes workloads, and what tools did you use in your project?

Answer:
Monitoring and logging are critical to ensuring the health and performance of Kubernetes applications. In my project:

  • Logging: We used Splunk to collect logs from our applications and Kubernetes nodes. Logs were forwarded using Fluentd or Filebeat agents running as DaemonSets in the cluster. Splunk allowed us to centralize logs, apply filters, and set up alerting for specific events (e.g., application errors, failed pods).

  • Monitoring: We used Prometheus for collecting metrics from Kubernetes components and applications. Prometheus scraped metrics from the Kubernetes API server, nodes, and application pods. For visualization, we used Grafana, which was integrated with Prometheus to display health metrics, CPU/memory usage, pod status, and custom application metrics.

  • Istio Telemetry: Since we used Istio in our project, we also used Istio's built-in telemetry features for distributed tracing, metrics, and logging. We integrated Istio with Prometheus, Grafana, and Jaeger for a comprehensive observability solution.

7. What is your experience with container security in a CI/CD pipeline, and what tools did you use for scanning?

Answer:
In my project, security was a top priority in our CI/CD pipeline. We used a combination of tools for static code analysis, container image vulnerability scanning, and dependency scanning:

  • SonarQube: Used for static code analysis and to identify potential bugs, code smells, and security vulnerabilities in custom code.
  • Synopsys, Fortify, BlackDuck: Integrated for scanning dependencies and container images for vulnerabilities. These tools helped in identifying known vulnerabilities (e.g., CVEs) in third-party libraries.
  • Twistlock (Prisma Cloud): Used for container image vulnerability scanning. Twistlock was integrated into the pipeline to scan Docker images for known vulnerabilities before they were pushed to JFrog Artifactory.
  • Kaniko: Used for building Docker images in the pipeline in a secure manner, without requiring privileged access.

These tools were incorporated into our GitLab CI/CD pipeline to ensure that every commit was scanned for security risks before being deployed to Kubernetes.