我能想到的一个主要区别是kubectl apply可以用于所有Kubernetes对象（Pod，Deployment，ConfigMaps，Secrets等），而kubectl rollout专门适用于处理一些计算的对象，如Deployments，Statefulsets等。
此外，kubectl rollout restart对于重新启动pod很有用，而不需要在spec字段中进行任何更改，这在kubectl apply中是不可能的。如果我们在spec字段中没有更改的情况下运行kubectl apply，则pod将不会更新，因为没有需要更新的更改。
考虑这样一种场景：某些配置（比如外部证书）作为ConfigMap挂载到pod，而ConfigMap中的任何更改都不会导致pod自动更新。在这种场景中，kubectl rollout restart可以用于创建新的pod，然后可以从ConfigMap读取更新的配置。
另外，文档中有一个重要的说明：
注意事项：当且仅当Deployment的Pod模板（即.spec.template）发生更改时，才会触发Deployment的rollout。例如，如果模板的标签或容器映像发生更新。其他更新（如缩放Deployment）不会触发rollout。

kubectl apply -f用于应用配置文件kubernetes（在其中部署所需的应用程序）。
kubectl rollout用于检查上述部署的应用程序
例如
假设你的部署配置文件看起来像这样，你保存在nginx.yaml文件中。现在你想从下面的yaml文件部署nginx应用程序。所以你应该使用kubectl apply -f nginx.yaml，现在你想检查你的应用程序是否使用kubectl rollout status nginx成功部署。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

字符串
如果你在本地更新了yaml，并且你想用现有的替换它，那么使用kubectl replace -f nginx.yaml

扩展Krishna的答案。
以部署为例。
如果您是第一次创建pod，添加新pod，更改配置（如副本），或者如果您在pod中有版本化的映像，并且您正在提升或降低版本，则使用apply -f <filename>。
在最后一点上，你正在提高或降低镜像的版本（由pod使用），如果你使用最新的版本，并且你运行apply -f <filename> kubernetes，那么文件中不会有任何变化。但是如果你确实更新了pod的镜像，并且你想rollout新的变化，那么你必须使用rollout。
此外，使用rollout，您可以使用部署的revisions（history）返回（undo）、pause部署和resume暂停部署。
有关卷展栏的详细信息，请参阅Deployments