Key DevOps Interview Q&A: Git, MySQL Replication, Kafka, Kubernetes

Git and SVN differences

Git is distributed, while SVN is not. Git stores content as metadata, whereas SVN stores files directly. Git lacks a global revision number, while SVN maintains one. Git uses SHA‑1 hashes for data integrity, ensuring safety against disk or network failures. Git can view the full log offline; SVN requires an update before committing. Cloning a large repository is much faster with Git than with SVN. SVN relies on a single central repository; Git repositories are decentralized, allowing work even if the central repository is unavailable. In SVN, a branch is a full copy of the directory affecting all users; Git branches are lightweight and local. Commits in SVN go directly to the central repository, while Git commits are local and later pushed.

MySQL master‑slave replication principles

The master records changes to the binary log; the slave copies these events to its relay log and replays them. Two slave threads operate: an I/O thread fetches the binlog, and an SQL thread executes the events. To troubleshoot desynchronization, check show processlist, show master status, and show slave status\G. Solutions include skipping errors with

stop slave; set global sql_slave_skip_counter=1; start slave;

or rebuilding replication by locking tables, dumping data, transferring the dump, configuring change master to ..., and restarting the slave. Adjust parameters such as slave-net-timeout and master-connect-retry to reduce latency, and consider hardware or configuration optimizations.

Kafka vs traditional MQ

Traditional message queues like RabbitMQ (AMQP) are mature, reliable, and suited for high‑reliability messaging. Kafka, originally designed for log aggregation, excels at handling large‑scale streaming data and big‑data analytics. Redis can act as a lightweight queue but lacks reliability and may suffer from data buildup.

Kubernetes service types

ClusterIP provides an internal virtual IP for pods. NodePort maps a port on each node for external access. Headless ClusterIP (clusterIP: None) creates no virtual IP. LoadBalancer provisions an external load balancer.

Pod communication

Containers within the same pod share a network namespace and can communicate via localhost. Pods on the same node use the default Docker bridge. Pods on different nodes typically use a CNI plugin such as Flannel, which provides a flat L2 network with centrally assigned IPs.

Kubernetes health checks

Liveness probes tell Kubernetes when to restart a failing container; readiness probes indicate when a container is ready to receive traffic. Both use the same syntax.

Kubernetes pod states

Common states include Pending (unscheduled), Running, ImagePullBackOff (failed image pull), CrashLoopBackOff (repeated crashes), Error (startup failure), Terminating/Unknown (node lost), and Evicted (resource pressure). Use kubectl describe pod and kubectl logs to diagnose.

Kubernetes resource limits

Pods have CPU and memory requests and limits. Exceeding the memory limit triggers an OOM kill; exceeding the CPU limit throttles the container.

Soft vs hard links

A soft link creates a new file that points to another file’s path; deleting the target breaks the link. A hard link adds another directory entry to the same inode, cannot cross filesystems, and the file persists until all hard links are removed.

Permanent mount configuration

Add an entry to /etc/fstab with the device UUID, mount point, filesystem type, options, dump flag, and pass number, e.g., UUID=... /media/aborn/data ntfs defaults 0 2.